Aftermarket Pipes 2004/8

Back to the salt mines

Mmm... writing unit tests today. I like Test Driven Development.

However, after using unit testing frameworks in languages with proper introspection, using them in languages without them is painful.

Oh well... suck it up.

On an unrelated note, I'm back to SPE. Too many pretty shiny things to stay away, I suppose.

Can you fly that thing? Not yet...

Every once in a while I notice something that reminds me of a scene from a movie. Generally, if it's a movie that has made me think a bit or consider things in a new light (Fight Club, The Matrix, and Pulp Fiction are a few), it means there's something worth chewing on in the situation.

I'm no Matrix fanboy, but I had an experience that put me in mind of one scene. Neo asks Trinity if she can fly a helicopter. She answers, "not yet," calls up her "operator", and he transfer the appropriate skills to her virtual persona.

Today I wanted to check out something using the ctypes module, so I popped open an interpreter window and typed import ctypes. No dice--I didn't have it installed on my work machine. One quick download and install later, I uparrow+entered in the same interpreter, and had ctypes available.

But this could get better. PyPI is gaining traction--it's not CPAN yet, but it seems to be turning a corner. Thinking in terms of yum and apt-get, what would be very cool is to turn this:

>>> import blahdb
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named blahdb
>>> [switch to web browser, hit Google, find the right page, find the download for my version of Python, 
     download, find installer, run installer, switch back to console]
>>> import blahdb
>>>

into this:

>>> import blahdb
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named blahdb
>>> install(blahdb)
PyPI: found blahdb (Library for accessing Blah databases) version 1.6 for Python 2.3
PyPI: <blah_author@python.org> signature OK
PyPI: installed.
>>> import blahdb
>>>

or even this:

>>> from __future__ import magic_imports
>>> import blahdb
>>>

The Contractual Obligation Post

It appears that, as it has "Python" in the tagline, this blog is legally required to comment on the current decorator controversy in the Python community.

I think Hans Nowak has the best and most thorough explanation of what the new decorator does (at least in its current implementation), and exploration of how you can use it in interesting ways. Certainly, it's been the explanation that fits my brain best.

Everything I've seen so far, though, has been "this is how it works", plus some "this is cool because it makes classmethod less of a special case". And it lets you extend the language, which is very good, in that Python-as-a-larval-Lisp way.

The next obvious question to me is, which interesting applications of decorators are going to be provided in the standard library? There are a number of "good ideas" (function attributes, synchronized, docstring replacement, PyProtocols implementation, magical hook insertion like atexit and sys.settrace, etc.)

My biggest concern: right now, everyone is caught up in the syntax for the feature, and to a lesser extent, the implementation corner cases. I haven't really seen anyone (and by "anyone" I mean the BDFL) talking about what decorators will exist as part of the standard Python distribution.

I fear that decorators will become Python's equivalent of the "everyone's own favorite homegrown string library" phenomenon we saw in the early days of C++. Everyone will have their own favorite and flawed implementation of @synchronized.

O'Reilly and Trackback permission

As a few people have pointed out, "slimy" is rather a harsh word to describe O'Reilly's requirement that bloggers create a O'Reilly account in order to get a trackback URL.

Don't get me wrong. I like O'Reilly books, and I like the company.

But I still don't like the practice--it pretty much undermines the whole idea of cross-site blogging and trackbacks. It's reminiscent of the universally-ridiculed "site linking policies" of early corporate Internet presence ("you can't send any visitors to our site unless you notify us ahead of time and get our permission"), and it's not exactly what I've come to expect from a company like O'Reilly. I expect more from them, based on their track record.

So slimy? No, not really. Just disappointing.

Fixing the Mix: Junior and Senior Developers

William Grosso over at the O'Reilly Weblogs notes that "less than 5% of the available positions are for junior developers", and is looking for reasons why. He thinks that it's being caused by the economic environment, and that in a better economic environment the proportions would be different.

Maybe so, but I think there's more to it. One of the complaints I had at my last job was the practice of only hiring senior engineers, which predated even the Internet "bubble" years. I don't know whether this is becoming the norm elsewhere, but the thought was that the office didn't have time to let junior engineers grow, and there were enough senior engineers available in the area not to have to worry about it.

I haven't been able to articulate why this bothered me. It's more a feeling that an all-senior shop creates a bit of a fragile ecosystem, but I haven't been able to quantify this beyond such fuzzy terms.

One of the dangers of having an all-senior shop is that senior engineers tend not to have the off-hours time and energy for learning about everything coming down the pike. I know I don't spend as many off-hours learning about new technologies as I did ten years ago.

Another piece of anecdotal evidence: the first place I worked, the environment was about 20% junior, about 70% mid- to senior, and 10% what I'd consider "emeritus": people who had been in the industry since the Altair came out, and were mostly doing interesting research projects and setting technical direction. That seemed like a good mix.

I'm not sure what the mix is here, partially because the ranking system is in flux and we're growing so fast.

An aside: oreilly.weblogs.com forces you to create an account there before it will give you a trackback URL. That's surprisingly slimy from a company that usually does the right thing.

Editing Python Code: The Quest Continues

Sigmund's Crypt - Doom 3

One of the nice features of the new company is that there are a couple of gamers there. Haven't worked with gamers since... well, since I worked at a game company.

So far the hardest of the hardcore seems to be Sigmund. We'll see... time to exercise the "PC reimbursement" feature of the new company and get training on some FPS action. The only other hardcore I've played on a regular basis was Brother Dog, and that was years ago.