It works only in Germany and will find the nearest cash point for Cash Group, which is an association of Deutsche Bank, Commerzbank, Postbank and a few others. As someone not living in Germany you may ask Why? Well, if you use a cash point from another bank you will have to pay fees for withdrawing cash, sometimes as high as €6.

So, without further ado:

Screenshot

App Store links

• English
• German

Why not RVM?

Well, I tried RVM but compiling Ruby took 3 hours on my EC2 micro instance and was eating all my CPU so that my webserver was basically not available anymore. To me that isn’t acceptable. Besides, I think it is highly wasteful to compile packages from source when there are precompiled versions available. I admit that apt is too slow to keep up with the rapidly moving gems ecosystem but for the Ruby interpreter itself I strongly prefer the OS to handle the installation.

Besides I don’t really want to use different versions of Ruby at the same time. I just want something that isn’t Ubuntu’s default 1.8.7, which in Ruby years is ancient.

The steps

The good news is that as of writing this, Ruby 1.9.2 is available without any PPAs straight from the official Canonical package repos. The bad news is that information about how to get it is thin on the ground.

For starters the package for Ruby 1.9.2 is called ruby1.9.1 and Googling around, it wasn’t immediately obvious that any version of Ruby 1.9 is even possible on Ubuntu.

Anyway, here it goes:

sudo apt-get update
 
sudo apt-get install ruby1.9.1 ruby1.9.1-dev \
  rubygems1.9.1 irb1.9.1 ri1.9.1 rdoc1.9.1 \
  build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev
 
sudo update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.9.1 400 \
         --slave   /usr/share/man/man1/ruby.1.gz ruby.1.gz \
                        /usr/share/man/man1/ruby1.9.1.1.gz \
        --slave   /usr/bin/ri ri /usr/bin/ri1.9.1 \
        --slave   /usr/bin/irb irb /usr/bin/irb1.9.1 \
        --slave   /usr/bin/rdoc rdoc /usr/bin/rdoc1.9.1
 
# choose your interpreter
# changes symlinks for /usr/bin/ruby , /usr/bin/gem
# /usr/bin/irb, /usr/bin/ri and man (1) ruby
sudo update-alternatives --config ruby
sudo update-alternatives --config gem
 
# now try
ruby --version

This installs Ruby 1.9.2 and sets that to be the default ruby on your system. Crucially, it also installs rubygems for that interpreter and sets that to be the default. (Thanks for the initial snippet to Michał Frąckowiak. His version got me most of the way there.)

Uninstalling Ruby 1.8

If you, like me, ran a Rails app on 1.8 you probably have a bit of stuff hanging around the file system. Lets clean that up.

First uninstall all gems from the 1.8 installation with:

gem1.8 list | cut -d" " -f1 | xargs sudo gem1.8 uninstall -aIx

Secondly, remove the ruby packages with apt.

sudo apt-get remove libruby1.8 ruby1.8 ruby1.8-dev rubygems1.8

After you have done that you may want to check if there is anything else hanging around with a quick:

dpkg --get-selections |grep ruby

On Ubuntu you can do the following:

$ dpkg --get-selections |grep apache
apache2						install
apache2-mpm-prefork				install
apache2-prefork-dev				install
apache2-utils					install
apache2.2-bin					install
apache2.2-common				install
libapache2-mod-php5				install
libapache2-mod-wsgi				install

This tells me that I have mpm-prefork.

I had heared of Sass repeatedly for a while now but so far I had always mentally filed CSS precompilers under “Interesting concept, but probably not all that useful for me”. I thought that CSS is fine as it is and after all it’s just a bunch of style definitions, right?

On the other hand I grew to actively dislike handling CSS files. I didn’t quite understand at the time that this had mostly to do with their great redundancy and repetition.  When you’ve been used to something’s mediocrity for so long you don’t really noticed those weaknesses anymore.

When a coworker suggested using a CSS precompiler to help our CSS explosion, I was pretty sceptical. But I like learning new things so we went ahead and introduced LESS in our current project.

What a difference! I may end up sounding like a used-car salesman but it really is a difference like day and night. I’d love to tell you lots of reasons why these precompilers are great, but unfortunately Jason Z. from 37 signals has done a much better job.

Wasn’t this post suppossed to be about Vim?

Lets talk business then. I’m using Vim to edit LESS and it looks like this:

Vim with vim-less, vim-css3-syntax, vim-css-colors

I can recommend a trio of plugins for LESS and general CSS3 editing:

vim-less

This plugin’s syntax highlighting was fairly feature-rich to begin with but I have added a few extra features including indenting and autocompletion and the original author has merged them back to his branch. The plugin’s compatibility has led me to check out vim-css-colors.

vim-css-colors

