I've been working closely with our intern Cory, and have now been put in the situation of having to explain why Rails is doing X or not doing Y more in the last couple weeks than the whole of the last several months. (It's also worthwhile saying that it's incredibly nice having someone to bounce thoughts off of again - no more coding in vacuum.) After each time one or both of us gets tripped up on something, I'm reminded to store that bit of knowledge somewhere useful.
I'm going to be more diligent about reading Rails code - I've done my fair share of poking, but I'm going to be much more stringent about reading documentation and code to really understand what's going on.
I'm going to stop lurking / being an isolationist on Github and be more proactive about submitting patches, which I've been improving at over the last few months (especially for documentation, as I encounter things that end up being "duh" moments).
First up, `redirect_to`:
redirect_to is an awfully common method in controllers, and most people use it without thinking or looking too deeply at the internals. Cory tried to be a little more correct with one particular redirect_to, though, by adding
:status => :unauthorized, and we found that the controller, in fact, no longer redirected the user. Instead, it displayed a "You are being redirected." message and simply sat there.
Digging into the source shows us that
redirect_to works by returning a HTTP response status of 302 to the browser (of course) - which then knows to look up response's
location and fetch that instead.
So when a 4xx response code is passed in, it overrides the default 3xx redirect status code and the browser simply displays the response_body and (seemingly) chokes. I've committed a change on the docrails Github project to clarify this point for anyone staring at the documentation in the future.
More up in a second blog post!
Let me know what you think on Twitter.