ldami

Beautiful Riga

2011-08-19T12:41:00.002+02:00

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!

Why not bless objects into … metaobjects ?

2011-08-18T06:32:00.006+02:00

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 ?

about MsOffice::Word::HTML::Writer

2011-08-16T05:09:00.002+02:00

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 http://search.cpan.org/dist/OpenOffice-OODoc/ : 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.

Bad luck with Riga trip

2011-08-14T20:51:00.002+02:00

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 http://yapceurope.lv/ye2011/talk/3410.

DBIx::DataModel 2.0 is on the way

2011-08-08T22:06:00.002+02:00

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 http://www.slideshare.net/ldami/dbix-datamodel-endetail 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 !
http://yapceurope.lv/ye2011/talk/3411

a municipality called Perl

2011-08-05T15:39:00.002+02:00

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 ?

http://en.wikipedia.org/wiki/Perl,_Saarland

Perl dualvar is useful, after all

2011-06-10T04:05:00.002+02:00

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";

good luck to Plat-forms 2011 Perl teams

2011-01-14T19:26:00.004+01:00

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.

plat_forms 2010/2011 : call for Perl teams

2010-08-26T06:18:00.002+02:00

A new edition of the Plat_Forms programming contest is going to take place in end 2010 or beginning of 2011 : see http://www.plat-forms.org/2010/plat-forms-in-2010 .

The first edition took place in 2007 and our Geneva team on Catalyst was winner of the Perl track (http://use.perl.org/~dami/journal/33559 ). Unfortunately we will not be able to participate again this time; but I wish that another Catalyst team will be present. Reports from that contest got significant coverage in specialised press , and can play an important role in propagating a positive image of Perl. See for example the August 2010 issue of the prestigious "Communications of ACM" (http://cacm.acm.org/magazines/2010/8/96637-platforms-is-there-one-best-web-development-technology/abstract , full text available at http://page.mi.fu-berlin.de/prechelt/Biblio/platforms07-cacm-2010.pdf ); the conclusion reads :

Is Perl outdated? No. In contrast, the small size of the solutions and their good modifiability suggest that Perl may be a particularly strong platform with respect to maintainability.

So, Perl programmers, please build up teams to participate in the 2010/2011 edition!

rakudo perl6 runs on win32

2010-06-13T21:37:00.002+02:00

The French Perl Workshop 2010 had a whole track on perl6; so before going there, I quickly downloaded the parrot and rakudo packages for win32 from sourceforge, with the intent of playing with perl6 during the (long!) trip from Geneva to Calais. I've been reading and hearing about perl6 for some years, but so far I had never taken time to give it a try.

Alas, the distribution did not work, complaining for a missing DLL that I didn't know where to find. So I had plenty of time for other, more urgent tasks during the travel, but sadly I hadn't written a single line of perl6 yet.

At the conference, I started telling my neighbour about this misadventure ... and it turned out that this neighbour was François Perrad, the author of the parrotwin32 package ! François quickly found out the problem with the distribution; we fixed it manually on my machine, and François is going to issue a new distribution within a few days.

So, because of this nice coincidence, I finally was able to write my first "hello, world" program in perl6.

The next step will be to try to do some real work ... but for this I need a database connection, and as far as I know, the DBI redesign for perl6 by Tim Bunce is not complete yet. I talked about this to Martin Berends, who had given several talks on perl6 during the day .... and nice coincidence again, it turns out that Martin has a "fakedbi" project that implements a subset of Perl DBI , ported from perl5 to perl6 !

So after these lucky coincidences, my only problem is that I no longer have any excuse for not looking seriously at perl6 !

slides for the perl french workshop 2010 : ORM and EDM

2010-06-13T12:11:00.002+02:00

My slides for the French Perl Workshop 2010 are online :

Gestion documentaire pour les tribunaux genevois : Geneva courts of law rely more and more on Perl for all their information systems. This talk presents three facets of electronic document management : storing justice decisions, preparing projects of documents, and a project for building a paperless justice file, combining webdav and modperl.
DBIx-DataModel in detail : DBIx-DataModel is an object-relational mapping framework for Perl5. Schema declarations are inspired from UML modelling. The API provides efficient interaction with the DBI layer, detailed control on statement execution steps, flexible and powerful treatment of database joins. More on http://search.cpan.org/dist/DBIx-DataModel.

A testimony of Perl efficiency

2010-06-05T11:00:00.003+02:00

Within our team, the person who so far was our specialist in front-end javascript / ajax recently took up a new project involving quit a lot of back-end Perl programming (Catalyst controllers, data validation, database and ORM, etc.).

Now at the middle of the project, she just announced that the initial effort estimate would be cut by about 40%, because she discovered that Perl and its libraries were easier to learn than she expected, and because Perl data manipulation facilities are surprisingly powerful.

Hear that message, you all IT managers who only swear by Java !

talk proposal for MST

2010-05-20T05:20:00.007+02:00

So people are voting for MST's forfeit for not having posted a blog during the last month.

My own last blog dates back to october 2009, so I don't really feel like I'm entitled to say anything on anybody dropping the ironman contest. But the idea is fun, and it gets me blogging again, so let's participate !

What I would be most delighted to hear would be if Matt could compensate for my poor sense of marketing and talk about Ten Reasons to adopt DBIx::DataModel :-)

