Why does desktop-background-changing in Ubuntu has to be rocket science?

Some sort of disclaimer

I am a big fan of Linux for quite some time now. My migration from Windows to Ubuntu (although bumpy) was a very successful one in the end.
This is however only because I have an enormous patience when it comes to improve my working conditions on the long term, and, of course, because I’m a fuckin’ geek programmer.

However, I am 100% convinced that I were to be an accountant, secretary or languages student, I wouldn’t touch a Linux even if you would point a gun at me. I want to start a series of articles to prove why Linux won’t “Ship on More Desktops than Windows”. I know is an old topic, but there’s just too much of this in the Linux community and especially in the Ubuntu community.

Before getting threatened by some frustrated Linux garage programmers, I want to state something clearly. As already mentioned, I like Linux and I really really really want to see a decent desktop distribution one day. But this is only because I know what I am doing at least half of the time. The thing is that there isn’t any Linux distro (or that least none that I know of) that is capable to deliver a humanly usable desktop to non-IT-literate users. Such users are the ones around which I want to focus my posts, so I will try to stay out of the development-related topics as much as possible (although there would be plenty of those too, unfortunately).

Most of what I’m going to post is obviously Ubuntu related since I don’t have the time and resources to install a new distro every fuckin’ weekend – I did that in college, but I got a life in the mean time. So to all those CentOS, Fedora or openSUSE fanboys that are going to bitch about things like “oh, but my distro doesn’t (or does) that” – you are totally missing the point. The same for the ones whining about “oh, but this requires proprietary drivers, bla bla, freedom and free software, bla bla, we don’t want to pay to use software” – just die.

My only hope is to have the Linux geeks pay attention to the common user and not the one that is able to compile his kernel at 3 AM. That’s the only chance the Linux has if we really want it to ship on more desktops than Windows.

Stay tuned. Or find out in the mean time what you should be using Linux for.

If you think that the previous posts certified my geekness. you ain’t seen shit.
This time it involves some electrical wiring, soldering, low-level C/C++ programming and lots of smoking: my first Atmel AVR project. Yeah baby, that’s what I’m talkin’ about.

I’ve ran into this technology a couple of years ago when I coded a desktop application to communicate with such a device. So I wasn’t really involved in designing the parts external to that.
A couple of weeks ago I decided to try the real deal and implement something inside the AVR controller. Since I wanted to do something that is actually useful, I decided to make a digital thermometer.

At first I searched for some temperature sensors and it seems that there are many options in that area. So I had to do lots of digging to find out what would best fit for such solutions. In the end, I found out that there are both sensors and AVR controllers supporting the I²C two wire interface. No, I didn’t have a clue about what that was before starting this. In fact I admit learning lots of the electronics basics with this project.
Based on I²C is how I got to my winning candidates: ATmega168 and the DS1621 sensor.

Obviously, the other part of the problem was getting the information displayed. I was aware of the (most obvious) options in that area from the beginning: LED display or LCD display. I knew that using an LED display will either use up my controller pins or force me to use some shift register to expand the number of outputs. Since I wanted to keep it simple I opted for an LCD device. I bought one that is a lot larger than necessary, but only because I also plan to use it for some other purposes.

This is how the whole thing looked like in it’s final phase.

No, of course the board is not something I built. It’s the STK200 AVR starter kit from Kanda which is also an AVR programmer.
I know how the whole thing looks messy, but I didn’t spent time in making it compact since that was not the actual purpose.

The TWI and the LCD interfaces didn’t seem impossible to code since it’s pretty standard and well documented stuff. But since I am a complete rookie on this, I didn’t want to spend too many nights re-inventing the wheel when there are lots of libraries taking care of the low-level communication. So I used Peter Fleury‘s LCD and I²C master libraries to handle the low-level protocols.

What I did have to clarify in detail though (even if it was fairly light) was the DS1621 specs where each of the commands and expected results are described. This however was the part that I found the most attractive and I believe that in general these are the parts that are worth the trouble: at a certain level of specs, you get the detailed description of what bits you have to wire and what you get back. No questions asked – (almost) always works as specified.

Once I’ve put all the pieces together and managed to display the actual temperature value, I had to somehow validate the output. Not that there is much to do about it. The thing is that if you managed to read some value from the sensor it usually means that you did your part of the deal and an error in the actual numerical value is (probably) not something you caused. This was however not the case since I have a multimeter that also does temperature measuring among other things.

Yeah, I know, my place is pretty warm. In the winter I sometimes overreact with the heating. Anyways, the DS1621 also has an 0.5 degree error (at least that’s the spec value), as for the multimeter’s sensor I have no idea. Bottom line is that is good enough so I’m a happy panda.

