Ivan Sanchez

This week I had the chance to help the guys from the London Ruby User Group running a coding dojo for ~50 people. It was the largest dojo I’ve been involved so far and it was really interesting.

To allow everyone to participate, the attendees were divided in three groups: Ninjas, Pirates and Zombies. Each group would solve the minesweeper challenge using the randori approach and at the end each group had a chance to show their solutions.

Another interesting approach for this dojo was providing a common set of cucumber stories to guide the development. Matt Wynne wrote them and also provided a rake task to help keeping the TDD flow by encouraging people to solve the tests one-by-one (source code is available here). As a result, all the groups managed to solve the challenge in less than one hour, giving them enough time to experiment alternative solutions and refactorings.

Although there was no general retrospective at the end of the session, reading the feedback on the LRUG mailing list it seems like people enjoyed the experience. Personally, I really liked the fact that everyone participated, probably because they’re used to the language and tools and knew each other from previous LRUG meetings. Well, maybe is time to start organising public dojos again.

Work Coding Dojo, Programming, Ruby

The next coding dojo will happen on the 4th June (Thursday) at the Skillsmatter office. The registrations are already open.

For this session we’ll work on the Minesweeper challenge in Ruby once more, but this time with the Randori rules slightly changed:

• A pair will work on the solution for 10 minutes
• The pair must use Test-Driven Development and Baby Steps all the time
• The pair must follow the Ping Pong approach:
  • One person writes a failing test
  • The other person makes the test pass writing a minimum amount of code
  • The same person writes the next failing test
• After 10 minutes one of the developers switches place with someone from the audience

Who attended the dojo before knows the minesweeper problem was solved a few times before, but trust me, it doesn’t matter. The idea of this session is focus more on the pair communication rather than the technical challenge. And if you never tried Ping Pong programming, it will be a good chance to experience one of the most enjoyable forms of pair programming.

See you there!

Work Coding Dojo, Ruby

This Wednesday (April 22nd) we’ll have another coding dojo at Skillsmatter. This time the challenge will be the Poker Hands:

[...] Your job is to compare several pairs of poker hands and to indicate which, if either, has a higher rank.

Here’s some initial code generated at a previous dojo that may serve as starting point for the solution. The session format will be a Randori, which means everyone is welcome to code.

As usual, registration is required and should be done at Skillsmatter’s website. If you have any questions or suggestions for this session please feel free to participate in the Coding Dojo London mailing list.

Work Coding Dojo, Ruby

Is it just me who’s loving this whole Ruby vs. Scala debate going on lately? So far it shows that:

• No language can prevent bad code.
• There will be never an ultimate language, but there will always be people to defend the one they are using.
• Java (the language, not the platform) is dead.

I know it’s not the first time we have a language war and I have to confess I was missing that a little. Years ago it was Visual Basic vs. Delphi, then C++ vs Java, now it’s Ruby vs. Scala. And I have to confess: I’m already curious to see what will be the next one.

Work Java, Programming, Ruby

In our last coding dojo, instead of a randori we had a kata prepared by Danilo Sato. He solved the Minesweeper problem in ruby in about one hour using proper TDD and stopping for questions/suggestions from the audience. Here are some of the tricks people could learn from that session:

• When working with ruby on a Mac, the RSpec bundle for TextMate is great. It has really helpful shortcuts and can easily run your specs and see your reports inside the editor.
• Rspec can be used as a TO-DO list during the development of a class. This can be done by creating pending tests as reminders of test cases to be covered. These are tests appear “yellow” state, waiting for a proper implementation.
• Autospec is also a great tool for TDD. Seeing a test becoming green is fun, but doing so without running it manually is way better. Specially using Growl.
• When doing a presentation using the command line, it’s easy to be tricked by font colors. They may look great on screen, but a projector may not like them.
• During TDD, it’s really important to know how to fake it. But knowing when to refactor the fake code is even more.
• Being able to create methods like “[]” in ruby can be really helpful.
• TextMate allows you to run any text file or even just a few lines of it as a ruby script . This can a good alternative to play with the language instead of using irb.
• A piece of code can sometimes be used as a good visualization tool for a problem. Here’s an example:

    it "should find neighbours around cell" do
      @field.neighbours_at(1, 1).should have(8).neighbours
      @field.neighbours_at(1, 1).should include([0, 0], [0, 1], [0, 2],
                                                [1, 0],         [1, 2],
                                                [2, 0], [2, 1], [2, 2])
    end

• It’s easy to create bugs by using “…” instead of “..” in ruby ranges.
• Multiple assignments FTW.
• jUnit should have something like nested describes in RSpec. It’s a great way to group related tests for a single class.
• Nice RSpec reports can be generated even outside TextMate by using “rspec –format html”
• In BDD sometimes makes more sense having multiple assertions inside the same test. The condition in this case is that they should all help to verify a single behavior of the class being tested.
• Being able to refactor a field into a method without having to care about the references to that field is really cool.
• Assertions for boolean values in rspec are very elegant.
• The pending feature in rspec can really good for big refactorings. It helps to be sure a test or more should be failing during the process.
• Creating your own matchers can make a rspec test more readable. And people should use this feature from jUnit more too.
• It’s easy to get confused by the use of &block and yeld in ruby. In any case, it’s better to learn both and stick to only one of them whenever possible.
• Some ruby conventions are really smart. Append “?” to describe a boolean method, or “!” to do the same for a method which changes the internal state of the class.

If you want to check the source code it’s available on github. To know more about the dojo and or attend our next session check our mailing list for the discussions going on.

Work Coding Dojo, Kata, Programming, Ruby, TDD

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

Work Programming, RoR, Ruby

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.

Work Java, Programming, RoR, Ruby