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])

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 http://convore.com/packaginator.

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

• Run the test suite before you submit your pull request
• Keep your pull requests small and focused
• Be familiar with PEP-8 and keep your code simple

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.

Tickets

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

• Low hanging fruit tasks
• Challenging tasks
• Priority tasks

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

Launch

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.

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.

Conclusion

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

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, Web.py, 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
• Web.2.py Garbaginator Bridgerator ('cause people always get Web2Py and web.py confused with each other so we bridged them together)
• BlueBream

Check out the home page at: http://garbaginator.cartwheelweb.com

Fork Garbaginator on GitHub: https://github.com/cartwheelweb/garbaginator

Note: This was an April Fool's Day Joke

PyCon 2011 Tutorial Report

As mentioned many times in previous entries of this blog, with Brian Rosner I taught the Pinax Solutions tutorial. We had some last minute people sign up so turnout meant nearly every seat in the room was taken. The second-half being a workshop seemed to go smashingly well. That said, one person had serious problems with getting things running and they left the tutorial without having anything running. I'm not sure how to deal with that besides having a spare laptop setup for that invariable bad laptop that always seems to show up.

The next day I took Noah Kantrowitz' (Re-)Introduction to C for Python developers. It was my first time every trying to code in C, and it was done by solving problems on this day. He dumped us right in the deep end, which was awesome for the first exercise but then I got a bit lost. I think he should have shown the answer code after everyone got a chance to try to solve things. He finished up the second half of things with some incredibly good content that made me want to use C a lot. I hope he gives this tutorial again next year since I think with a little fine tuning it will be a showcase class.

I kept my eye on a few tutorials, and was pleased to see that all the introductory Python classes were full. That is a good sign because more beginners means a stronger community.

I'll get you next time, Wesley Chun!

At the start of this month I laid out the Great Pycon Ribbon Game. PyCon ribbons are given to people based on their contribution to the conference. Give a tutorial, present a speech, volunteer to do grunt work, sponsor the event, be Guido van Rossum, and more each gives you a special colored ribbon you get to attach to your conference badge.

Last year I had the most of anyone except for Wesley Chun. He's one of my favorite instructors, is an author and Google App Engine advocate, and a good friend. To my five ribbons he had seven. He clearly beat me and deserved the win.

This year when I issued my ribbon challenge he immediately said that he was giving up. He had too much work and family things going on. I gave him my regrets and planned to totally crush everyone's ribbon count at the conference. I was sure I could duplicate my five ribbon effort from last year and no one else would be able to match me!

So imagine my surprise when Wesley Chun had seven, SEVEN ribbons on his badge. He beat me this year. Worse, I managed only four this year. So he didn't just beat me at the game, he opened the lead.

I'm a good loser. I don't begrudge him. Well, maybe not too much.

Next year I'll issue the challenge again. I hope you join us, since win or lose the wonderful thing about this competition is that PyCon and the community benefits.

The Great PyCon Ribbon Game!

Here is my challenge for attendees of PyCon 2011 - try to win as many volunteer badge ribbons as possible. Whoever gets the most ribbons at PyCon 2011 can claim the title "King of PyCon Badge Ribbons" and I'll write a special blog post for you, your employer/company, and your favorite non-obscene thing.

Rules:

• You have to earn the badge ribbons. You have to give tutorials, make presentations, volunteer left and right, and be a great sport. Stealing ribbons is out. So is trading for them.
• Only real badge ribbons are valid. You can't write your own and tape them onto your badge.
• You must proudly affix the ribbons to your badge.
• Cheaters will be lambasted verbally. You deserve what you get.

In 2010 I managed to earn five (5) PyCon ribbons and only Wesley Chun beat me. Think you can beat our scores from last year? Think you can beat me this year?