Mounting SD memory card on boot

I have a SD memory card that I use as my music stash. Previously in order to access the music via Amarok I had to mount it manually (ie. click the device in "last plugged in devices") and have Amarok to scan it. Obviously I got tired of this after a while and started to look for a solution.

First of all I had to figure out how to mount the device manually. Unix systems provide mount command for this. Basically you invoke it using "mount -t " (example: "mount -t vfat /dev/mmcblk0p1 /media/sd_music") while in root mode (su first or sudo the command (sudo mount ...)).

The source part refers to what is going to be mounted ("ls /dev" to see alternatives). There are certain conventions that help you to spot hard disks, memory cards and whatnot.

The target refers to directory in which you are going to mount the device. You can create one using mkdir (example: "mkdir sd_music").

To unmount the folder, just use "umount ".

After checking out that I can mount the memory card manually I decided to look into making this process automatic. There is a special file, /etc/fstab, that happens to do exactly what I needed. Luckily I found a page describing it thoroughly. Essentially all I had to do was to add "/dev/mmcblk0p1 /media/sd_music vfat defaults 0 0" into my fstab. I checked out if it works by using "mount -a" (it executes fstab) and all worked out well. Obviously things still worked after a boot.

Note that before editing /etc/fstab or other system files it's probably a good idea to create a backup or two of the file edited. This can be particularly useful if things don't work out as they should. :)

You can find more information about mount and umount commands by surfing to man:/mount and man:/umount using Konqueror. Of course you can access the same information using the "man" command.

Subclassing a list in Python

Sometimes you need to data types provided with Python. You can do a lot of neat stuff just by subclassing and then adding some own tweaks to the child class. Here's an example:



Additionally you can override the default functionality (ie. __getitem__, __setitem__, __call__ etc.). Note that to refer to the contents of the data structure itself you can use "self". So to iterate the contents of a subclassed dictionary inside its method you can use something like "for k, v in self.items(): ..." and it should work.

Code coverage links

I have pondered for a while now how to implement code coverage functionality for TinyTest. I think I finally found the right way! Initially I thought it might be smart to implement own PHP parser based on PHP's BNF description (formal description of the language!). I did not manage to find such description anywhere. I suppose there must be one somewhere. :)

It might have been too tedious to do it this way anyhow. The next best thing is to have someone other implement the coverage part for you. I decided to look into the sources of existing testing tools providing support for coverage. PHPUnit gave me the needed clue, it uses Xdebug to handle coverage. I suppose this is the way I should handle it too. It is easy to get line coverage this way. Checking out branch coverage might take some extra work but that's alright.

During my research I found some useful sites. In addition I have listed some related material:

• http://agilesoftwaredevelopment.com/blog/pbielicki/code-coverage-against-unused-code - Nice explanation of what it's about. Remember to read comments too!
  
• http://misko.hevery.com/ - Heaps of useful information about testing.
• http://homepage.mac.com/hey.you/lessons.html - Hints that help you to push your code towards 100% test coverage. Note the importance of mocks!
• http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata - Classic Bowling Game kata. Read this if you are still new to testing and related methodologies.
  

MEPIS goes kaboom, time to try openSUSE

As KDE 4.2.4 was just released I became really eager to try it out. I have tested KDE 4 series earlier. The first version, 4.0, was bit of a disappointment. 4.1 and earlier versions of 4.2 seemed solid enough for casual use. MEPIS is still based on 3.5 by default. There is a fork known as DanumLinux that provides 4.2, though.

It is possible to update MEPIS to 4.2 by adding some experimental repositories to /etc/apt/sources.list. That's what I did. Debian experimental repositories work out of box. I managed to install the KDE 4.2 packages after bit of wrestling. To cut the story short I ended up system in which I could not get into graphical login screen. It was time to give openSUSE a go.

I have used openSUSE 10.2 before. It has proved to be a solid operating system except for some occasional Firefox crashes due to opening a file dialog. The installer managed to retain the partitioning I set up during the MEPIS installation. Overall it worked really smoothly. It's hard to find anything to complain about openSUSE's installer.

After installation I added some needed functionality (ie. media playback, KDE 4.2.4) using "one click install" links found on the net. Things worked out quite smoothly. I had minor problems after trying to install fglrx driver for by graphics card according to instructions given at http://en.opensuse.org/ATI. I managed to revert back to open source driver by logging in as root and using "init 3", "SaX2 -r -m 0=radeon" (that's a zero!) commands.

I managed to get by DVB-T card work yet again by copying the missing firmware in its place as described earlier. I also had to change the keyboard layout to "Acer Laptop" as in the case of MEPIS. For some reason the artefacts seen in DVB playback are much less severe than in MEPIS and Ubuntu. I suppose openSUSE must use a newer driver or something. :)

