So, after the last upgrade and the frustrations that came with it, I decided to ask around for good blogging software. The main contenders I had in mind were WordPress and Movable Type. Most of the people who replied talked wonders about WordPress, but I decided to try both. WordPress’ installation was ridiculously easy (I’m talking about installing my own copy, not opening a blog in wordpress.com obviously) and I had a working blog pretty quickly. Also, at least the first impression of the UI is that it’s very slick and easy to use. It shows maturity. Movable Type was easy enough to install, although I did have some problems (mostly due to my own stupidity, but still). The first impression was that Movable Type was much “heavier” and maybe a bit too much for a single, personal blog. So I decided to go for WordPress, which was the one that I had been recommended by most people anyway.

So, the first thing I had to do was exporting the content from Typo’s HCoder so I could import into WordPress. I quickly found some script for Typo that would export in WordPress’ format, for easy import. It worked very well, although I did a problem with the tags: they were treated as normal categories, so I ended up with many categories and no tags (and a huge, horrible, impossible to navigate sidebar with dozens of categories). I started to look around, and I couldn’t find a spec for the wxr format. Maybe I was naive thinking that there would be one, but hey. In any case, eventually I figured out that I had to change the:

<category>rants</category>

to

<category domain="tag">rants</category>

for the tags. The categories had to stay as they were, but luckily for me, all uppercase names were categories, and all lowercase names were tags, so I could do the trick with vim with:

:%s/<category>\([a-z]\)/<category domain="tag">\1/

After that, I could import back all the content, but then I had the next hurdle: the style of the blog. I didn’t mind if the design wasn’t exactly the same, but I was used to the old one and didn’t want to change it too much, so I used the excellent Opera Dragonfly to inspect the styles of the old blog, and I slowly copied the most interesting values (colours and font sizes mostly) to the equivalent CSS classes in the WordPress theme. I’m happy with the result, so I think I’ll leave it as it is for now.

Last, but not least, I wanted to try to keep the old URLs working. I did two things for this:

1. I added some URL rewrites to keep Typo’s feed URLs working. However, the Atom ones also redirect to the RSS ones, I wonder if that’ll be a problem.
2. I changed the default permalink settings in WordPress so they matched what I had in Typo. Hopefully almost all blog posts will actually keep the URL and the migration to WordPress won’t be very traumatic. You tell me if I’ve broken anything ;-)

One thing that I don’t like about WordPress’ blog editor is that apparently it doesn’t allow you to write in some Wiki-like syntax, like Markdown or Textile. I know Movable Type does have it, but several other things made me stick with WordPress and I’m happy overall. At least for now ;-)

It took me a while, mostly because of stupid Ruby deployment nonsense that makes me even more tired of Ruby as a language for production usage, than I already was. Oh well.

One of the most important new features for me in this release was the article preview, which doesn't seem to work. Or maybe it does, but then support for writing blog posts in Textile seems like it was dropped. Suggestions for other blogging platforms that aren't a pain to upgrade because of the language dependencies, supports writing in some wiki-like syntax (e.g. Textile or Markdown) and generally works well are very welcome.

It seems that everything is in place and working now, but if you see anything misbehaving, please give me a shout and I'll try to fix.

• It does have a (lame) name now: Bubug (supposedly stands for “Barely Unconventional Bug Untracking Gizmo”. Whatever).
• It has improved a lot here and there, and it now has authentication and multi-user support, not to mention a lot of UI bling bling and goodies.
• The development has moved to BitBucket, an excellent free service built by ex-Opera’s Jesper Noehr, where you can follow it more easily, comment on, check the Wiki, fork, or whatever you want. You even have a screenshot there ;-)

As you can guess from the last point, for this project I’ve been using Mercurial instead of Git. Although I certainly don’t have sophisticated needs, so YMMV (heavily), I find Git more pleasant to use. Which is kind of surprising, because I always thought that Git’s UI was a pain in the ass. Oh, well. That doesn’t mean that Mercurial is hard to use, though. I think it’s more that I’m used to Git now, and there are a couple of things that I find more convenient: the coloured diff (possible in Hg, but you have to install some extension for it, and only thinking about installing some Python extension that is not even packaged for Debian makes me want to switch to Git) and the staging area are the most important ones I can think of.

So, if you thought I had abandoned the TODO application thing, you were wrong ;-) If you’re interested, have a look at the Bubug BitBucket project page, download it, play with it, and tell me what you think.

• I learned QUnit, which I used to write some really useful unit tests. It’s quite nice to be able to write Javascript unit tests easily.
• I made some heavy refactoring (see above) which made me learn some more Javascript and made the code much more flexible, so now the widget is not limited to a single Kiva API page of results, but to as many pages as needed to fetch whatever number of loans the user wants. Not to mention that the data source need not be a URL.
• Now the widget actually has some configuration. Namely, the number of loans to show in the map. It also stores it persistently using the preference store, which is quite nice.

