Tuesday, October 26, 2010

Geek and Poke versus Subversion

I noticed that Geek and Poke has done a fair share of SVN-bashing over the last months. These are awesome, hilarious, and ring so true to my experience with SVN.  I've collected them here and written a few thoughts on how it's different with a distributed alternative like Git.

1. Being a Coder Made Easy
Typical syndrome of first-man-to-the-mill syndrome. The typical use-case is to commit a big fat refactoring early in the morning, before anyone has a chance to get in your way.

With Git, these situations do not occur so often. Big commits are made in branches where they do not disturb the workflow of others. Branches do have to get merged back at some point, and conflicts dealt with, but this happens in a planned and orderly fashion. There is no race to merge branch first.

2. Simply Explained - SVN Guinea Pig
Oh, so typical. Do not update the code when it's broken centrally. This problem is magnified in the lack of a continuous integration system or a fast build.

With Git, your active work is on a branch where you can pull in needed changes as you need them. You can also set up staging branches that run tests or code-review on incoming code, before they are merged into the main line, like they do with Gerrit.

3. Good Coders
Nuff said. Same point as in the previous one.

4. Real Coders Help Eachother
Ditto. Well, it's worth rubbing in :)


5. One Day In The Life Of A Coder - Part 2
After you do a Subversion update, you're stuck with the latest revision, which is bad in the case of a broken build you're not going to fix. You could of course update to an earlier revision, but this typically takes so long, that you're better off getting a coffee and having a chat before you try doing another update to see if the build has been fixed.

With Git, you can immediately reset to the code you had before merging in the latest changes. This takes a matter of seconds, even in a huge repository.


6. One Day In The Life Of A Coder - Part 3
Again, so typical. You want to commit, or you have to commit, but you can't find a good description for it on the fly. You either write a worthless commit message, or fiddle around for ten minutes finding out what you are actually committing.

With Git, you don't let these moments break your flow. You commit, use "Yada yada" as the commit message, then return later with rebase --interactive to squash, and rewrite your commits.

Bottom line
Dear SVN-users. It should be a wake-up call that there are actually comics making fun of one of the most fundamental and important tool in your infrastructure. Start making some changes.

Tuesday, October 19, 2010

Pumping blog traffic with DZone, etc.

This is microscopic blog, readership-wise. Since I started tracking traffic in June 2006, there's been 15,514 visits. Each blog entry usually gets around 100-300 views, with a few odd cases booming into the thousands, like my Spring TestContext post with 2,378 views and counting. The thing that made that post so popular was that it got 'DZoned', and is still the 3rd result on Google on the subject to this very day.

By any standard of the Internet, my blog is tiny, but I don't mind, cause for me it's just my voice in this "tribe" of these 300 like-minded people, typically Java-enthusiasts with a sense of agile in them. Many of them are old friends and colleagues, and some are new people that I sometimes meet at user-groups and conferences. The blog is part of my dialog with them, just like with my twitter account (number of followers is also right under 300).

Recently, I devoted quite a few evenings putting together my first ever screencasts, on the topic of Git/Subversion. After blogging it, tweeting it, and talking about it at a conference, there were still only about 150 views on YouTube, all seven videos together. This was a bit.. disappointing, because I thought this would really be useful to the world of software developers, not just in my "tribe". I mean, there are a lot of Git lovers out there stuck with Subversion (about every fifth Git-user uses git-svn)!

So I went ahead and blogflogged, and DZoned my own article.

The result? Boom:


From an average 10 hits a day (meaning for that page, not the blog in general), up to 400. 

It feels a bit.. rotten. First of all, it feels a bit like cheating. Secondly, it's a bit sad that you have to pull pagerank like this to get out there. I'm not saying Google is broken, but it's very unfriendly to fresh, might-be useful content. I mean, my Spring post is so outdated now, I would remove it from the Google search result if I could, and replace it with something newer.

Are these the right people visiting? The avg. time on site seems above the usual, so I guess they thought it was interesting.

Should I DZone every post I make here and automatically become 100 times more Internet famous? In the end, I guess it comes down to what the purpose of this blog is (as described earlier). So I think no in general. But if I write an article or something important, and I feel "the world needs this!", I might do it again.

Thoughts?

Sunday, October 17, 2010

GearConf 2010 impressions

