meta::hack is back!

For the third year running, we have the privilege of working out of the ServerCentral offices in downtown Chicago in order to hack on MetaCPAN. This year, five of us will be working on improving our corner of the Perl ecosystem. The physical attendee list is follows:

  • Doug Bell
  • Joel Berger
  • Olaf Alders
  • Mickey Nasriachi
  • Shawn Sorichetti

This, of course, would not be possible without the help of our 2018 sponsors: and ServerCentral. You’ll notice their logos on the front page of MetaCPAN into 2019 as our way of thanking them for their support.

I’d like briefly to revisit last year’s event, which was quite productive and would not have happened without our 2017 sponsors:

In 2017, we made excellent progress on various fronts. Part of this progress came via an onsite visit from Panopta, our monitoring sponsor. They have a Chicago office and were very responsive when I asked them if they’d be willing to send someone down to chat with us about improving our Panopta configuration. So, Shabbir kindly dropped by, giving us in-person advice on how to configure our Panopta monitoring. One of the most helpful tweaks was setting up an IRC integration, so that outages are now broadcast to #metacpan on

Here’s a photo of Shabbir’s visit. (I wasn’t able to attend in person last year, but I was able to do so remotely. I’m the one watching from the wall.)

meta::hack v2 in 2017

From left to right:

Doug Bell, Thomas Sibley, Nicolas Rochelemagne, Graham Knop, Leo Lapworth (front), Joel Berger, Brad Lhotsky, Olaf Alders (pictured on monitor), Shabbir Karimi (from Panopta) and Mickey Nasriachi.

I’ll post more about our progress over the next few days. We’re working on some fixes and something new and shiny too. Wish us luck!

vim, Ale, Syntastic and Perl::Critic

As a vim user, I’ve used Syntastic for a long time. It’s a great tool for syntax checking. However, I was recently introduced to Ale. Ale does a lot of what Syntastic does, but it does it asynchronously. The practical benefits are

  • You should experience less lag when editing large files
  • Ale flags problematic lines containing errors and warnings in a gutter, making it easy to find problems
  • Detailed information about errors and warnings appear at the bottom of your buffer

I may actually be underselling it. Ale is almost a drop-in replacement for Syntastic. (At least it was for me). Try it out. I don’t think you’ll go back to Syntastic once you’ve tried Ale.

Ale Configuration

let g:ale_perl_perl_options = '-c -Mwarnings -Ilib -It/lib'

This is what I’m currently using. (Note the Ale defaults to -c -Mwarnings -Ilib). Often I’m working with a t/lib directory. Having this included by default means less chance of my code not compiling when it’s run by Ale. Of course, pass in any flags which you may require here. You’ll likely want to keep the -c since you want to compile the code rather than run it. Keep in mind that code in BEGIN blocks will still be executed under the -c flag, so there can be security implications to opening random Perl files with this setting. Explicitly enabling the warnings pragma at the command line will cover you for cases where you haven’t already enabled warnings in your code. Your needs may vary depending upon your environment, so keep in mind that your vimrc can source other files. You can add something like the following to your vimrc:

source ~/.local_vimrc

Perl::Critic Configuration

let g:ale_perl_perlcritic_showrules = 1

When this is enabled, you’ll be shown which Perl::Critic rules which have been violated by your code. This helps you to a) fix the issue or b) copy/paste the rule class name so that you can whitelist the code in question.  For example, you may be told that you’re violating Perl::Critic::Policy::Modules::ProhibitEvilModules.  If you feel you need to embrace the evil, this makes it easy to add a ## no critic (ProhibitEvilModules) to the code in question.   Trust me, this is much easier than digging around to figure out exactly which policy you’ve violated.

Lastly, the default behaviour of Ale’s Perl::Critic linting is to display all violations as errors. I find this confusing, because if something is not preventing my code from compiling, I do not consider this to be an error. In order to set Perl::Critic violations to be displayed as warnings, just add the following to your .vimrc:

