pydanny

How to justify attending PyCon sprints

2012-01-25T10:16:00.000-08:00

Sad that the PyCon sprints fall on business days? Wishing you could stay but the boss/client won't let you and demands you back so 'you can work'? This is how you make it so that the sprints are something your management is demanding you attend every sprint ever.

Make it foremost in your mind that the wonderful thing about the PyCon sprints is that the odds are that anyone who knows anything about whatever you are doing in Python will be there.
Write up a list of the things that you are finding challenging, hard, or impossible to do with Python.
Now go to the boss and say something like:
"Because the experts and leaders of the open source tools we are using are going to be there, I want to attend PyCon sprints. All my time at the sprints will be focused on sitting around them and working on our tools. I'll focus on things that directly impact our agency / company / organization, specifically things I wrote down on this list."
If the boss says,
"Why not just use IRC or email?"
Then you say something like,
"Well, IRC/email is not the same as sitting next to these people. I'll be so much more productive there!"

Rinse and repeat.

Then, when you attend the PyCon sprints, follow through on what you said you were going to do. Sure, it might be more fun to work on project 'spam' even though your company uses project 'lumberjack', but if you prove how much you got done during the sprints, next year the boss will be much more encouraging. Even if a good boss says to go do what you want, at least spend some time sprinting on work related technology.

Also, once you get approval to go, consider sending your boss to this old rant of mine.

Don't forget to register for PyCon! Early bird rates end today (January 25th, 2012) which means today is the last day to get involved in the extremely unofficial PyCon Early Birds program!

Join the PyCon Early Birds program!

2012-01-23T08:16:00.000-08:00

First off, I want to say that me and my fiancee will be attending PyCon US this year! Hooray! Can't wait to see old friends and make new ones. I'll be chairing one of the Panels at the PyWeb Summit on March 8th. We're absolutely delighted to see all the great talks, hang out in the hallway, and just be in the middle of Python for well over a week.

Now on to the extremely unofficial PyCon Early Birds program!

PyCon early registration ends on January 25th. If you register at the early bird rate that gets you the benefit of joining the elite PyCon Early Birds group. Being a member of the PyCon Early Birds gets you all sorts of incredible rewards and benefits.

Most importantly, you get some serious bragging rights.
A custom ribbon that says 'Early Bird' that you get to attach to your conference badge.
A discounted rate from the regular ticket rate as according to the registration page.
The confidence of knowing you have a ticket before they sell out.
A tasty and rather edible store-bought cookie provided by myself and Audrey Roy.
If the PyCon Early Birds program gets enough members, I'm going to challenge PyCon chair Jesse Noller to stump me with Yoga poses! There's no way he'll even consider accepting a challenge like this unless the PyCon Early Birds membership roster is big enough. So join and help me find out if his Bikram will beat my Capoeira!
Other incredible things that are in the works!

Of course, PyCon has tons of other reasons to sign up besides the PyCon Early Birds program. Amazing tutorials, talks, and sprints, plus great hallway tracks, a vendor room filled with great schwag, poster sessions, and startup row. Sponsorship levels are unbelievably high, and since the event is non-profit that means the money just goes right back into the community - starting with PyCon itself. This year is going to be AWESOME!!!

So what are you waiting for? Sign up for the Pycon Early Birds before it's too late!

Tips for speaking

2012-01-21T08:35:00.000-08:00

Last year I wrote a blog post called My tips for speaking. In the face of SCALE 10X and other events coming up, this is my refactoring of that talk.

My experience in giving talks? I've been presenting on the job since 1999. I've been presenting at conferences since autumn of 2008. This past year (2011) I gave a lot of talks, helped others with their talks, and did a number of cooperative talks where I shared the stage with another person. I've learned a lot, from my own mistakes and those of others. Since I like to share, here we go.

You aren't Steve Jobs

In terms of presenting, Steve Jobs was no mere mortal. He got away with wearing black in front of a black background. His slides were frequently dark. And he held up tiny objects in front of literally billions of people. He did all of this and got away with it.

You. Won't.

Steve Jobs was billionaire leading a multi-billion dollar company. His presentations were highly choreographed affairs where every detail from lighting to audio to who got to attend was tightly controlled.

For example, Steve could wear black because of amazingly proficient stage lighting techniques. Carefully watch a high definition video of him showing off the latest product while in a black sweater and you'll see that he's literally standing in a column of light. Odds are most conferences don't have spotlights or fancy lighting, and even if they do - the stage crew are not being promised a bonus for doing it right and financial ruin if they fail.

What this means is be very, very careful about using the attributes of Steve's talks for inspiration or arguments on how you are going to do a talk.

What to wear

Bring several presentation shirts to the conference so you can be sure that what you are wearing shows up in front of the background. Be a little classy and wear a polo shirt instead of that t-shirt. If the background is the same as your shirt, go and change. If you don't have a shirt that works, go buy one or wear your jacket.

The reason being is the same as why Newscasters don't wear some colors on video. They don't want to look like floating heads and hands. It happens to them, it happens at technical conferences, and it will happen to you.

Black text on white background

I said it last year and I'll say it again: High contrast slides please. If a designer, manager, friend, or spouse tries to stick colored backgrounds or text into your slides, politely remind them that what shows up nicely on the monitor or laptop will absolutely fail to be appreciated by the attendees of the talk. Social media and IRC will be filled with comments about the unreadable colors of your slides.

Remember, unlike Steve Jobs, you have no control over the AV team or whatever the conference venue provides when it comes to projectors and screens. So play it as safe as possible.

I really prefer the black text on white background. The people in the vision community (arts, theatre, animantion, and eye doctors) all agree with me.

This past year I've had technical people (all with jobs outside the vision community) quote some interesting material about the validity of white text on black background, but I personally find it hard to read those slides if I'm in the back. Also, if the room is brightly lit, the letters are barely visible.

The happiest alternative I've seen was at a Mongo event, and was a certain shade of dark blue with bright yellow letters. However, I think like the black background, it would be suspect in the wrong light.

One last note: Don't use color gradients in your slides. Please.

Cheat at the command line!

I'm giving a talk today at Southern California Linux Exposition 10x called Intro to Python. It's inspired by folks like Raymond Hettinger and David Beazley. And the big thing I'll be doing is avoiding the command-line like the plague.

This is because the command-line is treacherous in front of an audience. Conference networks are notoriously prone to going down at the wrong moment. Same goes for laptops, especially when connecting to projector hardware it's never touched before.

Also, you know what it is like typing with someone looking over your shoulder? Imagine that times hundreds, or thousands when your video is being uploaded so people around the world can view it.

So either use something like PLayer Piano to record a command-line session in a docstring, or do what I do and use slide transitions to mock typing.

Be rested, fed, and sober for your talk.

In 2011 I watched a guy fumble through a talk with beer in hand, a personal hero of mine blearily try to get through his talk after a late night of drinking, and a couple people try to present after all-nighters.

Respect your audience and take care of yourself before the talk. Get some sleep, eat well, and drink moderately. This will really help you get invited to more events.

Practice, practice, practice

In the past I've said I don't practice much. If at all. Ahem...

It has been pointed out to me that I practice. A lot. Maybe not in front of a mirror, but I'm constantly going through my slides and coming up with things to say. I'll go through all my slides one-by-one and mouth what I'll be saying, and work out the timing of things. Which means that while I haven't been projecting my voice, I have been practicing.

In 2011 I did the curious thing of actually trying to practice on a couple presentations. And I have to say that I've seen a huge amount of improvement. I certainly felt more confident and I feel like the talk goes better! For example, A talk I gave at PyCon AU 2011 that had some issues after a lot of practice went smashingly better at DjangoCon 2011.

Push questions and comments to the end

Your talk should have a flow, a pace as it were. And lots of interruptions will cause you to lose your chain of thought, or cause the audience to lose focus. If someone asks a question during your talk, ask them to wait until the end.

If they keep asking questions or giving comments, ask them nicely to talk to you after your presentation. People are decent and will respond nicely to your request.

Sign up for Pycon US!

Early bird registration closes on January 25th. Sign up for it beforehand and you'll have enough money for a really good dinner with drinks. What are you waiting for? Go do it!

My SOPA boycott

2012-01-18T11:10:00.000-08:00

I'm against SOPA and PIPA.

I believe that those bills will kill not just free speech, but also business within the USA. Innovation will wither. I'm also of the belief that those companies trying to get SOPA into place don't realize that no idea is new and if SOPA passes they'll be hammered with an increasing amount of takedowns and suits against them for anything they do. Litigation based on SOPA won't be as easily handled as the current status quo.

I've signed the petitions, I've posted on Twitter, Facebook, and Google. That isn't enough. I have to be willing to make a sacrifice. And in this case I'm going to make the sacrifice my vote.

My vote sacrifice is a boycott. It's directed at any politician, local or otherwise:

My Boycott:

If you as a politician vote for SOPA/PIPA then you lose my vote. Regardless of whatever other opinions you have or party you belong to, you've lost me as a supporter.
If SOPA/PIPA passes you can get my vote back by voting for what bill that destroys SOPA/PIPA is nominated.
If SOPA/PIPA fails you can get my vote back by voting against whatever bills are resurrected to replace SOPA/PIPA.
I will ignore party boundaries. I will vote against my normal grain simply to get you removed from office.

Why?

Like campaign finance reform, controls of freedom of speech often have unpredictable repercussions.

The terrible thing about these bills is that their supporters are bi-partisan. While it's wonderful to see political opponents working together, in this case, it's for a terrible cause.

So I'm going to cross political boundaries too. I'm going to say that as a registered Democrat I'm going to vote Republican if a Democrat candidate at any level votes for SOPA/PIP.

About Me

I don't use pirated software. I don't read, watch, or listen to pirated content. I purchase everything legally or use open source equivalents. I make a pretty decent salary and am pretty much in the direct center of what is called the 'middle-class'.

I'm also pro-business and a rather patriotic citizen of the United States. I believe in our nation and what it represents, and I know these bills are going to be a dagger in the heart of what our founding fathers gave us.

Finally, as I said, I'm a Democrat willing to vote Republican, Green, Libertarian, or whatever to make my point. That's my sacrifice. My vote and role in this nation that took my family in over 100 years ago is now in the hands of politicians.

What's yours?

Resolutions for 2012

2011-12-29T12:09:00.000-08:00

Go to a Python related conference in North America, South America, Europe, Asia, Africa, Australia, and New Zealand.
Attend at least one JavaScript related conference or event.
Upload all my outstanding pictures to Flickr!
Make Consumer Notebook profitable.
Find more ways to make Audrey Roy happy.
Pull off an Aú sem Mão during a Capoeira Roda.
Attend my first Capoeira Batizado.
See a place in the USA I've never been.
Work out at least three times a week.
Drop to a 32 waist
Visit friends and family back east. Been over a year since I've seen my sister!
Blog once a week. That is at least 52 blog entries!
Visit a Theme park.
Learn how to surf or snowboard.
Implement something in node.js, backbone.js, and handlebars.js
Take a high level Python class from the likes of Raymond Hettiger or David Beazly.
Teach some Python or Django.
Have a beer with Thomas, Andy, Andy, Tony, Garrick, Bernd, and the rest of Ye Aulde Gange.
See my old DC area friends such as Eric, Chris, Steve, Beth, Sarah, Daye, Renee, Kenneth, Leslie, Whitney, Dave, and many others.
Visit my Son.

2011 Resolution Summary

2011-12-27T18:34:00.000-08:00

Items that are crossed out are completed.

Travel to Europe again. Travel to Asia or Africa.(Went to Australia instead. Which was an very, very acceptable substitute.)
Visit a Disney park.
~~See a place in the USA I've never been.~~
Drop the waist size 2 inches and ~~not break any bones.~~
~~Go to Pycon and present or teach.~~
~~Go to DjangoCon and present or teach.~~
~~Present at LA Django~~
~~Continue my Muay Thai and Capoeira studies~~, get back into Eskrima, learn some more BJJ, and ~~practice the forms I know.~~
Work out at least three times a week.
Go back east and teach martial arts for a day.
~~Finish some outstanding legal proceedings.~~
~~Launch a site that does cool stuff and somehow brings in money.~~ (Consumer Notebook)
Get to the point with LISP where I can do cool stuff in it without needing a textbook. (I seem to have spent this time working on JavaScript instead).
Blog once a week. That is at least 52 blog entries! (almost there!)
~~Explain why I wrote Diversity Rocks.~~

New Year’s Python Meme

2011-12-22T16:46:00.000-08:00

I love these blog memes, so I give you my version of Tarek Ziade's New Year's Python Meme.

1. What’s the coolest Python application, framework or library you have discovered in 2011?

For python libraries, that would have to be Kenneth Reitz' python-requests library. I've used it for an amazing amount of stuff and blogged about it. It took the grunge out of doing HTTP actions with Python. The API is clean and elegant, getting out of your way. It embodies the State of the art for API design, which closely matches the Zen of Python.

For applications, djangolint.com is awesome. It has helped me out so much on several projects. I would love to see something like this implemented and maintained for modern Python.

All the Python friendly PaaS efforts that have emerged are changing the landscape for those of us who want to launch projects but don't want to become full time system administrators in the process. Heroku, DjangoZoom, DotCloud, ep.io, gondor.io, and others are making it possible for developers to focus on development not server tooling. Google App Engine paved the way and it is wonderful to see the rest of the universe catch up with material that more closely follow core.

2. What new programming technique did you learn in 2011?

Event based programming! I've touched on it for years, but this year I really got a lot more more into it thanks to Aurynn Shaw kickstarting me and Audrey Roy expanding my knowledge ever since.

3. What’s the name of the open source project you contributed the most in 2011? What did you do?

I participated mostly as co-lead in the Open Comparison project, which amongst other things involved running the largest sprint at PyCon 2011. We maintained Django Packages and launched Pyramid and Plone versions of the project. We hope to launch a Python implementation in 2012.

I took a lot of notes this year at pydanny-event-notes - enough to make a book.

4. What was the Python blog or website you read the most in 2011?

Like Nick Coghlan, that would be http://planet.python.org.

5. What are the three top things you want to learn in 2012?

How to use whatever consistently maintained project that replaces PIL that works in Python 2.7.x and Python 3.x.
Really advanced Python as taught by Raymond Hettiger.
backbone.js

6. What are the top software, app or lib you wish someone would write in 2012?

A tool python-requests, but for shell access. Something like Unipath, but kept up-to-date and with nicely written documentation on Read the Docs.

A PIL replacement that is maintained, works for all modern Pythons, and is close enough to the PIL API to not cause too much confusion.

Something like Django Lint but for Python 2.7.x/3.x.

An open source project that tracks test coverages across PyPI and publishes reports of the results via an API.

Want to do your own list? here’s how:

copy-paste the questions and answer to them in your blog
tweet it with the #2012pythonmeme hashtag

Evaluating which package to use

2011-12-17T15:10:00.000-08:00

In November of 2009 I wrote about which third-party Python Packages I'll use. Here is my modern take on it - much of it inspired by personal experience and the advice of peers and mentors:

Tag and release on PyPI

I really don't like pulling from tags on Github, BitBucket, or whatever. Or being told to pull from a specific commit. That works in early development, but it certainly doesn't fly in production.

I also get frustrated when people release on PyPI but then insist on hosting the release themselves. That is because invariably at some critical point in development when PyPI is up, the host provider is down.

A huge point of frustration is that I shouldn't have to leave the canonical source of Python package versions to hunt down what I should be using. I've seen too many beginning Python developers fall into the trap of using 3 year old packages because they didn't know they should be using trunk. I was guilty of doing it for a 6+ month old release in 2010, and for that I apologize and promise I won't do it again.

This also means your package needs to be pip installable. If you don't know how to do it, please read the The Hitchhiker’s Guide to Packaging.

Documentation

2011 is closing, which means your package needs to have Sphinx Documentation. And those Sphinx Docs should be on Read the Docs. Read the Docs is great because it doesn't just host the rendered HTML, it also lets you easily push to it from a DVCS push - and implements nice search and handy PDFs too.

Yes, I know there is packages.python.org but I don't trust it. It doesn't have the easy push/deploy workflow of Read the Docs, which means often the docs are dated because it's yet another step for developers. Plus, the lack of search outside of Sphinx makes it hard to discover documentation.

The same goes for hosting docs yourself. In fact, that's usually worse because when someone goes on vacation and the docs go down... ARGH!

Please don't mention ~~easy_install~~ in your docs. We are nearly in 2012 and ought to be unified on our package installer, which is pip.

Tests

You should have them. Otherwise any update you put on PyPI puts the rest of us at risk. We can't be sure your updates to the project won't break our stuff. So please write some tests! If you add in coverage.py and some kind of lint checker, it can even be fun! It certainly does earn you bragging rights having a high coverage rating.

Code Quality

Are you using new-style classes or old-style classes? Do you follow PEP-8? Do you keep meta-classes to the absolute minimum? Is the code on an available DVCS so others can fork and contribute? These are things that weigh in my judgement, and certainly the judgement of others.

Announcing Consumer Notebook!

2011-12-16T11:57:00.000-08:00

Need a Python programming language book? Want to see a comparison of the ones I own and use? Check out my Must-Have Python Programming Books comparison grid.

Let's drill down and take a closer look at one of the items on the page, in this case Doug Hellmann's amazing The Python Standard Library by Example. The product detail pages include the ability to add pros and cons and attach said products to comparison grids and specialized lists like 'my wishlist' and 'my possessions'.

Speaking of wishlists, check out my own:

In order to add items, like footy pajamas, I click on the 'add' button and paste the Amazon (or BestBuy) URL into the form:

At this time we just handle Amazon USA and BestBuy USA. In the future we plan on adding more affiliate providers, including non-USA providers to support our non-USA friends.

There's a lot more than that...

In addition to weekly infographics, comparison grids, lists, and products, Consumer Notebook also awards points, coins, badges, and a growing privilege set to participating users. We even implemented an energy bar which regenerates over time, designed to match the pace of human users and serve as one of the brakes on scripts and bots.

Technology

I built this with Audrey Roy using Python, Django, JQuery, PostGreSQL, Memcached, and RabbitMQ. I'll be blogging in depth about the technical side in an upcoming post.

Genesis

It was the summer of 2010 and we were brainstorming ideas for a coding contest called Django Dash. The one we settled on was a listing and comparison site for Django called Django Packages. The result has been a very useful tool for the Django community. Eventually, with the help of several dozen people, we turned the code into the Open Comparison framework and launched Pyramid and Plone implementations. Time permitting this year, we plan to do Python, Flask, Twisted, Node, JQuery, and other implementations.

Since then we've wanted to do something similar, but in the context of products. And we wanted to do it right - elegant design combined with an ad-free space. So we cooked up Consumer Notebook, launching today!

We'll be adding features and enhancements in the months to come. We've acquired a community manager, and even have a blog. We would love for you to check out the site, share it with your friends and family, and send us your commentary, suggestions, and advice.

My BaseModel

2011-12-09T07:05:00.000-08:00

When I build projects in Django I like to have a 'core' app with all my common bits in it, including a BaseModel. In that BaseModel I'll define the most basic fields possible, in this case a simple pair of created/modified fields built using custom django-extension fields.

# core/models.py
from django.db import models
from django.utils.translation import ugettext_lazy as _

from core.fields import CreationDateTimeField, ModificationDateTimeField

class BaseModel(models.Model):
    """ Base abstract base class to give creation and modified times """
    created     = CreationDateTimeField(_('created'))
    modified    = ModificationDateTimeField(_('modified'))
    
    class Meta:
        abstract = True

You'll notice I also have core.fields defined. That is because (unless things have changed), django-extensions doesn't work with South out of the box. Hence the file below where I extend those fields to play nicely with my migration tool of choice.

# core/fields.py
from django_extensions.db.fields import CreationDateTimeField, ModificationDateTimeField

class CreationDateTimeField(CreationDateTimeField):

    def south_field_triple(self):
        "Returns a suitable description of this field for South."
        # We'll just introspect ourselves, since we inherit.
        from south.modelsinspector import introspector
        field_class = "django.db.models.fields.DateTimeField"
        args, kwargs = introspector(self)
        return (field_class, args, kwargs)    
        
        
class ModificationDateTimeField(ModificationDateTimeField):

    def south_field_triple(self):
        "Returns a suitable description of this field for South."
        # We'll just introspect ourselves, since we inherit.
        from south.modelsinspector import introspector
        field_class = "django.db.models.fields.DateTimeField"
        args, kwargs = introspector(self)
        return (field_class, args, kwargs)

