My friend Noah, a sysadmin at MIT, reports that on October 1 he switched off the info-mac hyperarchive (hyperarchive.lcs.mit.edu), one of the oldest websites on the internet. It was a web-accessible version of the info-mac archive, an online repository of Mac freeware and shareware, which before then was mainly browsable via FTP. I have fond memories of spending evenings trolling through the hyperarchive's directory structure, looking for neat stuff to fill my Mac LC's 40 GB hard drive, circa 1994.

Several years ago, when I was writing the Nutshell book, I discussed the possibility of being the hyperarchive's volunteer maintainer. Nothing came of it, though, and the server was allowed to coast into electronic senescence. I see from that Wikipedia article that there exists an info-mac website that claims lineage from the original archive and mailing list, but it's now just one more computer-news website in a vast sea. It does sport a mirror of the info-mac archive, where it's quickly apparent how little traffic it got since the turn of the decade; viewing some categories by date shows you software from the 1990s on the first page.

Though the hyperarchive's role was supplanted by better-organized websites years ago (hello, versiontracker), I won't forget its important role in the early history of Macintosh software, the web, and myself as a computer dood. Goodbye, old friend!

I recently had a phone conversation with a recruiter who, after we established that I wasn't interested in a permanent position anywhere, confessed to me that she was having a great deal of frustration trying to find people with my skillset and level of experience who were looking for a new career.

To her - and to y'all - I say: Visit jobs.perl.org, and consider posting a want-ad there. In the few years the site's been up, it's quickly become the center of job-posting in the world of Perl expertise. Almost every client I've worked with independently or via Appleseed I met after they posted a job description on that site.

Excellent essay by Daring Fireball's John Gruber on Apple's poor decisionmaking regarding the App Store. They've had a penchant for kicking out applications due to one reason or another, and the main trouble here is that there's no way to know ahead of time whether or not your application will offend Apple until you actually create and submit its 1.0 release. For any app other than the most trivial, this means a lot of software-development time and energy not just nonchalantly discarded but made permanently unusable, since there are no routes to installing software on the iPhone other than Apple's.

If Apple maintains their current behavior, the only high-quality iPhone applications written with confidence will be published by large companies with enough clout to broker distribution agreements with Apple - with the occasional surprise gem from a hobbyist or other individual hacker. For the wide middle band of independent software professionals and entrepreneurs (such as yours truly), the App Store - and therefore the entire iPhone - looks less attractive as a target each time Apple arbitrarily nixes someone's hard work for unclear and inconsistent reasons.

Anyone who has used Unix more than a little has probably seen this message. I estimate I've seen it, oh, maybe as many as one hundred times in my career so far.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

It appears when you try to use the ssh command, which opens a secure login session with a remote Unix machine, but your own computer detects that something about the target machine's identity changed between the last time you connected to it and now.

In my experience, every single time this has happened, it's because the remote machine changed its IP address for one reason or another. That's not something that normally happens often to an individual machine, but when your normal daily routine involves connecting to an ever-changing variety of computers
via ssh, it's not an entirely rare phenomenon, either. So, I end up seeing this message once a month or more.

Its all-caps, exclamation-point-studded text is clearly meant to convey alarm and urge immediate wariness, but after you've seen it a handful of times, all that stuff is completely invisible. When I see it now, I think: Oh, has this machine's IP changed? Yes, I suppose it has. OK. It's good that I think that, but it has rather little to do with the words on the screen.

More valuable is the fact that ssh will refuse to create the connection until you edit a file containing the target machine's public key. (Typically, you just blow away the old key and let ssh generate a fresh one for the target machine's new identity.) This is correct behavior, and forces the user to think about what they're doing. I just wish that its programmers (or, today, its maintainers) chose a warning message that looks less like screaming paranoia that users will start to ignore the third time they see it, and more like rational admonition requiring a prudent safeguard. Hey, something changed. As a security precaution, I'm not letting you make this connection until you edit your .ssh/known_hosts file. You should only do this if you know why the target machine changed its identity. If you're not sure about this, consult your system administrator. That's all.

Our office space and mailing address have moved. From now on, please address all written correspondence and other postal materials to:

Appleseed Software Consulting
24 Lexington Ave.
#1
Somerville, MA 02144

This is the only pointer-change; all relevant email addresses and phone numbers remain as they were.

A List Apart, an online magazine about web design (in both the graphical and application-interface sense), has posted a new survey for web professionals, in an effort to construct a snapshot of the state of this young but enormous industry. Anyone who falls under the statement "I make websites" is invited to participate, anywhere in the world.

