Training Debrief

During the second week of February, I ran my (approximately) annual public Perl training courses in association with FlossUK. Things were organised slightly differently this year. Previously we’ve run two two-day “general purpose” courses – one on Intermediate Perl and one on Advanced Perl. This year we ran four courses, each of which were on a more specific technology. There were one-day courses on Moose, DBIx::Class and testing and a two-day course on web development.

Class numbers weren’t huge during the week. We had about six people on each of the days. That’s a large enough class to get plenty of discussion and interaction going but, to be honest, I’d be happier if we got a few more people in. The attendees were split pretty much down the middle between people who working for commercial organisations and people who worked for universities. I’m sorry to report that there were no women booked on any of the courses this year.

As is often the case on these courses most of the attendees had been using Perl for a long time and were pretty comfortable with some quite advanced Perl features. But, for various reasons, they simply hadn’t had the time to investigate some of the newer Perl tools that would have made their lives much easier. I often get people at these courses telling me that the best thing about the course is just having a day set aside where they can try out cool new technologies that they have heard of without the worry of someone calling them away to deal with some vital production issue (this, incidentally, is also why most trainers far prefer off-site training courses).

We started on day one with Moose. Most of them had used “classic” Perl OO techniques and were well aware of how baroque that can become. They were therefore very interested in the more declarative approach that Moose gave them. By the end of the day our Dalek class was using roles, traits, type coercion and many other useful Moose features.

Day two was DBIx::Class. Everyone was using a database of some kind and all of them were using DBI to interface to their database. I really enjoy introducing people like that to DBIx::Class. Once they’ve run dbicdump and have generated classes for their own databases most people’s eyes light up when they see ho much easier their code can become. As a bonus, this class contained no-one who needed to be persuaded of the benefits of defining foreign keys in your DDL and making use of referential integrity checks.

The third day was testing. I mean, it was about testing – not that it was particularly difficult. The class was full of people who knew the benefits of testing but who were maintaining large codebases with hardly any (in some cases no) tests. In the morning we looked at how simple the Perl testing framework is, did a quick survey of some useful testing modules on CPAN and even looked at writing our own testing modules. In the afternoon we expanded that to look at mocking objects and Test::Class. I think the most popular sections were when I introduced Devel::Cover and the concept of continuous integration. I encouraged them to write even just a few tests and to hook their test suite up to a highly visible Jenkins job. If you make your lack of test coverage obvious, then other people in the team can be encouraged to help improve it out of sheer embarrassment.

Thursday was the first day of the two-day course on web development. The first day concentrated on PSGI and Plack. We looked at what they are and how they make web development simpler. We also looked at ways to run non-PSGI applications in a PSGI environment in order to benefit from PSGI’s advantages. This seemed to really engage a couple of people in the class who used a practical session at the end of the day to start working to get their own legacy apps running under PSGI. I was particularly pleased when, the next morning, one of them told me that he had continued to work on the problem overnight and that he had got a huge system that used a combination of CGI and mod_perl working under PSGI. He was really happy too.

On the final day, we looked at web frameworks in Perl. The morning was all about Dancer2. We started by building a small web app and I showed them how simple it was to interface with a database and to add authentication to the system. Later on we added an API to the app so that it could return JSON or XML instead of web pages. Early in the afternoon, I took that a step further and demonstrated Web::Machine and WebAPI::DBIC. The rest of the afternoon was about Catalyst. We built another app (similar to the Dancer on from the morning) using the standard Catalyst tutorial as a basis. I’m not sure how well this went, to be honest. Following the simplicity of Dancer with the (relative) complexity of Catalyst wasn’t, perhaps, the best advert for Catalyst.

But, all in all, I think the week went really well. I sent a small but enthusiastic group of people back to their offices with a new interest in using Modern Perl tools in their day-to-day work. And, perhaps more usefully, I think that many of them will be getting more involved in the Perl community. A few of them said “see you at the LPW” as they left.

I’m running a half-day workshop on Modern Perl Web Development at  the FlossUK Spring Conference next month. Other than that, I don’t have any public courses planned. But if you think that your company would find my training useful, then please get in touch.

Training Courses – More Details

Last week I mentioned the public training courses that I’ll be running in London next February. A couple of people got in touch and asked if I had more details of the contents of the courses. That makes sense of course, I don’t expect people to pay £300 for a days training without knowing a bit about the syllabus.

So here are details of the first two courses (the Moose one and the DBIx::Class one). I hope to have details of the others available by next weekend.

Object Oriented Programming with Perl and Moose

  • Introduction to Object Oriented programming
  • Overview of Moose
  • Object Attributes
  • Subclasses
  • Object construction
  • Data types
  • Delegation
  • Roles
  • Meta-programming
  • Further information

