Monday, April 25, 2011

We won first place at Startup Camp LA!

On a whim we (me and audreyr) decided to try out Startup Camp LA organized by Semantic Seed. This is one of those Silicon Vally style competitions to launch a minimally viable product along with a business plan and marketing pitch in the course of a weekend. We thought it would be a good excuse to hack on a project we've been cooking up in our heads over a year. So we booked our tickets via and showed up at the new Nextspace Los Angeles location.

The organizers did a really good great job providing space, food, and lots of useful advice. I look forward to the next event that they run in the area.

Startup Camp LA Pitches

The first pitch was on Confidox, an exclusive recruiting site for lawyers with a focus on clean design, security, and good use of email/sms. The presenter, a professional attorney with great oratory skills, had mockups and a business plan ready to go.

Audrey gave our pitch, which is a site for recruiting developers that is created and maintained by developers. Developers are treated with dignity and respect, and not as replaceable components. We've talked to people on-and-off about this for over a year, and thought this would be a good opportunity to get things moving.

After Confidox and our proposal came a lot of other dreamers.

Then began the bargaining and voting for team placements. Voting was done with paper money. We received the second-highest amount of paper money and Confidox got third place.

Switching projects

As said, our recruiting idea got second place in votes. We got assigned two other people, one of them being the Confidox guy. This meant we got the most paper money total!

Rather than work on our project and have to educate the new guys on the developer ecosystem, we decided to switch to Confidox for the weekend. The scope was reasonable, the plan sound, and the mockups meant we had a specification to code against.


"Ideas are cheap, implementation is hard."

From the start Audrey and I decided to not allow any scope creep. No social media widgets, banner advertisements, forums, branding, coupons, or anything that distracted from the business model. That would allow for a clean design and elegant implementation. We went to work, taking breaks to help hammer out the marketing pitch and socialize with the other teams. Our goal was a stable, functional prototype - something we achieved thanks to our mostly open source technology stack.

Technology Stack

Unless specified otherwise, everything is open source:
The Final Pitches

The Confidox pitch:
  • Our group presented as a team. Marketing talked marketing, techs talked tech.
  • A live prototype site with fully functioning authentication, registration, profiles, listings, search, and email/SMS notifications. 
The other teams presented well, but I was shocked by a few things:
  • Most pitches lacked even a buggy prototype.
  • Presenting teams bickering during their presentations.
  • Unbelievably, one slide presentation had music that the presenter had to shout over.
Why Confidox won Startup Camp LA

Audrey took charge of the group and kept us focused on the elegant, straightforward idea. She didn't just code, she also treated the business side as being equally important as the technical delivery (giving them constant feedback and coaching). Which meant we could both roll out a working prototype and nail the marketing pitch.

When it came down to it, we were a team. Everyone had purpose and everyone contributed. We communicated our idea and demonstrated that our prototype works.

Going forward

Confidox is not off the ground yet, we'll see where it goes. We certainly have a capable team.

This event was a success for us and our company Cartwheel. Also, with ancillary projects with large contributor basis such as Django PackagesPackaginator, and Django Uni-Form, me and Audrey have proven ourselves capable of just launching dynamic projects quickly that work and are used by real people for real work. We'll see what we can do with that proof.

Finally, if you want to learn our techniques for constructing Confidox and other efforts, come to our Los Angeles area classes.

Friday, April 22, 2011

I teach Python and Django

This is one of those blog posts where a developer announces that he/she is teaching for a whole week. The difference is that in this post I'm going to explain why I want to teach and why you should take my classes or send your staff.

I'm an experienced instructor.
I've taught a variety of things for over 20 years, including in alphabetical order: Best practices, Django, English, JQuery, martial arts, Pinax, Python, Selenium, soccer, and unit testing. I speak clearly, get across technical points well, and love the material. I also know how to provide an early foundation of knowledge and then expand upon it for maximum benefit.

I don't just dump knowledge into the heads of my students; I take the time to teach them common standards and best practices, so their code is extendable and maintainable.

I'm not alone. 
Audrey Roy, co-founder of Cartwheel, leader of PyLadies and Django Packages, who has tutored and lab assisted at MIT will be teaching with me, meaning the teacher-to-student ratio is kept at 5:1 for our first offering. 

I want you to surpass me.
After teaching various things for many years I've found it a point of honor and immense pride when a student shines better than myself. I'm not one of those teachers who holds something back so I can always have the edge. In fact, my ultimate goal is to make you better than me.

I rest on the shoulders of giants.
I'm sure the people I'm mentioning in this section are going to roll their eyes, but lets face it - they rock!

