The Pragmatic Programmers have announced the beta release of Agile Web Development with Rails, Third Edition. The final version of the book, updated to Rails 2, is scheduled to be released for October 2008. Even if the style of the tutorial is not...Excerpt from Zen and the Art of Programming at
Foi anunciada hoje a terceira edição do principal livro sobre Rails no mercado: Agile Web Development with Rails, que agora cobrirá o Rails 2. Na terceira edição, Sam Ruby participará como escritor-líder, junto com Dave Thomas e David Heinemeier...Excerpt from Learning on Rails at
This really isn’t the place to come for Ruby news. But that’s OK, because I have the pointers to where you should go. Plus, one of the news stories is making me think “Smells like Erlang.”...Excerpt from ongoing at
Ruby seems like it changes pretty often/quickly... And, as you point out in your tag line, “Rails just keeps on changing”. I’m curious what the conventional wisdom is, with respect to using either/both of them in a production environment. In particular, it seems that they change so often that, were you to upgrade them as they evolve, you’d be spending a lot of time running regression tests (and then fixing whatever may have broken as a result of the most recent set up updates).
I come from a corporate environment, where the idea is to create a tool, and then spend as little time maintaining it as possible — because your small, underfunded team has to move on to the next thing. :-) Is it practical to use Ruby and Rails in a situation like this? Certainly, you could deploy an application, and then never upgrade the underlying Ruby and Rails. But then, you don’t benefit from security patches, performance enhancements, and the like.
Any thoughts/rules-of-thumb?Posted by Ruby Watcher at
I come from a corporate environment, where the idea is to create a tool, and then spend as little time maintaining it as possible
Forgive me, because I’m going to exaggerate a little to make a point. Rails works best in environments where the focus is to spend as little time as possible to create a tool, and as much of the total effort as possible on maintenance. Of course, they use different words to say this, but they mean essentially the same thing. Furthermore, the goal is to make the total effort be 1/3rd or even 1/10th of the total effort of approaches where tools must be perfect before release as the expectation is that they will receive little attention in terms of maintainance.
All that being said, Ruby has been stable over the life of the book. It is Rails that has changed the most. And changed in ways that affect the book and people new to Rails more than people who are using Rails. As an example, scaffolding — which was previously envisioned as something that quickly got you started, and most of the time just as quickly discarded — radically changed into something that doesn’t get you started quite as quickly but what is produced can remain, evolve, and grow with your project.
There also have been features originally present in Rails that have subsequently been deprecated and ultimately removed. This affects book authors and maintainers of tools about the same. A global rename of files ending in .rhtml to .html.erb is an example. As the number of content types produced by Rails applications and the number of templating engines grows, it makes more sense to separate these two concepts. These types of changes are neither hard nor time consuming.
Such active pruning keeps the framework light, easy to learn, and easy to keep up with. The disproportionate down side falls to authors of books as opposed to tool builders.Posted by Sam Ruby at