They did this last year, too, and this is an improved version of the survey based on what they learned as a result. I hadn't heard of that first attempt, but apparently its results impressed plenty of folks, as I've run into several pointers towards this followup effort. (And now you have another one.) I am definitely looking forward to seeing the results.

A bit of behind-the-scenes for you: when I first went independent last year, I gave myself the title "web architect", but wise friends advised me to drop that for being a phrase rather meaningless to anyone outside the profession - and, indeed, when I used it at local business conferences, I found myself having to explaining what it meant to nearly everyone I handed my card to. So I took on "software consultant" as a mantle, and have been trying hard to live up to that since. You can imagine, then, my surprise at discovering that "consultant" wasn't an option, but "architect" was, in this survey's multiple-choice list of job titles! "Other" it is, for me.

Here is a Making Light thread with interesting commentary, built on an essay by Jon Stokes on "IT consumerizaton and the future of work". Lots of good discussion on how technologies sold directly (or, in Googlish cases, made freely available) to consumers nowadays easily outpaces the technology and work-paradigms typically found in offices and enforced by IT departments, often by a factor of years.

For me, it brings to mind the continually increasing feasibility of distributed work environments, where a professional team doesn't work together nine-to-five in a physical office, but instead works wherever they happen to be, applying their own resources as they see fit, and using the internet to collaborate. I find this sort of discussion serendipitous, as I'm just starting to move Appleseed towards this sort of configuration, slowly and carefully bringing colleagues on-board as fellow consultants. It's a trend I've been noticing among several other newer, information-based businesses like mine.

The goal in our case is to allow Appleseed to serve more customers, without diminishing our level of personal attention to each. But I want to do it without sacrificing the independence I've enjoyed - and which has directly translated into higher-quality work for Appleseed's customers - since I launched the business, nor would I ask the same sacrifice from anyone I work with.

It's not something that's going to work for every kind of business. While a distributed office must maintain a minimal set of IT-style standards in order to keep all its team members synchronized, there's still a need for everyone to serve as their own personal system administrators. This is a lot easier to pull off if the company happens to be in the software consulting biz.

The results so far have proved quite promising. I feel quite confident about Appleseed's continued growth as both a great source of software expertise and a great place to work. (Sorry, though; no "careers" link on our website header just yet. :) )

Having apparently mislaid my print copy, I was surprised and delighted to just now find that Google Books has the full text of many pages from Damian Conway's Perl Best Practices online. Edit: Gah, I just realized that it's not the full text; many pages are arbitrarily withheld, and marked as such. My praise for the book still stands, however.

Those who have worked with me over the last couple of years have been subjected to my occasionally holding up this book as improving the way I wrote software faster and more profoundly than any other single influence. It not only made me a better Perl hacker, but changed the way I approach any software project, regardless of the programming languages it may happen to use. I cannot recommend this book strongly enough to my fellow professional Perl people, and suggest that even those who primarily work in other languages have a look.

Now, if you'll excuse me, I have some well-documented and robustly tested exception objects to throw...

Following my previous post, another consultant I work with mailed me to reveal himself as another FreshBooks fan, and pointed me to a free Mac OS X dashboard widget the service offers that obviates the need to use their web-based timer. My goodness! That's quite cool. This may be the first dashboard widget (beyond Apple's own orange calculator) I actually make regular use of.

I just sent out my first invoice via FreshBooks, an online time tracking and billing tool that a colleague recommended to me earlier. So far, I really like it! I'm impressed that it's an ad-free service that seems to make all its money by selling you things around the fringes, like the ability to accept online payments or send out invoice hardcopies via postal mail, while keeping all its core features free of charge. Same colleague suggested that it starts charging when you add a number of active clients beyond a certain limit, but if so, I haven't hit that yet. [Update: OK, I found it. It's free so long as you manage three or fewer clients with it, and then they require you buy into a monthly subscription.]

When I first went independent last year, my time-tracking system involved the clock on the wall and a text file full of date-grouped clusters of stop/start times, and my billing system was just rote re-use of the invoice template that ships with the Pages word processor. After a few months, I switched to using SlimTimer, a minimal-but-functional AJAX-based time tracker, which served me well for about half a year. The monthly, manual translations of lists of labeled time chunks into invoice tables was still a pain, though.

FreshBooks's timer, I have discovered, is at least as nice as SlimTimer's, and it's very easy to dump the information that it collects into nice-looking invoices, which it can then go ahead and mail to your clients for you. I am likely to stick with FreshBooks for a while.