Database Programming with Perl and DBIx::Class

  • Brief introduction to relational databases
  • Introduction to databases and Perl
    • DBI
    • ORM
  • Schema Classes
  • Basic DB operations
    • CRUD
  • Advanced queries
    • Ordering, joining, grouping
  • Extending DBIC
  • Further information

If you have any further questions, please either ask them in the comments or email me (I’m dave at this domain).

And if I’ve sold you on the idea of these courses, the booking page is now open.

Public Training in London – February 2016

For several years I’ve been running an annual set of public training courses in London in conjunction with FLOSS UK (formerly known as UKUUG). For various scheduling reasons, we didn’t get round to running any this year, but we have already made plans for next year.

I’ll be running five days of training in central London from 8th – 12th February. The courses will take place at the Ambassador’s Hotel on Upper Woburn Place. Full details are in the process of appearing on the FLOSS UK web site, but the booking page doesn’t seem to be live yet, so I can’t tell you how much it will cost.

We’re doing something a little different this year. In previous years, I’ve been running two generic two-day courses – one on intermediate Perl and one on advanced Perl. This year we’re running a number of shorter but more focussed courses. The complete list is:

  • Object Oriented Programming with Perl and Moose (Mon 8th Feb)
  • Database Programming with Perl and DBIx::Class (Tue 9th Feb)
  • An Introduction to Testing Perl Programs (Wed 10th Feb)
  • Modern Web Programming with Perl (two day course – Thu/Fri 11th/12th Feb)

This new approach came out of some feedback we’ve received from attendees over the last couple of years. I’m hoping that by offering this shorter courses, people will be able to take more of a “mix and match” approach and will select courses that better fit their requirements. Of course, if you’re interested, there’s no reason why you shouldn’t come to all five days.

I’ll update this page when I know how much the courses will cost and how you can book. But please put these dates in your calendar.

Update: And less than 24 hours after publishing this blog post, the booking page has gone live.

Places are £300 a day (so £600 for the two-day course on web programming) and there’s a special offer of £1,320 for the full week.

Prices are cheaper (by £90 a day) for members. And given that an annual individual membership costs £35, that all sounds like a bit of a no-brainer to me.

Moose Course This Saturday

I’m running another Perl School this Saturday (6th April). This time the subject is Object Oriented Programming with Perl and Moose. I ran a two-hour taster version of this course at the London Perl Workshop back in November, but this is the full six-hour version. Tickets are £30 each.

The course is run at Google Campus on the outskirts of the City of London. There’s a full list of topics and a booking form over on the Perl School web site.

Perl School 3

Yesterday was the third Perl School. Twenty-one students converged on Google Campus in London and spend a day learning about Moose.

The day seemed to go well. People asked intelligent questions and seemed to understand what I was telling them. Hopefully the feedback forms will tell a similar story.

No more training now for a couple of months. But once Christmas is over, I’ll need to start thinking about Perl School 4 – which will be about DBIx::Class. Hope to see some of you there.

Perl School 3

The second Perl School course is just under four weeks away (and there are still tickets available) but it’s time to start looking ahead.

The third Perl School is going to be on 8th December. Like the others, it will be at Google Campus.  But this time the subject will be slightly different. The first two have been aimed at people who don’t know much Perl, but this one will be the first in a series for Perl programmers who might just not be completely up to date with the latest tools. This one is called “Object Oriented Programming with Perl and Moose”. Tickets are £30 and are available online. More details of the course are on the Perl School web site.

The more observant amongst you will have noticed that I’m giving a two-hour tutorial on Moose at the London Perl Workshop two weeks before this course. That tutorial will cover something like a quarter of the material in the full-day version.

 

Evolving Software with Moose

Last night I was speaking at the Milton Keynes Perl Mongers technical meeting. I gave a new talk about how Moose (and, in particular, Moose traits) make Perlanet easier to maintain and enhance. The slides are available on Slideshare.

Learning About Traits

I’ve been teaching basic Moose in my training courses for several years now. And, as I’ve mentioned before, I’ve been slowly converting some of my CPAN modules to use Moose. But there are still bits of Moose that I haven’t really needed to get to grips with.

One such area is Moose’s support for Traits. Oh, I knew vaguely what they were and I understood why you might use them. But I’d never implemented a system using traits, so my knowledge about how you’d actually use them was a bit shaky to say the least.

But over the last few days I’ve learned quite a lot about how to use traits. And I’ve had to learn it pretty quickly.

