Rails and Merb -- Why Merge At All?

In my third round of mini-interviews about the Rails and Merb merger, I've turned to James Britt (@jamesbritt). James is a long time Ruby hacker and a fan of non-Rails web frameworks. If you think the merger is a panacea for the Ruby world, James' answers may give you some food for thought from a different perspective.

---

In a way, this reminds me of the gcc/egcs merger back in the day. What kinds of benefits do you think the Ruby, Rails, and Merb communities will see from this merger?

JamesWhat kinds of benefits? Very little for Ruby overall, some for the Rails communities. I don't understand the value to Merb.

Major disclaimer: I do some Rails work, but prefer Ramaze (and before that, Nitro). I did Rails for money, and Nitro for fun. For about a year now I've been free to use whatever framework I think best for a task, and that's been Ramaze, and limited time means I've lately not been keeping up on the all the goings on in the various Rails communities.

I did try to get a feel for Merb recently, and found it to be much nicer than what I know of Rails. If I couldn't use Ramaze, Merb looked to be an acceptable alternative. But whether or not I used it, the ideas explored in Merb (as with IOWA, Sinatra, Waves, Camping, and any of the other two-dozen or so Ruby Web frameworks) were of value because everyone could learn from each other and steal the best parts.

Because Merb was essentially (as best I could tell) a variant of Rails (with ideas from Nitro, Ramaze and other frameworks), it seemed easer for ideas to trickle back and forth between Merb and Rails. Rubyists had more options, and both Merb and Rails could feed off of each other. It seemed a win all around to have them independent.

The consolidation removes this useful competition. This is maybe a plus for folks who prefer Rails, and a gain for people who want to do things the Merb way but can now say they are using Rails. Less useful to people who want to see more distinct options.

The competition for the top spot in the Ruby Web Framework space has been good for everyone. What's going to happen now that the two big fish represent one, even bigger, fish?

James The idea that there is a "top spot" in the Ruby Web framework space has not been good for Ruby. There are real benefits to having a large, thriving community behind any tool or framework, but it's also critical to avoid a monoculture. It's better to have many thriving communities and an exchange of ideas.

There is a surprising mood among some Rubyists to want to see a "winner", for there to be just *one* of certain things. There's a cult of personality applied not just to people, but to projects as well.

The fuss over Merb v. Rails was a bit odd because it seemed (to this outsider) that the fight was over Pepsi v. Coke Cherry Zero, when in the back of the Ruby fridge we had mineral water, moonshine, champagne, and iced tea. There are lots of great things going on in Rubyville, things that aren't getting the attention they deserve.

Ruby appealed to me because it seemed to be about choice. One could craft a language on top of the language that suited the task at hand. You were not locked into the The One True Way.

If this merging helps people interested in Merb and Rails, great for them. But if it means less attention to the many other valuable Ruby Web tools, if it means fewer exchanges of ideas, then it's a loss for Rubyists at large.

Where else in Rubyspace do you think this kind of merger would be possible and helpful?

James What would be useful is more thought given to reasonable modularity rather than to more merging. For example, I'd like to be able to pick among Ruby tools for managing project tasks. Rake is the current leader there, though sometimes I want something a bit different.

But I'd also like to be able to reuse individual task definitions from my Rakefiles, even if I'm not using Rake.

Given that Ruby is so flexible, I should be able to move around in tool-space and still have a fair amount of re-use. I should be able to use templates and parsers and task runners and HTTP request routers and ORMS and never feel locked-in to one or another Big Framework. (Rack is a good example of providing mid-level granularity.)

I'd rather see less consolidation, less coupling, less emphasis on "winners" and "leaders", and more focus on solid, pluggable code, crafted and assembled by each of us.

Rails and Merb -- Better Together?

After my quick interview with Yehuda and Kevin the other day. I wanted to post a couple more points of view. David Heinemeier Hansson (@d2h) and Jeremy McAnally (@jeremymcanally) were good enough to weigh in as well.

---

What kinds of benefits do you think the Rails and Merb communities will see from this merger?

DHH We get to join the best ideas into Rails and make those ideas available to a much larger audience. We also get a bigger, better team for pushing Rails forward.

Jeremy I think this can only be good for the two communities. Bringing Merb's sensibilities to a large, mature codebase will not only open up a lot for the framework technically, but I honestly think we'll see a lot of innovation and, dare I say, *synergy* between the two cultures. There's been a lot of squawking about monoculture this or competition that, but honestly I think we'll see a lot more come out of working together rather than arguing with one another.

I have my own apprehensions about adding someone to the core team who isn't actually *using* Rails every day. One of the biggest wins for Rails was the fact that was and still largely is extracted from working code changes, additions, and extensions from working production code. Adding people to the team who aren't "practitioners" will create a slightly different dynamic I think, but I'm not sure if it'll end up being a good or a bad thing. I trust Yehuda is a very competent Ruby programmer, so I don't doubt that the code will be good, I just think the perspective may not be the same.

The competition for the top spot in the Ruby Web Framework space has been good for everyone. What's going to happen now that the two big fish represent one, even bigger, fish?

Jeremy As for non-Rails web frameworks, I don't think it means much. Frameworks such as Sinatra, Ramaze, Mack, and so on all have something fundamentally different to offer technically, whereas Merb and Rails were very technically similar in their goals. This similarity is why it makes sense to merge Merb and Rails, but it's also why it won't affect the other frameworks.

DHH You should look as competition being much larger than just the Ruby sphere. There are a TON of choices in this world to do web-based software. Everything from .NET to J2EE to PHP. In that picture, Rails is still a comparably small fish.

Where else in Rubyspace do you think this kind of merger would be possible and helpful?

Jeremy I'd like to see the ORM's become a little more singular. I'm hoping something like Active Relation or (a much simpler version of) Sequel or Ambition will create a Rack-like interface for ORM's to hook into so we can have different DSL's on top of a core that's super fast and tight.

I'd also like to see a merge in the realm of these extension libraries. There's Active Support, facets, extlib, this, that, etc. etc. that all do basically the same thing on one scale or another. Ideally we'd have some sort of core library that lazy loads/installs each piece or something so you don't have to have a gigantically huge library but still get the same functionality. Having a ton of hands working on these libraries will speed them up and make them more efficient.

You Got your Merb in my Rails

When the news about the Merb/Rails merger broke, I shot off an email to Yehuda Katz (@wycats on Twitter) to get his take on things. Here's what he had to say:

---

In a way, this reminds me of the gcc/egcs merger back in the day. What kinds of benefits do you think the Rails and Merb communities will see from this merger?

Yehuda The benefit is that Rails becomes a framework that can scale from a single-file, light app, all the way up to a full stack (perhaps even more full stack than Rails is today!). That means that people who were having to struggle to gain acceptance for Merb at their work will be able to leverage Rails' popularity, while also being able to hold onto the reasons they wanted to use Merb in the first place. A win-win.

The Rails community will get all the benefits of Merb in their favorite framework. Faster performance, a public API (which means plugins that break less), the ability to use other ORMs, and the list goes on and on.

