InAnEmergency

Can't play when the company decides to stop spending money on servers...meaning your game will actually expire and stop working one day.

LastPass?

Not that this isn't a cool project, but the Twitter archive download comes with search-by-regular-expression built in, no server or database required. Just open up the provided index.html.

Brakeman will not check all gem dependencies and is not a general-purpose gem dependency security checker... bundler-audit will probably end up being the de facto tool for that: https://github.com/postmodern/bundler-audit

Yes, especially in web applications. Found that out the hard way.

Agreed. My wife's hybrid is rated at 35mpg, but it regularly gets more than 40mpg, sometimes as much as 48mpg.

Of course, if you get really creative... https://secure.drivers.lexus.com/lexusdrivers/magazine/artic...

It was certainly the high end (I think the range was $20-40), but relatively common for graduate students (edit: in this geographic area).

Yep, I was hired by a company where I did an internship and was actually paid slightly less as a full-time employee than as an intern (more benefits, though). As an intern I made $40/hr, hired full-time at $80k/yr.

> if you're expecting to work 40-hour weeks, you'd better be registered as a part-time student

Not all schools let you be registered part-time :'(

I often see this with sites that assume a GitHub account has an associated public email, when that is not always true. The Devise gem for Rails has this issue, if you are using that.

After just having spent a couple days wrestling with g.raphael.js, I would recommend against it. The documentation is vague and incomplete, the generated graphs are inconsistent (e.g., points placed outside of axes), simple bugs with fixes in pull requests have been sitting for months with no response...honestly it looks abandoned.

It used to be at http://www.calendaraboutnothing.com/ which seems to be down now. You can get an idea from the archives: http://web.archive.org/web/20110716142534/http://calendarabo...

Yes, exactly. This is only directly exploitable if the user can submit a hash with symbol keys. Otherwise, it seems like it would take some unusual code path in the app to exploit the vulnerability.

The original post of the problem goes like this:

1. Gain an application's secret key, used to sign session cookies. 2. Inject a marshalled hash with _symbol_ keys into the session cookie, sign it with the secret key. 3. Now you can exploit the SQL vulnerability in the dynamic finders, assuming the session value is used directly as input.

Last I heard, the firehose is something like 30MB/s of data. Maybe maintaining a pipe like that to a large number of subscribers is just not what Twitter wants to spend its time or money on.

The "homework" line is referring to people blaming unrelated events on Twitter's API changes.

Very cool site.