As I said, I used Git for it. I don’t “hate” it anymore, but I still find some things annoying, like the horrible, confusing names some options have (I’m thinking about “git checkout ” to revert the local changes, or “git diff —cached” to see the contents of the index/staging area; seriously guys, W-T-F?). I used to be skeptical about the “git add” for changes and then “git commit”, but I actually find it quite nice: it’s easier to plan a commit that way, and if you don’t want to plan it, you can always just “git commit ” directly. Also “git add -p” is really nice to commit just parts of a file (at last, someone copies some of the good stuff Darcs had had for ages!). Apart from Git itself, it’s cool that there is GitHub, so it’s easy to share your repositories without having to rsync to some web server or similar… not to mention that your project is much more visible that way.

But the World Loanmeter wasn’t the only pet project I was working on these past weeks: I also wrote a simple sudoku solver, demisus, in Ruby. The reason? Writing a prototype of a sudoku solver in a language I’m fluent with, to play with the design and get something interesting and easy to maintain… to rewrite it in Haskell. I have been trying to learn some functional language for some years now, but I never find a “project” that is interesting enough to write some “real world program” in the language and I end up not learning anything. After starting reading Real World Haskell, I really felt like trying to learn the language once and for all, and I figured that a sudoku solver was easy enough to write, something I know enough about, and something math-y enough to be reasonably easy to implement in Haskell.

So, if you’re interested in any of them, you can have a look in Github and even contribute ;-)

• I had to install a ridiculous amount of dependencies, sometimes to go from version 1.1.1 to 1.1.3 of some module. I really wonder if Typo 5.2 really needs those versions.
• When trying to upgrade, it seemed to hang in this line: Backing up to /var/www/virtual/hcoder.org/db/backup/backup-20090223-1843.yml. It turns out, it didn’t really hang, it just takes a good while (and yeah, the file stays at 0 bytes for a long time too)
• I had some permission issues that I had to fix (when upgrading, it tried to modify/copy some files, and it couldn’t)
• When applying the migrations, it died with a really strange error message. It turns out, my version of Rubygems was too old ????

While writing this first post, I see some improvements in the admin interface, although I still can’t see any kind of “preview”. I hope it helps me with my struggle with spam, at least :-/

1. Possibility to “postpone” a task, so it doesn’t appear in the main view for a defined time.
2. Possibility to associate a task to a “person to nag”.

When you have a lot of small tasks to do, and they are not the kind of things you put in a BTS (say, stuff that you have to do that is not really connected to some project’s code) I think these two features are really useful, and I was surprised that no applications I saw seemed to have those. I mean, don’t people have the same problems as me?

That’s why, as I had mentioned, I started writing my own TODO application: I’d have what I wanted, and I’d learn a thing or two about Merb, DataMapper and jQuery. The application has several design limitations that I used to simplify things, like not having any notion of users (single user app without authentication) or supporting only a “title” for the tasks, without any longer description. It isn’t something I really plan to publish for other people to use (I mean, the code is in my Darcs repo, I’m just not going to make a project page for it or anything like that), so I don’t really care how much it fits other people’s needs :-)

As it is a pet project and I didn’t really mind how long it would take to finish it, I started by making some mockup of the application in HTML (+ a bit of Javascript with jQuery), and once I was happy, I started with the actual design and code. I think some parts of the code are nice, and it has some Ajax sweetness, but I admit I haven’t used it yet for myself: only as a kind of underpowered BTS for the application. Maybe I’ll upload some screenshot some day. In the meantime, feel free to download and try it out ;-)

• Make a TODO application that I actually like (I’ll post about it some other day).
• Learn Merb and DataMapper… and jQuery.

The experience have been roughly half frustrating, half rewarding. It’s fun learning new things, but the documentation for both Merb and DataMapper sucks big time so sometimes I spend much more time than I would like figuring out how to make things work. Don’t get me wrong, the reference documentation looks very complete… but there’s no single source of consistent documentation to learn how things are done. And that’s painful. Moreover, apparenly the API has changed several times (at least before 1.0.0, but it hasn’t been that long since), so a lot of recipes or solutions you find on the internet are simply not valid anymore, which just adds up to the confusion and frustration.

Anyway. The client-side piece of the puzzle, jQuery, has proven to be a very handy, clean, easy-to-use-even-for-non-Javascript-wizards, natural way of writing Javascript. I admit I’m a kind of Javascript-phobe, as I don’t really know more than the basics and never has had the need or inclination to actually learn the language (yeah, my bad, but whatever). And yet, I really like jQuery, so there has to be something there. My favourite feature is the selectors: they’re a very clean way to access elements in a page, and add event handlers or otherwise manipulate them. Also the jQuery Ajax features feel really natural and comfortable to use.

