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 :-)

“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.

XML::Feed

XML::Feed is the module that does most of the heavy lifting for Perlanet and, as such, it powers some important parts of the Perl community’s infrastructure. Unfortunately, for a while now it’s had a rather long list of outstanding bugs that weren’t getting fixed.

Sometime last year, Matt Trout got co-maintainership on the module and shortly afterwards he shared it with me. I released a couple of versions last year (largely to fix one particular and important bug) and fixed a few of the easier bugs on the list, but most of the list remained untouched.

Whilst working on these few fixes I set up a copy of the repository on Github. And about a month ago, that started to pay dividends as I got a couple of pull requests from Gabor. In combination with a couple of new bug reports that came it at about the same time, this galvanised me into putting a bit more effort into the module.

I’ve released a couple of new versions in the last week. Most importantly, I think that version 0.48 fixes the test failures that were common in the last few releases – and initial indications are that I’m right.

It seems that people are interested in this module. So let’s see if we can get a little community going. I’ve set up a mailing list to discuss the module and. of course, there’s already the bug list and the Github repository.

Patches welcome. Github pull requests even more so. But if you just have ideas and suggestions or want advice on how to use the module, I’d love to hear from you.

Being Helpful

I like to help people who know less Perl than I do. I like to help them to improve their standard of Perl. I particularly like to help to improve the standard of Perl that is found on random sites on the web. This is because if I find your nasty Perl code on the internet then someone trying to learn Perl might also find your nasty Perl code and not realise just how nasty it is.

I used to do a lot more of this, but I’ve really cut down. Mainly I have a lot less free time now, but also it used to sometimes get me in trouble. People aren’t always as grateful for help as you’d like to think they would be. Those of you who have known me for ten years or so might remember some amusing scrapes from the support forum for a particular beginners’ Perl/CGI book. The phrase “use strict is gay!” still brings a smile to the face of the older London Perl Mongers.

A few months ago I saw this site. The site is owned by a MySQL consultant who posts some really quite complex programs that he has written to interact with MySQL in various ways. Most of his programs are written in Perl. But it’s clear that the author is not really familiar with Perl – he makes that point explicitly in his sidebar. This means that the Perl really isn’t very good.

Now I know that we’re happy for people to use “baby-talk Perl”. And I know that a correct Perl program is one that gets the job done. But I also think that if you’re sharing code with other people then you should make a bit of an effort to make it as well-written as possible.

So soon after I found the site I dived in with some suggestions. “Try using strict and warnings”, “these days we like to recommend lexical filehandles and three-argument open”, “you know you can avoid those leaning toothpicks” – that kind of thing. I didn’t get much response and the Perl didn’t get any better so I lost interest and drifted away.

Yesterday I got an email from the site saying that someone had added a comment to one of the entries that I had commented on. Reading the new comment I saw my contributions described as “obnoxious”. Following my experiences of ten years ago I’m a little sensitive about accusations like that. I grew up on Usenet and I know that my language can sometimes come across as more robust than I intend. But reading back what I wrote, I don’t think that’s the case here. I tried to explain but was told that I was just making my critic’s point even more valid.

I don’t think I’ll be going back to that site. They don’t seem to be interested in my help. But I left them a parting gift – a link to my version of the program. I doubt they’ll say thank you.

Yet More Modern Perl in Linux Format

Over the weekend the postman bought me my subscribption copy of Linux Format issue 155. This contains the third (and final) part of my Modern Perl tutorial. In this part we’re adding features to the Dancer web application that we started in issue 153.

This series has concentrated on web applications (with Dancer) and database access (with DBIx::Class). I’ve already got provisional agreement for another short series later in the year – where I plan to cover OO programming using Moose.

The new issue will be in the shops later this week.

Free Training Competition in Linux Format

I’ve mentioned before that I’m running some public training courses in London next month. But how do you fancy coming along to those courses for free?

Those lovely people at O’Reilly have put an advert for the courses in the new issue of Linux Format which hits the shops about now. That’s issue 154 and the advert is on page 54. The advert contains details of a competition where two people can win free places on the two courses – one person on each course.

There are also four runner-up prizes which are copies of the new edition of the Camel book.

All you need to do is… well to find that out you’ll need to buy the magazine. Ok, so entry isn’t 100% free – you’ll need to pay £6.49 for the magazine.