It all started a few weeks ago when I got a github pull request from Oliver Charles. Oliver had taken a fork of my Perlanet repository and had massively refactored the codebase so that all the clever bits were implemented as traits.

What this means is that the core Perlanet code is pretty dumb. In order to do anything really useful with it to need to add in some traits. There are traits to read the configuration from a YAML file, traits to carry out various kinds of cleaning of the input and a trait to produce the output using the Template Toolkit. There are also traits to handle caching and OPML generation. All in all it makes the code far nicer to work on.

Oh, and there’s a Perlanet::Simple module which uses all of the traits required to implement the Perlanet behaviour that users currently expect.

There were a few problems with Oliver’s initial version. Some of the dependencies weren’t quite right. But we soon fixed that and last week I finally released Perlanet 0.47 which implemented these changes.

Then I installed it on the server which hosts most of my planets. And everything broke.

So I’ve spent a lot of the weekend fixing these issues. Part of it was that Oliver’s changes assumed some configuration file changes that I hadn’t implemented. I changed his changes so that they worked with the existing configuration settings (we don’t want users having to change configuration files unnecessarily). Other changes were harder to track down. I particularly enjoyed one where no feeds were fetched unless the user turned on OPML support. I learned a lot about how traits worked by tracking that one down.

But it all seems to be fixed now. Perlanet version 0.51 is available on CPAN and it will hopefully be a lot easier to customise to your needs. I hope we’ll see a number of other Perlanet traits appearing over the next few months.

And, most importantly, I’ve learnt a lot about traits. I think I understand them now.

If you want to learn traits, I can highly recommend asking someone to implement traits in one of your projects. And it’s even better if they do it in a slightly broken way so that you need to debug it.

Moose or No Moose

I’ve known about Moose for some time.The first time I talked about it in a training course was at the Teach-In back in the summer of 2007. It’s been part of my training courses ever since.

But even though I was telling people about Moose in my training courses, I wasn’t really making use of it in my own code. Obviously as a freelancer, in my day-job I’m constrained to using whatever technologies my clients are using and I have yet to be paid to work on a project that is already using Moose (although I’ve suggested that a few clients switch to it).

That leaves my own code. Which is largely my CPAN modules. Until recently I hadn’t used Moose for any of them. The first one I released that used Moose was Guardian::OpenPlatform::API. That was a new module which used Moose right from the start. But I knew that eventually I’d want to go back and refactor my existing modules to use Moose wherever it was appropriate.

Having gone to YAPC::Europe this year, I was subjected to another week of people telling me face to face just how cool Moose was. So I decided that it was time to bite the bullet and start refactoring.

The next module I tried was Parse::RPM::Spec. I chose this for two reasons. Firstly, it’s very much an attribute-driven module. Apart from the initial parsing of the spec file, objects of this class exist simply to return the values of their attributes. This makes it a great match for Moose. In fact converting it to use Moose was largely a case of removing code. The second reason for choosing it was more pragmatic – as far as I know no-one is using the module so if I broke anything I wouldn’t have hordes of angry users on my back.

Impressed by how easily that conversion was I moved on to Array::Compare. This module holds a special place in my heart as it was my very first CPAN module. I don’t think it’s a particularly useful module. It’s algorithm is pretty basic and other than the project that I originally wrote it for I’ve never used it in any production code. I often use it to try out new techniques. I released version 2.00 on August 9th (the change of implementation seemed to justify bumping the major version number).

Yesterday I got an RT ticket asking me to stop using Moose. The ticket is pretty clear that for several uses (it specifically mentions command line usage) the extra overhead added by Moose leads to an unacceptable performance hit.

I’m not sure which way to go on this. As a developer I like using Moose. Moose makes it much easier to write object oriented code in Perl. And I think that over the next year or so more and more CPAN developers will be using Moose in their code. Already if you’re writing something reasonably complex in Perl there’s a good chance that you’ll be using a module that uses Moose. As time goes on the percentage of Perl code that relies on Moose will increase. But if it really imposes an unacceptable performance hit for smaller applications, do I really want to force developers into using Moose sooner than they want to?

I think I’m going to put on hold my plans to move stuff to Moose until I’ve thought this through a bit more. But I’d be interested in hearing other people’s opinions. If you’re a CPAN author, are you planning to move your modules to Moose. And if you’re an application developer, have you started to avoid CPAN modules which force you to use Moose?

Let me know what you think.

Update: Well, didn’t this entry start a lot of discussion? As well as the comments here, there have been a number of other posts that reference my post. Here are the ones I’ve seen (in no particular order):

I’ll add more as I come across them. Of course, the more discussion I see, the more unclear my decision becomes.

But thanks for the interest. The discussion has been fascinating.