Leonardo Borges

For those who don’t know Git is a version control system developed by Linus Torvalds. It’s main difference from other tools like SVN and CVS is the fact that it’s distributed.

Recently I gave a workshop about Git here at the company where I walked through the most common cases I usually see when working in a team and thought about posting a summary of the commands used in the workshop.

It turns out that just this morning I found this - a.k.a the rest of my post. It’s a really nice and concise Git Cheat Sheet that covers most of what I talked about  in the workshop. So I highly recommend you bookmark it. It will certainly be useful.

As many of you know the new language supported at GAE now is Java, as officially announced on their blog. As a Ruby/Rails developer you might not be interested on it but here is a reason you should be: JRuby.

It was only a matter of time until we saw some people deploying JRuby on Rails apps on GAE, like Ola Bini’s mini blog app. Guess that was the first one really, as he was beta testing the service in secret. Google App Engine imposes a few catches to any java application deployed there and any JRuby app wouldn’t be different. For instance, your Java API access is limited to these classes - called JRE Class whitelist.

As you can see on his blog, you don’t need active record and in fact shouldn’t even be loading that on your app.

I felt compelled to try it and the timing was perfect. I am currently developing a JRuby on Rails app at the company I work for and it was a perfect fit, since we are not using ActiveRecord. The reason is that we get the data we need from other sources, such as web services and even text files.

Ola Bini’s tips were crucial here. He provides a small script you can use to prepare the jars you’re sending to your app. Another important piece was the Google App Engine SDK for Java. It ships with a server that emulates GAE’s behaviour locally so you’re less likely to have problems once you deploy it.

I did have a problem though with the number of files uploaded to my appspot. It’s currently limited to 1000 - a thousand - and a Rails app can easily exceed this limit. So before deploying, remove anything that is not crucial: activerecord - you should’ve done it already - , all tests directories - including the ones inside gems your app needs in order to work, fixtures and etc.

After that it was rewarding seeing a custom JRuby On Rails application working perfectly on GAE. And as much as I’d like to, I can’t really share the URL since it’s a private app but I encourage people to try it. I believe GAE will ultimately help the community improve JRuby even more.

And as a last tip, this time thanks to Fabio Akita, is this snippet. You should redirect your log so you can debug your app form GAE’s dashboard.

Have fun!

It’s been more than a year since I started my new endeavor here in Spain, moving from Brazil and starting a whole new life - both personal and professional. Time for a little retrospective.

More precisely, a retrospective about the agile practices here at the company.

When I first started out back in January ‘08 the company thought they were agile. NOT! They did adopt some XP practices but just to give you an idea, I’m gonna focus on just one: stand-up meetings.

My first stand-up meeting was a shock! We were a team of 6 developers and 2 sys admins and the meeting lasted for 40 -yes, forty - minutes!

The reason? Several, but the most obvious one was that in their stand up meeting they were actually, well, sit. That was my first suggestion which some people were actually reluctant about. But we survived.

Since then we improved a lot our stand-up meetings being able to usually cut it down to 10 minutes. But we can get better.

Another problem we usually have is the “i-want-my-finger-in-everything” syndrome. I guess you’re all familiar with that. It’s the developer who wants to know everything in its minimum detail and interrupts everyone in the stand-up meeting to ask questions or make clarifications that could, both, be done afterwards. And that’s a problem we still have every now and then.

But we are much better now and to get here we basically successfully tried:

- Standing up ( duh?! - believe me, this was harder than you might think)

- Trying to bind people’s thoughts on what they’ve done the day before and what they are going to do that day. Anything else should be left for after the meeting - it’s probably not everyone else’s concern. Focus.

- Limiting the amount of time allowed for each developer - currently we have a generous 2 minute limit.

- Using a token -any object light enough to be hold while you’re talking. People are only allowed to talk when they get hold of it. This was a nice idea brought by my colleague Philip MacIver.

But we still have issues. People still jump in somebody else’s turn and get the token basically as if just by getting it they can talk. And because of that we still suffer from the “i-want-my-finger-in-everything” syndrome.

So after telling this little story about how stand-up meetings evolved here, I’d like to hear from you guys what do you do to keep your meetings short and to the point. I’m really willing to hear suggestions and success stories.