<div dir="ltr">Hi,<div><br></div><div>I've been "laterally 'promoted'", but the guy they had to replace me ended up taking another position, so we're looking for another replacement.</div><div><br>
</div><div>The technical name of my job is "release engineer" but I've turned it into "write code to do the releases for me, and then write code to do all the other stuff there is to do".  It's not 100% coding yet, but management is happy to see more and more automation, so it's a pretty good gig from that standpoint.</div>
<div><br></div><div>I have a dancer app running from a perlbrewed perl (so you can install whatever modules, etc, you want independent of what development is doing).  It's just getting to the point where the app is paying off for the work I put into it and begging for all kinds of expansion.  I really don't want to leave it, to be honest, but there's so much depth of functionality possible with it that there's no way I can keep working on it and get the new stuff done, too.</div>
<div><br></div><div>I'll be available indefinitely for questions and stuff so there should be no problems with mystery code or whatever.</div><div><br></div><div>The position is in Operations, and it includes things like triage/diagnostic/post-event investigation of live performance issues.  All of which are just further opportunities to write code to make all the processes easier and more automatic.</div>
<div><br></div><div>One simple example--the application we're supporting runs under mod_perl and is able to receive a USR2 signal and respond by dumping a stack trace of diagnostic information.  I wrote something that sends a process that signal and then tails the apache log watching for the signature of the output, then reporting it back (or reporting the absence of a response after a timeout period).  Nothing extremely fancy or anything but it was fun to write and I hadn't messed around with inter process communication for a while so I learned stuff doing it.</div>
<div><br></div><div>Also wrote a slick little log parser that pulls performance data from a custom apache log and dumps it into a Sqlite database which you can then query to your heart's content--or just mail to development and tell them it's their problem.</div>
<div><br>These are in addition to the Dancer app I mentioned earlier (and will probably be sucked into it, actually) which manages the release process and is slowly taking over a lot of formerly laborious diagnostic and maintenance tasks.</div>
<div><br></div><div>It's full time telecommute with occasional travel to the Boston and San Mateo locations for "Operations Summits" and company-wide all-hands Ops meetings and stuff like that.</div><div><br>
</div><div>One of the best bosses I've ever worked for, too.</div><div><br></div><div>I think they give me an iPad or something if you join via my referral, so be aware that I have that as a possible conflict of interest :).</div>
<div><br></div><div>We're a linux shop, I think the machines are RHEL (older ones v5 something, newer v6), mysql databases, the application is in perl and most of the supporting scripts are also in perl or bash.  The perlbrewed perl we are using is 5.14.2, but nothing's keeping you from updating to more recent than that if you want to.</div>
<div><br></div><div>We have just started moving our operations codebase into gitlab (like an internally hosted github).  In addition to being responsible for the production releases of the NetSuite OpenAir product, you are responsible for managing and releasing the code that the ops team writes.</div>
<div><br></div><div>Major releases happen six times a year during Saturday release windows (5-9am central) which are planned well in advance of the event.</div><div><br></div><div>There is a slipstream release of minor fixes every Thursday night at 9, but almost all of the work for that is pre-done by my Dancer app now, and we're very close to the point where the last bit could be cronned.</div>
<div><br></div><div>The on-call rotation is kind of in flux right now--when we get it back running normally I will expect to be on call once every six weeks.  Incidents requiring off-hours attention are pretty rare, though (we just celebrated a year without a single site-wide incident).</div>
<div><br></div><div>It would be best for the candidate to know OO Perl as well as being very familiar with sysadmin-type tasks (I'm stronger on the Perl and weaker on the sysadmin stuff, but that's fine, and it would work fine in the other direction, too).<br>
</div><div><br></div><div>If you're interested, or know someone that would be, let me know.  Also, since it's telecommute, if you know someone located elsewhere that would be interested, that would be possible too (I think they have some restrictions on which states they can hire in based on some considerations regarding tax or insurance status or whatever--I just don't know which or how strict it is, and they have bought quite a few companies recently so I think that restriction is getting smaller by the month).</div>
<div><br></div><div>mike</div></div>