A Cautionary Tale

I can never remember exactly how Time::Piece works. But that’s ok because I have documentation.

$ perldoc Time::Piece
No documentation found for "Time::Piece".

Huh?

$perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
...

$ corelist Time::Piece
Time::Piece was first released with perl v5.9.5

$ perl -MTime::Piece -E'say $Time::Piece::VERSION'
Can't locate Time/Piece.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .).
BEGIN failed--compilation aborted.

So Time::Piece has been in the Perl core since 5.9.5. I’m running Perl 5.14.2 but I don’t have Time::Piece installed.

After ten minutes or so of head-scratching it came to me.

$ sudo yum install perl-core
Loaded plugins: langpacks, local, presto, refresh-packagekit
[ stuff snipped ]
---> Package perl-Time-Piece.x86_64 0:1.20.1-212.fc17 will be installed
[ more stuff snipped]

I’m running Fedora. The Fedora packagers have decided that they don’t need to install the whole standard Perl distribution as part of their standard installation. I don’t have a problem with that. I do have a problem with their naming conventions.

The minimal Perl installation that they include by default is in an RPM called “perl”. The full RPM that includes everything that a Perl developer would expect to see is called “perl-core”. Surely it’s obvious that those names are the wrong way round?

Isn’t there some way that the Perl 5 Porters can object to  this renaming of Perl?

I know I should be installing my own Perl with perlbrew. But I generally find that the system Perl works for everything that I need. There’s just this one thing that is guaranteed to trip me up every time I work on a new Fedora installation.

This is a public service blog post. Perhaps someone will come across it and be saved a couple of hours of confusion.

CGI.pm vs Templates

I’ve just been involved in a discussion on LinkedIn that I thought deserved a wider audience (I have no idea how well that link works if you’re not a member or or logged in to LinkedIn).

A couple of days ago, someone asked for advice on the best way to include HTML in a Perl program. They got a lot of good advice (basically – don’t do that, use a templating system instead). And then this morning, someone came in and said:

use CGI module, u don’t need to write a single HTML tag..just use CGI Methods…

I did a bit of a double take at that point. I thought we’d all stopped using CGI.pm’s HTML generation methods back in the last millennium. I replied saying that, but this chap was adamant that CGI.pm worked for him. He asked me to explain why I was so against his approach.

This was my reply:

I never said that it didn’t work. I just think that it’s a really limited way to build things and you’d be better off taking a more flexible approach right from the start.

My main objection is the separation of concerns. The logic of your application is separate to the display layer. It’s quite possible that the display of the application will need to change in the future. And that all becomes easier if the HTML is stored separately from code.

This leads to other problems too:

As I hinted at above, CGI.pm only has pretty basic support for HTML. It’s really hard to create a great-looking web application using CGI.pm. In fact, I wouldn’t be surprised if CGI.pm was largely responsible for the terrible web sites that the Perl community has been building for itself for most of the last twenty years.

Your project might well have HTML experts who know how to create good looking web pages. Expecting them to do it by editing Perl code is a bad idea. Front end developers need to know HTML, CSS and Javascript. Why force them to understand Perl as well?

Even if you’re the only developer on a project (as I often am for my personal projects) there are advantages to separating your work into “front-end task” and “back-end tasks”. I find it really helps me switch my mindset to the appropriate skills if I switch from editing a Perl source file to editing an HTML template.

It makes your Perl code more complicated than it needs to be. Seriously, try moving the HTML out of the code and into a template. See how much simpler your code becomes.

It’s unlikely that your CGI-generated pages will make up all of the web site. There will almost certainly be static pages too. If you use a tool like the Template Toolkit then you can generate static pages from the same set of templates that your CGI programs use. That way it’s easier to maintain a consistent look and feel across all of the pages on the site.

I’m not saying “don’t use CGI.pm” (well, I am a bit – but that’s a different story). The CGI bits of CGI.pm (for example the bits that give you access to the incoming parameters or let you set the outgoing headers) are great. It’s just the HTML generation stuff that I strongly recommend that you don’t use.

I’ve just remembered an article that I wrote in 2001 that might also help. The first half is about cookies, but the second half demonstrates using Templates instead of the HTML generation methods. I hope it shows how much simpler it makes things

See http://mag-sol.com/articles/cgi3.html

Does that help at all?

I think that pretty much sums up my objections. Did I miss anything obvious? Or am I completely wrong and many of you are still using the HTML generation methods in CGI.pm to do this?

The Perl community on LinkedIn is a fascinating place. I should really write a blog post about it.