If there is one thing I favor openSUSE over MEPIS, it's the network manager. It's really simple and nice to use. Setting things up worked out smoothly unlike in MEPIS where it took a bit of "try and see if it blows up" to get it work.

Favorite Firefox add-ons

There are quite a few Firefox addons I prefer to use. Next I will list them and give brief descriptions of each:

• Adblock Plus - Bye bye annoying advertisements!
  
• AutoPager - Tired of clicking around? AutoPager might help in this. It allows you to browse next pages of many popular sites just by loading them on the current page automatically.
• Flashblock - Adblock for Flash. Nuff' said.
  
• Greasemonkey - Greasemonkey allows you to extend web pages locally. In case you don't feel like writing extensions on your own, you might find a few at http://userscripts.org/.
• Web Developer - A definite add-on for a web developer.
• Zotero - If you do any research you might find Zotero extremely handy.
• Omnibar - Combines search with location bar just like in Google Chrome
  

In addition Firebug is most useful tool in case you happen to do any JavaScript development. It's quite possible I have missed some excellent add-ons. In that case let me know. :)

[edit]
I thought it might be nice to hide the menubar of Firefox. With a bit of poking around I managed to find Hide Menubar that does the trick. Should you wish to see the menubar again, just hit alt. :)
[/edit]


[edit]
Added Omnibar.

[/edit]

K.O'd by Zenwalk -> Time to give MEPIS a go

Yesterday I decided to upgrade the packages installed on my system ("netpkg upgrade"). Apparently this wasn't a particularly good idea. Today as I booted up my computer a blank screen greeted me instead of expected login one. I suppose I managed to break up my graphics driver or something yet again. I didn't figure out how to boot in "safe mode" or similar (probably simple if you know how :) ) so it was time to seek another Linux distribution to give a go.