Unfortunately, this all shows up as red marks when I run coverage.py reports. To deal with that I added in some tests. However, I'll readily I'm not super pleased with the tests below, but they are better then nothing, right?

# core/tests/test_fields.py
from django.test import TestCase

from core.fields import CreationDateTimeField, ModificationDateTimeField

class TestFields(TestCase):
    
    def test_create_override(self):
        field = CreationDateTimeField()
        triple = field.south_field_triple()
        
        self.assertEquals(triple[0], 'django.db.models.fields.DateTimeField')
        self.assertEquals(triple[1], list())
        self.assertEquals(triple[2], {'default': 'datetime.datetime.now', 'blank': 'True'})
        
    def test_modify_override(self):
        field = ModificationDateTimeField()
        triple = field.south_field_triple()
        
        self.assertEquals(triple[0], 'django.db.models.fields.DateTimeField')
        self.assertEquals(triple[1], list())
        self.assertEquals(triple[2], {'default': 'datetime.datetime.now', 'blank': 'True'})

Closing Thoughts

My pattern is also If I need more stuff in this BaseModel I extend it with another abstract class instead of changing it. That way I can be sure at least this part works really well and any additions are isolated in another class.

I'll reiterate that I'm not happy with the tests. I'm open to suggestions.

I pretty much got the BaseModel from Frank Wiles of RevSys back in the summer of 2010. What I added was sticking all the common bits into the core app, getting the South migration to play more nicely, and adding tests.

But much of this is moot!

Note: I added this segment several days after my original posting because of the stuff in the comments. Thanks Jannis Leidel and someone named John - this is part of why I post.

Jannis and John both pointed out that django_extensions now has a TimeStampedModel that does what my BaseModel does. They also pointed out that django_extensions comes with built-in South migrations for it's CreationDateTimeField and ModificationDateTimeField fields.

Which means thanks we can safely just do this and not worry about migrations:

# core/models.py
from django.db import models
from django.utils.translation import ugettext_lazy as _

from django_extensions.db.fields import CreationDateTimeField, ModificationDateTimeField

class BaseModel(models.Model):
    """ Base abstract base class to give creation and modified times """
    created     = CreationDateTimeField(_('created'))
    modified    = ModificationDateTimeField(_('modified'))
    
    class Meta:
        abstract = True

Made Up Statistics

2011-12-07T08:16:00.000-08:00

At DjangoCon my good friend Miguel Araujo and I presented on Advanced Django Form Usage. Slide 18 of that talk mentioned some made up statistics. Here they are for reference:

91% of Django projects use ModelForms.
80% ModelForms require trivial logic.
20% ModelForms require complex logic.

Important Disclaimer: These numbers were cooked out of thin air by yours truly. I determined them with zero research, they carry absolutely not scientific weight, and shouldn't be used in any serious argument. They are wholly my opinion, which is good or bad depending on your point of view and your own opinion of my opinions.

With that out of the way, I'm going to make a bar graph out of my fictional data:

You'll notice that my bar titles could be stronger. I actually did that on purpose in case anyone tries to use that chart in real life. In any case, if you thought that was interesting, then read on. I have many more made-up statistics. For example, here are more numbers I've cooked up:

Pydanny Made Up DevOps Statistics

DevOps is the new hotness. I know because every other Python meetup features someone speaking on it - just like every other Ruby, Perl, and PHP meetup. Anyway... numbers:

24.3% Python developers doing DevOps think they could have launched a PaaS (aka Heroku clone) before it got crowded.
46.3% Python developers doing DevOps spend all their time writing Chef/Puppet scripts and yet still claim to be Python developers.
14% Python developers are worried about so much of the backend being done in Ruby.
54% Python developers are just happy that there are many options now and don't care about the internal machinery that much.

This time, because I'm worried about the data being taken seriously, I've titled the bar chart in such a way that no one will reference it in anything important:

Pydanny Made Up Python Enviroment Statistics

Following the obvious logic flow (to me anyway) of DevOps to something else, let's go into Python environments, also known as the VirtualEnv vs Buildout debate, which adds up to an even 100% (making it good pie chart material):

77% of Python Developers prefer VirtualEnv.
13% of Python Developers prefer Buildout.
7% of Python developers rolled their own solution and wish they could switch over.
3% of Python developers rolled their own solution and are fiendishly delighted with how they have guaranteed their own job security forever. I know who some of you are and I can say with some confidence that when the Zombie apocalypse happens, no one is going to invite you into their fortified compounds. We hate you that much.

Pydanny Made Up Template Debate Statistics

The made up statistics in this post frequently touch on contentious topics. So let me add another controversial topic, this time the never ending template debate in Python:

70% python developers prefer non-XML templates
25% python developers prefer XML templates
5% python developers wonder why we don't just use the str.format() method and be done with it
50% python developers strongly disagree with my Stupid Template Languages blog post from last year.

The display for this data is a lovely pie chart as seen below. In order to make it appear more useful, I took out the part where people disagreed with me and also made it a 3-D pie chart.

Pydanny Made Up Python Web Optimization Statistics

I sometimes get asked how to best optimize a Django site. My answer is 'cache and then cache some more' but there are those who disagree with me and start switching out Django internals before doing anything silly like looking at I/O. My bet is this same thing happens with other frameworks such as Pyramid.

20% developers argue switching template languages.
80% developers argue using caching and load balancing.
100% Django/Pyramid/Flask/etc core developers argue using caching and load balancing.

Of all the made up statistics in this blog post, I suspect this is the one closest to the truth of things.

Update: Alex Gaynor and Audrey Roy pointed out that the original line graph for this data was not appropriate. My weak defense was that I'm trying not to make things too serious but they stated that the line graph was so inappropriate it distracted from the rest of the post. Thanks for the advice!

Pydanny Made Up Framework Debate Statistics

Alright, let's conclude this article with some statistics I cooked up about frameworks in Python. I'm going to do more then just mention web frameworks, dabbling into other awesome things that the Python community has given us.

23.6% of us get web.py and web2py confused with each other.
42% Python developers think Pyramid/Flask have awesome names that don't get mispronounced the same way Django does.
28% Python developers wish they could find a way to get some SciPy into their projects.
22% Python developers wish there was a PEP-8 wrapper for Twisted.
49% Twisted developers wish that Python had accepted their standard instead of PEP-8.
90% Python developers wonder what they were drinking when they renamed it to BlueBreem and wonder if it is sold over the counter in their municipality.

No chart? Getting this one to look meaningful was turning into a herculean effort. I invite others to render this data into something that look attractive and doesn't lose meaning. Come up with something impressive and I'll put it into a follow-up blog post.

The Story of Live-Noting

2011-12-04T16:46:00.000-08:00

Like a lot of people, I've got this thing I do when I attend conferences, meetups, classes, and tutorials: I take notes. My open source based ones are mostly written in RestructuredText and I've kept in a particular folder since at least 2006.

Putting notes in a DVCS

On September 13, 2009, I uploaded these notes to Github.com. I did that because I wasn't pleased with the workflow I established of moving items to Dropbox for backup. I use DVCS all the time and I figured why not just put my notes where I put my code? So I added my notes as a Github repo.

DVCS Notes Based Management System?

For a while I tried to use the Github folder README.rst trick to make a navigations system for my notes. But Github isn't designed for making a README into a dynamic custom content navigator, and it would make a silly feature request. I would rather the Github team work on Mercurial integration or other practical things before they honored a request to turn their system into my own custom Notes Management System. Eventually I just gave up on it and moved on.

Sphinx + Read The Docs!

In early July of 2011 I had a wicked fun thought. What if I turned my notes into a Sphinx project and posted it on readthedocs.org? Most of my content is in RestructuredText and I've gotten really fast at rolling out Sphinx documentation. The 'hard' part would be converting the few README.rst files into index.rst files, but on the flip side I could use fancy Sphinx directives.

I'm not exactly sure when I started down this path, bit this commit log entry leads me to think I had it working on or around July 8th. What that would mean is that every time I pushed up a change in my notes, within minutes readthedocs.org would publish the content to the world in lovely HTML markup.

The result?

Pydanny Event Notes

Here's a screen shot of the front page

PyCon Australia 2011 Test Drive

For the 2011 PyCon Australia I gave my new process a serious whirl. I found if I created the page before the talk and entered some basic data like author and title and tied it to the index then I could constantly check the quality of my output while taking my notes. It made my notes seem a bit more exciting and alive. I even tweeted about it cause I thought it was fun, and people around the world seemed to enjoy the effort I was putting into my notes.

Because I was committing constantly in order to get updates on readthedocs.org as soon as possible, I also adopted the habit of super-short pull request messages. That's because the content I'm writing overrides the need for verbose comments. So when you see me writing "moar" it's because every minute or so I'm doing something like:

$ git commit -am "moar"
 $ git push

Kiwi PyCon 2011

I did my rapid note taking again at Kiwi PyCon and it was fun. The downside was that sometimes I get rather critical in my notes and I had a couple speakers come up to me later to clarify their positions. This makes it a bit challenging because I want to put down my thoughts, but if my thoughts impact another person, what should I do? Especially since if my negative notes on someone turn up in a search it can negatively impact the speaker way beyond a single talk. This is now always on my mind when I take notes, and I'm trying to figure out a good way to handle this going forward.

In essence, I don't want to constrain what I write but I also don't want to write something that will haunt someone else later. Even with a caveat and all that stuff, it can still be problematic. There is a difference between me ranting about something and me taking notes, and the written word is such that things are all too often taken out of context.

Food for thought indeed.

DjangoCon 2011 and the invention of the term 'live-noting'

At the start of DjangoCon 2011 someone tweeted that they were planning to 'live-blog' the event. Suddenly I realized that what I was doing had a name for it, and that was 'live-noting'. So I tweeted that was what I was doing and it seemed to catch on.

Not only that, but I got asked if I would accept pull requests. After a good two seconds of deep thought, I responded that I would only consider corrections and clarifications, not new material. I received not just one, but two pull requests from good friends and left the conference pretty happy.

On top of that, I managed to get featured on the front page of http://readthedocs.org! (Thanks Eric)

Kenneth Love also took notes in a similar fashion: readthedocs.org/docs/djangocon-2011-notes

PyCodeConf 2011

I had the excellent fortune of being an invited speaker to Github's PyCodeConf. While I gave my talk, my lovely fiancée, Audrey took notes of my talk and submitted a pull request. Her contribution was the first time I accepted content I did not write, and I'll say right now she's the only one for whom I will accept such content. On the other hand, If you take notes when I present let me know and I'll link to them from my own notes.

Josh Bohde also took notes at the event in a similar fashion readthedocs.org/projects/joshbohde-event-notes and even as I write this post he shares the featuring of our notes on the frontispiece of readthedocs.org:

Closing Thoughts

I often use my notes as reference, and if you follow the commit logs you may even see me comment or clean up things I wrote down years ago.

The graphs and stats of this effort is really interesting. Fortran? And a total of
Five contributors!

All of this makes taking notes a lot more fun. I enjoy finding ways to enhance and improve my process, and find it exciting that others are following a similar pattern of effort. My hope is to make 2012 the Year of PyCon, where I find a way to go to a Python related conference on six continents (Antartica is too cold for my tastes) and take notes everywhere.

Going forward, should I document how I built this out? Would my steps and patterns be useful for others?

Redux: Python Things I Don't Like

2011-11-04T13:00:00.000-07:00

Back in May of 2009, I wrote about Eight Things I don't like about Python. It was my attempt to come up with things I don't like about my programming language of choice. Consider this my update of that post.

1. Division sucks in Python

In Python 3 this is fixed so that 2 / 3 = 0.6666666666666666 but in Python 2.7.x you have 2 / 3 = 0. You can fix that in Python 2.7.x with doing a from __future__ import division before your division call. Can anyone tell me if a version of 2.7.x will natively support 2 / 3 = 0.6666666666666666 without that import?

Note: Chris Neugebauer pointed out that changing division in Python 2.7.x will break backwards compatibility. However that doesn't change that I don't like it in Python 2.7.x.

2. TKinter blows

Honestly, it doesn't really matter to me anymore. I either use command-line scripts or things delivered to the web. Also, thanks to Brett Cannon, I know if I need to make TKinter look good, I can use TK Themed Widgets right out of the standard library.

3. Lambdas make it easy to obfuscate code

I'm known for not liking lambdas in Python. These days, I do know of use cases for Lambdas, but those are far and few between. I might even try to turn that into a blog post this month - use cases for Lambdas in Python. Fortunately for me, these days I seem to work with people who mostly agree with me on this subject.

4. Sorting objects by attributes is annoying

This is still annoying for me. As I said, "... the snippet of code is trivial. Still, couldn't sorting objects by attributes or dictionaries by elements be made a bit easier? sort and sorted should have this built right in. I still have to look this up each and every time."

I've thought of proposing something easier as a PEP. Imagine that! Me submitting a PEP!

5. Regex should be a built-in function

Before I got to do Python full-time I was a go-to person with regular expressions. Languages without them were weak in my opinion. Since then (2006-ish) my skills have faded somewhat in regards to regular expressions. And you know what? It hasn't been a problem. Python's string functions are fast and useful, and when I really need regular expressions, I import the library and do some research. I'm considering this one closed.

6. Reload could be less annoying

Reload only works on modules. I want to be able to something like reload(my_module), reload(my_class), reload(my_function), or even reload(my_variable):

>>> from my_module import MyClass, my_function, my_variable
>>> mc = MyClass(my_variable)
>>> mc 
5
# I go change something in my_module.MyClass and save the file
>>> reload(MyClass) # reload just MyClass
>>> mc = MyClass(my_variable)
>>> mc 
10

My current fix is to use unittest as my shell as much as possible. And that is probably a good thing.

7. Help doesn't let me skip over the '__' methods

As I said way back when, "Python's introspection and documentation features makes me happy. And yet when I have to scroll past __and__, __or__, and __barf__ each time I type help(myobject), I get just a tiny bit cranky. I want help to accept an optional boolean that defaults to True. If you set it to False you skip anything with double underscores.

The See project is one solution to the issue. A different approach I've used is the Sphinx autodoc feature, but Sphinx is a lot of work and doesn't cover every contigency.

8. Not enough female Pythonistas

These days I know a lot of female Python developers. There is my own fiancee, Audrey Roy. Face-to-face I've met and talked to Christine Cheung, Jackie Kazil, Leah Culver, Katharine Jarmul, Katie Cunningham, Barbara Shaurette, Esther Nam, Sandy Strong, Sophia Viklund, Jessica Stanton Aurynn Shaw, Brenda Wallace, Jen Zajac, and many more I know I'm missing. And there are even more with whom I've had in-depth online conversations.

So why didn't I put a strike-through on this one? Because the numbers still aren't good enough. I know a lot of female Pythonistas, but how many do you know? And even if you know a decent number, what percentage of a meetup group you attend are women?

I can say that things are improving, but they could be better - for women or minorities. Find ways to pitch in, be it PyLadies events, PyStar workshops, or what have you.

One last note on this subject, I've heard some unsubstantiated statements that the .Net world has a higher female-to-male ration then the Open Source world. Are we going to take that kind of thing sitting down?

Loving the bunch class

2011-11-02T13:40:00.000-07:00

Warning
This is me playing around with things in Python. It's not anything I use in real projects (except maybe the odd test). Please don't use these in anything important or you'll regret it.

Every play with a bunch class? I love 'em and make them protected or unprotected. I started using them early in my Python career, although it wasn't nearly about 2 years ago that I learned what they were called and the best way to code them. In any case, here is a simple, unprotected Bunch class.

# Simple unprotected Python bunch class
class Bunch(object):

    def __init__(self, **kwargs):
        self.__dict__.update(kwargs)

bunch = Bunch(name='Loving the bunch class')
print(bunch.name)

You can also make protected ones, that don't let pesky developers like me overwrite attributes, methods, and properties by accident:

# Simple protected Python bunch class
class ProtectedBunch(object):
    """ Use this when you don't want to overwrite existing methods and data """

    def __init__(self, **kwargs):
        for k, v in kwargs.items():
            if k not in self.__dict__:
                self.__dict__[k] = v

You can also write them to raise errors when a key is in self.__dict__. Or perhaps merely publish a warning. There are many ways to customize, but generally you want to keep these things as simple as possible. Anyway, let's get back to the main topic...

In the early days of my experiences with Python I found a small, nagging issue with dictionaries and objects. The notation wasn't as handy as what you got with JavaScript and some other languages I was using at the time. For example:

// JavaScript object notation
o = {};
o.name = 'Loving the bunch class';
o.name; // Calling with 'dot' notation
o['name']; // Calling with 'bracket' notation

Unfortunately, in Python you can't do this with a normal bunch class:

# Python bunch class failing on bracket notation
class Bunch(object):

    def __init__(self, **kwargs):
        self.__dict__.update(kwargs)

bunch = Bunch(name='Loving the bunch class')
print(bunch.name)
print(bunch['name'])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'Bunch' object is not subscriptable

The quick answer is found with a little trick I found in the comments of a recipie by Alex Martelli that gives you the ability to do:

# Fancy dictionary/object trick
class Buncher(dict):
    """ Warning: DON'T USE THIS IN REAL PROJECTS """

    def __init__(self,**kw):
        dict.__init__(self,kw)
        self.__dict__.update(kw)

bunch = Bunch(name='Loving the bunch class')
print(bunch.name)
print(bunch['name'])

I'm not the only one who likes Bunch classes. On PyPI I found a really complete implementation.

Of course, in a lot of cases you probably don't want this 'weight of code', right? Dictionaries being lighter than full objects and all that. Nevertheless, it's fun for noodling and playing around with code. Still, I'm thinking it might be a fun little project to take a group of bunch implementations and do performance checks on them versus each other and dictionaries. Maybe the 'performance hit' isn't so bad.

I should also dig into things like defaultdict and other constructs to learn more. Part of the fun of any programming language is the depth of even the 'simplest' components of the language.

PyCodeConf 2011 Report

2011-10-14T08:16:00.000-07:00

As my fiancee said, "PyCodeConf is a new kind of Python conference with a radically different format. Speakers are invited to speak about whatever they desire relating to the theme ("The Future of Python"), in front of a room of round tables. In between talks there are long breaks to encourage discussion. As a result, talks are edgier, and you really get to know people and possibly shape the future together."

This summer (2011) I was invited by Chris Wanstrath to be an invited speaker at the first ever PyCodeConf, to be held in Miami, Florida. I've been using Git and Github since early 2009, and more importantly, I've known Chris since DjangoCon 2009. I've always appreciated his interest in not just providing tools for the community, but also his efforts across languages and platforms to improve the lives of developers and those who support developers. And that he and his partners seem to make a pretty penny at it and share what they make (drink-ups and now conferences) is only a good thing in my opinion.

So I accepted Chris' invitation. :-)

The theme for the conference was the future of Python, and I submitted a talk proposal about Collaboration. Chris helped me figure my talk topic, which was awfully nice of him. Shortly afterwards my fiancee, Audrey Roy, received her own invitation to speak.

Between the time that Chris invited me to speak and the start of conference, Chris Williams of JS Conf got involved.

Alright, let's review things...

Accommodations

Everyone stayed in the Epic Hotel, in downtown Miami. The rooms fit the name of the hotel, being Epic in size and having amazing stuff in them. The rooms had free/good internet if you signed up for a hotel mailing list. Since we rehearsed and polished talks the night before the conference we ordered room service and were pleased with what we ate. The hotel had a heated outdoor pool on the 14th floor, which I'll get into later. In any case, the only time I've been in a comparable hotel was the incredible arrangements provided by the PyCon New Zealand folks who put us up in the Museum Hotel for a few days.

Sure, $189/night is high, but 3 nights when you split it with 2 or more people makes it not so bad.

Result: Superb

Conference Meals

If you are serving me food, you can't go wrong with salmon, steak, good cheese, fresh vegetables, coffee, and juice. I can report that PyCodeConf did quite well in this regard.

Outside of the conference I really enjoyed the food. Andiamo was a crazy good pizza place. I also got some really nice grouper which you can only seem to get in Florida.

Result: Superb

The Conference Room

The conference took place on the 14th floor of the Epic Hotel. This was a single track conference, with all the talks were given in the same room. The room was large, but everyone had a comfortable seat at large round tables. That was a nice touch, because it encouraged you to socialize with everyone nearby.

