Monthly Archives: May 2010

Building A Sane Development Environment

Posted on by

For all these tasks, make them easy to do or you won’t really do it.

Start everything in a clean environment

Don’t hack in an environment filled up with artifacts from the previous release. Clear them all out. Make sure that your environment looks like what you released for 1.0 before you start 1.1.

Encourage lots of sandboxes

Be able to explore mutually exclusive solutions to the same problem and not worry about conflicts.

Make your environment realistic

Design your sandbox so that it resembles your production environment.

Just to be clear, I don’t mean that development must be identical to production. I mean that if you anticipate bottlenecks in production, figure out how to model them.

Deploy during development

Deployment should be boring. But it usually isn’t, because developers overlook trivial dependencies they created along the way.

You’ll quickly discover what you forgot to add to your deploy scripts last time if you start every session like this:

  1. Reset your sandbox.
  2. Check out your code.
  3. Run the deployment script.
  4. Now start working.

By the time you are ready to release, you will have simulated the deployment process many many times.

I just submitted my talk for PyOhio 2010

Posted on by

I’d be happy to get any crititicism ahead of the presentation. I’m hosting the code examples and the talk material here.

Building your own kind of dictionary

Python level: novice

Description

My talk is based on a project that seemed very simple at first. I wanted an object like the regular python dictionary, but with a few small tweaks:

  • values for some keys should be restricted to elements of a set
  • values for some keys should be restricted to instances of a type

For example, pretend I want a dictionary called favorites, and I want the value for the “color” key to be any instance of my Color class. Meanwhile, for the “movie” key, I want to make sure that the value belongs to my set of movies.

In the talk, I’ll walk through how I used tests to validate my different implementations until I came up with a winner.

Unlike my talk last year on metaclass tomfoolery, and the year before that on fun with decorators (and decorator factories) I’m hoping to make this talk straightforward and friendly to beginning programmers.

You’ll see:

  • how I use tests to solve a real-world problem
  • gotchas with the super keyword
  • a little about how python works under the hood.

Extended description

I’m not done with the slides, but all my code examples are finished. You can read it all online at my github repository here.

Outline

  1. What kind of object I want
    1. Tests define the expected behavior
    2. How to run those tests
  2. First implementation (subclass dict)
    1. How the implementation is defined
    2. Examine test results
    3. Examine the C code behind the dict class to see why my subclassed __setitem__ method won’t get called from the parent class
  3. Composition-based implementation
    1. Explain composition vs inheritance
    2. Examine test results
    3. Point out irritating need to manually redefine every related dictionary method on the container class
    4. Show how to use __getattr__ to avoid all that boring wrapper code
    5. Show how __getattr__ doesn’t play nice with inspection tools
  4. UserDict.UserDict
    1. Explain implementation
    2. Examine test results
    3. Add a new test that uses this class as a parent for a subclass
    4. Explain how UserDict.UserDict is not a new-style class, so the super keyword behaves differently
  5. UserDict.DictMixin
    1. Explain implementation
    2. Examine test results
  6. PEP 3119 and why it is nice
    1. duck-typing, why it is awesome, why it isn’t perfect
    2. abstract base classes
    3. As of python 2.6, don’t use UserDict.DictMixin; use collections.MutableMapping

Moving on

Posted on by

Last week marked the end of my employment with OnShift Inc. What started off as possibly the worst idea for a business conceivable (I’ll justify this claim later) is now an enterprise.

It has been a really good experience. I got to build something all myself. I had some really patient customers that politely filed bug report after bug report, and met with me over and over again to discuss their frustrations.

And then the business crossed one of those inflection points.

We started getting sales. Customers became happy to be references. More than once, people offered to pay for the product out of their own salary after they sat through a demo.

Some fantastic developers and designers joined the team.

In March I sat in the back of the room during a training. At the end, the trainer pointed me out. Usually I take that moment to do my little talk about how this is a new product, and these users are going to run into bugs or things that just seem goofy. I tell them I really want to hear about them, so that I can fix them as soon as possible.

But before I started my speech, everyone started clapping.

So that’s why I have to / get to / want to / need to leave. For about four years now, I’ve been banging rocks together trying to start a fire. And now I got one. So now I’m going to take a break, and perhaps more importantly to OnShift, get out of the way.

I’ll be happy if the business makes it big. I’ve been fully vested in my shares for a while now and I keep those after I leave. But this was never about getting rich. This was about proving something. I aimed to prove that I could design a product and then start a business around it.

I’ve been focused on getting that fire lit for the last four years. Now it is lit.

As for that worst possible biz plan, I’m not going to spell it out. Instead I’ll cram all the bullet points from my partner’s slides into one run-on word salad:

Orthodox Judaism SMS location-based time of Sunset on Friday mobile microblogging opt-in advertising