Intended Audience

I thought I’d pretty much finished blogging about my upcoming Modern Web Development with Perl and Dancer training course. But a couple of days ago I saw a tweet that reminded me about an aspect that I’d completely forgotten.

And he’s right, of course. I haven’t mentioned that at all. Let’s put that right.

As it happens, yesterday I pretty much finished writing the slides for the course. So that means that I know what I’ll be covering and, therefore, what the attendees will need to know.

What You’ll Need To Know

To start with, I need to make it clear that this is not a “beginning Perl” course. There’s a lot of new topics to cover and if Perl itself was on the list then it would need to be a two or three day course.

So you’ll need to know Perl. But to what level?

If you’ve read Intermediate Perl then you’ll be fine. That means you’ll need to understand how to use modules, packages and references. Probably the most advanced Perl concept we’ll need is subroutine references. But, to be honest, if you’re not completely comfortable with them, that won’t be a problem.

You’ll need to know a bit about how web pages are made – so a little bit of HTML and CSS. We’ll be using Bootstrap to deal with most of our CSS, so you won’t need to do anything at all complicated with CSS. If you understand the difference between a class and an id in CSS terms then you’ll be fine.

We’ll be using quite a lot of Javascript – specifically jQuery with Mustache. I’m no Javascript expert, so it’s likely that many of the people in the class will know more than me. If you’ve never used jQuery, then I recommend that you spend a couple of hours looking into it before coming to the class. You don’t need to know anything about Mustache before the course.

There will be a database at the back-end of the app. I’ll be running MySQL (actually, probably MariaDB), but any of the popular database systems will work – just as long as Perl’s DBI supports it. I’ll supply SQL to set up the database and insert some test data and we’ll be using DBIx::Class which will remove the need to know any SQL. But it would be good if you were familiar with whatever database system you’re using – to the extent that you can run queries against your local database.

What You’ll Need to Bring

You’ll need a laptop. I’m assuming that we’ll have access to WiFi at the training venue, but it would be great if you could install as much as possible of the required software before the day – just so we save a bit of time.

My laptop runs Windows 10, but I do all of my development in a virtual machine running Fedora 24. I’m happy for you to work in Windows or OSX, but the level of support I can provide for people not running Linux will be limited.

You’ll need Perl installed. Linux and OSX will already have a version of Perl installed. For Windows users, I recommend Strawberry Perl. Get the most recent version of Perl that you can install. The current version is 5.24. I think my laptop has 5.22. Anything  earlier than 5.10 is unlikely to be particularly useful.

You’ll need some CPAN modules installed. These are all pretty common modules:

  • Dancer2
  • Dancer2::Plugin::DBIC
  • DBIx::Class
  • DBIx::Class::Schema::Loader
  • DBI
  • DBD::* (for whatever database you are using – e.g. DBD::mysql)
  • Moose
  • MooseX::NonMoose
  • MooseX::MarkAsMethods
  • DateTime
  • DateTime::Format::Strptime
  • Template

You’ll need a database server installed on your laptop. As I mentioned above, any of the popular database engines will work – but I’ll be using MariaDB. Make sure that you know how to start the database server and connect to it using a command line program.

You’ll need a Git client so that you can clone the Git repository that contains the source code for the course. You’ll want to ensure the the repository is cloned to your laptop before turning up to the course. You might even want to glance through some of the code to get a head-start on the rest of the attendees.

You can find the course code at

The CSS and Javascript libraries are all included in the Git repository.

I think that’s about all you need to know. Please let me know if you have any further questions.

I’ve been really pleased with the reaction to this course. We already have a large number of people signed up. So many, in fact, that I need to start thinking about the number of people I have room for. I think we can get another five (perhaps ten) people in. So if you’re thinking of signing up, please do it soon to avoid disappointment (trainers say stuff like this for every course – but this time it’s really true).

Hope to see some of you in Cluj-Napoca.

Modern Web Development with Perl and Dancer2

Here are some more details of the Modern Web Development with Perl and Dancer2 course that I’ll be running in Cluj-Napoca on the day before YAPC Europe.

