So what’s this immutable stuff all about? In short, it’s the Moose equivalent of
use strict; use warnings;
Summary: Stick
__PACKAGE__->meta->make_immutable;
at the bottom of every Moose class unless you really know what you’re doing. It makes your code safer (and faster).
Continue readingIn January this year, we (the NET-A-PORTER GROUP Product Management team) introduced work-in-progress limits to our software development process. For example, we have at most five items “in development” (including in code review) and four “in test”. An item in this case is a user story, bug fix or investigation task.
We added the work-in-progress limits as part of a Kanban-inspired move away from a fixed-iteration process to a continuous flow of work.
Continue readingDuring some routine network security testing recently, it was pointed out to me that my laptop had X running an open network port — anyone could connect to it and control my desktop as if they were me.
Being that I’m fairly conscious of network security, and particularly when you are surrounded by some very technical people with a mischievous sense of humour, this is something that I would never have manually configured.
Continue readingExploratory testing is an approach to testing. Traditionally, testing has always had a “scripted” approach, where tests are planned based on a list of requirements supplied by the business stakeholders, and these scripted tests are written long before any software is even written. Although this might be useful in some circumstances, and scripted tests are still used in some circumstances within Net-A-Porter (in the regression team for example), it can be painful to use a scripted testing approach in other situations (like when testing new functionality in the streams). Continue reading
We have processes that communicate via ActiveMQ. They mostly work, but sometimes we get very strange problems. This is the story of one of them.
The consumer I’m talking about is written in Perl, using the Net::Stomp module.
Continue readingAs 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 positioning.
This changed quickly and suddenly for me towards the end of 2012.
Continue readingThis year we are running an IT Graduate program here at Net-a-Porter. The four graduates are doing three-month rotations with various teams, getting experience with many aspects of our business. I volunteered to give them a quick introduction to shell programming and regular expressions. Killing two birds with one stone, I have adapted the shell programming part of that session into this blog post — the regular expressions part of the workshop will be the topic of a future post.
Continue readingOne 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.
When I started in the Labs team at Net-a-Porter, the job description contained the following desired trait:
Candidate is unafraid to fail, but fails fast
This phrase was new to me at the time and it certainly wasn’t something I could say I was actively doing, but three years later failing fast is not only something I strive to do as a software developer, but something I look to do in aspects of my day-to-day life.
So what does this phrase actually mean? The phrase has two parts; let’s look at each of them.
Continue readingWe 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.
Continue reading