HCoder.org

Hey there!

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}
=> [#false, "count"=>true}, staged_position: nil, type: nil>,
    #"Links", "body"=>"..."}, staged_position: nil, type: nil>,
    #"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!

After porting Haberdasher to Rails 2, I had forgotten to execute all the testsuites I had (unit, functional and acceptance, with Selenium and Selenium on Rails). The bad news is that they didn’t pass. The good news is that it wasn’t such a big problem making them pass again.

The functional tests failed because of some stupid change in Rails 2. Namely, it seems that now you can’t make more than one request in a single functional test method (bug?). The acceptance tests had some minor problems due to some changes I made in the interface. The rest worked without problems.

Now that everything is ported and working like a charm, it’s time to make some interesting changes. I had been wanting to use a really cool library called RemixUI, made by my former company, Fotón Sistemas Inteligentes, and these days I finally had the chance to use the latest version. RemixUI is a “web widget” library, similar to DJWidgets, MCWidgets and RemixWidgets (all of them available in the Fotón BerliOS page, but unfortunately obsolete), that makes it much easier to write validation, integration between client side and server side, interface improvements with Javascript, reusable widgets/controls, etc.

I haven’t used it that much yet, but I’m really eager to change all the forms and controls in the application to take advantage of the cool stuff offered by RemixUI. The problem now is that the RemixUI gem is not public yet, so I can’t really release the new version of Haberdasher. I’ll try to make them put the Gem somewhere public, so I can release Haberdasher, and other people can have a look at RemixUI.

I’m kind of back to Haberdasher work, so I’m playing again with Rails. However, I’m a very late adopter for many things, and that included Rails because I wasn’t that interested in investing time in learning all the new stuff and porting my applications to the new version.

But the universe had its own ideas about Rails 2.0 and me, so I had some retarded compatibility problems with Haberdasher and the up-to-date rake utility version in Debian. The problems were related to some Rails plugins I was using, and they made me have a look at upgrading to Rails 2.0 from Rails 1.2. It turned out to be really easy to do, the hardest by far was replacing the plugins that gave problems with application code or other plugins (yes, I know that if I was going to get rid of them anyway, I might as well have stayed in Rails 1.2, I just thought it was a good idea to upgrade if I was going to resume Haberdasher development).

To be honest I haven’t really learned new stuff yet. I’m just using the same things I was using, only now powered by Rails 2.0. A couple of improvements/clean ups in syntax, deprecated code removal and similar, but nothing big yet.

The other news is that now that I have a working Haberdasher again, I’m making some changes I had in mind since months ago, namely adding some user preferences “framework”, and adding the ability to assign a copyright notice to the patches (with a configurable default notice per user, hence the user preferences). I haven’t published this work yet, but I plan to do it in a couple of days, after updating the demo installation and checking that everything’s alright.

Haberdasher has been quite silent in the last months. I wanted to add some things, but I never got to actually devote some time to them, partly because of my work on dhelp.

However, yesterday I added something that I wanted to add long ago: some simple changes in the RSS code, to make it actually useful. Namely, (1) now the pre tag is used for the patch contents, so they are readable, and (2) each news item adds the name of the program the patch is for (it used to be just the patch name/description, which is not that descriptive if you don’t know which program it’s for of course).

Those changes are of course updated now in the demo installation, so go and have a look at the new patches feed or some application patches feed (in this case, my fake PDF::Writer patches).

Comments welcome :-)

As part of my QA work on several projects, months ago I was looking for a continuous integration server. I looked at several, but most of them seemed really scary judging from the documentation. I finally went for CruiseControl.rb, and I have been really happy with it all this time. It’s a really nice, very simple continuous integration server written in Rails. I had it up and running before I even understood how to install the others I looked.

Even though is a really cool piece of software, I was missing some better test result reporting. It was actually there, but only for Rails projects, and unfortunately we don’t have any Rails (or Ruby, for that matter) projects at work. So, I just had a look at the sources to see if I could hook my own reporting there, and the code turned out to be impressively easy to understand (especially taking into account that it’s a rather non-standard Rails application, as it has builders running as daemons, it doesn’t really use a database, etc).

The result is a patch for CC.rb, already submitted to their BTS, that adds a plugin-based result reporting, that can be extended to understand any kind of testsuite. It’s basically a parser that collects all the test passes and test failures from the testsuite output log.

Also, the other day I had another need, which was even easier to make because it could be implemented as a simple CC.rb notification plugin. It depends on the above patch, and it collects all the bugs in the current build, searches in the history of the project, finds out who made the commits that produced the regressions, and bugs all those people by e-mail, pointing out which failures were supposedly made by them, and which build they started failing (so it’s easier to locate the offending code).

It’s not perfect, and it cannot be, but it’s a nice addition to continuous integration. This notification plugin is not public yet, but it might be in the future (especially if they accept my patch as part of upstream), so stay tuned if you’re interested.