As a whole, the community gets more smart people working with each other instead of against each other. This should help grow Ruby even more. I am absolutely convinced that this is the year we put away the myths of Ruby's so-called inadequacies by scientifically disproving them one by one.

The competition for the top spot in the Ruby Web Framework space has been good for everyone. What's going to happen now that the two big fish represent one, even bigger, fish?

Yehuda The competition has yielded results! Merb has proven out a bunch of ideas that the Rails core team now wholeheartedly embraces. That's only a win-win for everyone. Now that Rails will become more like Merb, it'd be great if another framework, representing a different community with different interests did exactly the same thing. Forcing Rails to acknowledge the needs of a community of people by proving those ideas out in code worked here, and it will work again.

Where else in Rubyspace do you think this kind of merger would be possible and helpful?

Yehuda The proliferation of rspec-like frameworks has gotten a little bit out of control. I'd love to see some combined efforts there. Dave Chelimsky, who runs rspec, has said over and over that he's in favor of cleaning up the core, which seems to be the big objection that people have that causes them to go make yet another speccing kit.

Hopefully future successes here will show people that it's possible to put aside differences and build something great!

---

I also asked Kevin Clark (@kevinclark on Twitter) for his take on the merger

Kevin I think the Rails/Merb merger has potential to be good and bad for the community. A single API for a unified set of tools and plugins is a good thing, clearly, and makes it more attractive to develop software in and (maybe more interestingly) for the Ruby web space. I feel Merb got a lot of things right when reconsidering how a web framework should be built, and Rails will benefit from that. Merb at the same time is going to be wrapped up into the Rails ecosystem that's churning out documentation and libraries at a sometimes dizzying pace. A bigger community will help smooth the edges that are still sometimes rough around Merb development.

The big thing that worries me is the competition aspect of the merger. Yes, sometimes the rivalry was silly and overly dramatic, but each group pushed the other to improve and pay attention to alternate lines of though and provide something better. I hope that discourse continues publicly. The worst thing to come of this would be that debates that formerly happened in the open, and produced new insights in the open, are hidden away in rails core.

One thing to consider is that this is exactly the sort of behavior Dave Thomas encouraged in his keynote at RubyConf. If we look at Merb as an experimental fork of rails (yes, this is horridly simplified) that gained popularity and was eventually folded back into the mainline, it exemplifies what Dave thinks we need to start doing with Ruby. So, I'd encourage more forking rather than merging. Even smaller libraries benefit. Just look at the Nokogiri/Hpricot arms race.

RubyZone, RailsSpace, and Ruby DVDs

dZone has recently introduced a set of ‘zones’ with original content, forums, and other things about specific topics to compliment their social bookmarking site. One of these is the RubyZone. I’ve been asked to work as a ‘Zone Leader’ there, writing new material and helping build the community. Even before I’d gotten there someone else had written some material, a review of the book RailsSpace: Building a Social Networking Website with Ruby on Rails.

Since there are a lot of people who can do a better job of reviewing Rails books, I’ve been trying to stick to pure Ruby (or other non-Rails) books recently. But I feel like I should point out something about this book. Addison-Wesley is moving their Professional Ruby Series beyond books and ‘digital shortcuts’ and into video with the release of their RailsSpace Ruby on Rails Tutorial

I’ve lent a copy of this to a friend from church who’s just getting started with Rails. Every week now, he comes up to me and tells me how wonderful Rails is and how excited he is to be working with it. The DVD contains over 5 hours of video spanning 15 tutorial sessions. Judging from my friend’s response, I’d say that this video is a great way to get started with Rails.

Practical Rails Projects Interview

To celebrate the close of the Holiday Practical Ruby and Rails blogging contest I wanted to post this interview with Eldon Alameda. He and I spent some time talking about his new book Practical Rails Projects and other Ruby and Rails topics. I'll be announcing the contest winners soon, until then, enjoy this interview.

---

Why do you think Rails is a practical framework for Web development?

Eldon I think my answer for this is pretty boring because it’s the common things that we always hear about when describing Rails. Rails not only made it easy for web developers to adopt many of the best practices that we had been giving lip service to for years, but it did it in an attractive and fun way that consistently rewarded you for doing things “the right way”.

For me – Rails made web development feel right again which brought back a lot of the fun that had originally attracted me to becoming a web developer.

What makes a Rails project ‘practical’?

Eldon I guess that depends on your definition of practical ;-) But in the context of the book I was thinking of the projects as “practical” based on the ideals that they were involved in the practice of Rails Development. So for me, what I really wanted to do with this book – was to create a series of projects that would help people learn Rails. I’m a big believer in the idea that the best way to learn a language or framework is to build a variety of projects with it. On my own hard drive I have a huge mess of dummy applications that were built just to play around with a specific feature or plugin, and I think that type of playfulness and experimentation is one of the keys to my success in web development.

How did you settle on the projects in the book?

Eldon Well like i said I for this book I wanted to try and help the readers by guiding them through the creation of a series of projects designed to explore features of Rails that I thought were important to understand but that might get breezed over in other books. So in that regard – I considered the project practical if I thought it was teaching something that would help build a better understanding of a principle or feature that would be beneficial to Rails developers as they launch into their own projects.

On the other hand though, I really wanted to try and make sure that the readers would actually have the opportunity to engage their own minds while building the projects, so I wanted to avoid too much “spoon-feeding” of the information to the reader. So I also tried to choose projects that might have a fun twist or angle on them – that we could get up and running fairly quickly in the book but leave ample opportunity afterwards for the reader to expand upon the ideas and projects to customize them for their own needs.

I really wanted to help people move from book/head knowledge of Rails to more hands-on experience.

How important do you think it is for a Rails developer to really know Ruby? What about getting involved in the Ruby community?

Eldon I actually think that a Rails developer can get pretty far with Rails before having to dig into Ruby. I like to joke that Rails is the doorway drug to using Ruby, because Rails really does make it possible to build some pretty complex applications with code that can appear fairly simple. Someone building a site in Rails may not even realize that they’re using things like blocks, iterators, etc. So in that regard it helps ease people into Ruby. Of course to provide balance to that statement – there is a pretty significant glass ceiling that comes into play for Rails developers who don’t dig deeper into Ruby (and SQL for that matter).

I do however think that it’s critical to get involved with the Ruby community at least at the local level. I’ve been attending my local Ruby users group for over two years now and I can’t begin to express what a wonderful blessing it has been to me along the way. It’s one of those few meetings that I truly look forward to every month. As I was starting out with Ruby – it was fantastic to be able to interact with Sr. Ruby developers who were kind enough to explain things or point me in the right direction for solving problems.

What did you learn about Rails while you were writing this book?

Eldon Curiously enough, writing a book like this has a dual edge sword – On the one hand I had to dig deeper into subjects that I wanted to teach in the book. So I have a much deeper understanding of subjects like caching, REST, and ActionWebService than I had before (or probably even need). On the negative side – focusing on the projects in the book meant that I had less time for personal experimentation which means that I “missed out / fell behind” on some pretty interesting developments within the Rails community this last year. Most notably was the wide adoption of Rpsec and the BDD paradigm – so once I’m past the holidays – I’m looking forward to going through the Peepcode screencasts on Rspec and setting up some test projects to experiment with that deeper.

