I've started posting perl (and other) portland and/or telecommute jobs on twitter. I thought I'd also include these tweets in the 2pdx.com LinkedIn group. LI supports rss feed inclusion in the news for their groups, so it should simply be a matter of pasting in the rss url
https://twitter.com/statuses/user_timeline/this_job.rss
into their UI. Nope. LI claims that this is not a valid rss feed. Hmm... The validator disagrees, but it does point out some warnings. Maybe LI's code just isn't up to handling that. Even if this was only an issue with twitter's feeds, "just twitter" is a rather large set of rss feeds to exclude based on an overly-strict parser. I advised them of the issue via their feedback form.
In the mean time, I can take a couple of minutes to write perl to grab one internet resource (the twitter feed) and scrub the content enough so that it is palatable to another internet resource (LI). Now I've got a suitable workaround until LI updates their code.
This seemed like a pretty canonical case of being the duct tape for the internet. The code isn't pretty, but it doesn't need to be.
#!/usr/bin/perl -T my $dirty_rss = 'http://twitter.com/statuses/user_timeline/this_job.rss'; my $clean_rss = 'http://wickline.org/bird_bath/'; use strict; use warnings; $| = 1; use WWW::Mechanize; my $mech = WWW::Mechanize->new(); $mech->get( $dirty_rss ); my $feed = $mech->content(); for ( $feed ) { s{xmlns:twitter="[^"]+"}{}gi; s{<twitter:[^\n]+}{}gi; s{\Q$dirty_rss\E}{$clean_rss}gi; } print "Content-type: application/rss+xml; charset=utf-8\n\n$feed\n"; exit;]]>
If you use twitter, follow @this_job. If you use rss, subscribe to https://twitter.com/statuses/user_timeline/this_job.rss. If you prefer email updates, well I'm sure there is some service out there which will turn twitter streams or rss feeds into email. Actually, I think twitter started doing that themselves.
We'll see if this experiment works any better.
]]>A week ago I joined #moose and nopasted a public key. Cats and kids jumped all over me and I didn't follow through. In the end, I think that nobody acted on that. Today I thought I'd get back to that while the kids were out of the house. I still had the nopaste tab open, so pasted the URL and mst added my key.
hmmm... but I still couldn't clone the rw repo. Sigh. I turns out that the public key was an orphan. From the comment in the public key, I'd believed that it was the one I was using to access github. However, they'd had that security kerfufle a while back and asked everyone to re-verify their public keys. I'd taken that opportunity to simplify a bit and just down my public key list at github to one key. ...and it wasn't the key that I'd sent mst. In fact, after much digging, I believe that I do not actually have a private key to go with that public key.
I also found another public key which appears to be an orphan. I've tidied up a bit now and hope never to be in this situation again. Just in case (or in case anyone else ends up there), here's some bits of info...
github does not show you the public keys you have with them. Instead, it will show you fingerprints:
https://github.com/settings/ssh
You can view the finger prints of your public keys to see which (if any!) match:
for i in ~/.ssh/*.pub; do ssh-keygen -l -f "$i"; done
If none match, but you are still able to access github, then you may have misplaced your public key since uploading it to github. Presumably you still have the private key or you would not be able to access github.
ssh-keygen -y -f ./name_of_private_key_file > name_of_private_key_file.pub
at that point, you can redo the finger print bit and see which public key github is really using.
]]>
I'll take a closer look when I've got time and may tweak whack.pl some based on what I see there, but I can also see that there are some things I'd like to keep different.
Also, I'm used to using PerlCritic as a pass/fail sort of tool. Some unit of code is either good enough or not. There is no affordance for talking about relative quality other than "this code passes/fails and the other does not". So, the main difference of whack.pl is that it is intended to say "these are the bits of code that are the worst" so that you can improve them. You can decide in advance how much effort to invest in improving them by saying "I want them to be at least as good as that bit of code over there" (or equivalently, "I want them out of the top-N").
I suppose one could use PerlCritic in a similar fashion by tweaking the max_mccabe parameter and lowering it below X as you found that you got everything passing at value X.
fix it
repeat... virtuous whack-a-mole with https://github.com/wickline/whack
]]>This is good for developers. Even if you're not actively looking for work, your employer will feel market pressure to improve your working conditions. They want to be sure that you're not sucked out the door. If you are actively looking for work, then there's a veritable smorgasbord of options out there. If you don't see something you like today, just keep your eyes open. If you'd like to be actively looking but are not sure where to start, then the rest of this blog post is for you.
I think you should read two books
You don't have to read them before you start a job hunt, but read them while hunting. If you're not in a rush go ahead and read them first. If you're in a rush then you need to have a generic resume ready first.
The Laidoff Ninja is primarily targeted at folks who have been laid off and are struggling with the financial and emotional terrors of unemployment while hunting for work. The psyc bits are still relevant to employed job hunters, however. Job hunting is quite demoralizing and raises all sorts of insecurities. The chapters on finding work (particularly the chapter on using LinkedIn) are also totally relevant.
Land the Tech Job You Love is totally targeted at anyone who has read this far. One of the key pieces of early advice is to get your kit together before you do anything else. So, do that before you read the book ;) Once you have a resume, you're ready to hunt.
There are tons of sites where you can find job postings. Most of them will allow you to set up searches and get email and/or RSS notification of new jobs matching your search criteria. I have found that I get the best coverage from three sites: jobs.perl.org, indeed and craigslist. I've subscribed to others and I expect you would too. However, I got 90% of the value of RSS/email notifications from those three sites.
Now you'll have a steady stream of job postings clogging your daily diet of electronic media. Most of them are crap. Well, they're great jobs for someone, but they're not what you want. Get used to skimming and deleting these posts. You may be motivated to tune your queries to cut out more of the crap. You'll still have mostly crap to delete.
When you see something you like, you've already got your resume ready, so just tweak it for this particular opportunity and tap out a cover letter indicating why this opening excites you so and apply. Expect no response. It's just easier if that's your expectation. The hiring manager is normally a busy person. Now that they're short-staffed, they're even more busy. Eventually they'll get around to looking at the apps. It might be days or weeks. They may not reply to every applicant.
Just keep firing resumes through the front doors of attractive opportunities until you get some serious nibbles. (#blog_post_idea: resume hints)
That's one approach. Another is to go in through the side door. If you've got a nice-sized social network (#blog_post_idea: using LinkedIn), then you may well know someone in the company (or know someone who could introduce you to someone in the company). Reach out to one or more current developers and learn more about the position. This conversation is essentially a no-stress interview. You can learn more about them, and they'll be selling you on the company, and you won't yet be asked to sell yourself.
If you find that the position is a poor fit, then you've probably saved the company (and yourself) a nice chunk of time. If you decide to apply, you've got more details to use in crafting your resume and cover letter to fit the position and the challenges currently facing their team. You might also have the email of the hiring manager to ensure that they see your app before HR has a time to sit on the application for a week. If you actually know the folks on the inside, you might be able to get them to recommend you to the hiring manager (or at least to mention that they should expect your app soon).
If you're not sure what to ask, consider each of your prior jobs. What have you loved and what have you hated? What have you heard good/bad about other folks' jobs? As questions about all those sorts of things to ensure that they have much more of what you love and less of what you hate. Dave Rolsky posted a nice write-up of his personal set of questions last month. You might find his list to be inspiring if you're still coming up blank.
You really want to see if this opportunity is a good fit for you. The goal is not "to get inside contacts and build rapport" or "to sound cool and impressive". You're trying to learn. Put together a list of questions which will help you to learn whether or not you'd like to accept the advertised position.
Once you start finding interesting positions and start getting interview requests the job search becomes more interesting (ahem!). One problem is that i can be difficult to schedule time off. See if you can arrange for some regularly available time off (work early and have late afternoon free, work late and have mornings open; work long days and take half or even a full day off. Failing that, you're going to have use PTO every so often. (#blog_post_idea: interview hints)
I'll end this here. I've got a few more ideas for future posts. Right now I am struggling to keep my eyelids open. I'm sure that there are some strange typos in this text, but am too tired to re-read with any hope of finding them ;)
]]>Ron Savage asked what that job was. Well, I'm happy to share that. I'm working at Rentrak. Yes, they're hiring. I've been there going on eight years now. If you're in the market for a perl job in Portland, Oregon USA, then look them up.
Perks: tons of smart coworkers, serious about test-driven development, huge repos of code in much better shape than is typical out there (from what I've seen and from what I've heard from others), various degrees of XP and agile influence (which practices are in play depend on which team you land on... and may change over time), etc. There's more behind the link above.
If that strikes your fancy, submit your resume!
Note: that "huge repos of code" bit also means that much of the learning curve is learning your way around perl_lib/RTK. Rentrak has hired plenty of non-perl programmers who do great and contribute novel perspectives. Picking up perl is nothing compared to picking up the existing code. So, if you're a great hacker of some other stripe don't let a lack of perl experience stop you from applying.
]]>Alternatively, use short enough subs that you can always see the sub name when editing the sub (and manually correct any files which don't fit this convention).
]]>