The Product Management team recently built a new Catalyst Perl application and we wanted to ensure that we would maintain a high level of code coverage in our test suite. This seemed like an ideal opportunity to use Devel::Cover; we currently use Jenkins to build all our branches, and Devel::Cover allows us to integrate easily with Jenkins to run the coverage report after each build.
At a recent meeting, some ideas for an office event were being discussed, and people were considering hiring a photo-booth for the evening. I had a huge lightbulb moment: we’ve had a photo booth in the office and at some staff events already — why do we keep paying other people to do this? Surely we can create our own for a fraction of the cost?
How hard can it be?
This is the question I set out to answer in our most recent Hack Day.
A requirement arises in many systems to update multiple SQL database rows. For small numbers of rows requiring updates, it can be adequate to use an UPDATE statement for each row that requires an update. But if there are a large number of rows that require an update, then the overhead of issuing large numbers of UPDATE statements can result in the operation as a whole taking a long time to complete.
Exception handling in Perl is, like OO support, very basic:
throw an exception,
eval to catch it into the global
variable. What an exception is, what to do when you’ve caught it, and
other such niceties are just not part of the language.
So what’s this immutable stuff all about? In short, it’s the Moose equivalent of
use strict; use warnings;
at the bottom of every Moose class unless you really know what you’re doing. It makes your code safer (and faster).
As a developer-by-nature, I’ve been fortunate not have to understand
global networking, and the effect of the speed of light, in any great detail.
I’ve been in the lucky position where I have been able to write code that
“does what it’s supposed to” without much thought to global server
This changed quickly and suddenly for me towards the end of 2012.
One of our programs was leaking memory. Not much, but enough that Tech Ops were not going to allow us to put it into production. Fair enough, I wouldn’t allow it either, if I were on-call.
So I did the obvious: started looking for the leak. This is not as easy as I’d like.
We have a large automatic test suite here at Net-a-Porter, and that test suite gets run automatically whenever we check code changes in to our source code repository. Of course, a developer will run the suite manually before checking in changes, but it’s nice for the rest of the team to be able to see that a particular change hasn’t broken anything.
Occasionally, the test suite will flag problems that weren’t introduced with the most recent code change. This can get frustrating for the poor developer who gets the blame for breaking something that she didn’t touch. So when we find strange problems like this, we try to fix them; this is how we fixed one this morning.
We’ve recently hired our first group of graduate developers, and they’re currently undertaking a graduate programme where they will work with various technical teams in different disciplines. As a member of the Perl group, I’m obviously hopeful that they’ll enjoy their time using Perl, and that they might be excited enough by using Perl, and the work we do with it, to want to stick with Perl after they finish the graduate scheme.