I didn’t spend the time to draw the schematics of this, but if you are really interested drop me a note and I can send you some summary of what exactly is to be done.

It took me a while to learn everything since this doesn’t quite work like “learning a new framework for the platform you know for years”. But it’s definitely interesting and it’s definitely a new level of geekness for me. Fuck yeah.

Last week at TJUG, our local Java User Group, I had a short presentation called “Stripes – Painless Java Web Development”, introducing (obviously) Stripes. Slides can be downloaded here.

We also had a chance to take a look at Eclipse RAP in another presentation by Gabriel Ciuloaica – “From Eclipse RCP to RAP”.

Many thanks to Gabi Pop who always takes care of planning and organizing the TJUG meetings.

I’ve been looking for a decent tool to determine the byte code version for a Java .class file. You know, the one based on the numbers after the CAFEBABE magic (you can read more about this here or here).
There are some tools around for this, but most of them written in Java. I really don’t see the point in starting a JVM just to read 4 bytes from a file, so I wrote a short Perl script for this. Again, I am no Perl expert so this is probably not the best solution performance-wise and such.

Usage

1. Running the script with no arguments – will result in scanning the current directory recursively for .class files. The results are grouped by directory and a total number of files is also displayed. Directories that do not contain any .class files will be ignored, in order to keep a clean output. Below is a short sample.

cosmin@cosminaru:~/work/quizine$ bcversion.pl

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine (2 files)
	QuizineException.class -> 1.6
	ApplicationContext.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/web (2 files)
	ErrorHandlerFilter.class -> 1.6
	SessionContext.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/web/actions (1 files)
	ActionBase.class -> 1.6

2. If you provide one or more arguments, the script will only scan the content of these arguments. If the argument is a file then the byte code version is displayed for that file. If it is a directory then it will be scanned recursively, just like above.
Note: The paths from the argument list should all be relative to the current directory in order for the script to work correctly.

cosmin@cosminaru:~.../model/quiz$ bcversion.pl AbstractQuestion.class result
* AbstractQuestion.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/model/quiz/result (5 files)
	QuestionnaireResult.class -> 1.6
	BooleanAnswer.class -> 1.6
	AbstractAnswer.class -> 1.6
	SingleChoiceAnswer.class -> 1.6
	MultipleChoiceAnswer.class -> 1.6

I’ll probably want to scan JAR files and directories containing JAR files. But the really poor Perl docs for reading ZIP buffers didn’t quite help me. If you think think you can give a hand with that, drop a note .

Download:

You can get the script from here.

TestNG-XSLT, a small project of mine, has finally made it to 1.0. It’s currently tested only with Firefox 3.x and Internet Explorer 7, but it will probably work on most modern browsers. For the moment I thought it is more important to target the popular browsers and leave the more exotic ones for later.

Some of noteworthy features that I’ve added since the project start:

• Maven plugin with access to all transformer features and settings.
• SVG pie chart with the overview of the pass/fail/skip status.
• Configurable CSS style sheet – you can build your own “skin” by overwriting the built-in styles and setting the testNgXslt.cssFile parameter. More about this here.
• Ability to change the report title, to generate information about test durations and other settings configurable through XSL transformer parameters.
• Other smaller or bigger issues and feature requests reported by users.

I want to thank all the guys that used this and came up with bugs, feature requests and suggestions: Andreas Guther, Xuan Ngo, Francis Henninger, Csongor Gyuricza, Andreas Kuhtz and others.

Last, but not least, I would like to mention that Haw-Bin Chai has managed to successfully integrate TestNG-XSLT in Lightest, a lightweight testing framework based on TestNG and Groovy.

The download is available here. If you use Maven, make sure you update your pom.xml to get the 1.0.9 version of the plugin.

There are many situations when I need to convert an amount of Euros to RON (Romanian Leu). There are a couple of sites that can do the conversion for you (even Google does this pretty well). However, none of them seem to be as accurate as the the National Bank of Romania, whose exchange rate is the only one that has any relevance for me. So most of the times I have to open the calculator, go the BNR website and use the exchange rate provided here, an issue that doesn’t work very well for a lazy ass like me.

Fortunately, BNR also provides an XML with the exchange rates for the most important currencies in a manner that is very easy to understand:

...
<Rate currency="DKK">0.4926</Rate>
<Rate currency="EGP">0.4291</Rate>
<Rate currency="EUR">3.6747</Rate>
<Rate currency="GBP">4.6020</Rate>
...

Luckily, Perl knows how to parse XMLs so we’re almost good to go. Now I am not Perl expert, nor want to become one very soon, but this sounded like something doable with a minimum amount effort.

