Friday, August 19, 2011

Beautiful Riga

This year Perl YAPC::EU::2011 conference brought us to Riga : what a nice discovery!

I barely knew about the existence of this city (apart some vague remembrances of having seen this name when reading Jules Verne's Un drame en Livonie, long long time ago). Now I will recommend it to friends.

Riga has a lot of beautiful buildings, mostly from end of 19th-beginning of 20th century. The Art Nouveau museum has an interesting film explaining various architectural substyles during that period; then you can easily recognize them when walking in the city. By the way, walking is a pleasure because there are large pedestrian areas through the old town, and several beautiful parks just around that center. There are various churches of different eras and styles, and a tremendous romantic organ in the Dom Cathedral, with a concert every day at noon !

I discovered interesting composers at the Sacred Music Festival (with high-quality choir, orchestra and soloists); and discovered many interesting painters at the Latvian National Museum of Arts.

So Riga has many advantages of a capital with rich cultural life, but seemingly without too many of its inconveniences : most buildings look fresh and unaffected by pollution, I didn't see any traffic jams, prices are reasonable, etc. Maybe that's the positive aspect of Soviet occupation, that the city was preserved so many years from wild capitalism...

In short, not only was YAPC a very nice conference, it was also the totally unexpected pleasure of a very interesting touristical exploration (albeit too short).

Thanks to the YAPC organizers for having brought us there!

Thursday, August 18, 2011

Why not bless objects into … metaobjects ?

Yesterday, Jesse Vincent gave a talk at YAPC::EU::2011 about the future of Perl; among many interesting things, he mentioned the idea of adding support for a metaobject protocol , directly in Perl5 core.

This immediately got me thinking, because in the past weeks I have been struggling with a design problem that is closely related to that topic.

My project was to add a layer of meta-information in version 2 of DBIx::DataModel, so that the client code could navigate through the available tables, joins, etc. available within the current datamodel. Since tables and joins are classes, it would seem natural to use class methods for navigation in the metamodel. However, in Perl there are no separate namespaces for class methods and instance methods : any subroutine declared in a package can be called either way; it's the code in the subroutine that has to inspect its first argument to know if it was called as a class or as an instance, and then take “the appropriate action”. So in short, the problem is :

  • we want each table to have an C method;
  • a table must be a class (so that rows from that table can be blessed into something)
  • a call to $row->associations() makes no sense, so there is no “appropriate action” (except throwing an exception, which is only halfway satisfactory)

The design decision for DBIx::DataModel was to create a separate set of metaobjects. When a Table() is defined, it simultaneously creates a subclass of DBIx::DataModel::Source::Table, and an instance of DBIx::DataModel::Meta::Source::Table. The class has a method to reach its metaobject, and the metaobject has an attribute to know which class it is attached to. Now the associations() method is defined in the metaobject, not in the subclass, so rows are not affected. It works, it's pretty clean in the separation of concerns, so I'm almost happy.

What would be really, really great, however, would be to be able to bless an object directly into its metaobject. Unfortunately, Perl won't let you do that : it raises an exception “Attempt to bless into a reference”. This makes sense, because Perl needs to know the name of the symbol table where it will start looking for methods. So in order to fool the compiler, let's put in a stringification operator :

package Meta;
use overload '""' => sub {my $self = shift; join "::", @$self};
sub meta_method {print "I'm a clever meta-method for $_[0]\n"}

package Foo::Bar;
sub m {print "hello from Foo::Bar\n"}

package Bar::Foo;
sub m {print "hello from Bar::Foo\n"}

package main;
my $FB = bless [qw/Foo Bar/], 'Meta';
my $BF = bless [qw/Bar Foo/], 'Meta';
my $fb = bless {}, $FB;
my $bf = bless {}, $BF;
$fb->m; $bf->m;


It works! This code compiles and runs! But it doesn't bring us very far, because stringification occurs at blessing time, which is too early : ref $fb returns the string 'Foo::Bar', not the metaobject; so it is not possible to call

(ref $fb)->meta_method


This would require a change in the perl5 compiler, allowing bless to take objects as second argument, instead of just strings. Conceptually this does not seem to be infeasible; it's quite similar to what happened a couple of years ago with exceptions (initially exceptions were just strings; now they can be objects too). And if we have that, we can build a metaobject protocol, we can build delegation chains à la Self or Smalltalk, etc.

Unfortunately, when I came to this point yesterday, it was too late to grab one of the perl5 core guys to discuss that idea. So let's do it online : what do you think of this proposal ?

Tuesday, August 16, 2011

about MsOffice::Word::HTML::Writer

Yesterday I gave a lightning talk on MsOffice::Word::HTML::Writer, a module to produce documents for MsWord from HTML content. To anybody interested, here is some more info :

  • the module only needs Perl, and therefore can run on a server; it doesn't need MsWord to be installed (actually, that's the whole purpose of that module).

  • it was written for the needs of Geneva courts of law, where we needed to generate thousands of documents every day, from hundreds of models, with libraries of reusable content parts, with fusion of complex datastructures ... but the resulting docs must be editable in MsWord.

