Spyced

David MacIver has an interesting blog entry up about determining logical project structure via commit logs . I was very interested because one of Cassandra's oldest issues is creating categories for our JIRA instance. (I've never been a big fan of JIRA, but you work with the tools you have. Or the ones the ASF inflicts on you, in this case.) The desire to add extra work to issue reporting for a young project like Cassandra strikes me as slightly misguided in the first place. I have what may be an excessive aversion to overengineering, and I like to see a very clear benefit before adding complexity to anything, even an issue tracker. Still, I was curious to see what David's clustering algorithm made of things. And after pestering him to show me how to run his code I figure I owe it to him to show my results . In general it did a pretty good job, particularly with the mid-sized groups of files. The large groups are just noise; the small groups, well, it's not e...

There were a lot of good talks at PyCon but I humbly submit that the best one you haven't seen yet is Robert Brewer's talk on DejaVu . Robert describes how his Geniusql layer disassembles and parses python bytecode to let his ORM turn python lambdas into SQL. Microsoft got a lot of press for doing something similar for .NET with LINQ , but Bob was there first. box = store.new_sandbox() print [c.Title for c in box.recall( Comic, lambda c: 'Hob' in c.Title or c.Views > 0)] This is cool as hell. The Geniusql part start about 15 minutes in.

I'm starting to conclude that git just doesn't fit my brain . Several months in, I'm still confused when things don't work the way they "should." My co-worker says I should start a wiki for weird-ass things to do with git: "You keep coming up with use cases that would never occur to me." But, I have to give the git community credit: I've never gone in to #git on freenode and gotten less than fantastic help. Even with git-svn.

I'll be leading an open-spaces discussion about distributed database architecture, implementation, and use today at 5:00 PM in the Lambert room. Specifically, we will cover bigtable, dynamo, and cassandra, and how to port a typical relational schema to cassandra's ColumnFamily model. I wrote a little background information yesterday about why I think Cassandra in particular is compelling .

I need a distributed database. A real distributed database; replication doesn't count because under a replication-oriented db, each node still needs to be able to handle the full write volume, and you can only throw hardware at that for so long. So, I'm working on the Cassandra distributed database. I gave a lightning talk on it at PyCon this morning. Cassandra is written in Java and implements a sort of hybrid between Dynamo and Bigtable . (Both papers are worth reading.) It takes its distribution algorithm from Dynamo and its data model from Bigtable -- sort of the best of both worlds. Avinash Lakshman, Cassandra's architect, is one of the authors of the Dynamo paper. There is a video about Cassandra here . The first 1/4 is about using Cassandra and then the rest is mostly about the internals. Cassandra is very bleeding edge. Facebook runs several Cassandra clusters in production (the largest is 120 machines and 40TB of data ), but there are sharp edges th...

I'm running Linux on my desktop at work after a year of OS X, and Gnome as shipped by Ubuntu 8.10 has just been a world of hurt. The panel looks and works like ass when moved to the left side of the screen (the only sane place to put it in today's world of widescreen monitors), network-manager just decided to quit working one day (I got by with wicd after that), alt-tab behavior sucks both ways you can configure it, etc. I installed KDE 4.2 over the weekend to see if I was missing anything there. Wow. It's like daylight after being in a cave for two months. I didn't realize how hard it has been to use a butt-ugly environment until I wasn't anymore. (Yes, I tried all the gnome themes I could find. Even Nimbus which took a bit of work. What's that recently-famous phrase? "Lipstick on a pig?") What is better in KDE? In a word, everything. And put me in the camp that really likes having the desktop turned into a usable area for the first time. ...

I will be giving an Introduction to SQLAlchemy tutorial and Mike Bayer and Jason Kirtland will be teaching Advanced SQLAlchemy , both on Thursday. I'll be covering similar material as last year , updated for 0.5. I'm also trying to see if I can get the emails of the registrants so far to see what else they would like covered. My tutorial style is exercise-heavy, so if you've read the docs or my slides but still find it hard to write SQLA code, coming to the tutorial is a great way to fix that. (Note: the blog link to the 2008 slides is broken since we moved utahpython.org. If you want them, drop me a note.)

It seems like Bloom filters are all the rage these days. Three years ago I had barely heard of them and now it seems like I see articles and code using them all the time. That's mostly a good thing, since bloom filters are a very useful tool to avoid performing expensive computations without the full memory overhead of a standard map/dictionary. Bloom filters are surprisingly simple: divide a memory area into buckets (one bit per bucket for a standard bloom filter; more -- typically four -- for a counting bloom filter). To insert a key, generate several hashes per key, and mark the buckets for each hash. To check if a key is present, check each bucket; if any bucket is empty, the key was never inserted in the filter. If all buckets are non-empty, though, the key is only probably inserted -- other keys' hashes could have covered the same buckets. Determining exactly how big to make the filter and how many hashes to use to achieve a given false positive rate is a solved p...

