Last week my colleage Tino Dietel wrote a little Tampermonkey userscript, that improves the Assigned to dropdown of Redmine. In large teams it becomes tedious to pick the right assignee, especially if you almost always pick the same four or five people from a list of say thirty people. His solution to the problem was to simply add secondary option elements to the top of the list, one for each of the top assignees which have to be previously chosen. His work is published on GitHub as well.

Inspired by this and having a bunch of further improvements in mind, I started out writing a little framework today, that eases development of Redmine userscripts. It tests for the existence of jQuery and jQueryUI on the page, optionally injecting those if no recent versions are found. Afterwards it starts each and every extension. Besides it provides some helper methods like easy access to localStorage and a user selector.

More details can be found on the fresh Redmine Extender page. If you already have a userscript manager (like Tampermonkey) installed, just click the download links and you are set.

Recently I came accross a Pen by Azik Samarkandiy, who implemented a accordion in pure CSS and immediately wondered how he did that. So far I was pretty convinced, that you just have to use JavaScript to achieve something like that, since you can’t keep state (i.e. which content part is active) with just CSS …

Azik had a very clever idea, that easily solves the problem: he just uses radio buttons. This way he doesn’t even have to disable (i.e. hide) the other elements, since the radio elements already make sure that at most one is active all the time.

After all the radio buttons are made invisible (via display: none) and controlled with labels, that are easily stylable using CSS. The appropriate content is made visible using CSS’s general sibling cominator, i.e. ~, and otherwise defaults to invisible like so:

/* Show .info, if the related radio button is checked. */
.block input[type='radio']:checked ~ .info {
    height: 130px;
}

/* Generally hide all .info blocks. */
.info {
    height: 0;
} 

Transitions between state can easily be achieved using transition CSS properties.

After all I think it is still questionable to add radio (form) elements to HTML markup to keep presentation state, since it mixes the concerns of the HTML/CSS/JS triple, i.e. I’d still expect the state to be wrapped in a JS (be it jQuery) module. On the contrary e.g. Geierlein has a checkbox to show/hide large (hardly used) parts of it’s tax declaration form. In that case I would not object using CSS at all, since the checkbox is a visible, directly user controllable element.

Update October 10, 2015: just removed the widget during a major update of the blog itself.

The other day I’ve noticed yet another very interesting app for the N900, called Saera. On Youtube there is a nice video, showing it in action.

After all it aims to become a full fledged Siri clone. It’s written in Python, the GUI is based on PyGtk. Speech recognition is performed either using Pocketsphinx or the Google Voice Search backend.

But well, it’s rather buggy:

First off the speech recognition using Google Voice API was broken. Saera was always relying on Pocketsphinx. If that one didn’t come up with the utterance, it passed the voice recording on to Google’s API. So far, so good. But it didn’t pass the utterance back to the processing module. It just passed it on to answers.com. I’ve quickly fixed that and provided a pull request on GitHub, which was merged within two days.

I’ll definitely put some more effort into the project. Mainly I’d like to speak to Saera in German language and have a plugin based processing backend.

Some weeks ago I more or less accidentally stumbled over a neat little tool called HeySms by Thibault Cohen. It’s written in pure Python, hence should be cross plattform, but actually it targets the Maemo 5 platform (i.e. the Nokia N900).

After all the tool bridges between SMS message transport and the Bonjour protocol. This is, if the N900 receives a SMS message it’s automatically passed on via Bonjour to a previously defined contact. Furthermore if this contact possibly answers via Bonjour, the reply is automatically forwarded as a SMS message.

The user interface is actually dead simple:

It just allows you to select the Bonjour contact, to pass incoming SMS messages to, as well as a friend list. All friends are exported as Bonjour contacts, so they are visible in the contact list of the Bonjour client on your PC (I prefer Empathy). This enables to actively send SMS messages, i.e. not just keep answering.

After some initial problems HeySms really does a good job on my N900. I’ve sent quite a few pull requests to the author, which usually were integrated within hours. Really, really pleasing :-)

The most apparent problem was that incoming messages were not decoded correctly resulting in total gibberish being passed on to Empathy. Digging around a little I found out, that the software assumed a phone number length of 11 or 12 digits. Unfortunately my girlfriend’s number has 13 digits :-)

A second problem I quickly noticed was that the size of outgoing messages was limitted to only 70 chars. This is due to the SMS PDU providing space for a message payload of 140 bytes and HeySms using UCS-2 encoding (which means 2 bytes per character). I Initially solved this by adding support for concatenated SMS messages. Later I added support for sending GSM-7 encoded messages to allow for the typical 160 chars per SMS.

One last thing that really bugged me was that HeySms didn’t correctly work in the office. After quite a while I found out that the phone didn’t send multicast group joins as needed. It turned out, that the Linux kernel I had installed (which is the stock power kernel image, aka kp51) had multicast support disabled. After flashing a multicast-enabled kernel HeySms worked even there.

In case you’re interested, here are kp51 kernel images with multicast enabled:

• Linux 2.6.28 kp51+multicast image
• flasher for the above image
• Bootimg version of the above image
• Kernel modules for the above image

If you’ve got a N900 and send plenty of SMS messages, give HeySms a try. You’ll definitely like it.

