The talk is about Damian Conway’s module Lingua::EN::Inflexion and how it makes programmers’ lives easier. As part of the talk, I invented a logo for the fictional DamianWare brand. DamianWare is, of course, a brand that specialises in using deep Perl magic in order to produce tools that help Perl programmers be lazier.
It was just a joke. A throwaway visual to make a point in the presentation. But after the talk Mallory approached me and suggested that the logo would look great on a t-shirt which was sold to benefit The Perl Foundation. I couldn’t really argue with that.
And, having emailed him overnight, it turns out that Damian agrees it’s a good idea too.
So the shirts (and a couple of other things) are now available on Spreadshirt (currently the UK version, I’ll try to make them more widely available as soon as possible).
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.
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.
@perlhacks could you give a few details about the intended audience? Perl level? Familiarity with x? Etc?
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.
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:
DBD::* (for whatever database you are using – e.g. DBD::mysql)
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.
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).
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:
Set up a basic Dancer2 app
Make it look nicer with the addition of the Bootstrap CSS framework
Use Plack Middleware to serve static content more efficiently
Display some data in our app
Get the data from a database
Return the data as JSON and display it using Mustache
Use jQuery to show/hide completed items
Mark items as completed
Add new tasks to the app
Add user login
Edit and delete tasks
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.
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.
Last night, I uploaded a new version of Ogg::Vorbis::Header – a CPAN module that hasn’t been updated since 2003 and which I strongly suspect no-one at all uses any more. You might be interested to hear what I did or why I did it.
About a year ago, I wrote about the dashboard I had written for my CPAN modules. It’s a simple page that pulls together information about all of my modules and, among other things, shows me how they are doing on Travis CI and Coveralls.
One of the aims of the dashboard was to encourage me to do more work ensuring that my CPAN modules were working well and had good test coverage. The idea was that if I’m constantly looking at a page which shows how rubbish the test coverage for a module is, then I’ll be more motivated to fix it. Of course, that only works if I’m constantly looking at the dashboard and, to be honest, over the year since I built it I really haven’t taken much notice of it.
But recently, I was reminded of its existence as I updated it to remove some modules that I’ve handed over to other people and to add a couple of new modules I had released. And, in doing that, I took a closer look at it and my attention was drawn to AudioFile::Info::Ogg::Vorbis::Header. This is the only one of my modules which doesn’t even build on Travis. Clearly, more investigation was needed. But, before we get into that, it’s probably worth making a brief digression to explain what the module does.
Some of you will be too young to remember this, but there was a time back in the early middle ages of internet history (so, perhaps, fifteen years ago) when not everyone listened to music as MP3s. Back then, one of the biggest sources of digital music for many people was ripping their existing CDs (ask your parents – they might still have a CD or two they can show you). And when ripping music from CDs we had a choice of formats. Most people (even then) were using MP3, but some of us took the ideologically superior option of ripping to OggVorbis. The main reason was that MP3 format was patented, but Ogg Vorbis was completely free.
All of this meant that in the first five or six years of the 21st century, I ended up with hundreds (maybe thousands) of Ogg Vorbis files on my hard disk. This immediately gave me problems as it dramatically limited the devices that I could play my music on. For example, it probably explains why I’ve never owned an iPod.
But I also… er… acquired a number of MP3s over the same time. And, being a geek, at times I wanted to write programs that gathered information about all of my music, no matter what format it was stored in. There were modules on CPAN for dealing with MP3s and there were modules on CPAN for dealing with Ogg Vorbis files. But (as is so often the way with these things) all of these modules worked in completely different ways.
And that’s I wrote the AudioFile::Info set of modules. They acted as a wrapper around the various modules for dealing with the different audio formats and gave them all the same interface. It meant that I could write programs that got information from any of my audio files and I didn’t need to care what format they were in. Think of them a bit like a DBI for audio file formats.
Of course, no-one else ever had any use for them. And soon afterwards MP3 became the de-facto standard for digital audio and Ogg Vorbis was relegated to the same (virtual) drawer as Betamax. I’d say that no-one uses it any more – but I suspect there are actually about eight users left and they would all write comments telling me that I was wrong.
None of the AudioFile::Info modules have been updated for a very long time, because no-one uses them any more and no-one cares about them. I’d remove them from CPAN, but that goes against my pack-rat nature.
All of which leaves me annoyed by the failure of AudioFile::Info::Ogg::Vorbis::Header to build on Travis. So a couple of weeks ago, I investigated further. And, to my delight, I found that it wasn’t my fault. Actually, it was the underlying module (Ogg::Vorbis::Header) that had the problem. That module no longer built successfully on modern Perls. And that failure prevented my module from building on top of it.
The problem is described in this RT ticket. Basically, there was some very funky syntax in a test. Syntax that became a fatal error through some parser fixes in Perl 5.22. The test looked like this:
When it should have looked like this:
In the RT ticket, H. Merijn Brand gives a good explanation of how the test ever passed – but try working it out for yourself before looking.
So, anyway, I knew what the problem was and I knew how to fix it. My next step was to pass this information on to the author of the module. I emailed him a couple of weeks ago, offering to make the fixes myself if he was too busy (or too uninterested) to do it himself. I got no reply, so at the end of last week I emailed the CPAN Powers That Be explaining the situation and asking for co-maintenance rights on the module so that I could fix the problem. They granted my request – which is why the new version was released yesterday. I can already see that the tests for this version look a lot healthier than the ones for the previous version.
Healthier, but still not as healthy as I’d like them. Within an hour or so of my release hitting CPAN, this issue was raised. The Makefile.PL uses Inline::MakeMaker and I can’t work out how to make that work, given that the “use” statement is executed long before any of the configuration code that tells the build tools what modules are required. If you have any suggestions, please let me know (or send me a pull request). I’m a bit out of my depth when it comes to Inline-based modules.
There are a few other things that I might fix. It’s an old-style distribution where there are no /lib or /t directories. It’s all in the top-level directory. I’m very tempted to move all that stuff around.
But really, I should get back to ensuring that my module builds successfully now.
Update: On Sunday, I released another version of Ogg::Vorbis::Header which fixed the packaging problems. But it still hasn’t solved my Travis-CI woes and there are still a disappointing number of failures on CPAN testers (actually they are “unknown” results rather than real failures – because there are still cases where the module won’t even build).
The problem is the underlying C libraries. Ogg::Vorbis::Header relies on the libogg and libvorbis libraries. And a large number of people aren’t going to have those libraries installed (the Travis-CI environment certainly doesn’t). Trying to build the module on a system that doesn’t have those libraries is doomed to failure.
The solution is, I suspect, to build Alien modules for these two libraries. But that’s something that I know very little about. I doubt I’ll have the time to learn a whole new area of CPAN packaging until after YAPC Europe at the earliest. Of course, if some kind person who knows more about this area than me was to offer to help (or even to produce the Alien modules for me) then that would make me very happy 🙂