Does this lead to a significantly smaller memory footprint than otherwise running .js in electron or a full browser?
I see you've become a big fan of bazel :)
HN user
JPL → Coinbase → Google → Unit 410 → Coinbase
[ my public key: https://keybase.io/witoff; my proof: https://keybase.io/witoff/sigs/G0bVxHtzRp4ALbVWewtkLPzMTDjELfwtbe0-d5ImkbE ]
Does this lead to a significantly smaller memory footprint than otherwise running .js in electron or a full browser?
I see you've become a big fan of bazel :)
In practice, cramming all this into the same account doesn't work. Segment is following best practice here.
For example, IAM doesn't provide the granularity in resources and conditions that you'd want to effectively isolate the blast radius of developer keys. ec2:TerminateInstances didn't (doesn't?) support VPC level conditions, so being able to terminate one instance meant you could terminate all instances.
Similarly, you might want your engineering team to iam:PutUserPolicy in development, but have a much more restricted group in production which isn't possible with IAM today.
I've taken this pretty far in the past to attempt segmenting within one account, but always run into limits: https://github.com/witoff/self-service-iam
Yep - See some of the work my last team published here while we were rebuilding deployment tooling: https://blog.coinbase.com/scaling-developer-productivity-d23.... For hard to measure metrics, softer measurements like repeated team surveys work fine too.
I'd be cautious of directly measuring "assistance" outside of peer input in perf to avoid an unhealthy incentive. The most helpful people I've worked with in the past tend to grow through strong peer reviews and having the most opportunities to join new projects.
The OP here really misses the point of demonstrating impact. Doing the right thing ethically then for the business is a strategy that is, well, rarely the wrong thing. Optimizing just for getting promoted might is a greedy strategy that might get you promoted once, but good luck finding peers that want to work with you again.
same here. our s3 services are reporting similar 503's and network timeouts. a few of our partners are already down as well with their own 500s. another stormy night in the cloud.
here's how we manage our dev environment: https://developers.coinbase.com/blog/2015/03/30/self-service...
full blog post here: https://developers.coinbase.com/blog/2015/03/30/self-service...
After 3 scrubs most of our non-critical colleagues left the cape, but the view of our payloads in the trunk after 2nd stage sep made it all worthwhile. It's amazing what SpaceX has been able to accomplish and reinvent in a business this risk-averse and I can't wait to see what's next.
I was the Launch Systems Lead for one of the primary payloads on this flight and was surprised when they announced this but excited to watch it happen (or attempted). Almost every Falcon/Dragon flight is innovating in multiple major ways which is NOT how Aerospace normally works, but why many of us we chose to work in the industry and a refreshing change.
From that list, etherpad looks like the most promising open source & self hosted solution. We'll give this a shot soon. Thanks.
Since this is the first request for collaboration with NASA we've seen on HN, are there other obvious problems you'd like to independently analyze with us? ISS? Rovers? Navigation? Deep Space Networking? (etc)
In practice this is an interesting problem for ISS. Considering the varying contingent of shadow-casting (and reflecting!) payloads, orbital replacement units, visiting vehicles and robotic elements the station's geometry is constantly changing. Then we have to consider system and lifespan effects. Solar array orientation alters the corresponding equilibrium attitude of the station and thereby the need for gyro and thrust stabilization. Along with problems we've had with overuse of the solar array rotary joints, there is a lot to consider after and optimal array orientation is found. Space is expensive.
Not with SAM. The best its 2 spectrometers and chromatographer will do is tell you chemical makeup.
Totally agree. The PR team is usually much more careful than this. This reads like a case of an excited scientist over indulging a friendly journalist.
Sorry but products are getting mixed up here. There is an older "Lockitron deadbolt kit" that was $295, and that's not what's being pre-ordered here.
Had to throw another instance behing the load balancer, so the data set is split. Will merge after traffic settles down.
Thanks @mparlane, turned off prime debugging but was still routing all requests through a WebError handler prior to hitting root. You can otherwise find the rest of the code here: https://github.com/witoff/BrowserAge :)
Yep, it's not very smart yet. There's a small json dict of firefox releases that it's referencing (https://github.com/witoff/BrowserAge/blob/master/data/age-fi...). I haven't updated past the stable releases so it's defaulting to the last known release date. Feel free to clone on github :)
Looks like you're on Safari, caught a bug in some of the newer user agents -- fixed now.
It approximates how long it's been since your browser was released and aggregates other stats based on referrer. I'm asserting that site's being visited by newer browsers are gathering a more tech savvy crowd.
Hey Paul, though I'm not drawing from the largest sample size I've computed my DOD with SpaceX to be 2.00, which is telling compared to my 178 average.
That's a great question - I'll reach out and see if we can pull one of their DODs too
The same concept can easily be applied to any tool listening on port 25.
Also, the text to speech portion can be accomplished with festival on linux and SAPI on windows.
sweet! bunch of entrep's and beer always great.