dispatched

Transition to github/git from trac/svn

Ever since I evaluated and implemented project management software for my current employer, I have been a big fan of trac. While I knew about the downsides of svn, I liked the upsides of trac: it's lean, it's clean, it's Python!

During the last year, however, I came to realize that even though trac is a great tool for many projects, it might not be best for my personal projects. For one, social visibility is close to zero - in part because I like to host on my own server. Second, I was wrong to think svn is good enough for smaller projects - even when working alone git has major benefits. If only for being able to work offline, worry free distributed backups and beyond human speed. Anyway, "good enough" sometimes is just a fancy argument for being lazy.

So, last week I finally decided to get over it and to try github and git as my SCM toolset of choice. To use github is a no-brainer these days - just about every day I read great stories on HackerNews or reddit/r/programming. It's not just about free hosting, that's not a real problem anyway. It's all about social visibility these days. Not having a github link on your CV will lead to certain questions.

Being on the wrong end of this discussion can be unnerving. It's not that I can't defend my point of view. It's because everyone asking me about it has been right. After having worked with github/git the last couple of days, I conclude those tools have become mainstream for a good reason.

I'm a strong advocate of kaizen - to always improve yourself a little bit. I also encourage people to not only use the tools they know, but to always seek out for the best tool for a new job. I now have to realize, that concerning SCM it was me who had the outdated mindset. trac certainly is a great tool, I won't deny that. But there is space for improvement. Time to move on.

Turns out, I'm a pretty active coder in my spare time. I worked on four projects the last few days, three of them visible on my new github account. Just smallish hacks, but hell - that's what I love about coding: always being able to tackle new problems quickly and upfront; it is not about the big bucks - those are a side-effect.

Some GForge automation

There is no automated way of moving tracker items in GForge. Each item has to be moved by hand. I just wrote an iMacros script to automate this task, which has saved me and a friend a whole day of clicking repetitively.

You can find this script on github: https://github.com/preek/gforge-mass-move-tracker-items

Why we needed this: When you implement a new custom workflow in a legacy GForge environment, it is best to do so in a template. Every new project can then be cloned from it.

Unfortunately old projects will not get updated. You have two choices now: One is to repeat enforcing the workflow on every project (which is a tedious task and can easily take up to a day). The other is to make a new tracker which is cloned from the template. Then you can move your tracker items from the old tracker to the new one. Voila, you got the new workflow rules applied.

Getting rid of a Ubuntu resource hog

While graphical package managers like Synaptic or KPackageKit certainly are great tools for the novice Ubuntu user, I personally don't see any benefit against the various apt CLI bindings. For one, I'm not a big fan of using GUIs where not needed and secondly, the graphical package managers' search features come with extra baggage - they use Xapian in a cron job for indexing, which can be quite a CPU hog.

Even though Ubuntu has good defaults and uses ionice to schedule for IO priority, this setup caused my system to hang completely. To be fair, I should mention that I run VirtualBox instances in parallel.

To disable the regular indexing, you can remove execute permission on the cron job:

sudo chmod 644 /etc/cron.weekly/apt-xapian-index

Or you can completely uninstall the tools:

sudo aptitude purge apt-xapian-index

You can also uninstall KPackageKit or Synaptic completely, but you would lose your update manager reminding you of new packages.

Fullscreen for GVIM in Linux

To me, fullscreen does magic in terms of gained productivity – there’s no distraction anywhere; I can perfectly focus on the work ahead. MacVim has a nice fullscreen feature(CMD+SHIFT+F). I don’t want to miss it in my Linux environments, though.

In GVIM, there is a little manual labour involved, because in Linux, the window manager is responsible for, well.. managing windows – GVIM itself can’t implement “fullscreen”.

To achieve true fullscreen capabilities in GVIM and Linux, there are two steps involved:

• Make a shortcut in your window manager for fullscreen
• Get rid of GVIMs’ menu and toolbar

I’ll demo #1 for KDE:

Get rid of the menu:

And the toolbar:

Of course, you could edit your vimrc and set those flags globally.

Now, enjoy your editing with SHIFT+ALT+F.

Redirect system sound to Airport Express

The Airport Express is a great device when used in combination with iTunes - I thought. I could sit on my couch on my MBA, do some coding work while listening to my streamed Library (Mac Mini) not through internal speakers, but through my Harman-Kardon Hifi system.