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.

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

After thinking a lot to the future of that tiny ORM (which is actually very small, unfinished and questionable) I came to a conclusion: Class:DBIx is in the place and just rules. That’s an amazing ORM and is really a great module to use. -I’m aware what follows in that blog entry may sound contradictory- I work daily with Ruby on Rails, but I just love Perl and the goodness of CPAN, I love writing Perl code, I love writing Perl modules ; I also find Rails’ORM amaizingly well designed, easy-to-use and scalable. I like the choices made, well, I like how you can feel your database through that object-mapping abstraction layer that ActiveRecord provides.

My point here is not to discuss Class::DBIx, but rather to underline how Rails’ ActiveRecord is something worth looking at, and something - I think - Perl lacks.

I may be wrong, but I feel like some Perl developers around could agree, I hope. I also hope I won’t trigger the anger of someone involved with Class::DBIx, which, let me say it again, is a great module.

My plan here is to take the ActiveRecord API, and try to upgrade Coat::Persistent, piece by piece, in order to get as close as possible to it. That’s an exciting challenge, and could give me enough intellectual food for the next months.

I may be targetting something too large for me, I may be taking the wrong path, but I feel like following the spirit of Perl taking that direction : There’s more than one way to do it, isn’t it?

WWW::Mechanize is good. But if you want to be as close as possible to a real browsing, the best thing to do is to drive an instance of a real browser. There comes in play Mozilla::Mechanize and Win32::IE::Mechanize. Both of them use the browser they implement to do the work, and that’s pretty great.

Even better : you want to support javascript and simulate real clicks done in the webpage? Mozilla::Mechanize::GUITester does the job. The CPAN is really a gold-mine, you know.

I was happy, I could use several agents to run my tests, that was what I wanted. But when I started writing my tests suites, I realized I was about to write the same suites for each agent I wanted to test. That sucks. Do not repeat yourself, you know, the mantra. Hmm.

I got the idea of a small test-wrapper that could handle the suites and run them with the agent you like. After a couple of experiments I came to something I was happy with, and published the first version, it’s called Test::WWW::Mechanize::Runner.

As you can read in the documentation, you write your test in a module that inherits from the runner; each of the test receives the agent in its argument list. Once the suites are defined in your module, just use it in your test script, set the agent you like and call the run() method.

For instance, say you want to run your “GoogleTest” suite with IE and Mozilla :

test-google.t:

use GoogleTest;
GoogleTest->init('msie');
GoogleTest->run();

GoogleTest->init('mozilla');
GoogleTest->run();

I might release a documentation soon, in the meanwhile, you can check the teaser.

• required which tells the attribute must not be set to an undefined value
• trigger which lets you define a code reference that will be called whenever the attribute is set

I’ve also rewrote the main documentation, taking bits from Moose’s and reorganizing the whole POD so it looks better. I’ve also removed the dependency to Scalar::Util::looks_like_number (which was used in 0.1_0.5 by Coat::Types) because it appears that function was not shipped with Perl 5.8.0. As my motto for Coat is the more compatible, the better, I decided not to use it anymore.

There are 129 tests now in the source tree and I think Coat is close to something stable. I welcome test reports and feedback, I hope I will be able to release a non-developer release soon.

While I’m at speaking about Coat, let’s say for the record that I’m also working on a persistence layer for Coat-built objects. The challenge here is to provide an ORM module that behaves quite the same as the one provided with Ruby on Rails : ActiveRecord. I’ve made a prototype that works pretty well, even if not complete. Maybe more about this later.

Stay tuned (and don’t forget: use your coat when it’s rainy outside!).

The version provides all the important features I wanted to provide with Coat, namely:

• a basic meta-class : Coat::Meta that provides class introspection
• a default root object : Coat::Object that provides a default constructor
• support for Moose’s attribute declaration with “has” with default values and type constraints validation
• support for hooks : before, around and after modifiers

Next target is to port test suites from Moose to ensure we actually are compatbile together…

I was honoured to be asked to share the Moose repo, and I thank you Moose people very much for hosting Coat like that, I hope this is the begining of long-and-happy collaboration.

Coat continues to get stronger, the last revision I commited todaytonight was about the new Coat::Meta class, that takes care of everything regarding, well, the meta layer. The last big thing to address is the attribute types handling for which I plan to write Coat::Types. I’m not yet sure how I’ll implement it, I want to keep it simple although it has to be efficient and well designed.

The history is simple: I had to write an API at work, I planed to write it with Moose. It was a good idea until I found out the company I work for was planning to release the code to their customers, meaning some of them under Windows systems.

Forcing Moose in the deployment was not possible according to my co-workers, they didn’t want to take a risk to complexify the deployment procedure with such a huge set of dependencies.

Then I started thinking about what I liked in Moose and realized the stuff I used didn’t justify such a huge set of deps. Basically I use the accessors automagic, the inheritance and the hooks. “Why not having a tiny module that provide that ?” I thought.

Then I got caught in a 3-days-evil-coding-whirl that has just unleashed me. Coat is born.

I know, I know, there is Moose::Tiny somewhere, bu it was too late when I found out. Coat was near to be released and nothing could stop it.