Jay-Z, is that you?

Hey jackhole, guess what? I've personally witnessed more than one registrar virtually automatically roll over in cases like this, without so much as a glimmer of a court order or even a UDRP filing to back anything up. Do you happen to work for GoDaddy or NetSol? If your employer is the former, tell Bob Parsons I said he's still the turd he used to be, that is if you can reach him these days. If it's the latter, you're probably trolling on their behalf, so take a 15 and try to think about what you're doing with your life.

You're 100% right. I'm presently driving a Hyundai Sonata (fantastic car, btw), and am considering either a Hyundai Genesis sedan or a Tesla Model S for my next car. The Genesis is a very nice car, but I'm strongly leaning toward the Tesla.

To be fair, Ruby as a language isn't the problem. However, Ruby on Rails and the atrocities of frameworks that are its spawn are frequently major problems.

You must have missed the follow up response I posted right after my initial reply.

No, it is not validly cached, at least not in any useful sense given the sea of caching proxies and user agents in the field. The headers presented merely hint that discretionary caching is okay, and do nothing to encourage caching either by proxies nor end user agents, nor inform such recipients of additional criteria which affects these factors. Please read RFC 2616 and come back when you're done.

It's not supposed to be. It is.

I'm not confusing anything. I've actually written a caching proxy from scratch, and there's a difference between saying the content could be cached and aggressively encouraging it. The headers are incomplete in this regard. Please refer to RFC 2616.

I'll just go ahead and directly quote from your notes:

You apparently don't spend very much time actually working with various caching proxies or examining the default behavior of various user agents when presented with various options (some caches follow RFC 2616 better than others, and different or incomplete response header combinations may well cause unexpected behavior as a result), or you wouldn't have wasted your time with a misleading and ultimately misleading response.

I've actually written a caching proxy and HTTP/1.1 accelerator from scratch. I suspect you haven't, which would have a lot to do with why you don't know what you're talking about.

Incidentally, I'm keenly aware they're using Akamai for CDN purposes. That doesn't make this any better; in fact, given some of their functionality, it makes it worse. Time for bed.

Let's examine an HTTP request for a rather beefy portion of the JavaScript in question from healthcare.gov:

pparadis::palegray-mobile { ~ }-> curl --head https://assets.healthcare.gov/global/js/lib/jquery-1.8.2.js
HTTP/1.1 200 OK
Server: Apache
ETag: "cfa9051cc0b05eb519f1e16b2a6645d7:1370524513"
Last-Modified: Thu, 23 May 2013 15:59:12 GMT
Accept-Ranges: bytes
Content-Length: 93436
Content-Type: application/x-javascript
Date: Tue, 08 Oct 2013 09:44:20 GMT
Connection: keep-alive

They're not even bothering to set the HTTP Cache-Control, Proxy-*, or Expires headers on this content, which will most assuredly limit intermediary proxy and client caching. To say this is amateur hour would be a gross exaggeration of the skills being fielded by these developers.

Much larger issues undoubtedly exist in their backend infrastructure. Given the shit I've seen in this area, I could probably spend the next hour making educated guesses about how badly they've fucked up in various regards, spend another hour partially validating those guesses, and wind up just saying "yup, they're idiots." Instead, I think I'll go to bed now. I have work in the morning.

So the story here is that a large team of software developers with no demonstrated experience in developing, testing, performing quality assurance for, and administering large scale enterprise application deployments get a federal contract and botches it horribly. Color me shocked.

I've been working in development and architecture roles for fifteen years, and have seen exactly the same pattern on a variety of scales over and over again. I've seen a number of rather large infrastructure development projects that worked out very well too, but none of those were public sector projects.

Just remember that the folks responsible for this mess are certainly still taking paychecks while an enormous number of government workers are suffering due to the inability of our Congress to do its job. Good times, huh?

You continue to make the assumption that he had no backup plan, and you offer (perhaps understandably, as you're not inside his head) no supporting evidence aside from statements on his part that any sane person would make, regardless of the truth of those statements. I've known a couple of guys who got in some trouble and had seven figures to lose, and be assured they both had contingency plans despite their pleas to the contrary. You aren't privy to his personal network of relationships; stop pretending you are. You shouldn't assume getting burned by one employee equates to never "hiring" again. I was once burned to the tune of USD $40K by an employee, which was not a small sum of money for me. I didn't stop hiring, but I did get smarter about it.

Aside from a fundamental misunderstanding of how scenarios on this level typically play out (they don't actually care about his money; they care much more about who he can help them grab to further pad their resumes), you make the mistake of assuming he'll be convicted and sentenced to anything more than a decade in prison. Conviction is uncertain, anything more than ten years is unlikely. Most men can do ten years with the knowledge that they have a fortune waiting on the other side, as long as they're smart about how they conduct themselves following release. Again, he wouldn't be the first guy to play it smart in this regard.

Once again, the people prosecuting him don't give two shits about Bitcoin. Think about that for a while.

Fair enough :). For the record, I've seen some pretty bizarre (read: wtf) stuff done in Python, Java, and certainly C. While I happen to greatly prefer Perl for various tasks, I'm also a big fan of coding to a style guide, whether adopted from an external source or developed internally, regardless of the language being used. I'm with you on context and structure.

When referring to the Perl programming language, the correct usage is Perl. Given the fact that you're apparently in a position to make hiring decisions on programmer positions, you would be well advised to be well versed in proper naming conventions. Incidentally, I've been coding in multiple languages, although predominantly in Perl, for twenty years. I'm not looking for a job, though.