This is my attempt to clear up some misconceptions about CouchDB and point out some technical details that a lot of people seem to have overlooked.  For the record, I like Damien Katz's blog, he seems like a great programmer, and Erlang looks cool.  Please don't hurt me. First, and most important: CouchDB is not a distributed database.  BigTable is a distributed database.   Cassandra and dynomite are distributed databases.  (And open source, and based on a better design than BigTable.  More on this in another post.)  It's true that with CouchDB you can "shard" data out to different instances  just like you can with MySQL or PostgreSQL.  That's not what people think when they see "distributed database." It's also true that CouchDB has good replication, but even multi-master replication isn't the same as a distributed database: you're still limited to the write throughput of the slowest machine. Here are some reasons you should think tw...

Today marks one month that I've been working for Rackspace's RackLabs with the Mosso group in San Antonio, Texas.  (Anyone want to start a Python group?  The closest one is in Austin.) It's kind of a gentle introduction to big company culture for me; at around 2,000 employees, Rackspace is easily ten times as large as any other company I've worked for, and 100 times as large as most.  Mosso is a lot smaller and RackLabs itself is smaller still, but I still had to go to five days (!) of corporate orientation.  Other than that, though, we're pretty much left alone by our corporate parent. To start with, I'm working on Mosso's Cloud Files , which is basically an S3 competitor.  Cloud Files is similar to the work I did at Mozy, but there are a lot of technical differences.  Some are driven by Cloud Files being more of a general purpose storage engine than the one I wrote for Mozy; others stem from the Cloud Files authors being Twisted fans. Strange coincidence:...

I'm a little over a week into a git immersion program.  Let me just say that git's reputation of being a little arcane (okay, more than a little) and having a steep learning curve is 100% deserved. One thing that would mitigate things is if git would give you feedback when you tell it to do nonsense.  But it doesn't.  Here's me trying to get machine B to always merge the debug branch from machine A when I pull: 232 git config branch.debug.remote origin 234 git config branch.master.remote origin 236 git config branch.master.remote origin/debug All of these commands completed silently. None accomplished what I wanted. In the end I renamed master to old and debug to master to avoid having to fight it. Then I blew away my working copy and re-cloned because those config statements had created a new problem that I didn't know how to undo. I'm sure the git virtuosos out there will know what was wrong.  That's not the point.  The point is that the tool gave me n...

FormAlchemy 1.1 is out, so you no longer need to run trunk to get the admin app goodness -- now with i8n support. We also added support for all composite primary keys, and most composite foreign keys. (The distinction is, rendering an object depends on the PK, but loading relations depends on FKs.) Gael also added the fsblob extension , which allows storing blobs on the filesystem and the path in the database. (FormAlchemy can handle blob-in-the-db out of the box.) (I previously blogged about basic FormAlchemy and the admin app , which are still good introductions.) FormAlchemy has pretty good documentation . The most important page is form generation ; instructions to configure the admin app are here .