But for a wider audience, I'd vote for a jump into the future : what about something like Initial design notes for perl7 ?

Initial design vs. maintenance and refactoring

2009-10-29T04:18:00.005+01:00

As previously mentioned in this blog, our team is busy rewriting a complex application from Cobol to Perl.

While studying the old Cobol code, I often discover some areas where the initial design was well-thought and well-organized, but later became blurred and confused over 20 years of maintenance. So part of our analysis task is to do some archeology, trying to understand the historical layers, and to sort out what is still relevant to the current needs of our users.

Unfortunately, the same phenomenon also starts appearing in the Perl code ! Some parts were written two years ago, and then had to evolve for various reasons ... and sometimes the initial design becomes blurred in this process.

One may think that when this happens, it is because the initial design did not have the proper abstraction / parameterization hooks to make it easy to extend. But sometimes when doing the initial design of a component, you don't have a complete picture yet of what is going to surround that component ... or the requirements may have changed because this is a long-term project, and life doesn't stop while we are working on this application. So what is really needed to keep it clean is constant refactoring.

The problem is that maintenance operations do not have the same metrics : maintainers are evaluated by how many tickets they solved and how long it took; so there is a natural tendency to just "get it to work". Spending additional time on refactoring operations brings no immediate reward : users won't see a change, managers won't understand why you need to revisit code that was already written, and there is an additional risk of introducing regressions.

It's easy to understand that on a collective level there would be some rewards on the long-term (better maintainability, cleaner architecture, etc.) ... but on the long-term the maintainer will probably have gone to another project !

how to reconcile audits and agile development ?

2009-10-17T10:29:00.006+02:00

According to recommendations recently emitted by the Swiss working group for IT government audit (Swiss chapter of ISACA, international Information Systems Audit and Control Association), every important IT project in Swiss government should have at least 10 documents ready for the auditor (among about a hundred kinds of documents defined by the Swiss project management method Hermes ) :

1. Feasibility study
2. Specifications
3. Cost effectiveness analysis
4. Integration into the IT environment
5. Requirements
6. Concept for an internal control system (ICS)
7. System architecture
8. Tests (test plan and documentation)
9. Acceptance by the user
10. Final assessment

The recommendations explicitly insist that this list also applies to "new so-called 'agile' development methods".

For our Perl project at Geneva courts of law, this means that we must produce such documents to be ready for occasional auditors. The problem is, that the Hermes method was mainly inspired by good old waterfall development methods on mainframe computers, and some of the documents listed above just do not make much sense in our context; so instead of helping to better structure and organize the project, they just represent an additional burden.

For example, some parts of the application start in an exploratory way, without formal specifications, and are progressively shaped into working functionalities; tests are not planned in a document, but written in a galaxy of test files; etc.

I guess that the pressure for formal deliverables in project management is probably stronger in government than in private companies, but nevertheless people doing big Perl projects in any context probably also have at least some of such constraints. Any testimonies on that ?

