Code wants to be responsive to change, and when it doesn't get its
way it tries to warn us. But often we aren't listening because it's
too easy to plow ahead to the next feature. Unfortunately, in our
haste we miss a golden opportunity to improve the code, which is
actually the design. And although the consequence of ignoring the code
isn't immediately noticeable, it quickly starts to drive up the cost
of change.
In the latest installment of my Code Craft column, "Relocate
for Reuse", we stop to listen to the code. Heeding its
warnings, we find a new home for small methods that fell out of
earlier refactorings, and end up with code that can be reused.
(Tue Oct 18, 2005) [/Rails] #
Let me start by saying that the information I'm about to describe is
the result of programming for fun. I've been watching the uptick of
Ruby and Rails job postings with keen interest as of late to see if it
offers any insights into the future trends of Ruby and Rails. Clearly
I'm sold on the value
these technologies bring to the table, but are other projects also
looking to cash in on the benefits of Ruby and Rails? And if so, what
skills are they looking for, where are the projects based, and what
kind of employment arrangement are they offering? I don't have all
the answers yet, and likely never will, but that never stopped me
before.
So I started by tuning my RSS reader in to Jobs.Rubynow.com and watching the
first 30 Ruby/Rails jobs get posted. (It's a free site, so I figure
there's no reason employers wouldn't post there.) The RSS feed would
have been helpful if I was actually looking for a job. But I'm less
interested in the details of a specific job posting (one data point)
than I am in data aggregated across all postings (a potential trend).
Synthesizing all the postings into a summary report that tries to
answer the aforementioned questions called for some automation. As
new jobs are posted, I need to remix all the data. Now, I don't have
direct access to the database used by Jobs.Rubynow.com, or any other
site's database, so I have no choice but to resort to the world's
greatest remote database access tool: screen scraping. That, a wee
bit o' Ruby code, and an ERB template turns all the job postings into
ten buckets of tokenized terms and the number of times each term was
used in the postings. That's it. No statistical analysis. Simplest
possible solution. I made no effort to get fancy other than to use
regular expressions to ignore the HTML tags, white space, and some
boring words such as the. Indeed, I wanted the data to be
raw so that it's open to interpretation.
Have a look...
I think it's still too early in the game to spot trends, especially
with such a small sample set. And rather than try to draw conclusions
for you, I'm interested to hear if you find anything worth keeping an
eye on. Does the fact that there are almost as many off-site
(telecommuting) jobs as there are onsite jobs say anything about where
we are in the adoption curve? How do you get a Ruby/Rails job if the
top required and desired skills are related to experience with Ruby
and/or Rails? Are you more likely to find a job if you have
prior experience with Java, PHP, or both? What buzzwords aren't on
your resume? Why do recruiters have such poor spelling skills?
And of course this data may be utterly meaningless. After all, the
word management listed in the Required Skills
section has zero subcontext. You don't know if they're looking for
someone with an MBA or someone with experience driving a truck for
waste management. I'm ok with that. Again, it was a fun little hack
to write. I'll run it once in a while to see if anything compelling
pops out. Or, better yet, perhaps the folks who run the job site will
do it for us...