What can Rails learn from other web frameworks?

Eldon I don’t want to stir up controversy but the only other web frameworks that I’ve built some production applications in are a few of the PHP based ones and the ones that I used really felt like they were behind the curve compared to Rails. Too much configuration, too many common problems left unsolved, etc. In some cases they just felt like they were simply trying to copy Rails rather than adopt the good pieces of Rails and forge their own path.

I haven’t had the opportunity to use Django yet but some people that I really respect are huge fans of it so I’m hoping to dabble in it a little next year—especially now that the official book is out.

Other than that now that I’m finished with the book—I’ve finally had a some more time to spend playing around with some of up and coming alternatives to Rails. This last month I experimented with things like Sinatra, Merb and DataMapper (which isn’t a framework but an alternative ORM). Of those – my favorite so far is DataMapper – even though it still has a ways to go before it would be ready for production – it’s a really fun library.

The interesting thing to me about these new ruby libraries is how reactionary they feel to Rails. There seems to be an emphasis on simplicity with how these new libraries are being developed that is kind of refreshing. Performance with these new libraries feels really good too.

How do you think the Rails community should react to these libraries?

Eldon Honestly I think that the relevant ideas will naturally make their way into Rails over time. While these other libraries have some fun and interesting ideas – I don’t see any pressure to try and push those ideas into Rails. One of the things that has always impressed me about Rails is it’s ability to glean best practices / ideas and integrate them into it’s own core in a fairly clean and natural way. Yet at the same time – Rails has maintained it’s strong opinions about what is the “right” way to develop web applications.

So in the case of DataMapper – I think it’s wonderful that we as developers can have other ORMs that we can use within our Ruby projects, but I don’t think I would ever want to see Rails adapt to support it and Active Record. Choice isn’t always good.

What plans do you have to follow up on the book? (A sequel, a blog/website, or something else?)

Eldon That is the million dollar question isn’t it? Unfortunately I don’t have a solid answer at the moment.

My days lately have been filled with doing contract work for the National Weather Service. It’s not Rails but it’s a lot of fun because of the scale of the web applications there. Those are fun problems to solve and I’ve been having a little extra fun there by introducing Ruby into a lot of the backend processing.

I’ve also been looking around to see if I could find a side Rails project that would interest me and fit with my schedule. But haven’t found anything thats really jumped out at me. I don’t have a ton of free time and I don’t want to waste it building “yet-another-social-networking site”.

I have been thinking about writing a sequel to this book as there was a lot of stuff that I didn’t get to cover in this book. I consider this book to be a beginner to intermediate book, so if I was to write another one I would want to take it up to the intermediate – advanced level. To do that I’d probably need to decrease the scope from seven to eight projects down to only two or three but dig much deeper into those few projects.

What projects did you want to include, but didn’t make the cut? Why not?

Eldon Actually, for me the bigger challenge was stopping development on each of the projects when I felt I hit that sweet spot where the project was up and running yet there was still plenty of room to customize it or take it in some fun new directions. But my goal was that if I was having all kinds of fun ideas about where to take the project next and it was hard for me to stop the project then hopefully it would also be hard for a reader to abandon it at that point as well.

That’s not to say that all of the projects I had originally wanted made it into the book. For example – I had planned on a completely different approach for a project that would utilize the new Active Resource library. The original plan was to develop three small applications (an inventory system, a simple wiki and a help desk ticketing system) that were going to be designed to communicate with each other via Active Resource. I think it could have been a fun and cool way to see how multiple applications could intercommunicate their data with each other. I even had built and written the chapters for the simple ticketing system and had some rough stuff started for the wiki and inventory systems—unfortunately I was using the needs of my employer at the time to help shape how that project should work. When I left that company – I had to make the hard decision to also abandon those projects from the book as well.

That’s too bad, it sounds like it would have made a cool set of projects.

Eldon Yeah – it was disappointing because I thought it was going to be a fun set of projects and nice that it was actually solving a problem for some people. In it’s place I put a project that used Active Resource to pull contact data from 37signals Highrise application and display those contacts on a Yahoo map. So I think that even though the projects are different the same principles were demonstrated / taught in a way that a reader could build the original projects if they desired.

What books would you recommend to get people ready for yours? What about as potential follow-ups?

Eldon I tried to write the book so that it could be a good next step for someone who has read an introduction to Rails book. As for a good introduction book I’m still a huge fan of the Agile Web Development book (even if it is a little out of date these days). The key is that the reader should have some basic familiarity with building a Rails application and some general idea of the features that Rails provides.

As for follow-up books – I’m a huge Ruby book junkie ( I think I have all the available books ) and every book will typically have at least something good in it. But for best value of learning code vs. price – I would recommend these:

Ruby Specific:

• Why’s Poignant Guide to Ruby — Just such as fun book to read and a great introduction to Ruby. Free
• Ruby By Example by Kevin Baird — is a fun little book which teaches Ruby principles through code examples $34
• Design Patterns In Rubyby Russ Olsen — This is a new title but one that I’m really enjoying. $50

Rails Specific:

• Money Train by Ben Curtis — PDF only book on building an e-commerce system. Doesn’t show you how to actually build anything but it’s filled with plenty of code examples $12
• Rails Code Review by Geoffrey Grosenbach (Peepcode) — Another great PDF book that demonstrates code $9
• Advanced Rails Recipes by Mike Clark — Although I’m not normally a big fan of the recipe format for programming books and this isn’t published yet, there seems to be a good amount of helpful tips in this one $40
• RailsCasts Screencasts — not a book but the information in these is invaluable. FREE

Holiday Blogging Contest

It’s been a while since I’ve run a blogging contest here but, just in time for the holidays, I’ve teamed up with Apress to run another one.

Earlier this month, they released Practical Rails Projects, and in December, they’ll be publishing Practical Ruby Projects. The idea of ‘practical projects’ sounded like a great topic for blogging, and the folks over at Apress agreed.

So here’s the deal, you write a blog post about a project you’re working on. Load it up with cool how-to information. Make it accessible and exciting to someone new to Ruby, Rails, or the specific domain you’re working in. Then, post a link to it in the comments below. After Christmas, the crack On Ruby judges will pore over the entries and pick two winners (one Ruby and one Rails). Each winner will receive three Apress books of their choice (electronic or paper copies).

Enter as often as you like, this is a great chance to build up your library while you’re helping build an online library of great Ruby documentation.

erubycon Contest

Continuing my happy tradition of letting readers win cool stuff, I have another contest to get started. Before I spill the beans (and tell you what you need to do to win), I’d like to fill in a little bit of background.

