Programming Language Usage

Back in May, I spent an afternoon at Silicon MilkRoundabout. Silicon MilkRoundabout is a recruitment fair for techies. It’s specifically aimed at people who want to work for start-ups around the Old Street area (although they aren’t particularly stringent about sticking to that – for example, the BBC were there).

We were given a booklet containing details of all of the companies who were recruiting. Those details usually included information about the tech stack that the companies used.

Over the weekend, I went through that booklet and listed the programming languages mentioned by the companies. The results speak for themselves.

There were 135 companies at the event. About twenty of them unhelpfully listed their tech stack as “ask us for details”.

Here’s the graph:Usage of Programming Languages by Companies at Silicon MilkRoundabout

Usage of Programming Languages by Companies at Silicon MilkRoundabout

I’ll obviously have some more to say about this over the next few days. But I wanted to get the raw data out there as soon as possible.

Github, Travis-CI and Perl

Last night we held a London Perl Mongers Technical Meeting. It was organised by Sue Spence and the venue was sponsored by Rick Deller of Eligo.

Much fun was had and much knowledge was imparted. Alex Balhatchet spoke about Test::Kit. Andrew Solomon talked about training people in Perl. Thomas Klausner introduced OX and AngularJS. And Mike Francis talked about using Web::Simple and Web::Machine to build a REST interface to a database – only to be told that Tim Bunce had just released a module that solved all of his problems.

Oh, and I wittered on a bit about using Perl with Github and Travis-CI. The slides are below.

Thanks to everyone for organising, speaking or just coming along.

London Perl Workshop

The London Perl Workshop 2014 has been announced. It will be at the University of Westminster (the usual location) on Saturday 8th November. That’s a few weeks earlier in the year than it usually is.

The theme for this year is “The Internet of Things”.

You can find out more about the workshop, register and propose talks at the web site. Hope to see many of you there.

Many thanks (as always) to Mark Keating for organising the workshop.

London Perl Mongers Meeting

I thought you might be interested in a couple of events that the London Perl Mongers have coming up in the next couple of months.

Technical Meeting

24th July 2014, Conway Hall
Currently, four talks have been announced.

  • Thomas Klausner (domm) from Vienna.pm is going to talk about OX & AngularJS
  •  Alex Balhatchet is going to talk about his rewrite of Ovid’s Test::Kit module
  • Mike Francis will tell us about creating a RESTful database frontend with Web::Simple & Web::Machine and how annoying that was
  • Dave Cross will natter about Github, Travis-CI and Perl

Meetup event / Facebook event / Lanyrd event

Hackday

20th September 2014, London Hackspace
This is a new experiment for us. Do you want to hang out with some Perl Mongers and hack on one of your current projects? Or do you want to find a Perl project to hack on? Then come and join us at the London Hackspace in September.

Meetup event / Facebook event / Lanyrd event

Hope to see you at one or both of these event.

Perl School Slides

In 2012 and 2013 I ran an experiment called Perl School. I ran cheap Perl training on a Saturday at Google Campus. I got some great reactions but I stopped it after almost a year because it wasn’t getting the traction that I hoped for and attendances were starting to drop.

That’s not the end of Perl School though. I have a couple of ideas that I’m considering and it will return at some point (in some form).

But I thought that the courses were good. And I realised earlier today that I hadn’t made some of the slides public. So I uploaded them to Slideshare and they are embedded below.

Let me know if you find them interesting or useful.

Training in London

For many years now a regular feature of my training calendar has been the annual public courses that I have run in London in conjunction with FlossUK. Normally these happen in February, but this year I had to postpone them as I was in the USA for a lot of February.

But FlossUK still wanted to do them, so we’ve arranged to run the courses in November instead. There will be two two-day courses which will be held at the Ambassadors Hotel in central London.

For full details (and soon, I hope, a booking form) see the FlossUK web site.

 

Data Munging with Perl

Data Munging with PerlMany years ago, I wrote a book called Data Munging with Perl. People were kind enough to say nice things about it. A few people bought copies. I made a bit of money.

Recently I re-read it. I thought that some of it was still pretty good. There were some bits, particularly in the early chapters, that talked about general principles that are still as relevant as they were when the book was published.

There were other bits that haven’t aged quite as well. The bits where I talk about particular CPAN modules are all a bit embarrassing as Perl fashions change and newer, better modules are released. Although it was still available from Amazon, I really didn’t want people paying for it as a lot of it was really out of date.