Other technologies considered, but rejected, were :

  • remote control of an MsWord instance, through a OLE connection. That's what most other courts do, but it only works on a local workstation : you could hardly do the same on a server, first because you would need to install MsOffice, and second because this architecture is not reliable enough : the MsWord instance is a bottleneck, it might break, or it might suddenly put a popup to ask the user for something ... except there is nobody to answer if running on a server. So this approach can be considered if you have a heavy application, deployed on everybody's PC; but not for a Web application.

  • generating RTF, using some templating tool : this works on a server, but authoring models can be tricky (esp. it is not obvious to factorize reusable parts).

  • generating XML, either in ODF (open format used by OpenOffice), or in OOXML (Microsoft proprietary format) : here the main problem is authoring, because both XML specs are huge, so you really need specialists to produce your models

  • generating ODF from : well, ODF can be read by MsWord, but many features are missing. Besides, OODoc uses a programming approach, not a templating approach, so it's harder to delegate authoring of models to people who are not familiar with Perl.

MsOffice::Word::HTML::Writer works by assembling HTML content (the main document, the headers/footers, other resources like images or CSS stylesheets), and then packaging the whole thing as a single MIME/multipart file. Model authors just need to know HTML, so it's easy to build an authoring team; and if you have a good templating framework, it's also easy to build a library of reusable content parts.

Sunday, August 14, 2011

Bad luck with Riga trip

I really seem to have bad luck with the trip to Riga for Perl conference YAPC::EU::2011.

I had booked my flight and hotel several months in advance. A couple of days ago, I received a mail telling that the hotel was overbooked, they had made a mistake, and sent me to another place.

Now today, my flight from Geneva got delayed by 90 minutes, and I missed the last flight to Riga, so I'm sleeping in Brussels.

There is a flight to Riga tomorrow morning, so if nothing worse happens, I should still be in time for my talk

Monday, August 8, 2011

DBIx::DataModel 2.0 is on the way

DBIx::DataModel version 2.0 is on the way.

It will be a major refactoring, introducing a metaobject layer, choice between single-schema or multi-schema mode, support for table inheritance, for arbitrary join clauses, for bulk updates and deletes; the API has been made more "perlish" (replacing camelCaseMethods by methods_with_underscores). A dev version is already on CPAN; the code seems to be quite stable now, but the distribution is still lacking in documentation and tests, so I'm not sure it will be fully ready before YAPC::EU::2011 ... but at least the slides are ready (see if your are interested).

The last major refactoring was version 1.0 in 2008, and the first published version was 0.10 in 2005, so I seem to be following a 3-year schedule !

I really hope that DBIx-DataModel will get some more visibility, because it has some features that are quite original in the (big) world of Perl ORMs, and could probably be useful to other people. For those of you who will be in Riga : come at the talk !

Friday, August 5, 2011

a municipality called Perl

I just discovered accidentally that there is a German location called "Perl", close to the Luxemburg border.

Maybe a place to consider for the next YAPC ?,_Saarland

Friday, June 10, 2011

Perl dualvar is useful, after all

For many years I had been intrigued by Scalar::Util::dualvar : why would one store both a number and a string within the same variable ?

Yesterday I finally found a situation where dualvar was just the perfect answer.I was doing some refactoring in DBIx::DataModel::Statement : each object from this class has a status, that goes through steps "new", "sqlized", "prepared", "executed". Originally his had been coded with plain strings; but the problem with strings is that they are not ordered, so I was considering a change to something like

use constant {NEW => 1, SQLIZED => 2, PREPARED => 3, EXECUTED => 4};

However such codes are not user-friendly, so when generating error messages I would need to translate them back into strings. Moreover, that change was not backwards compatible. So dualvar came to the rescue :

use constant {
NEW => dualvar(1, "new"),
SQLIZED => dualvar(2, "sqlized"),
PREPARED => dualvar(3, "prepared"),
EXECUTED => dualvar(4, "executed"),

Now I can write things like

$status >= PREPARED
or die "can't do that operation when in state $status";

Friday, January 14, 2011

good luck to Plat-forms 2011 Perl teams

I just learned from Gabor Szabo's blog that the 2011 Plat-forms programming contest is taking place next week, and that 3 excellent Perl teams are participating. This is great news !

In my last blog entry (August 2010 ... so long ago!), I mentioned the importance of that contest for the image of Perl outside of our community. Within a couple of months, when the reports will be published, IT specialists from all over the world will get a strong signal that Perl is alive and produces good results.

I very much enjoyed participating in the 2007 edition : this was a big stress, but also an enriching experience, not only on the technical aspects, but also on the collaboration skills under strong pressure. Unfortunately I could not register for the 2011 edition, because at work we had to prepare a major organisational change for 01.01.2011, which left us absolutely no time to think of anything else (not even to blog .. see above!).

So, all the best for the three Perl teams, thanks for having registered, and I'm sure you will show to the world that our technology is excellent for productivity, conciseness, flexibility and so much more.