geographical anonymity

On the Internet, nobody knows you live in Dogtown.

I've volunteered to do the publicity for PyOhio. I guess it's going really well. Two months out, we've already got 80 people signed up for the PyOhio announcements mailing list. If we assume that most of them will come to PyOhio, plus some others, and that the numbers will keep growing... maybe I'd better relax before we max out the library's capacity.

Still, bootstrapping a regional community is an interesting challenge. It's easy to go out on the internet and find a bazillion people who use Python - but how many of them are in or near Ohio? The wonderfully free-floating nature of the Internet and the open-source community, where geography is irrelevant, can become frustrating when geography actually is relevant.

Finding local companies is even harder. Most companies' websites try to give the impression that they have no geographical location whatsoever - wouldn't want to put off a potential client just because they're on another continent, after all. They also try to avoid mentioning the languages they use, again trying not to appear limited. (In a sense, that's a very good thing, because end users should shop for brains, not tools - it's just difficult for this application.) Finally, with a technology like Python, many of us users sneak it into our jobs without our higher-ups even knowing it, much less promoting it as a strength of their companies.

Any ideas? Googling for "Python Ohio" gets... well, me. Looking for "Python" plus the domain names of Ohio universities is helping a bit. (Universities, unlike businesses, do publicize their physical locations and the technologies they use.)

Anyway, if you've been thinking of submitting an abstract for PyOhio, quit thinking and write; our deadline is June 1 (this Sunday). And don't forget to blog...

That number again:

PyOhio

Regional Python programming miniconference

July 26th, 2008

Columbus Metropolitan Library

96 S. Grant Ave.

Columbus, OH 43215
USA

Tags: python open-source programming conference ohio

(Side note: Blogger's captchas are very near the threshhold of legibility, and getting worse. If I quit posting, I guess you'll know why.)

slides from SQL*Plus Alternatives

I've posted my slides from today's GCOUG presentation here.

Thanks for being a great audience! Feel free to contact me to ask questions about SQLPython or request new features.

cmd2 0.3.0

I'm speaking on SQL*Plus alternatives again on Wednesday at GCOUG, and trying to polish up sqlpython a bit in preparation for that. That required polishing cmd2; I've been increasingly embarrassed that cmd2 used homemade code (flagReader) to interpret --options --like --these, instead of using a perfectly good module from the standard library (optparse).

Optparse is not designed for iterative cmd-type apps where you remain at an application prompt after issuing each command - it keeps issuing sys.exit()s to kick you back to the shell. That was my excuse for not using it earlier, but once I decided to fix it, a little subclassing took care of it.

Next I got a little deeper into decorators than I'd ever been, to provide a concise way to specify those options:

@options([make_option('-k', '--ketchup', action="store_true", help="Ketchup on that?"),
         [make_option('-r', '--relish', help="relish (sweet or dill)")])
def do_hotdog(self, arg, opts):
    if opts.relish:
        self.stdout.write('One dog with %s relish\n' % opts.relish)
    if opts.ketchup:
         self.stdout.write('Hope you're not wearing white!\n')

That was pretty fun. Took some experimentation and this article, though, to figure out how to write a decorator that would accept an argument.

I didn't throw away the homemade ("flagReader") code, for backward compatibility; I issue a DeprecationWarning instead. I did throw away the guts and reimplement it as a wrapper around optparse. I managed to do that part on a single 20-minute bus ride, thanks to good doctests on flagReader. I feel so grown-up!

Finally, inspired by Brandon Rhodes' article in the March 2008 Python magazine, I tried supporting buildout deployments this time. I'm not sure I'm getting it quite right yet; expect it to actually work in cmd2 0.3.1.

PyOhio Call for Proposals

PyOhio: Call for Presentations

PyOhio, the first annual Python programming mini-conference for Ohio and surrounding areas will take place Saturday, July 26, in Columbus, Ohio. The conference is free of change and will include scheduled presentations, Lighting Talks and unconference-style Open Spaces.

You can read more about the conference at http://pyohio.org

PyOhio invites all interested people to present scheduled talks. All presentations are expected to last 40 minutes with a 10 minute question-and-answer period. PyOhio will accept abstracts covering any area of Python programming. A classroom area with computers will also be available for possible hands-on sessions.

All presentations proposals should submit abstracts no longer than 500 words in length. Abstracts must include the title, summary of the presentation, the expertise level targeted, and a brief description of the area of Python programming it relates to.

All proposals should be emailed to for review.

The submission deadline will be June 1, 2008. Accepted proposals will be notified by July 1.

choose the tool last

Yesterday, someone asked me if I could design "an MS Access database" for him.

Growl.

As I reflected on it, I realized that the problem is not really the particular technology specified - the problem is that the technology was specified at all before the need was described.

If I offered to make you anything you wanted for dinner, would you ask for "something made with a Teflon spatula?" If you did, I'd tell you, "No no no no no. Describe what you want to eat, and let me figure out what I'm going to use to cook it."

My potential client didn't literally mean that he wanted MS Access to be used, he meant that he wants a database with a GUI interface. He thinks of "Access database" as a way to describe that, because it's the only thing he's ever seen used to build products vaguely resembling the one he's imagining. It's nothing more than a limitation of vocabulary and experience.

The problem is that, so often, that kind of pidgin is taken literally. Tools are pre-selected far too early - while the business users are imagining their needs, before the geeks themselves are even involved,

As a result, there are a lot of geeks out there trying to beat eggs with Teflon spatulas.

My story ends happily, however. My potential client got it when I explained this, and we're going to meet so I can find out what he wants. Then - and only then - will we start discussing which tools to use.