5 reasons to have a coding dojo at your company

1. Is the easiest and cheapest way to invest in training To run a coding dojo people don’t need much more than a computer and a projector. Paying for the pizza and some beers for the end of the meetings is not expensive either, and is surely welcome. But if the company is really cool, some dojos can take place during work time to get more developers involved. Note that none of those items take lots of money nor is too complicated....

July 15, 2008

Ruby on Rails 2.1 - What’s new

Carlos Brando released the first book on RoR 2.1. More information and download here.

June 10, 2008

How to measure velocity in software projects

Three simple steps to measure velocity in a software project: Estimate your requirements using a size metric. Agree on the concept of done. Define a timebox size. Then we just need the formula: Velocity = Points done / Timebox

March 18, 2008

Integration versus Integration

Just to clarify: Integration test: modules of the system are tested together, as a group. Integration build: modifications made by developers are consolidated through a full build. Although the integration build may include running integration tests, they’re are clearly two separate problems.

March 18, 2008

Building self managed teams

Sometimes in a project: People are treated as mere “resources”, being part of the project only to work on predefined activities and nothing else. The managers want to be sure that everyone is doing exactly what they think it’s the best, and forget that people can have good ideas. People prefer to work on tasks defined by someone else because they don’t want to be responsible for their work. Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task....

January 10, 2008

Looking for testing mantras?

Then it’s time to try the Way of Testivus: If you write code, write tests. Don’t get stuck on unit testing dogma. Embrace unit testing karma. Think of code and test as one. The test is more important than the unit. The best time to test is when the code is fresh. Tests not run waste away. An imperfect test today is better than a perfect test someday. An ugly test is better than no test....

January 7, 2008

Deploying Ruby on Rails as J2EE application

If you haven’t tried Ruby on Rails because was too busy developing your J2EE applications, now you have no more excuses! It’s possible (and surprisingly simple) to deploy a RoR application in your favorite J2EE server just by following these few steps: 1. Install JRuby on Rails Get JRuby and install the Ruby on Rails gem: gem install rails --include-dependencies --no-rdoc --no-ri 2. Create a simple test application Run the following commands to set up your new application:...

January 2, 2008

Dealing with Software Failures

Reading about several things they don’t teach you in school, one that sounded me very important is how to deal with failure: In school, kid’s learn that “failure” is a negative term. However, it is nothing of the sort. There has never been a single successful person who hasn’t failed numerous times on their journey to success. In fact, the most successful people in life are those who have failed the most....

June 21, 2007

Coding Dojo

For the last year I’ve been involved with the organization of Coding Dojo meetings in Florianopolis/Brazil. This kind of “coding meetings” started in France and spread to Finland, United States ( Pittsburgh and Houston), United Kingdom, Canada, Brazil and Sweden. The sessions are basically about solving a programming challenges using Pair Programming and Test-Driven Development. Everyone is welcome since there’s no skill prerequisites for attendees. The main goal is simple: improve coding skills through practice....

June 12, 2007

Distributed Agile

The first agile principle is about “individuals and interactions over processes and tools”. How can it be managed when people are not all in the same place? Dave Churchville wrote about it and classified distributed team as: Type A: All developers are together, all customers are remote Type B: Multiple development teams in different locations (but each team is together) Type C: “Virtual” team where nearly everyone works remotely (e....

May 24, 2007