The only problem I have had was using the autocomplete jQuery UI feature. I read the documentation, downloaded the appropriate bits from the jQuery website, included everything in my application, but it just wouldn’t work. After a lot of trial and error (and more frustration), I finally could make it work… using the Javascript files from the demo page (js, css) instead of the latest version from the jQuery download page. I think the problem is that the API has changed (the API apparently documents the older version that they use in the demo page), but I couldn’t figure it out reading the source code, so I just used the older, known-to-work version.

I investigated a bit, and it turns out that there’s some bug (apparently related to saving a post as draft, then publishing) that makes the post have an empty “permalink”. When this happens, the link to the blog post looks exactly like the view of the posts for that particular day (say, http://hcoder.org/2008/11/23/ instead of http://hcoder.org/2008/11/23/why-i-hate-rubygems), so Typo decides that it shouldn’t show the comment form.

The bad news is that many posts are fucked now (although I have fixed some of the most recent ones). The good news is that it’s more or less easy to fix. You just have to connect to a “Rails terminal” with the production configuration (with ./script/console production) and do something like this for each post you want to fix:

>> a = Article.find(:first, :conditions => [“title LIKE ?”, “GPG%”])
=> #<Article id: 41, type: “Article”, yadda, yadda, yadda, …>
>> a.title
=> “GPG confusion”
>> a.permalink = a.stripped_title
=> “gpg-confusion”
>> a.save
=> true

Lesson learned: don’t save as draft for now (maybe I should upgrade to 5.1.3, it seems fixed there). Instead, untick the “Online” under “Post settings”, and hit “Publish”. That will assign a default, sane permalink value.

In the same way, I feel that the mere idea of having a programming-language-dependent packaging system is a broken idea. I know it has advantages, and I know that being specific to the language, some things work better or are more flexible, but I just don’t believe in that idea. Why should I use a different packaging system for certain things just because they’re written in Ruby? Why do I, as a user of those programs/modules, even have to know that there’s some Ruby-specific packaging system, that doesn’t integrate at all with my system’s packaging system, and mixing both leads to a mess?

Not only that, but Rubygems in particular is quite hostile to repackaging into a platform-specific packaging system. A lot of people only provide the gems for their software, which are harder to work with than “normal” tarballs. They also use their own conventions for directories, that break the FHS (for example) and basically only make sense in the context of Rubygems. In that sense, CPAN is much better (although I think using it for application deployment is a very bad idea, but that’s a different matter), because at least it installs everything in sane directories, it doesn’t change Perl in any way, and it’s not a special format, just a repository of easy-to-install, easy-to-work-with, easy-to-hack, easy-to-repackage “distributions”.

Why, oh, why?

I have just upgraded Typo. It was slightly traumatic, because at first the blog broke horribly and I couldn’t see anything other than errors 500. To be fair, the change was quite big, because it included also an upgrade to Rails 2 (I was using some older Typo that used Rails 1.2.x), so everything worked better than expected.

I could login as admin, and change preferences and whatnot, and the only thing that was broken was the public view of the blog. I had a look at the logs, and it complained about not being able to find some template for the sidebars. I was very confused, and didn’t know where to starting looking for this. So, obviously, I asked “Señor Google”. He didn’t tell me that much, but someone left me the following hint: if you comment out the call to the helper `render_sidebars` (in the active theme code) solved the problem…. at the price of not having sidebars of course.

So I decided to connect a Ruby/Rails console to the production database, and have a look at the Sidebar model. The summary of what I did is this:

>> Sidebar.find(:all, :order => ‘active_position ASC’).
map {|s| s.active_position}
=> [0, 0, 1, 1, 2, 2, 3, 4]
>> Sidebar.find(:all, :order => ‘active_position ASC’).
map {|s| s.type}
=> [nil, “CategorySidebar”, nil, “ArchivesSidebar”, nil,
“TagSidebar”, “StaticSidebar”, “XmlSidebar”]
>> Sidebar.find(:all, :order => ‘active_position ASC’).
find_all {|s| s.type.nil?}.size
=> 3
>> Sidebar.find(:all, :order => ‘active_position ASC’).
find_all {|s| s.type.nil?}.each {|s| s.destroy}
=> [#<Sidebar id: 1, active_position: 0, config: {"empty"=>false, “count”=>true}, staged_position: nil, type: nil>,
#<Sidebar id: 2, active_position: 1, config: {"title"=>"Links", “body”=>"…"}, staged_position: nil, type: nil>,
#<Sidebar id: 3, active_position: 2, config: {"format"=>"rss20", “trackbacks”=>true, “comments”=>true, “articles”=>true}, staged_position: nil, type: nil>]
>> Sidebar.find(:all, :order => ‘active_position ASC’).find_all {|s| s.type.nil?}.size
=> 0

So, the problem is that there were some (severely broken) leftovers of the upgrade. I just removed them, and everything started working again. Phew!