let g:ale_type_map = {
\ ‘perlcritic’: {‘ES’: ‘WS’, ‘E’: ‘W’},

The above is a map, so you can add config options for other Ale linters to this map as well.

Unfortunately, the current incarnation of Ale can’t tell the difference between a Perl error and a warning. I have started a pull request to try to improve this somewhat, but I got stuck on the Docker end of things and haven’t gotten back to it yet. If you’d like to pitch in, I wouldn’t mind the help. 🙂

How I Spent my Perl Toolchain Summit 2017

This was my 5th year of being invited to participate in the Perl Tool Chain Summit (formerly Perl QA Hackathon). It was a real pleasure to be invited to a rebranded version of the same helpful event.

Our Sponsors

This event would not have been possible without our sponsors. Let me take a moment to thank:


For the second year in a row, MetaCPAN was well represented at the event. This is important because it really does allow us to get much more work done. Getting everyone in the same room allows us to make decisions quickly and often deploy new ideas on the same day they’ve been discussed. Just like last year, we got a lot accomplished this year. I’m only going to touch on the work which I was directly involved with. Leo Lapworth, Mickey Nasriachi and Graham Knop both did much more than I’ll cover here.

I’m going to tackle this in roughly chronological order.


I arrived on Wednesday evening, and met up with most of the others at a local restaurant. It was good to see familiar faces and talk about what people had planned for the coming days.


Thursday was the first real day of work. I had gotten the 06perms index into MetaCPAN API as part of my preparation for PTS, but it wasn’t yet exposed via the UI. So, on the Thursday I made it my mission to begin the front end work. I also spoke with Paul Johnson and Leo Lapworth about tighter integration of into MetaCPAN. I think this is important because many people probably don’t know about This site runs coverage tests on all modules at upload time. It’s a great service and something that more people should probably know about.

In the evening we went out as a group to an Ethiopian restaurant. That was a first for me and I really enjoyed it.


On Friday we went live with the 06perms work from the previous day. Once it was up and running, Neil suggested I write a blog post to get the word out about the new feature.

The module permission views have already allowed people to spot inconsistencies in some module permissions. I had some back and forth with Babs Veloso and Neil about the permissions UI. We’ll be improving the UI moving forward, but it was important to get something out there now rather than perfecting it first.

I took a few minutes to release a new Net::HTTP which consisted of a patch from Shoichi Kaji, who was sitting just a few feet away from me at the time. I did this after a code review from Karen Etheridge, who was sitting in the next room.

I also got in a pull request to change some of the copy on the show more/less links for large Changes files.


At meta::hack this past Fall, Joel Berger had worked on moving the MetaCPAN module search from the front end to the API, so that anyone could use it. We quietly merged his changes earlier this year, but the endpoint was lacking in tests and documentation. This was no fault of Joel’s. Leo set about to document this new endpoint and I spent part of my Saturday helping with this. He wanted to make some code changes, but didn’t want to do this without existing unit tests. So, I wrote some passing unit tests for the master branch and he used them in his documentation branch to establish that nothing was being broken by his cleanup work. Now we have better test coverage, some more documentation and better organized code.

While I was working on the tests, I came to the realization that our Travis build times were going to be very problematic. Some of our builds were taking up to 45 minutes or longer. This isn’t a huge issue on normal days where you can push something and come back to it later in the day. However, at a hackathon, where many people are pushing many branches, it becomes a significant constraint. Waiting 30-45 minutes for a passing build before a branch can be merged can be a real problem.

The TLDR is that build times are now in the 5-10 minute range for both the front and back end code. That was a fun journey for me and will be the subject of its own blog post. There’s some information in there which can be helpful to other projects.

As part of my efforts to speed up the build, it was helpful to have Shoichi Kaji sitting at the next table. I had a question about App::cpm and he helped me with a code sample and an explanation immediately. That allowed me to shave 50% off the build time for installing CPAN modules. I also had an issue with a test suite which needed some files to run sequentially and some in parallel. Graham Knop had an answer for me within minutes and Leon Timmermans came over a bit later to help me get the implementation right. This helped me squeeze a lot of extra performance out of the build in a very small amount of developer time.

I also took some time to add some missing meta::hack sponsors to the MetaCPAN sponsors page. I also got a very old pull request merged which fixes a bug that showed user favorites for modules which had been deleted.

Saturday evening a group of us walked into the old part of town. Leo Lapworth, Nicholas Rochelemagne, Joel Berger and I ended up a really fun little restaurant called Chez Sylvie, which offers regional cuisine. Some of us had eaten there three years ago and I had good memories of it. I’m happy to say that it did not disappoint.


By Sunday, now that we had faster Travis builds, I took a proper look at the build logs and it became clear to me how noisy our build output was. It was really hard to distinguish between real problems and noise that just needed to be suppressed. I spent a fair bit of time working on that. I’m happy to say that build logs are now extremely succinct. Moving forward it will be much easier to spot warning messages as they appear and deal with them immediately. I also spent time with Leo troubleshooting MetaCPAN search results on the staging machine.

I had a discussion about producing a new, cleaner 02packages file for PAUSE. This would be an additional file which PAUSE produces, which I’m sure will be the subject of a blog post from someone else. As a MetaCPAN developer group, we had additionally had discussion about logistics for meta::hack v2, which we’re hoping to hold later this year. Exact date and location have yet to be determined.

I got on TGV from Lyon to Paris to finish off the day.  While on the train I spent some time partially implementing CPAN river data into the MetaCPAN UI.

Added to all of this, Mickey kept me busy every day reviewing code from his pull requests. He was also a valuable resource in helping me to get my own work finished faster.

I’d also like to send a special thankyou to Travis CI. Their customer support was excellent. I had told them we were at a hackathon and having some build issues and they immediately sprang into action. They played a big part in our weekend being even more productive.

Finally, I’d like to thank my employer for giving me time to attend the summit. To me, it feels like on the job training. I learned a great deal while I was hacking and/or chatting with other attendees. I’ll be able to put this knowledge to use on various open source and $work projects as I move forward.


I spent my Sunday evening walking around Paris.  I walked from Notre Dame up to the Eiffel Tower, mostly along the Seine.  I got up early the next morning for a run.

I then caught a plane from CDG to FRA.  At FRA I got into a plane bound for YYZ.  After an apparently successful takeoff from FRA we were informed that the flight behind us had spotted liquid leaking from our aircraft.  The flight crew had then ascertained that one of the hydraulic systems was no longer functional.  So, we had to dump 54 tonnes of fuel before landing back at FRA with loads of emergency vehicles waiting for us on the ground.  We then spent probably a couple of hours in the aircraft while crews assessed the damage.  No air conditioning or meals were available during this time and eventually we all piled into buses that brought us back to the terminal.  Then into another bus that brought us to a fancy airport hotel where there was a warm meal waiting for us.  I got a text that my flight was rescheduled for 18:30 the next day.  For various reasons my 18:30 flight actually left the ground at 22:30.  So, I got to YYZ on Wednesday at 00:30 rather than on Monday at 19:30 as originally planned.

I’m glad we all got home safely.  The way the airline handled it was mostly fine.  It was a bit weak on communication, but it otherwise decent.  My big takeaway is that I’ve learned for next time to pack more stuff that I think I might need into my carry on rather than my checked bag.  🙂

Viewing Your Module Permissions on MetaCPAN

We’re currently at the Perl Toolchain Summit in Lyon, working hard on improving MetaCPAN. One feature which we went live with yesterday is a view on CPAN module permissions. This means that you can now easily see which modules any CPAN author has permission to upload.

If you want to see every module which Neil Bowers has permissions on, you can go to You can get to this page via the module permissions link on the left sidebar of a MetaCPAN author page.

To see who has permissions to upload a particular module, you can use the module view. This is not yet linked from MetaCPAN pages.

To see who has permissions to upload a particular distribution, you can use the distribution view. You can get to this page via the upload permissions link on the left sidebar of a MetaCPAN release page.

This new feature is helpful in a couple of ways. Firstly, if you’re looking for someone to patch and release a module for you, you can now easily view everyone who has permissions to do this. It’s tempting to believe that the last person who released a module is responsible for it, but the reality is that in many cases there are several people who can upload a new release. This helps shift the burden from one person to multiple people in many cases. In practice, if you want to chase someone to upload a new version of module X, you now can easily find the canonical list of responsible people.

Secondly, if you would like permission to begin uploading a certain module, you can now easily find the module owner. Only the module owner can assign co-maint to you. In the past I’ve made the mistake of contacting the last uploader and asking for co-maint. What I should have done is contact the person who actually is the owner. This can save you some running around trying to contact folks and waiting for replies from the wrong people.

Lastly, you can now audit module permissions. You may notice when looking at permissions that there are authors who should not have co-maint on a module. Or you may notice that authors have co-maint on some modules in a distribution but not on others. Having inconsistent permissions on modules in a release can lead to problems when a distribution is released by an author who has some missing permissions.

So, please do have a look at your permissions and give them a sanity check. If you notice a problem with a module which you don’t own, contact the PAUSE admins at [email protected] and they’ll be happy to work with you to sort out the correct permissions.

How I Spent my 2015 Hackathon

On May 2, 2015 I had the pleasure of attending the hackathon, which was hosted at the Bloomberg tower in Manhattan. I was privileged to be one of 5 developers to have their travel and hotel sponsored by Bloomberg L.P. This made attending the event very easy for me. Basically all I had to do was show up at the airport and the rest was taken care of for me!

The event was very well organized, had a great vibe and was very encouraging to newcomers (to Perl and to open source contributions). For my part, I was there to work on MetaCPAN and (hopefully) be there as a resource to anyone else who wanted to contribute to MetaCPAN.

I’m happy to say that I got a number of things done. I was able to fix all of the failing tests on ElasticSearchX::Model. This is a module which MetaCPAN relies on heavily. Going into it, I wasn’t sure if the failures were in the code or in the tests. Luckily it was just a problem with the tests, so that was easy enough to fix. I trapped some warnings while I was at it and eventually got a green light from Travis. I got a good chunk of this done on the flight in, so I was able to finish it and release a new version as my first order of business at the hackathon.

Moving forward I continued to work on the MetaCPAN Elasticsearch upgrade, which I was working on at the QA Hackathon. I was able to fix bugs in the module which imports CPAN mirror data into the little known mirror endpoint of the API. I also (mostly) fixed bugs in the module which imports CPANTesters data into the release objects of the API. That still needs some work, but it took a fair amount of digging around.

In addition to this, I worked with MATTP, who added more handy keyboard shortcuts to MetaCPAN. (For example, go to and type “pr” — that will take you straight to the Github pull requests for this repository). I was able to merge and deploy this change at the hackathon.

I also had some good conversations with RJBS about finding recursive dependencies for modules and graphing them. It turns out he already has a workable solution for this and I don’t think converting his code to use MetaCPAN would actually speed things up for him.

I finally met Yanick Champoux, who was a very early contributor to MetaCPAN. I was able to recognize him from the 1/2 of his face which is exposed by his avatar! I should also mention that he helped me find my phone not once, but twice in 24 hours. (I really have to keep better track of it).

I also had a fun dinner with Florian Ragwitz and Augustina Ragwitz. (Florian has been involved with MetaCPAN since it was about six months old).

And, to round out the namedropping, I also met the following folks for the first time: I had an interesting chat with David Farrell about and using Perl6 to parse Pod. Charlie Gonzalez showed me all of the interesting stuff a Fitbit can track and I had a very brief chats with Nick Patch and Peter Martini, whom I basically crossed paths with as I was headed for my ride to the airport.

The facilities were outstanding as was the plentiful food (breakfast and lunch). This was all made possible by the sponsors: Bloomberg, RubensteinTech and

The organizers did a fantastic job with all of this, so I should particularly thank Jim Keenan, Charlie Gonzalez and David Golden and Kevin P. Fleming.

This was the 2nd hackathon. I have a hunch that this means there will also be a 3rd. If you have a chance to attend this hackathon in future, my advice would be do it!

I’ll be at the 2015 New York Perl Hackathon

I’m happy to say that I’ll be participating in the 2015 New York Perl Hackathon. I’d like to thank Bloomberg, L.P. for sponsoring me so that I can attend this event.

While I’m at the hackathon, I hope to continue my work on MetaCPAN as I did at the QA Hackathon one week ago. I’ve put together a list of possible MetaCPAN projects. If anyone would like to take on any of these projects, feel free to get in touch with me in advance if you have any questions on what might be involved with any of these proposals.

I’ll also be available to help out with things which aren’t MetaCPAN-related: Perl, Git, GitHub, etc. There’s more general information at the hackathon wiki.

I will, of course, report back on my progress at the hackathon after the event has taken place. I’m looking forward to a productive day of hacking with a group of smart, motivated people.

How I Spent My 2015 Perl QA Hackathon

One week ago I was in Berlin at the Perl Quality Assurance Hackathon (QAH), happily hacking away on MetaCPAN. Today I’ll summarize the good, the bad and the ugly about my time in Berlin. Spoiler alert: it was all good.

This was the third year that I’ve been able to attend the QAH. I was previously in Paris and Lyon. From my past years, I knew that I’d have some serious time to put my head down and get some work done. I didn’t make an overly ambitious TODO list, since there’s one main project for MetaCPAN right now: upgrading from Elasticsearch 0.20.2 to 1.5.0 It’s a big jump with a number of breaking changes. MetaCPAN has a pretty big stack and a lot of lines of code. It also relies on ElasticSearchX::Model as an abstraction, which needed some work for this upgrade as well. So, I figured I’d put some effort into this and work on a few other things as they came up.

My hackathon always begins at YYZ [insert joke about Rush] and continues on the flight in. I generally get a lot of work done in this phase rather than getting sucked into just watching bad movies. (Don’t get me wrong, I truly enjoy a bad movie, but I also rarely get a big block of time to move things forward with my open source projects).

On the flight I decided to get some smaller things out of the way, mostly not directly related to MetaCPAN. I wasn’t able to release anything from the air, so I’ll summarize those as part of my hackathon Day 1.

In addition to the code I wrote on the plane, I wrote a couple of blog posts to thank new MetaCPAN sponsors. I have 3 outstanding posts and I was able to write 2 of them on the plane. You’ll see those shortly. I’ll post them individually once all of the QAH blog posting dies down.


The Day Before


I flew out on Tuesday and arrived early on Wednesday morning.  I was at the hotel by 9 AM, but the room wasn’t available until 3 PM, so I ditched by bags and headed out on the town.  I had decided to fly only with enough clothing to get me through day one, so one of my first tasks was to find something to wear.  That was actually a lot of fun.  One of my favourite moments was when I told a salesperson that I was looking for a medium sized shirt.  Without skipping a beat he said, “you’ll need a large.”  He was right.  I’m sure there was no judgement implied!

In the evening I got to meet (for the first time) a couple of folks whom I’ve worked with on MetaCPAN since the very beginning.  Johannes Plunien, the creator of GitHub Meets CPAN happens to live in Berlin.  He hadn’t been planning to attend the hackathon, but was free to hang out in the evening, so he came by the hotel.  Next Clinton Gormley, one of the authors of  Elasticsearch: The Definitive Guide came by the hotel as well.  He was in town for the hackathon, having been sponsored by Elastic to attend.  I knew he was tall, but I wasn’t quite prepared for how he would tower over me.  It’s a good thing he’s a friendly giant!  Next Neil Bowers showed up and we all joined the others for dinner.  For me this is a good illustration of how hackathons are helpful beyond just getting things done.  It was really great for me to get to know Johannes and Clint in person.  It’s also nice to have Neil around, since he speaks the Queen’s English.


Day One (Thursday)


  • On the airplane I had written some code for Plack which allows it to use Cookie::Baker in Plack::Request. I had actually proposed to send this pull request back in November 2014 and it had kind of been hanging over my head that I hadn’t gotten to it. MIYAGAWA merged it on Day 1. It shrinks Plack::Request by 34 lines.
  • I merged a MetaCPAN pull request which adds boilerplate installation instructions for modules to the left sidebar of module and distribution pages. (You’ll find it under “PERMALINKS”). Once this was merged we found some issues related to the changes and after a few iterations I had those cleaned up and deployed to production.
  • I added JS beautification to MetaCPAN. We already tidy our Perl code automatically. This keeps our JS looking spiffy as well.
  • On the plane I basically finished up a proof of concept I had been working on in order to showcase HTTP::BrowserDetect. In the evening back at the hotel I registered a domain name and launched I had been toying with making this a web service so that you could use it for robot detection etc, but I opted for a Minimum Viable Product to start with here.
  • I merged a bug fix for WWW::Mechanize::Cached and released a new version.
  • I realized that I had some unreleased changes in WWW::RoboCop, so I released a new version of that and also fixed a test dependency and then re-released.
  • On the airplane I had made two big improvements to LWP::ConsoleLogger. First, I had converted it from Moose to Moo, which means that I now have the option of adding it as a proper dependency to GitHub::MergeVelocity without pulling in all of Moose. I also began using HTTP::Body to parse POST params. (What I had been doing before to parse POST params did work, but it made me sad.) I released a new LWP::ConsoleLogger with these improvements.
  • In addition to all of this, I worked with Clinton Gormley on the Elasticsearch upgrade.  That is, he did the bulk of that work and I helped him with issues specific to MetaCPAN.


Day Two (Friday)


  • I merged my own pull request which had begun on the airplane, where I had written some code to remove MetaCPAN’s Pod generation out of the Catalyst controller.  This makes it easier to test.  Also, this will allow us in future to accept an arbitrary base URL for Pod generation via the API. This means that if you are generating Pod but don’t want it to link back to MetaCPAN, you’ll be able to provide your own URL for the Pod generation.  This also something we’ll be able to use on the MetaCPAN search site when developing locally.  Right now Pod links bounce you from your development site to the production site, which is really confusing.  This part is not yet implemented, but it should be fairly trivial to implement.
  • I continued to work with Clinton Gormley on his Elasticsearch improvements
  • I fixed an issue with permissions on the MetaCPAN production machines.  This allows us to run many commands without having to su to another user first, which is quite helpful.
  • I released a new ElasticSearchX::Model  This included some of Clinton’s improvements as well as a few changes which were required to keep up with changes in Dist::Zilla plugins.
  • I spent some time improving the tests for the MetaCPAN API
  • I patched to recognize more extensions which are commonly used for markdown.  This will make more README files easier to find.
  • I also spent some time working with CPAN::Faker to add some tests for a new endpoint which Clinton was creating after a conversation with MIYAGAWA.  This will be used by cpanm and will simplify its internals once it is finished.  Essentially cpanm builds a complex API query to find the correct download URL for modules under various conditions.  We’ve decided to move this logic directly into the MetaCPAN API.  This will remove a fair chunk of logic from cpanm and will also make this new endpoint available to anyone else who wishes to use it.  That’s a big win.


Day Three (Saturday)


  • I fixed a bug in ElasticSearchX::Model which was particularly hard to debug.  It was throwing an exception in a DEMOLISH sub.  The problem with throwing exception at object teardown is that you have no guarantee of which classes are still available.  As a result, Moose was trying to inflate an exception to a class which was no longer available.  That, in turn, triggers a new exception which triggers a new exception which … (well, you can see where I’m going from here).  Basically hilarity ensues.  I was happy to get that sorted and released.
  • Based on my work with CPAN::Faker on Day two, I came to the conclusion that it wasn’t going to be a solution for all of our problems.  Possibly it could be, but not without a lot of effort, since it wants you to mock up CPAN distributions.  I had been spending time running the MetaCPAN indexer on a staging machine using the latest Elasticsearch and I was watching real tarballs trigger exceptions in our code.  I didn’t want to have to find the problems with those tarballs and then mock them up using CPAN::Faker, mostly because I’m lazy.  (This is not strictly a virtue of programming.  I’m pretty sure I was born lazy.)  So, I reworked the API tests to create a CPAN of arbitrary size using OrePAN2.  This now allows us to add any problematic tarballs to our test suite (but not to our Git repository).  This will make regression testing much easier.  It has already made my debugging incredibly easier.
  • This was also Clinton’s last day at the hackathon.  He did an incredible amount of work to move the upgrade forward and he also very graciously gave a presentation on Elasticsearch’s query language which makes it much easier to understand.  I would list off all of Clint’s accomplishments but that would make this blog post ridiculously long, if it isn’t already.


Day Four (Sunday)


  • As part of my work on the API’s test suite, I ended up releasing Git::Helpers.  The name is misleading since there is currently only one helper (oops!) but I actually do plan to add more.
  • The MetaCPAN API was getting pummelled over the time I was there.  I did some troubleshooting to find which IPs and UserAgents were occurring most in our log files.  I put those in a newly created metacpan-sysadmin repository.
  • As part of my work to add an arbitrary CPAN to the API tests, I came across a bug in CPAN::Repository.  I had wanted something to write an 06perms file and had casually mentioned this to Neil Bowers.  He had suggested this module.  I raised a ticket about the issue and GETTY immediately gave me co-maint and added me as a collaborator on the GitHub repository.  I’ve now patched this particular bug and have released a new version of the module.
  • After having dinner with PLU earlier in the week, we had convinced him to visit the hackathon on the weekend.  He graciously came by on the Sunday and worked like a machine.  By the time he had left, he had sent 4 pull requests for  The most notable of these pull requests is that we now have keyboard shortcuts, which I have wanted for a very long time.  Type “?” on a module page, for instance, to see what you can now do.  The shortcuts will be revised again shortly, so don’t get too attached to all of them, but this is going to make your MetaCPAN browsing much, much easier.
  • I was able to merge and deploy all of PLU’s commits on the Sunday


The Day After (Monday)


  • I got to the airport way too early, so I had a couple of hours to keep working.  I continued to refactor the API tests.  I also worked a bit on the download_url tests which Clinton Gormley had created for the new cpanm endpoint.  As part of my work I added some more documentation to the API as well.
  • I also looked into an issue with OrePAN2, which makes it hard to inject developer releases into your local DarkPAN.  This actually took up a bunch of my time as I had to poke around in Parse::PMFile as well as Parse::LocalDistribution.  ISHIGAKI has kindly worked through some of these issues with me.  As a result, I think we have a good solution and that should be implemented and released short.
  • I continued to poke at the test suite and various little things on the plane until I was exhausted enough that all I could reasonably do was watch a bad movie.


What I Didn’t Do


We didn’t manage to finish the Elasticsearch migration, but that’s OK.  Collectively there was a huge amount of work on this which got finished.  It was probably not realistic to think this would have been done over 4 days, especially given that MetaCPAN is a service which is heavily used in production.  Now that we’re out of beta, we can’t just push stuff out to production and hope that it doesn’t break too badly.

If you’ve read other hackathon reports, you’ll have read about all of the discussions around CPAN which took place.  I made a conscious decision not to participate in these discussions because a) I needed the time to work on MetaCPAN and b) there were other people who have thought much more about these things than I have.  I trust them to make the right decisions and from what I understand, they made a lot of progress.

