mpk

Yes, that would be normal. During an acquisition the future is unknown so you don't have a reliable roadmap you can use to set or update development goals. Other activities that take away from development could be developers working on capability demonstration or participating in technical due diligence.

(I don't know anything about the rethinkdb situation, I'm just speaking generally here)

Ember is fantastic, the oldest projects I have are about 4 years old and have been (more-or-less) painlessly upgraded every now and again. Everything is ember-cli and ember-cli-deploy now. Time and time again it shows that Ember is a community project that has a strong focus on scalability and maintainability over time.

I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.

A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.

That works very well combined with RFC 6902 - JSON-PATCH for partial changes to JSON objects, which in turn works nicely with HTTP PATCH method, RFC 5789.

Needs an active FB session to read.

Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar.

Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.

It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.

Otherwise, nice work and good job open-sourcing it!

That depends on how long it's been in the codebase. As this case is covered in the Rails security guide _and_ the Ruby security reviewer's guide I'd expect it to be quite old and now being found because it hasn't been properly audited before or indicate that the review process needs some work.

This article contains a number of fallacies. Storing sessions on disk? Over NFS? In the database? Please - no-one does that. And random MySQL bashing? What's that based on? MySQL is used by many high-volume shops to handle huge amounts of data. (See - I don't have to quote examples either!) And magic Oracle scales to infinity? For the kinds of database setups you need with high-performance web apps you can throw the same amount of money at percona.com and get there as well.

[Edit - didn't notice this was a 2004 article]

I'd like to know too, but I'm not skeptical of the 200k figure. If this is going to work then it's not going to be a solo effort, so let's say one or two more devs and someone to do QA or support or design or whatever and this budget is looking pretty tight.

If I'm on hacker news and I see the word cracking, I immediately hope this'll be some old school "let's open up IDA and see what's what here" article.

"And a Basecamp user uploaded the 100,000,000th file (It was a picture of a cat!)"

Aren't you supposed to treat user data as confidential and not examine the contents?