Are you watching the health of your software?

Kent Beck has probably been more responsible for the uptake of automated testing amongst the general developer population than any other figure over the last five years. One of the reasons is that he’s such a great speaker and writer that you can’t help but paying attention. Another, of course, is that automated testing is naturally a Good Thing to do, so it shouldn’t be such a hard sell.

Anyway, as the second edition of his Extreme Programming Explained is hitting the street, Kent has broadened his focus from just testing to the concept of software health. It’s not just about passing the tests today, it’s about being in a position that allows you to pass the test tomorrow too.

He talks at length about this and other great metaphors in an IT Conversations recording called Developer Testing. It’s about one hour of Kent’s thoughts. For free. So what are you waiting for?

When you come back, all energized with a strong desire to improve the health of your software, do check out Steve Kellock’s A Guide to Testing the Rails. Rails is uniquely supportive of getting your test game on with the least amount of configuration or even learning. For all the controllers and models generated, you already have test suites waiting for test cases to enter. And running rake will execute the whole lot of them.

If you do need a bit more assistance in exactly how you should do testing, and especially unit testing, I can heartily recommend the Pragmatic Unit Testing book by Andy Hunt and Dave Thomas. It’s available in both a Java and C# flavor, but don’t let that scare you off, pretty much all of the meaningful lessons apply directly to any environment. Combined with Steve’s guide, you should be all set.

As a rule of thumb, you want your rake stats to report that you have a 1:1 ration between code and tests.

Watch for huge requests on default FCGI

As you might have noticed, 43things have been down for the count a few times since launch with nasty 500’s. The cause was the combination of default FCGI settings and a bad-ass RSS query that pulled out everything from the system at once and took up a couple of pages in the log.

That action couldn’t be rendered within the 30 second limit that FCGI imposes by default, so Apache suspended the connection to FCGI and caused hits to that particular FCGI process to go out of commission.

Lessons learned…

  1. Make sure you don’t have any actions that take longer than the timeout limit in FCGI
  2. Increase the default timeout limit if you have actions that you expect to take close to 30 seconds or more

How the redesign of the website came to be

Jakob Skjerning is sharing some additional details on what we went through creating the new uniform look for Ruby on Rails:

The project was pretty interesting since we wanted to give the existing parts of the Rails web presence a uniform look’n’feel, mixing Instiki with Trac with RDoc with new additions WordPress and Hierarki. That’s 3 different scripting languages and 5 different ways of templating.

Learning Ruby on Rails with 43things

Ruby on Rails is already going strong on 43things. Learn Ruby is #2 and Write an application on Rails is #8 according to the 43things Zeitgeist. So if you already have done or are doing these things, please do let 43things know and share your experience with all the other people currently working on it.

About the experience of building 43things itself with Ruby on Rails, Erik Benson writes:

My first exposure to Ruby on Rails was when I sat down and started building the prototype for this site (43 Things). From the start, it was easy to learn, full of wonderous surprises, and it encouraged excellent coding practices such as separation of controllers, models, and views, unit testing, and documentation.

It has only been a little over 3 months since I started working in Rails, and 43 Things will be launching soon having been written completely with it. Having used several other languages and frameworks to build websites in the past for both personal and professional sites (I used to work at Amazon), I can say that this has been the most enjoyable one yet.

The Robot Co-op takes 43things.com live!

First things first: The Robot Co-op has launched 43things! Go check it out right now. It’s a portal for ambitions where you track the 43 things you currently want to do with your life. It’s growing fast to become a unique view into the dreams and desires of the human race. Check out my 43 things, sign up, check it out. You can read the rest of this when you’re done playing…

So, I first got in contact Josh Petersen back in late May of last year as he had been tracking the pre-release hype of Rails and was intrigued. That lead to a visit to Seattle in late June where I got a chance to hang with Erik, Daniel, and Josh for a few days to help them explore the idea, inject a (over?) dose of cocky Less Software mentality, and of course convince them that Ruby on Rails was exactly the platform they wanted to develop 43things on.

Over the following months, Josh and friends retained 37signals to work on the user interface, hired Ruby programmer Eric Hodel and three more guys to have a team of seven working on the company and their first Ruby on Rails application. I kept growing inspired by the idea behind 43things, the confidence shown by the Robots in Rails, and impatient to see the final result.

How fitting then, that the Robots would launch 43things on the first day of the new year. Just in time for you to enter all those New Year’s resolutions and committing to them in public. I’m already busy getting lost in the intensely intriguing world of desires. I could easily see one spending hours and hours and hours browsing the depths.

So there you have it. The second poster-app for Rails. Smashing! Huge congratulations to Ivan, Todd, Bob, Erik, Eric, Daniel, and Josh. You did it, guys. Can’t wait to see this thing skyrocket.

"Some amazing web apps appear on Ruby on Rails"

Luis de la Rosa is predicting the highlights of 2005, which includes plenty of Java goodies, such as Eclipse and Java 1.5 by default on OS X Tiger (that would be a nice move). But more importantly, Luis picks the rise of dynamic languages for spot number five:

5. Dynamic languages gain ground: Ruby and Groovy increase in usage, but no full-time jobs appear. Some amazing web apps appear on Ruby on Rails.

Luis made a safe bet predicting that “amazing web apps” will come barring the banner of Ruby on Rails: It happened on the 1st day of 2005! 43things.com launched and it is indeed an amazing web application that has the most lofty of goals: Push human ambition higher!

