This feed contains pages in the "devel" category.

I modified the livejournal import script so that it's capable of handling comments as well. There are better instructions on the script page on how to export comments.

Now I'm done with livejournal and I can finally delete my account there. All the relevant data has been migrated over. YAY!

Posted Sat Mar 6 18:57:33 2010 Tags: devel

I finally converted my old blog posts from Livejournal to ikiwiki. They have no real value to anyone but me and it hasn't been a real priority to me anyway.

Livejournal is capable of exporting the blog posts in an xml format with html markup inside, so it's rather simple procedure to compile markdown pages for ikiwiki to consume. This is mostly because you can use plain HTML inside markdown pages.

I did the conversion with XSLT, which started with a simple template and grew up a bit once I added some cleanup features (like filenames and metadata). The script itself is available for download and the archive is available for browsing.

Posted Sun Feb 28 15:26:02 2010 Tags: devel

When Finland switched to Digital Television, I opted for a Dreambox. The box has been well worth the money. Almost a year ago (yes, I've been meaning to make a post about this ;) ) I bought a Logitech Harmony One universal remote. Since the beginning it had some issues with the box.

The problem is that by default most of the commands repeated twice on the Dreambox. The remote itself can be modified to fit other devices, but it's not fine grained enough. You can basically alter the default setting of "2" to "1", what ever those mean. Keeping the setting at 2 gives duplicate presses and 1 gives me a poorly working remote (not all presses are registered).

Luckily the Dreambox is open and it's easy to dive in and dig around. After some digging around, I found /proc/stb/ir/rc/repeat which allowed me to alter the repeat time of the remote. After trial and error, I managed to find a working setting. Looks like 1150 ms is just a tad bit below the required repeat time for the remote, but for some reason increasing the setting to 1200 made things worse. So this appears to be as good as it gets for me.

I also created a script to set the repeat time at boot (since I shutdown the box for the night) which can be found here. Fix-repeat script takes install or uninstall as argument so it should be relatively easy to install it. The only real trick used in the script is the conversion from a decimal number to a HEX number.

Posted Sun Jan 25 09:37:17 2009 Tags: devel

Some people consider the gnome usability guidelines a nuisance and some consider certain applications way too simplistic. While it is really hard to get the usability right, it's well worth it.

We need to keep in mind that as computer oriented people we tend to see things differently. Things that are simple to us aren't really that simple to the "normal people". But one of the simple things we can do the insure that the software we write serve the people it's designed for is to remove all not needed pop-ups and questions.

A good way to detect these would be to ask yourself why would a user choose anything else but the most logical option. It's kind of hard to explain, so lets pick an example:

Firefox is updated, the first question it usually asks after upgrade is about incompatible extensions. The user is presented with choices, check for updates or cancel. Now, we are dealing with internet browser so the user should be connected to the internet so there is no problem with checking for the updates, we can rule out that scenario. The other scenario that I can come up with is that a developer doesn't want to update some certain extension.

So at least I can't come up with any reasonable scenario why someone would want to select anything else but to upgrade the main option of upgrading the extensions. Why not just leave out the option and instead do the upgrade automatically. If you wish to be transparent, you can show the user that you are doing the upgrade. Or you can do like some applications do and just do it without bothering the user with the options.

I know I sound like a Google fanboy, but Google generally gets this right. Their applications skip out all upgrade related notices and just do the upgrade. Regular user doesn't want to upgrade because the user has been scared with incompatibility notices and upgrade checklists for so long. Just going ahead with the upgrade in complete silence keeps their software up to date as well.

Another example would be from few years back: The Ubuntu installation. Back in the day Debian was working on Debian Installer, which is also used as the main installer in Ubuntu alternative installation media. Debian Installer is capable of doing most things silently, but with Debian it by default asks a lot of questions. It doesn't matter, since most people who install Debian can be categorized as developers. But in my opinion, the thing that made Ubuntu a success was that it doesn't ask the questions that can be answered without asking the user.

So, back to usability. There are basically 2 camps, the "normal" users and the developers. Developers want and need to see a lot of the backend behaviour, just to debug problems. Currently a lot of the open source software is focused towards developers while they are gaining grounds on the "normal" population as well. We should start focusing on the users for a change.

Posted Sun Jan 4 13:48:56 2009 Tags: devel

Sometimes I get the urge to vent a bit. Here goes...

It really annoys me to see websites that are designed in a stupid way. There are a lot of ways you can design a website and quite a few of them lead to problems that the designer didn't think about.

Designing websites isn't always easy. You need to be able to figure out all possible corner cases and prepare for them. Usually things go wrong right in the beginning. Developer picks a tool and decides that the tool is really nice and sticks with it. The thing is that the tool doesn't really make the website. It helps you to create one! A big part of creating a website is fine tuning the output of the tool.

The most common problem with web layouts is the orientation to the content. Most designers think that website should behave like a newspaper and have columns. Usually the right column has a menu and left column has ads or some other "relevant" information. The problem is that while doing this, designers usually opt for tables and images. Now, this presents us with a problem images fail to scale well and the table becomes static in width. What does the designer do? Opts for 800x600 or 1024x768 layout, depending on who they assume to be their target customers. This leads to horrible layouts, like the following.

While allowing the text to flow properly on the full window will get you some initial readability complaints, this is caused by the fact that people don't use 800x600 or even 1204x768 windows. Shocking, isn't it?! So we have web designers creating websites for window sizes that nobody actually uses.. What is the point in that?

Another thing that bugs be a lot is the use of JavaScript and cookies. Don't get me wrong, both of them are a good thing. There are a LOT of websites created with dynamic html which works really well. The problem is that too many sites rely on JavaScript and cookies when there is absolutely no need for either of them. Most of the common JavaScript tricks can be done with plain and simple CSS and too many sites use session to store data when there is no need to use a session. What makes things worse is the fact that hardly any of these sites check if cookies work or offer alternative navigation if JavaScript isn't available.

I just visited UPS which first presents me with a nice page about selecting my location. Since I use NoScript to block all scripts (yes, it makes the web a friendlier place) it alerts me about not being able to run scripts. Since there is very little on the page, we could assume that this is one of those "change the value of this drop-down and automatically submit"-scripts. Selecting the correct language and selecting submit brings me to a blank page.

Inspecting the front page a bit more reveals that the JavaScript actually changes the link to point to a completely different page. What this means is that if you ever visit the UPS front page with a browser that doesn't support JavaScript at all, you can't access the content at all.

In fact the whole selection is quite pointless. Yes, it brings me to the 'Finnish' page. The language is still English and there is hardly anything different from most other countries. Why was I forced to select my country? Why didn't the website guess? There are pretty accurate IP databases out there that can pinpoint the city you are accessing the site from. Language can be detected from the headers the browser gives your website. The whole front page is pointless and wastes my time.

In the end of this all ranting I must say that getting a website right doesn't happen by chance. It is possible with a lot of hard work and patience. And I appreciate those who manage big sites and get it right.

I was going to give more examples, but had a hard time finding them...

Posted Fri Jul 18 23:35:15 2008 Tags: devel

It's interesting to think about what kind of moods you need for certain things. Today I needed to write some code, at first it was pretty painful. Every line I wrote was a stretch. After a while I got the right mood and it got easier and easier to write.

I've said in the past that the last thing I want to do is to become a full time programmer. I would go insane if I had to force the code out of me. Then again, every time I get in to the mood I start to think about doing this for a living. Programming is in many ways just the right thing for me. At the same time it's challenging and easy; challenging when you want to do things the right way and easy when you finally figure out the best way to do things.

Now I'm in the mood for some sleep...

Posted Sun Oct 28 23:43:09 2007 Tags: devel

I just uninstalled tracker. I loved the idea and liked the fact that it wasn't a resource hog. What started to bother me was that there were a few outstanding issues that kept bothering me. I'm a bit too busy with other aspects of life to start digging in to the code and fix the problems so I waited for a new release.

I've also been following the discussion in the development list and noticed something that I've noticed with other projects too.

People keep urging people with problems with the stable release to compile the development version and using that instead. It's OK to refer people to try the release to see if a problem has been resolved but as a general solution it's not a good thing. Quite a few projects have problems pushing out releases, people focus on working on new features instead of stabilizing the code base for releases from time to time. Even though it can temporarily slow down development to push out a new release, it is a good thing for the project. It pulls in new users and ideas for the project.

I know that with tracker there were other issues too that delayed a stable release, but still I'm uninstalling it. I'm looking forward to reinstall tracker in the future.

Posted Mon Jul 16 22:32:34 2007 Tags: devel

Every now and then I see a post that talks about certain VCS, usually that VCS is something that the poster has discovered recently and is now discovering more useful features from the VCS. This is the time when the user is most valuable to the VCS communities. The user is valuable to the community from which (s)he left, because that community is able to learn what the users really wanted in their VCS. At the same time the community of the new VCS benefits because they can see what are the strong points of their VCS, what the users really think is useful. And in the end, it's useful to all the other VCS communities since it allows a glimpse in to the users minds and how to add features to their VCS to get more users to use.

This is all good. If you look at it reasonably it's always a win-win situation when a user changes to a different VCS.

If you put the objectivity aside, you can see how people get jealous. If someone likes a feature in some other VCS they are seen as a threat and either they get attacked or manipulated in to converting or simply both.

This all reminds me of the past desktop wars and editor wars. Of course both of these still are burning hot. Both of these wars (like with many wars) carry similar features. When a user switches over, both parties should try and find out why and work on improving that feature. It's a common good that way.

It's like the saying: 10 000 Flies can't be wrong. If 80% of the user base likes a certain feature, that feature is worth working on. If 10% likes a feature, it might be useful, but one should really think about investing time in to the feature. I'm not saying that you shouldn't implement the feature, just that the time invested to that feature is taken from some other feature. If you think that your time is well spent with that feature, for example, if it matches a set goal in that application, go for it! Don't go for feature bloat, you can't please everyone. Making a sensible plan and sticking to that plan (or reworking that plan) is a good thing.

In the end, we should all try and see what the people who selected some VCS saw in that VCS. Improve that feature, assuming it fits the goals, and make the world a better place.

As for me, I've picked Bazaar because it's straight forward. There are no magic commands to issue before the first checkout and the commands are reasonable. Sure it's slow and uses disk space, but the issues are being worked on. Speed is getting better all the time and the repository format is being worked on. I've used CVS and Subversion and tried quite a few others. And it's always the same thing, when ever I switch, there is a reason for it. I hardly ever switch to something just because someone recommends switching.

In the end, I should write more about the reasons why I don't like something. Not in the 'Bah! This sucks' way, but a constructive manner. It's hard to write that way, but usually it pays off.

Posted Tue May 1 11:14:45 2007 Tags: devel

Ever since i found subversion i have kept all the websites i've maintained or developed under a VCS. Some time back i discovered bazaar, which is a distributed VCS. With bazaar i learned the true power of VCS for maintaining a website.

The first thing people who don't use a distributed VCS notice is the excessive use of branches. It still gets to me sometimes, but it's a good thing in the end.

Ok, here is an example based on real life. A while back i set up a drupal based website. I started the development with an RC version and later migrated to a final version. I still have the repositories hanging around if i ever have to upgrade the site.

First we create the base repositories. I will use a shared repository to save some space, but there is no requirement to use one.

/work/ > mkdir -p website/upstream
/work/ > mkdir -p website/tarballs
/work/ > bzr init-repo --trees website 

Next we import the first drupal version (i've already copied the tarballs to the tarballs directory)

/work/ > cd website/upstream/    
/work/website/upstream/ > tar -xzf ../tarballs/drupal-4.7.0-beta4.tar.gz 
/work/website/upstream/ > cd drupal-4.7.0-beta4 
/work/website/upstream/drupal-4.7.0-beta4/ > bzr init
/work/website/upstream/drupal-4.7.0-beta4/ > bzr add 
added .htaccess
added CHANGELOG.txt
added themes/engines/phptemplate/node.tpl.php
added themes/engines/phptemplate/phptemplate.engine
/work/website/upstream/drupal-4.7.0-beta4/ > bzr --quiet commit -m "import drupal 4.7.0-beta4"
Committed revision 1.                                                          

Now it's time to start working with the website itself. First we get a copy of the website engine to start working on it. Lets create a dummy theme with a message in it.

/work/website/ > bzr get upstream/drupal-4.7.0-beta4 main
Branched 1 revision(s).
/work/website/ > cd main/themes/chameleon 
/work/website/main/themes/chameleon/ > cp -a marvin dummy
/work/website/main/themes/chameleon/ > cd dummy
/work/website/main/themes/chameleon/dummy/ > cat >> style.css << EOF 
> a:before {
>   content: "This is a message";
> }
/work/website/main/themes/chameleon/dummy/ > bzr --quiet add .
/work/website/main/themes/chameleon/dummy/ > bzr --quiet commit -m "commit my custom theme"

Next, we publish the website and create content. After some time we are ready for a full release and notice that drupal 4.7.5 has been released. Note that the import command is provided by bzrtools.

/work/website/upstream/ > cd drupal-4.7.5 
/work/website/upstream/drupal-4.7.5/ > bzr import ../../tarballs/drupal-4.7.5.tar.gz
/work/website/upstream/drupal-4.7.5/ > bzr --quiet commit -m "new upstream"
/work/website/upstream/drupal-4.7.5/ > cd ../../main   
/work/website/main/ > bzr merge ../upstream/drupal-4.7.5 
All changes applied successfully.

Now lets verify that the modification is still there:

/work/website/main/themes/chameleon/dummy/ > tail -3 style.css 
a:before {
  content: "This is a message";

That's all there is, bazaar will tell you if you modified some parts that were modified upstream and offer you some help in merging the changes. If the software was designed properly there usually aren't any conflicts.

At this point one could argue that you can do this manually too. It might even be easier for small projects to do it all manually, but on bigger projects it's increasingly difficult to track all local changes and changes made upstream without help. Getting it done by the tools provided to you makes it all worth it. And if you wish to add modules to the mix, just create new upstream branches for them too. Just create a branch based on a upstream release and add the module there, then merge that branch to your main branch. When you want to upgrade, replace the module in the upstream module branch and merge to your main branch again.

The last thing to note is that this all requires planning. Without planning or luck you will have to do a bit of work to get this all set up. It can be done, but it's not as easy as it is if you start off with proper structure.

Posted Sat Feb 24 15:54:51 2007 Tags: devel