Perl School

On Saturday, I ran the first Perl School session. Twenty-five programmers with little or no previous experience of Perl came along to Google Campus in London and listened to me talking about Perl.

Over six hours I tried to give a good introduction to Modern Perl. In the morning I talked about the core Perl language and explained some of the concepts (for example, context) where Perl differs from most other programming languages. In the afternoon I talked about some of the important big CPAN projects that are defining Modern Perl – things like Moose and PSGI.

The course was free as it was all a bit experimental. I was trying to work out how much material I could get through in a day and what topics would be most useful for the attendees. Many lessons were learned.

  1. There was slightly too much in the course. Things got a little rushed towards the end. I might need to cut a bit of material before running it again. Or perhaps I just need to waffle on a bit less.
  2. When you book a room you should ask how the seating will be configured. I turned up at about 9:15, expecting I’d just need to get to grips with the projector system. I found the room set up with chairs around a central table. It was a bit of a rush to turn that into a lecture theatre before the students arrived.
  3. Some people don’t value free training. There were fifty places available on the course. They were all booked within 24 hours of the date being announced. Over the intervening couple of months, a few people dropped out and were replaced by people from  the waiting list. That’s not a problem. In the 24 hours before the course I received five emails from people saying that they couldn’t come for various reasons. That’s not a problem either. What’s a problem is the twenty or so people who just didn’t bother to turn up and didn’t think it worthwhile to let me know.

I’m doing it all over again in October. Same course (slightly improved, I hope) art the same venue. This time it won’t be free – but I’m hoping that a fee of £30 will be cheap enough that people will still sign up.

And I’m planning more courses for the future. Initially, I plan to run something every couple of months. I’m thinking about one-day courses in Database Programming, Object Oriented Programming and Web Programming. Hopefully some of my readers will be interested to come along to some of that.

I hope to announce the subject and date of another course within a couple of weeks. It’ll probably be in early December. Watch the web site or the mailing list for details as soon as I have them.

Google Currents

Google Currents is an application for viewing content on Android and iOS devices. It reformats content (based on web feeds) to look like a magazine. It looks great on my HTC One X and I’m expecting it to look even better on my Nexus 7 when it arrives.

It’s possible to subscribe to web feeds using it, but for some reason content looks better if the web site owner goes through a simple process to publish the content. This is literally a three minute job which you do from the Google Currents Producer web page. I’ve done that for both this site and the Perl News web site. I can’t seem to find any way to share the address of this content, but if you open the Currents app on your tablet or phone and search for “Perl Hacks” and “Perl News” you should be able to find them.

Currently I’m using all the default formatting options, but I suspect I’ll be drawn into tweaking things soon.

If you published Perl-related content on the web (or, indeed, any other kind of content) then it might well be worth your while taking the three minutes it takes to publish your content for Google Current.

What is Modern Perl?

I wrote an article for Josette called “What is Modern Perl?” In it, I talk about the different things that people might mean when they talk about Modern Perl and why it’s well worth buying a copy of the new edition of the camel book.

After a gap of twelve years, a new edition of Programming Perl (affectionately known as “the Camel book” to its many fans) was published earlier this year. That came as quite a surprise to many people who had given up on seeing a new edition.  What has changed in the new edition? Does the book now cover Modern Perl? The answer depends on what you mean by the term “Modern Perl”.

Of course it’s not a complete coincidence that the subject ties in nicely with my forthcoming Modern Perl for Non-Perl Programmers course.

Update: There’s a discussion of the article on Hacker News. It seems to be taking a predictable path.

Introducing Perl School

Yesterday I talked briefly about the Modern Perl for Non-Perl Programmers course that I’ll be running at Google Campus in October. If you look at the URL for the course information you might see a hint of a wider branding strategy.

I’m planning to run a series of these low cost, high attendance courses. And I’m going to brand them as “Perl School”. The idea[1] is to get a bit of a buzz going about Perl training in London. And giving the series an easy to remember name is an important part of that.

There is, of course, a web site too. It’s at perlschool.co.uk. And a Twitter account – @perl_school.

I won’t just be running courses aimed at non-Perl programmers. I have ideas for courses for Perl programmers too (at all levels).

Please keep an eye on the site for more news.

[1] Ok. Part of the idea. There’s also some stuff about making money in there.

Modern Perl for Non-Perl Programmers (Redux)

Six weeks ago I announced that I’d be running a free one-day course called “Modern Perl for Non-Perl Programmers” in August. Places on that course were fully booked in less than a day.

