The current version is a first Alpha of a 0.5 and there’s still room for improvement, so ideas are more than welcome. In addition, the UI itself is not as “Rich” as “RIA” and not a major change in layout since the previous version. This is mostly because I didn’t want to invest too much effort in this direction just yet (and as we all know, professional UI is always a bitch in terms of effort).

I’ve managed to put up a demo .war file that can be dropped in a Tomcat or anything like it. It uses the HSQLDB engine so no additional setups will be required (except for what’s already here). Username and password for the demo .war are admin/admin.

I’m also trying to get some decent VPS hosting for a Live-Demo so it can get more exposure. I’ve evaluated some options so it should be sorted in a few weeks.

Anyways, any ideas or any kind of help is more than welcome. So if you like it, find it useful or want to contribute, just let me know.

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 original Excel file published on a web server:

Downloaded this on Windows to fuck around with it.

Download on Ubuntu to edit and etc…

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.

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.