If you have a Catalyst app which is generating PDFs with Catalyst::View::PDF::Reuse, and you want to use Unicode characters in the PDFs, you’ll need two things:

• you’ll have to specify a TrueType font explicitly to get characters out of the Latin-1 range. The documentation for PDF::Reuse has instructions on how to do this.
• Catalyst::View::PDF::Reuse uses Template::Toolkit, which will turn wide characters into rubbish unless it knows what encoding you meant. You can specify this by passing in an ENCODING parameter when you configure View::PDF::Reuse in your app module:

  'View::PDF::Reuse' => {
      INCLUDE_PATH => __PACKAGE__->path_to('root', 'site', 'pdf'),
      ENCODING => 'utf8'
  }
  

  Template::Toolkit’s manuals have other ways to set the encoding.

OH. MY. GOD if I had known about Devel::Ditto two months ago, I could have finished that project two months ago.

On closer inspection, it seems Devel::Ditto was not yet on CPAN two months ago BUT STILL.

You remember the project – the nightmare trawl through a pile of overdesigned, buggy web application which no-one still working here understands? The one that stopped me having the spare time to post here. Well, Devel::Ditto tags all of your code’s print and warn outputs with the file and line number. That would have been incredibly helpful.

Because when someone else has to learn how your system works, when they start out, they will be thinking about what it does from a user’s perspective, because that’s all (at that stage) they’ve got. Not from a programmer’s, and especially not from yours.

And if they have to learn a bunch of abstract class hierarchies before they can begin to get their head around it – even if those abstractions are well established and are in textbooks and such, and are all nice and neat and by the book, which, let’s face it, they probably won’t be – they will hate you, and curse you and your descendants.

I’m just finishing a project involving the porting and maintenance of a largish, fragile and buggy system, written six years ago in heavily Java-accented Perl. Though I can’t swear that I’ve looked at every class in the app, I’ve looked at most of them, and I have found exactly one family of classes which models a concept which I could explain to a user of the system.

That concept is ‘a report’.  Typically for this code, the family of classes is not called X::Y::Z::Report, but X::Y::Z::Sort, and tracing the inheritance relationships is a nightmare. So it’s not like modelling business concepts is going to make you write good code, but it avoids whole constellations and galaxies of ways of writing bad and misleading code.

By which I mean that Perl starts from C-style syntax and then allows a lot more flexibility and convenience.

Haskell feels like it does a similar dance with Lisp. It’s possible to write Haskell expressions in a very Lispish way, by avoiding all the syntactical conveniences like $ or backtick-infixing (which still seems very weird to me, but I can see the reason for it) which make it such an expressive language.

The current project – trying to port a web application I didn’t write from Apache 1 to Apache 2, and in the process getting my head around its bewilderingly complicated class hierarchy – has crystallised my already dim view of inheritance into the following principle:

If you are relying on deep inheritance, it’s a sign that you are modelling the wrong things.

I reckon objects should represent real world entities – Students, Customers, Parts etc. But inheritance isn’t often a useful property of real world objects; it’s a property of the abstractions we use to think about those objects. The sun ISA sphere, and so ISA orange, but that fact is not really the most important observation we can make about those two things.

One-level-deep inheritance (an orange ISA fruit, or, even more usefully, ISA pricelist-item) is handy, but inheritance of this sort – where a flat array of specific objects all inherit from a single template – is more like a way of filling in properties than anything else.

Deep inheritance may be better when the application domain is itself code: compilers and parsers etc.

In the code I’m grappling with, the classes are modelling application states and state machines and so on: the things the programmer is thinking about, not the things out in the world that the code is dealing with. Inheritance is a natural fit for such things, but that just makes it harder to read the code. While good code might be a possible outcome for some programmers using this approach, I think it’s the exception rather than the rule.

# This is where all the work is done

The programmer who wrote this was sincere, but it just isn’t true.

If we take into our hand any volume; of divinity or school metaphysics, for instance; let us ask, Does it illustrate recursive functions by means of either the Fibonacci series or factorials? Yes. Consign it then to the flames: For it can contain nothing but sophistry and illusion.

(I’ve been teaching myself Haskell.)

Once you start using named parameters, you have to use them everywhere.

Sometimes I get lazy and ignore this rule. It’s only a test script, I tell myself. Don’t slow things down. In doing this I am forgetting that the part of my brain which used to be responsible for remembering the order in which parameters are passed in to functions died several years ago from neglect, and that I can’t rely on it to help me anymore, and that I will get the parameter order wrong and waste even more time.

It’s buried next to the part of my brain which used to remember the names of “string” functions in C.

If I think of testing some aspect of my code’s behaviour, and I get the impulse “oh that’s so simple, writing a test for that behaviour is a complete waste of time”, and I then resist that impulse and write a test for it anyway, I’m guaranteed to find a bug.

This happens every single time. The “oh that’s so simple” impulse which would have stopped me testing the code is the same impulse that stopped me paying attention to it and noticing the bugs.

More notes for my future reference than anything else: this is a list of things which have puzzled me because they’re not in the documentation

• form parameter parsing on POSTs was looking for the MIME type ‘x-application-urlencoded’, not  ‘x-www-form-urlencoded’, which is what Firefox is sending. I don’t know why. I added the other MIME type to line 78 of Mojo/Message.pm; must get around to emailing the author about it
• To get form parameters in a controller, you say $c->request->params->param($name) (for GET) or $c->request->body_parameters->param($name) for POST.
• Passing variables to the Mojo::Template seems to be done by setting $c->stash() to a hashref (or whatever else you want) and then pulling it out in the template

That said, I am enjoying playing with this stuff. It’s not often that I actually enjoy reading other people’s source code in order to understand it.