So I’ve decided to run to course again, two months later. It will still be at Google Campus, and the date is Saturday 6th October.

The original course was free, but I can’t afford to do that on a regular basis. I hope you’ll agree that £30 is still a bargain for a day of training.

As last time, most readers of this blog probably aren’t in the target audience for this course[1], but you might know people who would be interested in the course. Please pass on the link.

You can buy a ticket using at perlschool2.eventbrite.co.uk.

Eventbrite - Perl School: Modern Perl for Non-Perl Programmers

[1] Programmers of other languages who want to learn Perl.

Perl Teach-In 2012

Back in 2007 the London Perl Mongers ran a free one-day Perl training course at the BBC’s offices in White City. That was five years ago, so for a couple of months I’ve been thinking that it was probably about time that we did another one.

And then suddenly this afternoon a few loose ends came together and all of a sudden it’s been organised.

The course will be on Saturday 4th August at Google Campus in London. It will run from 9am to 5pm. As last time, it will be completely free to attendees.

Last time the course was aimed at intermediate Perl programmers and introduced them to advanced Perl techniques. This time I’m aiming at the opposite of the spectrum. The course is called “Modern Perl for Non-Perl Programmers”. It’s aimed at people who are comfortable programming in languages other than Perl and who are interested in getting up to speed in Perl as quickly as possible.

Obviously most of the readers of this blog won’t be in the target audience for the course, but I’m betting that you all know at least one person who might be interested in the course. So it would be great if you could send the link to the registration page to anyone who you think would find the course useful.

The link is: perltraining.eventbrite.co.uk

Eventbrite - Modern Perl for Non-Perl Programmers

Update: All of the places on this course were booked in about 20 hours. In 2007, a similarly sized free course was all booked up in about two days. I guess it’s true that Perl is dying :-)

How Well Can You Read Documentation?

(I was going to call this post “How well do you understand context?” but I think this title is more accurate).

I just saw someone recommending this code:

Looks sensible enough, doesn’t it? But it isn’t. What’s the hidden inefficiency?

“You Must Hate Version Control Systems”

I’ve been an independent consultant for a long time now. Over the last seventeen years I’ve worked for dozens of different clients. In that time it’s been interesting to watch how good practices have slowly permeated the industry. These days, when I start working with a new client there’s about a 50% chance that they will have some kind of Continuous Integration environment in place. Over the next couple of years that percentage will, no doubt, increase and CI will just become part of the standard software development toolkit. Those of you thinking “but it’s already part of the standard software development toolkit” should realise that not everyone is as leading edge as you are.

For example, before CI was on the scene, unit testing was the big new idea. Over the last ten years, the percentage of clients where I seen unit tests being used has gone from about 10% to pretty much 100%. For most software developers, the idea that you would develop any large project without unit tests seems ridiculous. But it wasn’t always like that.

Before that, it was source code control. When I first started out in my career I had a number of clients where I spent a lot of time persuading people of the benefits of source code control. At one large bank in the City of London I was charged with getting all of the development teams in one department to use source code control. It was probably SCCS or RCS – either of which is just barely better than nothing. One of the development team leaders was particularly hard to persuade. At one point he told me:

I understand exactly what source code control is for. But it solves a problem that my team just doesn’t have.

I didn’t really understand that. He had a team of three people. They all worked on the same codebase. How was it possible that source code control wouldn’t make their lives easier? Later I worked more closely with that team and came to understand their working techniques as I found a directory of tarballs with datestamps in their names[1].

Of course, this is all ancient history now. In these enlightened times we can laugh at stories like this because we all know how important source code control is.

But look at this job description which was posted on jobs.perl.org a couple of weeks ago. There are a number of things in this advert which worry me – “raw perl (no modules)” – but I think the thing that scared me most was where it says:

You must hate version control systems, we won’t be using any.

I’m not sure what’s the most surprising thing here – the fact that there are people who still think like this or the fact that they admit it in a job advert as they think it will encourage people to apply for their job.

All in all I don’t think that Holophrastic Enterprises[2] sounds like the kind of place that I’d like to work. You might disagree. You might think that cutting through all this “best practices” nonsense and just getting on with coding sounds like your perfect job.

If you apply, please let us know how you get on.

Me, I’ll be sticking with version control.

[1] It can’t be coincidence that this was also the team leader who complained the most when the infrastucture and deployment team I worked in took the decision to remove developer access to the production servers.

[2] And if anyone can tell me why they need all that Javascript on their single static page web site, I’d love to hear it.