Debugging: Essential Technological Literacy, via CoolTools; a good-looking book that most programmers should read.
So Close, Yet So Far -- (not) publishing well online.
A process diagram for arguing about Intelligent Design.
Mac OS X and FTP
So, let me get this straight -- you can easily mount a WebDAV folder on your OS X desktop, and you can just as easily mount an FTP site on your desktop. The difference, of course, is that the FTP site can only be mounted read-only! Why? I can only guess... it doesn't seem like it'd be that difficult to do technically. Hell, it works in Windows...
In other news, a lot of OS X FTP GUIs suck. FTP Thingy didn't do a very good job of dealing with anonymous uploads... I recommend Cyberduck if you need a drag&drop FTP solution.
(Fugu is the way to go if you need to give an Apple user an SCP/SFTP interface.)
On Web services...
Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications.
An interesting, if a bit overly self-congratulatory article on AJAX-iness by Joel Spolsky.
Musings on the nature of OSS "marketing"
So I've been working on a fairly kick-ass piece of software I'm calling scotch, which contains a Web recorder/player (scotch.recorder) implemented as WSGI middleware and a Web proxy (scotch.proxy) implemented as a WSGI app. This lets you do obviously cool things like set up a recording proxy server, or do regression testing by recording Web sessions and then playing them back and comparing "now" responses with the "then" responses, or grok precisely how asynchronous HTTP transactions (aka AJAX) are being used by a site. (I've already used it for all three.) I've got a primitive twill translator written for it, and I'm thinking about writing a translator for Selenium, too. The architecture I've chosen -- decoupled WSGI objects -- is very nice because it allows me to chain things arbitrarily; I want to eventually add a cookie cleaner, a reverse proxy system, and an anonymizer, all of which could be swapped in and out as WSGI middleware. Heck, you could even use this as the basis for an "offline" browsing cache, or write a Web frontend that lets you browse through the recording as it's happening, or ... well, let's just say that a lot of tomfoolery could happen. It isn't even Python limited, because of the proxy app -- that can interact with anything in any language, as long as it speaketh HTTP.
My current source of cognitive dissonance here is that I just don't know how to start writing it up, or where to target my development. (I also don't seem to have any time these days, but that's not a problem that can be solved by anyone else. ;) How should I best apply my limited time?
Here are a couple of possible strategies:
- post what I have, and blog about all the neat, nifty, or just
plain cool things I'm doing with it. Hope people care.
- develop out a few specific applications -- regression testing and
twill translator are two obvious ones -- and write articles about using
scotch to solve real problems. Hope people care.
- figure out what other people want to use it for, and let them
proselytize it while I introvert on the architecture and coding. Assume
- start a company, and ... naaaaaah, never mind ;)
All of this boils down to thinking about "marketing", albeit in the OSS world rather than in the world of $$. And in that world I have reached a simple conclusion: marketing doesn't matter, at least at the scale I can do. My two biggest OSS "successes" so far are Cartwheel (used by 100s of biologists) and twill. Neither of these projects was really "marketed" by me; they were immediately useful to other people, who picked 'em up and ran with them. In a badly mixed metaphor, I'm just trying to stay on the horse -- and I really can't steer it very well.
Back to scotch. I think my best bet is to do two things up front: document as well as possible, and release a solid if not well-rounded implementation. If people find it useful, they'll use it; if not, not. It's the "market" at work...