Just a few notes on how to move your sonar installation to another machine without loosing any of your config and/or history. Some of that include the normal installation steps too. This list is specific to debian.

Add the sonar debian repo to your machine (/etc/apt/sources.list.d/sonar)

deb http://downloads.sourceforge.net/project/sonar-pkg/deb binary/

Update and install sonar (sonar pkg is not signed):

aptitude update && aptitude install sonar

Install postgresql and set up an account for your sonar:

This just refused to work because the flashplugin-installer that actually downloads the packet doesn’t honor the http_proxy environment variable to I had to do a little hack to get this going. It’s actually pretty simple: download the file and serve it from localhost so we don’t need the proxy at all.

First shell:

• mkdir /tmp/flash
• cd /tmp/flash
• wget http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_11.2.202.310.orig.tar.gz
  ==> or whatever version YOU need
• python -m SimpleHTTPServer 80

Second shell:

A while ago I wrote a quick tip on how to mount an ipod in linux, I did this while working on a python script that would retrieve all my music from my ipod and put it back into a file structure of my choosing with file and directory names that a human being can understand. The reason for this is simply the fact that I kept rating music over time and ended up rating everything - an information I don’t want to loose as I migrate all music onto my phone.

Sonar doesn’t support merging of projects out of the box so when you happen to rename a project as I just did, you’re suddenly stuck with 2 projects of the same name unless you do a little bit of sql trickery in the back. Here’s how you do it (quick & dirty approach). What we’re going to to is: rename the old projects (with all the juicy metrics) to the new groupid/artifactid and delete the new one (which only has a handful of builds anyway and we can afford to loose these, but not the yearlong history we’ve collected):

The gradle daemon speeds up builds quite a bit and you do want to have it running on your local machine but not on the build server, that one should always re-build from scratch. This is actually quite easy to accomplish.

In your ‘~/.bashrc’ add the following export so your local machine runs all builds with the gradle daemon:

export GRADLE\_OPTS="-Dorg.gradle.daemon=true"

Since, by default, the gradle daemon is not started, it will not be used on your build server.

I’m currently trying to get rid of my iPod and move all my music to my android phone. Needless to say my iTunes installation on the PC is long gone and these iDevices are the proverbial bottomless bit - you’ll never get anything back out of them, or do you?

Thanks to the libimobiledevice and ifuse projects, you can now mount an ipod like any normal usb stick in linux, and it doesn’t even have to be a rooted device.

I’ve found myself trying postgres over mysql for a few things and had some trouble accessing the db server at all at first. So here’s how you first access the server:

$ su -          # su to root
# su - postgres # su to postgres
$ psql          # access the server

That wasn’t so hard now was it? Once I’m in the psql shell, I tend to issue the following SQL statement so my primary user has unlimited access, to make things easier for development:

Always test your puppet modules. Even if it’s just a little smoke test like this:

class { my\_module: }

Now to make this one better, create a job on your continuous integration server and let it run the following script inside the modules directory of your puppet project:

#!/bin/bash

#DEBUG="--verbose --debug"
hash puppet 2>/dev/null || { echo >&2 "Please install puppet"; exit 2; }
[ -z "$(facter | grep fqdn)" ] && { echo >&2 "Your machine has no FQDN (according to facter), some tests may fail or print warnings"; sleep 5; }

for dir in $(find . -type d -name tests); do
 for file in $(find ${dir} -name '*.pp'); do
  echo ">>> TESTING ${file}"
  puppet apply ${DEBUG} --modulepath modules --noop "${file}" || { echo ">>> ERROR" ; HAS_FAILURES="true" ; }
  echo "------------------------------------------------------------------------------"
 done
done

if [ "${HAS_FAILURES}" = "true" ]; then
 exit 1
fi

It looks for all ‘*.pp’ files inside all ’tests’ directories and does a simple ‘puppet apply’ call. It may not be perfect but it’s small, simple, it works and it’ll save you some gray hairs.

My Virtualbox images are usually fairly small. Here’s how to increase the size of a vbox disk, to 8G in this case:

vboxmanage modifyhd /home/user/vbox/vm/vm.vdi --resize 8192

After that, remove the disk from the vm it’s currently attached to, hook it to a new vm, which will boot from an iso file. Once booted, start gparted. It will complain that the gpt partition table is not (anymore) at the end of the disk, ignore that message and you’ll see the full disk with the initial partition plus additional space at the end. Resize the partition on the disk or create new partitions, whatever you like. Save the changes, stop the vm, move the drive back to the initial vm and start that one again.

A little goodie I’m writing up here to document for my own future reference.

Objective: Remove all lines matching a certrain pattern from all files in a directory structure. The pattern is in the form of “part1..part2”

First try: grep and sed, unfortunately that leaves me with blank lines where the matching content was and I want that line removed completely. Apparently sed can’t do that.

Second try: use awk with regexes. It took me a while and I wanted to use ’next’ on matching lines but that didn’t seem to work so I ended up printing the entire line if the regex didn’t match. Here goes: