sukria.net

There are more and more people that use Backup Manager daily, for work or personal purposes.

I’m glad to see that, and want to to give the project a better shape for external eyes.
As explained in a mail sent to the users mailing-list, this could be done in two ways: a logo and a website design.

The project is looking for volunteers for a new website design (could be a Wordpress skin) and for a logo. We’ve been thinking at choosing a squirel or a beaver as a mascot for the project.

Submit your proposals either to the users list or to me directly.

A new release of Backup Manager has been published. This release closes a bunch of bugs reported in Debian and in the official Bugzilla.

The release notes are available here.

Here is the announcement made on the user mailing list.

I’ve also uploaded a new Debian package to sid, in order to provide 0.7.8 for the unstable distribution of Debian. Reports are welcome (but bug-related ones are prefered, if possible in the official Bugzilla rather than in the Debian BTS).

Hey planet, it’s been a very long time since I took my e-pen to write something down here, my work is taking pretty much all my time nowdays. Anyway, it seems that there is sort of a polemic rising here and there about RubyGems and its packaging philosophy.

I’d like to take that opportunity to contribute to the debate with the experience I had at Yoolink. Yes, we provide Ruby on Rails applications and are defacto dealing (or trying to) with Ruby and its gems.

Wouter enlightened the main reason why it’s such a mess to put into production a Rails app and to maintain it : the Ruby on Rails ecosystem is unstable. If you start writing your app, there are very big chances that when it gets mature for production mode, one or more of the Ruby libs you depend on will have a new version. And sadly, chances are there too that one of those libs will provide an API change.

This can happen in a lot of places in a Rails app, because of its modular structure: plugins, gems or even Rails’ core upgrades (try to upgrade a real-working Rails app from 1.x to 2.x if you like tricky games).

I agree with Joss when he said that Debian packages and Ruby gems are not designed for the same purpose, the latter are for a developer ecosystem and the first suitable for long-working production ecosystems.

That’s why setting up a complex Rails app in production is a nightmare : no Debian packages for all your Ruby needs on the first hand and API-unstable and hard-to-upgrade gems on the other hand.

At Yoolink, the only working way we’ve found to maintain in production our Rails apps is to freeze pretty much every Ruby-thing we can. Our production servers are then Rails/Ruby free (nothing installed system-wide) and the apps provides all their Ruby dependencies in their vendor/ directory. You can’t do that for native gems but that works for 90% of a random Rails app’s dependencies.

To conclude, I’d say that most of these issues come from the philosophy of the Ruby/Rails people : they don’t fear to change anything they want from one release to another, just take a look at the gettext support in Rails 2.2 and you’ll understand what I mean….

It’s like they don’t even take in mind that people are now using their stuff, in real world, with customers relying on their apps. It’s not a pet project anymore guys, if Rails want to remain the killer app it is, it will have to be someting stable and maintainable.

If you’re using (Apache2, mongrel and mod_proxy) for your Rails application you might have realized that when a bad HTTP request is performed over your app, mongrel triggers an exception :

$ mar nov 04 14:45:44 +0000 2008: HTTP parse error, malformed request (127.0.0.1): #

At first glance, this could sound logical that mongrel refuses to serve an invalid request, but if you’re a service provider, your first rule is: Never give up on anything. Rememeber : you’re on the Internet, you will have some junk in the hands eventually.

So, as a service provider, you wan’t your web application to be as pragmatic as possible: if an invalid request comes into play, let’s try to sanitize it so it can fallback to something understandable by mongrel.

This specific issue happens when you want to access a Rails app with an invalid/incomplete URL-encoded string in the query string, for instance :

var=%ZZ

The following RewriteRule Voodoo replaces any invalid % snippets with their encoded form (%25):

RewriteCond %{QUERY_STRING} (.*)%([^0-9a-fA-F]|[0-9a-fA-F][^0-9a-fA-F]|$)(.*)
RewriteRule (.*) $1?%1\%25%2%3 [N]

Quoting YoolinkPro:

We are proud to announce that Yoolink Pro’s Beta test will officially start at the Web 2.0 Expo in Berlin, the 21st of October. Come and meet us there to discover the service!

More than a hundred companies signed in for the Beta test. We are currently sending Beta test keys. Sign in to get yours in the upcoming weeks.

A new version of Coat is available on CPAN, it’s the version 0.333 which provides 3 important bugfixes:

• You can now safely use multipe coercions for the same subtype (thanks to Rached Ben Mustapha for discovering this issue)
• A major bug was found by Andy Yatz in Coat’s inheritance mechanism. This bug is closed in this version too.
• Another bug was closed, concerning the built-in subtype “Object”, whose validation code was broken.

I’m now focusing on porting as many Moose tests as I can to improve the test-suite of Coat.

A new release of Coat is available on the CPAN: Coat 0.331

It fixes a bug that appeared recently, when I added the Moose-compatible type constraint mechanism, when an undefined value was set to an attribute, it was set to 1 instead of undef.

This bug has been found by Stéphane Pontier who was experimenting with Coat::Persistent, thanks to him.

I’ve also cleaned the test-suite in order not to use Test::Exception and DateTime so the test suite can run smoothly on most systems.

It’s been a looong time since I blogged here. Perhaps I should write more frequently so you won’t start thinking I died silently ;).

I’m not dead. It’s just that I’ve started a company a couple of months ago and that does take a lot of my time. It’s pretty exciting, - as you can imagine - we’re using Debian everywhere and the team is great. I’ll write another blog-entry about that later.

In the meanwhile, I’m on holydays for a week, and I plan to squash my TODO list:

• Backup Manager (a couple of bugs have to be fixed)
• Electricsheep (a new upstream release is available)
• My Perl modules deserve a couple of maintenance too, like Coat::Persistent

A new major release of Coat - the diet-Moose - is now available and provides support for type constraints. It’s now possible to define types, subtypes and enums as well as setting up coercions in Coat classes, in the exact same syntax as with Moose.

I’ve uploaded a new major release of TinyMCE into sid, the package jumps from the 2.x branch to the new 3.x one.

For the record, packages that use TinyMCE should rather depend on that packge instead of shipping the sources itself.