Monday, January 31, 2011

What I want for Django Facebook connect

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
  • 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.

Tuesday, January 25, 2011

Los Angeles Open Source Hackathon

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

Thursday, January 20, 2011

Why you should go to Pycon

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.

Saturday, January 15, 2011

January Mongo LA conference

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

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?

Monday, January 10, 2011

Pinax Tutorial at Pycon 2011

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!

Thursday, January 6, 2011

I don't work in a vacuum

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.


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.