Raymond Law

We all know about the holy h() method that escapes your output when you do <=h blah %>. But how many of us can claim we remember to use it where it’s appropriate during development 100 of the time? Can you swear you’ve never missed one? Moreover, it’s such a mental distraction to think logic and h() at the same time. And when you take over a Rails project in the middle, how can you ensure the previous developers use h()?

Here’s the rescue.

safe_erb + footnotes

I don’t think I need to explain more. Just use it and you will find all those places where you should sanitize your output with h(), sanitize(), and untaint(), ...etc.

I am trying to raise money to buy pants for kids to keep them warm though the winter. I have found the Adidas ClimaLite and Clima365 pants to be the best Christmas gifts for this purpose. Please use the Chipin widget in the sidebar of this post to support this cause. Or you can simple click here.

We just finished the Lyricist application for RailsRumble 2008 with 3 other Intridea folks. Here are some observations:

• Keep the idea small and achievable – There are only 48 hours, so you can’t build the next Google. And there’s pressure. Try to keep your idea small and make sure you can accomplish it. You have to deploy a finished product in order to have any chance of winning. So stop day dreaming about cool extra features because you won’t get that implemented.

• Prior planning is the key – We barely had any because we had decided on the idea the day before the rumble began. When the competition started, people don’t know who’s doing what and it was kinda a mess. Fortunately we had a campfire room where all conversation happen, so we can kind of iron out the issues. However, better preparation and team cohesiveness would have helped a great deal in communication.

• Deploy early – I’ve seen too many deployment problems came up before, so I took the initiative to make sure we could deploy as soon as the competition began. It helped tremendously because we never had to worry about if we could deploy before time expired. While you are fixing last minute bugs and the pressure, it would have been tough to set up a server and deploy flawlessly.

• A lot of scaffolding – I took full advantage of Rails scaffolding. There’s just no time to reinvent the wheels when all the restful model and controller methods are already available with just one command. You use plugins and gems for the same reason, right? So, don’t be stupid.

• Conflicts – The bigger your team, the more conflicts there would be when people check in and out. We were writing a new application, so people were editing the same files. Now, if you organize and assign work to people as in a regular project, conflicts don’t usually happen and even if they do occur, it is trivial to resolve. However, when you are rumbling, you will step on one another’s toes. I can guarantee you that.

• Forget about writing tests – Look, I am in support of agile and test-driven development, with one exception. That is, you are not participating in RailsRumble. There’s just no time for it. If you are a good enough programmer, you can build a small application with no tests. If you can’t, I don’t want to work with you. Writing tests for a new application starting from scratch in just 48 hours is simple not feasible. No bargain!

• No ticketing system like Unfuddle and Lighthouse – One team member had tried to use Unfuddle to create tickets to get ourselves more organized. While it was a sincere attempt, it simply didn’t work. There’s no time to accept a ticket, create a new ticket, ... We pretty much abandoned it soon after we started.

• Nice to have a designer: – It is very nice if you have a designer on you team because it’s hard to wear two hats in 48 hours. Design work can draw your focus away from development.

Now that I’ve given you my insights for next year’s RailsRumble. As a token of appreciation, please vote for us!

UPDATE 2008/10/20

One more thought on RailsRumble the day after:

Numerous projects that I worked with before never deploy quickly, let alone in 48 hours. I think it’s refreshing and rewarding to have something built and deployed so quickly. It is true that we have to cut many features in order to deploy a first version, but lesser is better than never. I think many other projects can try to deploy early and often and just go through more iterations and get feedbacks from users and customers. The whole application doesn’t need to be finished. Even if you only have login and logout, you can still deploy. Add the next feature, deploy again. That way, you aren’t keeping the features to yourself. You can get feedback from users to see what improvements they are looking for and may even lead you to implement the real features that they truly want.