In any case, I've had the fortune of helping Steve Holden write Python 3 classes for the O'Reilly School of Technology. I've been exposed to the Django code bases of NASARevSys and Eldarion. While I can't share that work directly, I can take the abstract of their methods and turn it into lessons.

For the employers: Classes are a good way to find resources
Having trouble finding staff? Imagine instead you hire a talented developer from another language and send them to my classes. In a week's time for a fraction of the price they'll have been kickstarted into not just knowing how to do their job, but how to expand their knowledge so if they don't know something, they know who to ask.

Refresher courses are free for six months
Space-permitting, you can retake a class at no charge.

The course schedule
Our first classes are scheduled for May 16th to May 20th. We are offering:
One more thing, if you take both classes we'll give you a 10% discount after registration.

Sunday, April 17, 2011

How NOT to interview Pythonistas

There are a lot of firms who complain that all the experienced Python people are taken, and wonder if they should choose a different toolset. On the flip side of the coin, I've heard a growing  number of developers/engineers complain about horrible hiring practices they encounter. So which is it?

I think it is a mix of both. Compared to the current need, there is a shortage of experienced Pythonistas. On the other hand, I've seen really stupid mistakes by otherwise professional firms, stupid mistakes which are NOT caused by recruiters and don't just cost the firm a possible hire, but hurts their reputation. This is because people will complain to each other on IRC and in users groups about how your firm hires people and all of a sudden your firm has a bad reputation.

So that this stops happening, here are three really bad moves I've seen by companies:

1. If cold calling, don't EVER ask technical questions.

Recently I keep hearing about this one and it even happened to me about 8 years ago.

A pythonista is doing something, maybe coding, driving, sleeping, or eating when they get a call. The pythonista answers and are asked if they are interested in working for Company X. The pythonista gives a positive answer. Then the interviewer asks if they could answer some technical questions.

At this point the interviewer has failed. In fact, they have failed hard.

Odds are that being on the spot, the Pythonista will agree. And then, without a day to prep themselves for doing an interview, they are answering questions. There are no metrics for this one but I bet 90% of developers will fail questions they normally could answer in a heartbeat. Afterwards, the developer/engineer will kick themselves because they knew the answer, but because they were flustered they got things wrong.

And then, to really seal the deal, because the developer/engineer has failed the interview, the interviewer will inform them that they are not the sort of material that Company X wants. So not only did the pythonista mess up easy questions, now the lack of respect for their skills and person has been made abundantly clear.

The interviewer is completely at fault here.

The real problem for the interviewer is that if that potential hire that they just rejected talks about it, experienced developers/engineers will hear about it and it will be a unspoken black mark against their firm.

Lesson learned: What the interviewer should have done is email first, or if they called, ask if they could schedule a technical interview, either in person or on the phone. There is no exception to this system.

2. Make it clear that an interview is an interview.

Imagine there is a company you respect and admire. You meet the founders or the senior technical lead at a social event and they invite you to visit their firm. You arrive at the office expecting a tour and instead get handed to the technical staff for a challenging interview. Unprepared you don't do so well, and unsurprisingly the company doesn't hire you.

This is so full of wrong on the part of the hiring firm I don't know where to begin.

Lesson learned: If you are bringing someone into the office for an interview, make it abundantly clear you are interviewing the prospect. Say it in person and confirm it in email.

3. Make crazy requests in the technical interview

A few years ago a very capable friend was asked to provide a list of Fibonacci numbers, but he wasn't allowed to use a function and need to use a database. When he solved that one his effort was then criticized for 15 minutes by four developers. Then he was then asked to do it again, only this time in ECMA script.

Well before node.js existed, someone else I know was asked to use browser JavaScript to write a multithreaded HTTP server. When my friend asked "why would you ever do such a thing?", he was told not to ask that question but to solve the issued problem.

In all these cases the interviewee left annoyed, if not angry. Years have gone by and they still complain about these firms.

Lesson learned: For the hard questions, make them meaningful

Saturday, April 9, 2011

Are you looking for Python and Django Work?

I've done some consulting work for a company in New York City that is looking for full time developers of all levels. They've got a solid business model, experienced and excellent leadership, and an existing team of talented developers who do things the right way. The founders and developers have been behind a bunch of things you know and love. The company is stable, well-financed, and offers full benefits.

In short: they're building the dream team. They don't use dumb words like rockstar and ninja: they're looking for quietly competent developers with a taste for travel.

