Archives for 2011

  1. Hitchhiker's Guide to Python

    I first heard about The Hitchhiker's Guide to Python at PyCodeConf a few months ago. It's a fantastic idea: open source, community-driven documentation on how to do Python right: everything from how to learn Python, to how to write idiomatic code, to how to distribute your projects, to surveys of best-of-breed open source projects and libraries you can build projects and applications on top of. Many many thanks to Kenneth Reitz for creating and maintaining the project, which is hosted at GitHub.

    At this time, the Hitchhiker's guide is a little rough around the edges: many sections are only outlined, and need content written; other sections may not even exist yet. We can safely consider it a first draft, or, if you prefer, an alpha.

    This sort of undertaking is effectively impossible for one person to maintain--one person can't possibly know of every project, library, and idiom. Moreover, it's unfair as a user of the Guide to demand that one person must do all the work.

    Therefore, a call to action: in order to make the Python community great, everyone should fork the Hitchhiker's Guide today, find (or add) a section of interest, and submit a pull request. If you're lucky, Kenneth will give you a sparkly cake.

    And a pledge: time allowing (for, sadly, contributing to Python documentation is not my day job), I will make one contribution to the Hitchhiker's Guide per week until it reaches completion, or until there's nothing left to which I can conscientiously contribute (I won't attempt to document things which I know too little about).

    Finally, since this is a community effort, I want to give a shout-out to all those who've contributed to the Guide so far:

    Thanks to everyone who's helping to make Python a better place!

    (To the folks above, if you'd like me to add or correct any of the contact information, please leave a comment.)



  2. Truncating HTML with Python

    On the 10gen events pages we show a table of sessions for our MongoDB Day conferences, some of which are quite crowded. In order to try to keep the table relatively sanely laid out, we truncate the session descriptions to about 150 characters, and add a "Read More" link which expands to show the full description.


  3. Keystone: A Simple Python Web Framework

    After a conversation with my friend and co-worker Jesse Davis last week about Python web frameworks, I had an idea: what if there were a Python web framework that combined some of the simplicity of workflow and deployment of PHP with the readability and embodiment of best practices of Python? This should be a framework targeted towards folks who want to (or need to) learn web development, but don't have the background, interest, or time to learn one of the heavy-weight frameworks (like Pyramid or Django) or middle-weight frameworks (like Flask or CherryPy). This framework should let you get started immediately, and let you move smoothly from static sites to dynamic sites, let you learn best practices of both Python and web programming, and should not stand in your way when it comes time to go live or scale up.


  4. Ensuring Write-Your-Own-Reads Consistency in MongoDB

    In a question on StackOverflow a few days ago, a user was asking how to ensure that a document hasn't changed between when a client read the document and wrote to it. If user A reads the document and makes some changes (through a web form, for instance), the change should be accepted if and only if no other user B has updated the document since when user A read the document.

    MongoDB doesn't support transactions, and even if it did, they wouldn't help in this case. An assumption underlying the question is that the time between any given user's reads and writes is long -- otherwise explicit/pessimistic locking would be the simplest solution -- in which case holding a transaction open on a traditional database server would be prohibitively costly (in terms of resource usage and performance).

    The solution is to leverage MongoDB's atomic update semantics with an optimistic concurrency solution. This comprises four basic steps: 1. read a document; 2. modify the document (i.e. present it to the user in a web form); 3. validate that the document hasn't changed; 4. commit or abandon the user's update. For anyone who's used a source code version control system before, these steps should be familiar (i.e. pull, work locally, commit, and push for git users).


  5. Web A/B Testing with Dabble

    Thanks to a series of recent posts on the SvN blog, I've been thinking more about my little Python A/B testing framework, Dabble.

    I built Dabble to A/B test (sometimes also called "split test") features on 10gen.com. Following the advice of a blog post I've since lost track of, Dabble configures A/B test parameters entirely in code, follows procedure for independent testing, and generally works without much of a hassle.


  6. On Job "Requirements"

    If you look at pretty much any job posting, you'll see some variation on this (in this case, for a hypothetical web programming position):

    Requirements:

    • BSc in Computer Science or equivalent
    • 2-5 years web development experience
    • Expert in Java, SQL, HTML, CSS, Javascript
    • Strong communicator
    • Able to multi-task

    The numbers, degrees, and technologies will vary from one job to another, but the basic form is almost always there.

    But what's the point of this section? I've never gotten a job for which I met all the "requirements," and I've never cared if the candidate I'm hiring doesn't meet them either. Is it just out of habit?


  7. Never Use Source Control GUIs!

    Just received this IM from my friend, Nick:

    11:48:58 AM Nick: kjsahfdlkjashdflkajshdflkjh
    11:49:02 AM Nick: it was the git gui itself
    11:49:09 AM Nick: it periodically refreshes
    11:49:14 AM Nick: with a forked git process
    

    Version control GUIs are uniformly evil. They entice you with a multitude of colors, and 1-pixel lines; their siren song is one-click commits and graphical 3-way merges.

    But, like Odysseus, if we have any hope of prevailing, we must lash ourselves to the mast and steer past this temptation.



  8. The new Profiler in MongoDB 2.0

    One of my favorite features in MongoDB 2.0 is the finer-grained output of the database profiler. In earlier versions, the bulk of the profile information was contained within a (structured, parseable) string, but as of 2.0 the fields have been broken out and made queryable.


  9. Hello, Plog

    I've wanted to start writing a blog for the past few months. By which I mean, writing blog posts. But why focus on writing great content when you can write great software instead?

    Allow me to introduce Plog, the software running late.am. Read on to see how Flask, Mongoengine, and MongoDB can work together to create something beautiful.