Snowdevil: First e-tailer on Rails

I’m proud to announce the launch of the first e-tailer to go life with Rails Inside: Snowdevil. Especially so because the team behind it has core contributor Tobias Luekte at the technical wheel and because the site just looks cool and sells something as cool as snowboards.

It took Tobias and crew just under four months to produce the application that KLOCs in at around 6. In addition to the launch of Snowdevil, the team is looking to extract a platform for creating shops quicker with Rails. So if you’re looking into starting a shop project on Rails, you should have a chat with Tobias and see if that’s a platform that might be right for you.

Tobias posted a post-launch announcement on his blog (also powered by Rails) where he attributes the success of the project to Ruby on Rails and their TDD/XP practices. The flattering bit about Rails:

I consider the unveiling of Rails as one of the biggest jumps in productivity the computer industry has seen since it moved from assembler to high level languages. This is the time where small businesses can compete or outperform big businesses just because of better tools. You need to be as efficient as a team? No problem! By the end of the year most companies worth a damn will use Rails or a clone of it. Be ahead of the curve.

Tobias, who is also known as xal on IRC, is certainly doing his part to further Rails as well. If you look through the changelogs, you’ll notice just how busy he has been over the past couple of months bringing the framework further.

So. Do shop your next snowboard at Snowdevil. Do talk to Tobias and crew if you’re looking to get a jumpstart on your Rails-powered shop or e-commerce project.

When longer is better and more is more

The father of Java, James Gosling, is traveling the down under and has some.. erhm.. “interesting” thoughts on scripting languages. I’m getting these sound bytes from Alan Fracis’ summary of the Sidney meeting, so there is a chance they might not be accurate, but here they are:

Opinion of script languages – Perl, Python, Ruby, PHP
Program density and comprehensibility are inversely related
Write Once, Read Never. TECO was worse. Rapid Development
static typing gets you to prod faster, scripting gets you
to demo first. easy to write small things, harder to wrote
big things.

Oy. First of all, lumping all these dynamic languages together under the convenient banner of “scripting” to attack them in symphony is disingenuous in itself. But claiming that writing a long program leads to a more comprehensible one is just plain silly. I hope that wasn’t what he meant.

Additionally, the artificial distinction between “demo” and “prod” in a post-agile world rings awfully hollow in that High Priest of Architecture kind-of-way. Once more oy.

Address book tutorial in Portuguese

Learn how to build an address book using Rails. Or, learn to read Portuguese, then learn how to build that address book. Regardless of whether you need step two of that or not, I’m told that Ronaldo Ferraz has done a fantastic job to present Rails. The introduction bit:

Rails é uma nova biblioteca para aplicações Web que está conquistando as mentes e os corações de desenvolvedores em todo o mundo por causa da flexibiidade e poder da mesma. Este tutorial apresenta a tecnologia e mostra como a mesma pode ajudar a produtividade de qualquer desenvolvedor.

Amen. Oh, and the whole thing is available as a 47-page PDF complete with loads of screenshots. Great local stuff indeed!

Becoming a better programmer with Rails

Justin French have survived the first week on his transitionary journey from PHP to Rails. I have special sympathy for refugees from that camp as I used to do a lot of PHP myself not too long ago. Justin sums up his experience with:

I also think that a Rails developer is inherently a “better” programmer by force. PHP makes it very easy for anyone (myself included) to slap together some poorly planned procedural code and claim the title of “PHP Web Application Developer”. Rails on the other hand at least tries to make us better programmers by default.

It’s certainly possible to write PHP that doesn’t succumb to the draw of becoming a big ball of mud, but the structure is completely self-imposed. Easy to slip if you’re not careful.

Seems like Justin has quite a following of other PHP’ers curious about Rails, so its great to see that he’s continuing to blog the transition and hopefully instill others with the courage to do the same.

Really Getting Started in Rails

Amy Hoy is a designer, programmer, and writer digging into Rails. She read Curt Hibbs’ great introduction article on Rails at O’Reilly’s OnLAMP, but decided she’d like to decorate it a bit with why’s:

The only thing is, like all tutorials, it doesn’t always explain why. Why is that the syntax? What does that line mean, exactly? Why is the application designed so it fits together that way? Me, I like to know why—in reality, because of my designer brain, I have to know why to really grok it and retain it.

That decoration turned into a whole article entilted Really Getting Started in Rails that works very well as a companion to Hibbs’ original article. Great work, Amy!

Off the Treadmill, Onto the Rails

Mike Clark, author of Pragmatic Project Automation, caught up with me for a few quick questions about the automation of Rails. A snippet:

Mike: Everybody who tries Rails raves about how it makes them super productive. What types of automation does Rails employ to help developers create great apps so quickly?

David: The basic philosophy is to encourage good behavior through invitations. So, for example, when you use the generator to create a new model or controller, it also creates unit test stubs that are all hooked up. You just enter a new test case and off you go. The same goes to fixtures, where a YAML file is already created and hooked up, just waiting for you to input the data…

We also talk about Rake and continuos integration with Damage Control. Additionally, it was great to see Mike so excited about Rails:

Rails projects are popping up all over. I just started converting a small J2EE project to Rails, and let me just say that Rails is highly addictive stuff.

Rails 0.9.5: A world of fixes and tweaks

This release is mostly about polishing the Rails by closing holes, deficiencies, and subtle extensions to existing features. The long-awaited Directions and generator upgrade have been postponed to the next release. The highlights of this release is:

  • Rewritten reloading: Working in development with models and controllers reloading on every request now resembles “the real thing” a lot more by actually removing the model classes before reloading them. This fixes a bunch of subtle bugs and makes it possible to remove a method and see it reflected without restarting the application.
  • Create and update collections: Through calls like text_field "student[]", "last_name", it’s now much easier to get input tags like input name="student[123][last_name]"..., which together with the fact that Base#create, Base#update, Base#destroy, Base#delete, AssociationCollection#build, and AssociationCollection#create now all accept arrays enables handling of many records at once.
  • Stopping after render/redirect: Any before_filter can now terminate the chain by calling render or redirect and the pattern of redirect-and-return now works again. The first call to either render or redirect wins as well and subsequent calls are ignored.

That’s just three of the 37 changes, fixes, and additions available in Rails 0.9.5. You can read the full story in the changelogs for Active Record, Action Pack, and Rails.

This release shouldn’t require any changes to your application if you’re coming from Rails 0.9.4 unless you were relying on const_missing to load non-AR/AO/AC classes. In that case, you’ll have to start being explicit with require_dependency for the reloading to be triggered.

Pedrosa on Rails vs WebWork: 'Language DOES matter'

Joao Pedrosa has been using both Rails and WebWork and iterates five key points on why “…WW is clearly inferior to Rails in every aspect” before arriving at the following conclusion:

Although I think RoR is superior to all Java web framework I used so far, I really respect the WW guys for building this framework which is one of the coolest in Javaland (unfortunately still ruled by crapware like Struts) but there is absolutely NO WAY any Java framework can compete with RoR… just try to build some real life app with it to figure out yourself how much precious time you’ve been wasting until now.

Time to shutdown IDEA and launch TextMate, 2005 will definetly be the year of Ruby on Rails! :)