I saw an interesting article about logging today on reddit, and it struck a nerve with me, specifically how most text logs are not designed for easy parsing.  (I don't agree with the second point, though -- sometimes logging is tracing, or perhaps more accurately, sometimes tracing is logging.) We had a lot of log and trace data at Mozy, several GB per day.  A traditional parsing approach would have been tedious and prone to regressions when the messages generated by the server changed.  So Paul Cannon, a frustrated lisp programmer , designed a system where the log API looked something like this: self.log('command_reply(%r, %r)' % (command, arg)) Then the log processor would define the vocabulary ( command_reply , etc.) and, instead of parsing the log messages, eval them!   This is an approach that wouldn't have occurred to me, nor would I have thought of using partial function application to simplify passing state (from the log processor and/or previous log entrie...

I said that it would be possible to build a django-style admin interface for Pylons using FormAlchemy . (That is, generate a UI for basic CRUD operations for all your models, with no further configuration necessary.) I have a proof of concept in FA svn; it's missing some obvious features like internationalization so there is no official release yet. But the basics are there, so in the meantime, if you'd like to kick the tires , just install FA from svn and give it a try. Here are some screenshots from a pylons app incorporating models from the FA test suite. (The admin controller is fully customizable using standard FA (and Pylons) techniques, but these are what you'd see out-of-the-box.) Index: Order page: Creating a new Order: Deleting an Order: The User page: Editing a User instance: Documentation on using and customizing the pylons admin app is here .

A little background: a few months ago, I went looking for a web framework that was good at automating CRUD (create/retrieve/update/delete) against an existing database schema. I tried django but its database introspection abilities are beyond feeble, and django-sqlalchemy was not mature enough. I tried dbmechanic but its dozen-plus dependencies, most of which were alpha-quality, gave me pause; so did its basic architecture on top of toscawidgets, which I think is The Wrong Way to build web apps. (I understand that the former problem has since been reduced; the latter has not.) So, I went back to option #3, FormAlchemy . I knew SQLAlchemy could reflect very hairy schemas indeed, and what it could not reflect, it could certainly represent with a little manual help. And FormAlchemy was a decent start to automating CRUD with SA models. I added the ability to represent relations, automatic syncing of form input back to SA objects, Grid support, and a test suite. Then Gael came alo...

Feature50 is winding down now that CEO Ben Galbraith has accepted a job offer elsewhere.  So, I'm interested in exploring my options, specifically, opportunities to build out the technology for a start-up working in concert with a strong business CEO. I've done this twice now. Technical ability I am a senior developer specializing in back-end technologies.  At Mozy , where I was employee #2, I wrote a distributed file repository that stores petabytes of data, an amount comparable to Amazon's S3.  I have 8 years of experience with PostgreSQL. I know how to design for scale, and how to find and remove bottlenecks.  I am not afraid of diving into a new code base; I took over as maintainer of the Spyce web framework and the FormAlchemy toolkit, and I have contributed features or patches to SQLAlchemy, Pylons, and Jython, among others.   Soft skills I enjoy building and working with a team.  At Feature50 I am responsible for technical interviews, and personally recruited fiv...

As with many things in the blogging echo chamber, blog day takes itself a little too seriously. But it's impossible not to love an excuse to talk about some of my favorite blogs that don't seem to have as much exposure as I think they deserve: Theo Schlossnagle , CEO of OmniTI, a scalability and performance consulting company. His best posts deal with scalability at the ops level . His book is good, too. Greg Linden , ex-Amazon engineer, ex-Findory founder, current MS Live Labs employee. He likes to post analyses of interesting CS talks and papers, particularly in the area of collective intelligence. Greg stays very on-topic so the most recent posts are about as representative as any. Chris Siebenmann writes about life as a professional sysadmin . He also sometimes blogs about python . Josh Berkus , PostgreSQL core team member, mostly blogs about current events in the database world, but every once in a while he writes a must-read post about database design . Google th...

Having been eyeball deep in App Engine for a while, evaluating it for a project at work and putting together a presentation for the utah open source conference, I've reluctantly concluded that I don't like it.  I want to like it, since it's a great poster child for Python.  And there are some bright spots, like the dirt-simple integration with google accounts.  But it's so very very primitive in so many ways.  Not just the missing features , or the "you can use any web framework you like, as long as it's django" attitude, but primarily a lot of the existing API is just so very primitive.   The DataStore in particular feels like a giant step backwards from using a traditional database with a sophisticated ORM .  Sure, it can scale if you use it right, but do you really know what that entails? Take the example of simple counting of objects .  There's a count() method, but in practice, it's so slow you can't use it.  Denormalize with a .count pr...

My App Engine 101 slides and code are up now. Bad news: my macbook pro did not work with the projector, period. Good news: I have seen it do this before (in a room with several mac experts -- it was not user error) and brought a backup laptop. Bad news: I forgot to include the django beta1 framework in my code upload, so I told people to just download it. But beta2 was out, and didn't work with the version of App Engine Helper I had. (It looks like r58 fixes this.) Manual poking about the django download site ensued until I got a new zip uploaded. Good news: the conference organizers liked it anyway and asked me to present a second time later in the day. Everything just worked the second time around.

App Engine is probably the biggest thing to happen to Python this year, so of course I volunteered to give a presentation on it at at the Utah Open Source Conference . (I'm scheduled for Friday, Aug 29, at 10:00 AM.) Last year's conference was a big success, so I'm looking forward to an even better experience this year. Here's the abstract I submitted, before they blew away my paragraph breaks: Google launched the App Engine service earlier this year to immense interest from the web development community. App Engine allows running applications on Google infrastructure, including BigTable, Google's non-relational, massively scalable database. App Engine is appealing both at the low end, where small shops don't want to have to deal with hardware procurement and systems administration, and at the high end, where the kind of "instant scaling" App Engine promises to deal with bursty traffic is the holy grail of infrastructure planning. This tutorial will ...