Cultured Perl

Back in about 2008, I set up a group blog called “Cultured Perl”. The idea was to have a blog that concentrated on the Perl community rather than the technical aspects that most Perl bloggers write about most of the time. It didn’t last very long though and after a few posts it quietly died. But the name “Cultured Perl” still appeals to my love of bad puns and I knew I would reuse it at some point.

At YAPC Europe 2010 in Pisa, I gave a lightning talk called Perl Vogue. It talked about the way the Perl modules come into fashion and often go out of fashion again very quickly. I suggested an online Perl magazine which would tell people which modules were fashionable each month. It was a joke, of course (not least because Vogue are famously defensive of their brand.

Over the last many years people have suggested that the Perl community needs to get “out of the echo chamber” and talk to people who aren’t part of the community. For example, instead of posting and answering Perl questions on a Perl-specific web site like Perl Monks, it’s better to do it on a general programming site like Stack Overflow.

Hold those three thoughts. “Cultured Perl”, online Perl magazine, getting out of the echo chamber.

Medium is a very popular blogging site. Many people have moved their blogging there and it’s a great community for writing, sharing and recommending long-form writing. I get a “recommended reading” email from Medium every day and it always contains links to several interesting articles.

Medium has two other features that interest me. Firstly, you can tag posts. So if you write a post about web development using Perl and tag it with “web dev” then it will be seen by anyone who is following the web dev tag. That’s breaking out of the echo chamber.

Secondly, Medium has “publications”. That is, you can bring a set of articles together under your own banner. Publication owners can style their front page in various ways to differentiate it from Medium’s default styling. Readers can subscribe to publications and they will then be notified of every article published in that publication. That’s an online magazine.

So I’ve set up a publication on Medium (called “Cultured Perl” – to complete the set of three ideas). My plan is to publish (or republish) top quality Perl articles so we slowly build a brand outside of the echo chamber where people know they can find all that is best in Perl writing.

If you write about Perl, please consider signing up to Medium, becoming a contributor to Cultured Perl and submitting your articles for publication. I’ll publish the best ones (and, hopefully, work with authors to improve the others so they are good enough to publish).

I’m happy to republish stuff from your other blogs. I’m not suggesting that we suddenly move all Perl blogging to Medium. For example, whenever I publish something on Perl Hacks, the post gets mirrored to a Perl Hacks publication that I set up on Medium earlier this year. There’s a WordPress to Medium plugin that does that automatically for me. There may well be similar tools for other blogging platforms (if you can’t find one for your blog – then Medium has an API so you could  write one).

If you are a reader, then please consider subscribing to Cultured Perl. And please recommend (by clicking on the heart symbol) any articles that you enjoy. The more recommendations that an article gets, the more likely it becomes that Medium will recommend it to other readers.

I have no idea how this will go, but over the next few months I hope to start by publishing four or five articles every week. Perhaps you could start by submitting articles about what a great time you had at YAPC Europe.

Oh, and here are the slides from the lightning talk I used to announce this project at YAPC Europe in Cluj-Napoca, Romania yesterday.

 

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.

The Joy of Prefetch

If you heard me speak at YAPC or you’ve had any kind of conversation with me over the last few weeks then it’s likely you’ve heard me mention the secret project that I’ve been writing for my wife’s school.

To give you a bit of background, there’s one afternoon a week where the students at the school don’t follow the normal academic timetable. On that afternoon, the teachers all offer classes on wider topics. This year’s topics include Acting, Money Management and Quilt-Making. It’s a wide-ranging selection. Each student chooses one class per term.

This year I offered to write a web app that allowed the students to make their selections. This seemed better than the spreadsheet-based mechanisms that have been used in the past. Each student registers with their school-based email address and then on a given date, they can log in and make their selections.

I wrote the app in Dancer2 (my web framework of choice) and the site started allowing students to make their selections last Thursday morning. In the run-up to the go-live time, Google Analytics showed me that about 180 students were on the site waiting to make their selections. At 7am the selections part of the site went live.

And immediately stopped working. Much to my embarrassment.

It turned out that a disk failed on the server moments after the site went live. It’s the kind of thing that you can’t predict.But it leads to lots of frustrated teenagers and doesn’t give a very good impression.

To give me time to rebuild and stress-test the site we’ve decided to relaunch at 8pm this evening. I’ve spent the weekend rebuilding the app on a new (and more powerful) server.

I’m pretty sure that the timing of the failure was coincidental. I don’t think that my app caused the disk failure. But a failure of this magnitude makes you paranoid, so I spent a lot of yesterday tuning the code.

The area I looked at most closely was the number of database queries that the app was making. There are two main actions that might be slow – the page that builds the list of courses that a student can choose from and the page which saves a student’s selections.

I started with the first of these. I set DBIC_TRACE to 1 and fired up a development copy of the app. I was shocked to see the app run about 120 queries – many of which were identical.

Of course I should have tested this before. And, yes, it’s an idiotic way to build an application. But I’m afraid that using an ORM like DBIx::Class can make it all too easy to write code like this. Fortunately, it makes it easy to fix it too. The secret is “prefetch”.

“Prefetch” is an option you can pass to the the “search” method on a resultset. Here’s an example of the difference that can make.

There are seven year groups in a British secondary school. Most schools call them Year 7 to Year 13 (the earlier years are in primary school). Each year group will have a number of forms. So there’s a one to many relationship between years and forms. In database terms, the form table holds a foreign key to the year table. In DBIC terms, the Year result class has a “has_many” relationship with the Form result class and the Form result class has a “belongs_to” relation with the Year result class.

A naive way to list the years and their associated forms would look like this:

Run code like that with DBIC_TRACE turned on and you’ll see the proliferation of database queries. There’s one query that selects all of the years and then for each year, you get another query to get all of its associated forms.

Of course, if you were writing raw SQL, you wouldn’t do that. You’d write one query that joins the year and form tables and pulls all of the data back at once. And the “prefetch” option gives you a way to do that in DBIC as well.

All we have done here is to interpose a call to “search” which adds the “prefetch” option. If you run this code with DBIC_TRACE turned on, then you’ll see that there’s only one database query and it’ll be very similar to the raw SQL that you would have written – it brings back the data from both of the tables at the same time.

But that’s not all of the cleverness of the “prefetch” option. You might be wondering what the difference is between “prefetch” and the rather similar-sounding “join” option. Well, with “join” the columns from the joined table would be added to your main table’s result set. This would, for example, create some kind of mutant Year resultset object that you could ask for Form data using calls like “get_column(‘forms.name’)”. [Update: I was trying to simplify this explanation and I ended up over-simplifying to the point of complete inaccuracy – joined columns only get added to your result set if you use the “columns” or “select/as” attributes. And the argument to “get_column()” needs to be the column name that you have defined using those options.] And that’s useful sometimes, but often I find it easier to use “prefetch” as that uses the data from the form table to build Form result objects which look exactly as they would if you pulled them directly from the database.

So that’s the kind of change that I made in my code. By prefetching a lot of associated tables I was able to drastically cut down the number of queries made to build that course selection page. Originally, it was about 120 queries. I got it down to three. Of course, each of those queries is a lot larger and is doing far more work. But there’s a lot less time spent compiling SQL and pulling data from the database.

The other page I looked at – the one that saves a student’s selections – wasn’t quite so impressive. Originally it was about twenty queries and I got it down to six.

Reducing the number of database queries is a really useful way to make your applications more efficient and DBIC’s “prefetch” option is a great tool for enabling that. I recommend that you take a close look at it.

After crowing about my success on Twitter I got a reply from a colleague pointing me at Test::DBIC::ExpectedQueries which looks like a great tool for monitoring the number of queries in your app.

Beginners Perl Tutorial

A few weeks ago I got an interesting email from someone at Udemy. They were looking for someone to write a beginners Perl tutorial that they would make available for free on their web site. I think I wasn’t the only person that they got in touch with but, after a brief email conversation, they asked me to go ahead and write it.

It turned out to be harder that I thought it would be. I expected that I could write about 6,000 words over a weekend. In the end it took two weekends and it stretched to over 8,000 words. The problem is not in the writing, it’s in deciding what to omit. I’m sure that if you read it you’ll find absolutely essential topics that I haven’t included – but I wonder what you would have dropped to make room for them.

But eventually I finished it, delivered it to them (along with an invoice – hurrah!) and waited to hear that they had published it.

Yesterday I heard that it was online. Not from Udemy (they had forgotten to tell me that it was published two weeks ago) but from a friend.

Unfortunately, some gremlins had crept in at some point during their publication pipeline. Some weird character substitutions had taken place (which had disastrous consequences for some of the Perl code examples) and a large number of paragraph breaks had vanished. But I reported those all to Udemy yesterday and I see they have all been fixed overnight.

So finally I can share the tutorial with you. Please feel free to share it with people who might find it useful.

Although it’s 8,000 words long, it really only scratches the surface of the language. Udemy have added a link to one of their existing Perl courses, but unfortunately it’s not a very good Perl course (Udemy don’t seem to have any very good Perl courses). I understand why they have done that (that is, after all, the whole point of commissioning this tutorial – to drive more people to pay for Perl courses on tutorial) but it’s a shame that there isn’t anything of higher quality available.

So there’s an obvious hole in Udemy’s offerings. They don’t have a high quality Perl course. That might be a hole that I try to fill when I next get some free time.

Unless any other Perl trainers want to beat me to it.

Oh, and please let me know what you think of the tutorial.