That worked out for the most part, except for a couple of developers sitting at a table who had backs turned to the speakers and were talking loudly while pair programming or something. I asked them to quiet down but 30 seconds later they were back at it. We moved away, but in retrospect considering their rudeness, I should have politely asked them to take it outside.

Anyway, the acoustics were good, the temperature comfortable, and the seats comfortable.

Result: Superb

Speakers

Speaker selection was done magnificently well. There wasn't a dud within the lot of speakers. I normally expect that in any conference you'll get at least one dud talk per day, and pycodeconf didn't have that problem (unless my talk sucked).

Jesse Noller opened things up with a great encouraging talk, Raymond Hettinger gave a talk on Python basics that was so full of nuance that I'm terrified of attending an advanced talk by him, Alex Gaynor filled us with hope for PyPy, Tracy Osborn taught us how to bootstrap entrepreneur projects, Travis Oliphant wants Python core and PyPy to collaborate more with the Scientific Community, Audrey Roy gave up some of her community building secrets, David Beazly explained the issues of the GIL in terms mere mortals such as myself can understand, Gary Bernhardt gave an amazing talk comparing Python and Ruby, and Leah Culver made Django + backbone.js look easy, but if you talk to her you know whatever she does is sophisticated and not for beginners. Dustin Sallings sold me on a neat idea for testing to help catch edge cases and Armin Ronacher opened my eyes on WSGI.

The wonderful thing about these talks is that since everyone knew the upcoming tracks, or had seen the previous ones, we could relate to each other. So David Beazly, Travis Oliphant, and Avery Pennarun raised interesting concerns about PyPy that everyone got the chance to hear about. They weren't show-stopping issues, just raising awareness about things that Alex didn't cover in his talk.

I live-noted the event as much as I could, with notable gaps in Leah's talk (she talks fast and is very technical and wanted to give her my full attention) as well as Armin (his talk shocked me a bit - I'm still a WSGI newbie). You can see my efforts at my PyCodeConf live-notes.

Speaking of live-noting, Josh Bohde also live-noted the event and captured a ton of stuff I missed.

The gaps between talks were also a nice 15 minutes. That meant you could stretch your legs, get a drink, and talk to people.

Result: Superb

Parties

We (me and Audrey) missed the first party (hosted by New Relic at a place called DRB) on account of preparing for our talks. We always do our absolute best on talks, and both like to practice a lot. Also, Mark Pilgrim's disappearance had touched me and I wanted to talk about it. We heard it was a great party, so we'll assume that it was. :)

The next evening the party (hosted by Heroku) was on the 14th floor, which meant it was a pool party! There was great food, good drink, and a latin jazz band playing. One of the pools was heated, so most people stayed in there, and drank many watermelon mojitos served by the staff. The pool was a huge hit because it was comfortable and people just talked freely. No laptops, no phones, just talking. Chris Williams served us drinks himself, Chris Wanstrath got wet, and everyone just relaxed. I have to say, a heated pool party is something EVERY conference should give. MOAR POOL PARTEEZ PLEEZE!

The final night's party was at the News Lounge and was hosted by Github and Droptype. The drinks and people were awesome, and I have good memories of being in a circle listening to Chris Williams and Audrey Roy talk. I did go beyond tipsy, overdid the Capoeira, and tried to convince Chris Wanstrath to give up the whole DVCS hosting thing to do wedding planning. There was also a bunch of us getting kicked out of a Karaoke bar because of the antics of a Python core developer. Ha ha ha. It was a crazy night that took me two days to recover from.

I'm glossing some important discussions that happened while I was still sober at these two parties, and maybe in the future if things play out right I'll go over them.

Result: Superb

People

Part of attending conferences is to meet old friends and make new ones. I got to spend time with Mark Ramm, Jesse Noller, Nick Coghlan, Alex Gaynor, Ben Firshman, Armin Ronacher, Raymond Hettinger, Rachel Hettinger, Chris Wanstrath, and many other excellent people. I also got the chance to meet and befriend Kenneth Reitz, Chris Williams, David Cramer, Wayne Witzel, and Leah Culver. I'm missing at least a dozen more. It was great to put faces to people, and in some cases, hear their side of a story.

Also, I got to gush at programming heroes like David Beazly and Travis Oliphant like a total fanboy.

Believe it or not, I got a bit shy. I'm kicking myself over not introducing myself to more people. Next time!

Result: Superb

Summary

The conference was amazing. Like all conferences it had its own character and fun. Because it was a purely commercial conference I was a bit worried going into it, since I've heard about the corporate feel of these things. Those fears were completely mitigated by the open attitude and decentness of the conference organizers and sponsors. I look forward to attending PyCodeConf again in the future.

If you've got good senior technical staff and you want them to benefit from a conference, this is a good place to send them.

Overall Result: Superb

Conference Talks I want to see

2011-10-09T09:00:00.000-07:00

I'm writing this the day after Github's pycodeconf ended. That was an amazing conference, and I'll be blogging it soon (I'll also be writing about PyCon Australia, PyCon New Zealand, and DjangoCon US). With all this conference experience very current in my head, things I've seen and done at them, and the deadline for PyCon US submissions coming up, here are some talks I really want to see happen in the next six months. If not at PyCon US, then please consider these for other forthcoming events!

Note: Couldn't do my preferred 'linkify' as well as I liked thanks to bad hotel internet. I'll clean it up later.

Advanced SQL Alchemy Usage

I think the uber-powerful SQL Alchemy ORM needs the same sort of treatment me and Miguel Araujo gave on Advanced Django Forms Usage. Not a 30 tutorial or overview or 'State of', but tricks and patterns by someone who has used it frequently on more than one project. Multiple projects is important because the speaker should have had the chance to try multiple approaches. Start with something simple like a TimeStampModel all model classes might inherit from, then go into deeper and and more complex technical detail. Finish the talk with something crazy hard from SQL Alchemy that is hard to explain. If that causes you to open a bug/documentation ticket, then you'll know that you've done the talk right.

Advanced Django Models Usage

Following the same pattern as my SQL Alchemy idea above, start with something simple like a TimeStampModel (including South migration of fields), then go into complex looks with Q objects, good patterns for Managers, Aggregation, Transactions, and then finish it with the craziest, hardest thing you can find. When putting together the closing material causes you to open tickets for broken core code/documentation, then you know you've done it right.

Python Code Obfuscation Contest

This certain-to-be-controversial talk idea would be where the speaker would solicit Pythonistas to submit a single arcane Python code module that would have to display the text of "Although that way may not be obvious at first unless you're Dutch." There would be a 'Expert' category which would forbid the eval/exec functions. The "Anything Goes Category" would allow use of eval/exec. The conference talk would be where the speaker announces the winners and comments on the brilliant insanity of submissions.

Django + Flask + Pyramid: A demonstration of useful things you can do with WSGI

At pycodeconf Armin Ronacher showed how with WSGI, he can run Django, Flask, Pyramid all from same server from the same domain. This surprised a lot of people, including me, and I want to see more of what Armin was talking about. I don't want any theory. I don't want anything obscure. I just want meaty bits I can implement the day after I hear the talk.

Zen of Python

Richard Jones gave his version of the talk at PyCon AU, and I want to hear other opinions about it. I'm happy to hear an expert give his view, and I would also be delighted to hear how a beginner (or relative beginner) feels about it.

Websites and OO Design Concepts: A Tutorial

For beginners, I would love to see a talk on a list of OO theories, and as each list item was discussed, examples designed in the context of a web site, how to do things right, plus identified anti-patterns would be presented. The web angle would be a good way to get the incoming Python web crowd to attend and identify with raised issues.

Profiles: Breaking Normalization

2011-09-23T09:49:00.000-07:00

In the summer of 2010 I either saw this pattern or cooked it up myself. It is specific to the Django profiles system and helps me get around some of the limitations/features of django.contrib.auth. I like to do it on my own projects because it makes so many things (like performance) so much simpler. The idea is to replicate some of the fields and methods on the django.contrib.auth.model.User model in your user profile(s) objects. I tend to do this usually on the email , first_name , last_name fields and the get_full_name method. Sometimes I also do it on the username field, but then I also ensure that the username duplication is un-editable in any context.

Sure, this breaks normalization, but the scale of this break is tiny. Duplicating four fields each with a max of 30 characters for a total of 120 characters per record is nothing in terms of data when you compare to avoiding the mess of doing lots of profile-to-user joins on very large data sets.

One more thing, I've found that most users don't care about or for the division between their accounts and profiles. They are more than happy with a single form, and if they aren't, well you can still use this profile model to build both account and profile forms.

Alright, enough talking, let me show you how my Profile models tend to look:

from django.contrib.auth.models import User
from django.db import models
from django.utils.translation import ugettext_lazy as _

class Profile(models.Model):
    """ Normalization breaking profile model authored by Daniel Greenfeld """
    
    user = models.OneToOneField(User)
    email = models.EmailField(_("Email"), help_text=_("Never given out!"), max_length=30)
    first_name = models.CharField(_("First Name"), max_length=30)
    last_name = models.CharField(_("Last Name"), max_length=30)

    # username field notes:
    #     used to improve speed, not editable! 
    #     Never changed after original auth.User and profiles.Profile creation!
    username = models.CharField(_("User Name"), editable=False) 

    def save(self, **kwargs):
        """ Override save to always populate changes to auth.user model """
        user_obj = User.objects.get(username=self.user.username)        
        user_obj.first_name = self.first_name
        user_obj.last_name = self.last_name
        user_obj.email = self.email
        user_obj.is_active = self.is_active        
        user_obj.save()
        super(Profile,self).save(**kwargs)

    def get_full_name(self):
        """ Convenience duplication of the auth.User method """
        return "{0} {1}".format(self.first_name, self.last_name)

    @models.permalink
    def get_absolute_url(self):
        return ("profile_detail", (), {"username": self.username})

    def __unicode__(self):
        return self.username

All of this is good, but you have to be careful with emails. Django doesn't let you duplicate existing emails in the django.contrib.auth.model.User model so we want to catch that early and display an elegant error message. Hence this Profile form:

from django import forms
from django.contrib.auth.models import User
from django.utils.translation import ugettext_lazy as _

from profiles.models import Profile

class ProfileForm(forms.ModelForm):
    """ Email validation form authored by Daniel Greenfeld """
        
    def clean_email(self):
        """ Custom email clean method to make sure the user doesn't use the same email as someone else"""
        email = self.cleaned_data.get("email", "").strip()

        if User.objects.filter(email=email).exclude(username=self.instance.user.username):
            self._errors["email"] = self.error_class(["%s is already in use in the system" % email])
            return ""            

        return email

    class Meta:
        
        fields = (
                    'first_name',
                    'last_name',
                    'email',
                    )
        model = Profile

History of my most used shell commands

2011-09-14T09:39:00.000-07:00

I ran this a few years back and I'm running it again today.

What is interesting is that compared to the older history, git has replaced svn, pip has replaced easy_install, and virtualenv has now completely subsumed buildout. Oh, how the mighty have fallen!

$ history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn |head -n 20

209 git
123 python
34 ls
31 mate
18 cd
14 pwd
9 hg
8 touch
7 rm
6 cp
5 pip
5 mv
5 django-admin.py
4 mkvirtualenv
3 mysql
3 mkdir
3 bash
2 deactivate
2 add2virtualenv
1 workon

Quick conferences report: Presentations

2011-09-13T20:11:00.000-07:00

My lovely Fiancée, Audrey Roy, was invited to be the opening keynote speaker at both PyCon Australia on Diversity in Python (video) and PyCon New Zealand on Python on the Web.

