I’ll be working mainly with RoR but still a bit of Perl – as a result I’ve been playing with Rails for a couple of weeks now, and all I can conclude is that RoR might as well be Catalyst with Moose and a different templating front end. You can certainly see where the ideas have crossed over!

With regards to the new server, this is now a new server running Cherokee rather than Apache, so we’ll see how things go!

http://per.ly/ will be an aggregate of these blogs, and perhaps some other content. So hopefully more good content soon to be appearing!

I knew these campaigns were running in London, but was surprised to see it on a bus in Stockport. Never heard a religious message proclaiming “There probably is a god”!

So I hit the console and tried to manually make one of the modules and that worked fine. After some more digging I discovered that for some reason the config variable telling cpan where the make binary wasn’t set, so a simple “o conf make /usr/bin/make” and now everything’s hunky dory.

Silly CPAN.

The first one orders a beer.

The second orders half a beer.

The third, a quarter of a beer.

The bartender says “You’re all idiots”, and pours two beers. ”

Devel::NYTProf was originally made by the good people at the New York Times and Tim took it over fairly recently. It kicks Devel::Dprof’s ass, so go take a look.

Perl Buzz has a short extract from Chris Prather’s blog coding all your code like it should be for CPAN. In particular he mentions building make files so that you can automatically install dependencies using CPAN. Whilst I’m not entirely sure the merits of using make files for all your code are completely valid, the other stipulations that CPAN have in place certainly have proven useful to me.

Perldoc: Anyone not including proper documentation in their Perl modules really should do. Even if you ‘think’ noone else will ever work on your code. So many times I’ve come across some code that has no documentation and had to struggle through it. Now that’s a pain when it’s someone elses code, but it’s embarrassing when it’s my own!

Commenting: There is a big difference in my eyes between standard commenting and Perldoc. Perldoc is great for documentation relating to your modules. What your module does, what functionality it offers, who wrote it etc. Commenting however is to explain what you are doing with your code. All Perl developers are guilty of writing slightly less than readable code at one time or another. The more commenting you use the easier it becomes to follow the code. There is nothing worse than having to come back to your own code and not being able to fathem it out quickly.

Version Numbers: Version numbers are a requirement for all modules on CPAN. As I use version control for all my modules I have version numbers associated with them. I don’t include them in the modules unless they are to be distributed. Nevertheless being able to differentiate between instances of the same module is important.

Testing: All modules require unit tests. Unit testing is something I’ve recently learned to embrace. If you are of the mind set that writing tests takes too much time. Then I’m sorry you are simply wrong. Every time you write some code for a project you can quickly run the all the tests on all the modules in that project and you know that everything should work. As you need to check if your code works anyway you need to test it, if you don’t do this by writing tests you do it using some other process. Querying your web server for example. Firing you your web server takes time, requires resources and may not be a good for other people who want to use your module.

Well that felt like a bit of a rant but I feel that some of this stuff is fairly crucial to Perl developers and know that it’s the way things are tending towards at work.