The course runs a full day (that’s six hours – in four 90-minute sessions with breaks in between). It’s a hands-on course – you’ll need to bring a laptop and closer to the time I’ll email attendees with details of the software they will need to have installed. Like all of the pre-conference training, the course will take place at Cluj Hub on Tuesday 23rd August.

Over the course of twelve steps, we’ll build a simple Todo list program. We’ll be using a number of modern web development techniques (not just Perl) in order to make the app look really shiny and modern.

The twelve steps we will be taking are as follows:

  1. Set up a basic Dancer2 app
  2. Make it look nicer with the addition of the Bootstrap CSS framework
  3. Use Plack Middleware to serve static content more efficiently
  4. Display some data in our app
  5. Get the data from a database
  6. Return the data as JSON and display it using Mustache
  7. Use jQuery to show/hide completed items
  8. Mark items as completed
  9. Add new tasks to the app
  10. Add user login
  11. Edit and delete tasks
  12. Add tags to tasks and filter the display on those tags

If there’s time left at the end, we’ll discuss other useful enhancements that we might want to make to the app – and perhaps even try adding them.

We’ll be using the following Perl tools:

And the following non-Perl tools:

Usually, a course like this would cost around £300. But because it’s at YAPC and the sponsors are so generous, we can offer it for the heavily discounted price of 100€.

Cluj Hub sounds like a fabulous venue for the training courses and I’m sure that the day will be a lot of fun. Perhaps more importantly, I’m also sure that attendees will come away with some useful skills to add to their CVs.

Tickets are on sale now. Please buy quickly – before they sell out.

Easy PSGI

When I write replies to questions on StackOverflow and places like that recommending that people abandon CGI programs in favour of something that uses PSGI, I often get some push-back from people claiming that PSGI makes things far too complicated.

I don’t believe that’s true. But I think I know why they say it. I think they say it because most of the time when we say “you should really port that code to PSGI” we follow up with links to Dancer, Catalyst or Mojolicious tutorials.

I know why we do that. I know that a web framework is usually going to make writing a web app far simpler. And, yes, I know that in the Plack::Request documentation, Miyagawa explicitly says:

Note that this module is intended to be used by Plack middleware developers and web application framework developers rather than application developers (end users).

Writing your web application directly using Plack::Request is certainly possible but not recommended: it’s like doing so with mod_perl’s Apache::Request: yet too low level.

