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.

• 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 ;-)

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 ;-)

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!