As for me, I managed to get talks into both of those conferences AND DjangoCon US. I co-presented on three of them, and I share all credit for success with my cohorts. The talks I gave at the conferences were (I'll post videos when they get up):

Confessions of Joe Developer (PyCon Australia, DjangoCon US)
The genesis of this talk was as a lightning talk at I gave at the Hollywood Hackathon. It is a talk about admitting that us mere mortals need to ask questions, take notes, and follow good practices in general. I gave it again at LA Django this summer, extending it to a full length talk complete with lots of technical content. At PyCon Australia I toned down the technical content because I was nervous, and while the response was positive, it could have been much better. So for DjangoCon I ramped up the tech-talk and it worked much better. I've now given the talk 4 times, and I'm leaning towards retiring it.

Python Worst Practices (PyCon New Zealand)
This talk grew out of a SoCal Piggies lightning talk which I gave for the purpose of humor. Often we as Python developers are smug in the clarity of the language that we don't realize just how easily we can obfuscate code. In fact, I contend that Python is fully capable of a code obfuscation contest. This talk rejects a lot of crazy practices I've either done myself or had to debug from other people's work. For New Zealand I added a ton of content and tested things pretty diligently. The variable naming pages stumped some people I really respect and I was quite happy with that result.

Django Packages Thunderdome (co-presented with Audrey Roy, DjangoCon US)
Audrey did most of the work for this presentation. In this talk I helped review a horde of Django Packages across 7 different categories. It was nerve wracking because every part of our talk would get judged - but Audrey kept things really positive and made it clear we were providing constructive criticism. I think she got her message across to most people, and more importantly, it got a lot of people thinking about what ought to be normal community standards. I'll probably blog on those community thoughts and statements later, but I think Audrey (with help from me) accomplished what she aimed to do.

View more presentations from Audrey Roy

Advanced Django Form Usage (co-presented with Miguel Araujo)
Some time ago Miguel befriended me and helped resurrect the django-uni-form project. He graciously agreed to help me present on Django Forms and we decided to make the talk as sophisticated as possible. Previous Django form talks have been good, but focused on the fundamentals and we wanted to do something really different. This talk was hard because Miguel and I were on opposite sides of the planet, so we did a lot of github pull/pushes. In both doing research and presenting Miguel did an unbelievably good job and I hope he does more of this in the future. The response was extremely positive and I'm certain that our plan of getting our notes/work/transcript into Django core is well on it's way.

Ultimate Django Tutorial Workshop (DjangoCon US)
I got about 10 professional Django experts in a room, including Django core developers, and had them help me coach nearly 20 people through a modified version of the Django tutorial. Students seemed to learn tons, lots of socializing happened thanks to some happy accidents, and the experts got a chance to really see where the Django tutorial needs work. PyLadies organizer Esther Nam spent her sprint days working on something that ties the slides into the Django Tutorial - and for now I'm holding off on sharing my work until she says her work is done.

Summary
These were amazing opportunities to speak and will hopefully make a difference. I wouldn't have traded all of this for the world. It was a lot of work, and I doubt I'll ever go quite at this pace again. My plan is to do fewer talks and make them much better.

Responses to Github is my resume

2011-09-04T15:19:00.000-07:00

Shortly after I posted Github is my resume the responses started coming in. They seemed to fill these categories:

"Github is a portfolio, not a resume!"

I think this is rather valid, being a much more accurate description of the role that Github and other social coding sites are having in getting developer jobs these days. Two of the more choice responses in this category were posts by Gini Trapini and Andy Lester.

"In X years of hiring, I've never requested source code along with the resume!"

This comment raised the issue that personality, location, writing skills, etc were important. I agree that being able to not annoy your team into losing productivity is important, but it doesn't negate the frequent desire to be able to review the work of potential hires. Ignore the code at your own risk.

"Using only binary for calculations, how many ping pong balls fit in your car?"

A couple people said they prefer to ask programming questions or challenging problems in interviews to seeing portfolios of code. Personally, I think a few programming questions are okay but in my opinion 'challenging problems' all too often means sticking your interviewees with puzzles and trick questions that all too often have nothing to do with the day-to-day work of being a developer.

Github is my resume

2011-08-23T06:04:00.000-07:00

I remember the first time I heard that statement - a couple years back Eric Florenzano said it to me on Twitter when I posted my resume publicly and asked for opinions. At the time I laughed at his statement, because it felt like naive arrogance to ditch the idea of a resume and 'traditional' social networking like Facebook and LinkedIn. How wrong I was...

Before I go any further, this isn't to say that education, job history, and references aren't important in getting jobs that utilize a lot of Python. They are important, but I think they go more towards shaping you as a person than getting a job. So if you want access to Python jobs (and possibly other open source languages), you need to be able to show working code. Why is this the case? I can thing of several reasons:

It is much harder to forge your style of code, comments, tests, and docs in a repo than it is to make false claims on a resume.
Development team managers don't take LinkedIn references seriously because how often we see them gamed.
Code gives us a body of work employers (including me) can use in order to help evaluate your skill and ability levels.

Let's summarize that into a bold statement:

Python employers want to review your code in a public repo.

That puts the pressure on you doesn't it? Now you've got to show working code. One extremely unethical way to do that is to copy/paste other people's code into your own repo and claim it as your own. The problem with that is real reviewers know good code doesn't just magically appear in gigantic chunks. Which I'll sum up with another statement:

Python employers are smart enough to read your commit log.

So as a beginner, what can you do? A lot of shops will want to see your code but if you put up your early code, doesn't that mean they'll see your ugly, mistake-ridden work? Yes they will - but if you keep at it with tutorial examples you are working, whatever pet project you cook up, or even submitting patches to various existing projects, they'll see how your code improves. I am much more inclined to hire a person able/willing to learn than a jaded expert who doesn't want to grow - which is why I always try to think like an eternal beginner. Which brings me to my third statement:

Python employers are willing to hire bright, hungry developers willing to learn.

Getting away from employment, let's talk a little about the Python development community. This community is a meritocracy with amazing foresight. Passion for code and/or natural talent is often recognized before skill is achieved - but only if you show the community you are learning. Get your code onto Github, or BitBucket, or SourceForge so it is seen, and keep at it! Try to commit every day and if that isn't possible, then once a week!

Because if you write code every day or every week, over time your code will get better, you'll also be able to demonstrate a consistent body of work, and your passion for software development will be obvious. Also, try to comment your code as much as possible.

One good trick is to put your ongoing notes in a repo. I do it myself at https://github.com/pydanny/pydanny-event-notes. My early notes are very, very different from my later notes. Often embarrassingly so, but to a Python employer I'm pretty certain they are a useful reference into just how I think.

Github, not LinkedIn

LinkedIn (and Facebook, Google Plus, et al) are a place to define your profile and nothing more. That profile should include a link to your code. Python employers will be looking your for links to your code, not for any sort of networking you do on those sites. Employers get annoyed by 'developers' who excessively network but have no links to code samples on Github or other similar sites. If you have no code to find then it means we can't see your work, your thought processes, or your passion.

One common technique you see by a lot of Python developers is posting quick links to their projects and efforts on Github using various social networks. You can and should do the same.

You make connections by showing you want to learn

The Ultimate Django Tutorial Workshop

2011-07-31T14:26:00.000-07:00

That is a big statement to make as a title of a class/workshop blog post. However, in this case I believe I'm fully justified because this is going to be awesome. Here's why:

1. The teachers are beyond incredible

In the course description it says I'm the teacher and I have lab assistants. In retrospect, what I should have said is, "Daniel Greenfeld is organizing a workshop taught by the people he respects and admires".

Think I'm kidding? Look at just some of the names of people I've got lined up to participate:

Jacob Kaplan-Moss, Benevolent Dictator For Life of Django
Russell Keith-Magee, President of the Django Software Foundation
Audrey Roy
Jacob Burch
Katharine Jarmul
Corey Bertram
Sandy Strong
Jonas Obrist
Christine Cheung
Shimon Rura

Follow those links to their bios or talks and you'll see that they are the people speaking at DjangoCon. The general idea is to get the people already speaking at DjangoCon or those who are extremely experienced in it to teach the class.

2. The teacher to student ratio is going to be really small

This is not going to be a room with a few instructors and umpteen students in it. If the class size gets big, I'm going to bring in more teachers. I'll cajole, plead, and do whatever I must to get them in the room. I don't want anyone left behind!

I want a ratio of 5 students to each teacher.

3. Class implemented with a lot of lessons learned

I've taught a bunch. So have a number of the instructors I've lined up. We know which parts of the tutorial are important to focus on, and which parts should be visited by students later on their own. This means you learn the critically important parts that get you kick-started as a Django developer.

One thing we'll try to squeeze in is deployment to one of the new Django hosts such as Djangozoom.com, Gondor.io, and ep.io. In fact, Shimon Rura, one of the co-founders of Djangozoom, participating as an instructor.

4. We're all volunteers

All the proceeds earned by the instructors for this course will be going to the Pyladies Sponsorship program. That is important for two reasons:

Your attendance will help Pyladies sponsor more women to learn Python in the future.
The teachers are doing this because they want to do it. They want you to learn Django.

5. It won't end at 12:30 PM

Officially the tutorial ends at 12:30PM and we should be done. Sometimes though we stumble on things and we don't finish with the rest of the class (like me in my last C programming class). But after a lunch break I'm planning on grabbing some space and working through the rest of the tutorial with anyone who didn't complete the class.

6. The tutorial opens DjangoCon

The tutorial starts on Monday, September 5, 2011 at 9:30 AM at the Hilton Portland and Executive Tower at 921 SW Sixth Avenue in Portland, Oregon, USA. If you do plan on attending DjangoCon and are new to the framework, what a great way to get started!

7. You don't have to attend DjangoCon itself to take the tutorial

Tickets for the event are being sold separately from the conference. So if you can't take off more than one day of school or work, this is a great way to capitalize on DjangoCon.

Convinced? Here is what you need to know and do to get signed up:

Get a laptop running Windows 7, Mac OS X 10.5 or higher, or Ubuntu.
If there is no Python installed, install Python 2.7.1. DO NOT INSTALL PYTHON 3!!!
Make sure you have a grounding in Python. If you are new to Python you need to have finished at least half the chapters in learnpythonthehardway.org before you attend. If you come to this event with no prior Python experience you will be left behind.
Buy a ticket!

Amtrak Review

2011-07-17T20:53:00.000-07:00

Audrey and I got invited to a wedding in the Pacific Northwest. And mostly to try something new, we decided to take Amtrak's Coast Starlight from Los Angeles' Union Station to Seattle, Washington's King Street Station. There was some incredible awesomeness about the trip, and a lot that... wasn't so awesome.

No Internet (Bad)

Thanks to encroaching deadlines we planned to take advantage of Amtrak's wireless Internet, otherwise we would have flown. Each direction took 36 hours, which is basically two days. Which meant four working days on the train. Sure, we would have liked to have sat back and just enjoyed the journey, but for us that wasn't an option on this particular trip.

Unfortunately, both the ride there and the ride back lacked internet. In the first case the car with it wasn't part of the train. On the way back the car was part of the train but the Internet was nonfunctional. Which cost us nearly 4 days of work.

We did manage to use our cell phones for tethering, but coverage on rail lines is not that good. Each time we hit a town we connected and caught as much as we could. It wasn't ideal, but it worked. We're still trying to dig out from under work time lost.

What you should know is that more experienced Amtrak passengers all said that they've never had working Internet. There is always a problem on long journeys on the Coast Starlight. Which means don't use the train for business.

The Room (Okay)

We aren't big people and are fairly flexible and athletic. So the roomette we got was quite snuggly. Larger people or those unable to maneuver in tight spaces will probably be uncomfortable.

However, I think if I did this again I would get a bigger room. They have restrooms built in, but I think I would use external bathrooms so as to keep the room smelling nicer.

Food (Okay)

The breakfast eggs and dinner steak rocked. So did the ribs. The coffee was good. Everything else was mediocre at best.

The juices they served tasted like they lacked any connection to natural substances.

Room Attendants, Conductors, and Lounge Car attendant (Good)

The room attendants were amazing. They worked their butt off and got no sleep. I made sure to tip them well. The conductors were also extremely helpful. The first lounge car attendant, a guy named 'CJ' was incredible - he lacked a real lounge car and simply made do.

Diner Car Service (Unacceptably Bad)

The service in the Dining cars was uniformly bad. They were rude, obnoxious, and did their absolute best to avoid eye contact. One meal, when we waited two freaking hours for our food while others got seated and finished after we ordered, was unbelievable. If we asked about our food or drink refills we got snapped at. In retrospect, we should have gotten up and left - or filed a formal complaint.

After several attempts to weather the bad service we took all meals in our private roomette.

Scenery (Outstanding)

This is the part of things that was incredible. The Coast Starlight goes through some amazing scenery, from the beaches of Southern California to the incredible forests and mountains of the Pacific Northwest. Pictures just don't do it justice - you have to see it sometime for yourself.

Conclusion (Okay)

The lack of Internet was annoying. The abominable dining car service was infuriating and Amtrak should give their dining car servers some basic lessons in proper restaurant hospitality.

Those things said, because the scenery was just that lovely, I might consider taking another multi-day train ride over a time when I wasn't trying to hit deadlines and would avoid the dining car at all costs.

Python and Django class/hackathon!

2011-07-17T19:32:00.000-07:00

The Los Angeles Python community (LA Django and LA PyLadies) is meeting in Santa Monica on July 23rd to teach Django and hack on all things Python on Saturday, July 23rd. The day will start with a Django class based on the official Django tutorial, then turn into a general hackathon, and finish up with lighting talks.

Leading the event is noted Pythonista Katharine Jarmul. As Katharine is giving the talk on web scraping at DjangoCon US, I'm hoping we can get her to give a lightning talk on the subject.

Learning Django

Sandy Strong will lead the effort to teach people the fundamentals of Django. Besides all things Django and devops, Sandy is presenting the testing talk at DjangoCon US. And if that isn't good enough for you, she won't be alone teaching - there will be a bunch of us developers experienced with Django there to to provide her with support.

Even if you already know Django, please come and hang out for the first half! You can either help out others or work on your own project.

Hacking Python and Django

The second half of the day will be about working on whatever you want. If you are new to Django and want to finish the tutorial, go right ahead. Or you can work on your own pet Django or Python project. In fact, I know that there will be work on the nascent Pyramid project intended to represent the entire Los Angeles Python community.

Lightning Talks

We'll finish with lightning talks. Several people who attended the day will get the chance to talk for 5 minutes or so about a project, tool, or cause they wanted to share. If they go too long we start applauding until they step down.

Social Hour

After another awesome day of Python in LA, everyone will cool down by hanging and chatting over drinks. If you're lucky, maybe you'll get to see me do a drunken one-handed cartwheel where I don't spill a drop of what I'm holding.

My role

I'll be there in my normal role of setting up tables and chairs, helping during the class portion, and hacking on some Packaginator stuff in preparation for the forthcoming August/September Packaginator sprints at PyCon AU, Kiwi Pycon, and DjangoCon US.

Sponsors

This is all possible thanks to the sponsorship of Mahalo, Cars.com, and the Python Software Foundation

Sign up!

Tickets are selling out really fast! Sign up now!

Normalization noitazilamroN

2011-07-12T15:41:00.000-07:00

Since pretty much the start of my career as a developer back in the 1990s one skill I've carried from job-to-job has been an understanding of relational databases. Over the years I've worked with Foxpro, Access, Oracle, SQL Server, MySQL, Sqlite, and now PostGreSQL.

Interestingly enough, database normalization comes instinctively to me. I knew about complex SQL joins and unions and subqueries before I read anything about normalization. As I read up on normalization, it was rather exciting to discover that my natural instinct during database design was to hit the fourth or fifth normal form without thinking about it. And since for most of my pre-Python career the number of records I dealt with was measured in the tens of thousands, normalization was a great tool. I was aware that my record sets were smallish, and good database design kept my stuff running fast.

Relational Databases are not a panacea that lets you overcome bad code.

It surprises me how many developers I've encountered over the years who complained about the performance issues of normalized data but didn't understand normalization. Instead, they refused to follow any sort of standard and every table seemed to duplicate data and every query requires complex joins for trivial data calls. And usually with sets of records in the count of tens of thousands, not millions or billions. The end result are projects that were/are unmaintainable and slow, with or without normalization.

NoSQL is not a panacea that lets you overcome bad code.

Which brings me to the current state of things. NoSQL is a big thing, with advantages of NoSQL being touted in the arenas of speed, reliability, flexible architecture, avoidance of Object relational impedance mismatch, and just plain ease of development. I've spent a year spinning an XML database stapled on top of MS SQL Server, years using ZODB, and about a woefully short time working on MongoDB projects. Like relational databases, the sad truth about XML, ZODB, and MongoDB is that there are problems. And just as with relational databases, the worst of it stemmed not from any issues with data systems, but developers and engineers. Like any other tool you can make terrible mistakes that lead to unmaintainable projects.

So for now, like most of the developers I know, what I like to do is as follows:

Create a well-normalized database preferably using PostGreSQL.
Cache predicted slowdown areas in Redis.
Use data analysis to spot database bottlenecks and break normalization via specific non-normalized tables.
Use a queue system like Celery or even chronjobs to populate the non-normalized table so the user never sees anything slow.
Cache the results of queries against the specific non-normalized tables in Redis.

The end result is something with the rigidity of a relational database but with the delivery speed of a key/value database. Since I work a lot in Django this means I get the advantage of most of the Django Packages ecosystem (at this time you lose much of the ecosphere if you go pure NoSQL). You can do the same in Pyramid, Rails, or whatever. Maybe its a bit conservative, but it works just fine.

I'm going to Pycon Australia!

2011-06-29T02:14:00.000-07:00

I'm flying across the pacific! To a new continent!! To Sydney, Australia!!!

Okay, take a deep breath...

My girlfriend, Audrey Roy, is going to be giving a keynote speech at Pycon Australia. I'm going with her because, well, we travel everywhere together. To make the trip even more awesome, there was some last minute room in the schedule and the organizers of the conference offered me a speaking slot.

When and where will we be?

Pycon Australia will be from August 20th and 21st, with sprints the 22nd and 23rd, all at the Sydney Masonic Center at 66 Goulburn Street. Register and hang out with us!

What will we be presenting on?

Audrey's keynote is still in the works.

As for me, I'll be giving the new and improved version of my (in)famous Confessions of Joe Developer talk, of which the 'old slides' are here. You'll get to hear me confess about my shortcomings in public and in return I'll pass on tricks I've learned to convince people to believe that I know what I'm doing.

What will we be sprinting on?

I'll be leading the sprint on Packaginator, the framework behind Django Packages. The goal will be to finally launch Python Packages. Python Packages won't replace PyPI, it will simply provide a new window into what our wonderful Python community has produced. And I'm excited to work have our wonderful host, Richard Jones, as a resource for questions about PyPI API questions and systems sure to arise.

Audrey has told me she may assume her role as co-lead of Packaginator or work on another one of her great ideas (she created the idea for Django Packages - I just tagged along).

Will Pyladies host a workshop or hackathon in Sydney?

Audrey tells me there has been some interest from the Australian Python community in running a Pyladies event around Pycon Australia. She's put out a call-to-action and wants to do something the day before or the day after Pycon Australia. Please contact Audrey at audreyr@pyladies.com if you want to know more or volunteer.

Please come and say hi!

There will be lots of people there, and I'm asking everyone in greater Australia and nearby nations and planets interested in Python to register and meet us!

Hollywood Hackathon Report

2011-06-28T09:39:00.000-07:00

A few weeks ago, specifically June 18, 2011, two Python groups, Pyladies LA (since they are now global) and the local Southern California Python Interest Group joined forces with Border Stylo to put on hopefully the first of what I have styled the 'Hollywood Hackathon'.

Anyway, let's get down to some serious business. The event was exciting, eye opening, and I hope it happens again.

So why was this event special?

Out of the 55 local attendees, about 60% were female. Both genders had a wide range of skill levels and interests.
30 more people participated from around the world.
Numerous attendees, male and female, contributed to open source for the first time.
The waiting list for tickets was long.
The PSF and Python Sprints jumped at the chance to help out.
Code got submitted to various open source projects built using stuff like Python, Django, Pyramid, Bottle, Learn Python the Hard Way, and more.
The turnout was awesome. Imagine if there had been months of lead time and a dedicated conference site? Pyladies Con anyone?

What I did at the event

I did what I could to help set things up, presented at the end, and gave Python advice to those who needed it. Most of my Python advice was helping those stuck on setting up their system or trying to find a particular module to do a task.

The best thing about helping out people at an event like this is that people start figuring out things themselves. Yeah, you help them, but they do the thinking and they do the coding. All you do is provide that initial little bit of help and then they go off and make their world better. How cool is that?

Raise your hand!

I'm guilty of this too, that I don't want to feel stupid by asking questions.

This is crazy!

If you ever come to an event like this, where a dozen people are giving their free time to walk around to mentor, then raise your hand. Otherwise it is by luck that someone will help you. Maybe we'll see you stuck on the same few lines of code or maybe we'll hear you curse exclaim in frustration. Or maybe mentors won't see you in trouble and you'll never get help.

So please, if you have any questions or problems, don't hesitate to raise your hand!

Closing bits

I have some advanced notice that the Pyladies organizers (regardless of opinion I am not a Pyladies organizer) is putting together a kit so you can open up a Pyladies club in your city. Yup, they are going global and I'll be helping spread that message in a future blog post.

If you wan to know more about what happened, Pyladies has an excellent writeup.

The Future of Python is women making up 50% or more of the community

Do not upload dev releases at PyPI

2011-06-25T15:48:00.000-07:00

In my last blog post I mentioned that the plan was to release the django-uni-form 0.8.0 final in about six days. To my chagrin I was pointed at Tarek Ziade's post about not publishing beta releases on PyPI. So the django-uni-form team has now pushed up the 0.8.0 release of the library today, and removed the BETA from discovery via the web or pip.

Lesson learned: Until future notice from the distutils2 effort led by Tarek, if you are running a project that has any Stable releases, don't use PyPI to publish non-final versions.

Announcing django-uni-form 0.8.0 beta!

2011-06-24T14:04:00.000-07:00

This has been a long time coming, but I am pleased to announce the release of the django-uni-form 0.8.0 beta. We plan to release the 0.8.0 final next Friday around the start of July 2011.

This is an enormous jump forward in the project, and I think you'll like what has been done and who contributed.

Some notable changes

As of this release, there is now a formal django-uni-form release on PyPI that fully supports Django CSRF tokens.
Better error messages to help you debug. No more annoying Null messages on bad helpers!
The Python code has been carefully cleaned and optimized. Much easier to read, debug, and it plain runs faster on form heavy sites.
Various improvements to the templates to better match the parent Uni-Form library.
Only compatible with Django 1.2 or higher and Python 2.6 or higher. If you need something to work with other earlier versions of Django/Python, then I suggest using django-uni-form 0.7.0. Or better yet, upgrade your site!
Much improved documentation on the awesome readthedocs.org site.
Tons of other things!
Upcoming faster release cycles. More on that in the next section...

Leadership change for django-uni-form

Let's face it, over a year between releases is too long for any active open source project. I haven't done the incredible (and patient) django-uni-form community justice in supporting their issues and pull requests. This project has needed a much more active lead for some time. Fortunately, I found a new project in the way of Miguel Araujo.

Miguel Araujo shares my passion for good form generation and has a very deep understanding of Python, Django, and HTML. Also, his decisions on everything about this project either matches my own thoughts or he's been able to easily convince me why his concepts are sound. He is responsive to pull requests and issues, and his work is of high quality. So we should be seeing lots of releases and a better evolution of the system to match other advancements in the Django community.

So going forward Miguel will be the project lead for django-uni-form, and I'll be 'former project lead' and 'documentation donkey'.

The future of django-uni-form in the face of the forms refactor

Some people are wondering what place django-uni-form has in the face of the Django GSOC forms refactor by Greg Mullegger. Is the need for django-uni-form going away?

First of all, I actually have been pushing for a forms refactor in Django for some time. At the djangocon.us 2010 sprints Russel Keith-McGee, Django core developer and DSF president, asked my opinion on the design of a forms refactor. For the GSOC effort, I was delighted that the GSOC forms project followed the opinion that I preferred in how to doing things, and so I put in my non-binding vote for Gregor's approach. I'm rooting for you Gregor!

Second, while I think that while this library may change a bit to accomodate the eventual integration of Gregor's work, the need to be able to do guaranteed working Section 508 compliant layouts easily and more importantly make fancy layout changes in Python will keep this library alive and useful for a long time coming.

Whither goes the source code?

Finally, we'll be keeping the repo at https://github.com/pydanny/django-uni-form for the 0.8.x series so we have time to properly warn the community. When the forms refactor hits Django (prompting the necessary release of the 0.9.x series) we may be moving the library to its own github account.

Conclusion

I want to thank all the contributors, users, and anyone who gave me guidance or suggestions for this project. All the credit for this goes to you. I'm honored to have started something used by so many great people in so many wonderful ways.

This evolved from a Django beginner's shortcut filter to a rather sizable project with a great community. Due to my support of this project I learned git-scm, setuptools, JQuery, Sphinx, custom Django filters and templatetags, and more. I look forward to where it will go in the future with Miguel as lead.

Hollywood Hackathon on June 18th!

2011-06-12T01:31:00.000-07:00

Alas, that isn't the formal name of the event, but I'm calling it that anyway. That name just rolls off the tongue, and just seems to embody my East Coast style distorted vision of the Los Angeles Python community.

Anyway, this is a day long event in Hollywood for Python developers of all skill levels to come and code like fiends with either really smart people or nice people like me. The PyLadies and SoCal Piggies are organizing this event, and they even got some PSF funding for things like tables, chairs, and t-shirts.

Which reminds me, please encourage the smart women of all ages in your life to attend! We'll have mentors just for them!

I'll be there to:

Help out as a general volunteer by setting up tables, manning registration, and answering questions.
Assist a few friends on their open source projects.
Work on the new Python LA website (powered by Pyramid).
Finish the documentation of django-uni-form 0.8.0 if it isn't yet done.
Maybe close some Packaginator tickets and pull requests.

And now to open the floor to questions...

I'm just starting with Python, should I come?

Heck yeah! Hackathons (and sprints) are a great way to learn new skills or hone your technique by sitting alongside experienced developers who actually need your help. A lot of projects have what are called 'low hanging fruit', which are 'simpler' tasks saved for beginner developers to wet their teeth on.

Things I've learned at events like these include Git, Mercurial, JQuery, and a hundred other things that have made me a better coder.

What if I don't have a project of my own to bring? Should I come?

Heck yeah! There will be a number of projects around that you can join and contribute to in order to make the world a better place. There isn't a list up yet, but I'm hoping by Saturday there will be one.

What if I want to come and recruit people?

Absolutely not. This is not a job fair and we don't want unnecessary distractions.

What should I bring?

Your own functioning laptop with power cord.

How much does it cost and where do I register?

The event will put you back a measly $15 and that covers food and drinks for the day. Registration is here.

Python HTTP Requests for Humans

2011-05-26T05:40:00.000-07:00

Ever try to use Python's standard library for doing a POST? Or a GET, PUT, or DELETE? What about when you have to deal with HTTP Basic Auth?

In a word, ugh.

Let's face it, this is one part of Python that is really not for human consumption. While there are a million things you can do with things like urllib, urllib2, socket, urlparse, the fact of the matter is that implementing anything beyond urllib.urlopen() is a matter of diving into arcane APIs.

Sure, thanks to works like Doug Hellmann's Python Module of the Week and Michael Foord's documentation of urllib2 the problem isn't unsurmountable. Unfortunately, the eclectic mix of libraries and weird APIs means when you have to revisit your code in a few months your code feels like spaghetti.

Do you doubt me?

# This sample gleefully taken from https://gist.github.com/973705

import urllib2

gh_url = 'https://api.github.com'
gh_user= 'user'
gh_pass = 'pass'

req = urllib2.Request(gh_url)

password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm()
password_manager.add_password(None, gh_url, gh_user, gh_pass)

auth_manager = urllib2.HTTPBasicAuthHandler(password_manager)
opener = urllib2.build_opener(auth_manager)

urllib2.install_opener(opener)

handler = urllib2.urlopen(req)

print handler.getcode()
print handler.headers.getheader('content-type')

# ------
# 200
# 'application/json'

Really?

This much code to make a simple HTTP GET request with some auth?!?

Really?!?

This is a debugging nightmare! Especially when you have to deal with complex service APIs provided by Paypal, Amazon, Google, Authorize.net, and a million other systems.

I bet I could earn a decent living by charging Pythonistas a buck each time they took the shortcut of doing HTTP actions in the shell via curl or wget.

Anyway, wouldn't it be great if we could just call a single function with the URL and auth data as parameters? And that the same dialogue would exist for GET, POST, PUT, DELETE or whatever? Wouldn't that be just plain wonderful? If only we could have that functionality in Python!!!

Fortunately for us, we do have that functionality courtesy of Kenneth Reitz's Requests library! Our verbose code sample above becomes the wonderfully terse and easy-to-memorize script as shown below:

# This sample joyfully taken from https://gist.github.com/973705

import requests

r = requests.get('https://api.github.com', auth=('user', 'pass'))

print r.status_code
print r.headers['content-type']

# ------
# 200
# 'application/json'

Want to do a post with data? Try this:

# This example cooked up by me!

import requests
post_data = {"amount":10000, "service":"writing blog posts"}

r = requests.post('http://example.com/api', post_data, auth=('user', 'pass'))

print r.status_code
print r.headers['content-type']

# ------
# 200
# 'application/json'

The Requests library is still young, but I've yet to run into any bugs or undocumented edge cases. The documentation is awesome, but you don't really need it at all. The library is intuitive, fun, and and there is clearly one way to do.

I love this girl!

2011-05-23T14:01:00.000-07:00

In every person's life there are those incredibly memorable experiences that stick with you forever. The entirety of PyCon 2010 is for me that experience. You see, PyCon 2010 saw me introduced to the lovely, talented, and brilliant Audrey Roy.

Moments after I heard her lovely voice for the first time, we looked into each other's eyes. After that moment, I spent every waking moment of the conference finding excuses to spend time with her. Fortunately for me, most of her tastes for talks and social events matched my own. Within days we were dancing in each other's arms.

By the end of the PyCon we both knew we had something special. So after the conference we both flew back and forth across the country every two weeks for months to keep seeing each other. My phone bill skyrocketed. I became intimately familiar with Skype. It was crazy and magnificent. Finally, on May 5th of 2010 I moved out West to be with her for good.

Audrey may seem shy at first, but she has a fierce heart (FYI, she played Ice Hockey for years and did the bargaining for my car). She has a degree in Electrical Engineering and Computer Science from MIT. She supports me in everything I want to do. If you enjoy Django Packages and follow Open Comparison, she came up with the idea. We cook and eat healthy, and besides our differences on seafood/mac-and-cheese we are a food match. She loves my family and they adore her. She is a talented visual artist in any medium she attempts. As a developer, she learns unbelievably fast and produces high quality code in languages such as Python, C++, JavaScript, Objective-C, and anything else she touches. She hacks the Linux kernel so she can use her preferred peripherals. Her role in the technical community continually grows, and recently she launched the PyLadies advocacy group.

Airborne girlfriend!

An incredible thing about Audrey is that she makes me a better person. I didn't see this at first, but my good friend and mentor Steve Holden pointed it out. She doesn't just bring me joy, she makes me a more tenacious, honest, and compassionate person.

Life is never perfect, but thanks to Audrey and the Python community that brought us together, life is just plain good.

A couple great Pycon 2011 Talks

2011-05-19T00:01:00.000-07:00

Yes, this should have been posted months ago... Anyway, so many great talks at PyCon 2011, here are two great ones! Being an eternal beginner, I try to hit both entry level and advanced talks.

How to write obfuscated Python
Why waste your time with one decorator when 10 of them attached to a function, each named as descriptively as 'X' or 'G' will make your code delightfully hard to interpret? Also included such goodies as 'object = str' which I borrowed for my own Python Worst Practices. In my opinion, Reverend Johnny Healy gave the funniest and obscure talk of the conference, and yet somehow managed to export some useful knowledge in the process.

The Data Structures of Python
Alex Gaynor gave a great 'beginner' talk here. As he went over the basic types in Python, and while he presented well, I wondered if this talk was for me. My hubris was that I thought the talk was beneath me. Then Alex dove into some more sophisticated material like namedtuples and collections and yet again I was reminded how periodically going over the 'basics' is a good thing. Alex kept his talk to a reasonable pace, giving enough time for people to take notes and truly understand what he was teaching. If the whole crazy programming thing doesn't work out for him, he might want to consider becoming an educator.

We won first place at Startup Camp LA!

2011-04-25T16:16:00.000-07:00

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 meetup.com 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.

Development

"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:

Python
Django
Ubuntu
PostGreSQL
JQuery
Blueprint CSS
Apache HTTP Server
Tropo (commercial SMS messaging with free dev accounts and developer friendly API)

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 Packages, Packaginator, 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.

I teach Python and Django

2011-04-22T09:22:00.000-07:00

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 NASA, RevSys 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.

How NOT to interview Pythonistas

2011-04-17T09:26:00.000-07:00

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

Are you looking for Python and Django Work?

2011-04-09T07:30:00.000-07:00

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

2011-04-06T10:28:00.000-07:00

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:

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:

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

2011-04-05T10:23:00.000-07:00

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!

2011-04-01T00:01:00.000-07:00

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

2011-03-24T20:58:00.000-07:00

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!

2011-03-24T11:18:00.000-07:00

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!

2011-03-08T16:32:00.000-08:00

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?

My tips for speaking

2011-02-25T23:00:00.000-08:00

I've been presenting on the job since 1999. I've been presenting at conferences since autumn of 2008. I've got some tricks I've picked up over the years. I'll be using these tricks (and more) at PyCon, so you'll be able to see and judge them in action.

Black text on white background

Remember the old days of Geocities when people had purple backgrounds with yellow text? Or dark green backgrounds with white text? Or crazy fonts? We make fun of that sort of thing now. Unfortunately, I've seen presentations done that way in the recent past and so have you.

Yup, background colors that look great on a laptop or monitor screen often lose something in the transition to a projector. You can't predict what the venue will give you in regards to quality/brand of projector, so why take unnecessary risks?

So I stick with the classic of what people have been doing forever. I choose the lightest possible background, the darkest colored text, and I use the default font of the slide software. Maybe its not fancy or artistic, but my message isn't obfuscated by forcing people to squint to see slides reinforcing what I'm saying.

Fear the command line!

The sucky thing about giving a tutorial is that you have to touch the command-line. And something invariably goes wrong. If you do have to use the command-line remember the following tips:

White background and black text and increase the size of the text. I don't care if you prefer to code with a black background with tiny green letters - your audience simply won't be able to follow you as easily. Since I heard a Walt Disney Animation Studios technical lead have the same opinion, I now feel empowered enough to complain after any talk featuring an unreadable shell.

Try to fake the command-line. I've heard player piano is a great tool for doing that and will save you from that minute of silence when you try to figure out what you did wrong.

Don't read the slides to the audience

Listening to someone read the content off a slide is dull. I try to say anything BUT what is on the slide. When I do it speak the content of a slide exactly its because I'm purposefully breaking my pattern to make a point. Or to be silly because I'm getting tense.

What you should be doing is using the slides to remind yourself of your next point. Think of them as notes for your speech, not the speech itself

Bullets are dangerous

Bullets are live ammunition. Even in small quantities they can kill a talk. They can put an audience to sleep, cause them to start checking twitter, or even leave. So I use bullets very sparingly in presentations (classes can be different) because of their potency. Because of their inherent silliness I tend to use bullets in self-deprecating humor.

A better tactic than bullets is to create a subject header on a number of slides and put a single bullet under that subject header. So instead of one (1) slide about 'Python' with bullets of 'Monty', 'Guido', and 'Spam', I like to have three (3) slides each with a header of 'Python' and the content simply being 'Monty', 'Guido', and 'Spam'.

Sixty seconds per slide

If you wait too long your slide will become boring to the audience and their brains will drift. This ties right into the problem with bullets. Keep things moving along.

Be rested, fed, and sober for your talk

Skip the late night party and get a good night's rest. The day of the talk eat food that makes you feel physically better.

In January I went to a talk where the speaker was presenting on a technical matter with beer in hand. Maybe he thought it was hip, but his talk sucked. He got out of sync with his slides and stumbled around his own thoughts. Not only was the talk of poor quality but it was disrespectful of the speaker.

Needless to say, the audience was very grumbly about the 45 minutes they wasted.

That was a terrible shame because his slides were pretty good. I bet if he had been sober that talk would have rocked.

If people ask questions during the talk, ask them to wait until the end

They'll break your pace, rhythm, and timing. If they can't wait until the end then they now fall under my definition of heckler and are not worth answering anyway.

Be nice to people who come up to you after a talk

You never know who is that new person who comes up to you. Maybe they are planning to blog about you or write about you in the press. Maybe they are a possible business or job lead. Maybe they are someone who wants to throw a gajillion dollars at you. Be nice to them and you'll find out. Try to find time to talk to everyone, even if for just a minute each.

My Django tutorial at PyCon

2011-02-17T11:21:00.000-08:00

Working on my tutorial slides for my PyCon class/tutorial/workshop last night I suddenly came to a stark realization.

Out of dozens of slides, only 5 of them are Pinax specific.

o.O

I think this is because the slides are a condensed version of what the best and brightest in the Django and Python community think are good practices and tools. What do I mean?

Jacob Kaplan-Moss on matching best practices with incredible documentation and tests.
James Bennett on using small apps rather than monolithic ones.
James Tauber and Brian Rosner's code in Pinax which taught me and so many others incredible Django tricks.
PEP-8
Zen of Python
Mark Ramm on well, nearly everything but especially his critical commentaries on Django.

So what does this mean?

Well, I've been rethinking the mantra "Pinax is Django". It is hard to say that when users of django-cms and satchmoproject and other frameworks can't use core Pinax components. That said, users of those tools tend to rely on same foundation: Python, Django, virtualenv, and pip and growing ecosphere of Django Packages.

Which leads me to realize that with just 5 slides pertaining to Pinax material in the tutorial, the Pinax Solutions class could be renamed "Django Solutions class with a bit of Pinax".

And this makes a lot of sense. Some of the bits that made Pinax special such as static media handling are now part of Django as of the forthcoming 1.3 release. Lessons learned from Django Uni-Form which grew out of supporting div-based forms in Pinax are helping determine the path of forms work in Django 1.4. Which means that if you are using django-cms or other CMS, django-shop or other e-commerce tools, then you are benefitting from what Pinax has done for the community.

All of this leads to my closing statements about the class/workshop: The class is about Django with a little bit of Pinax tossed in. Having in the past worked with multiple non-Pinax projects, I can assure you that the solutions presented and the workshop itself will be of use to you regardless of if your project is using that framework.

My Pinax Solutions class at Pycon 2011

2011-02-14T09:38:00.000-08:00

Heavily inspired by Zed Shaw's Learn Python the Hard Way class I'm changing the lecture style format of the Pinax Solutions class at PyCon 2011 to a more workshop-oriented format.

Which means that the first half of the class we (myself and the peerless Brian Rosner) will spend on material critical for people new to Pinax or old hands who want to see what 0.9 offers. That means setting things up via virtualenv and pip, Pinax specific settings, media handling, template layout, extending core Pinax apps, use of idios to change profiles, openid/openauth, Django Packages to find Pinax approved stuff and more. That will be the foundation and our slides/handouts will be useful as cheat sheets for these critical parts in any Django application.

The second half of the class will be a workshop. We'll spend the next half helping people with their personal projects, and will even have a few stock projects we can toss at people that either already are open source or could be released as open source. We won't write your project for you, but we will provide advice, guidance, and some elbow grease in getting things to work. If someone asks for something that we think the rest of the class could benefit from, we'll show them how to do it on the projector and then everyone benefits.

After the class, I'm free the rest of the day so I'll continue helping people even after the tutorial is officially over. Thursday (March 10th, 2011) after lunch I'll be also available to provide aid and support. Anyone else can join but those who attended the Pinax Solutions tutorial will get precedence.

During the main body of the conference I'll be attending talks and giving a couple myself so my time to provide aid will likely be completely curtailed.

I will be there at the sprints working on various Pinax and Django projects.

If time permits we'll go over deployment, but I recommend Jacob Kaplan-Moss' Python/Django Deployment Workshop if you want a full treatment of the subject.

Note I: If you've already signed up for the Pinax Solutions tutorial, you should be getting an email from the PyCon tutorial staff shortly.

Note II: If you are new to Python, I recommend that you take any of the basic Python tutorials at PyCon instead of this class.

How to sell Python panel at Pycon

2011-02-12T13:58:00.000-08:00

Do you want to use Python but are you fighting Fear, Uncertainty, and Doubt (FUD) in your organization? Does any of this sound familiar to you?

Python is just a scripting language.
Python is too new to use in real production environments.
Language X has better benchmarks doing obscure math so it is better for web development.
Python sounds great but we've already spent so much on this expensive tool that does things badly!

A lot of people want to use Python, but their customer, management, school, government, or organization won't let them. Python is a great tool, but can be challenging to get in the door. This panel will explore how companies and individuals have successfully introduced Python, what tools are available to sell Python, how to fight the good fight, and what pitfalls there are to avoid.

Panel Questions
For this event at Pycon I've got some stock questions ready but I want the community at large to suggest some more.

Speakers
For this panel I choose five speakers from the broad categories of academia, government, commercial organizations, and non-profit who have had a known impact in their organizations:

Academia
C. Titus Brown is an Open source hacker, Artificial Life/Digital Evolution, B.A. Math (Reed), Earthshine research, Ph.D. Developmental Biology and Regulatory genomics (Caltech), Python testing tools, Python Software Foundation member, Assistant Professor (Michigan State U.) - dev bio, genomics, metagenomics, software engineering.

Note: A lot of my personal understanding on how to do web tests outside of Selenium is thanks to a Pycon tutorial given by Dr. Brown and Grig Gheorghiu back in 2008.

Government
Chris Shenton is a partner at Koansys LLC, a consulting company whose clients include US Federal Government agencies, Internet startups, and non-profit organizations. He is a free software and UNIX bigot, advocating for the use of both in organizations large and small. He's been involved with the Washington DC area's Python/Zope/Plone user group ZPUGDC for years, and recently was appointed to its board.

Note: Chris has the dubious honor of introducing me to Python in 2005 and was pivotal in promoting the adoption of Python for use in NASA's Science Mission Directorate.

Large BusinessThe Vice President of Engineering at Evite/IAC, Dan Mesh is the person credited by other Evite staff with bringing Python to life in that business.

We used Evite for our just passed LA area hackathon and plan to use it for future events.

Non-Profit Organizations
Rich Leland is an Application Architect at National Geographic where he uses Python on a daily basis to work on nationalgeographic.com and its ecosystem of web sites. He is also the founder of django-district, a group for Django users in the Washington, DC area. In the past life he worked for Discovery Channel as Designer and Lead Web Developer.

Small Business
Frank Wiles is President of Revolution Systems, Lawrence, KS. Expert in Internet infrastructure scaling and performance. Primarily focused on Django and PostgreSQL.

Note: I credit Frank with providing me with a great opportunity to work with an awesome code base but also the encouragement and support to get me through my first year as a freelance consultant.

What I want for Django Facebook connect

2011-01-31T15:11:00.000-08:00

For a customer I need to do Facebook authentication on a new Django project. I went to the Django Packages Facebook Authentication Grid and figured I would plug it in, set some keys, and go! Facebook authentication is a common client requirement, and this must have been solved many times over, right?

Unfortunately, most (I'm still going through them) of the listed packages worry me. Security is HARD. Security is DANGEROUS. Since Facebook auth is a common requirement I shouldn't be forced to roll my own authentication or hack through someone else's implementation to get things working.

Yet many of the packages listed in the grid above lack documentation or what exists is outdated. Some of them simply drop errors or seem to intentionally obfuscate them (I won't name anyone YET because I want to give people a chance to correct these issues). Finally, I've yet to find any with any sort of logging to help diagnose possible intrusions or just as a way to see what is happening when you have trouble hooking up things.

I understand that Facebook is a moving target. But on the other hand, shouldn't updates to these things be in place?

So what do I want in a Django app that does Facebook authentication?

Documentation that will build on readthedocs.org.
Use of the logging module for diagnosis.
Sample project with a working example of hitting a dummy app (call it stupid-test-for-pydanny if you like) on Facebook provided by the project manager.
Proper packaging on PyPI

In the spirit of things if your project does this I'm willing to try it out and blog about it. I'm also going to sprint on this issue during Saturday's Hackathon at Cartwheel HQ.

Los Angeles Open Source Hackathon

2011-01-25T19:37:00.000-08:00

I want to announce the launch of our new company which we've named Cartwheel! Besides Python and Django consulting, our plan is to support local Los Angeles small business, teach classes, and host events. And our first event is a Los Angeles Open Source Hackathon on February 5th! Space is limited so RSVP before tickets run out!

Open Source Hackathon at Cartwheel

A hackathon (or sprint if we want to be Pythonic) is where a bunch of developers get together to push various projects forward.

Bring your laptop and work on any open source project that you'd like, as long as it's open source. It can be an existing open source project (e.g. Django, Python) or a new one of your own. Leave the work stuff at work!

Got an existing project? Hackathons are a great place to share ideas and perhaps find additional contributors. Let me know and I'll put it in an additional blog post.

New to open source? A beginning developer? We'll help you get started with open source software development and do our best match you to a project that fits what you want to do.

Some projects that may be worked on:

Nudge: Evite's API tool is being open sourced!
django-packages: Integration with brabeion and bugfixes
django-uni-form FormWizard integration, documentation cleanup
Pinax django-tagging-rst 0.3.1 integration
tastypie adding oauth for authentication

Please RSVP as soon as possible. The $10 ($11.54 with fee) ticket price covers breakfast, lunch, and dinner. Costs are partially subsidized by Cartwheel. We hope you can join us!

Why you should go to Pycon

2011-01-20T09:31:00.000-08:00

Because you are new to Python
If you want to get better at Python then Pycon is one of the better avenues to learn. Think of it as a nine day data dump of Pythonic knowledge straight to your brain!

When it comes to the fundamentals of Python, the tutorials are a great way to hit the ground running. How do you think I learned? Also, there are dozens of beginner talks designed to introduce you what highly qualified people think you should be doing. Finally, the sprints are a great way to work with real experts for days - because even the most advanced projects needs people to knock out the invariable score of simple bugs, do documentation and write additional tests.

Also, Zed Shaw is going to teach his Learning Python the Hard Way tutorial throughout the conference. (follow that link!) To summarize, besides going over his lessons and some basic conference coaching, he's going to take his class to conference talks and then bring them back to apply what was learned. He won't be doing it alone either - a number of other python folk are going to volunteer their time to help, and I'm going to be one of them.

Because you are old to Python
A good chunk of the tutorials are designed specifically for experienced Pythonistas wishing to expand their knowledge (OMG Raymond Hettinger). And then as we all know the conference itself has scores of advanced talks designed to challenge you. Finally, what better place to work on your favorite project or get people to work on your project then the massive Pycon sprints ?

Want to do Python related technology full-time? What better place to look then where amazing companies and organizations hang out with the intention of hiring people? And invariably some of those hiring groups will be hosting parties too...

Because you are recruiting
Looking for good staff to do Python, Django, Plone, Pyramid, wxPython, NoSQL, Linux admin, Unix admin, BSD admin, Windows admin, Science, or Engineering work? Pycon will be where 1500 of the best and brightest people on the planet will hang out for over a week and some of them will be interested in new opportunities. Sponsorship is a great way to get yourself noticed by hundreds of Pythonistas.

Because it is cheap
Until January 25th Pycon registration is at its early bird prices. Even when it goes up it is still a pretty good deal. Admittedly the biggest expense is the hotel ($159/night) but there are decent and much cheaper hotels ($80/night last I checked) within a few blocks of the conference.

January Mongo LA conference

2011-01-15T08:13:00.000-08:00

Back in the mid-1990s my professional software development career started in relational databases. Periodically though I interacted with NoSQL databases. In 1999 I heard about ObjectStore. In 2003 I played with a few XML databases. With XML databases of the time, I found all you got out of them was a lot of complexity bolted onto a SQL based system. In 2006 I was introduced to ZODB, the Zope stack's object oriented database. ZODB has some fascinating traits, but the hard schemas used by Plone and Zope made it as rigid/stable as SQL systems but without as many useful tools. In 2008 I played a bit with Google's BigTable via appengine, where my impression was that of a relational database without indexes.

Since then, a lot of new NoSQL solutions that have embraced the idea of schema-less architectures have presented themselves. I've glanced at them but until recently nothing on my plate really justified their use and taking the time to learn how to use them. Recently I've come across a project that justifies the whole document store approach used in systems like MongoDB, CouchDB, and others. However, because users of NoSQL tend to be such heavy kool-aid drinkers, I've been a bit shy.

Well, last night Media Temple laid out an awesome spread for Mongo Los Angeles. The agenda was clearly a kool-aid fountain of information, but at least they weren't trying to sell me a timeshare, right? Plus, it gave me a chance to hang with awesome python folk like Audrey Roy and Brian Luft.

Most of the talks were will implemented, I've picked out two presentations out for being just plain well done:

Building your first MongoDB Application
Antoine Girbal delivered a talk that was a great, elegant introduction to MongoDB. In thirty minutes he gave a solid introduction to why Mongo was created, how the data is structured, how to call data, how to index it, and more. And yet it didn't feel like a firehose of information. This is how it should be done for any introduction to any open source project.

Beyond Logging: Using MongoDB to Power a Private Social Network
This was the pièce de résistance of the evening, a presentation on mating MongoDB with an existing relational database design. It was incredibly informative and demonstrated that with a bit of moderation and discipline you can make the very difficult rather easy. Plus the presenter, Justin Jenkins educates via learnmongo.com.

Have I drunk the kool-aid?
So what did I get out of these introductory talks? Well, it appears that MongoDB is exactly what I need for an upcoming Django project. The downside is that if I use MongoDB for all the persistence for this Django project then I lose the chief advantage of working with Django. I'm not talking about the admin and ORM themselves cause I know django-nonrel and mongoengine exists, I'm talking about the multitude of efforts that support the relational database roots of Django.

Also, this project involves quite a bit of information best stored in a relational database. Not everything is a document! And I know from a lot of experience that trying to fit a spiffy square peg into a round hole is dangerous. So what I'll probably do is use PostGreSQL for the accounting information and user management. The documents will be stored in MongoDB, with one of the indexes for said documents being on the username attribute of each document.

Simplicity itself, right?

Pinax Tutorial at Pycon 2011

2011-01-10T18:18:00.000-08:00

Tutorial Name: Pinax Solutions at Pycon 2011 (March 9th)

This year I am yet again part of a two man team providing instruction on Pinax at Pycon. Last year's Long Pinax Tutorial went well, with myself and James Tauber receiving a lot of positive feedback plus some really good constructive criticism.

Based off that criticism and our own experiences since last year's tutorial we decided to make some changes, specifically we wanted our class to be very solutions focused. Think of it as an organized brain dump of how best to start a project, leverage in the Pinax framework plus the rest of the Django ecosphere to do all that tedious make work we so dislike. Using these tools will let you focus on your project's unique attributes, meaning you get to focus on all the fun stuff!

Another big change to the class is that Brian Rosner will be taking over in James' place as co-presenter (last year he was instrumental in reviewing the content of the class). Brian is a Django core committer, a Pinax core developer, the tech lead of Eldarion, and the steward of Gondor. If you like how the current Django admin works, you can thank him for his hard work. Even if he didn't have those credentials, Brian is a great speaker and really patient with questions. He started me on git back back at Pycon 2009 and has been kind to me the times I've screwed things up in git ever since.

The course itself will go over the 0.9 series of Pinax. You'll need a laptop with Python 2.6+ installed (Python 3.x won't work in Django). You should be familiar with Django and Python.

See you there!

I don't work in a vacuum

2011-01-06T11:17:00.000-08:00

Not too long ago I wrote a blog rant called 'Stupid Template Languages'. I suspected I was setting off a firestorm, but I have to admit I didn't quite expect to have the singular honor of having both Armin Ronacher and Mike Bayer respond to me in their own blogs. As one might say, "Danny, you really stepped into it."

My initial response to their entries was to start writing another post that would refute what they said point-by-point. However, while the tone in my original post was somewhat confrontational, the problem is that I didn't want to turn the debate into a sordid affair with drawn sides. You see, I've long respected both Mike and Armin as developers and people. Even if I didn't care about them, all it would do is stir up angry retaliations and steer people away from good tools. So I linked to their responses, let it go, and I hope we can drink over the issue this year at Pycon.

However, if we step away from the tools, the real problem I was addressing in my post was this:

I don't work in a vacuum

Any tool has the potential for misuse. As Alex Gaynor pointed out in Django Dose, he is familiar with the poorly crafted system which was part of the reason why I wrote 'Stupid Template Languages'. Heck, anyone reading this blog has probably run into one of those nightmarish system created by others that we have to maintain, and many of us will sheepishly admit to having been the author of such systems.

When you create a system like that you are making things harder for others to contribute and enhance. Trivial tasks become monumental and the desire to post your sad story to The Daily WTF becomes very strong.

Don't work in a vacuum

There are the well-documented methods called 'best practices' that us programmers ought to follow in order to make our work more maintainable. In the general programming world, patterns like Model-View-Controller (MVC) is a common way to break up pieces of a project into predictable components. In the Python world, we generally follow a set of standards called 'pep-8' for writing our code. Various groups and organizations often have additional standards for naming, tests, and documentation styles.

Standards can be created without wisdom or consideration for real-world issues. Too many tests and documentation can eat up time on a project and cause interminable delays; there are horror stories about developers writing pages of non-technical material in order to produce a single line of working code.

Following these methods and doing so with wisdom is like striving for a platonic ideal. It is both gratifying and time consuming to reach for perfection - and this perfection is fleeting because of the shifting requirements of clients, operating systems, and tool changes. To attempt to reach for this helps a person be considered a good developer, but doesn't guarantee that they are actually good.

Breaking the rules

Sometimes you have to abandon best practices. Sometimes the tool at hand makes it hard to perform a task without breaking the rules. In the python world a good example is monkey-patching, which we do with trepidation. In the relational database world, people with a deep understanding of normalization will sometimes indulge in de-normalization in order to boost performance.

Unlike best practices, there is no platonic ideal that clearly states when breaking the rules is a good thing. Ever seen a database created by a developer without any knowledge of normalization who smugly says their database is better because it started off de-normalized? How many of us have seen views where control and persistence is integrally embedded? Or where views are embedded in control code?

In regards to the debate that triggered this post, I've read the following phrase a few times as an argument against my rant: "We're all consenting adults here".

Does that mean we can do what we want? That we can write spaghetti code?

Certainly most people reading this post will know that statement generally refers to variable handling in Python, not the right to sunder the rules of good coding practices. Yet I've seen people use that as a mantra to ignore any sense of good coding practices for python related projects. Which meant that the level of effort to maintain and expand those projects increased at the same rapid rate that the bus factor decreased.

Conclusion

I'll just throw out some well known platitudes:

Code like you aren't in a vacuum.
Break the rules only when you have a concrete reason.
Learn to take criticism well.

Resolutions for 2011

2010-12-30T22:04:00.000-08:00

Travel to Europe again.
Travel to Asia or Africa.
Visit a Disney park.
~~See a place in the USA I've never been.~~
Drop the waist size 2 inches and not break any bones.
~~Go to Pycon and present or teach.~~
~~Go to DjangoCon and present or teach.~~
~~Present at LA Django~~
~~Continue my Muay Thai and Capoeira studies~~, get back into Eskrima, learn some more BJJ, and ~~practice the forms I know.~~
Work out at least three times a week.
Go back east and teach martial arts for a day.
~~Finish some outstanding legal proceedings.~~
~~Launch a site that does cool stuff and somehow brings in money.~~
Get to the point with LISP where I can do cool stuff in it without needing a textbook.
Blog once a week. That is at least 52 blog entries!
~~Explain why I wrote Diversity Rocks.~~

Recap of 2010

2010-12-30T13:52:00.000-08:00

This has been an unforgettable year. I can't believe all this stuff happened. I've moved many times, met wonderful people, and seen my life change in ways I could have never predicted.

The good:

Met a whole new bunch of wonderful people - relationships to last a lifetime. Arthur, Audrey, Celso, Cody, Daniel, Jacob, Jeff, Lahn, Moriah, Skyler, Todd and others I'm certainly forgetting to my undying shame. Thanks for your awesomeness!
Presented and taught at Pycon 2010.
Had a blast in the blizzard of 2010.
Prepped my house of 9 years for sale and sold it.
Paid off my debts. I sleep so much better now.
Left NASA after 5 years and 3 months for freelancing pastures. Thanks Eldarion LLC, Revsys LLC, Holdenweb LLC, and Bryan Klein. Being exposed to some of the incredible code and developers on these projects has made me a better developer. Show me more!
Flew enough in the spring to put me ahead of notorious traveller James Tauber for about 2 months in sheer mileage accumulated.
Got to reconnect with a cousin and met his lovely wife and handsome son. Also hung out with my Uncle Al and Aunt Sandra.
Got a tour of Ames Research Center thanks to Michael Sims. He'll probably be presenting at Pycon!
Attended another NASA wedding by Mark and Ariel.
Took a cruise to Mexico on a ship that caught fire just months later.
Said goodbye to Virginia and moved to Lawrence, Kansas to run with the unicorns and 5 months later to Los Angeles, California.
Road tripped across the Western half of the country! Twice! Spent 3 days in Las Vegas over Halloween!
Learned fundamentals of Capoeira from Celso Wills. Wish I could learn more from him. :(
Learned how to drive and bought my first car.
Worked on another course for Holdenweb LLC.
Launched Django Packages.
Presented at DjangoCon 2010.
Started Muay Thai classes in Los Angeles. I've done quite a bit of it, but these were the first regular classes I've had in about 16 years.
Brought my son to Los Angeles so I could spend a week with him for the first time in 15 months.
Almost up to 7 years without a broken bone!
Worked another year in Python related technologies.
Started learning LISP and played a lot more with JavaScript (especially JQuery and JQuery UI).

The bad:

Left my students in Virginia. The young ones were especially hard to let go.
Had to say goodbye to friends in the DC area. Some people I'll miss are Alex, Beth, Brandon, Chris, Dave, Daye, Eric, Jim, Joe, Katie, Muhammed, Pilar, Rich, Renee, Ron, Sarah, Sebastion, Shawn, Steve, and Whitney. I know I'm missing some names!
I'm far from all my immediate family: Carla, Ciana, Dad, Doug, Michele, Midori, Mom, Seth, and Timiri.
Watched NOVA Django falter after I left the DC area.
Had to wait 15 months between spending more than a day or so with my son.
Didn't really practice much Eskrima all year.
Didn't blog enough. Last year I blogged almost twice as much!
Frustratingly, haven't been able to finish something that prevents me from writing about certain things. Yes, this is quite vague, and my hope is to clarify it in a few weeks.

2010 Resolution Summary

2010-12-30T13:12:00.000-08:00

Items that are crossed out are completed.

~~Sell the house, pay off the remainders of my debts, and get my own place to stay. And get a car too.~~

~~Travel to another country.~~

Take my son to another country.

Drop the waist size 2 inches ~~and not break any bones~~.

~~Go to an amusement park, visit the beach, and also see a part of the USA I've never been.~~

~~Do more educational work for Python related technologies~~, and that includes getting the Django Education Foundation really rolling forwards.

Throw away at least half my current stuff. I don't have much stuff now, and I want even less. Also, If I don't use or interact with any one of my non-book remaining possessions by 2011, I'm throwing it away.

Move my blog to my own system and blog at least once a week.

Get a mountain bike and have reasons to use it.

Get back into Eskrima, focus more on BJJ, ~~get into Capoeira.~~

Hire a maid. I'm not messy, but I want someone to do the fine tuning of my place.

Go to ~~Pycon~~, ~~DjangoCon~~, and a new conference.

Have a beer with ~~Thomas~~, ~~Andy~~, Andy, Tony, Garrick, Bernd, and the rest of Ye Aulde Gange.

Reactions to "Stupid Template Languages"

2010-12-06T05:50:00.000-08:00

My blog post on Stupid Template Languages has had some excellently crafted responses by Armin Ronacher, Mike Bayer, and Steve Holden. I respect and admire each of these developers, and their combined projects have made a real impact on my career. I'm happy that our community is large enough to have a difference of opinion, delighted that our base language of Python allows us the power to play with different options so easily, and hope that we can debate our differences of opinion this year at PyCon. The first round of drinks are on me!

Response of Armin Ronacher, creator of Jinja2 and other projects
Response of Mike Bayer, creator of Mako and SQL Alchemy
Response of Steve Holden, Chairman of the Python Software Foundation and creator of PyCon

Stupid Template Languages

2010-12-03T05:57:00.000-08:00

For years I've been absolutely certain that I really prefer stupid template languages any time I'm generating HTML. The less the template language can do the better. Since I spend most of my time coding in Python you might assume this applies just to Python, but I think it also applies to anything where you have the power to readily mix HTML generation and code.

The biggest annoyance I have with smart template languages (Mako, Genshi, Jinja2, PHP, Perl, ColdFusion, etc) is that you have the capability to mix core business logic with your end views, hence violating the rules of Model-View-Controller architecture. While the web can be hard to match to MVC, in general you aren't supposed to do that sort of thing. I've made the mistake of putting core logic in the wrong places in the past, but I'm proud to say I've gotten good at avoiding that particular mistake.

I don't work in a vacuum.

I often work on projects crafted by others, some who decided for arcane/brilliant/idiotic reasons to mix the kernel of their applications in template function/macros. This is only possible in Smart Template Languages! If they were using a Stupid Template Language they would have been forced put their kernel code in a Python file where it applies, not in a template that was supposed to just render HTML or XML or plain text.

What it comes down to is that Smart Template Languages designers assume that developers are smart enough to avoid making this mistake. Stupid Template Languages designers assume that developers generally lack the discipline to avoid creating horrific atrocities that because of unnecessary complexity have a bus factor of 1.

So what is a Smart Template Language?

In my own vernacular, template languages that let you write functions/macros are what I call a Smart Template Language. Some of them are brilliantly executed, the example of Jinja2 comes to mind, but invariably I suffer through abuse of its Macro control structure as implemented by others.

Misery Cubed a.k.a. Genius Template Languages

Next comes Genius Template Languages, which take things a step further. These template languages allow you to not only define functions/macros, but also let you embed unrestricted Python (or Java or Ruby or whatever) in the template. This 'feature' lets you code your entire application in the templates! In the Python world what comes to mind is Mako and Genshi, but I'm sure there are many other tools with this 'capability'.

I like Stupid Template Languages!

Stupid Template Languages don't let you define functions/macros. They don't let you embed Python code. They barely let you define variables and often have simplistic control architectures.

For Django efforts, which is about 70% of my work, I like the Django Template Language (DTL). Since it is used by a huge community, there are a ton of useful apps which have it as a dependency. Switching away from it would mean cutting myself off from a large ecosphere of tools I can use to not reinvent the wheel.

Back in my Zope/Plone days I really, really enjoyed the Template Attribute Language (TAL) because it was stupid too. If I needed an XML generation template language and could import it easily I might consider using it again, or perhaps Chameleon, which is a new, improved version . The downside is that they come paired with another tool paired with it, METAL, which gave it macros. My own experience with METAL is that it was all too easy to do what we developers do with Smart Template Languages.

But DTL and TAL are slow!

So what?

If you want to boost your performance, first try caching. There are a ton of tools you can use, with Varnish being one I keep seeing in action. Read the docs on your favorite web framework's caching engine and apply what you learn. And Djangonauts should read up on Mike Malone as much as possible.

If after all that the site still delivers slow content and it appears to be a template language issue, then identify the bottleneck content and consider alternatives for that one portion. My favorite response is a bit of AJAX. Use your framework to render the content as JSON and have JavaScript parse it into legible content, a task which JQuery makes trivial.

Release classifiers in distutils/pypi

2010-11-06T15:26:00.000-07:00

Thanks to Doug Napoleone I'm now aware there is already a convention followed for the python and framework versions, but it appears that not enough people are aware of it. This post is pretty much a reposting of the second comment of the post immediately preceding this one and Doug gets full credit for this post. I'm just repeating his message:

The release classifiers in this post should be included in the standard distutils documentation. For the moment, you can see the full list of classifiers here:
http://pypi.python.org/pypi?%3Aaction=list_classifiers

For the python language version the classifier is:

Programming Language :: Python :: x.y.z

With each version on it's own line. That way you can browse the repository by python version (see the bottom of the page):

http://pypi.python.org/pypi?:action=browse&c=214

There is also support for frameworks which you can see on that page as well. There it is done with:

Framework :: Django :: x.y.z

There is Zope, Plone, and a number of other frameworks already there.

In the example you gave the proper, and supported way of writing the metadata is:

Programming Language :: Python
Programming Language :: Python :: 2.4
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Framework :: Django
Framework :: Django :: 0.96
Framework :: Django :: 1.0
Framework :: Django :: 1.1
Framework :: Django :: 1.2.1
Framework :: Django :: 1.3

Now it becomes a matter of education and illumination. This should be in the standard distutils documentation and arguably the home page of PyPI (or easily found there). And Django Packages will be supporting this functionality in the near future.

A request for new pypi classifiers

2010-11-06T12:34:00.000-07:00

This request is to help enhance Django Packages, PyPM Index, and other projects. This would also help the Python community at large.

Would it be possible that a standard be established for listing in PyPI classifiers which versions of a package is known to operate? Using James Bennett's django-registration at http://pypi.python.org/pypi/django-registration as an example (see my bolded, last two lines to understand what I'm trying to demonstrate):

Development Status :: 5 - Production/Stable
Environment :: Web Environment
Framework :: Django
Intended Audience :: Developers
License :: OSI Approved :: BSD License
Operating System :: OS Independent
Programming Language :: Python
Topic :: Utilities
Python Versions :: 2.4, 2.5, 2.6, 2.7
Django Versions :: 0.96, 1.0, 1.1, 1.2.1, 1.3

The metadata system I'm writing about in this blog post is specified on the distutils documentation page.

I picked a Django package but this could be for Zope, Pyramid, PyQT, or anything.

If we had something like this in place then people could quickly identify on PyPI and other resources if a tool can be of use to them or if it needs to be updated to the latest code base. If this already exists, then can someone point me at the existing specification so I can promote it?

Edit: Noah Kantrowitz suggested I take a look at the 'requires' keyword which is part of the distutils spec. However, this does not show up in the PyPI API (http://wiki.python.org/moin/PyPiXmlRpc) and so doesn't fit our needs.

DjangoCon 2010 report I

2010-09-21T19:16:00.000-07:00

The conference was like a family gathering except without any oddly weird uncles. To my utmost embarrassment I got overwhelmed a few times and forgot names of people I respect and admire.

If I went through people I got to touch base with, I would have to list three digits worth of people and play favorites. That just ain't me, so I'm just going to say everyone there was awesome and I hope to see you again at Pycon!

Alright then, some reporting:

Django Software Foundation Panel

Russel Keith-Magee, the new DSF president hosted a panel with Ben Slavin, Sean O'Conner, Jeremy Dunck, and myself. Russ went over plans for DSF finances and the hopeful creation of a DSF ecosphere of applications.

My own contribution was talking a little about Django Packages, and bit more about "Why Django".

Why Django, or maybe one day "Enterprise Djangoproject" is an advocacy site for Django targeted not to developers but to decision makers. It is a work in progress, we are collecting case studies and articles, and building out the site.

Ben Slavin then challenged me about the code and data. Other Django community projects like djangoapps and djangosites are closed source efforts without an API and this causes problems for the community. If a site goes down or is unmaintained then the community loses.

I agree.

So I promised that for these Django community projects the code is public, APIs were being made to support people fetching data from them at any time, and I'm trying to figure out how to do data dumps without handing out even salted passwords. Furthermore, I would give full access to these sites and servers behind them to those that Russell appointing to the position of being watchdog.

And I'm working on that promise. Django Packages now has an API and a BDFL has server access to Django Packages. Why Django is still a work in progress, so things are still in flux. I'll post updates to my promise of openness.

Furthermore, I challenge anyone who puts together a site useful to the community, be it a new version of Django Apps or Django Sites to follow my own promise. By all means maintain and work your project, but be willing to publish all data and keep your code under an open source license. Also provide access to whom the DSF president appoints so that others can provide maintenance for your site.

Eric Florenzano's Keynote

Eric Florenzano gave the keynote on What Sucks about Django (and how we can fix it). He did a very good job of it. Watch his talk. It has some amazingly telling points.

Anyways, I'm challenging for Eric to eat his own dogfood. The only people I saw Eric talk to were the same people he is always around and conferences. How many times did he go up to a person he didn't recognize and start talking to them? How many new people did he meet at DjangoCon 2010?

Portland Views, Food, and Beer

On Saturday, as a break, I went with Eric Holscher, Ben Firschman, and Andrew Godwin to the park around the Portland zoo. Below you can see where a lady pointed out that we could see mountains 50 and 150 miles away. That left three geeks speechless while
Ben Firschman captured the moment. This picture is Ben's and all rights belong to him.

And then I had my action shot taken by Ben. Again, all rights to him.

I just have to say that Ben is an amazing photographer and I'm honored to be in a few of his pictures of DjangoCon. In addition to that he presented on class based views in Django, which I plan to blog about as well as incorporate into Django Packages in the near future.

Edit: Blogspot is acting really oddly which is why I took out the linking and other things.

Edit II: Eric ate his own dog food. Awesome!

New features for Django Packages

2010-08-28T17:11:00.000-07:00

Since the Django Dash ended, the Django Packages team has been working to add new features and close out bugs.

"I Use This" added

Since we only want hard metrics on this site, we incorporated an "I Use This" button on the packages. This is so you can identify which packages you use. Please don't press this button for packages that you like, only the ones that are part of your coding efforts.

Added BitBucket support

We are still working out some of the kinks for coming up with stats from BitBucket. Most of the data we collect is fetched via the API, but a little is scraped off individual project pages.

Cache the commits

Originally the commit history was fetched live. But Github only provides the last 35 commits and BitBucket limits you to the last 50 commits. So now we store the commit history and update it nightly. Which means that the sooner you post your packages the better your commit history will look on Django Packages.

Rebuilt the package updater

Limitations on how many API calls you can make against Github (60 a minute) meant that we had to write some fun code to get around that problem. I think the problem is solved now, but I'm worried I might get to eat my words.

Added a help section

As much as we wanted a completely intuitive site, this will hopefully make it easier for people to figure out how to participate on the site.

Package Add/Edit form refactor

We completely rebuilt the Package add/edit form to make it easier to add packages. So far the response has been entirely positive.

Page cleanup and CSS Reset

We've been slowly cleaning up the HTML and resetting the CSS. Everything is looking prettier. Our goal is to make things more readable, so a lot of the changes are subtle.

Email verification works

It works, and now you get an email to confirm your account.

Django Dash Lessons Learned

2010-08-21T09:22:00.000-07:00

Our experience with Django Dash 2010 was that it was an wonderful exercise in classic Django development, cowboy/cowgirl coding, and drinking copious amounts of caffeinated beverages. The result, Django Packages, is something we are happy with, are continuing to improve, and hope will improve the community.

Lesson: Fixtures are a must

Django gives you this amazing Admin control panel. As soon as you get your models in place and are entering test data, start creating fixtures. For the dash we named them initial_data.json and loaded them into the individual app directories. This meant that every time we blew away the database we got a reload with records in place. Sometimes this means you have to hand-edit JSON (or YAML if you swing that way), but the alternative is to waste time re-entering the same data again and again. Don't forget to change the names of your test fixtures before you launch!

From the command-line how to save a fixture pydanny-style:

./manage.py dumpdata package > apps/packages/fixtures/initial_data.json

One nice thing about fixtures is that when you do have the time/need, you can use them to help you write tests. And it makes development easier for contributors.

Lesson: Research ahead of time

In the days before the contest, we researched to see if our target repos (Github, ;BitBucket, and Google Project Hosting) each had an API and a python library to speak to that API. Github has both an API and python library, Bitbucket has an API but no library. And as far as we can tell, Google Project Hosting lacks both API and library (someone please tell me I'm wrong about Google Project Hosting lacking an API).

This meant that when we commenced coding we knew which code base to work with - we weren't trying to look up this or that random package.

We did the same thing for rendering charts.

Lesson: Get it working then optimize

Looking at some of the code makes us wince a bit. But we got it working. Now we can go back and do some code cleanup, maybe use an XML parser instead of regex to try to scrape content from PyPI, and generally feel better about ourselves.

Lesson: Plan out system architecture in advance

In retrospect it was really amusing, but the night of launch the site was serving via the Django runserver command. We were so dead tired and neither of us are crack system administrators that we did what we had to do to score the contest launch point. The next day Audrey got the site running underApache, and next week we'll be giving someone else system access to increase reliability. Next year for the contest we'll probably use something like this or get continuous integration running in the first hour.

Lesson: Don't be afraid to chat with others after the contest starts

Share your ideas, selected packages and frameworks with your competitors. The break from coding helps clear the mind and they might counter with a better idea/package/framework you can use.

Announcing Django Packages!

2010-08-17T07:30:00.000-07:00

I'm part of a two person team that just launched that BETA site for http://djangopackages.com, a site that is designed to list all the Django Applications, Frameworks, and Packages created by the Django community. While there are already a few places to look for these things, it is quite easy to argue that they are challenging to navigate, don't give any hard metrics, or are woefully incomplete/unstable/closed. Our goal was to provide an attractive, easy-to-navigate, easy-to-add-data, stable site and share it with the world.

Also, this was our entry into Django Dash 2010, and was the culmination of a few days of brainstorming over paper, a lot of research, and two days of feverish coding/designing. The project was feature complete to our specifications at 5pm the second day, and the rest of the time was spent adding in UI tweaks, usability enhancements, and trying to deploy our creation.

Since then, we've cleaned up a the UI, improved the design, and got the site stable. The code is open source and on github, so fork and contribute!

Design Consideration: No 'Like' button or 'Rate my app' rating systems

We wanted hard metrics. So the package numbers are pulled from the repo sites such as Github, Bitbucket, and Google Code. Otherwise things get weighted funny. Sure, this system can be monkeyed with, but its a good metric for now. We've had suggestions from Django core developers of coming up with a quality check system, things like pypants and/or a formalized approval system.

Design Consideration: Grids

Early on we wanted to duplicate and improve upon the Django CMS Comparison page. There is also a version for Forums, but it would be nice to have a current one for blogs! In addition, recently I heard that 'tag clouds are the mullets of web 2.0'. This really struck a chord in my soul. Since we had metrics on packages, why not compare those metrics, and use those comparisons, which we call 'grids', instead of tags? In fact, we extended our idea and instead of traditional tabs we use grids in the top navigation area as seen below:

Design Consideration: Categories

The site groups packages into three categories, 'Apps' which are individual django applications. 'Frameworks' which are aggregates of apps and python modules. And 'Projects' which are implementations of Apps and Frameworks. We've thought about adding 'Tools' but weren't sure if there was anything that fit that concept, and we are leery about allowing regular Python efforts into the fold.

Design Consideration: Regex vs XML

Slurping data out of Github was easy, especially since I used python-github2. Bitbucket has a RESTful API as well that serves out JSON. I think Google Code does as well. PyPI does not and DOAP on PyPI seems to give little that is useful, so I was forced to do screen scrapes of version numbers and downloads. I'm much faster with Regex and string methods than XML juggling, and speed was of the issue this weekend. I'm not sure what benefit there is to redoing it in HTML5lib or lxml, since what I have works and appears to be stable.

Design Consideration: Leave caching and optimization for later

Besides a tiny bit of memory based template caching on the home page, there is/was no optimization. In time I plan to cache many things using a proper key/value store like redis or memcached. Perhaps not before more design and usability work is done.

Why scared of rabbits?

You wouldn't understand unless you live on the Kansas prairie.

Note: if you have any suggestions, issues, problems with Django Packages please use our issue tracker!

More reasons to go to DjangoCon!

2010-08-08T12:04:00.000-07:00

I was thinking some more about DjangoCon next month.

Capoeira - I'm known for doing one-handed cartwheels. But at last year's DjangoCon I got a chance to try my hand at Capoeira. Since then I've managed to get in some actual regular Capoeira training. My hope is to tag up with Oregon Capoeira and see how my Angola matches their Regional. Even if you've never done a cartwheel, it should still be a blast to try out!

Okay, now on to listing some more talks I'm looking forward to having at the conference:

Why Django sucks and how we can fix it - While Django is the king of Python web framewrks, Eric Florenzano is going to slam it hard. But he isn't going to just troll the conference, he's also going to provide us some possible solutions. The best thing of all, is that since Django is open source, we can all contribute to make it better!
Pony Pwning - Django is a nicely secure framework thanks to the security focus of the community, but Adam Baldwin shows us how as developers we can make compromising mistakes. If you want to avoid being caught with your pants down on a day where you didn't wear clean underwear, go to this talk!
State of Pinax - Pinax is a platform for rapidly building websites in Django that I've made contributions to off-and-on since about December 2008. Heck, my talks and tutorial at DjangoCon and Pycon were about Pinax! Anyway, Brian Rosner, arguably the second tallest man in the Pinax community is going to tell us the past, present, and future of this incredible tool set.
From Slice to Site: Django in 30 minutes - Tired of hearing about how its easier to deploy a <insert-competing-but-sucky-language> site? Katie Cunningham of NASA SMD fame is going to show you how you can do it fast and easy. A great beginner talk from someone skilled at speaking and educating!
How to sell Django - So your trying to convince the customer/boss that Django is the way to go. But they read somewhere that XML + Shell scripts is how to build an application used by millions or talk to a well-dressed salesperson selling antiquated/broken technology. How do you get past this issue? Well, I'm hosting a panel on how to convince the people who sign the checks that Django is the way to go. I've got Steve Holden, James Tauber, and either Jacob Kaplan-Moss or Frank Wiles, plus another person to discuss this on a panel.
Large Problems in Django, Mostly Solved - Unfortunately scheduled at the same time as my own talk, my good friend Eric Holscher is giving a talk on some of the best applications written for Django. These are tools that solve a lot of problems for you. Ever wonder what is the best REST application? How to do proper searches? Migrate data? Also, want to make your pet application endorsed by the Django ecosphere? Then attend this talk!

Getting excited about DjangoCon US!

2010-08-06T18:21:00.000-07:00

Djangocon starts in just a month. I'm looking forward to this event because of so many reasons. Lets go over some of them!

Friends - I'll get to meet with old friends and make new ones. Rather than list names I'm going to mark a sheet of paper with the alphabet and check off letters as I meet/make a friend with the first name that matches an unmarked letter. Which makes me wonder if their is a Django app for that in the making...

Portland - Great food and awesome beer at cheap prices. The wonderful thing about Portland is that the base ingredients are really good. I found I liked the simpler/cheaper things there more than fancy foods. The food carts alone are worth visiting the city.

Oregon State - It is a beautiful state and since words can't do justice here is an image:

Me at Mutnomah falls!

The conference schedule rocks! - The talks they lined up all look really good. They range from the basics to the advanced, and include things that go beyond the technical. Some of my favorite picks from just the first day:

Typewar: A Case Study - James Tauber is an incredible speaker, not to mention the founder of Pinax and the CEO of Eldarion. His talks are best served live. Typewar is an interesting game but the story of its inception and maintenance is a gem for anyone looking to see how the masters do it.
So you want to be a core developer? - Russel Keith-Magee, a core developer, lets us know what we need to know and do to work on Django core. He got approved for three talks so you know he has to kick butt as a speaker.
Maps of Imaginary Lands - Malcom Tredennick, another core developer, shows how to use django.contrib.gis to set up fancy maps of non-existant places. One day I'll have to do this for a place I created in my youth, a place called 'Dannyland'. Anyway, Malcom also has three talks so he's got to have a lot of cool points.
Django Forms: Tips, tricks, and ways to stay out of trouble - Shawn Rider of PBS fame might not be a core developer but he's another brilliant coder and great speaker. This is a great beginner talk and maybe a decent advanced talk too.

Thats just four great talks described. And its just the tip of the iceberg! This is going to be great!

Edit: Fixed a geography mistake. I am so embarrassed.

Rainbows on the prairie

2010-07-30T14:05:00.000-07:00

What is life like on the prairie? Well, under the right conditions it is like this:

About two months ago I rented a nice house a few miles outside Lawrence, Kansas. My original goal was to bike into town a few days every week. However, I'm leery of biking alone down rolling country roads so I bought myself a cheap little car. It gets me to and from Lawrence.

My fun new activity is Capoeira. It keeps me in shape and is something new and exciting for me to do. In order to support the Capoeira, I started up a local meetup. Yeah, at the extreme end of things you see some crazy acrobatics but for most people its the chance to have fun and get in shape. I should post some video online of my antics at Capoeira.

I'm also doing a bit of cooking. The kitchen in our house is really nice and I'm practicing my old culinary skills. My hope is to do a cook-off or a food camp with local friends at some point. Or maybe just relax and just cook for fun.

I tried a ballroom dance class in the area but was not happy with the quality of instruction. Also, that each class we learned a whole new dance form meant that you never really got comfortable with a single method. That said, I did learn some nice steps and hope to do them at a conference and found I really enjoy salsa.

The food here is generally cheap and good. Especially when it comes to core produce and meats. Getting some of the edgier ingredients means paying coastal prices or more. Fish and seafood seems to be hit or miss. I've heard the barbecue is outstanding but haven't been to any of the really notable places.

Life is a lot cheaper here. The dollar stretches amazingly far. My monthly rent on a really big house is a third of the cost of my mortgage or much less than what I was paying for a room in Arlington, Virginia. That means I do a few more of the things I really enjoy and also be able to save at a good rate.

Getting piston forms to play nicely with JSON

2010-07-16T15:14:00.000-07:00

Critical Update 2011/09/29!!!
Critical Update 2011/09/29!!!
Critical Update 2011/09/29!!!

django-piston has been barely supported for nearly two years. That is an eternity, and the number of forks to address multiple issues is a cause for alarm. Because of that, in it's place at this time I recommend django-tastypie. It is up-to-date, has very good documentation, supports OAUTH, and scored second place in the Django Packages thunderdome (it got nearly 3x as many points!). Another tool to consider is Django Rest Framework, which is as good as django-tastypie but lacks the OAUTH support.

On the django-piston front, Joshua Ginsberg has taken over the reins and we should hopefully see some movement again. In which case I'll be able to remove this section of the blog post.

Back to the existing blog post...

A commonly used tool by Djangonauts is django-piston, which is designed to make building a REST API easier. It even works with Django forms to provide easily written PUT/POST validation, which should be pretty darn nice. Unfortunately, if you go with django-piston forms validation it doesn't accomodate the JSON (or XML or YAML) requests and if validation fails it responds in HTML. Even more unfortunate, making validation accept and return JSON with PUT/POST requests is not documented.

While one could argue that it is documented in the django-piston docstrings, in my opinion that is not sufficient.

Fortunately while working on a project for Revolution Systems we worked out a solution:

"""
myapi/resource.py

    author: Daniel Greenfeld
    license: BSD

This assumes your API accepts JSON only.
"""

import json

from piston.decorator import decorator
from piston.resource import Resource
from piston.utils import rc, FormValidationError

def validate(v_form, operation='POST'):
    """ This fetches the submitted data for the form 
        from request.data because we always expect JSON data
        It is otherwise a copy of piston.util.validate.
    """
        
    @decorator
    def wrap(f, self, request, *a, **kwa):
        
        # Assume that the JSON response is in request.data
        # Probably want to do a getattr(request, data, None)
        #   and raise an exception if data is not found
        form = v_form(request.data)

        if form.is_valid():
            setattr(request, 'form', form)
            return f(self, request, *a, **kwa)
        else:
            raise FormValidationError(form)
    return wrap

class Resource(Resource):
    
    def form_validation_response(self, e):
        """
        Turns the error object into a serializable construct.
        All credit for this method goes to Jacob Kaplan-Moss
        """
        
        # Create a 400 status_code response
        resp = rc.BAD_REQUEST
        
        # Serialize the error.form.errors object
        json_errors = json.dumps(
            dict(
                (k, map(unicode, v))
                for (k,v) in e.form.errors.iteritems()
            )
        )
        resp.write(json_errors)
        return resp

Usage in handlers.py:

from django import forms

from piston.handler import BaseHandler

from myapp.models import Article

# We use our custom validate rather than piston's default
from myapi.resource import validate

class ArticleForm(forms.Form):
    """ This is best stored in forms.py but we put 
        here for sake of clarity"""

    author      = forms.CharField(required=True)
    title       = forms.CharField(required=True)
    content     = forms.CharField(required=True)

class ArticleHandler(BaseHandler):

    allowed_methods = ('GET', 'POST', 'PUT', 'DELETE', )
    model = Article
                    
    @validate(ArticleForm)
    def create(self, request):
        # Create/POST code goes here. 

    @validate(ArticleForm)
    def update(self, request, id):
        # Update/PUT code goes here.

Usage in urls.py:

from django.conf.urls.defaults import *

from piston.authentication import HttpBasicAuthentication as auth

# Import our ArticleHandler
from myapi.handlers import ArticleHandler
# Use our custom Resource class instead of piston's default
from myapi.resource import Resource 

article_handler = Resource(ArticleHandler, authentication=auth)

urlpatterns = patterns('',
   url(
        r'^articles/(?P(\d+))$', 
        article_handler,
        { 'emitter_format': 'json' },
        name='api_article'
       ),   
)

Of course, this assumes you are mapping Create/Read/Update/Delete (CRUD) actions to your API.

I'm interested to see other solutions people have used to handle this in django-piston, and what suggestions people have that could improve on the examples I'm supplying here.

I want to talk to Jython and Iron Python developers

2010-07-09T12:59:00.000-07:00

I want to ask some questions of the Jython and Iron Python communities. I'm primarily looking for efforts that can go into publishable case studies. Experience in use of Django in the Jython and Iron Python environments is also very much desired. Please use my email address which is obfuscated below and can be decoded by simply running the code in a python shell:

''.join([chr(x) for x in [112, 121, 100, 97, 110, 110, 121, 64, 103, 109, 97, 105, 108, 46, 99, 111, 109]])

Apologies to the Python community

2010-06-29T11:43:00.000-07:00

Apparently planet python is pulling all content off this blog to its RSS feed. Which meant a rant I wrote this morning that was completely off topic went to the entire Python community. I'm contacting the staff behind planet.python.org and asking that they point at the correct feed so this doesn't happen again.

I hate Mac & Cheese

2010-06-29T08:23:00.000-07:00

I'm not a picky eater. I'm willing to eat every meat that is legal in the United States and wouldn't mind traveling to places where the laws are different. I have this strange desire to try pickled insects in a third world nation. I often eat things I don't like, such as eggplant.

However, the truth is that I really loathe mac & cheese. I hate cooking it, I hate eating it, I hate cleaning up after it. I've thrown away pots that have been used to cook it. I claim to be different because I despise this American staple, and silly as you may think it may be it is my preference not to have anything to do with cheesy pasta. Heck, it ain't even healthy.

Note: I sometimes like some cheese on top of tomato based sauces or chili that has pasta mixed into it. This is not the same thing as mac & cheese.

Yet the complication I face is that I have dear friends and family who think that their prize-winning homemade mac & cheese made from imported unpasteurized cheese will be something that I love. That I'll change and they'll get the chance to smugly say that it was the quality of what I've eaten that discouraged me.

That won't happen.

I've been forced to try everything from Kraft mac & cheese to gourmet cheesy pasta prepared by chefs I otherwise respect. I've had it dumped on my plate on picnics and in fancy restaurants. I've had the people proudly insist I try their recipe all while making it clear that they would take it as a personal insult if I didn't try it and would also take it as a personal insult if I didn't like it.

And you know what?

I hated it. Its vile. Its disgusting.

Please stop insisting that I try your concoction. You aren't going to change me.

My little unit test trick

2010-06-08T17:29:00.000-07:00

This is an oldie but a goodie.

I love writing unit tests for Python code. It makes me so happy seeing the little dots go by. Add in some coverage.py and you can even make a game out of how much your code is covered. Of course, adding in Hudson just makes it even better.

However, sometimes when your unit tests get sophisticated it can be a pain to introspect via the Python shell (REPL) on one terminal shell and then go back to the unittest. Especially when the unit tests get even the least bit sophisticated. In the shell you can forget steps since you are entering things manually.

So as soon as things get the least bit complicated I simply start using the Python help() function and pdb library inside my test code. For example:

class MyTests(unittest):
    def test_pretending_to_be_complex(self):
        ...
        complex_object = really_complex_actions()
        ...
        
        # help demonstration
        help(complex_object)

        # PDB example cause everyone loves that too.
        import pdb        
        pdb.set_trace()

So what does this give you? Well, the help() function acts here exactly the same way it does from the Python shell. It stops the code processing and lets you do introspection. pdb lets you step through things with joy.

Try it out!

EDIT: Of course, you probably wouldn't use both help and pdb. Thats because you can call help() inside of PDB. My example just shows you available options. Thanks to Gary for pointing this out!

Using modernizr to help with canvas

2010-05-11T12:14:00.003-07:00

On my current project I've been using a little bit of the HTML5 Canvas element to provide a little bell/whistle. However, the problem with Canvas is that not all browsers support it. Out of the box though Canvas gives you a quick and handy way of dealing with that problem:

<div id="content">
    <div id="demo-space-wrapper">
        <canvas height="100" id="demo-space" width="100">
            This text is displayed if the client browser does not support HTML5 Canvas.
        </canvas>
    </div>
</div>

The problem with this approach is that if your layout expects to have an object there and your client's use of Internet Explorer doesn't include the Canvas extension then this could damage the overall feel of your layout.

And that is where Modernizr comes in to play. It is a trivial to use JavaScript library that makes it possible to detect if a browser can use Canvas or any other HTML control. So what I did was take the Modernizr Canvas detection documentation and apply it to my JavaScript. With that in hand I wrote this:

// check for canvas
if (Modernizr.canvas) {
    // We have canvas so add a rectangle
    var demospace = document.getElementById('demo-space');
    var context = demospace.getContext('2d');
    context.fillStyle = "rgb(255,0,0)";
    context.fillRect(10, 10, 10, 10)            
} else {
    // No canvas. Remove the layout space to preserve the layout.
    var ul = document.getElementById('content');
    var li = document.getElementById('demo-space-wrapper');
    ul.removeChild(li);
};

Code highlighting on blogger

2010-05-11T11:38:00.002-07:00

Thanks to Luka Marinko I have code highlighting now!

def python_funct():
   a = a + b
   print "Hello Highlighted code"

class Foo(Bar):
   pass

Steve Holden giving a talk on Python education

2010-05-07T09:45:00.002-07:00

Steve Holden, Python Software Foundation chairman and all around decent guy is giving a webcast talk today at 1 pm PST (4 pm EST) about the O'Reilly school courses on Python and the upcoming O'Reilly Python certification programs. Check out the O'Reilly promotional page:

Steve Holden's Webcast

Some quick notes:

1. Steve Holden is a marvelous speaker and a great wit. Even if you don't do Python and aren't a geek its worth listen to him talk. Leaving the DC area means I won't get the chance to sit at his feet and absorb his magnificent wisdom.

2. In certain ways, I believe Python needs these kinds of certification programs. The lack of certification or any paper validation of python skills means that a number of large and conservative organizations are often hesitant to use Python. And one way to make those organizations more open to using Python is certifications. Its not the only answer, and its an answer that comes with its own set of problems, but I think that Steve and O'Reilly are a really good choice for overcoming these problems.

3. I helped Steve write the Python 1: Beginning Python. So by attending you will be supporting my work too. :)

Moving away from DC

2010-04-23T06:31:00.005-07:00

Way back in 1969, when I was about a year and a half old, my family moved to Laurel, Maryland, which is about 20 miles north of Washington, DC. Since then, I've lived in central Maryland, Washington, and Northern Virginia. I enjoyed my friends and family, and the things that I've done.

Yet I always wanted to see the rest of our world, try new things, explore new horizons. Breathe different air, if you will. My ideal existence would be to live in a lot of different places, living six months for a time in place to place so I can get a good experience of the planet.

Not long ago conditions came together that made it feasible for me to do all this. My house is sold, my son is 18, I don't currently own any furniture, and I have a job that allows/encourages for telecommuting (and that is because of Python and Django).

So on May 5th I'm moving to Los Angeles, California for a short term stay. I'm there to hang out with a certain artist/developer and to go on a vacation that I've wanted to do for many months. More details on this move in another post.

In early June I'm moving again to Lawrence, Kansas. I've got a number of friends there, but much more important are the professional reasons. The entrepreneur for my start-up will be living not far from there, Revolution Systems offered me office space, and the cost of living is amazingly low. Another nice feature is that its in the central point of the USA, so flying anywhere on the continent doesn't take that long.

I'm very excited, but I'm also sad to go. I'll miss being near my son, my parents and siblings. I'll miss all my DC area friends, who are way too numerous to list. I will certainly miss all my students, young and old, not to mention the other teachers at OMAA.

I will be coming back in late June, and then perhaps in either late July or August. And who knows, maybe someday my travels will bring me back to the Washington, DC area for an extended stay?

Leaving NASA

2010-03-21T09:33:00.026-07:00

This has been a hard post to write.

I was delighted that on January 3rd, 2005 I started my first day working for the National Aeronautics and Space Administration (NASA). While I wasn't working on science efforts, I was at least contributing to the cause. In 2005 I was introduced by co-worker Chris Shenton to Python, which became my favorite programming language ever. I also learned tools like Zope, Plone, and Django. Over the past five years, I've met a lot of fascinating people in and around the agency, a list that seems endless in size and scope. That includes astronauts, scientists, engineers, developers, managers, and so much more.

This meant so much to me, and maybe because my first memories of television as a child were the moon landings of the early 1970s. I dreamed as a child of being an astronomer or astronaut, and sometimes I plot how I would redo my life to fit these dreams if I got a second childhood.

In the past year I've had some incredible opportunities present themselves to me. I've been presenting frequently on Django and Pinax. I've had the singular honor of writing course material for Holdenweb, LLC on behalf of the O'Reilly School of Technology. Representing NASA as a contractor to the Python and related communities has been both enjoyable and a great honor.

Yet all things, even good ones, must come to an end.

I've decided to become an independent consultant. My first project will be working with Revolution Systems (Jacob Kaplan-Moss and Frank Wiles) on a neat stealth project that looks very promising and once launched will help people. The project will be Python/Django/Linux based, and the client insists on accessibility, testing, and quality work. We'll be exploring the boundaries of what has been done with those tools and besides what must remain proprietary, a lot of our work will end up going back to the community. Sounds like my kind of thing!

My last day is April 1, 2010. I'm both excited to explore this new project, and saddened that my professional world for the past five years is coming to an end. Yet the overlap in technology and the participation of the NASA SMD python group in the open source world means that my work with NASA isn't coming to an end, its just transforming into something different.

Nevertheless, this is the end of an era for me.

Which is partly why I'm happy that I'll still be in touch with my fellow NASA SMD Python contractors such as Katie Cunningham, Chris Shenton, Chris Adams, James Saint-Rossy, and others. I also plan to be real friendly with the awesome Ames Research Center Python/Django/FOSS groups such as the intrepid Mark Friedenbach and the entire incredibly awesome Nebula team.

I'll miss having the pleasure of working with Leslie Cahoon, Jessy Cowan-Sharp, John Kasmark, Bob Ryan, Candace Solomon, Bill Keeter, Gamble Gilbertson, Meredith Mengel, Malik Ahmad, Jenny Mottar, Mike Brody, Virginia Butcher, Dawayne Pretlor, Michele Montgomery, Jim Consalvi,Siew Chin Hon, Hans Goetzelt, Shannon Lantzy, and many more.

Lastly, I'll miss the honor of serving civil servants such as Gretchen Davidian, Sharron Sample, and Ruth Netting and others.

Pycon 2010 report III: Sprints

2010-03-05T10:11:00.003-08:00

My report for the sprints of Pycon 2010. This isn't a general review of the sprints, just how it affected me.

Pinax Sprint

I don't have a hard count of how many people participated on Pinax this year. Last year's sprint looked like we had a lot more, but last year the Pinax room was home to people doing other things, albeit mostly Django related stuff. In any case, this year we had probably about 10 people working on Pinax, or things that went directly into Pinax.

While James Tauber is the leader of the Pinax community, this year Brian Rosner stepped up and did an amazing job being both a technical resource and director of geeks. The mutual clarity of vision and obvious telepathy between Brian and James is truly a joy to behold.

I also appreciate the entire Pinax community. Besides coaching me on Git branches (work uses SVN so I just don't get enough Git practice) they also gracefully understood that I was a bit distracted this year.

My specific contributions to Pinax

One of the things that had bugged me about Pinax for some time were the individual project tag apps. These were a per project extension of django-tagging, and were used to simply display tagged data. I was never happy about the displays of the tags, the lack of pagination, or that you had to create/modify an entire project level application just to control a display.

So last DjangoCon I wrote django-tagging-ext. What it does is let you control the displays of tags via a root urlconf wiring. It still needs some work (cleaning a query, 100% test coverage, better documentation), but its a big step up from the alternative.

For Pycon I volunteered to go into all the Pinax projects that used tags and replace the tag_app there with django-tagging-ext wiring. I thought it would be relatively trivial, but in practice it was not.

The issue was that immediately prior to the conference, changes had been made to Pinax trunk that caused a small number of errors. All them passed existing tests but failed when you actually clicked through pages. Yeah, that does mean that Pinax code coverage needs improvement, but that is something we are working feverishly on. In any case, what that meant was that by implementing the new tag display system, I got the chance to fix a number of small but poignant bugs.

I also worked some to help the code coverage of tests. Brian Rosner worked with me and gave me some excellent pointers. I feel sad because I think we had a disconnect on what we consider pair programming, and want to assure him that the time he gave me was a high mark of the conference.

In regards to pair programming, I don't mind working with someone until you figure something out, but spending hours and hours sharing a computer drives me nuts. Once a person 'gets it', go do something else and let them go forward.

Volume of Contribution

Looking at the Pinax impact chart on github I can claim that I had the most impact during the sprint. Heck, I even jokingly claimed it on Twitter.

Except that claim is false.

The truth of the matter is that how many commits I did in a brief period is nothing compared to what Brian and James did to equip others to make commits. Or what they've done during the history of Pinax. Or what they might have done to side projects that touch Pinax. Also, during the sprints my work was really focused to a specific area of Pinax, and besides some work I did with Skylar Saveland, I worked mostly by myself.

So that claim is full of hubris and rather silly. If that claimed annoyed anyone in the Pinax community I'll buy your forgiveness with a beer.

Conferences are a double edged sword

2010-03-03T06:28:00.006-08:00

This post isn't for developers, its for managers.

In the Python world once a year there is Pycon. In other languages, tools, and frameworks they all have that one big conference where all the top people go. There are classes, tutorials, scheduled talks, open spaces, keynotes, and tons of networking. All your developers will want to go, and the ones that do will rave about the time they had. So how do you as a manager handle a big conference?

Conferences are a double edged sword. If handled well they will be a huge boon to you and your organization. Handled poorly and they can be devastating to you, your projects, your team, and your organization. Knowing which way to swing the 'conference sword' in such a way that you don't get cut is a handy tool to have in your pocket.

First, remember that at the big conference there will be lots of networking. Make sure your developers are really happy with you before they go. Also have your your developers go with business cards. Ask them to bring back business cards. Remind them of whatever referral policy your company might have. Why pay for a headhunter when your own staff can do the hiring for you?

Second, remember that people will be scoping out your staff for potential hire. Don't anger your developers immediately before, during, or immediately after a conference. Keep deadlines as far away as possible from the conference. Don't begrudge them leaving and task them with petty work. Because what would have been training plus an energizing break for your staff will now be considered job fair by your staff.

Third, try to cover even a portion of the costs of the conference. If your organization doesn't officially do conferences, then offer to pay for their time during the sprints just so long as that open source work even tangentially affects what they do back at the office. That way they don't use up so much leave and odds are they'll have lots of smart comrades around to help them through some of the tricky parts.

Fourth, when the developers come back, ask them what they learned. Ask if they can incorporate these lessons into current or future tasks. They'll gush about twenty new things and most of them will be inapplicable. But there will be one or two things that are a perfect match and you'll both be grinning at each other in regards to challenges now effortlessly overcome or new services you can offer.

Fifth, try to go yourself. In fact, try and organize the whole trip. If you are close enough, rent vehicles and drive down. Set up the hotel rooms. You'll be able to network with other manager types and your staff will rave about you. Hiring will become that much easier.

So lets look at two ways to handle a big conference like Pycon:

The Wrong Way

Block any attempts the developers make in getting reimbursement for the trip.
Schedule deadlines around the conference. If anything goes wrong, declare that this is why people should not go.
Before the conference, grumble about developers going away and then when they come back grumble about time lost.
Developer time lost at the conference should not be compounded by talking about the conference when they come back.
Act surprised when your team comes back angry and at low morale levels. Act more surprised when they leave for positions elsewhere.

The Right Way

Get business cards and fliers for your staff to bring to the conference.
In the meeting before the conference, go over the company referral system for new hires. Also offer beer or a meal for new hires.
At least get the developers paid hours for the sprints. Beg and borrow from your own manager to try and cover other parts of the conference. Act surprised with the gratefulness of your staff.
Afterwards, dedicate a staff meeting to things learned at the conference.
Go yourself and hang out in the vendor room. Hand out cheap but goofy swag. Bring thousands of business cards and hand them out. Visit a few talks. Invite developers from other companies to meals. Boast about your staff and company. Be amazed by the new hires you pick up.

Apologies to Katie

2010-03-02T06:40:00.005-08:00

Katie Cunningham is a good friend of mine. We met about nine years ago through a mutual acquaintance. We had a number of similar interests all tied to general geekery and kids. I've always appreciated her honesty, humor, and work ethic. In December 2006 I got her a job at NASA, which eventually got her involved in Python and various related communities.

One thing I like about Katie is that she likes to cook and she always does so from scratch. Her focus is on a mix of various savory dishes and baking. Since she takes care to find out her friend's allergies and preferences, it is a rare moment when people do not like what she cooks. One of my absolute favorites is a blackberry cobbler that she makes, which she does not destroy with loads of sugar. She knows that when taken in quantity sugar adversely affects me and that I also love blackberries.

I'm good at entrees and appetizers and sides, but baking is beyond me unless I use a pre-mix. So I really respect what Katie does.

So anyway, recently on twitter when she was discussing bagels with Jacob Kaplan-Moss I called her out publicly for putting icing on cheesecake. As an Ashkenazi Jew from family who spent generations in the New York area (although I was raised in Maryland) I'm picky about cheesecake. Legal toppings are berries, and going crazy with toppings is having those berries in a heavy glaze.

Well, it turns out that the illegal toppings cheesecake instance was not done by Katie, but rather her mother. Katie's mom is a wonderful lady who is also a cook whose work is worth tasting and all around wonderful person. But she puts a thin layer of sour cream icing on cheesecake. While I'm sure somewhere there is a Jewish law against illegal toppings on cheesecake, Katie's mom's defense is that she is not a Jew. And I certainly appreciate her Southern style fare.

So, for what it is worth, this is my public, formal apology to Katie. She rocks and if you are smart, you'll convince her to bake for you.

Pycon 2010 report II

2010-03-01T05:13:00.005-08:00

The first half day report for formal conference activities on February 21.

Plenary: Introduction

I helped in registration so I arrived late to listen to Van Lindburgh start the conference. Which was a shame because I like to listen to him speak. Nevertheless, I consoled myself with the knowledge that I had contributed my time and service to help him launch what turned out to be an amazing conference.

Keynote: Steve Holden

In December Steve had presented to the NOVA-Django a much earlier draft of his speech. As much as his stuff back in December was good, what he did at Pycon was right on the money. He was in fine form, and the conclusion was very much Steve Holden at his best.

The next night Steve was in rare fine form, but that is a story for another day...

Keynote: Guido Van Rossum

Being that I am Guido's biggest fan, and have trouble breathing in his presence, you might think I'm a bit biased. Alas, in this case, Guido's talk was not my favorite of the conference. If memory serves, at last year's Pycon he mentioned a desire to remove the "For Life" from BDFL and this year I think that showed a little bit. It was nice to have him field questions from the Eldarion supplied pycon.djangodose.com feed and the audience, but from Guido I guess I want vision and on-high judgements.

Leafy Chat, et al by Alex Gaynor

Alex Gaynor is great at public speaking. He is unafraid of crowds and speaks with good clarity. His talks are always informative, and this was no different. The downside was that for his talk he had 35 minutes to present a lot of information. So he didn't have the time to explore some of the technical hurdles they overcame in each effort. Nevertheless, it was informative, and by the end it seemed clear that one of the lessons re-learned was to focus on a simple core architectural design and make it work.

A Short Pinax Tutorial by Me

I've given variations of this talk at least three times previously. Once at DjangoCon, once for NOVA-Django, and once for Django-District. So I'm rather practiced at it, which turned out to be a good thing. Because, brand new good luck charm or not, this talk ended up having a host of problems.

First off, we couldn't get any Apple laptop to work with the projector. So we started 7-8 minutes late on a Windows machine. So I had to speak very quickly, especially if I was going to include the technical side of things.

So I finished the majority of slides with time to spare and then things went wrong again. The Windows machine... didn't do what was needed. Displaying Pinax and showing off its tricks just wasn't going to happen. So we ended up with an extended Q&A session.

Not my best presentation, but memorable.

In the works is me giving the talk a least a couple more times. Once with my local friends at ZPUG-DC and once at LA Django.

Managing the World's Oldest Django Project by James Bennett

James is always on the ball when it comes to presentations. His stuff is well researched and documented, and his voice is both relaxing and invigorating. It was good to hear about lessons learned, experiences, and some of the more interesting foibles they've been through.

An Underwater Python: Tortuga the Python Powered Robot by Joseph Lisee

Python powered underwater Robots? I was so excited by this talk!

Yeah, odds are it would have almost no professional applicability, but sometimes you just have to see what other people are doing with one of your favorite tools. I was impressed by the energy and creativity of the students at the Robotics group at the University of Maryland and am trying to figure out how to include robots in my next project.

Pycon 2010 report I

2010-02-24T12:13:00.010-08:00

Pycon was an incredible learning experience and networking opportunity. I met many good friends again and made just as many new ones. In addition, this was the first time I presented and did so on Pinax two times. Furthermore, in the name of diversity, this instance of Pycon saw the premiere of the Financial Assistance Grant for Women. We also had a dedicated talk on Diversity as a Dependency. The benefit this focus on diversity was that...

um...

yeah...

like...

uh...

um...

Diversity Rocks

Did I learn a lot at pycon? Heck yeah. Networking was life changing. And unlike previous conferences, I'm in a position to take advantages of opportunities offered. The next few weeks and months will see a lot of changes and challenges for me.

Note: I've got to keep some things under wraps for now so I'm going to have to aggressively moderate comments. Feel free to comment, just don't take comment rejections personally.

Note II: For reference, this post is mostly about Audrey Roy and some about the job offering I got at PyCon 2010.

I've got ribbons!

2010-02-18T09:08:00.004-08:00

Odds are this will be my last post on blogspot. After this it should be on my personal blog.

Anyway, I'm here at Pycon. I presented a Pinax tutorial and tomorrow I'm presenting a talk on Pinax. I'm also a session chair and plan to help with assembling things for registration. And what do I get out of it?

Ribbons.

RIBBONS!!!

My plan is to have more ribbons than anyone else.

Eating my own Dog Food

2010-02-10T07:43:00.007-08:00

For several years now I've hosted this blog here on blogspot/blogger. Its been both a good and bad experience. For writing out simple posts it has made things pretty easy. However, if I try to post code examples I've got to deal with the various quirks of the blog engine. How it escapes special characters and that you can't easily do color colorization has been really annoying. Yes, I know you can do some hoop jumping to make this work, but I decided a long time ago that if I had to do that then I would host my own blog.

Speaking of which, a few months back I got called out for not eating my own dog food. Yup, as a Python developer shouldn't I use something Python powered? I currently do Django professionally so those are in my tool chest so this should be trivial. Heck I also do some serious Pinax work so why not that?

Whatever I put it under, it would be a nice move. I would be able to format and control my blog to a much better degree. I could easily supply code examples. I could use the hosting to demonstrate pet projects or launch some of the things I've wanted to try for some time.

So which blog to use? Roll my own?

Heck no.

I've got a full-time job, I teach 10+ hours a week, and my consulting efforts eat up a chunk of my free time. So rather than use my energy to reinvent the wheel, I would rather rely on the hard work and labor of others.

With that in mind, I really, really like Django-Mingus. Out of the box it does everything that I want and is a breeze to get up and running. It has a large, active community and it even uses a project that has my name attached, django-wysiwyg (although Chris Adams did most of the work).

Some might ask the good questions as to why I'm not using Pinax for my new blog. In essence, I wanted to do something in the wild that wasn't Pinax powered and my concept projects all use Pinax. So don't worry, I'll be doing Pinax work for as long as I can foresee.

So I've begun working on it during the Blizzard of 2010. I'll have it up today unless we lose power or Internet.