Images inheritance in Plack based apps

My plan for Nblog is to let users customize it by subclassing and overloading, in the screencast I showed how to do that with controllers and templates, in the latest revision of Nblog I added the possibility of overloading images. There are Plack components for all parts of this task - but I had a bit of struggle with getting the settings right. Maybe the following code snippet will spare similar time waste for someone?



Some explanations: psgi_callback is the method in WebNano that constructs the anonymous subroutine required by the PSGI standard and here I use the around Moose method modifier for it to add some additional processing there. static_roots returns a list of directories where to search for the static files - this is our search path - the first file found in these directories is served. In the base class this list contains only 'static' - if you want to overload the static files in a subclass you need to add your directories before this one, in my example subclass config I have:

static_root => [ 'static', '../Nblog/static' ]

(these are relative paths). See also Plack::App::Cascade. All of this would be a bit easier to assemble if the Plack components logged some debug info to STDOUT, like what you can find in the standard Apache logs about files not found, when run in development environment. I am volunteering to write a patch if there is a green light from the core devs.

Unit Testing

With one functional/system test you can test lot's of low level parts that in Unit Testing would require a separate test each. It is also easier to write - because you only need to test how the module/library is used and using it should be easy (and not require mocking etc) - otherwise the library would not be a good library to start with. And what are the reasons to do unit testing? Personally I was never convinced by the arguments until I started reading Misko Hevery - here is for example is the single best explanation of why to do unit testing I've ever seen:

Lets say you would like to test a car, which you are in the process of designing, would you test is by driving it around and making modifications to it, or would you prove your design by testing each component separately? I think that testing all of the corner cases by driving the car around is very difficult, yes if the car drives you know that a lot of things must work (engine, transmission, electronics, etc), but if it does not work you have no idea where to look. However, there are some things which you will have very hard time reproducing in this end-to-end test. For example, it will be very hard for you to see if the car will be able to start in the extreme cold of the north pole, or if the engine will not overheat going full throttle up a sand dune in Sahara. I propose we take the engine out and simulate the load on it in a laboratory.

from It is not about writing tests, its about writing stories

In the rest of his writings you'll also find how to structure your code in a way that makes unit testing easy and does not require crazy mockings. I am also convinced that code structured in that way is well decoupled and easy to understand, modify and talk about.

Experiments in Inheritance - a screencast

This is a short screencast I made to replace the video made at my London Perl Workshop presentation. It did not make the list eventually - but I still think it might be interesting: http://warszawa.pm.org/WebNanoInheritance.mpeg. It is my first screencast ever made - please comment.

The main idea presented there is about solving the "give mi an application like this one but ..." problem, illustrated by making a blog engine that inherits from Nblog, but extends it and overrides some of it's elements.

Namespace Matching

The other day I was reading the Dancer Advent Calendar and I finally found the two words description of what WebNano does. WebNano is the minimal addition to PSGI that provides Namespace Matching. Beside easy deployment, which is currently covered by Plack, Namespace Matching is probably the main feature of Catalyst and now with WebNano you can have that without the heavy baggage of the whole of the Catalyst framework. I think it is important because it seems to produce just the right granularity of the controller classes and provides a path for the application growth (without overloading one file with too much stuff).

WebNano - some incompatible API changes ahead

I tried carefully not to document some things that are likely to change in the closest WebNano releases, but the example code I put in the docs needs to be exact and that means it contains some details I have not yet decided are stable. One of these examples is about overriding the local_dispatch. It used to take the path as a string parameter - now it takes an array - i.e. the path split on the '/' character. The past way was more universal as it let the user programmer to specify how to parse the path - but I think splitting on '/' is such a common usage that it justifies the change. And it is not destructive - so if someone really want's to parse the path in a different way then he can join it back.

This change will be in the next WebNano release.

In the longer perspective I am thinking about being more compliant with the Law of Demeter and building the controllers with the needed model parts in their own attributes, instead of accessing them through app. So for example some code in Nblog would change from

$self->app->schema->resultset( 'Article' )->search
to
$self->article_rs->search

Now this can be done by overriding the handle class method - but maybe it needs something more elegant.

WebNano as Catalyst::Tiny

If you have read The Philosophy of WebNano you might think that WebNano is radically different from Catalyst, the more so if you'd compare the size of these projects (sloccount reports over 5000 lines in lib for Catalyst, versus less then 250 for WebNano). But if you compare the code structure between Nblog and the original RavLog project you'll find it very similar. The DBIC schema and form classes were just copied around, you'll see mostly the same controllers with mostly the same methods.