This week, me and a couple of colleagues attended GearConf 2010 in Düsseldorf. I also did a talk there about Git+SVN. Figured I'd write a couple of impressions from the conference.

First of all, there aren't enough conferences around here aimed at our profession. There must be tens of thousands of people working with software- and IT in NRW, and this amount of people deserve a bigger community scene than a few JUGs.

GearConf is a great event in this landscape. Obviously, it's a lot about gear, tools we use for software development. It's also language agnostic, so there are talks about .Net and Java and others as well. Finally, this year attracted many talks about agile practices, like Scrum and Kanban, and specific agile techniques.

Day one
On day one, we started off by attending the "Agile refactoring" talk by André Neubauer (@devpg) and Oliver Schmitz-Hennemann (@oschmi), from ImmobilienScout24.de. It was a fascinating talk, with lots of insight into a real, large, internet based business, their challenges with architecture and agile, Scrum in particular. Great slides, good speakers.

We then attended the Maven 3 (PDF) talk by Stefan Scheidt (@beezlebug). Stefan strikes me as being a professional, but entertaining and funny speaker. Very cool tone through the talk.

Stefan Lay (@stefanlay) from SAP then gave us a tour of EGit and Gerrit, naturally very interesting topic for me. I'm aching to get an EGit version which is good enough to get the rest of my team over on Git, and Stefan showed us this is not far away. We also had a nice talk with Stefan over lunch on software development, open source, and the enterprise.

Then it was onto "Agile Projekte mit JIRA und Greenhopper". Andreas Ebbert-Karroum (@andreasek) meant to do a demo-intensive presentation, but unfortunately, his VirtualBox acted all up on him and kind of screwed the show. He made up for this later by putting some screencasts online.  Lots of good stuff there for Jira users. Unfortunately, we're stuck with other tools.

We then attended Software-Metriken und Refactoring (PDF) with Thomas Haug. This was particularly interesting to me, as I'm kind of the "metrics man" at work. I haven't found a good practical use for how to apply the metrics yet, but Thomas certainly brought me up to speed on a lot of the theory and thoughts behind it.

Fabian Lange (@codingfabian) then did a great presentation on Agile Development of High Performance Applications, really hammering that we can't forget about the requirement of performance in our work, not even in early on development. Very wise words, and very nice style presentation. He then showed off a really cool tool for monitoring and finding performance bottle-necks in Java applications, called AppDynamics. Do try it out on your own app. It's a bit pricey, but with the free version you can monitor for 2 hours, and already find interesting stuff. If you want something free for Java, you could take a look at VisualVM.

Day 2
On day 2 we had major traffic issues getting through Düsseldorf, so I dropped the first talk in favor of preparing my own talk, which went well, after what I heard :)

After that, it was "Entwicklerproduktivität steigern mit Mylyn", by Oliver Gierke (@olivergierke) from SpringSource. I tried out Mylyn against BugZilla a few years ago, and it was OK back then, so it should be really good by now. I'm a big believer in tools that assist the whole context/coding focus thing, and although Git's topic branches and stashes helps a lot with this, I still believe there's a place for Mylyn. But it has to work really smoothly to be worth it! Will check out its Mantis integration tomorrow.

"Das ist genau, was wir wollten! - ATDD & Kunden in der Softwareentwicklung" with Björn Jensen. Björn is one of the organizers of the Hamburg JUG, and really came across as a smart guy, knew what he was talking about and how to get customers on board with agile. Unfortunately, at this point my German ear was starting to falter with tiredness, so I didn't capture as much as I would've liked of the discussion.

"Projektorganisation vs. Build- und Configuration Management" with Karl Heinz Marbaise (@khmarbaise) seemed to be aimed a bit at software developers stuck in awkward and old-fashioned setups. As we recently did a major structure change in our own Subversion repository, it was a very nod-nod-nod talk for me, not so much new.

The final talk of the day for me was "Wie kann Software die Teamarbeit in agilen Teams unterstützen und wo liegen die Grenzen?" by Ralf Kruse. It was a bit of a hidden product push for Agilo but there was a lot of room for discussion on how to keep working efficiently in a distributed agile team. Again, my German at this point was weak with fatigue, so I missed out a lot on some good points.

And after that, we headed home.