But today I got an interesting letter from the publishers, telling me that they have taken the book out of print. And that all  the rights in the book have reverted to me. Which means that I can now distribute it in any way that I like. And people don’t have to pay a lot of money for a rather out of date book.

So, you can download a PDF of the book from http://perlhacks.com/dmp.pdf. Or I’ve embedded the book below.

I might even have the original documents somewhere. So if I get some spare time I might be able to produce a more reasonable ebook version (but don’t hold your breath!)

Let me know if you find it useful.

Installing Modules

If you’ve seen me giving my “Kingdom of the Blind” lightning talk this year, then you’ll know that I’ve been hanging around places like the LinkedIn Perl groups and StackOverflow trying to help people get the most out of Perl. It can be an “interesting” experience.

One of the most frequent questions I see is some variant of “I have found this program, but when I try to run it I get an error saying it can’t find this module”. Of course, the solution to this is simple. You tell them to install the missing module. But, as always, the devil is in the detail and I think that in many cases the answers I seen could be improved.

Most people seem to leap in and suggest that the original poster should install the module using cpan (advanced students might suggest cpanminus instead). These are, of course, great tools. But I don’t think this is the best answer in to these questions.

In most cases, the people asking questions are new to Perl. In some cases they don’t even want to learn any Perl – they just want to use a useful program that happens to be written in Perl. I think that launching these people into the CPAN ecosystem is a bad idea. Yes, eventually, it would be good to get them using perlbrew, local::lib and cpanminus. But one step at a time. First let’s show them how easy it can be to use Perl.

In many of these cases, I think that the best approach is to suggest that they use their native package manager to install a pre-packaged version of the required module.

Yes, I know the system Perl is evil and outdated. Yes, I know that they probably won’t get the latest and greatest version of your CPAN module from apt-get or yum.  And, yes, I know there’s a chance that the required module won’t be available from the package repositories. But I still think it’s worth giving it a try. Because in most cases the module will be  there and available as a recent enough version that it will solve their immediate problem and let them get on with their work.

There are three main reasons for this suggestion:

  1. People in this situation will almost certainly be using the system Perl anyway. And the  system Perl will already have pre-packaged modules installed alongside it. And installing modules using cpanminus alongside pre-packaged modules in the same library installation is a recipe for disaster. The package manager no longer knows what’s installed or what versions are installed and hilarity ensues.
  2. The pre-packaged versions will know about non-Perl requirements for the CPAN module and will pull those in as well as other required CPAN modules. One of the most common requests I see is for GD or one of its related modules. Your package manager will know about the underlying requirement for  libgd. cpanminus and friends probably won’t.
  3. The user is more likely to be used to using their package manager. Teaching them about the CPAN ecosystem can come later. Let’s ease them into using Perl by starting them off with tools that they are familiar with.

I know that both Fedora/Centos/RHEL and Ubuntu/Debian have large numbers of CPAN modules already pre-packaged for easy installation. Let’s suggest that people make use of this work to get up and running with Perl quickly. Later on we can show the the power and flexibility that comes with using the Perl-specific tools.

Of course there’s then a debate about when (and how) we start to wean these people off of the system Perl and pre-build packages and on to perlbrew/cpanminus/etc. But I think that having a community of people who are used to using CPAN modules (albeit in this slightly restricted manner) is an improvement on the current situation where people often avoid CPAN completely because module installation is seen as too difficult.

What do you think? Are there obvious errors in my thinking?

The Return of blogs.perl.org

About an hour ago we turned blogs.perl.org back on. There’s also a blog post where we explain what happened in a lot more detail.

If you have an account on the site then you will have received an email explaining what you need to do now. Basically, we’ve invalidated all of the passwords so you’ll need to ask the system for a new one.

Sorry again for the inconvenience. And huge thanks to the rest of the blogs.perl.org team (particularly Aaron Crane) for fixing this.

blogs.perl.org

It seems that last night blogs.perl.org was hacked. I first became aware of it when someone pointed me at this story a few hours ago. As you’ll see, the contents of the mt_author table have been made public.

We’re still investigating the extent of the hack. But, as a precaution, we have configured the site so that all dynamic pages return a 404 response. This will, unfortunately, prevent you from logging on to the site.

We will publish more information when we have it.

Apologies for the inconvenience.

Update:

  • As I said, the mt_author table was leaked
  • This contains both your username and password
  • The password is salted and encrypted (with crypt)
  • If you use your blogs.perl.org password elsewhere, we strongly recommend that you change it

Update 2:
Here’s a cut-down version of the published data that includes only the name columns. Hopefully you can use this to work out whether or not you have an account on the system.