One of the things that always annoyed me regarding my Nokia N900 mobile phone was that it was not working correctly with the PBX at our office.

At first we had an Auerswald COMpact 5020 VoIP PBX there, that supports SIP out of the box. The N900 does so two. Therefore why not just connect the two? Well it even allows you to connect and make outgoing calls.

Incoming calls however cause trouble. The phone even rings, but as soon as you want to accept the call, the connection is reset. Back in January 2011 I found out, that the problem seems to be caused by Telepathy SofiaSIP (Telepathy’s connection manager for SIP, which is mainly written by Nokia employees). It particularly does not support so-called 3pcc INVITEs. However the PBX is solely capable of sending this kind of INVITEs (or at least it doesn’t seem to be configurable).

I’ve submitted a bug report against Telepathy SofiaSIP back then. However until now Telepathy SofiaSIP still lacks 3pcc support (as opposed to alternative clients like Twinkle or Ekiga).

Meanwhile we got a new PBX at the office, an Auerswald Commander 6000. Unfortunately this one also sends those 3pcc INVITEs, not supported by Nokia’s N900. Installing other VoIP clients on the phone was not an option to me, since the whole phone is built around DBus and Telepathy. Another client like Ekiga would be painful, since it wouldn’t integrate with the other applications on the phone, like addressbook and presence signaling.

Besides SofiaSIP got renamed to Telepathy Rakia, but still no 3pcc support in sight.

After all it’s free software. With enough effort it should be more than possible to have 3pcc support on the phone. Since I decided to stick to the N900 for the upcoming months, I started studying Rakia’s sources. It cost me quite a lot of time (read: several days in a row) and unfortunately the resulting patch’s length doesn’t tell so at all…

Also available:

• backport to Telepathy SofiaSIP version 0.6.3.
• Maemo package of Telepathy SofiaSIP 0.6.4, having the patch applied.

With the patch applied even incoming phone calls are no problem any longer. As it would have been too easy otherwise, two more problems popped up:

• the PBX lists the N900 as unavailable minutes after connecting
• there always is some chirping if I start to speak

Having a look at the UDP packet stream using tcpdump it quickly became clear, that the N900 didn’t re-register as needed (i.e. it didn’t send keep-alives). I haven’t debugged the issue much since there was a new upstream version of libsofia-sip. Instead I built a new package of the library and it’s glib bindings. After installing those, the problem instantly disappeared.

The glitches and chirping were caused by power saving modes of the processor. The frequency governor is configured to activate any frequency between 125 and 805 MHz. So when noone was speaking, the speed fell down to 250 MHz or so. As soon as one party started to speak, there’s just not enough processing power to do the voice encoding in time. Locking the frequency to 600 MHz immediately helped, everything works just as expected then.

So how to lock the minimum frequency to 600 MHz during calls? The phone stack already has code to increase it during the ringing phase, however lowers it as soon as the call is established. That’s okay for GSM calls, which use the DSP for voice encoding, but bad for VoIP. Since I didn’t want to touch the existing C code I added a little daemon called voipspdy that’s monitoring the session DBus to notice calls. If a VoIP call is active it monitors the frequency settings file using inotify and constantly forces the minimum frequency to at least 600 MHz.

In the latest issue of the German Linux User magazine there is an article on Geierlein written by Hanno Böck. Unfortunately there’s only a teaser available on the linked web site, …

I especially like the image of the vulture which fills about half a page :-)

My day-to-day mobile phone still is the Nokia N900. Unfortunately the platform is dead for quite some time now and as a matter of fact there are next to no cool apps like there are for Google’s Android.

Hence the fundamental question: stick to Maemo 5 or leave for Android? I very much appreciate the openness of the N900 - admittedly there are some proprietary components). Want to jailbreak? Just use sudo. Besides I’m very much into Debian and since Maemo is kindof derived from it, you can just open up a xterm window and sudo apt-get dist-upgrade to do a full system upgrade. Want to overclock the phone? Well, just kernel-config lock 850 on the shell. And last but not least it has got a hardware keyboard which is very useful if you’re typing lots of stuff over the day …

At least there are Android phones with hardware keyboard like the HTC’s Desire Z or Sony’s Xperia mini pro. Compared to the 805 MHz of my overclocked N900 they both don’t have much more processing power. The Desire Z is clocked at 800 MHz (by default though). The Xperia runs at 1 GHz. However both have twice as much RAM – a detail of the N900 that really bugs me. It almost always uses more than 300 megs of swap space.

After all I decided for the openness. Having sudo, apt-get, openvpn, iptables etc.pp at hand is just plain cool and awesome. In order to have an even cooler phone I’ll tackle the missing 3pcc call support of the SIP stack soon. Hopefully with more luck than last time on it…

I once more decided to update and re-focus my blog. In the past it was a wild mix of anything that mattered to me and was worth losing some words on. The new blog shall focus on coding, generally and regarding my projects. Furthermore I want to keep writing in English language, that way broadening the possible audience, on the other hand sharpening my skills in English writing.

Since I love Git and Github, enjoy working on the console and writing in vim, I was just sick of typing into the Wordpress backend. After getting in touch with Jekyll when creating a little homepage for Geierlein (and feeling very very pleased) I decided to migrate the blog to Jekyll as well.

Besides I can host the page on Github that way.