Luckily, Luis is already kinda wrong on “no full-time jobs appear, will be fully wrong half-way into the New Year, and even silly wrong by the end of December 2005. Companies around the world are already employing full-time Railers, like ”http://www.combustionlabs.com/“>Combustion Labs (4 developers), ”http://www.robotcoop.com/“>The Robot Coop (4 developers), ”http://www.collaboraid.biz/“>Collaboraid (3 developers), ”http://www.basesys.com/“>Base Systems (2 developers), ”http://www.37signals.com">37signals (2 developers), and of course a legion of independent consultants and tech departments in tons of universities and big corporations (read more).

But I agree with Luis that big companies won’t be picking up Ruby on Rails for real before 2006. So that’ll leave the front runners and early adopters among small companies with a significant competitive advantage for the entirety of 2005. Congratulations, guys.

Giving up on Java for lack of love

Kate Rhodes is yet another developer leaving Java behind for the lack of love. As she says: “I’m really good at Java. I know my way around it but I don’t love the language.” Life is indeed too short to be spend toiling your days away without feeling a passion for the tools of your craft.

As many other Java developers just getting out, she naturally expected that life in the shade would be just as hard as under the Sun. But then she found Ruby on Rails and this was what she saw:

I decided to see how much work it would be to reimplement my project management app in Ruby and Rails with the expectation that it would probably be just be too much work to port it and rewrite the thousands of lines of code. But after spending a few hours just poking around, learning what methods to use, I’ve already gotten about a third of the infrastructure implemented and working.

It’s very encouraging to see that Java experts like Kate, who co-authoredProfessional Java Tools For Extreme Programming, can recognize the competency trap and get out of it. Welcome to Ruby on Rails, Kate!

Setting up EliteJournal on TextDrive without a vhost

TextDrive is the official host for Ruby on Rails and as such gets all the action for cool integration efforts. We have a bunch in store that’ll turn the current state of “easy to get going” into “ridiculously easy to get flying”.

While that is cooking, Scott Baron has written up an excellent guide on how to install Elite Journal on TextDrive without using another vhost. He even created a testing blog just to prove it.

For those of you that don’t have a TextDrive account yet, I’d like to reiterate the point that this is one of the best ways to support the development of Rails (short of contributing patches or documentation).

They have some incredibly reasonable plans, an excellent environment for Ruby on Rails development, a staff that actually cares deeply about Ruby and Rails, and they’re contributing 50% of the profits on Rails signups to further development of the framework.

So if you’re still stuck elsewhere, now is the time to think about migrating.

And that concludes this shameless plug for TextDrive hidding behind the appearance of a documentation announcement.

"Simple design that even my grandma can understand"

Hamilton Verissimo captures the essence of what Ruby on Rails is about:

On the other hand I’ve coded the Castle on Rails, which is based on Action Pack. I have no merits here, the credits should go for the original author of Ruby on Rails, which implements an incredible simple design that even my grandma can understand how it works and how to create new controllers and views.

Good design doesn’t need to be hard to use. Best practices should be implemented, then hidden away. Programmers shouldn’t need to remind themselves how clever they are by applying the same complicated pattern over and over again. Extract, abstract, move on!

Escaping Java but not its thinking

Kevin Dangoor is getting out of J2EE development after four years of legacy mud and fear-driven technology choices. He has picked to start his new businesses on a dynamic language with Python. Unfortunately, he’s still stuck in Java-skewed thinking on the difficulties of learning a new dynamic language or framework:

Ruby looks nice and Rails is attracting a lot of attention for good reason. Seaside on Squeak should be attracting attention, because it looks like a very productive way to put together apps. There are two problems with both of these: 1) I don’t know them, and 2) they are less mature and have smaller communities than Python or Java.

I can certainly overcome (1), but that would slow me down initially. The clock is ticking, because I need to generate money to pay my mortgage and all that… The second point also means slower velocity: there are fewer places to turn for help. There are fewer prepackaged modules, and those modules may be less-tested.

I guess its natural to think that you must stay in the competency trap when exiting one of the deepest and most alive in the tech world today. But it needs not be this way. Very much unlike Java, it doesn’t take months and months to gather hard-won experiences with application servers or climb mountain-high framework stacks when starting out with Rails (or Seaside+Persistance for that matter). You can try it out in a day or two and have a pretty darn good idea of what’s going on. So the cost of escaping the competency trap is at an all time low.

So let’s address the charge “less mature and have smaller communities”. I’ve found that while a language community at large is a nice backup, the real importance for productivity is having a strong community around the frameworks that you pick. When people have problems with Ruby on Rails, it’s very rarely the general ruby-talk mailing list that hears their pleas. It’s the Rails-specific outlets.

Speaking of those, the Rails mailing list is buzzing with activity averaging 26 mails per day in December. The Rails IRC channel is ever so alive filled with between 100 and 120 developers every single day. This is a uniquely vibrant force that’s able to provide end-to-end help and advice. Unlike the scattered search for assistance that’s necessary when trying to combine template, web-flow, and persistance frameworks from separate communities.

This is not a charge against Python for not having a complete on Rails solution, but rather just a dissimal of the claim that the Ruby sub-community of interest should be less mature or vibrant than a comparable stack in Python. It’s simply not the case.

So. Blue Sky Development woes to persue “technology choices [that] can be made on technical (and business) merit without politics getting in the way”. I’d say you owe that statement at the very least a day or two outside your most immediate comfort zone. I’m pretty sure you’ll find that the competency trap is not inescapable and that the fears of a missing community are expelled instantly.