Switching keymap

As some of you might know, I am now using a Typematrix 2030 on a daily basis. When I switched to this great keyboard I also adopted a new layout on it : Colemak.

However, to be able to pair with others not using a Colemak mapping, I did not set the default mapping to Colemak but I instead use an udev rule to set the input method to Colemak only for the Typematrix.

Write a keymap switch script

Thanks to @BitardMichael tips and existing scripts I ended up with the following script saved in /usr/local/bin/set_typematrix_colemak_mapping

One of the tricky part was having a way of executing the script only when the keyboard is ready, without blocking udev’s job (or the keyboard is not yet visible by the X system). The workaround I found was scheduling the execution of the job with the simple at command.

Tell udev to run the script on keyboard detection

The process is really easy, all you need to do is to add the following to a new file : /lib/udev/rules.d/85-typematrix.rules

Adapting it to your use case

If you are using another keyboard than a Typematrix you will need to adapt the udev rule with the proper Vendor / Product IDs (you can grab them with lsusb). For the xinput part, you will need to adjust the grep to match your hardware.

Of course the same goes for your layout : colemak / dvorak / bépo …

Arquillian testing

Arquillian testing is very convenient to get a full environment deployed on an application server and test quickly. However sometimes we need to debug what’s inside.

Launch Maven in Debug mode

One way of doing it can be launching Maven in debug mode with the mvnDebug command instead of the classical mvn. It will open a JPDA debugger on port 8000 by default, you then just need to connect to it with your preferred IDE. But, if there is forked processes, you won’t be able to debug inside them.

Launch Failsafe Integration Tests in Debug mode

When using Arquillian, there is a high probability that Arquillian is running in a forked process (with embedded containers).

There is an easy way to tell maven-failsafe-plugin to wait for a debugger when starting : use the -Dmaven.failsafe.debug property.

You can even specify the options as you would in $JAVA_OPTS to change ports / wait…

Oops

A few days ago, I finally decided to upgrade the installed Linux on my dedicated box hosted at OVH. As with every task you tend to postpone until it is too late, it failed miserably, Murphy’s law I am looking at you right now !

During the install process, the machine hanged (I am not sure whether the machine is faulty or not, it seems to shut down under heavy load). Fortunately for me, OVH is kind enough to send a tech resets the machine, and if it does not ping when booted, the tech reboots the machine in rescue mode.

Rescue mode

The rescue mode is a lightweight Linux booted on the machine so you can run fsckand other commands to rescue your filesystem (you can even scp files to backup before a reinstall for example.

My problem was simple, I needed to allow dpkg to finish its job in order for me to get a working machine. Then I think of the good old powerful chroot command and I remembered how powerful Unixes are !

Mounting filesystems

As you should know, chroot is a command allowing to change the root of a file system, litterally jailing it into a directory (popular things of today like pico containers like Docker are improved versions of chroot).

The partition layout of my machine is the following :

• sda1 contains the root filesystem
• sda2 contains home directories

I issued the following commands to “jail” the rescue mode into my machine :

$ mount /dev/sda1 /mnt
$ mount /dev/sda2 /mnt/home
    
$ mount -o bind /proc /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -o bind /dev/pts /mnt/dev/pts
$ mount -o bind /sys /mnt/sys 
$ chroot /mnt/
    

From then, I was on my machine, with my files and so on, so I have been able to run dpkg to finish the install :

$ dpkg --configure --a
    

Finally, dpkg sent me back to a working prompt and I have been able to reboot the machine (do not forget to change boot disk in OVH manager to hd or netboot to prevent rebooting in rescue mode).

Command line nerd

As a command line geek, I always have at least one open and tend to use it for everything on my machine.

HomeBrew is a very convenient tool to install command line tools to your Mac without cluttering up your environment. You can use it like your Linux friends are using apt-get or yum and it feels really nice.

One thing that your friend can do and you cannot, is installing Google Chrome only using command line, this is where HomeBrew Cask comes to the rescue.

Installation guide

Cask will be up and running in a very few steps :

$ brew tap phinze/cask
$ brew install brew-cask
$ brew cask install dropbox #for example

Usage hint

This tool is really nice because it allows you to script your machine setup. No more headaches forgetting the installation of when you want to use it.

Don’t hesitate to add a small script in your .dotfiles to seed your software on new machines, and if your preferred software is missing, it is really easy to add new casks.

Manage your services

If you’re using HomeBrew to manage your software installation on your Mac, there is a thing that is not that easy to do : launchd or launchctl service management. Often you need to manually tell launchd to load the plist of your newly installed service. It leads to a lot of things launched at boot on your machine, and they are not easy to manage.

LaunchRocket provides a simple PreferencePane allowing you to start/stop services when you only need to with a clean and simple GUI.

You can easily install it via brew cask (more to come on brew cask soon) or download the zip distribution