tfnico's blog

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  In preparations for presenting "Living with Git and Subversion in parallel" at GearConf  in a few weeks, I've been practicing a Git+SVN exercise, going through all the steps from Git-cloning a Subversion repo, to full centralized Git-SVN mirror. While I was doing this, I figured I might as well make some more use of this, and record some screencasts as I go along. I've just posted the first three on YouTube , and collected all my various works on Git and Subversion on this page . Feedback is much appreciated! Update: I'll try embedding the videos here on the blog too: Git+SVN #1: Cloning a repo Git+SVN #2: Some commits back and forth Git+SVN #3: Conflicts

I recently did a lightning talk at the local Java User Group in Cologne. Topic was  Agile in a Year in 5 minutes , a shortened version of the talk I did earlier at FrOSCOn. I'm gonna be doing the full talk at the Cologne JUG on the 8th of November, so be there! Well, if you're in the area, anyhow.

Some time ago,  Ole Morten tried a concept called MyWeeklyLinks , but he stopped after the eighth one. I speculate this was because he defined an audience that had no need for this kind of information, namely us: his readership. We rely on Twitter, blogs and other community-driven sites (Digg, Google Reader, DZone) for the fitting stream of links we consume. That's not to say that that weekly links is a useless practice. Remember that you, dear readers,  are "information power users": We like to stay on top of what's going on out there, we stay updated. We devote a certain amount of time for this activity. Perhaps we have no need to consume "weekly links", but we can produce it for our colleagues. I wrote my first mail like this to the team mailing list little over a year ago, simply three links: Hi folks, I just wanted so share some interesting resources I found the last few days:   This is a short overview of some Java programming styles that can g...

In the newest Javamagazin , there's an article by Bastian Helfert and Steffen Hohn about CodeCity , a really interesting tool for visualizing code. I just ran it over our 300k LOC Java project, and got this model ( click to see larger version ): Buildings are classes.  Height is based on class LOC Building ground-area is based on number of attributes City blocks are packages. If you actually run the program, you can interact with the model, fly around, click to see which package is which block, etc. This is all fun and cool-looking, but does it have any practical usage, I wonder? I think we want to work in small friendly villages, where most houses are evenly-sized, nicely sized neighborhoods, no big ugly gray parking lots, and no towering sky-scrapers. Here I ran it again on a smaller, nicer project: Certainly a lot easier to find your way around this neighborhood. I know Michael Feathers has made quite a few thoughts around code aesthetics . Perhaps ...

After tirelessly blogging about how to work with Git and Subversion in parallel for some time now, I fired off an abstract to GearConf , as this looked like a subject that would be right up their alley (they had talks about Git and Mercurial last year). They accepted the talk a couple of days ago, so it looks like I'll be driving up to Düsseldorf on the 11-12. October. Interestingly enough, GearConf is sharing the event with the Atlassian Software Conference Düsseldorf ,.  I've been up close and personal with their products before , so it'll be cool to see how far they've gotten since back in the day (when their products were already awesome). For anyone in the area, the people behind GearConf are also arranging  WebAppDays  in Düsseldorf from 27-28. September. I would go there too, but I think I'm all out of conf-days for this year :)

I've gotten some questions about Knowledge Meetings after I presented them as one of our agile practices at FrOSCon some weeks ago. Here are some more ideas/thoughts on how to do them: What are they? One hour every week. Gather the whole team together, and learn something. What should we learn about? Anything that will be of interest to your team, work-related. Some examples: This new open source library/project/technology we (can) use New programming language This cool testing technique A certain module of the business application The hardware architecture of our data-centers Some applied computer science (algorithms and stuff) What is the concrete contents of a Knowledge Meeting? Anything that'll make you learn. Examples: 10 minute lightning talks/ignites Coding Katas , or Randoris Longer presentations (try to not go over 30 minutes) Lots of discussions! Lots of live coding! Remember : Let people present the things they already know, but.. Give people time to pr...

You can now find the recording of the talk  on the page for the Agile-in-a-Year presentation . Note that it's missing the first few minutes with intro, but that wasn't so interesting anyhow, I'm sure regular readers know most of the background . There's about 40 minutes of me talking, and 20 minutes of questions and discussion in the end. Sorry for not being so good at repeating your questions into the mike!

I recently did a talk about practices we have introduced to make us more agile. At the end of the presentation, I mentioned distributed revision control as one of the next practices we want to do. Now how on earth does using Git or Mercurial increase our agility? The short answer is:  Feature Branches . The long answer is... We have a defined agile as among other things, this value: Ship working software. This value implies that we keep the mainline of the code (known to many as the stable branch) in a working state. A good way to keep it that way is by making sure that only safe changes make it into the mainline. If you've got developers continuously working on the mainline to create new features piece by piece, chances are the code is in a broken state every now and then. In order to remedy this, lots of companies (including ours) have decided that the team should maintain two versions: one experimental, where new features are developed, and  one stable, wh...

Just a few hour ago, I did a talk called Agile in a Year at FrOSCOn 2010 . Great conference, as it was last year. Hopefully going back tomorrow for day 2! I've put the "slides" and references from the talk on my homepage . Hopefully, a recorded video of the talk will be online soon. Unfortunately, I botched it a bit by forgetting to put on the microphone at first, but got it on about 5 minutes into the talk. Will post back here when the video is ready. And if you were in the audience: Thank you so much! Full house, great discussion and questions afterwards.

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This post is part of a (slightly chaotic) series on Git + Subversion. Unfortunately, due to my problem with editing posts in Blogger, they've ended up a bit scattered and poorly organized. So here's a summary of the posts with more fitting titles: A big rough introduction to distributed source control and Git Why and how clone of a Subversion repo into a Git repo  (aka SVN mirror) Sharing a Git SVN mirror in a team Sharing a Git SVN mirror in a team clarifications So, if you just want to get into using Git, take a look at 1. If you want to port an existing Subversion repo, 2nd post is the thing. The 3rd and 4th are for those of you who need to stick with Subversion for a while longer. The illustration below illustrates an example workflow for the last case. Ref GitFaq . Note that devs *might* have to run update-refs ...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  I'm afraid I exaggerated in my previous   posts , and given the impression that living with Git and Subversion in parallel is easy. I would update it, but Blogger is refusing to edit the post without screwing it up. So here it is in clear text: Be prepared to face some major constraints in using Git against a Subversion repo, compared to how it using Git standalone. The manual says it best: The git svn tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines: Keep a linear Git history that doesn’t contain merge commits made by git merge. Rebas...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This is a follow-up to the previous post on how to live with Git and Suversion in parallel . It's really trivial stuff for any experienced user, but was worth noting down somewhere for my own sake. I've cloned a project called "fudge" from Subversion: >git svn clone https://scm.mycompany.com/svn/fudge So my local repo has the correct svn-remote configuration and all that to go with it inside fudge/.git/svn . This is done automatically when you svn-clone. The bad thing is that all my Git-mates at work have to wait for me doing svn-rebase before they can pull the latest code from Subversion from my repo into theirs. I want to get rid of this responsibility. I'll put something similar to my svn-rebasing repository on a server, have it run svn-rebase regularly, and push the changes to a centralized git repository, ...

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...