You can find more information on the speaker's site:
Moonpig is an innovative billing and accounting system that Rik Signes and I worked on between 2010 and 2012, totaling about twenty thousand lines of Perl. It was a success, and that is because Rik and I made a number of very smart decisions along the way, many of which weren't obviously smart at the time.
You don't want to hear about the billing and accounting end of Moonpig, so I will discuss that as little as possible, to establish a context for the clever *technical* designs we made. The rest of the talk is organized as a series of horrible problems and how we avoided, parried, or mitigated them:
* Times and time zones suck
* Floating-point arithmetic sucks
* It sucks to fix your mangled data after an automated process fails
* Testing a yearlong sequence of events sucks
* It sucks to have your automated test accidentally send a bunch of bogus invoices to the customers
* Rounding errors suck
* Relational databases usually suck
* Modeling objects in the RDB really really sucks
* Perl's garbage collection sucks
* OO inheritance sucks
Moonpig, however, does not suck.
Some of the things I'll talk about will include the design of our web API server and how it played an integral role in the system, our testing strategies, and our idiotically simple (but not simply idiotic) persistent storage solution. An extended digression on our pervasive use of Moose roles will be deferred to the lightning talks session on Sunday.
Much of the design is reusable, and is encapsulated in modules that have been released to CPAN or that are available on GitHub, or both.