Additional experience with CSS, JavaScript/JQuery, GIS, Git, Linux, and experience with contributing to open source projects are definite pluses.

Before you apply you need to pass this little test of mine. If you fail any portion of of this test then we won't consider hiring you.
  • Can you get to the office or are you willing to move closer? When you begin, you need to be able to get to New York City, New York every day of the week. Over time you can work out telecommuting options. 
  • Are you a solitary developer? I'll throw away any responses from recruiters and consulting firms.
  • Bonus Question: Not a requirement but do you have any open source contributions from any languages to share?
  • Can you send your resume to my email address 'hidden' in the code below? To do that, you'll need to know enough about Python to run this code:
    numbers = [83, 101, 110, 100, 32, 114, 101, 115, 117, 109, 101, 32, 116, 111, 32, 112, 121, 100, 97, 110, 110, 121, 64, 112, 121, 100, 97, 110, 110, 121, 46, 99, 111, 109, 32, 119, 105, 116, 104, 32, 115, 117, 98, 106, 101, 99, 116, 32, 111, 102, 32, 39, 108, 111, 102, 116, 121, 39]

    ''.join([chr(x) for x in numbers])

    Wednesday, April 6, 2011

    Python Packages sprint on Sunday 4/10/2011

    Want to help Python? Want to encourage PyPI to focus on being the best package index system possible and not a catalog/ratings/documentation engine? Then sprint with us on Packaginator this weekend because...

    We need your help!

    In my last blog post I mentioned Packaginator which will power the forthcoming Python Packages site. The purpose of this site is to do for Python what Django Packages does for Django. We aren't quite ready for launch, and the purpose of this post is to list what tasks remains. There is an enormous amount of outstanding work, and we want to launch as soon as possible so...

    Before I begin, Python Packages will have some dramatic differences from Django Packages:

    • The 'Add Package' controls won't exist. The only way to get a package into the site is to put your package onto PyPI.
    • At launch only approved moderators will be able to create new grids and grid features.
    • Only approved moderators and package owners will be able to edit the target repo URLs and add/edit/remove packages on grids.
    • Users will still be able to click the "I use this" button. 

    Please join us!

    We invite you to sprint with us on Sunday, April 10, 2011. We are sprinting on Python Packages / Packaginator from the Los Angles OS Hackathon this weekend but also invite remote sprinters to join us from across the globe.

    How to participate

    How to contribute to Packaginator is really well documented and I beg you to read that before commencing any sort of work. We don't use IRC to communicate, instead relying on our convore channel at

    Because we can, have, and will reject pull requests, I need to reiterate a few things:

    Important: Because we are "this close to launch", for Sunday we aren't the least bit interested in dramatic architecture revisions, model changes, obfuscating our settings, new design, different layouts, or adding Haystack. We'll consider those afterwards.


    Priority tickets are the real choke points that we want to overcome. We could use help on all of them:

    When you start a ticket, please let us know in so we can mark it as assigned in the Github issue tracking system or warn you if it is already being worked.


    We hope to launch this sunday or in the immediate days afterwards, and for that Jacob Kaplan-Moss, Jacob Burch, and Noah Kantrowitz  have graciously volunteered their time to do the engineering work.

    Tuesday, April 5, 2011

    PyCon 2011 Sprint Report

    I love sprints. I've yet to participate in a sprint where I didn't learn something that made a difference in my programming career. Off the top of my head some of the things I've learned include distributed version control, picking the right Python tool, JQuery, SQLAlchemy, Bazaar, Git, Mercurial, the true importance of unittests, and Python's built-in zip function. And the PyCon 2011 sprints were no different.

    PyCon 2011 was different in that this time I was going to co-lead a project, specifically Django Packages and the hopeful launch of Python Packages.

    Note: The goal of Python Packages is not to replace PyPI, but rather serve as a resource to find, evaluate, and compare packages used in the every day life of a Python. In my opinion, PyPI should be dedicated to listing and serving packages - anything else (comments, ratings, documentation, etc) just adds complexity to the project and diffuses the focus of their team.

    It all started with us being the second-to-last in line at the PyCon sprint announcements. At the microphone I forgot to mention a few things so I was worried that our attendance would suck. I tried to take it in good humor, but doubt worried at my gut. My co-lead, Audrey Roy, was confident that if no one showed, then we would have fun with just the two of us hacking away.

    To our delight and surprise, turnout was good with about ten (10) people showing up. And thanks to lessons learned at DjangoCon 2010 and our tricks to getting more sprinters and helping sprinters deliver code, the number of participants kept growing. In the end we had twenty-four (24) new contributors to the project, which was simply amazing.

    Test coverage had been mediocre on Django Packages, but after a show stopping bug got into production (someone changed a commonly used function to a property), we did a huge amount of work to not only increase test coverage but also refactor tests to be simpler and actually test rather than just increase coverage numbers. The improved quality and quantity of test coverage gave contributors the confidence to refactor and simplify some of the 'brilliant code' that I had written during the first month of the project.

    We also got a bit draconian about accepting pull requests but documented how to get pull requests accepted. That might sound mean but if stopping one person's bug allowed ten (10) other people to maintain productivity then everyone is happier. Also, it allowed us to coach some of the new Python developers coming from other languages on their work. Which was awesome because we saw people's work evolve in a day from rank beginner material to competent Pythonista submissions. To think we had some part in helping people improve is one of the best things we got out of the sprint.

    And the results?

    The biggest thing, which we got into place on the second evening of the sprint, is that Django Packages is now an instance of Packaginator. Packaginator is a framework for launching package comparison sites for Python based tools. After a bit more work to happen this coming Sunday (4/10/2011), we'll be able to trivially deploy Python Packages, Pyramid Packages, Plone Packages, and Flask Packages - all of them able to support patches from Packaginator without causing the maintainers of those sites to hate our guts. We should also will have the hooks to support things like Vim Packages, Ubuntu Packages, Fedora Packages and more quite shortly.

    Packaginator handles repos much better and now supports Bitbucket, Github, and Launchpad out of the box. SourceForge may happen very soon. Google Project Hosting, when Google implements Project Hosting API (cause we refuse to screen scrape pages for MetaData) will be handled shortly thereafter. Thanks to the work of the 'repo men' adding a new repo is now much easier, and we hope people submit new ones to handle things like Trac and other repo systems.

    Our documentation went from passable to incredible, and our installation story is awesome. You want people to participate in your project? Then learn you some RestructuredText and Sphinx and host your documentation on Read the Docs. Read the Docs is awesome and I need to blog about why all Python docs should move there.

    There was a huge amount of template cleanup - and the grid X-Y access can be rotated. We haven't turned on that feature yet, but you'll see it shortly.


    The sprints were awesome. I learned a lot about running projects and managed to get into some new coding tricks (zip() comes to mind) into my brain. That this project is helping the open source world made it even better. And the best thing of all is I got to make over twenty new friends - all of whom worked with us towards a single common goal.

    PyCon 2011 Contributors

    • Aaron Kavlie
    • Adam Saegebarth
    • Alex Robbins
    • Andrii Kurinny
    • Audrey Roy
    • Brian Ball
    • Bryan Weingarten
    • Chris Adams
    • Daniel Greenfeld
    • Eric Spunagle
    • Evgeny Fadeev
    • Flaviu Simihaian
    • Gisle Aas (Repo Man)
    • Jacob Burch
    • James Pacileo
    • Jeff Schenck
    • Jim Allman
    • John M. Camara
    • Jonas Obrist
    • jrothenbuhler
    • Nate Aune
    • Nolan Brubaker
    • Preston Holmes
    • Stuart Powers
    • Szilveszter Farkas (Repo Man)
    • Tom Brander
    • Vasja Volin

    Friday, April 1, 2011

    Announcing Garbaginator!

    While working on Packaginator at the PyCon 2011 sprints we discovered some serious issues in the way that Django handles garbage collection. After a huge amount of work, we managed to isolate and fix the problem. This 'fix', as it were, was only possible by doing a very sophisticated 'hack' of critical internal components of the Django Web Application framework. We also discovered that similar issues occurred in other existing Python application frameworks such as Pyramid, Flask,, Web2Py, Grok, Twisted, Tornado, Google App Engine, and Rails.

    Since then the Packaginator community has been fiercely debating what we should do with our newly created set of hacks. After a lot of arguments going both ways we've decided to come up with our own application framework and release it to the world under the GPL license.

    This brand new application framework ignores the lessons learned from all the other Python frameworks and embraces the cutting edge concept of Not-Invented-Here. It focuses less on features and enhancements over existing systems and much, much more on the critical concept of formal Garbage handling.

    Some of the critical modules include:
    • RubberGloves (for handling dirty objects)
    • Django-Garbaginator
    • Flask-Recycling
    • Pyramid-Garbaginator
    • Garbaginator Bridgerator ('cause people always get Web2Py and confused with each other so we bridged them together)
    • BlueBream
    Check out the home page at:
    Fork Garbaginator on GitHub:

    Note: This was an April Fool's Day Joke