HCoder.org

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.

Too funny not to share :-)

I always thought that Smalltalk would beat Java, I just didn’t know that it would be called ‘Ruby’ when it did.

From La Cara Oscura del Desarrollo de Software.

Dhelp’s new release is coming along nicely. In the last days I have fixed a couple of bugs in dhelp_parse’s rewrite, and I think it’s now ready for upload. The new package closes 28 bugs, which is more than half the current open bugs for the package.

I have warned the current maintainer and the debian-doc mailing list, so I hope to upload the new version in a couple of days…

In the last days I have gone back to working on dhelp, a Debian package for documentation indexing and search. Months ago I had started rewriting dhelp_parse, the only program in the suite written in C, in Ruby.

The rewrite was almost done, but the program wasn’t tested much (some modules had unit tests, but the program itself didn’t), so I found a couple of big bugs easily :-D Now it looks better, so hopefully I’ll be done soon, and I’ll upload the new package to Debian so people can start testing it.

In the last days I’ve had some time to devote to Haberdasher. Finally the domain is up and running (haberdasherhq.org), currenly pointing to the RubyForge project page.

I’ve also set up a new screenshot gallery, I’ve the Darcs repository online and soon I’ll have a demo online, so you can try it out.

On the code side, I’ve updated Rails to the latest 1.2.x, have updated all the plugins, and I have added a very simple tag system. I’m also experimenting with a new web widget system, more news when I have something interesting to show.