This great plugin visualises a color expressed in hex, RGBa or HSLa and paints the background underneath it in the corresponding color. If you’re not sure what I mean, here’s screenshot:

This may look like a toy to some, but LESS lets you have a file with just the colour palette of your app/website and seeing them all visualised is very nice. It also helps you to reuse the same variable name for each colour rather than re-introducing new ones.

vim-css3-syntax

This has a very complete syntax file for CSS3 and I have  added support for this plugin in vim-less. That works pretty well and those fancy new CSS3 properties are then also displayed with correct syntax highlighting applied.

Improvements for the future

The current autocomplete (hit Ctr-X, Ctrl-O if you’ve never used it) that ships with standard Vim is pretty complete for CSS2. However there is no autocomplete script for CSS3. Looking at the CSS2 version, it shouldn’t actually be too hard to parse the syntax highlight files and add the new properties to the existing script.

I’d also like to implement a syntax checker but looking the the source of lessc, LESS’ command line compiler, there doesn’t seem to be a validating phase that I could use.

I also saw that some web-based CSS prettifyiers can order CSS properties alphabetically. Wouldn’t that be a neat feature for Vim?

Well, this works pretty good until you realise that there are some config entries you want to be different in the two environments. Git’s user.email is obviously such a case.

The solution

Git does not allow you to to include other configuration files in your .gitconfig but you can use the environment variable $EMAIL in order to overwrite user.email.

What I have done is to add the following to my .bashrc (which is also in the dotfiles repo):

if [ -f .host-specific.sh ]
then
    source .host-specific.sh
fi

This loads a host-specific bash file (if it exists). In this file you’ll stick your email address like this:

export EMAIL=lenni@work.com

(Obviously this file needs to be recreated on each host and can’t be shared across computers through the dotfile repository.)

Now you can safely share your .gitconfig between the two computers without having to worry about the email settings.

Turns out it is harder than it sounds but in the end I found an example in the Cobertura Jenkins Plugin.

So, this is just a mental note for myself in case I need it again. If you’re Googling for it like myself, hopefully you’ll stumble over this and say hi in the comments.

Preparation

It was around Christmas ’10 that I thought what my goals were for the coming year. I had run the Berlin and Potsdam half marathon in 2010 and figured I could push myself harder this year. I didn’t fancy the Berlin Marathon as it is in August, which would mean training all summer when I could be lying in the sun doing nothing. Besides, I dislike the heat and much prefer colder days for running. So I signed up for the Prague Marathon in early May 2011. I knew that I wasn’t remotely in marathon shape but signing up early forced me to be serious about it all. I can only recommend this tactic.

I had been using an app on my phone called Runkeeper which GPS tracks you as you run and gives you instant feedback about distance run and average speed. They had a feature called training sessions gives you a fairly detailed plan about what distances and intensity you should be running. I signed up for the one aiming for a marathon in 4h30. The plan had a gradual increase in distance but was nevertheless pretty intense: 16 weeks training with four training sessions a week. This sounds like a big burden but I must say as the training progressed and my alcohol consumption, smoking and going out decreased I noticed not only increased fitness but my mood changed substantially, too. I become happy as I had never been in my live. It was hard to not constantly talk about how good I was feeling at the moment and how happy the training made me.

I had one annoying injury from one of the long runs on Sunday where I my left thigh started to ache for the rest of the week and would only heal by the following Sunday. I even had to pause the training for one week and that made me feel quite anxious about my progress. In the end the worry turned out to be baseless – every training has its setbacks and I haven’t talked to anyone who said that there wasn’t ever a problem during their preparation.

The peak of the training was two weeks before the actual event where I ran 28km. This doesn’t seem like a lot if your’re planning to run 42km but I had been doing 12km the day before and the stated strategy of the training plan was to “spread the load” over multiple days in order minimise the risk of injury. After this weekend the training decreased sharply and I only did about 10km max and finishing off with a gentle 15 minute stroll the day before the marathon.

The day itself

To say it upfront: the marathon was great and a thoroughly enjoyable experience. I had been running the training runs at a speed of 5:15 to 5:30 mins/km. At the marathon I reduced the time per kilometre to 6 minutes because I had no idea how my body would react to distances greater than 30 km and therefore I decided to take it easy.

I had slept poorly the night before and was nervous at the starting line but finally around about 9 o’clock the crowd went on their way. I decided not to use Runkeeper during the run because I knew that the GPS connection would drain the batteries and listening to music was more important to me anyway. This was a great decision. During the first 10km I managed to stick to my planned time almost to the second. At 10km I still felt great and fresh and at 11 I briefly saw my parents, who had come to Prague, and stopped for a quick photo.

From 10 to 20km it was still plain sailing and at the half-marathon mark I was ahead of schedule by about 1:30min. From 20 to 30km I was expecting some tiredness but I was surprised how well I was still feeling at 30km. I had been taking an energy gel every 5km (starting at 15km) and even my energy balance ,which I was very worried about before the race ,was okay: I wasn’t feeling the depleted or hungry and with a good mood I entered the last stage of the race.

