HN user
The Rails framework is written to reload (reevaluate) most application code between requests in development mode, so that changes during active dev are reflected. This is not the (default) behavior in production.
This is an example of a Socratic Dialog[1], and relies on metaphor. It's in that way a piece of art useful as a teaching tool, but as such it trades some precision for the end effect.
> Omitting the return statement is a good thing? How do you know if this method even returns anything?
In Ruby, all methods return the value of the last expression executed in the method.
> .size could be a method that doesn't return anything, right, since parens are optional?
This is in theory true but never happens in practice.
Edit: Ruby has no "non-method" properties on objects. Everything is a method call, regardless of use of parens.
> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.
An experienced Rubyist would catch it, if not at first glance, with the second. This is used relatively sparingly, and in scenarios conceptually similar to an early bailout return statement. It makes sense where it makes sense, if you will.
Neither of these is a problem in practice. It may be an issue of familiarity and comfort with the language, but in my experience it doesn't take long to be comfortable with either of those conventions.
A combination a bootstrapping issues (arguably minor, of course) and the minor complexity of building the package, plus the workshop-friendly approach contribute to the zip directory distribution method.
Right, this would be very valuable as a teaching resource, and thus indirectly valuable to the, I believe, sizable chunk Ruby/Rails community at large who enjoy doing it as their "day job".
Though I'm quite thankful Engine Yard chose to fund his work, I'd categorize doing so as an investment than a generous act. Nothing wrong with either, of course.
I read the accent as being on his track record of delivering on open source software efforts. In other words, he's demonstrating the soundness of investing your money toward his goal. Regardless, count me in.
I interpret the statement as being closer to "function pointers are under-discussed".
Not really disagreeing with your contention, but there are probably different applicable definitions of "failure" here. It could be argued doing what one loves is inherently successful, etc. (I'm sure you're familiar with the sentiment.)
The reply seems immature from the perspective of project maintenance.
Do note, as is mentioned in the comment Thread for the gist, that Fibur is also fully Ruby 1.8 compatible...
I think you're being downvoted for poor reading comprehension and for the entirely unnecessary and contextually-inappropriate use of the term "bitching".
So perhaps it would be generally beneficial to simply oppose online "dickery" and bullying across the board, particularly in cases where there's a component of implied threat beyond the virtual world. "Men are treated unfairly" is an unsympathetic point, even when true.
"I am honestly surprised that she let her real email address be publicly available anyway"
This is called "blaming the victim". It is bad, and you should consider researching it.
Bald-faced pimping of a resource the company I work for, EdgeCase, put together as well: http://gitimmersion.com/
This isn't really true, particularly with Rails 3. If you don't want to use the ActiveRecord database patter, don't use the default ActiveRecord ORM that ships with Rails. Drop in DataMapper instead, and use whatever pattern you wish.
Rails != ActiveRecord these days.
All of this "Rails makes you do X; or, well, you can do Y" is conflating Rails as a framework with Rails' ActiveRecord library, which is the default ORM. Since Rails 3, you can easily, and effectively transparently, use DataMapper instead, which is a general ORM that supports whatever pattern you wish, not simply the ActiveRecord pattern.
Mind you, prior to Rails 3 this was a heinous world of pain, so it's understandable to overlook it.