My company is dusting off some job descriptions and considering expanding our team, which got me thinking of a blog post I’ve been meaning to write. Hiring developers can be tricky business, so I wanted to share some practices that have both worked well for me as a candidate and hiring manager. But first…
A Little Story
In the not too distant past, I found myself attracted to a fairly new company with a veritable A-list of Perl developers. After being declined, I was offered some feedback by the hiring manager which I gladly took the opportunity to hear:
Originally, I was assigned TryCatch. “At least something I can use,” I thought. Also, the module's ticket queue was 21 issues long, so there should've been something to pick up. When I took a closer look, though, I discovered the module was XS heavy (I have never written any XS, and almost no C either), and the only issue I would've been able to work on was “Mark as deprecated” — but I wasn't sure I'm able to judge whether it would be the right thing to do.
If you are reading this and you didn't hear that Larry bit the bullet, rolled the dice, flipped the coin, shattered the space time continuum...breathe... then you really are going to get a shock.
Larry has announced that the Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015.
So why do I say attempt?
Well it isn't as easy as promising, because we have a real issue if we do such a damn fool thing. There are a number of reasons, aside from the hidden complexities of code, that could scupper the plans. The inevitable bus-in-the-face failure being just one of them. A cautious 'Murphy doth exist' attitude is the right one to take.
clpm is designed to make managing sets of files easier at the Unix command line. It's free and open source. Please view the demo here. Find more info at http://tinypig.com/clpm
If you happen to be in Sydney Australia this month, please join us for a night of Perl and conversation.
SiteSuite have again offered to host us this month, thanks be to Cees Hek for setting the wheels in motion. Note: SiteSuite have moved, so check the new North Sydney address below!
What: Sydney PM
Date: Tuesday, 10th February 2015
Time: 6-9:30pm
Where: SiteSuite, Suite 202, 53 Walker St North Sydney
Speakers are needed!
Here are some ideas:
perlprew, perlcritic, perltidy, podweaver, any of these sorts of tools
Anything related to Mojolicious/Catalyst/Dancer
Anything to do with rapid creation or consumption of rest/soap/xmlrpc/other apis
Getting started on perl testing
Queue things like beanstalkd, gearman
Using perl in funky cloud services like digitial ocean, codio, heroku etc
Maybe something on logging, log4perl, Log::Any, Log::Dispatch
Something cool that you did, just a fun little tool or something
There is a projector with all the usual trimmings and wifi access may be available.
Lightning talks would also be really great!
Meeting after that?
At this weeks meeting, everyone seemed happy to plan for the month after as well. So if you can't make this month - look out for March!
I recently gave a talk at AmsterdamX.pm about web scraping. I provided a few examples of scraping (most of them on my Github repo), and amongst them, a few relating to the January assignments page Neil has put up.
In my quest to clean up my CPAN distributions and to normalize them, I've been working on CPAN::Critic, my unreleased tool that looks at my directory and complains about things I don't like. That's going nicely for the most part, but I ran into a small problem that's taken me down a bit of a rabbit hole of C++. All this in the same week I wrote a Python program.
However, I'm in love with postfix dereferencing, a v5.20 feature. PPI reports 5.004 and Compiler::Lexer thinks 5.008 because neither handle the latest syntax enhancements:
At YAPC::NA 2014 I talked about FFI and Perl. FFI is an alternative to XS that I think is worthy of consideration. My talk was well attended, I think primarily because I jokingly subtitled my talk "Never Need To Write XS Again". So there is a market for this idea. I mostly talked about FFI::Raw, which was a great way to experiment with FFI and to write real live CPAN modules with FFI right then and there. The question of performance inevitably came up, so at the Pittsburgh Perl Workshop last year I talked about that.
The Perl Quality Assurance Hackathon (hereafter QAH) is an annual 4-day gathering of the people who work on the core CPAN toolchain and associated systems & services. This gives them dedicated time to work on these systems together, solving hard problems and working out how to move everything forward.
Like pretty much everything in the Perl world, these are all volunteers, so our approach is to get sponsorship to cover expenses (travel, accommodation, working space, meals) for as much of the gathering as possible. If your company relies on Perl, ask yourself how much you rely on the toolchain working smoothly? Perhaps you could persuade someone to sponsor the QAH this year?
The CPAN toolchain isn't glamorous, so generally doesn't get much press, but it's an essential part of our world. So over the next few weeks we'll be posting some short articles to raise awareness and hopefully encourage some sponsorship.
In the previous post I discussed my January Pull Request Challenge contribution. It's only part 1 because there's another part: the contributions others made during their PRC which were related to projects I'm in charge of.
Every week, I work with about a dozen SQL databases. Some are Sybase, some
MySQL, some SQLite. Some have different versions in dev, staging, and
production. All of them need data extracted, transformed, and loaded.
DBI is the clear choice for dealing with SQL databases in Perl, but there are a
dozen lines of Perl code in between me and the operation that I want. Sure,
I've got modules and web applications and ad-hoc commands and scripts that
perform certain individual tasks on my databases, but sometimes those things
don't quite do what I need right now, and I just want something that will let
me execute whatever SQL I can come up with.
Yertl (ETL::Yertl) is a shell-based ETL
framework. It's under development (as is all software), but included already is
a small utility called ysql to make dealing
with SQL databases easy.
While I was focused on the social aspects of the PR Challenge, such as the IRC channel (opping literally everyone), the guides (wrote several), the repo (plus organization), and lately even a small parser for the web page Neil created (which will appear in another post), I still had my own responsibilities - mainly, my own PR challenge, and taking care of others' PR challenge contributions that fell under my purview.