What we need is to get the XML with an HTTP request, parse it and convert the given amount of money using the desired currency. So I created a tiny script convert2ron.pl that accepts two parameters: the currency identifier (EUR, USD, etc.) and the amount to be converted. I will not go into the details of how this script works as it’s pretty straight-forward (even for someone with a minimal understanding of Perl). So now I can convert all sorts of currencies to RON using calls like this:

$ ./convert2ron.pl EUR 245


and get results like these:

245 EUR = 900.30 RON

(rate is 3.6747)


Is this the geekiest way to do this, or what? And the geekness doesn’t stop here. Now I also have some scripts like eur2ron.sh and usd2ron.sh so I can do stuff like this all day:

$ eur2ron 456

So, if you want to convert international currencies to RON the geek way, here’s the download: http://cosminaru.ro/downloads/ron-convert.zip.

I finally got the time to finalize the Maven plugin for TestNG XSLT. A detailed usage scenario is described here.

A few important notes:

• Integration with the Maven site (navigation link in the “Project Reports” section)
• CSS customization is performed by passing a cssFile configuration parameter to the plugin

As mentioned in a previous post, starting with the 5.6 version of TestNG, we have the ability to get an XML report (in the testng-results.xml file) that takes in consideration most of the TestNG features that are not available in the JUnit-compatible XML results. Although my spare time was fairly limited lately, I finally managed to create a project for an XSL transformer to handle these reports, in order to provide a useful and user-friendly output for TestNG, as an alternative to the classic HTML reports.

The project is currently hosted on Google Code at http://code.google.com/p/testng-xslt and the current version is 0.2. For the moment you can only get it from the SVN repository, but that will change as soon as I’ll have some time to write some decent documentation and pack it with a download zip. Some sample generated reports are available at http://cosminaru.ro/test/testng-xslt.

To get started, you can call ant test in the project base directory to see it running with a sample set of data. Your output should be generated in the test/single/output subdirectory. You can also use the build.xml file as a sample of integrating this with Ant and the output of a TestNG test run. Please take in consideration that the module is relying on lots of XSL 2.0 features. As far as I can tell, the only current implementation for that is Saxon, but you don’t have to worry about that since is bundled in the lib directory of the project.

Load balancing is a common issue for many web-sites or web-based applications. Last couple weeks I had to play around with a Java-based web application that, among other things, needed to be balanced for high availability and failover. The most handy solution for this seemed to be Apache httpd and mod_jk. I won’t get into the details about setting up and configuring this stuff as it can be read on hundreds of other websites. What I want to show you is a simple way to get a more realistic (even if not bullet-proof) load balancing configuration out of this.
Let’s take a sample mod_jk configuration of a load balancer with 2 nodes. This configuration also includes a jkstatus worker that we use to monitor the overall status of mod_jk.

JkMount                 /test/* router
JkMount                 /jkstatus/* jkstatus
...
JkWorkerProperty worker.list=router, jkstatus

JkWorkerProperty worker.worker1.host=localhost
JkWorkerProperty worker.worker1.port=8009
JkWorkerProperty worker.worker1.type=ajp13
JkWorkerProperty worker.worker1.lbfactor=1
...
JkWorkerProperty worker.worker2.host=localhost
JkWorkerProperty worker.worker2.port=8019
JkWorkerProperty worker.worker2.type=ajp13
JkWorkerProperty worker.worker2.lbfactor=1
...
JkWorkerProperty worker.router.type=lb
JkWorkerProperty worker.router.balance_workers=worker1, worker2
...
JkWorkerProperty worker.jkstatus.type=status

As you can see, the lbfactor must be set here manually and I used 1 for both nodes to create an equally balanced cluster. The problem that we encountered is that we need to set the lbfactor at runtime based on the actual load of the Tomcat nodes. For example, we might want the load factor to indicate the CPU usage or memory allocation percentage.
Using the jkstatus worker, there is a very simple way to do this, once you obtained your number that indicates the load factor of your node. Assuming that the gateway (the machine running the Apache with mod_jk) is accessible from the machines running Tomcat, we can use wget to easily set the load factor:

wget "http://gateway_ip/jkstatus/?cmd=update&from=list&w=router&sw=worker1&wf=453"

Once you did this, your value (453) can be seen in the corresponding row for worker1 on the page located at http://gateway_ip/jkstatus/.
This might not be the most enterprisey way to do this stuff, but it’s a quick solution that can provide a pretty realistic load balancing (as long as the factor itself is calculated in a realistic manner).
You can put this stuff in a script, for example an update_lbfactor.sh on a shared NFS drive and adjust it to accept the worker and the load factor as arguments:

wget "http://gateway_ip/jkstatus/?cmd=update&from=list&w=router&sw=$1&wf=$2"

This way, the nodes will just have to call this with the appropiate arguments:

update_lbfactor.sh worker2 345

Hope you find this usefull.