Last year, RailsConf and several smaller conferences joined RubyConf on the list of places discriminating rubyists might be found. This year, the regional Ruby conference scene has exploded offering a wealth of opportunities to get together with other ruby-folk and learn about what other people are doing with our favorite language. This summer promises something new though—erubycon. From July 16th until the 18th in Colombus, Ohio attendees will have the opportunity to learn more about using Ruby and Rails in enterprise settings.

Joe O’Brien and graciously put up some erubycon related prizes for a conference contest. All you need to do to enter is write a blog post about how you’re using Ruby or Rails in the enterprise, and post a link to it below. On 1st of June, Joe and I will read through all the entries and pick our favorite three. Our top pick will win free registration to the conference, and the two runners-up will receive erubycon T-Shirts.

Interested? Then get writing!

More About SoC and Ruby (Get Ready for the Proposal Window)

Google hasn't announced their final selection yet for mentoring organizations, but I'm operating under the assumption that we will be. Given that, this is the time for people to start putting together proposals for student projects. The window is only about a week long, and is opens up in just a couple of days.

We've got mentoring volunteers from the JRuby, RoR, rubinius, ruby, and Xruby communities, so don't feel constrained to any particular field. On the other hand, projects that are liable to benefit the largest possible group of users are certainly going to get some extra karma.

If you're not a student, but have a great idea, feel free to toss it out for discussion. Who knows, maybe someone will pick it up and run with it.

March Blogging Contest

Why does March always sneak up on me like this?

Now that we've finished the February Contest, it's time to start March's. We'll follow the same rules. Anyone who wants to submit a blog entry can just put a link to it into the comments below. On the 1st of April, Jason Gilmore and I, along with our guest judge(s), will read the entries and pick a winner. The winner gets 3 Apress books (print or PDF) of their choice.

The last two contests have been a bit 'Rah! Rah!' for some people, though I've enjoyed the entries. This month we're doing something a little bit different. No language, and no framework is perfect. Anyone who has more than a passing familiarity with one ought to know about its warts. With that in mind, March's challenge is —

What can Ruby on Rails learn from other web frameworks?

Give this some real thought and tell us about what you think Rails could do better. Give us an example of how another framework (it doesn't even have to be Ruby based) does it. Hopefully, we'll come up with some great ideas for the Rails core developers to chew on.

Write on! (I'm looking forward to your responses.)

---

Update: One of the Rails core developers has expressed some concerns with the topic of this contest. Just to be absolutely clear:

• This is not an official Rails contest ... Rails is opinionated software, and the core developers opinions are the ones that matter. (Of course, you might be able to help them see the light with a well written entry.)
• If you really want to see your ideas in Rails, you'd do well to remember: "Rails has never been about inviting suggestions, we'd prefer patches :)"

Author Interview: Rob Orsini

O'Reilly has just released the Rails Cookbook by Rob Orsini, and I've taken this opportunity to interview him. I first ran into Rob at the 2006 RubyConf, and I've been waiting patiently for his book to come out so we could do this interview. Hopefully it was worth the wait.

---

The Rails book market is getting full fast. Other than the O'Reilly name, what sets this one apart? Why should people buy it?

Rob: Well, from a developer's point of view, more books to choose from is not really a problem at all, right? Also, no market is ever really full — it just becomes unprofitable to participate in. Since profits from direct sales were not my motivation, it's up to each publisher to decide whether they want to push another Rails book into the market or not.

When I was asked to write a book on Rails, it was initially going to be Rails Hacks or Head First Rails. After some discussion, we decided to write the first cookbook on Rails. I did a little investigation and saw that Rails Recipes had been in the works but then was stalled for some reason. It wasn't until about two months into it, at O'Reilly's sales conference, that Andy (of the Prags) announced that Chad would be picking up Rails Recipes.

At that point I was a little concerned about duplication between the two cookbooks. It turns out though that our books are really very different. Chad's book is 70 recipes that range from intermediate to advanced, while my book has 190 recipes that really cover a much broader spectrum — covering many of the basics through some pretty advanced rails concepts.

Of course, my book took a lot longer to write, so we really ended up covering the framework at different times. The bottom line is that there is very little duplication between the two cookbooks and the consumer has the luxury of choosing between the two — or they can buy both.

I think that i did a pretty good job of covering all the material that a Rails developer need to know in order to become productive, fast. So far I've been getting good reviews but I encourage people to check out the table of contents to make sure it's the right book for them.

What is the appeal of the recipe approach in books?

Rob: The way that different people tend to learn is a very complex subject. Everyone might take a unique path towards mastery of a specific technology. I find that when I'm learning something new, I make a series of "passes" over the subject. The initial fly-over is analogous to skimming the table of contents of a book. Each subsequent pass reveals more details and hopefully leads to a more in-depth understanding of the subject. In terms of Perl books, for example, Learning Perl may be an initial fly-over where Mastering Perl for Bioinformatics would be much later pass. This is one dimension; that of varying degrees of complexity.

In addition to complexity, there's granularity. Think of granularity as the size of the chunks of information that are being presented within a book. A very small chuck might be a line from a Pocket Reference that says to use "params" instead of "@params" while a large chunk might walk you through the creation of an entire web application. The level of granularity I prefer in a book at any given time depends on how in-depth an understanding I need combined with how much time I have available at that moment.

I see a cookbook as a highly indexed body of medium sized chunks of information that vary in complexity. A cookbook is something you reach for as you're developing. You have a problem that you're trying to solve and you want the answer as fast as possible. The idea behind the cookbook is that you look in the list of recipes (and then their problem statements) and find something that resembles your problem, and then you have your answer. That's the goal anyway.

I don't expect that the cookbook format is right for everyone but I think having it in the selection of books a Rails developer has to choose from is critical.

You mentioned a Head First book. Do you think we'll see a Ruby book from the Head First team?

Rob: I expect so but I really can't say for sure. Head First books differ drastically from traditional books in that they only work with the perfect author. I'm sure O'Reilly is looking for that author but I'm not sure what the status of that is. I'll keep you posted.

What kind of Rails development were you doing before you started on this book? How did that experience affect the book?

Rob: About the time I started working at O'Reilly my wife and I decided that we needed to try to raise our kids on a single income. This meant that I had to fire up my contracting business up in order to supplement my O'Reilly salary. This was right around when Curt Hibbs posted his first Rails articles to O'Reilly's OnLamp.com. My Rails adoption route was probably similar to most; starting with amazed curiosity, followed by a healthy amount of skepticism ("Does it scale?", etc...), and finally by the confidence that Rails is, in fact, a better way to develop web applications efficiently.

I can't boast about any high profile Web 2.0 Rails projects but I had no trouble finding a steady stream of Rails work. I really got wrapped up in the excitement of Rails and wanted to share it with my friends and others. At that point I did couple of talks on the subject. In fact, it was at one of these talks (at a North Bay Linux User's group meeting) that I was approached by Mike Hendrickson from O'Reilly about doing a Rails book. Incidentally, Mike (an executive editor) and a few other O'Reilly brass were playing poker around the corner form our meeting.

