21–30 of 102 posts
Why is this using Amazon servers? Wouldn't it make more sense to use purpose-built machines for this?
Earlier quoted context omitted.
Unfortunately we're not doing any recordings -- it's hard to be candid and recorded for all history at the same time. :(
This is an absolutely baffling comment. Particularly for a community (hackers) that value openness and transparency above pretty much all else. What in the world are you talking about, to a general public audience, that can't be heard by the rest of the world?
The question I have is, how do we get government to hire teams like this in the first place?
Build a federal gov run IT branch that isn't the NSA instead of contracting things like this out?
On another note I am really delighted to see that the government was forced to step out of their bubble to make this happen.
Earlier quoted context omitted.
Unfortunately we're not doing any recordings -- it's hard to be candid and recorded for all history at the same time. :(
This is an absolutely baffling comment. Particularly for a community (hackers) that value openness and transparency above pretty much all else. What in the world are you talking about, to a general public audience, that can't be heard by the rest of the world?
Why is this using Amazon servers? Wouldn't it make more sense to use purpose-built machines for this?
No. You serve the static assets from a CDN, but the authentication and dynamic content generation need to scale very quickly when you have an in rush of traffic. This is the perfect use case for Amazon AWS (GovCloud, specifically). EDIT: Disclaimer: I did not work on Healthcare.gov, but did study up on the entire architecture while trying for a gig on the recovery team.
A bunch of the folks in this article are Y Combinator or Google alumni, and we're giving a talk on Saving HealthCare.gov next Thursday in SF for anyone who's interested: http://www.eventbrite.com/e/saving-healthcaregov-tickets-118... Let us know if you have questions! Or if you want to help. UPDATE: we seem to be sold out. Trying to find a larger venue. In the meantime, feel free to sign up on the waiting list and yo…
How do you, as technologically savvy people who are in a better position than most to understand the grave transgressions of the NSA, reconcile your support of an administration that has shown complete disregard for our privacy and civil liberties (specifically within the scope of the NSA/Snowden scandal) with your inherent duty, as an engineer of powerful systems, to above all further the public good? As a subtext, what are your thoughts on continuing to further said administration's political aims in one arena while they restrict your rights and livelihood* in another?
Furthermore, and more on topic, what steps have you taken to place privacy concerns at the forefront when creating a service that consumes vast amounts of personal and medical information from millions of people?
Last, as someone who has been "on the inside" do you see corruption as a large problem with government procurement? To what extent did corruption create the situation that you were called in to fix with the original HealthCare.gov fiasco?
*assuming, of course, that the NSA/Snowden revelations have hurt US tech interests
Edit: Mods, if you disapprove of this comment feel free to delete it. That said, I think these are some important questions that need to be asked.
Earlier quoted context omitted.
Unfortunately we're not doing any recordings -- it's hard to be candid and recorded for all history at the same time. :(
This is an absolutely baffling comment. Particularly for a community (hackers) that value openness and transparency above pretty much all else. What in the world are you talking about, to a general public audience, that can't be heard by the rest of the world?
The question I have is, how do we get government to hire teams like this in the first place?
It's incredibly difficult. When government money is involved the good old boy network swings into action. Contractors are picked based on political connections first and actual capabilities second.