Wrapping-up Jazoon09

I was attending Jazoon09 in Zurich, Switzerland last week. As with springOne 2009, I wasn't really satisfied with this content of the conference.

The problem was, that there were only a few really good speakers and thus only a couple of great talks. The keynotes were average, only Adrian Colyer's presentation on the last day was standing out. Even James Gosling's presentation or Danny Cowards talk were both not that exciting.

However, instead of telling you what sucked, I rather want to highlight, that the organization of the conference was great! The food was really good! There was an vegetarian alternative every day and the coffee was delicious. Jazoon took place in a movie theater, just like Devoxx, thus it was easy to get there by train and the seats were nice and comfy. Kudos to the organizers.

There were a couple of great talks I want to highlight: Neal Ford's "Smithying in the 21st Century" as well as Ed Burns' "Secrets of the Rockstar Programmers" were really awesome and I can only commend listening to them, in case they come up on the schedule of another conference.

I'm not too sure if I'll come back to Jazoon next year, although I think it could be a really cool conference and a great alternative to Devoxx, which takes place in Antwerp.

Jazoon 2009

I'll be at Jazoon 2009, which is starting next week on Monday with a Glassfish Day. It's going to be my first time in Zurich this year and I'm really excited, because they have a great line up of speakers.

Among others, there's gonna be the father of Java himself Mr. James Gosling. For me it's always something special to listen to a keynote of him.

There's gonna be sessions on a wide range of topics, e.g. "Concurrency and Performance Reloaded" with Kirk Pepperdine, "Development for the iPhone" or "Design Patterns in Dynamic Languages" with Neal Ford, to name only a few of the first conference day.

Git talk @ JUG-Ka

This coming Wednesday Samuel Mellert (1&1 Internet AG) is going talk about "Distributed SCM with Git" at the Java User Group Karlsruhe. I'm a newbie when it comes to distributed version control and especially Git, that's why I'm really looking forward to this meet-up. The talk starts at 7:15pm and takes place at University of Karlsruhe.

JetBrains and ZeroTurnaround are each giving away a free license for their products. We are gonna have a lottery, so if you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.

To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.

Git(Hub) Pain

This is a little bit of a rant post, so if you are not interested in my subjective experience with GitHub, you should stop reading now.

A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:

You are working on a local clone of the full repository and a commit is basically a set of changes applied to a version of that repository.

I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?

One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.

The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.

Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:

crusty:doublemill dlinsin$ git pull origin master 
error: Could not read 9b82bba67693db3b47189aefea07ec4e1d7be38e 
fatal: bad tree object 9b82bba67693db3b47189aefea07ec4e1d7be38e 
remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done. 
error: waitpid (async) failed 
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. 
remote: Total 8 (delta 0), reused 0 (delta 0) 
remote: aborting due to possible repository corruption on the remote side. 
Unpacking objects: 100% (8/8), done. 
error: waitpid (async) failed fatal: error in sideband demultiplexer

Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:

The best thing to do would be to delete the repository and recreate it with a fresh git push.

I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.

However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.