Basically, I didn't enter the Book writing process as a total noob to Rails, but neither was I a Rails expert. Much of what I've learned about Rails, beyond my contracting experience, has been from researching and writing the book. Ironically, I think this is part of what makes this book work. I know the learning curve that new Rails developers are up against and I believe I've offered a clear and no-nonsense path past it, towards the end of being self-sufficient with the framework. But also remember that much of the book was contributed by other members of the Rails community — many of them having a enormous amount of Rails experience and expertise in areas that I was lacking.

With Rails 1.2 out now, how much of your book is already obsolete? How do you write a book against a target that moves this quickly?

Rob: You'll notice that the book states on the cover that it's been updated for Rails 1.2. This is because I made the decision in December to pull the book out of O'Reilly's production process in order to update it for Rails 1.2. At that point we already had a chapter on RESTful Rails development so there wasn't as much to update as you may think. Still, there was plenty of work to be done. Luckily, I had the help of a couple of my good friends; Christian Romney and Ryan Waldron.

I wasn't really sure when Rails 1.2 would emerge from it's release candidacy but the timing really couldn't have worked out better. My book went on sale a single day before Rails 1.2 released.

As for writing about a moving target, such as Rails; It was a challenge. There were many parts that I had written months before that had to be revised as new features appeared and as old techniques became deprecated. The good news is that you can see most new developments coming from pretty far off by staying in touch with the community and by following changes to the framework via the Rails Trac project and/or blogs of the people driving Rails development.

Part of what makes Rails exciting is it's flexibility to change with the evolving needs of the Rails community. While trying to document things as they change is sometimes difficult, I really wouldn't want it any other way.

What is your favorite recipe from the book and why?

Rob: One cool recipe that I've been thinking about recently is titled "Creating a Custom Report with Drag and Drop" in the JavaScript/Ajax chapter. The idea behind this recipe came from a Rails application that we use at work called Dove, written by John Butler. The idea behind Dove is that it allows users who don't know SQL or much about the complexities of our database to easily create custom reports from our database. Roger Magoulas, of O'Reilly's research department, designed Dove to be a web-based version of query tools like Brio.

Because of the back story of this recipe, it was interesting to see it mentioned on the Ruport mailing list recently. Someone suggested that a Ruport plugin for Rails should be created based on the techniques demonstrated in this recipe. Come to think of it, maybe I should work on that.

Have you spent any time looking at other web development frameworks? What can Ruby on Rails learn from them?

Rob: Over the years, I've had to deal with many web applications that probably should have used a framework, and occasionally some that were designed well enough that they could have had a framework extracted from them, but didn't. To confuse the issue, I've used many components of frameworks. For example, I've used several different ORM (object relational mapping) layers, and as many different stand-alone template languages. Rails is really the first full-stack framework that I've used for more then a single project.

Before discovering Rails, I was shopping around for a framework and was hoping to find a suitable one in the Python world. When I was webmaster at Industrial Light and Magic I was introduced to Zope by a friend (Jed Parsons). He was using it successfully for a large documentation management system for ILM's training department. My impression of Zope was that if you could climb its very steep learning curve then you could eventually be very productive. This seemed like a bit more then I needed at the time so I started checking out CherryPy — a lighter weight Python framework. (This must have been before Django and TurboGears were out in public.) Unfortunately, I never got a chance replace the Servlet/JSP based intranet I was in charge of before leaving ILM.

Shortly after starting at O'Reily, I jumped into my first Rails project with a friend of mine, Ben Bangert. We learned Rails together as we rebuilt a client's site that had been running PHP-Nuke. After that project, I worked on a few more Rails gig before eventually starting on the book. Ben, on the other hand, began writing Pylons. It's funny; the whole time I was writing the book, I had Ben IM'ing me about how he didn't like one thing or another about Rails, and that he had "fixed" it in the framework he was working on (Pylons). Pylons is built to work with the WSGI standard (Web Server Gateway Interface) and supports the idea of pluggable middleware layers. You can stack these layers together as needed. I think this could be an area for Rails to learn from, in terms of clean and standardized way to extend the framework. Rails plugins are great but there is no way to know if one plugin is going to work with another without testing them together. I think Pylons and the WSGI standard have a good solution for this.

What do you think are the most glaring weaknesses of Rails?

Rob: This might sound like an odd point, but I think it's the explosive growth of the framework. It may be that this growth is exposing weaknesses that might not otherwise have been problematic. The rate at which people are jumping into the community is really presenting some difficult challenges. The Rails mailing list is extremely high-volume and is almost a full-time job to monitor. Because of this, many people (some who may have a lot to offer new users) opt out and retreat to more private discussion venues. The same goes with the IRC channels. I assume this will all work itself out as more people get Rails experience under the belt, but this almost frenzy-like growth has definitely been an issue. I don't mean to say that growth is a bad thing for the framework — we just need to work on the logistics of being able to handle that growth.

Documentation is another weakness and one of the areas that suffers most in Rails. The early adopters tend to want to document the most advanced areas of the framework and report on new features the moment they see the light of day. This really leaves the bulk of the community without consistent documentation for some of the mostly commonly used areas of Rails. This is why I think my book is such a good fit right now. I tried to compensate for what I see as a void in general Rails documentation.

A final weakness that I'd like to point out is about process. I would like to see the Rails core be more traditional (professional, whatever) about their software release process. The way we bounced from Rails 1.1.4 to 1.1.6 (I call this Revision Reverb), and how the security flaw that caused all of that was handled, needs work. Open source works best with predictable release practices and security notification systems. Of course, all of this has been hammered out now, but I'd like to see Rails adhere to more established best-practices in its management. I'm sure we'll see improvement going forward, but I has been a weakness.

If you weren't programming in Ruby and Ruby on Rails, what languages and frameworks would you be using?

Rob: In response to a literal interpretation of that question: I don't feel that because I build a lot of Rails apps or even because I wrote a book on the subject, that I can't use other languages or frameworks. In fact I do. I love that I have the freedom to choose the best tool for the job. I like to think that I'm a pragmatist about the tools and languages that I use for any given project. I do feel strongly about Open Source tools and I always lean towards them when possible.

If I wasn't programming in Ruby and Rails, that would have to mean that they didn't exist. If that was the case, my top choice for a language would definitely be Python. As for a framework (again, assuming Rails was off the table), that would necessarily have to be Pylons because otherwise I'd never hear the end of it from Ben (who I sit next to all day).

What non-Ruby/RoR books should Ruby and RoR hackers be reading?

Rob: This one I can answer with out blowing anyone's cover, but what complicates the question is that so many people are coming to Rails from different backgrounds. So, I could repeat a fairly standard suggestion that software developers read the 'gang of four' Design Patterns book but getting a designer to work through that book might be a bit much to ask. For most people I think Chad Martin Fowler's Refactoring is a much more digestible approach to design patterns, as well is O'Reilly's Head First Design Patterns. Any kind of object-oriented design pattern homework a developer can do will payoff, especially with larger Ruby and Rails projects.

