I want to change the date. I don’t want to compile a kernel module, biatch.

Last week I’ve looked around for a decent flash solution to present flickr.com photo sets and after a while I ran into SmashingMagazine’s list (which is not around flickr but also highlights some solutions supporting it). I have a high (although probably not 100% founded) level of trust for SmashingMagazine’s relevance in terms of media and internet content so I kind of took this for granted – although there might be other alternatives out there.

Anyways, going through the list, the candidates either look over designed (and clearly serving other purposes), were licensed under some inconvenient terms or just with a low level of control over the features and content aggregation.

So I decided to give it a shot and see how really complicated is to code something like this with flex and here are the results: http://cosminaru.ro/photo/cosmin and http://cosminaru.ro/photo/alexandra.

It doesn’t have the smooth scroll and other fancy stuff but it gets the flickr sets and it displays their content – which is actually what I was looking for. Later maybe I can find some time to add some cool effects here and there, but for now is good enough. It also has support for linking directly to one of the images so you can do stuff like this.

The binary package can be found here. It works by editing the flickr-user.txt file with your flickr user id (not user name) which you can obtain from here: http://idgettr.com/.

I also want to publish the code but it needs some cleanup and some wtf’s removal first.

The Read-NoWrite-Web (not even on your fuckin’ machine).

The original Excel file published on a web server:

Downloaded this on Windows to fuck around with it.

Download on Ubuntu to edit and etc…

The “playa”…

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

I am a huge 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 am a huge fan of Linux and I really really really want to see a decent desktop distribution one day. However, (as also mentioned earlier) this is only because I know at least half of what I’m doing at the fuckin’ console. 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 now I have a personal life that also involves non-IT-related stuff. 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 (I’ll probably delete your comment if you become very insistent). The same for the ones whining about “oh, but this requires proprietary drivers, bla bla, freedom and free software, bla bla, we don’t use the devil’s proprietary drivers” – we all know that’s not the user’s problem on Windows, for example, is it?

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.

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.