If you’re writing a web application, not a framework, then you’re encouraged to use one of the web application frameworks that support PSGI (http://plackperl.org/#frameworks), or see modules like HTTP::Engine to provide higher level Request and Response API on top of PSGI.

And, in general, I agree with him wholeheartedly. But I think that when we’re trying to persuade people to switch to PSGI, these suggestions can get in the way. People see switching their grungy old CGI programs to a web framework as a big job. I don’t think it’s as scary as they might think, but I agree it’s often a non-trivial task.

Even without using a web framework, I think that you can get benefits from moving software to PSGI. When I’m running training courses on PSGI, I emphasise three advantages that PSGI gives you over other Perl web development environments.

  1. PSGI applications are easier to debug and test.
  2. PSGI applications can be deployed in any environment you want without changing a line of code.
  3. Plack Middleware

And I think that you can benefit from all of these features pretty easily, without moving to a framework. I’ve been thinking about the best way to do this and I think I’ve come up with a simple plan:

  • Change your shebang line to /usr/bin/plackup (or equivalent)
  • Put all of your code inside my $app = sub { ... }
  • Switch to using Plack::Request to access all of your input parameters
  • Build up your response output in a variable
  • At the end of the code, create and return the required Plack response (either using Plack::Response or just creating the correct array reference).

That’s all you need. You can drop your new program into your cgi-bin directory and it will just start working. You can immediately benefit from easier testing and later on, you can easily deploy your application in a different environment or start adding in middleware.

As an experiment to find how easy this was, I’ve been porting some old CGI programs. Back in 2000, I wrote three articles introducing CGI programming for Linux Format. I’ve gone back to those articles and converted the CGI programs to PSGI (well, so far I’ve done the programs from the first two articles – I’ll finish the last one in the next day or so, I hope).

It’s not the nicest of code. I was still using the CGI’s HTML generation functions back then. I’ve replaced those calls with HTML::Tiny. And they aren’t very complicated programs at all (they were aimed at complete beginners). But I hope they’ll be a useful guide to how easy it is to start using PSGI.

My programs are on Github. Please let me know what you think.

If you’re interested in modern Perl Web Development Techniques, you might find it useful to attend my upcoming two-day course on the subject.

Update: On Twitter, Miyagawa reminds me that you can use CGI::Emulate::PSGI or CGI::PSGI to run CGI programs under PSGI without changing them at all (or, at least, changing them a lot less than I’m suggesting here). And that’s what I’d probably do if I had a large amount of CGI code that I wanted to to move to PSGI quickly. But I still think it’s worth showing people that simple PSGI programs really aren’t any more complicated than simple CGI programs.

Perl APIs

For a lot of programmers out there, Perl has become largely invisible. They just never come across it. That might seem strange to you as you sit inside the Perl community echo chamber reading the Perl Ironman or p5p, but try this simple experiment.

Think of a web site that you use and that supplies an API. Now go to that API’s documentation and look at the example code. What languages are the examples written in? PHP? Almost certainly. Ruby? Probably. Python? Probably. C#? Quite possibly. Perl? Almost certainly not[1].

Perl has fallen so far off the radar of most people that when web sites write example code for these APIs, they very rarely consider Perl as a language worth including. And because they don’t bother including Perl then any random programmer coming to that API will assume that the API doesn’t support Perl, or (at the very least) that the lack of examples will make using Perl harder than it would be with plenty of examples to copy from.

This then becomes a self-fulfilling prophecy as Github fills with more and more projects using other languages to talk to these APIs. And the chance of anyone who isn’t already a Perl user ever trying to interact with these APIs using Perl falls and falls.

Of course, this is all completely wrong. These APIs are just going to be a series of HTTP requests using REST or XML-RPC (or, if you’re really unlucky, SOAP). Perl has good support for all of that. You might need to use something like OAuth to get access to the API – well Perl does that too.

Of course, in some cases good Perl support exists already – Net::Twitter is a good example. And to be fair to Twitter, their API documentation doesn’t seem to give any examples in specific languages – so Perl isn’t excluded here. But in many other cases, the Perl version languishes unnoticed on CPAN while other languages get mentioned on the API page.

I think that we can try to address this in 2014. And I’d like to ask you to help me. I’ve set up a mailing list called perl-api-squad where we can discuss this. In a nutshell, I think that the plan should be something like this:

  1. Identify useful APIs where there is either no Perl API or no Perl examples
  2. Write CPAN API wrappers where they are missing
  3. Approve API owners and offer them Perl examples to add to their web site

That doesn’t sound too complicated to me. And I think (or, perhaps, hope) that most API owners will be grateful to add more examples of API usage to their site – particularly if it involves next to no effort on their part.

I also expect that the Perl API Squad will produce a web site that lists Perl API support. We might even move towards producing a framework that makes it easy to write a basic Perl wrapper around any new API.

What do you think? Is this a worthwhile project? Who’s interested in joining in?

[1] Yes, I know there are exceptions. But they are just that – exceptions.

Just Build Something

The Political Web

About a month ago, JT Smith suggested that we should all stop talking about Perl and just build something. And, purely coincidentally, over the last few weeks I resurrected a project that I have been poking at for about five years and have finally turned it into something that I’m happy to show the world.

The Political Web is a site which aggregates all of the information I can find on the web about individual British MPs. I say “all of the information”, but that’s obviously a bit of a work in progress. But I think that what I already have is useful and interesting – well, for people who are interested in British politics. I have plans to bring in more information in the future.

Although I’ve been working on the site for five years, I pretty much rebuilt it from scratch when I recently returned to it. Actually getting something useful up and running took about four hours. That’s because I was building it using Perl and, more specifically, Dancer.