Blog is moving!

This blog is going to the cellar. New blog at http://blog.christophermahan.com/

Uh, actually, no. Blog is going away. Continue at http://christophermahan.com/

Pyrant

Pyrant (http://code.google.com/p/pyrant/) is a fork of pytyrant that supports the TokyoCabinet table data store. Still in beta, but more actively developed than pytyrant.

recession proof graduate

http://www.slideshare.net/ramit/recessionproof-graduate-1722975

Interesting. Especially since it comes from a 22 year old.

Socal-piggies

Great get-together at the socal-piggies meeting today!

Cool presentation on some tools Dan Stromberg put together (pnetcat, looper), and a nice demo of TokyoCabinet+TokyoTyrant+pytyrant+restish by Grig Gheorghiu, following a retailed presentation, also by Grig, and discussion about REST for those in the meeting who had not been exposed to it.

There was a discussion on whether is was ever appropriate to expose (db) transactions as REST URI. Grig Spoke highly of RESTFul Web Services by Leonard Richardson and Sam Ruby.

I passed around some back issues of Python Magazine encouraging people to take the ones they would find interesting, and about half were taken. I'll bring them to the next meeting and hopefully they will all be gone!

I also promised Grig that I would do a socal-piggies presentation on the backend for grabatask.com that I am building. It involves an API in FAPWS with pytyrant that stores and retrieved data from TokyoCabinet throught TokyoTyrant.

I personally liked the discussion on how to use TokyoCabinet tables from within python. Great stuff!

Slide on Netflix Culture

Outstanding.

pytyrant

>>> import pytyrant
>>> t = pytyrant.PyTyrant.open('127.0.0.1', 1978)
>>> t['__test_key__'] = 'foo'
>>> t.concat('__test_key__', 'bar')
>>> print t['__test_key__']
foobar
>>> del t['__test_key__']

obvious no?

from http://code.google.com/p/pytyrant/

Sharin's poem

I wrote a poem for Sharin Bhatti. She really liked it.

She noted that she'd never come across that meter. She called it Chris Meter. 8-6, repeat.

Recent tweet by a coder I know (VS2008)

OMFG! ARGH! I QUIT! I CANT DO THIS ANYMORE! I AM RESKILLING TO FLIP BURGERS! ARGHHHHHHHHHHHHHHHHHH! OMFGWTF-BARB-E-EFFING-QUEEEEEEEEEEEEE!!!

Discouraged by version control

So I watch the Git vs Mercurial vs bazaar vs SVN low-intensity conflict simmer on the intarweb and I wonder... Is is me or has all that stuff suddenly become Too Hard to use? Where has it all deviated from the Unix philosophy and gone down the Enterprise Way?

I think I'm just going to go back to the old way: compressed archives of (few) directories.

For those who ask, indignantly, and not on this blog because comment count is almost negative, about the multi-member team working on massive software, I reply: The Rule Of Modularity (http://www.faqs.org/docs/artu/ch01s06.html#id2877537), which I transcribe here purely for effect.

Rule of Modularity: Write simple parts connected by clean interfaces.

As Brian Kernighan once observed, “Controlling complexity is the essence of computer programming” [Kernighan-Plauger]. Debugging dominates development time, and getting a working system out the door is usually less a result of brilliant design than it is of managing not to trip over your own feet too many times.

Assemblers, compilers, flowcharting, procedural programming, structured programming, “artificial intelligence”, fourth-generation languages, object orientation, and software-development methodologies without number have been touted and sold as a cure for this problem. All have failed as cures, if only because they ‘succeeded’ by escalating the normal level of program complexity to the point where (once again) human brains could barely cope. As Fred Brooks famously observed [Brooks], there is no silver bullet.

The only way to write complex software that won't fall on its face is to hold its global complexity down — to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole.

On writing software.

Excellent rant by Bruce Eckel on what it's like to write software. Along a similar vein, a post by Mark Ramm that generated lively and interesting comments!

Then more interesting stuff here from Jakob Kaplan-Moss with lively discussion, including Ian Bicking.

On thinking in

Part of the ongoing thinking forming in my mind about how I create software.

I left a comment there:
http://myownhat.blogspot.com/2009/07/help-how-do-you-do-test-driven-design.html

See also: http://chrismahan.blogspot.com/2008_10_01_archive.html

I've just made another interesting deviation while rereading the above. The rulers in Dune relied on the mentats to best determinate long-term strategy, as well as implementation details. The elder Herbert continues to amaze me.

Python in the Browser?

I so can't wait for this to work!

By work, I mean usable by mortals like me.