WebNano

In the weekend I published WebNano to CPAN. There is some documentation there - so it is ready for experimenting. I am thinking about a "Why WebNano" article. For now let me just say this: WebNano has just 232 lines of code in 'lib' (as reported by sloccount) and beside Plack it uses only minimal dependencies, but when porting a non-trivial blog engine from Catalyst to WebNano I did not miss any Catalyst features. To be honest in that conversion I did use two WebNano extensions (both also already published), Template Toolkit renderer with dynamic paths and a CRUD controller, but even including them the line count would not excede 500.

Extending the 'Template Method' design pattern

There is this notion that you should not put semantics into names, or maybe that what your program do should not change in alpha-conversion. But of course everyone is breaking that rule if she is using the Template Method design pattern (if we agree that the library they use is somehow outside of the program and is not alpha-converted together with it). There the names of methods have a lot of semantics.

In Advanced Search in web DBIx::Class based applications I proposed an extension to DBIx::Class that would treat all methods with names search_for_* as predicate builders. This way programmers could easily extend the query language used by DBIx::Class with new predicates by adding methods to the ResultSet class. Now in WebNano all *_action controller methods also have a special meaning - these are the methods that can be called from outside via automatic dispatching from an url. Taken literally sub my_method_action is not that different from sub my_method : Action which is the way to specify that in Catalyst. The difference is only ' : A' versus '_a' (and I could use *_Action if I wanted to golf it even more) - but yeah - I am cramming the semantics into the name while Catalyst reserves it for the code attributes. Catalyst way is cleaner - but my goal was a 'minimal' framework. The 'Extended Template Method' design works in a few lines while MooseX-MethodAttributes is 13 packages with who knows how many lines of very subtle code.

What surprises me is that I have never seen a description of this 'Extended Template Method' design pattern. It looks rather obvious, maybe it is called by some other name in the literature.

Inviting non-Perlers to speak at Perl conferences

There is an organized effort, by the Perl volunteer marketers, to attend non-Perl events and communicate about the all new things happening in the otherwise insulated Perl word. I wish this effort all the best, and I hope that The Perl Foundation will find a way to support it. To enforce the effect I would like to see also the symmetric and complementary action of inviting non-Perlers to our conferences. I am sure that is already happening to some extent - but personally I have not yet seen it - so I conclude that this extent is not enough.

Whom, from non-Perl speakers, would you like to hear at your next Perl conference?