All in all it was a good conference. The level of the speakers was solid, the venue was really nice, and the size of it was small enough to be comfortable. Very informal and nice atmosphere. A big thanks to all the speakers, and of course a big thanks to Heiko and Sabine in Infaktum for putting this conference together. Looking forward to GearConf 2011!

Sunday, October 10, 2010

Git+SVN #7: Leaving SVN behind

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 my last Git+SVN screencast for the time being. Appropriately, it's about the steps we can take when leaving Subversion behind forever, allowing us to fully make use of Git.



We are yet to do this at our place. We will still maintain the Git+SVN bridge until the majority of the developers have been persuaded into using Git as an "SVN client". And in case Mercurial starts to show off some more impressive SVN-integration, we might drop Git in favor of that.

Credit to Thomas Rast who helped me out on the #git IRC channel some time ago. This article of his covers the technicalities of the last screencasts much better than I could explain in the video.

All videos can be viewed on this YouTube playlist, and all content is linked together on my Git+SVN page on tfnico.com. Thanks for watching!

Git+SVN #6: Grafting together SVN history

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here.

Time to whip out the last two screencasts for this round. Here's the first of the two, hopefully the second one will be out later this evening.



Depending on the complexity of the history of your own Subversion projects, undertaking this kind of "archeology" might seem intimidating. At work, we have a rather large SVN project which has been thrown around different locations, split into 30 projects, merged back together again, and moved again on a regular basis. I once began digging through this to get all history into Git, but gave up after two modules. It simply wasn't worth it before we're ready to do a complete migration (leaving SVN behind, which is the topic of the next screencast). 


So, for now, I haven't got the *entire* SVN history in the Git repository. But it doesn't matter, I can still work productively with Git, and we can always get the old history later on when we're willing to invest the time.

Friday, October 08, 2010

Git+SVN #5: Centralized Git-SVN Mirror

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here


Another episode on how to live with Git and Subversion in parallel:



Only a few days left till GearConf, where I will be repeating the exercise, adding all sorts of useful hints and tips on the way.

NOTE: At the end of the cast, I presented this little shell-script that I normally use for committing:

#!
git update-ref refs/remotes/git-svn refs/remotes/origin/master
git svn dcommit

Some more background:

git svn dcommit actually updates the refs/remotes/git-svn

However, in the case that I first do a git pull from the bare repo, getting the new commits via the "pure" git command, no svn refs are updated! Example:

Let's say bob commits a change. John then updates his repo:

tfnico@flint:~/john/website/>git pull --rebase
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From /Users/tfnico/john/../git-repos/website
884f657..1cb7f98 master -> origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 1cb7f98dbcc6fd9351108021e3ab9aa29a6bcb6a.
tfnico@flint:~/john/website/>vim README.txt
tfnico@flint:~/john/website/>git commit -a -m "Fixed readme again."
tfnico@flint:~/john/website/>git svn dcommit
Committing to file:///Users/tfnico/svn-repos/company-repo/website ...
Transaction is out of date: File '/website/deploy.sh' is out of date at /opt/local/libexec/git-core/git-svn line 572

See? We can't push back to SVN, because the ref is out of date. This is where the update-ref comes into play:

tfnico@flint:~/john/website/>git update-ref refs/remotes/git-svn refs/remotes/origin/master
tfnico@flint:~/john/website/>git svn dcommit
Partial-rebuilding .git/svn/refs/remotes/git-svn/.rev_map.748a8128-3b48-42b3-854a-26eb1451c56d ...
Currently at 8 = fe775358fcec6db0cc130f2377549c1cc5668400
r9 = a72a3e8c37f3fa174c5ec7464ab97a8fddbf4652
r10 = 1cb7f98dbcc6fd9351108021e3ab9aa29a6bcb6a
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.748a8128-3b48-42b3-854a-26eb1451c56d
Committing to file:///Users/tfnico/svn-repos/company-repo/website ...
M README.txt
Committed r11
M README.txt
r11 = c019fc06ad36b06ef644518e85085da653335fb9 (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
tfnico@flint:~/john/website/>

The dcommit was now successful. Remember: If you pull normal git style, nothing happens with the svn refs even if we pull changes from SVN. Perhaps this is a fault in git-pull, but we'll have to do this work-around for now.

Another important note: The reason why John uses --rebase for his pull is that he has local commits, and he wants to keep history linear for the sake of Subversion, like we discussed in previous episodes. If you have local commits, always pull from the bare repo with --rebase.

Monday, October 04, 2010

The Worklog aka Diary

This is a pattern I've been applying for the last five years, ever since company wiki became the standard at my workplace. At some point I added it as an agile practice to the Cantara wiki, and named it "The Diary". However, I always end up calling it Worklog in practice. It's a bit of a GTD technique, with some positive side-effects.

Basically, on a day-to-day basis, write down what you're working on in a wiki page.

--------------

2010-10-04
- Fix the funky registration bug -
Bug tracker id #18355. 
--------------
2010-10-05
- Still the funky registration bug -
Jason committed a fix in r8040, but it didn't work. Writing unit-test.
-------------
2010-10-06
- Knowledge meeting -
Awesome stuff. Remember to upload the presentation to wiki.
- Registration bug -
Resolved task. Talked to Jason and product owner, done-deal.
-------------


Keep focused
I'm an easily distracted person. I'd be working with something, get side-trekked by a build-break, or a colleague needing assistance, and then when getting back to work on the original task, I've forgotten what I was doing, and start doing something different, like refactoring that ridiculous exception handling! How on earth did that get in there? Woops, there goes my personal WiP limit...If I've got the current task on top of my worklog, I'm more likely to get back on it. And any other incoming tasks, I can just paste in further down, and I'll get on them later.

Multiple paste buffer
Many people keep an txt on their desktop, simply using it as a quick copy/paste buffer. That SQL statement was rather handy, wasn't it? Better paste it into the worklog.txt for later use.

(By the way, Clips for OS X is awesome.)

Mini problem database
And dang, haven't I seen this exception message before? It was something manual that needed to be done when setting up a new server instance. Didn't I have the exact problem three months ago? Ah, I'll just search my worklog to see what it was that time.

Be transparent
Ever had a manager asking what you're working on last week? Ever had a colleague asking about what you're doing? The most transparent thing you could do is to put your worklog out there in open. Yes, on the company wiki. If you want people to be all agile and open about what they are really doing, you'll have to be first out there.

Keep history
It's great to have a quick look through the last week right before a Retrospective, or a meeting to make sure you've remembered the worst impediments and ideas you had. Freshen up what you're working on.

Some tips
Use notepad. Browsers generally suck. I've lost so much worklog from keeping my new content in a text field in the browser that crashed on me. Better keep your intermittent content in a wee text-editor, and paste it into the wiki page at the end of the day. Most recent entries on top works for me.

Archive old content. At the end of every year, archive your worklog-wiki page. We use MediaWiki at work, and I use my Talk page for worklog. At the end of the year, the page is usually quite a few MB's, so then I move it into a tfnico_worklog_2009 archive page.

Don't write too much. Yes, of course you'll regret not noting down some things at some points, but the key is to not make this into overhead work. Just do it as the worklog.txt, or notebook you always had, just that you store it on the wiki at regular intervals.

Are Yammer and CampFire better tools for this? Sure, but you haven't got those tools now; you've got a wiki. And if everyone catches on and does a worklog, invest in Yammer.

If you haven't got a wiki, you've got bigger problems.

Saturday, October 02, 2010

Git+SVN #4: Collaborate with other Git users

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 one explains some more of the physics of syncing repositories between Git and Subversion land.  The big morale is that you can't really work with branches the way they were made in Git. History will have to be linear by the time you want to push back to Subversion, if you don't want to lose history. This basically requires every merge operation to be a rebase instead.

Theoretically, you could do branches between Git collaborators, but it's probably best to not stay so long out in Git before pushing changes back to Subversion, anyway, so the case for doing any useful branches are basically lost.

You can still do local branching for experimenting with some wild refactoring, or just for sorting different working sets of your code (I do this a lot, in fact). But as long as it's going back to Subversion, it'll have to be straightened up and rebased sooner or later.

Feedback?
This episode is a lot longer than the first ones, almost 15 minutes. I like to keep them shorter, but there was a lot of stuff to go through. I don't spend a huge amount preparing for the recording, and I'm not so interested in spending too much time editing it anyway, so there is some slack in there.

There's a lot of command line action in these videos, so I like going slow and keeping it simple so most viewers can follow what's going on. Do you think the pace is alright? I'd love to hear some more feedback in the comments (preferably here under the blog, not on YouTube).

You can find the first three episodes here.