Database design is another topic I think that many Ruby/Rails developers could read up on. One of my first books on the subject was Database Design for Mere Mortals. I don't think you need to go too deep with database theory but you need get to a point where a metal alarm goes off when you see a bad database design. After all, this is the foundation of your application and problems born here will reverberate up the stack and potentially cause a lot of problems.

Another category of books that developers should read are on sound development methodologies. Right now, the Pragmatic Programmers have a number of good ones in this area. Practices of an Agile Developer is a good one to start with that will resonate well with common practices found in both the Ruby and Rails communities.

What I do is read up on whatever interests me at any given moment. When I hear about a new gem or a topic from someone, I add it to a text file that I store in subversion. This serves as a "todo" list of things to investigate, as time allows. One way to chisel away at this list is to divide the investigation up among a group. This is a great thing to do in Ruby or Rails user's groups or even your software team at work. Having other people do the leg work of looking into a new topic can help you stay on top of more subjects then you might be able to follow up on alone.

Ruby Hacker Interview: Jens Kraemer

I recently completed an interview with Jens Kraemer, a german Ruby Hacker, and the author of several Ruby and Ruby on Rails tools. Read on to learn more about Jens and what he's doing.

---

To begin with, would you please introduce yourself to the readers?

Jens: I'm 28 years old and live in Dresden, Germany.

I work as a software developer at webit!, a mid-sized IT-consulting and software development company specializing on web-based applications. I also keep a blog.

I started studies in economics and engineering at the Technical University of Dresden in 1997. Though I always was fascinated by computers and especially by letting them do what I wanted, I choose not to study computer sciences because it seemed far too theoretical to me. Later in my studies I selected computer science courses wherever possible (picking the interesting topics, and leaving out the theoretical ones, of course ;-).

I started earning money with software development in 2000 when I joined webit! for what I thought would be a summer job developing an e-commerce portal. The project died the .com death, but I kept working at webit! while trying to finish my studies by the way. So it took some time, but in 2004 I finally finished my diploma thesis. I stayed at webit! without looking around too much for alternative jobs, just because it's a really great place to work, without too many rules and with lots of cool people around.

How did you discover Ruby?

Jens: I don't know for sure, but I think the first time I heard about Ruby was in a conversation with Steffen Gemkow, an IT consultant from Dresden. Must have been 2002 or 2003, I think.

I then had a look at it, but at first underestimated it's power. I liked it more than Perl because of the cleaner syntax, and so I used Ruby for what I would have done with Perl otherwise - small scripting and screen scraping tasks, and some data import/export/conversion jobs.

I was a Java guy at this time and I didn't think too much about using Ruby (or any other scripting language) for 'serious' web apps.

Later I discovered an early version of Rails while looking for some ORM layer to simplify a database migration job I planned to do with Ruby.

I found quite interesting what I saw, tried it out in a small side project, and fell in love with it right away. I think the real secret to Rails' success is the Ruby language, at least that's why I prefer it to all the other newish Rails-like web frameworks written in other languages.

Are you using Ruby professionally?

Jens: Yes, we already did several Rails projects at webit!, some for customers, some for internal use. Right now I'm working on an ecommerce solution implemented in Rails for a publishing company here in Saxony. It allows customers to subscribe to online and printed versions of several official publications concerning saxon law and administration. Ferret-powered full text search is available to registered users, too. The site is located at www.sachsen-gesetze.de.

As time permits, I also do some Ruby/Rails freelance work.

What other languages are you using?

Jens: Recently I was involved in C# and Perl projects. Before that I've built J2EE web apps for several years.

What is the Ruby community like in Germany?

Jens: As far as I can tell - quite small ;-) But it seems to be growing. I really can't say much about this, there's not much activity Ruby-wise in or around Dresden. In other areas (Berlin, Hamburg, Frankfurt) there seems to be more movement, though. There's a quite low traffic german rails mailing list.

But Ruby seems to get momentum, recently a potential client explicitly asked for Ruby experience ;-)

What projects are you working on with Ruby?

Jens: Besides building web applications with Rails at webit!, I currently maintain two Ruby-related open source projects:

• RDig is a full text indexer for web sites and file systems written in Ruby
• acts_as_ferret is a Rails plugin for easy full text search across model data.

Both projects are built on top of David Balmain's great Ferret library.

In addition to that, I'm involved in the soon-to-go-live project led by Benjamin Krause, that David talked about in his interview ;-)

What can you say about this project?

Jens: OK, time for some planned leakage ;-)

The project is called Open Media Database or short, OMDB. As the name says, it's a database about media. Our goal is to provide objective, correct and structured information about media of any kind, be it books, movies or music. To reach this goal we combine full text information with structured, domain specific data. For now, the scope of the platform is limited to movies.

Basically all data will be open for editing by the public, just like Wikipedia. To ensure the correctness of the structured data, it is possible for a team of editors to freeze never-changing relationships like 'George Lucas has made Star Wars' to a non-editable state after they have been confirmed as correct.

All information will be published under a free license. we're currently looking into the CC and GNU license versions. Of course we plan to provide APIs for easy access to the database.

At the moment we're busy getting ready for a public beta. A team of film students and journalists is entering content into the site as we don't want to go live with an empty database.

You can have a look at our current development version here.

It's our testing server, so expect the occasional hiccup ;-). As we're mainly german natives, most of the content already entered is in german, too. But we plan to go live at least with english as an additional language. Most of the user interface already is translated.

We also have a blog.

Can you give some examples of how Ruby makes Rails better?

Jens: In general Ruby tends to not surprise it's user - most of the time even a novice developer can guess how to do something. That makes it very easy to get started with Rails for people coming from other languages.

From a more technical point of view, I think one of the important Ruby features that make Rails what it is is objects and classes being open to extension from the outside after their declaration. That enables the little goodies like '3.weeks.ago' as well as custom methods in Active Record relationships and plugins that build complex stuff such as versioning right into the framework.

Another example of using Ruby's power in Rails is when you create your own DSL for use in your integration test sessions - telling user stories with statements like 'joe.buys_a_book' makes testing really fun.

Another point is that in a standard Ruby installation, you have almost everything you need, in terms of functionality. So, any special needs aside, you have Ruby, Rails, and maybe the ruby-mysql bindungs, but that's it. You can start hacking away on your project and chances are you don't need any other libraries. Depends on the project, of course, but it makes installation and maintenance in general much easier if you have less external libraries to watch.

Compare that to Perl, where even object orientation is implemented in external modules. A project like Catalyst has to depend on so many external modules (not talking about the project itself being split into another huge set of modules), that it really can be a hard job to get everything installed in the right versions. Imho, you have to be a hard core Perl hacker to get a successful start with Catalyst. I don't want to say the way Perl does handle this is plain wrong, but it makes it harder to get up to speed with a new project, especially for people who are new to the framework and the language.

What problems have you seen with Rails?

Jens: Deployment could be really hard in the beginning (say before Mongrel was there). Zed Shaw is really doing a great job with Mongrel, and it became my preferred deployment platform right from the start.

Otherwise, I'm really happy with Rails :-)

