druidgreeneyes
- provide me a way to use your tool locally during development, in place of (or wrapped around) the standard build tool for my language, and a guarantee that (within reason) it will give the same results on my machine as it does when running an automated job managed by the server. Give me clean, detailed ways to inspect the difference in situations where the behavior differs between my machine and the server. This would in theory help me to reduce the incidence of "works on my machine" sorts of errors.
- Give me a a well-documented http/s api, and a way to add arbitrary endpoints to that api, which trigger arbitrary scripts/jobs (or just query arbitrary subsets of data from my first point above). I should be able to decide whether my new endpoint is specific to some arbitrary grouping defined for my org (and thus only visible to members of that grouping) or available to anybody who can reach the endpoint. (I'm thinking of teams practicing radical transparency, who might want to, say, provide a public endpoint that anybody can hit that provides various build metrics; or teams who want to provide their product owners or business stakeholders a controlled window into parts of the process, without having to build their own services to provide the api for that window)
- give me an easy way to wrap a debugger around a given job or step, locally or remotely, and a clean interface for stepping through it and (if appropriate) walking the stack.
- save a run as an artifact, so that it can be marked, saved, exported, reviewed, downloaded, and stepped through safely at a later date and on a different machine. I should be able to see responses that we got from remote resources without having to touch those resources when reviewing a job saved in this manner.
Anecdata: I'll admit to having the experience of, after playing Burnout: Revenge for many hours, continuing to view streets and traffic on my way to work through the lens of traffic-checking and drifting for extra points/boost. I hasten to add that I never felt the urge to -act- on that view; so much of driving is subconscious and/or automatic that I suspect we have something of a built-in buffer working in favor of normalcy here. But it was pretty surreal.
But, that idea ignores a fundamental problem with expert-based markets; it's impossible to me, as a non-consumer, to make a rational decision about which mechanic to use because to me, the mechanic is a black box. I don't have any way to immediately fact-check what they're telling me, and in the worst case, if a mechanic does something wrong, I may not find out about it until it's far to late to hold the do-er accountable. Thus, I can change mechanics based on the limited information I have available (price signals, perceived reputation) but, A) this distorts the market to optimize for low prices and perceived reputations instead of efficient prices for quality work, and B) I don't ultimately have any way of knowing whether I'm making the right decision when participating in this market. At least, not in the time frame where that knowledge is useful.
The same, holds true with 'free' health markets; I'm not a doctor so I can't accurately tell if my doctor is lying to me, which should cause similar distortions in an ostensibly free healthcare market. Additionally, as with an auto mechanic, if I need something done -now-, my demand for that service becomes completely inelastic, which means prices for emergency services/procedures should become obscenely high.
They already are today, and people are -already- getting forced into bankruptcy by emergency medical expenses, so I can't speak to whether or how a market sans insurance might change that phenomenon, but it seems to me that the goal ought to be to eliminate it entirely, and that in turn a 'free' healthcare market cannot be the end goal.
That said, I don't think I know enough about the subject to pick out a particular optimal solution to this problem. I like the -idea- of single payer or other universal healthcare solutions, but I haven't studied any of them in enough depth to analyse them critically; dealing with healthcare in the UK was a joy while I lived there, so I wouldn't mind having that experience here in the US, but that in turn requires a lot of government funding (among other things), and we can already see that that's unsustainable in the short term by what's happening to the ACA.
Location: Bath, UK (until October)
Remote: yes
Relocate: not until October
Technologies: Spark, HBase, Java, Clojure, Linux, Bash, AWS, Lisp, Scala, C#, F#, Apache, Python, SQLite
Résumé/CV: can share via email
Email: [email protected]