Leonardo Borges

I’ve just watched a video from Google IO where Martin Fowler and Rebecca Parsons went through some of the aspects that involves the development of an application for the cloud - focusing on the JVM.

In terms of the Google App Engine, you don’t have access to a relational database, thing I found out when I first tried it.  Instead you get a Big Table.

Martin put out a good analogy and you can just think of it as a nested hash map. It’s certainly a shift on how we think these days, but layers of abstraction like google’s DataStore and the Java Persistence API will help in the transition.

Another interesting bit about the presentation was on how concurrency works on GAE.

Essentially, in an standard Java application you have a single memory space where you have at least one running thread. You can create threads on the fly, which will share the same memory space, thus making it easy to share data.

On the app engine, things work differently. What you have are separate memory spaces with a single thread on each one. Any attempt to create a new thread will result in an exception. The solution for sharing information in this case? Use the nested hash map (big table).

Now, whereas you might not be worried about this since your application doesn’t span any threads, as well pointed by Martin Fowler, it’s the code you don’t see that you need to be careful with. Any Java application uses a number of 3rd party libraries that might span out threads of their own, which will result in your application blowing up.

That rang a bell. Again, back when I was trying the app engine, one of the configuration bits shared by Ola Bini looked like this:

   config.webxml.jruby.min.runtimes = 1
   config.webxml.jruby.max.runtimes = 1
   config.webxml.jruby.init.serial = true

I think the properties are pretty much self-explanatory but I didn’t quite understand the reason for setting it back then.

If you happen to have bigger values for the number of runtimes you want, you need to set the serial property to true, otherwise JRuby will span several threads to create the runtimes.

This is a really good example of things that might fail whether you’re migrating or developing a new app to deploy on the App Engine. Luckily for us, JRuby has a smart and neat way to handle this - the configuration I’ve just shown, but most of the libraries out there that might rely on threads are not prepared.

Martin and Rebecca’s opinion on this is that new releases of these same libraries will start to take it into account, since a bigger adoption of the Cloud seem to be on the way.

Make sure you watch the video. I certainly left a lot of interesting stuff out.

Wanna help improve JRuby? Make sure you read this post by Charles Nutter first. There he explains how to run Ruby specs with JRuby.

Start with fixing Ruby specs is a great way to get acquainted with the code. And it’s also a important task in order to make sure JRuby is the most complete and compatible ruby implementation out there.

But before you get your hands dirty, it will be a lot easier if you can actually debug JRuby’s source while fixing any specs - or bugs/features for that matter.

Taking as an example one of the specs I fixed, this is how you run it - form within your jruby source directory:

$ bin/jruby spec/mspec/bin/mspec spec/ruby/language/class_spec.rb

This is using jruby to execute the mspec binary against the class_spec.rb script. Now, if you want to debug this script instead of only running it, try this:

$ bin/jruby -J-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=4000 \
 -J-Xdebug \
 spec/mspec/bin/mspec -T-X+C spec/ruby/language/class_spec.rb

The extra arguments will start a debugging session on port 4000 and suspend the VM, which will be waiting for another debug process to attach. You can do that using any IDE of your choice but I’ll use Eclipse for this example.

Go to the Run menu and select the “Debug Configurations…” item. You’ll see a screen similar to the one shown below:

Eclipse Debug Configurations Wizard

As you can see, you need to create a new “Remote Java Application” configuration, setting the port to the same one you used to start the debugger session - 4000 in our case. Don’t forget to add JRuby’s source code in the Source tab on this same screen.

Once you’re done, set a breakpoint anywhere in JRuby’s sources and run the newly created configuration.

That’s it! Enjoy!

This is basically a compilation of a few tools/habits that I use to keep focused and at a high level of productivity when working alone. Works great for me and I hope there are useful tips for you as well.

Music

This is one of my favorites. When working alone I hate having noisy people around, which happens quite often if you work in an open office space like me. - It is great for pair programming but I find it inefficient otherwise. Thus, I came up with the term the Heavy Metal effect. Ok, just fit your favorite music genre there but the important thing is that it must act as a barrier to the outside world. It won’t work if you put something new and start babbling the lyrics!

Password Manager

In my day to day I have a number of web sites open like API documents, programming related groups, email… There are also the ones you open a few times a day like the company bug tracker, review board and etc. I find that having a password manager, in my case LastPass, saves a lot of time. The big advantage of it over similar tools like 1Password is that it works on mac, linux or windows. It’s just a firefox plugin.

Multiple Workspaces

Probably the most obvious item on this list to developers but I’s never too much to reinforce it. Multiple workspaces are great. And they are available in whatever platform you happen to be locked in. In my case, I split my environment in at least 3 workspaces:
-Development - where I keep things like my IDE, Browser and Terminal
-Documentation - where I keep API documents, tutorials and related stuff
-Communication - where I have my email, both personal and business, twitter and etc. This allows me to easily set a time per day to do each of my stuff without having noise from things that aren’t important to what I’m focusing in that very moment.

App Launcher

A must! On Mac I use QuickSilver and on Linux, Gnome Do. I won’t say much here. If you don’t use some sort of application launcher, do yourself a favor, stop reading and install one. You have no idea of how comfortable and time saver they are.

Batch tasks

Maybe this wasn’t the best title but I couldn’t think of anything better.
As a result of having a communication workspace that I use a few times a day, I find stuff that I’m interested in but don’t have the time to dig at the moment. So I need a way to queue that and read later when I’m home. The tools of the trade in this case are Twitter + Evernote.
Evernote is roughly a to-do manager. And since they released their Twitter integration it’s been dead easy to queue those things I talked about earlier. Just send a direct message to evernote and the item gets added instantly.

Now, what about you? What works for you?

Yesterday I organized our first CodingDojo here at the company and I’m glad to say it was a great success!
The problem chosen was the Karate Chop, from Dave Thomas’ Code Kata.

As it was also my first time organizing a Dojo, we took some time to get things straight, explain everyone the rules and start coding. Nothing that would compromise the experience, though.

The rules were basically the ones of a RandoriKata and as a mechanism for switching pairs we chose the TimeBox with a limit of 5 minutes.

We came up with 3 different solutions in about 1h 30min. The 1st one looking like crap!

Which was actually interesting because the general feeling before we started was that it would be boring, or too easy since “everyone” knows what a binary chop/search is.
Wrong!!! It all changes when you have a time limit and a bunch of people behind you doing funny noises! It’s a pressure different from your day to day job. A healthy one in my opinion.

Hearing the feedback afterwards was rewarding. Everyone seemed to have had a lot of fun and can’t wait for the next one.

I guess the most important lesson we got from it was to be quiet and not bother the current pair when we do not agree with their idea - not even if we do. This one is very important as it both shows respect and allows you to learn from how your colleagues think.

Next thursday we’ll keep going with this one and hopefully finish and pick up the next problem!