Socially, there are a lot of people at the hackathon that I didn’t really connect with.  I had some good conversations with various people, but I did spend a lot of time with headphones on trying to get this or that sorted.  That was a conscious decision as well.  I tried to be available to anyone who had MetaCPAN questions but I also had to take advantage of this opportunity since I won’t have another 4 day block to work on MetaCPAN at any point in the near future.


Thank You (The Credits)


Basically, I just had to show up and do my thing.  That wouldn’t have happened without many, many other people who did their part to make this happen.  First off, I should thank MaxMind for allowing me to use my annual training time to attend the hackathon.  It’s much easier to attend an event like this if you don’t have to take vacation to do it.  Basically it was a choice between attending the QAH or attending YAPC::NA. So, I won’t be at YAPC this year, but I think it’s a worthwhile trade-off.

I should thank my family for letting me swan off to Europe to pursue my hobby and just generally enjoy myself.  (I keep trying to say “this is actually hard work”, but nobody at my house is buying it.)

I should say that Tina Müller did a fantastic job of organizing the hackathon, supported by Andreas König. Also, Neil Bowers worked his magic to conjure up sponsors for the event. Whenever I saw Wendy van Dijk, she was either hauling food from a shopping trip, washing and preparing food and making trips up and down the stairs to do this. When there’s no elevator available, this is no easy task. 🙂

I’ll close with a proper thank you to our sponsors!