Look for example at Nblog::Controller::Ajax and RavLog::Controller::Ajax - the changes are minimal, mostly just changing sub check_articles : Local to sub check_articles_action and accessing the model from $c->model('DB::Tag')->search to $self->app->schema->resultset( 'Tag')->search - a bit longer perhaps. Sure there are other controllers like: RavLog::Controller::View that I renamed to Nblog::Controller::Article. This renaming is not important - I just did not like a controller called View but there is also some difference in their methods. The RavLog controller uses the Chained Catalyst dispatcher - while in the Nblog one I overrode local_dispatch, and it uses stash to communicate with the template while in Nblog I passe the data directly as a parameter. Still some similarity remains.

WebNano uses some dependencies - so it does not fit into the original Adam's definition of tiny modules (by the way I cannot fin this definition now - maybe this should go to some semi-official place like the p5p wiki?). But the prerequisites are really minimal - and mostly tiny themselves. Maybe in the subject space of web frameworks this should be allowed?

Why WebNano - the article

My article on the motivation for WebNano was published at perl.com.

Old code and survivor bias

If code is well designed, decoupled and has good test coverage there are chances that it will be regularly updated to new technologies and new programming techniques. The other code will probably scare programmers and have much chance to stay in it's sad state until decommission.

Templates

I've heard that Perl is ugly because of all those pesky '$'. Purely esthetically this might be true, depending on the font used, but I have the impression that people use the word 'ugly' in a more metaphorical way, like 'ugly subroutine'. Somehow they believe that using an otherwise unused character for marking variables is inelegant - but I think they are confused, I think their opposition arises from the kneejerk reaction to an unfamiliar character. For me the '$' signs make parsing and understanding Perl code easier.

