In his talk at the Agile2008, Bob Martin proposed an addition to the Agile Manifesto:

Craftsmanship over Crap.

Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:

Craftsmanship over Execution.

I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.

After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on his own attitude.

The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.

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. The only things needed are some engaged developers and good sense of the company to invest in their professionals.

2. Stimulates social and self-organization skills

Many developers have some hard time when talking in public, exposing their ideas or collaborate with other people. Others have problems to self-organize, work in a team or even lead. When does a company invest on those kind of skills of a developer? Rarely. The dojo is a great start for those people, and even who doesn’t have any of these difficulties will have a chance to exercise their skills and explore points which may need some improvement.

3. Is good publicity for the company

If the company took the first step and the developers are already comfortable running a dojo, why not open the doors for the public? The company name will become associated with the agile principles behind the the coding dojo and developers won’t have to leave the company to network. Better, if everything goes well the company won’t have to publish ads to get new developers since the potential candidates will be part of the company’s routine.

4. Helps developers to be active in the community

Discussing the techniques applied in the dojos can be a good incentive for some developers to participate more in the software development community. It can also be a first step help some open source projects, publish articles or participate in conferences.

5. Breaks the routine

Code something different from the daily projects, using other languages, tools and techniques, with other people and in a more relaxed environment may be very stimulating.

So, do you need more reasons?

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

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.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

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:

rails test_app
cd test_app

You’ll have to edit the first line of the created scripts (’script‘ directory) to use JRuby:

#!/usr/bin/env jruby

And at this point you’re ready to test your application:

script/server

Open http://localhost:3000 and check if your application is running as it should.

Now let’s create some functionality. First, edit your config/database.yml file, defining your development and production database as it follows. Note that we don’t need the test database and we can use the same database for both development and production for the scope of this example:

adapter: mysql
database: test_app
user: root
password: xxx
host: localhost

Create a scaffold:

script/generate scaffold Dog name:string
rake db:drop:all
rake db:create:all
rake db:migrate

At this point you’re already able to point your browser to http://localhost:3000/dogs and start playing with with your database.

3) Install the JDBC adapter and change your application

In order to deploy as a Java web application, you’ll have to replace the database adapter by a JDBC one. To achieve this, first you need a new gem:

gem install activerecord-jdbc-adapter --no-rdoc --no-ri

You also need to copy your mysql driver (JAR file) to your JRUBY_HOME/lib directory and edit your database.yml once more:

adapter: jdbc
driver: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost/test_app
username: root
password: xxx
host: localhost

Restart your server and, since we just changed its configuration, everything should be still working exactly as before.

4) Install Goldspike and create your WAR file

In your application directory, install the plugin:

script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspike

To include your database driver in the generated archive, you have a few options (Maven is one of them), but for now let’s just copy it to the ‘WEB-INF/lib’ directory of the application:

mkdir WEB-INF/lib
cp $JRUBY_HOME/lib/mysql-connector-java-5.0.5-bin.jar WEB-INF/lib

You also need to edit the app/controllers/application.rb file and include the line:

protect_from_forgery :secret => '6dc47d156f8f3724e4634c37bc0f9f94'

Finally, to create your WAR file, run:

rake war:standalone:create

Deploy the generated file in your favorite J2EE server like Tomcat or WebLogic.

Conclusion

The integration between Ruby on Rails and Java is easier than most people would expect, and it may become a new option to develop your next web application. That may be also a great motivation to learn JRuby and start taking advantage of its integration with existing Java code.

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.

Edison ‘failed’ more than ten thousand times before he
succeeded in creating the light bulb. As said by Thomas
Edison: “I have not failed 10,000 times. I have
successfully found 10,000 ways that will not work.”

In software development, failure is mostly seem as a negative term too. Obviously we don’t want to deliver software with bugs to the end users, but I believe that most of the bugs could be avoided if the developers change their view about failure.

When you start doing Test-Driven Development, one of the first lessons you learn is how failures are useful during the development process. Every test that fails is an allied to understand a little more about the problem you’re trying to solve. Why don’t they tell this in Software Engineering class? I really don’t know.

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.

Apparently today when it comes to Agile, there’s a huge gap between the software Industry and Academia. I thought it was just in Brazil, but it seems that there’s too much students out there finishing their degrees without even heard about it. Well, the Coding Dojo doesn’t fill this gap, but it seems to be right at the middle: it’s a simple way to learn about some agile concepts and it can benefit both Industry and Academia.

Today I’m not living in Florianopolis anymore but I’m helping my friends there to keep the sessions running. New people are asking me about the next meetings and in the last weeks I heard about at least more 2 possible Dojos (one more in France and other in Sweden). I think it’s just the beginning for the Coding Dojo Global.

My result was:

Your programmer personality type is:

DHTC

You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.

Now you can take the test too or simply check the other possible results.

After read the 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know, I tried to figure out my favorites shortcuts. I think I would go for:

1. Alt + Shift + X, T: Run Test Unit
2. Ctrl + F11: Run Last Launched
3. Ctrl + Shift + F : Code Format
4. Ctrl + 1: Quick Fix
5. Alt + Shift + R: Rename (refactoring)
6. Ctrl + Shift + T: Open Type
7. Ctrl + Shift + R: Open Resource
8. Ctrl + /: Block comment
9. Ctrl + Alt + Down: Duplicate lines
10. Ctrl + Shift + O: Organize Imports

You can see more shortcuts (or even print them) in the eclipse-tools site.