I don't hate the stash ... but I loathe the session.

2009-10-06T21:11:00.007+02:00

A couple of days ago, John Napiorkowski asked : Does Anyone Else Hate the Stash?

True enough, the stash in Perl Catalyst is a big bag in global memory. Any method along the chain can read or write into that bag. Then you pass the whole thing to the Template Toolkit (TT), that integrates the Catalyst stash into its own stash, and again any template fragment can read or write into the TT stash. So when studying one particular component along the chain, it is indeed sometimes hard to track what is in the stash at that point, and where the data came from. I frequently need to resort to the perl debugger to sort out such situations.

Nevertheless, I don't hate the stash, because it is sooo convenient to let various software components collaborate at little cost. Setting up a more controlled way of passing information between components would be quite tedious and would imply more maintenance. It is like when having several humans in a team : if collaboration is harmonious, it leverages some multiplicative power; if not, people start treading on each other's toes, and the global result is unsatisfactory. A simple step for ensuring harmonious collaboration is to partition the stash namespace through additional levels of hashrefs (same principle we use on CPAN for avoiding collisions between module names).

Furthermore, global memory in stash is not too risky because it is very limited in time : at the end of the request the whole stash is cleaned up. Unfortunately, there is something much worse than the stash : the session !

Some colleagues tend to like putting stuff into session storage, because it's easy to program sequences of requests without having to propagate state through URL parameters or JSON data. I try to avoid it as much as possible because :

data in session storage is likely to produce unwanted "action at distance"
the URL API is no longer RESTful (calling the same URL with same parameters might yield different results)
there is a cost in serializing / deserializing the session data at each request
session data is limited in size
so session data is not appropriate for storing recursive datastructures of unknown sizes

Programmers a tempted by the easy aspect of session data, but are not always conscious of the limitations above.

YAPC presentation styles

2009-10-03T19:00:00.000+02:00

One personal comment I got from the YAPC::EU::09 Survey results was : "Split slides so they contain less text". Well, while attending several talks, I felt exactly the reverse : I wished the speaker had condensed slides so they contain more text !

Finding the right balance is really a difficult question. It is true that I have a tendency to fill slides with a lot of material, in order to exploit complementary channels : while my voice gives the general idea, or emphasizes a particular point, the slide can convey more detailed information, and people in the audience can grab more content if they are especially interested in one particular aspect.

Probably I like this style because it corresponds to my own way of learning. When I was at school, at a time where beamers were rare and expensive, most teachers used physical transparencies. Some of them had the habit of putting the transparency and immediately hiding it with a piece of paper; then they would progressively uncover the slide, one point at a time. I hated that habit, because I was forced to think at the same speed as the teacher. If I see the global picture at once, I can immediately choose which points seem more important to me, and focus on them, maybe already preparing a question, or think back at what was said before, or anticipate what is probably going to be said next. But if the teacher dictates the rhythm, and decides to pause for 5 minutes on a point which is important to him, but not to me, or decides to quickly skip over a detail which I need to elaborate in my head, then I'm in trouble.

The modern way of uncovering slides one point at a time is the Takahashi style (lots of slides, very few words, huge font), which seems much praised in the Perl community. I must admit that I was quite impressed the first time I saw a presentation in this style : it is quite efficient for a lightning talk, or to create some suspense at a particular point in a presentation. However, if many speakers adopt this style just out of fashion, without deliberate thinking about which effect they want to achieve, then at the end of the day it becomes quite boring, and I feel like having watched several hours of videoclips. After such a day I don't really remember what were the highlights.

Design patterns, or why Java needs external crutches

2009-09-24T21:17:00.005+02:00

In my last blog about architecture and design I promised to come back on the topic of design patterns. This term was coined in a famous book that proposed a catalogue of "Elements of Reusable Object-Oriented Software", and became a best-seller in the Java world (usually referred to as the "GoF" book, for "Gang of Four" authors). Feeling the golden ore, all editors quickly produced a whole line of similar books, where patterns were adapted to various domains and languages : for C##, for Ruby, ..., etc. I almost expected to see patterns books for assembly code and for Befunge, but these never came out !

