My last day at MaxMind will be January 5, 2017. For the curious, I left of my own free will. I was not laid off, fired, put into a cannon and launched into space, or NDA’d as seen on the TV show Incorporated. So now it’s time to find something else to do to fill my time and checking account. I’m open to both consulting work and full-time employment. My ideal position would look a lot like what I did at MaxMind.
Have you seen my new module, Params::ValidationCompiler? It does pretty much everything that MooseX::Params::Validate and Params::Validate do, but way faster. As such, I don’t plan on using either of those modules in new code, and I’ll be converting over my old code as I get the chance. I’d suggest that you consider doing the same. The speed gains are quite significant from my benchmarks. Since I’m not going to use them any more, these two modules could use some maintenance love.
I’ve been thinking about DateTime recently and I’ve come to the conclusion that the Perl community would be much better off if there was a DateTime core team maintaining the core DateTime modules. DateTime.pm, the main module, is used by several thousand other CPAN distros, either directly or indirectly. Changes to DateTime.pm (or anything that it in turn relies on) have a huge impact on CPAN. I’ve been maintaining DateTime.pm, DateTime::Locale, and DateTime::TimeZone as a mostly solo effort for a long time, but that’s not a good thing.
I’ve decided to stop renewing the masonbook.com domain after next year. The new home for the book is masonbook.houseabsolute.com. Please update your bookmarks.
My employer MaxMind is hiring for two engineering positions. We have a positions for a Software Engineer in Test and a Software Engineer. If you’ve always wanted to work with me, here’s your chance. If you’ve always wanted to avoid working with me, now you have the knowledge needed to achieve that goal. It’s a win-win either way! Note that while this is a remote position, we’re pretty limited in what US states we can hire from (Massachusetts, Minnesota, Montana, North Carolina, and Oregon).
I recently released a new parameter validation module tentatively called Params::CheckCompiler (aka PCC, better name suggestions welcome) (Edit: Now renamed to Params::ValidationCompiler). Unlike Params::Validate (aka PV), this new module generates a highly optimized type checking subroutine for a given set of parameters. If you use a type system capable of generating inlined code, this can be quite fast. Note that all of the type systems supported by PCC allow inlining (Moose, Type::Tiny, and Specio).
It’s not too late to sign up for my Introduction to Moose class at YAPC::NA 2016. This year’s class will take place on Thursday, June 23. I’m excited to be doing this course again. It’s gotten great reviews from past students. Sign up today. There are lots of other great courses. For the first time ever, I’m also going to be a student. I’m looking forward to attending Damian Conway’s Presentation Aikido course on Friday, June 24.
My Introduction to Moose class is back at YAPC::NA 2016. This year’s class will take place on Thursday, June 23. I’m excited to be doing this course again. It’s gotten great reviews from past students. Sign up today. And of course, there are tons of other great offerings this year too, including several from the legendary Damian Conway! I already signed up for his Presentation Aikido course on Friday, June 24.
What sort of things can you learn when interviewing someone for a technical position? What questions are useful? This is a much-discussed and sometimes hotly debated topic in the tech world. I’ve done a fair bit of interviewing for my employer over the past few years. We’ve built an excellent technical team, either because or in spite of the interviews I’ve done. Here’s my unsubstantiated theory about interviews and what they’re good for.
I’ve been on vacation for the past week, and I decided to take a look at using Test2 to reimplement the core of Test::Class::Moose. Test::Class::Moose (TCM) lets you write tests in the form of Moose classes. Your classes are constructed and run by the TCM test runner. For each class, we constructor instances of the class and then run the test_* methods provided by that instance. We run the class itself in a subtest, as well as each method.