Releasing Early Releasing Often
My bits often suck but one day turn out useful


I have a tendency to explore a cool new idea, write some code to test it out, hit a snag, then shelve the project.

Or I’ll write a hack to solve a specific problem, get it working good enough for me, but not be proud enough of the qualty to go through the trouble of releasing it.

In both of these cases the code would bitrot, and I’d eventually lose it, only to have to rewrite it from scratch when I needed it again.

Also, in the past, I was often under NDA restrictions that made releasing any code require legal review.

Fourthly, managing small bits of code under a good source code control system used to require a lot of setup.

These latter two problems aren’t a problem anymore with the advent of social coding.

My (early) New Year’s resolution: REFORM! Release more code more often. In that spirit I’ve taken the time to put 2 of the coding projects I’ve been working on “out there”, on my web servers, and in a git source code repository in the cloud that anyone can access.

Gnugol

The project with the most potential is gnugol. Gnugol is a command line web search client with an interface to emacs. Unlike surfraw (which is excellent, btw, and their web site is hysterically funny!), it outputs the search results in the format I’m working in - org-mode primarily, but also wiki and plain text. It saves a mental context switch.

Gnugol is also very fast, as it’s written in C. I like, and use it, a lot. I wish it did more stuff.

Cryptolisting

It has always bothered me that email’s ancient RFC2487, published in 1999, basically prohibited “crypto-by-default”, specifying a 530 5.7.1 “reject” message rather than “try again later, with crypto enabled”. My cryptolist postfix policy daemon (modified from greyfix) checks for STARTTLS being enabled, and has a modifiable greylisting policy for encrypted and unencrypted email transports. It is not perfect but I hope it will encourage the use of more cryptography for email exchange.

Neither project is “done”, but both are usable as is, and in focusing myself on getting releases out, I’ve:

  • Improved my own workflow. I can now (almost!) commit/build/publish a project with a single keystroke.
  • Improved both bits of code to where I’m not too disgusted with my coding skilz
  • Fixed a few bugs and added some features I’ve always wanted
  • Got a roadmap for both projects
  • Written/corrected a ton of documentation
  • Maybe helped out some people that have wanted something like these

Marvelously focusing is the idea of “doing a release by Christmas”!

I have numerous other half-baked projects I’ve been sorta-kinda-half maintaining for years, and I’m going to try to get them sorted out and “out there” so I shan’t lose them ever again. But first, I want to finish these. Maybe there’s potential contributors out there that can help tackle some of the bugs and missing features

Find me elsewhere.

Best of the blog Uncle Bill's Helicopter - A speech I gave to ITT Tech - Chicken soup for engineers
Beating the Brand - A pathological exploration of how branding makes it hard to think straight
Inside the Internet Mind - trying to map the weather within the global supercomputer that consists of humans and google
Sex In Politics - If politicians spent more time pounding the flesh rather than pressing it, it would be a better world
Getting resources from space - An alternative to blowing money on mars using NEAs.
On the Columbia - Why I care about space
Authors I like:
Doc Searls
Jerry Pournelle
The Cubic Dog
David Brin
Charlie Stross
Eric Raymond
Anonymous
WikiLeaks
The Intercept
Chunky Mark
Brizzled
Dan Luu's rants about hardware design
Selenian Boondocks
Transterrestial Musings
Callahans

February 10, 2011
491 words


Tags
latency code