So what about patterns for Perl ? To my knowledge, no major editor published any book on that topic, which is kind of surprising because one would think that there is some money to make. However, Phil Crow privately published Perlish patterns (cheeply available as e-book), which is really worth reading; Phil proposes the following explanation in his introduction :

Eventually, I came to understand that there were several reasons why patterns were never as enthusiastically embraced in our community as they were in others. Some of the patterns just apply new names to common techniques. Some are represented in Perl's core, so we don't think much about using them, at least in their normal forms. Some apply better to languages which focus on object orientation.

I very much agree with this analysis. The original GoF book was refreshing to read, but when programming in Perl I never think in terms of those patterns, because the standard language features plus some common CPAN modules answer most of my needs for structuring my programs, even when assembling large bodies of functionality.

The fact that Java is so verbose, and that everything has to be an object, results in code that is often spread among lots and lots of classes. So to condense that information, it is no surprise that Java programmers need other abstractions like "patterns", so that they can think in terms of larger units. For the same reason, they also need sophisticated tools like Eclipse for navigating through the class hierarchy, and they need costly tools like Rational Rose to see and design the big picture, and generate code skeletons. I'm always surprised to hear such tools presented as strenghts of the Java world, while to me they are just necessary consequences of the way Java code is layed out.

In standard Perl, we have hashrefs and arrayrefs, we have closures, multiple inheritance, namespace manipulation primitives, dynamic classes and dynamic methods, functional grep, map and other List::MoreUtils goodness; we can assemble those into dispatch tables, delegation structures, function and method templates and factories ... enough patterns to fill a whole life !

hit by operator precedence and right associativity

2009-09-21T20:48:00.010+02:00

While studying a bug, I wrote the following test program :

use strict;
use warnings;
use Data::Dumper;
my $bool = 1;
my %h;
$bool ? $h{true} = 't' : $h{false} = 'f';
print Dumper(\%h);

The ternary expression starting with $bool was supposed to be a concise way to write a conditional, but the result was a disaster. Can you guess the output ?

Here it is : $VAR1 = { 'true' => 'f' };

This really seems totally insane : something is assigned to the 'true' slot of the hash, but the value comes from what was supposed to be in the 'false' slot !

OK, the ternary expression above is wrong, because the '?:' operator has higher precedence than '=', so one should really write

$bool ? ($h{true} = 't') : ($h{false} = 'f');

But how comes that perl issues no error, no warning, and happily produces a very strange result ? It seems that both sides of the conditional are executed simultaneously, and collapse in a mysterious way.

I tried running the script through B::Deparse to understand how it was parsed, but the output was exactly like the original source, so it really seems to be legal Perl !

It really took me a while until the 'aha' moment that made me realize that because of right-associativity, and because conditional expressions can be lvalues, and because "Unlike in C, the scalar assignment operator produces a valid lvalue" (perlop dixit), this was parsed as

($bool ? ($h{true} = 't') : $h{false}) = 'f';

So the $bool test chooses an lvalue between $h{true} and $h{false}, and it doesn't matter that this lvalue is first assigned a 't', because later the main assignment puts a 'f' into it.

Obvious, isn't it ?

Learning architecture and design

2009-09-19T11:48:00.005+02:00

Matt Trout asks about how people learned what they know about architecture and design.

As far as I am concerned, I've always been more or less interested in that subject, but only started to study it more seriously about ten years ago, when I left the academic research world and started writing real software instead of writing papers about software.

So where to go when one is interested in design ? One source of information is books. My sources are quite similar to the ones cited in Matt's article. Currently I'm reading Beautiful Architecture (actually I bought it at YAPC::EU::09), which I enjoy very much because the articles are of high quality and cover a vast territory. The previous book in that series Beautiful Code is also worth reading, although a bit less interesting in my taste. Of course I also read a couple of books about design patterns ... but I'll blog another time about those.