Have you looked at JRuby at all for bridging the Ruby/RoR and Java worlds?

Jens: I did a short look at it, but at the time (I guess somewhere in between 2004 and 2005) it was still quite inactive and I decided to not try using it in production code. Maybe I would have taken a second look after JRuby got up to speed recently, but I didn't do any Java projects since then.

That said, a working .NET integration would be what I need now ;-) I've been watching the Gardens Point Ruby.NET Compiler project for a while now, but I think it will take at least a year until we can talk about using Ruby e.g. in an ASP.net web app.

I'm not an RDig user, can you tell me a bit more about it? Do you know how many people/projects are using it?

Jens: RDig mainly does three things:

• crawl for documents
• extract content from those documents
• index that content with Ferret

The crawling can take place in the file system, or on the web.

For content extraction there are pluggable content extractors for various formats (pdf using xpdf-utils, doc using the wv utility, and html - here you have the choice between a Rubyful Soup based extractor, and one based on the hpricot lib). The hpricot content extractor was the great news of the latest version of RDig, since it's way faster than Rubyful Soup.

In theory, the indexing backend could support other indexing libs, too, but I didn't feel the need to implement one yet.

There's also a CLI for querying the ferret index created by RDig, but that's more for testing purposes. You're supposed to write your own frontend for your index, think of the search in your intranet, or for a site search on a public web site. RDig however has some code to make accessing the index easy, there's no need to learn the Ferret API.

For the numbers, they're quite small. There have been 25/31 gem/tgz downloads of the last version in 2 months. However I have mails from several people successfully using it for tasks like intranet search. Some even send me patches - so I guess it's a useful tool for some people.

At webit! we use RDig for a client who has a web site that in large parts is built by a CMS that publishes static HTML pages. RDig crawls the site via HTTP every night and so rebuilds the index that is used for the site wide search (which is implemented in Rails).

FamilyLearn Interview

Duane Johnson and Neal Harmon are a programmer at and the president of FamilyLearn, a small company using Ruby, Rails, and Amazon's S3 and EC2. They've ported their applications from PHP to Ruby on Rails, and have recently started a Public Beta of their iMemorybook tools. I've invited them to share some of their experiences in this interview.

---

To start things off, would you two please tell us a bit about yourselves and about FamilyLearn?

Neal: My wife Trisha and I started this website as a little family project over 4 years ago. After reading a wonderful compilation of stories my grandpa wrote, we decided to collect stories about our family to share with our unborn son, Michael. The project evolved, went online, and was shared with other families. So, we became a company with the same vision for the rest of the world, build the world's most enjoyed family library. We're building a place where families can preserve and share the stories of their lives. iMemoryBook is a powerful software for capturing stories and publishing them as a hardbound book. The best part is it's free for families to use.

Duane: I've been a web developer ever since graduating from High School. I didn't know the difference between VB Script and Javascript in those days, so when my first boss said I'd be programming in ASP, I thought, "Great!" and they gave me a company laptop to boot. Since then, I've followed most of the webdev crowd as we've moved to happier and more sensible development languages. PHP was a nice, clean language for a large set of problems. But I was lucky enough to be an early-adopter for Ruby on Rails, as I'd been secretly using Ruby for a number of years before Rails 0.5 came out.

My first job also taught me a lot about what I wanted to focus my life energy on. I had an opportunity for a short time to help engineer the operating system software for an electronic slot machine. I found out quickly that getting paid for something I couldn't give my heart to was bad for both me and my employer. A number of jobs later, I'm delighted to work for a company that believes in family and preserving relationships. FamilyLearn is a smart company with a great leader.

How did you decide on Ruby and Rails for your development platform?

Duane: From my angle, as an experienced web developer, I wanted to enjoy what I do. I got pretty tired of re-inventing the wheel in PHP, or, if you'll pardon the analogy, trying to fit a Honda engine in to a Jetta. You can find anything for PHP, but getting the whole system to work right together was a real challenge for me — one that kept me up at night and eventually led to frustration and a search for something better. When I found out about Ruby on Rails, it just had to have "Ruby" in its name and I was already hooked.

Since Neal was already hearing good things about Rails, I think he just needed the right players with availability and he was willing to see what we could do.

Neal: I choose to give Ruby on Rails a try after reading "Agile Web Development with Rails". The framework conventions seemed to make programmers happier and more productive. I saw impressive demonstrations on the development speed of the technology. Also, I liked to use nearly all the websites that I encountered which had been built with Rails. They were, for the most part, simple and straight forward.

Our company faced some rapid growth on a hodge-podge of loosely tied together PHP applications, along with some Perl, LaTeX and TeX. The database reflected numerous shifts in the business' direction and changes in programmers. Bringing on new engineers to help the iMemoryBook service grow quickly revealed the weaknesses in our mess of code and we ultimately decided to green field our new iMemoryBook application completely in Ruby on Rails. I made the decision hoping for some miraculous development times before our company outgrew the old code (we were already having some serious growing pains).

What challenges has that created for you?

Neal: Initially, Rails didn't prove as fast in development times I had hoped (part of it was that two of us on the project were getting into Rails for the first time). It was a slow start in the beginning, but the benefits of the framework and our Ruby guru's (Duane) approach began to shine as the code base grew.

Duane: Choosing Ruby on Rails meant green-fielding the first version that Neal had put so much time and effort in to. We couldn't re-use a scrap of code once we chose Ruby. But as a testament to his flexibility and personal humility, Neal was willing to take a leap of faith — we built the database structure from scratch so that it would fit cleanly with ActiveRecord's expectations of what a database should look like. When Neal would look at the new database, he'd laugh so hard and say, "You can tell I wasn't a programmer when I started this thing, can't you?" This has been a blessing in the long run, but rebuilding what was basically an already functioning system was a real frustration for everyone at first.

Another area where Rails has not been kind to us is in its speed. Our iMemoryBook system is a computationally intensive process — sometimes taking minutes to complete a task (such as converting a TeX book into PDF format), which means that a whole process can be tied up for that long. We're still trying to figure out how to get this to work on a large scale.

Neal: When I asked Paul (our other developer) about this, he said:

Ruby itself seems just as fast as the next scripting language. It's not C, but nothing but C is. ... There are a couple of problems with rails/mongrel in a production environment. Ruby/Rails encourages lazy programming. The think the philosophy is something like, "don't work for the computer, let it work for you". If you are not careful you will be dong things the ruby way and not realize that you are hitting your database multiple times on every iteration of a loop. This just won't work in real life. You still have to remember you are working with finite hardware.

Duane: For our system, Ruby hasn't been the bottleneck. By far, using LaTeX in the back-end has been our challenge. It's just so hard to get speed improvements out of that system when it isn't really meant to be creating PDFs on-the-fly for each change the user makes. Once we address that issue with some caching techniques, we'll be able to see if Ruby becomes a bottleneck

In addition to using Ruby on Rails, you guys have been using the Amazon EC2 and S3 offerings. I'd like to spend a little bit of time talking about them too. Looking back on the past couple of months (the time you've been working with Amazon) what's stood out as the good and the bad?