This time I decided to give MEPIS 8.0 a go. Installing it was easy. The installer was almost as smooth as one provided by Ubuntu (I'm a bit biased towards the simplicity Ubuntu installer provides :) ). By default Mepis provides KDE 3.5.something based desktop. It uses apt-get/Synaptic combination familiar from Ubuntu for handling packages. So jumping in was not quite that hard.

After getting my feet wet I decided to install some programs I happen to need and give 3D acceleration a go. To my surprise Blender ran well. Even bigger surprise was that there were no problems with PyOpenGL whatsoever!

MEPIS includes special utilities which can be used to install drivers/whatnot. This made it easy to install the proprietary driver (fglrx). After installing the driver it booted up just fine. There were some minor artefacts in the lower right corner of the desktop. Unfortunately running Blender or glxgears resulted in instant freezing of the system. I suppose this means fglrx is unusable but that's just fine considering the open source driver (radeon) appears to work well on MEPIS.

I still have many things to test and figure out (DVB-T card does not appear to work out of box so it's time for another firmware "hack" I suppose) but at least it has worked quite well so far.


I got the DVB-T card work just the way as previously (all you need to do is to copy the missing firmware file to right place). The DVB playback works but it has nasty artefacts (blue/red vertical lines). I had this same problem in Ubuntu (Jaunty) as well so that was to be expected.

[edit]
Volume up/down (fn+arrow up/down) didn't work by default so I had to set my keyboard model (Control Center -> Regional & Accessibility -> Keyboard Layout, Keyboard model) to "Acer Laptop". After this tiny tweak it appears to work just fine.
[/edit]

TinyTest - test runner for PHP

About a week and a half ago I had one day and nothing particularly useful to do. As I had just spent around a month developing PHP (not my favorite language, I'm more of a Pythonista :) ) extensions for MediaWiki at my current job I had accumulated certain amount of frustration. I figured that my future work would be easier if I had some nice and simple testing tool at my disposal.

There are many testing tools available for PHP already. SimpleTest provides a good example of one. I got used to py.test during my earlier development work (user interface library Scocca, I will post more about this later) and I quite like the simple concept. Essentially py.test does not have an API. This means that all you need to do as a developer is to write tests and test files following given naming conventions and use assert statements inside actual tests. That's about it.

Besides being without API py.test provides a way to run tests in a looping manner so that as you develop your code and tests it runs tests automatically and you get instant feedback on whether or not you have broken something. I find this extremely nice way to develop. Essentially it cuts your testing cycle next to nothing. :)

Another cool feature of py.test is that all you need to do is to invoke it and it finds the tests automatically based on where it was invoked. Of course it's possible to determine in more specific manner which files to run and so on.

The above features gave me a good idea of what my test runner, hopefully aptly named TinyTest, should be about. It took around a day to get the basic functionality done. I also made some tweaks following weekend. First release, 0.26, is available at https://launchpad.net/tinytest/trunk/tinytest0.26 .

So what do TinyTest tests look like at the moment? Basically you have to do two simple things: name your files using test suffix (ie. utils_test.php) and write tests using test prefix (ie. test_sum). If you wish to use classes name them with Test prefix (ie. TestAnimal) and name methods using test prefix as in the case of functions.

The contents of test files may look something like:



So quite simple, eh? Of course I still have to give proper functional testing to the tool yet (also it might be useful to write proper tests for the runner :) ) but I believe it might be useful in small scale development at the moment. Note that the release includes more examples and documentation (-h and --help flags as usual).

On longer term it would be extremely useful to have means to handle mocks, code coverage and perhaps acceptance testing even. On grand scale it would be awesome to have a development environment handling all these aspects in a smooth way (ie. write requirements -> figure out higher level tests -> figure out lower level tests + generate code as possible and fill in technical details).

From Ubuntu (Jaunty) to Zenwalk

I have been using Ubuntu since Hardy (released on 2008-04-24). A year ago I migrated to Linux Mint, a derivative of Ubuntu. (Ubuntu itself is derivative of Debian.) Coming from a world of Windows it was quite a shock at first. I learned to appreciate the perks (package manager, workspaces, stability, ...) of the platform though and sticked to it.

My hardware, albeit a bit old now (Acer TravelMate 4502WLMi with 2GB RAM), worked just fine till Intrepid. Unfortunately AMD decided to drop support for Mobility Radeon 9700 and a wide range of other older cards in their proprietary driver. As Ubuntu Jaunty moved on to newer version of XServer it became impossible to use a version of the proprietary driver that works with the older cards with it (see this for more).

This meant that it became necessary to use the open source driver. The driver works just fine for 2D. 3D support is quite not there yet though. Using the open source driver gave me continuous issues with PyOpenGL (see bug report) and made it impossible to use.

I tried a newer version of the open source driver but it didn't quite work as well as expected. Furthermore it caused flickering in Blender making it unusable. I figured that it was about time to try out some other distribution.

By chance I happened to find something interesting, Zenwalk Linux. Before that I took a good look at Arch Linux but the installer scared the bejeezus out of me, perhaps I should look at it some other time again. Anyway Zenwalk was more like it.

The installer was rather archaic again (I'm used to smooth Ubuntu installers :) ) but it managed to do its job and now I'm happily running Zenwalk. One of the main reasons why I found Zenwalk interesting was that they had actually documented well how to get the proprietary driver work with the current version (they haven't moved on to the newest XServer yet apparently).

Not everything worked out of box. I had to enable CPU throttling separately. Memory card reader was unusable as well. To get my memory card reader working I had to uncomment lines "/sbin/modprobe tifm_core" and "/sbin/modprobe tifm_sd" in my /etc/rc.d/rc.modules. After peeking at my devices using lspci I figured out the model of my memory card reader. This lead me to a helpful thread which in turn helped me to figure out which lines to uncomment.

I yet have to figure out how to make my sound volume controls (Fn+up/down) work properly but I suppose reading this wiki page thoroughly will help in that. It was a bit surprising they didn't work out of box as they did in Ubuntu. Also CPU throttling, memory card reader and DVB-T receiver worked in Ubuntu out of box.

To get my DVB-T receiver (Hauppauge WinTV Nova-T USB version) work I had to check out what dmesg says and work based on that. I found the device on dmesg output and saw that it didn't find firmware. To fix this I did following: "cd /lib/firmware", "wget http://www.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-1.20.fw", "ln -s dvb-usb-dib0700-1.20.fw dvb-usb-dib0700-1.10.fw". After booting the device showed up in Kaffeine just fine and worked as expected.

Zenwalk provides Xfce based windowing by default. Xfce is nice and light compared to GNOME and KDE. After browsing available desktop environments I decided to give Window Maker (not Widow Maker) a go. So far it has proved to be more than adequate. It can seem a bit weird at first.

I have had two notable problems with it. To configure the time of the clock applet you have to modify the TZ environment variable! To close applets right click on the left part of the applet. More specifically you have to click on the left border (it's a bit wider than rest). Select "kill" on the menu to get rid of the applet.

Sadly the environment doesn't retain Iceweasel in session data although it manages to work alright with terminals. The way it implements workspaces is a bit different than what might be expected. You have to manually add new workspaces as you need them. You can do this by clicking middle mouse button on the workspace widget (it has a clip on it) and then by selecting "new".

I hope to keep this blog more as a notebook. As seen above it can take quite a bit of research to get things work. Hence it makes sense to have something to look at once you need to do something similar again.