Despite the fact that they seem to sell well, books on design are are not numerous ... probably because they are so hard to write ! I mean, writing a regular technical book is hard; producing good designs is hard; so writing a good book that highlights the design process is necessarily even harder. Actually, books mentioned above are never an organized discourse starting at A and ending at Z; what they do is supply a catalog in which the reader can grab interesting ideas, and that's probably the best any book on design can do.

Which brings us to the point : books on design are nice, they open your mind, but that's seldom the place where you really learn. Design is acquired by practice, using or reading other people's designs, and then doing your own through trial and error. It reminds me of my counterpoint courses : although there are a few recipes, it's only after having studied a dozen Bach fugues and having painfully written two or three in the same style that one really understands what it means to design a fugue.

So I enjoy browsing through technical manuals and APIs of many components, even if I'll never use them. For example, it's quite instructive to study the difference between the object models of Microsoft Word and Microsoft Excel, two products in the same family, but with huge differences in design. Word is an infamous amalgamation of fuzzy concepts (anybody ever understood how automatic numbering works ?), while Excel is a beautiful join of many powerful features into a single orderly framework.

Here is a list of some designs that I considered particularly inspiring:

the NeXT operating system and programming environment had a nice language (Objective-C) and a beautiful OO architecture, with a generic notion of object inspector for editing object properties ... really a joy to use and program. Too bad all of this disappeared for lack of market penetration.
when Netscape first proposed to integrate Javascript into Web pages so that they could become dynamic, I had a "wow" moment : this opened so many possibilities ! Besides, the documentation was extremely well-written (many years after, it's still a useful reference, especially the chapters on how to exploit prototype-based inheritance).
in the same vein, I had another "wow" moment one or two years later when Internet Explorer first came with the notion of manipulating the DOM through scripting (initial versions of Javascript in Netscape could not do that). Again, this opened a whole new world, and the API was quite clean and very well documented (not respecting standards is another story). By the way, at that time the MSDN library site was really cool, with support for keyboard arrow command while navigating through the documentation tree --- later on they moved to .NET technology, and were no longer able to support keyboard navigation !
the Apache architecture is amazingly well-thought for extensibility, with its clean separation of each phase in the request lifecycle, and the possibility to to insert hooks in each of those phases. Actually I didn't study Apache directly, but only through mod_perl, which exposes almost everything of the Apache API to Perl programming, and is another piece of amazing design. I must say, however, that mod_perl has a peculiar way of doing OO, through a kind of home-made mixing of packages into common namespaces, which for the time was quite clever but took me some time to understand. I guess this would all be written with "roles" if redesigned in modern Perl.
several important CPAN modules would be worth discussing here, but that would bring us too far ... maybe later in another blog entry. Let me just state that every time I came to discover another module of Andy Wardley, I felt a sense of beauty : to me, Template Toolkit, AppConfig, Pod::POM

ldami

Beautiful Riga

Why not bless objects into … metaobjects ?

about MsOffice::Word::HTML::Writer

Bad luck with Riga trip

DBIx::DataModel 2.0 is on the way

a municipality called Perl

Perl dualvar is useful, after all

good luck to Plat-forms 2011 Perl teams

plat_forms 2010/2011 : call for Perl teams

rakudo perl6 runs on win32

slides for the perl french workshop 2010 : ORM and EDM

A testimony of Perl efficiency

talk proposal for MST

Initial design vs. maintenance and refactoring

how to reconcile audits and agile development ?

I don't hate the stash ... but I loathe the session.

YAPC presentation styles

Design patterns, or why Java needs external crutches

hit by operator precedence and right associativity

Learning architecture and design

Centralized bug reporting is precious

Birth of DBIx::DataModel (or : Perl ORMs in 2005)

Emacs/Perl integration

Be fair to ActiveState

Object-oriented accessors considered (sometimes) harmful

Good Perl idioms are no longer available

No obvious distinction between "setter" methods and other methods

Hard to debug

Non-scalar attributes must either copy or reinvent an API

No generic data traversal modules

Methods are slower than direct access to attributes

Conclusion

extending DBD::SQLite functionalities

YAPC::EU::09 paper on managing Geneva's law courts

The Perl community is exceptional

Hello, world