I've heard that TT2 code is ugly because it uses '[%' instead of the more familiar '<', and that it 'FOR' is a heavy burden for the eyes of the programmer because it is "shouting" at him, but I think that the features that make TT2 code standout in the text being templated make it easier to parse and understand and they help my eyes in their work.

Beside that purely ergonomical argument I don't see any purpose of the mini language and I think I am not that thrilled by the future direction of TT.

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?

Value Objects - some notes

There is a controversy - or maybe a fuzzy consensus about what you should be able to do in templates. Some template engines, like Template Tookit, let you call subroutines and methods on stuff passed to the template. This is very useful - you don't need to care about turning the data into a specially formed hash that can be iterated by the template, you just pass the data there and can be sure that it can display it. But it can also be abused. I think everyone would agree that template should not for example change the data in the database, but where is exactly the limit is not clear. Value Objects seem to be a good answer, templates should work only with Value Objects.

The question is how sharply you can divide your objects into Value Objects and Service Objects. In ActiveRecord is hard to test Hevery proposes a design where the record in Active Record is a Value Object (newable in his terminology is a synonym) with no link to the repository object which would do all the database manipulation. This would work for normal attributes - you'd assign the value there on object creation - but what about relations? $user->books is very convenient, especially in templates, and it can be pure - if you know that you need the books on the user you could put them there when creating the user object. But then you'd have two kinds of objects - those with books, needed in some places - and those without, when you want to spare the additional database calls. Maybe we need subclasses of User? But then we'd need subclasses for all possible combinations of relations (users with books, users with friends, users with books and friends, ...), not to mention the mess with relations on the related objects.

Another argument for immutable objects

Class is like a little program, it has data, it has code, it can be instantiated - like a program can be run. From the perspective of the object it's attributes are global. There can also be other variables - like parameters passed to the methods or other block scoped variables - those are local, but attributes are global. If they are immutable - they are like programs constants, but when they are changeable - they are like global variables. And we know that global variables are bad.

Managing Object Lifetime

This is the title of a blog post by Misko Hevery. There are also lot's of other materials authored by him freely available on the net. I have just started exploring them, and there is a lot of repetition if you just google around like me - but I already want to recommend it to anyone working on improving the design of their programs.

WebNano does not (yet?) meet all the design criteria he is talking about - but he is putting into words many of the foggy intuitions that made me not satisfied with all of the existing Perl web framework and write yet another one.

Inheritance and rapid prototyping

There is much talk about the dangers of too much inheritance and how composition is better then inheritance - and probably they are right if we are talking about the final product. What they don't account for are the dynamics of the development - where you grab the first thing that does something similar to what you need and you start testing it, changing it, evaluating your ideas. Inheritance allows you to do exactly that - making changes to something that was already finished and working somewhere else. With procedural code this is not possible, the most similar thing you can get there are examples.

In other words Inheritance might lead to tightly coupled code, with intricate execution paths, but at least it is an easy way to get something working quickly. You can refactor it later.

Installing Dist::Zilla plugins

Dear lazyweb - when I try out a distribution converted to DistZilla I often discover that I don't have all the plugins used there. Starting the work then consists of a string of 'dzil build' commands, searching the monstrous error stacks for the name of the missing plugin and then running cpan with it. Sure that should be automated!

And, by the way, it could also install the distribution's prerequisites.

Update: Repeating one of the comments - apparently the latest Dist::Zilla supports following solution dzil authordeps | cpanm.

Object::Tiny:RW and MooseX::NonMoose

There are conflicting requirements for WebNano. On one hand I would like to build big heavy web applications based on it, and of course I would like to use Moose as the object framework for them. On the other hand I would like to give it a chance to work in the restricted environments of most shared web hosting serving CGI scripts - so heavy dependencies and XS and big startup times are out. And I would also like to make it suitable for serving huge amounts of simple Ajax requests - so it needs to be fast.

First I tried using Any::Moose and let people decide if they used Moose or Mouse. By using Mouse people could solve the startup problem and also there is some way to use Mouse without XS.

But Mouse was still huge dependency - so next I asked myself it it would be possible to subclass in Moose a non Moose base classes. That proved to be rather simple with the aptly named MooseX::NonMoose. Using it in WebNano I can build my objects in what ever way I choose and as long as I stick to the standard hash based objects I can extend the WebNano classes in my Moose based applications with no problems. Or at least it seems to be with no problems for me now - if someone knows more about disadvantages of this solution - please leave a comment.

After discovering MooseX::NonMoose I switched to use Class::XSAccessor. It small and very fast, but unfortunately it was XS based. I was thinking about the possibilities of bundling the software as a PAR package or so and using it in the restricted shared hosting environments and relying on a C compiler seemed to complicate things a lot.

Next I tried Object::Tiny, it was tiny, fast and did not use XS, there was just one but - it did not produce the attribute setters. I could live with that and it did not take much time for me to port WebNano to use Object::Tiny, but still it seemed like an extreme choice. Fortunately just browsing CPAN I discovered a fork of O::T - Object::Tiny::RW - this one is small, fast, does not use XS and does produce attribute setters. I am still a bit worry about why Adam would not add that feature to his module - given that it is such a trivial change (compare the sources of Object::Tiny::RW and Object::Tiny - its just one line changed), he must have had a good reason for that?

RavLog - a perl blog engine

For testing HTML::FormHandler Gerda Shank wrote RavLog. Recently I've made a fork of it, switched to SQLite as the main db engine and made it easy to install. It still does not pass all formatting tests (HTML::Tidy seems to be uninstallable) - but it is usable. My goal is to make another fork out of it and port at least part of it to WebNano, but I think that what is now there can also be interesting for someone looking for a Catalyst based weblog engine.

Technically right, socially not so

Imagine that you let anyone use your hard work by publishing your code as Open Source and then instead of thank you notes you receive angry emails about purported bugs in it.

Imagine that you noticed a problem about some Open Source code and as a good citizen you analyze it and report your findings and instead of a thank you note you receive a reply explaining how much confused you are for thinking that that could be a bug.

Imagine that this happens in a public space like an mailing list, open bug tracker, etc. This is like the setting of a Greek tragedy - both sides have their own rights and values, both sides can be technically right - and yet the conflict spreads and escalates. People copy the emotions of each other, even perceived emotions and especially anger, when displayed publicly leads to more anger. This is a vicious circle of positive feedback loop. When it starts everyone gets irritated and everyone wants to know who started it, who is responsible for that.

But go back to the start - it's not anyone's fault - you cannot point the finger on one person and say 'he is responsible'. Looking for the main culprit is really looking for a scapegoat - a surrogate victim that would heal everyone's consciousness. This is not especially geek thing overall - it is a universal trait - but sadly inventing fodder for the scapegoat search is a prominent part of geek culture.

One of the many things that I admire about Larry Wall is how he can neutralize the poisons of angry reactions. People scorn Perl for being a 'scripting' language - he talks about Ada Lovelace:

Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She'd probably look at you funny, then say something like: Well, a script is what you give the actors, but a program is what you give the audience. That Ada was one sharp lady...