Neal: Except for the struggles to successfully launch a SUSE virtual machine, everything has worked well for us so far. I have seen a few slow downs in our website that are not due to our own traffic. I suspect that the grid got hit by too much traffic all together and we weren't really getting our full virtual machine resources or we didn't have access to enough bandwidth. But, I don't know...we haven't done sufficient testing to determine if Amazon is the problem.

Duane, there's a lot of movement around S3 libraries for Ruby right now. Are the Amazon libraries good enough for you, or are you looking at any of the third-party offerings?

Duane: We've wanted some better tools. While the S3 sample ruby library that Amazon provided was a good starting point, it didn't seem to take advantage of some of Ruby's idioms. In other words, I guess it didn't feel like a Ruby library to me, and so it fell in to that "itch that needs to be scratched" category. I've taken a quick look at some of the nicer offerings that are now available, but since our code seems to do well enough with the current implementation, we haven't had a need to go fix it. In the words of my coworker, Paul Jones, "on a scale from terrible to beautiful, this code is 'working'".

What tools do you find lacking?

Duane: We've wished that some of our FTP tools would support S3. I use Panic's "Transmit" application for the Mac, and I've heard rumors that they may be implementing a solution soon. It would also be nice to have a more centralized "control panel" or something for all of the common tasks on EC2. The command line is a bare-bones kind of tool that gets the job done--with a lot of reference help. I'd like to see some kind of web-based administration system for tasks like backing up / duplicating your EC2 image, starting new instances of common images, and browsing what other shared images people have created.

How is working with EC2 and S3 different than developing for a local system?

Duane: There are some pros and cons to using S3 for file storage. Some of the benefits are widely known, such as infinite, scalable storage space and very fast content delivery. We've found some disadvantages, however, that have made things a little painful, but still workable. For example, we do a lot of image resizing in our application, so we have to decide between caching on S3 for speed and getting scaled / rotated images directly from our server. We've kind of struck a balance so far where some of our "probably not going to change very often" images are stored on S3 while our "probably going to change" images are generated dynamically. Another area that has sometimes surprised us is that uploads to S3 will fail inexplicably and so our code has to take retries in to account. Other than that, we've been quite happy with the fast transfer times between the two systems. Amazon has definitely thought out how the two systems orthogonally complement one another.

Neal, what changes would you like to see in the EC2 or S3 offerings?

Neal: I would like to see pricing that scales with a business. The day will come when Amazon will be more expensive than building our own system. We will need to switch when that day arrives. I suspect, even hope, there will be a company who will solve that problem for us before we get there. It'd be great if it were Amazon.

What advice would you give to someone who's looking at the Amazon Suite?

Duane: I think it's a great solution for small developers who intend to grow quickly. While a stand-alone server will work for quite some time, it's always painful when you hit that "wall" and realize your configuration isn't going to hold up against all of the traffic. Being able to turn on another server and/or rely on the distributed storage of Amazon is a decent way to scale on a budget.

Neal: Use both. Bandwidth between S3 and EC2 is basically free. It saves us a lot in image processing.

What advice would you give to someone who's looking at migrating to Ruby on Rails?

Neal: Consider hiring one RoR developer to guide your project and hiring other developers to learn RoR while helping with the project. It's difficult to find good RoR people.

Duane: Make the switch, and don't look back! Seriously though, if you're someone who takes pride in what you do as a programmer, Ruby is a great language with a great supporting culture. There are a lot of computer-scientist types in the Ruby world that make for good examples wherever you have weaknesses. And of course, the push for "convention over configuration" on the Rails platform is generally a good thing when it comes to quickly learning how to get things done.

I've saved myself often by doing something the "Rails way" by finding out later that a convention I'd followed earlier was smarter than face value. Web development isn't a new thing anymore, and we shouldn't have to be re-thinking the whole business each time a new application is built. That's why I said good-bye to PHP two and a half years ago.

Technorati tags: Ruby Rails interviews

Button, Button, Who's Got The Button?

Wow, the nice artists over at Apress have put together a button for this month's How Rails Made Me a Better Programmer blogging contest. If you've already submitted an entry, feel free to grab the image and use it with your essay. If you haven't entered yet, what's keeping you? Time's running out. Just go read the challenge and leave a link to your entry in the comments.

I'm hoping the Apress artists will come up with a special button for the winner too. Hey, three books and a button — what more could you ask for?

Update: I just realized that the button was an animated gif ... *sigh*. I've deleted it to see if we can come up with something better. Until then, I've pulled it. Sorry.

>p>Update again: Okay, new image, no animation, less ad-like.

Win Books By Blogging

Digg this

Update: ¿Hablas español? Mira aqui.

Update: It's time to get going on the February contest. — this one is now closed.

Update: It's time to get going on the March contest.

I can't tell you how excited I am to have Jarkko Laine as our guest judge this month, and even better, he's come up with the theme for this month's contest: "How has Ruby on Rails made you a better programmer". (You can read more about Jarkko in the interview I did with him.) Here's his challenge:

For me, the spell of Rails comes roughly in three parts:

1. Productivity boost
2. Having more fun
3. Doing the right things

#1 has been the reason numero uno almost everywhere Rails has been mentioned. I guess it's easier to sell productivity to managers than having fun ("oh, that's so unprofessional!") or doing the right things without rigid explicit processes. However, I see the increased productivity mostly as an inevitable consequence of the two latter points.

Much of my liking Ruby and Rails development more than other environments comes from the feeling of the language and tools being a natural extension of my brain. Why shouldn't I be able to write something like "2.weeks.ago"? It's easy to dismiss things like that as just syntactic sugar without real meaning, but you know, things add up, and overall happiness in work is built of small details.

Point number three could be described as the dullest and most minor benefit Rails brings to table. However, in many ways it's the grounding factor of both the happy Rails development and the improved productivity.

The things I include in doing the right things are stuff like making testing as easy as not to, conforming to the Rest principles and naming conventions, the MVC-type separation of concerns, and keeping yourself DRY (don't repeat yourself). I sleep my nights much better when I know that my application has extensive test coverage and that anyone knowledgeable with Rails can take it up in a few hours in case we need more labour force because the structure of the application is so obvious.

Now, none of these things are specific to or even popularized by Rails. However, many web developers have come to learn these lessons through Rails and I don't know any other framework that would make them as integrated part of the development process as Rails does. As the king of the Rails kingdom, David Heinemeier Hansson, has said, Rails tries to be the angel on the developer's shoulder ("Write your tests, it's as easy as not to!") as opposed to the PHP devil ("SQL in the views, quick'n'dirty, man!").

However, my imagination is very limited and I'd like to hear more about what healthy habits Rails has made people learn and what bad habits to abandon. That's why the topic of our January blogging contest is "Rails Revelations: How Rails made me a better programmer". Heck, if Rails made you quit smoking, tell us about it.

So, post links to your entries here, and Jason, Jarkko, and I will look them over the first week in February, pick a winner, and award the prize. Happy blogging!