tfnico's blog

Next month I'll be presenting my  Agile in a Year  talk at FrOSCon , a local university-driven conference about open source and related topics. At the moment I'm mashing together the slides (well, strictly speaking I'm not going to use slides) that have to be done by Sunday, so I'll keep this short. I'll be talking about the agile practices we have introduced at IP Labs, more or less during 2009 . Just to be clear: I'm not saying that we "became agile" in this period, but we did become more agile* . If you are in the vicinity of Bonn/Cologne around the weekend of 21-22th of August, I hope you'll drop by. Visiting the conference will set you back a whopping 5 €. * Tip o' the hat to Johannes  for this idea.

This post is part of a series on Git and Subversion . To see all the related posts, screencasts and other resources, please click here .  About a month ago, I made my first attempt at introducing my team to  Distributed VCS with Git . We agreed that the cost of switching away from Subversion was not a hit we would want to take right now, but we continued experimenting with Git (and Mercurial) migration on the sideline. Waiting a bit longer can't hurt, as  Git continuously gets more support in both  Windows  and  Eclipse . In the mean time, I wanted to learn git properly, and also get a good grasp of git-svn . We will have to live with Subversion until I can convince everyone of two things git can do the atleast all things svn can do better than svn transition will not be too expensive (technical issues, training, people-friction) So, I started using git as my tool for working with our Subversion repository. I quickly got into the " porcelain " of gi...

Update: I've moved the list of Google Guava resources to  http://www.tfnico.com/presentations/google-guava . This page won't be updated any more, but I'll leave it the way it was. I recently blogged about the Guava Libraries taking over for Google Collections . I figured I'd add a few more pointers to documentation, as the Guava wiki seem to be a bit empty (feel free to copy in these links). Update: More resources (I think if there are any more updates, I'll move this into an editable page on tfnico.com). A four part quite extensive tutorial from Sezin Karli: http://scaramoche.blogspot.com/search/label/guava Google Guava, the easy parts. A basic tutorial that recently surfaced on DZone: http://www.copperykeenclaws.com/googles-guava-java-the-easy-parts/ Old entries: A collection of short snippets (great mini reference for Google Collections): http://blog.publicobject.com/2007/09/series-recap-coding-in-small-with.html Codemunchies' 4 part series o...

Update: There's a full list of Google Guava resources on  http://www.tfnico.com/presentations/google-guava . I recently spent some time gathering documentation for our internal use of Google Collections . No more than a few days after quickly presenting Collections at work last week, Kevin Bourrillion announced Guava Release 05 , urging all users of google-collect to replace it with Guava  ASAP, and spread the news (so here we go). If you don't know Guava or Google Collections, they're basically a nice set of Java util classes that you always wanted. I figured I'd have a look through the library's docs, and as I went along, I coded a few easy examples (mostly from the base package). The code is available as a Maven project on github , and I also made a presentation (PDF) with roughly the same examples, seen here: Google guava presentation on slideshare Feel free to extend the examples by forking them on GitHub!

We recently did an internal knowledge meeting about Distributed Revision Control at work. Rather than post my rugged presentation on SlideShare, I figured I'd rather pull together my notes into a blog-post. In our presentation, we were supposed to go head-on-head with Git vs Mercurial (as these were our DSCM finalists). Most of my notes are pro-Git, although I'm equally fine with adopting Mercurial. So, what's the deal with distributed? Basically, instead of having a single repository on a central server, everyone has their own repository. These repository are the same, because internally they have the same identifier-keys (SHAs) and history. Since all bits and pieces are globally understood in relation to eachother, you can bring together changes from two separate repositories pretty easily. Why would anyone want to distribute their repos? You want to let people work without ruining the main line. Consider feature branches. Remember that feature branch we ...

I want to tell you about how we introduced one of our more recent practices: Workshops . During one of our retrospectives this spring, it became apparent that some of our colleagues felt that there was room for more learning  in our shop. People were sticking a bit too much to their usual tasks and their usual technologies. We're not a consultancy, so it's not really the core of our mission to use the latest and most hyped tools all the time. We still need to stay updated so we make the right architectural choices when considering doing something the old way, or trying out something new. But we're too busy to learn new stuff! For a software developer, the responsibility for your actions is split between what you choose  to do, and what you're assigned  to do. Of course, you can't run wild and smash all the latest open source tools and languages into the main product line, but at the same time, if you  don't take initiative to do a little research on what...

Some years ago, I got into the habit of using fire alarms as a metaphor for continuous integration and automated tests. My take was that organizations were always holding back resources to get servers for continuous integration, especially where project funding was provided by the business side. Simple reason: the management didn't really grasp concepts like automated tests and CI. I know that the metaphor doesn't completely fit in many ways, but it's a nice way to communicate the urgency and importance of having this security around. So I started using terms like "security net" and fire-safety to illustrate our need for a build-server. It also is a handy metaphor when convincing developers to write tests for their code. Many developers fail to see the immediate benefits of practicing TDD, for example, but everyone has the fear of fire, or letting a bug slip by and into production. I like comparing the team to the fire squad in a small city. The more fire alarms w...

The 97 Things Every Programmer Should Know book was recently released. Kevlin Henney has gathered together advice from a wide bunch of programmers, many of which are from the Norwegian developer scene, and a good few of which I consider old friends. They are even arranging a release party in Oslo next Monday at XP-meetup . So far, over 250 people have RSVP'ed to attend the event. Unfortunately, I didn't get my act together to write a submission for the book before after the deadline, but I submitted it anyhow , in case of any 2nd edition of the book. Anyhow, out of sheer jealously of all the attention the accepted submissions are receiving now, I figured I'd post mine here: Fight For Your Infrastructure It is in your role as a programmer to demand proper infrastructure from your organization, simply because nobody else will. If the organization does not provide it for you, you must explain them what you require, and dedicate as much of your own time as necessary until an a...

One of the reason I like blogging is that writing forces me to gather insights on what I do. It's kind of like a personal retrospective . In my current situation, I'm now at a bit of a stand-still, where we (our team at work) have achieved what we set out to do last year, and now we are a bit unsure on what to do next. So, before we move on to have a look at our future goals, let's do a little year-in-review, 2009: I started working at IP Labs in the beginning of the year . Part of my role in the team was to do some agile coaching. Why did they need this? I think they were feeling some frustrations which are typical for growing teams. They come from a situation where they were small enough to master chaos, but over time, as the code-base and team grows, they need some protocols, rituals and routines to help them keep on top of the mud . In short, agile practices . There were times where I got really frustrated because things were moving to slow, and the team did not adopt s...

I noticed via @jvanzyl that Kent R. Spillner has been taking apart Maven and some of its features in a recent rant . The twittersphere has shown support for Kent's views - and being the Maven fan I am , I figured I'd take some time to try countering his post a bit (forgive me if this post is a bit unstructured, I'm trying to squeeze it out under some time pressure). "The best build tool is the one you write yourself..." I think this first paragraph contains a lot of absolute statements that happen to be false in a lot of cases. My experience is that a lot of projects or modules are built the same way. It's a bunch of source code, and in the end you end up with a JAR-file. We've got a 25 module web application at work, and I just mavenized the whole thing from Ant. All of the modules exlucding the final web-app module itself were easily built with Maven. Nobody says that every module in the world is built this way, but it sure is a lot. Java code goes in,...

I started off this post with the title "Our Quest for Agility" but it kind of trailed off into being about our latest customer-dashboard tool. I'll do another post about our agile quest later. The Greenback project Before the summer, I was issued with the task of setting up a customer-management portfolio tool, which I named Greenback (as in, money , because that's what we want from our customers). The first goal was to provide our customer-managers with an overview of which customers exists, where they are installed, which applications they are running and other configuration details. Greenback is basically a web application with a big table with our customers and some filters to see the customers for a single manager, or with a particular configuration. Our customer-managers can also edit, add and comment all the entries, naturally. We have a rather large portfolio of customers (200+), and each of these are hosted with their own application of our software. Through ...

The last couple of weeks I've been spending a little effort on getting some code metrics up and running. I've blogged about measuring in software development before , and I think code is definitely one of the easiest and most important things to measure. The most important thing about metrics is that you monitor them . I am of the firm belief that if you run a static code-analysis report manually, it will give you very little. Your team will say "wow, we have 3000 FindBugs warnings", fix a couple of them, and then forget about it. Then the next time you run the report, you'll find new bugs that have crept in, with no idea of when or who did it. There are two ways to track these kind of metrics: IDE warnings Continuous integration reports IDE warnings Most of you have probably enabled the built-in warning system inside Eclipse (unused method, potential null-pointer, etc). Some of you strive to minimize these numbers of warnings, some of you have perhaps even turned...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Reason 2: Clean up your JAR-files Huge projects are hard to work with Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project. Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-fi...

Update: Added a summary section at the end of this post. This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Some background Back a couple of months, I got the rewarding task of cleaning up our project's lib folder. You know the one: Crammed with JAR-files of various versions of the various dependencies your project has.. fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar lots and lots of others... ... Yup, good old fizz-libs . It needs to be regularly cleaned up to reduce software rot . Over time, the developers try out new open source libraries and remove the use of old ones, but they seldom take care to clean out the libs-folder, because they don't know if there could be any hidden effects from removing JAR files. Now, at our place we use Eclipse's . classpath file for specifying ea...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven The libs folder We have a libs-module in Subversion. When you check out the source code for our main product, this is one of the modules you get. It contains a hundred-and-some JAR-files. These are the dependencies for the sum of our modules: fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar Downloading all these MB's of JAR files is something you'll have to do no matter which build system you use, so bandwith cost isn't an argument. Subversion also uses binary diffs, so copying or changing a JAR file doesn't increase repository size significantly. The problem arises when you want more than one product. As soon as you want to split your product into two applications (or services), each project needs its own libs-folder : fizz-project \ fizz-core fizz-web fizz-libs \ ...