The last 7km

At 32km I was ahead of schedule by about 3:30 mins. But by about 33km I started to feel some discomfort in my legs and thighs. Nothing major at that point but simply the stress of the race taking its toll. This kinda got worse by the time I reached 35km and from then on it could no longer ignore the pain. It hurt!

Well, you can imagine what happened now. I switched into survival mode an put all my will power into not stopping. I saw lots of people taking a short break at the side stretching their muscles but knew from experience that this would be a bad idea. Starting again after those breaks is very hard if not to say impossible. So I struggled on.

At kilometer 37 a lot of people were walking but I still hadn’t stopped my running (save for the drinking stops) but there was a small elevation, almost nothing, which I just couldn’t run up anymore so I walked it up. This really bruised my ego and made me loose some time but at that point I just didn’t care anymore. The same thing happened at kilometre 39 but in total I only lost about 3 minutes during the two short walking periods.

And then the final kilometre came. This was a great time as I was so relieved to have made it there. The spectators cheered and all the runners where scraping together the last bit of energy that was still in them. I crossed the finish line at 4 hours 13 minutes 55 seconds. That was 2 minutes slower than I had planned the day before but of course much better than the 4:30h that the training plan had aimed for.

In reflection

Looking back at the entire time I must say that the following things made my marathon as success.

• Using an Android app that tracked my progress was a huge motivation boost. I really like Runkeeper but there are plenty about.
• Practicing using the energy gels during the long training runs before the race. My biggest worry was that I would run out of energy and feel depleted. This is often called The Wall.
• The weather: it was 17 degree on the day and there was always a slight breeze coming from the water

If you have an ambitious personality and like to push yourself, I can only recommend that you run the marathon yourself. You’ll be proud forever and you will notice an unprecedented increase in your happiness and well being.

Do it!

Basically, I was having trouble uploading files generated by Maven’s site plugin to a host. The URL was specified as follows

<site>scp://server:/some/long/path</site>

In Maven2 this worked out of the box without extra configuration.

In Maven3 this threw the following error during site-deploy:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:2.2:deploy (default-cli) on project $PROJECT_NAME: Unsupported protocol: 'scp': Cannot find wagon which supports the requested protocol: scp: java.util.NoSuchElementException

The trouble was that the Site Plugin apparently doesn’t automatically pull the Apache Wagon SSH implementation. You have to tell it manually to do that like this:

<build>
  ...
   <plugins>
     <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-site-plugin</artifactId>
      <version>2.2</version>
      <dependencies>
        <dependency>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-ssh</artifactId>
          <version>1.0-beta-7</version>
        </dependency>
      </dependencies>
     </plugin>
    </plugins>
  ...
</build>

I chose Ubuntu as the operating system and a lot of tutorials tell you to configure and use the command line tool for starting an instance but I found it a lot easier to just go through the web interface. I will walk you through how to do that.

Sign up

Well, duh, you’ll need to set up an account at http://aws.amazon.com/ec2/

Selecting an AMI

Once you have the account go to the AWS management console and select the region you want your instance to be hosted. You’ll be redirected to the Console Dashboard where you’ll find a big fat “Launch Instance” button. That’s exactly what you want to do, so proceed to choosing an AMI.

An AMI is an Amazon Machine Image, basically a template for the various Linux distros. Collin Percival has also recently added AMIs for BSD, so if that floats your boat, go knock yourself out. Search for the most current (or LTS) version of Ubuntu you’re interested in and check that there is a yellow star next to it. There will be quite a few ones for your chosen release so just select one starting with the official Ubuntu user id of ’099720109477′. I’m not sure why there are so many copies of the same release but I guess they continually repackage the image with all the updates applied, so you don’t have to do that.

After the image select ‘micro’ as the size of the instance (one micro is a free for for one year for new customers) and accept the standard settings for everything until you get to the key pair section. There you should create a new named pair and download the pem file to, say, foo.pem. Remember that name for later.

Allowing network access

This one is a bit tricky and took me longest to understand even though it is right under your nose: by default your instance won’t be reachable from outside Amazon’s data centre. You’ll have to enable the services you want to allow.

So, create a new security group and give it a name you’ll remember. Then select the services you want to allow; most likely you want at least ssh, http and https but maybe you’re running a mailserver as well.

Connecting to the instance with SSH

Back in the Management Console you’ll see your newly created instance. Right-click on it and select connect from the context menu. This will give you the instructions on how to actually log into the instance. Basically you’ll need the key file and start SSH with something like this:

ssh -i foo.pem root@ec2-11-111-1-1.eu-west-1.compute.amazonaws.com