pydanny

10 reasons to go to DjangoCon Europe

2012-05-14T19:30:00Z

You should go to DjangoCon Europe in lovely Zurich, Switzerland. Here are 10 reasons why:

1. Chocolate

So much of what we like about chocolate comes from Switzerland. For example, Milk Chocolate was invented in Switzerland.

2. Keynote speaker: Jacob Kaplan-Moss

Always a great speaker and fun to be around, he's one of the BDFL's of Django.

3. Cheese

I grew up thinking that Swiss Cheese was just about holes. It's so much more. I can't wait to try fresh European cheese made by master craftsmen from the freshest ingredients.

4. Keynote speaker: Jessica McKellar

In a word, Jessica is incredible. She's a Twisted core developer, PSF board member, part of the trio responsible for the gigantic Boston Python User Group's massive size explosion, and a talented speaker. She's used her incredible talents and skills to increase diversity in the community and generally help other people.

5. Breakfast

Muesli was invented in Switzerland. I love Muesli. I was floored by how much better it was in New Zealand. I can't wait to try it in it's homeland.

6. Web Site

The DjangoCon Europe site is crazy. I mean, look at all those animations!

7. Talks

This is a single track event with proven speakers like Zachary Voase and Andrew Godwin, yet balances that with bringing in new blood to spice things up. And dare I say I'm giving a technical talk with Audrey Roy? ;-)

8. Mountains

With all the incredible food, you would think you would gain umpteen kilograms. Fortunately there are mountains all around to climb and hike.

9. Sprints

Want to sprint on Django itself? Look no further because there will be Django core developers around! There will also be notable Python developers like Kenneth Reitz and others around working hard on a lot of different projects. It's going to intense and fun!

10. Castles

Living in the USA, we just don't have anything like castles. DjangoCon Europe will be near a small horde of stone fortifications. Which means if the Zombie Apocalypse happens during the conference, we'll have many secure places to go. They also make lovely tourist destinations. :-)

What are you waiting for?

DjangoCon Europe has a cap on attendance. Tickets for Python events have been selling out, not just for PyCon US. Don't miss out!

It's all about me

Yup.

Call me selfish but I want you there because I haven't haven't met all our European friends yet in person. Hope to see you next month in Zurich!

CSS Hacking to make my code samples legible

2012-05-11T08:30:00Z

I've been very happy with Pelican as a blog engine so far, and haven't even moved off the sample theme. There's just been one problem: Myself and others have had a lot of trouble reading the code snippets.

I didn't have time to cook up a full Pelican theme, so instead I just hacked the local CSS files. The problem with this hack is that every time I regenerate the blog I have to copy the right CSS files into place. So next week when I have time I'll do a proper Pelican theme.

In the meantime, enjoy!

from random import shuffle

class Meal(object):
    def __init__(self):
        self.food_type = ['Beef', 'Fish', 'Vegetarian', 'Chicken']
        shuffle(self.food_type)

Choosing an API framework for Django

2012-05-10T08:00:00Z

First off, out of the box, Django lets you construct API responses with a little work. All you need to do is something like this:

# Copied from https://docs.djangoproject.com/en/1.4/topics/class-based-views/#more-than-just-html
from django import http
from django.utils import simplejson as json

class JSONResponseMixin(object):
    def render_to_response(self, context):
        "Returns a JSON response containing 'context' as payload"
        return self.get_json_response(self.convert_context_to_json(context))

    def get_json_response(self, content, **httpresponse_kwargs):
        "Construct an `HttpResponse` object."
        return http.HttpResponse(content,
                                 content_type='application/json',
                                 **httpresponse_kwargs)

    def convert_context_to_json(self, context):
        "Convert the context dictionary into a JSON object"
        # Note: This is *EXTREMELY* naive; in reality, you'll need
        # to do much more complex handling to ensure that arbitrary
        # objects -- such as Django model instances or querysets
        # -- can be serialized as JSON.
        return json.dumps(context)

Once you get that mixin, use it in your views like so:

# modified from djangoproject.com sample code
from django.utils import simplejson as json

class JSONDetailView(JSONResponseMixin, MyCustomUserView):
    def convert_context_to_json(self, context):

        context['objects'] = User.objects.values('first_name','last_name','is_active')
        return json.dumps(context)

This works pretty well in a number of simple cases, but doing things like pagination, posting of data, metadata, API discovery, and other important things ends up being a bit more work. This is where the resource oriented API frameworks come in.

What makes a decent API Framework?

These features:

pagination
posting of data with validation
Publishing of metadata along with querysets
API discovery
proper HTTP response handling
caching
serialization
throttling
permissions
authentication

Proper API frameworks also need:

Really good test coverage of their code
Decent performance
Documentation
An active community to advance and support the framework

If you take these factors, at this time there are only two API frameworks worth using, django-tastypie and django-rest-framework.

Which one is better? django-tastypie or django-rest-framework?

I say they are equal.

You simply can't go wrong with either one. The authors and communities behind both of them are active, the code is solid and tested. And here are my specific thoughts about both of them:

django-tastypie

Using django-tastypie is like playing with pure Python while using the Django ORM. I find it very comfortable. Seems really fast too. The documentation is incredible, and I rarely have any problems figuring anything out. It also supports OAuth 1.0a out of the box, which is mighty awesome these days.

In fact, I wrote a custom OAuth2 handler for django-tastypie for consumer.io that I'm working to extract for publication.

django-rest-framework

As it's based off Django 1.3 style Class Based Views (CBVs), it has a very familiar pattern. Actually, because of the quality of the documentation, I really prefer using django-rest-framework CBVs more than using Django's actual CBVs.

Maybe I should make an HTML renderer for django-rest-framework? :-)

But what about django-piston?

Don't use django-piston.

I don't want to say anything negative, but let's face it: django-piston is dead. Besides a critical security release last year, nothing has been done for it in about 3 years. The documentation is weak, the code mostly untested, and the original author left. He has gone on to do some amazing things. Django-piston was amazing in its time, but its time has passed and so should you.

The only reason for using django-piston for years has been that it supported OAuth, but django-tastypie now addresses that use case. I've used django-tastypie's basic OAuth class and rolled custom Authentication modules to support some extra OAuth flavors and found it wonderful.

Use django-tastypie or django-rest-framework instead. You'll be much, much happier for it.

Discuss this on Hacker News

Django Requirements for a project

2012-05-09T08:00:00Z

Today I'm starting a new project. I'm working as fast as I can and hope to launch on Friday. What are my package dependencies?

Django==1.4

Unlike my last quick project which was Flask, this effort really falls into Django's sweet spot. I need sessions, forms, templates, and models to do things in an ideal Django pattern.

psycopg2==2.4.5

I need transactions and hard-type validation in the database, which means PostgreSQL. If I didn't need transactions or the hard-type validation I would consider MongoDB instead.

django-extensions==0.8

Because amongst other things this library gives you, I never want to write my own TimeStampedModel ever again. :-)

South==0.7.5

Django gives you the freedom to migrate data in the way you want. The way I want to do it is via South.

django-registration==0.8.0

Normally django-social-auth is my go-to tool for registration, but in this case I need simple username/password registration. This is a very solid tool, but you do have to make your own templates or find someone's fork that has a copy of templates that match.

django-floppyforms==0.4.7

An excellent tool for making your forms HTML5-ish out of the box.

django-crispy-forms==1.1.3

The child of my own django-uni-forms, this will let me create forms using div-based controls super fast, and do layout customizations if I need them.

django-heroku-postgresify==0.2

This tool makes getting the PostGreSQL settings out of Heroku trivial.

django-heroku-memcacheify==0.1

This tool makes getting the memcache settings for Heroku trivial.

gunicorn==0.14.2

All the cool kids who play in devops swear by Gunicorn. I use it because Heroku seems to recommend it for Django deployments.

Installing the above packages

Never copy/paste these libraries directly into your projects. If you do that, you'll end up hating yourself later as your local instances become unmaintained forks of the real project. Also, unless you are really careful in your copy/pasting, you'll be in violation of various open source licenses. Odds are the FOSS police aren't going to find you, but I can assure you that when you bring in one of the authors of these packages to help you fix a problem he/she is going to be mighty annoyed at the lack of attribution.

Do it the right way: do proper Python dependency management.

Create a requirements.txt file and install them as proper dependencies. The file should contain the following text:

Django==1.4
South==0.7.5
django-crispy-forms==1.1.3
django-debug-toolbar==0.9.4
django-extensions==0.8
django-floppyforms==0.4.7
django-registration==0.8.0
django-heroku-memcacheify==0.1
django-heroku-postgresify==0.2
django-registration==0.8.0
gunicorn==0.14.2
psycopg2==2.4.5

Once you have that, you install them thus in your virtualenv:

pip install -r requirements.txt

Now that I have all this, it's time to code!

Los Angeles Open Source Sprint on May 12th!

2012-05-01T09:20:00Z

This is a day long coding event in Los Angeles for Open Source developers of all languages and skill levels to come and code like fiends. They'll be joined by dozens of either really smart coders or nice people like me. Sponsors are providing food, drinks, venue, and more!

RSVP at http://www.meetup.com/LA-Hackathons/events/62796642/ before it fills up! It's free.

I'll be there to:

Organize the event with the assistance of the awesome Los Angeles technical community!
Code like a fiend. I want to work on django-mongonaut and could use some GraphViz and JavaScript help.

And now to open the floor to questions...

Where and when?

Where:

Spire.io
7257 Beverly Blvd #210
Los Angeles, CA 90036

When:

May 12, 2012
10 AM to 10 PM

Is this like a Hackathon?

Yup. See http://en.wikipedia.org/wiki/Hackathon#Sprints

Will there be Wifi?

Yes!

I'm just starting as a developer, should I come?

It depends.

If you've never coded before, this isn't the right place. Instead, you might consider one of the local coding workshops or classes. In fact, here's a good bi-weekly hack night / study group for you.

If you've done a tutorial or two, sprints can be 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.

On the other hand, if you want to help sponsor we'll happily mention you on the meetup.com description.

Are there going to be any presentations or lightning talks?

No.

This is a sprint, not a conference or demonstration. We'll try and limit announcements and interruptions as much as possible, the only exception being for letting you know food has arrived.

What should I bring?

Your own functioning laptop with power cord. Neither event organizers, the venue, or sponsors are providing equipment. We also encourage you to bring a power strip labeled with your name.

I'm sold! How much does it cost and where do I register?

The event costs you nothing and you RSVP at http://www.meetup.com/LA-Hackathons/events/62796642/.

Join us at DjangoCon Europe!

2012-04-10T12:00:00Z

This year in June, the European edition of DjangoCon is going to be held in lovely Zurich, Switzerland. It is my great fortune and delight to announce that Audrey and I will be attending. Hooray!

Needless to say, we're extremely excited. My trip to Europe in 2007 was an amazingly fun and educational experience, and I can't wait to share a similar experience with Audrey. We can't wait to see all our old European friends, make new ones, and be dazzled by what Europe has to offer.

Also, let's face it, the conference is going to be incredible. They've lined up some awesome venues, the food (cheese, chocolate, muesli, etc) in Switzerland is world-renowned, the website looks fantastic, and they've got Jacob Kaplan-Moss to keynote. It looks so good I'm surprised there are any sponsor slots left!

Talks

While attending the conference, we submitted and hope to give a presentation on the positives (speed, flexibility, community, etc) and negatives (a few) of using MongoDB as a Django datastore. I'm also considering giving a second talk. Some ideas for that include:

Zen of Django
Django isn't for beginners (A Tredennick inspired talk explaining why teaching beginning developers Django isn't a good idea)
Advanced Django Template Usage
Advanced Django Models Usage (An intimidating talk to put together)
Django Packages Thunderdome II

Any thoughts?

While I'm at it, I'm going to poke any prospective conference goers to submit their own talks. I love attending conference talks and at PyCon US this year I barely got to see any. Show me what you got!

Choosing a new python based blog engine

2012-04-05T12:00:00Z

Why a new blog engine?

On my old blog, I had been having issues with Blogger for some time. The WYSIWYG text editor was annoying in that it produced wonky HTML, so I had to hand craft the posts. Which meant I often wrote the HTML formatted copy in a text editor and then copy/pasted it into the browser. A few times this blew up and I really wished I had version controlled back ups. Adding code examples was problematic, even with a stylesheet helpfully provided by Google. Finally, some of the changes to the blog engine itself were beginning to worry me, so I started looking for alternatives.

After my fiancee, Audrey Roy, converted her blog to https://github.com/mojombo/jekyll at it's new location of audreymroy.com, the static file hosting seemed so awesome I was impressed enough to give Jekyll a try. Why did Jekyll and static file hosting interest me so much?

I don't want to maintain my own server

A couple times I rolled out a blog on a site I stood up, but didn't really feel like maintaining a site. I want someone else to do it. When I write, I want someone else to worry about the details. I want to focus on writing and nothing else.

Well... almost nothing else. You'll understand shortly.

I want to be able to write without connection

With blogger, I needed an internet connection to get my blog posts to format correctly. With Jekyll and other static file systems, I can just type away.

I want to publish via git

My http://pydanny-event-notes.rtfd.org has really exploded in my own usage and continued because it uses the same patterns I use in software development. I'm used to the pattern of using Git to push up content, so why use naked HTML? Sure, there are RST-to-HTML processors that I could use to generate that HTML, but they always require some amount of manual correction. Jekyll, and it's alternatives, let me just write.

Jekyll wasn't for me

I found Jekyll to be good and much more fun than Blogger, but not good enough. To sum up:

I prefer RestructuredText over Markdown.
I don't know enough Ruby to easily customize things. I don't feel like diving into Ruby just to learn how to make modifications.
The template engine was like Smarty/Django/Jinja2, but not as much fun. Debugging errors was very problematic. Which was a problem when I started to play with modifying the theme.

On the second and third bullets, you might wonder why I would care about the underlying engine if all I wanted to do was write. Well, I'm well aware of the fact that I change opinions now and then. :-)

It was after trying out Jekyll that I started looking for Python based static file blog systems. The choices that seemed appropriate were:

blogofile

This is probably the most mature, most common Python static file generator around. It looks really awesome, and everyone who uses it swears by it. Alas, it's powered by Mako templates, which is... um... not my friend (apologies to Mike Bayer). What I really wanted was something with templates powered by Jinja2.

hyde

Hyde claims to have started as Jekyll's evil Python twin. On the surface it looks awesome. Where it fails is documentation. There are lots of wonderful features that appear to exist, but follow the links to those features and you find yourself on placeholder pages.

In theory, I could have just looked at the hyde code and figured out stuff myself. Maybe even document out the holes.

In practice, all I want to do is write blog posts. It's one thing to customize things to suit your needs, it's another thing to make things work. Or document a tool. Color me lazy if you will, but when it comes to blogging, that's just how I am.

I think in the near future, once fully documented, Hyde is going to be AWESOME. For now? Well, I wanted another option.

pelican

I was immediately hooked. Python powered engine with Jinja2 templates with complete documentation. In fact, every time I asked the author for help, he resignedly pointed me at the documentation. How cool is that?

At some point I'll use the CSS setting to change the color of pygments to something with white background and black text. For now I'm happy as things are now.

Discuss this post on Hacker News

Calendar About Nothing

2012-03-28T11:30:00Z

On October 16th, 2011, which was one hundred and sixty-four days before I published this post, I resolved to get myself onto the Longest Streak list of Calendar About Nothing. Today, with this blog post, I've managed to do just that - get on the Longest Streaks.

Calendar About Nothing tracks your open project commits on Github. It tallies your total number of days, records your longest streak, and lets you compare yourself against other committers. The idea comes from an article where Jerry Seinfeld says his secret to productivity is to get something done every day, because if you skip one day then skipping another day is easier.

I feel a great sense of accomplishment.

The majority of those days I would like to think I did real commits. I pledged to myself to do more than just white space tweaks or write a script to do the work for me. I wanted to accomplish things and make a difference. I started projects, wrote code, cleaned up old code, added tests, documented a lot, and moved my blog here. It's been an awesome time, and keeping my fingers constantly in projects has been eye opening.

I feel a great sense of relief.

I've really enjoyed this but there were days it was hard to get to the internet or days I was busy on other things. I discovered early on my phone was not a good interface with Github's text editor. Some days I had no desire to code or lacked the creativity to write. Then I remembered that my ability to work openly on Github is a gift, and I should just do it. Now I can relax a bit and if I miss a day, it's not such a big deal. I've made it to the Longest Streak list!

Going for a longer streak

We'll see what happens now. I just feel happy that I've captured the moment and made my mark on the board. I invite you to do the same.

Launching our API at PyCon 2012

2012-03-09T07:30:00Z

A few months ago me and my fiancee, Audrey Roy, launched our start up, Consumer Notebook. It's a Python powered product comparison site that combines the best features of Open Comparison, Yelp, Consumer Reports, and Pinterest. We've worked day and night to make it better, with countless members of the Python community using the site and giving us invaluable feedback.

All of that brings us to PyCon. We're not just here as attendees and participants, but also to promote our startup. It used to be the cool thing to launch your startup at SXSW, but times have changed. Now it's the cool thing to launch at PyCon!

Like Twilio, Twitter, Facebook, and Google, we've got an API we want developers to use. And as an upcoming startup, we've got to really be creative in how we gain your attention, so here is what we're doing for PyCon 2012:

1. Demos at our PyCon Startup Row booth.

Thanks PyCon!

We've got a booth on Saturday. We've got banners and bright red track jackets. We're giving out handy API reference cards, as well as 10 different flavors of Oreo cookies (see our site for a complete list of every Oreo cookie flavor, by the way).

So stop on by, sign up for the BETA, have a cookie, and talk to us about our API. For that matter, feel free to talk to me or Audrey about the API any time you see us. We're wearing bright red jackets with 'Ask me about our API' on our back.

Speaking of the API, the next item on our plan is...

2. A big kickoff API contest.

We've put together the Consumer Notebook API, which lets you get product list and comparison data out of our site via a simple REST interface.

We're kicking off our PyCon 2012 API launch with an API contest.

You have from now until April 22 to find new and exciting ways to use our API. If you win we'll give you a Kindle Fire or equivalent gift certificate valid in your nation of origin.

API Contest Details

3. We're hosting the Saturday night PyCon Capoeira Open Space

Want to see some awesome Capoeira moves? Want to learn some of the basics? Want to just have fun?

We've hired professional Hollywood stuntman and Capoeira instructor to the stars, Contra Mestre Xingu, to come up from Los Angeles to lead this event. In addition to appearing in movies, videos, and commercials, he's got first hand experience with snakes. In his own words:

Capoeira saved my life. What? How? Well it was a sunny afternoon, I was shooting a film in the Hollywood hills off Coldwater Canyon at a house. I was running back to set from the bathroom and out of nowhere a rattlesnake jumped up from the ground and tried to bite me. I quickly jumped out of the way and did a fast negative rolé away from the snake. Then I called the other people on set and we caught it. I really didn't think much of it afterwards until after the shoot. My friend told me the rattlesnake was a young one and I'm lucky I didn't get bitten. When a younger rattler bites you, it usually unloads all of it's venom in you because it cannot control the amount it releases.

—Contra Mestre Xingu

Over 30 people have signed up up for this event, including Python core developers.

Details:

When: Saturday, 8pm - 10pm
What to bring: Camera!
What to bring if you are participating: Workout clothes, water bottle

Location: The PyCon upstairs central open space

See you around!

The sorry state of Python OAuth providers

2012-03-05T07:30:00Z

This is one of those challenging posts to write. The people whose projects I'm going to describe have put in a lot of dedicated, hard work to overcome a challenging subject. Writing an OAuth consumer is a hard problem and writing an OAuth provider is an even harder problem. The efforts put in by the authors of these projects has been nothing short of incredible. The problem, however, is that the existing projects are not usable as-is, and need the support of the community in order to improve.

The terrible thing is that this is a solved problem within our community. Python based projects are successfully implementing OAuth providers, and often using internally hacked versions of the efforts I'm about to describe. However, they aren't giving this back to the community. It might be that they want to protect their competitive edge, but I'm going to be nice and say that it's because their too busy to find time to send pull requests back.

In any case, let me present our use case. For Consumer Notebook we want an API. We want to be able to track usernames, passwords, and the application using our API - which is the OAuth use case. Much as BasicAuth or DigestAuth is the easier way to go in terms of implementation, OAuth was designed for our use case: allowing third-party developers to build apps using our API without having to store credentials. In fact, it's a critical security issue: Twitter dealt with malicious "Twitter apps" stealing usernames and passwords before they switched to OAuth. As an API provider, being an OAuth provider might be more challenging, but it's the responsible thing to do.

Existing OAuth Providers

Time to get into the meat of the issue. Let's look at the current implementations of OAuth providing within the Python community. Again, I wish I didn't have to be negative, but I'm up against the wall:

OAuth2app (Django)

https://github.com/hiidef/OAuth2app

OAuth version: 2.0

Strange URL construction that might be a security hole.
Bitwise operators in the logic making it harder to debug. Security is hard. Don't complicate your security code because your mistakes will cost.
Uncommented code. Security is hard. Comment your code.
Documentation outdated and insufficient.
Doesn't work without serious hacking and adding of undocumented parameters. Which means I have to worry if I'm breaking anything.
We managed to get it working with GET requests. Then we realized that we were using GET requests, which seems like a bad idea.

django-piston (Django)

https://bitbucket.org/jespern/django-piston

OAuth version: 1.0

Stalled project.
Documentation insufficient.

django-oauth-plus (Django)

http://code.larlet.fr/django-oauth-plus

OAuth version: 1.0a

Tutorial doesn't work.
Documentation insufficient.
Doesn't work without serious hacking. Which means I have to worry if I'm breaking anything.
We could not get it to work.

lastuser (Flask)

https://github.com/hasgeek/lastuser

OAuth version: 2.0

No documentation
No tests to serve as documentation
Lack of documentation means I'm not sure if it is actually a OAuth provider.

python-oauth2 (Python)

https://github.com/dgouldin/python-OAuth2 (best example)

OAuth version: 1.0

Called 'OAuth2' but only works with OAuth 1? Really? WTF? This needs to fixed.
Documentation insufficient.
Provides only a skeleton of a provider. Not a turnkey solution.
Doesn't work as a provider without serious hacking. Which means I have to worry if I'm breaking anything.
Many, many forks of the project, with various blog posts advising people to use various particular forks rather than the main one.

How about a solution?

Alright, I've ranted and laid out out a bunch of bullets identifying a problem. Time to try and fix the problem.

For starters, a production-usable OAuth provider should meet certain standards:

Near turnkey solution
Working code (duplicates above bullet but I'm making a point)
Working tutorials
Documentation
Commented code
Linted code
Test coverage > 80%

This is my specification. If your project for any Python framework matches it, I'll list it on a forthcoming website that also covers Python based OAuth consumers.

For what it's worth, Idan Gazit has been working on something to help address the problem, specifically https://github.com/idangazit/oauthlib. It also is intended to cover the Python OAuth consumption issue I didn't cover in this article. It and related efforts need a lot of work, so...

The PyCon US 2012 sprints start on March 12. I think as a community, we Pythonistas should band together and make things right. I think we'll have the brainpower and enough eyes on the problem to make serious headway on the issue, either by fixing existing solutions or creating new ones. Right now I've got interest from people to join in and help, including Idan Gazit, Audrey Roy, George Hickman, and others.

We're willing to put in the time to make OAuth in Python better, how about you?

Join us at the PyCon US sprints either in person or on-line. Details of the sprint are near the bottom of this PyCon Sprint page.

Updates

03/05/2012 - Removed Velruse from the list of providers as it's lead, Michael Merickel, clarified that it is not a provider. 03/06/2012 - Added a link to the PyCon OAuth sprints.

Discuss this post on Hacker News

You should Heroku

2012-02-28T12:45:00Z

In mid-November me and my fiancee, Audrey Roy began our startup. We had been frustrated with trying to do on-line product research and came up with an idea to take the lessons learned from Django Packages / Open Comparison and apply them to a commercial effort. The result has been Consumer Notebook, and it's been a steadily growing success.

We've been bootstrapping the project. That means supporting it with consulting and grinding away on it during our free time. That means 12-16 hour days of Python, Django, and Javascript coding, marketing, system administration, graphic design, communicating with users and vendors, and a thousand other tasks. Since we've had to explore new techniques for making things work on the backend and front end, that means we've needed to have a robust system that is trivial to deploy and certain to never go down. Which, of course, requires serious sys admin skills.

The Big Problem

I hate system administration work.

Sys admin is boring. I find it tedious and dull. Devops doesn't make it easier/faster, it just makes it possible to do it at a large scale.

Fortunately for me, my fiancee likes the sys admin side of things. However, she's got serious programming skills in Python/Javascript, understands CSS, is an excellent illustrator, and has good business skills to boot. Which means I needed Audrey not to be doing sys admin.

Solution: Platform as a Service

Platform as a Service, or PaaS, is where someone else does the majority of work involved in system administration. There are now dozens of companies edging into the Python capable PaaS space. We've been leery of using any of them but finally settled on Heroku after a long period of evaluation.

Why Heroku?

We choose Heroku for a number of reasons:

We competed in a Los Angeles area Hacking contest with Randall Degges. He was responsible for the sys admin and went with Heroku. He got it up and it was out of the way for the competition. He spent his time coding, adding features, and fixing templates instead of tweaking knobs on something in the cloud. We saw other people not deliver products at the contest because of this issue.
Heroku doesn't lock you in. If I wanted to, I could take all the pieces out in about 10 minutes, then go old school and host it myself on my own closet server.
Heroku has very good PostgreSQL support. Our web framework is Django, which has an ORM that works best with PostgreSQL.
Heroku has staff. At least seventy of them. Odds are they would have people around 24/7 to deal with issues.
The add-on system means they've got many other people adding great new features. Want MongoDB? No problem! How about something to handle video? You got it!
Heroku scales up trivially. If we get an upswell of users, I just type heroku ps:scale web=50 and I've got 50 web server things handling the load.
When I think of Heroku I think of Puffer Fish. Which is awesome because Puffer Fish are awesome.

Creative Commons: Some rights reserved by Saspotato

Things that we really liked about using Heroku

As we progressed down the journey of building our site, we discovered even more nice features about Heroku. Here are some of the things that really make me smile:

Releases and especially rollbacks means we deploy with a lot more confidence.
Logging and other diagnostic add-ons like Sentry and New Relic means we know what's going on.
During one huge data migration effort I scaled up the workers so a 6 hour task became a 5 minute task. Cost was less then 10 cents for workers instead of me losing hours of labor.
In case we go viral, we don't have to worry about load balancers and all that high performance stuff.

What does that mean?

It means I'm doing the deployments. I'm the sys admin. And I'm happy with my role because it takes minutes out of my day. Me and Audrey team up on everything else and the results so far have been great. If you've ever worked with me, the fact that Consumer Notebook is administered and deployed by me is going to be a shock.

We've been able to really focus on development of the project. And when I mean development, I mean a lot of things. I mean:

Python
Django
HTML
CSS
JavaScript
Data Modeling
Documenting the API
Marketing: blogging on Consumer Notebook, Tweeting, and working with other groups
Trying out public tickets
Iterating through the user experience by communicating to users
All the boring legal and business stuff

What you don't see is anything about sys admin issues. That's because what could have been a huge sink in time and resources is pretty much gone. We deploy staging servers with a bit of code I copy/pasted from a bash history into a Fabric script:

from fabric.api import local

commands = """
heroku create --stack cedar
heroku addons:add memcache
heroku config:add S3_KEY=HAHAHAHAHAHA S3_SECRET=NOTGIVINGITOUT
heroku addons:add redistogo
heroku addons:add sendgrid:starter
heroku addons:add mongolab:starter
heroku addons:add sentry:test
heroku addons:add pgbackups
heroku addons:add custom_domains:basic
heroku addons:add zerigo_dns:basic
heroku domains:add staging.consumernotebook.com
heroku addons:add ssl:piggyback
git push heroku master
heroku scale web=1
heroku addons:add heroku-PostgreSQL:ronin
heroku pg:wait
"""

def build_staging():
    for command in commands.strip().split('\n'):
        local(command)

How awesome is that?

How much does Heroku really cost?

You can do Heroku for free. A lot of people do. More power to them.

But let's face it, beyond a certain point, every PaaS, including Heroku, is going to be more expensive then getting your own EC2, Rackspace, Dreamhost, or Linode hosted server. For a fraction of the cost, you can provision a server, install all the bits, configure the database, http server, load balancers, and even write Chef/Puppet/Fabric scripts so you can do it repeatedly at scale. Cheap!

So why pay more for Heroku? Why not just do it ourselves? For example, right now we're on dedicated PostgreSQL hosting which Heroku charges us $200/month. That's a lot, right?

Wrong.

Right now we're seeing a 50% increase in visits every day. So if we ran our own servers, Chef/Puppet/Fabric or not, odds are we would be spending at least 10 hours a month doing server work. And I can assure you that when we consult that we make more than $20/hour.

$200 < 10 hours of us doing consulting work to bootstrap the project.

Until you hit a certain point, these days the real cost of servers is labor. If you're a developer or small effort, and you think going with a cheap hosting provider is the way to go, think again. Think about the hours you're losing monkeying around with servers and databases instead of getting code done.

Heroku saves us money.

The Takeaway

One of the problems Django and other Python web frameworks has had is the difficulty of deployment. I can't tell you how many projects I didn't do because of the thought of handling the sys admin side of things. Let's face it, one of the great ongoing successes for PHP is that deploying the majority of sites is trivial.

With the rise of devops we've seen a lot of developers across languages and frameworks dive into Chef and Puppet. It's been sadly amusing watching people muck around with these great tools to make the deployment of 1-2 servers 'easier', when the real benefit of those tools has been to do things at scale. Things like deployments of fifty servers at once or deployment abstractions for hundreds of people (my fancy talk for PaaS).

In any case, things have changed. Deploying Python web apps is as trivial as deploying PHP code.

For developers I see great times ahead.

Discuss this post on Hacker News

I use this

2012-02-25T12:45:00Z

I had been meaning to do this for some time, and even had a nascent page for it on this site already. I just noticed my old friend Jessica Hammer was featured on usesthis.com. Then I remembered Kenneth Reitz blogged about his tools not that long ago. Looks like it is my turn now.

So without further ado, seven of my tools, specifically software.

TextMate

"My relationship with Textmate isn't healthy."

—Myself

I continue to use it, even though it's unsupported, has weird whitespace issues, and people make fun of me. I don't mean the EMACS/Vim people, cause they mock everyone, I mean people using Sublime Text 2, PyCharm, and NotePad on Windows. I try to make a brave face of it and for the most part I succeed.

Speaking of which, you know how you sometimes wish deep inside that the fairy tales of youth were actually true? Or that there was a zombie apocalypse and you got the chance to show off how all your eclectic skills and pursuits would make you a survival genius? Well, I feel that way about TextMates 2 being released in my lifetime. Alas, stark reality stares me in the face; yet I cling to hope.

Alright, sometimes I dabble in Sublime Text 2. I've played with PyCharm. In 2010 I even worked on a project where use of PyDev was mandatory. When I touch servers it's EMACS, Vi, or even Nano. And yet to TextMate I always return.

Is TextMate dead? Probably. And yes, someday I'll switch over to something else, probably Sublime Text 2. In order to be certain I'm starting to list all the Python editors so I can review them properly before switching.

Keynote

I never liked Powerpoint. I tried to use Google Presentations for years. Finally I tried Apple's Keynote for presentations and it was an amazing decision. It's simple, easy, and remains out of my way. To make code pretty I copy/paste pygmentized code and it just works.

Read the Docs

"Wikis are where documentation goes to die."

—Jacob Kaplan-Moss

I'm of the opinion that Python open source projects that don't have Sphinx documentation are not ready for production use. And if I have to decide between two projects that are close in capability and one of them isn't on Read the Docs, then you know which way I'll go.

Why?

Because I want my documentation as up-to-date as possible. Wikis often fail in this, so do custom documentation solutions, and so does upload tarballs to a service. You should be using the same patterns for documentation as you do coding. Use Read the Docs.

Heroku

When I first heard that Heroku had become yet-another-Python-PAAS, I shrugged. The field is crowded. We've tried a bunch, but never felt like committing a real project to this type of service.

After a coding contest in October over in Hollywood where Randall Degges served as sys admin for the project and tried out Heroku, I was impressed. Heroku provided a nice command-line interface and had an impressive feature set on it's own. A stand-out feature I noticed was the add-ons, which are Heroku moderated third-party plug-ins for their service. Finally, it didn't hurt that Heroku has the staff to provide 24/7 coverage of their servers.

We decided to give it a try and the results are that Consumer Notebook is hosted by Heroku. We're more than pleased, and I'll be blogging about the advantages of PaaS over doing-servers-yourself in a future article.

1Password

For all my umpteen accounts they all have different, crazy obscure passwords. All I need to do is remember one password and I've got access to them. What is even better is that it allows me to look up passwords in a crowded room - they are kept obfuscated by the password **** field. So much better than trying to keep it all in my head, or relying on weird coding patterns.

Consumer Notebook

Yup, I eat my own dogfood. It lets me build comparison grids or look at what other people are comparing. I can list stuff for any purpose, and turn the content of those lists into grids. It is still in BETA, so things are still under development. However, on the other side, since I'm the one building and using it, I get to determine the features going in or coming out.

Mac OS X

I started as an Apple user:

I use Mac OS X professionally and have done so since 2006. However, between autumn of 1985 and 2006 I used MS/DOS and Windows (deployments usually to Unix/Linux). Not by choice but by hard reality of management decision. In September of 2006 as I started to learn Python work gave me an old, discarded Macbook Pro. Since then coding on OS X and then deploying on Linux has been my pattern. I've followed this pattern ever since, and I'm going to hit six years now as an OS X user.

PyCon Australia 2011 Review

2012-02-24T12:45:00Z

In June of 2011 I had the good fortune of having my then girlfriend, Audrey Roy, now fiancee, invited to present a keynote speech at PyCon Australia 2011.

I was terribly excited for her to get that invitation, and that excitement was compounded when they allowed me to present on Confessions of Joe Developer.

Travel is a passion of mine, and it's only been since 2007 that I've gotten a chance to do much seeing of the world. Australia was always this distant goal of mine, but I never thought I would get the chance to go. Fortunately, my assumption was wrong and we landed on August 18th in Sydney, Australia!

Audrey wrote her own statement about the event right after we were done. She's good that way. Okay then, off to my own review. This is belated, but better late then never, right?

Conference Rooms

The Sydney Masonic Center was the venue and it was a really curious building. They built it a while ago, then apparently grafted an office building onto the top of the temple. You have to see it to believe it.

The main temple room was room, interesting, and fun. The acoustics, to my limited ear, seemed quite good. The alternative rooms for some of the tracks were small presentation rooms, which did quite nicely except when the organizers chose popular talks for small rooms and things overflowed. Everyone was good natured about that and we all just worked it out.

Result: Great

Speakers

I'm partial but I think the opening keynote by Audrey Roy about diversity was wonderful. Mary Gardinar also talk about open source projects trying to change the world that need our support. Raymond Hettiger seriously delivered the goods with another version of his amazing talk about what makes Python great. Whatever you do, go and see it as many times as possible because he changes it each and every time. Richard Jones' presentation on the Zen of Python was very solid too, and I'll use this as an opportunity to promote my Anti-Zen of Python.

When it came time for me to present on Confessions of Joe Developer, I finished way too early; plus me and Audrey felt the talk was not technical enough. Even though the reception for my talk was very positive, based on that experience and observation we ramped up the technical content for DjangoCon US and I delivered a much stronger talk. I want to thank the Australian Python community for being a wonderful audience.

The rest of the talks I saw were all quite good, in fact the one on decorators was incredible.

Result: Super

Conference Meals

The night before the conference, Frends/mentors Russell Keith-Magee and Malcolm Tredennick took me to a sushi-train place and we gobbled down some very nice raw seafood. Call me silly, but sushi on moving plates just tastes better! Thanks guys!

In between talks they served nice little sandwiches. The coffee bar had lovely Flat Whites and considering the quality of dairy in Australia I was very happy with the break food.

The first night of the conference they served an amazing, amazing meal. The lamb was like nothing I've tasted before - my best way of describing it was "so this is how lamb is supposed to taste". We also got served Pavlova, which Audrey really enjoyed.

The last evening of the conference we went out to a famous Sydney gastropub/brewery and got kangaroo and crocodile pizza. The kangaroo was outstanding, but the alligator wasn't my thing.

After the conference we went with Graham Dumpleton to a wonderful Dim Sum place and I stuffed myself silly while Audrey quizzed Graham on WSGI. I was sleepy for the rest of the day.

Pounds gained? Many.

Result: Superb

Parties

There were some lovely dinners and hang-outs. It was incredible putting faces to names and personalities. Everyone looked as I imagined, which meant they looked smashing. Events tended to be lower key, which can make for some wonderfully nice, cozy conversation.

Result: Good

Accomodations

There was no official conference hotel so we stayed at World Hotel - in easy walking distance of the conference center. It wasn't cheap, but I've learned from painful experience that when you travel to a conference, you want to spend your time at the conference, not going to-and-from a cheap hotel five miles away.

The staff of the hotel were very nice and helpful. Unfortunately they were working around the limitations of their building. The rooms were really tiny and rather stuffy. Normally that isn't an issue since we spend a lot of our time outside the room, but in this case Audrey was polishing her talk and needed a quiet room.

Result: Average but not the fault of the conference

Sprints

We talked with Richard Jones about PyPI authentication issues, and he decided to go with OpenID. Personally, I would prefer OAUTH but I'll take whatever I can get. On the behalf of the community Mark Rees implemented OpenID on PyPI at the sprint so things like http://opencomparison.org can support the community better. One goal at PyCon 2012 is to get that working as another authentication system.

Otherwise I closed bugs and worked lintification of the project. Audrey and a couple Australian PyLadies, Elena Williams and Jenny Nguyen, worked some core Django documentation tickets. We didn't get as much done as we hoped thanks to an outside distraction, but the organization of the sprints was top-notch.

During the sprint, those crazy Australians taught us how to do a Tim Tam Slam. It's rather scary and not for the faint of heart.

Result: Great

Overall Result

The conference was run professionally. The leadership was on the ball. The few issues that cropped up were taken care of, certainly better then what I would have done. Thank you everyone who put it together or just gave us a great time: Tim Ansell, Richard Jones, Nick Coghlan, Russell Keith McGee, Graham Dumpleton, Malcolm Tredennick and many others.

Australia was amazing. The people were wonderful. I wish we had more time to go sightseeing and relax, but we were off all too quickly. I could write a book about the experience.

Combined Result: Great

My PyCon 2012 Schedule

2012-02-22T09:00:00Z

Here I was thinking that this year's PyCon wasn't going to be so busy because I didn't submit a talk or tutorial. Ha! What the heck was I thinking?

Here's what I've already got in the works.

Wednesday, March 7th

Me and Audrey are driving up from Los Angeles. I've wanted to do this drive for a while, so this is very exciting. We'll arrive in the evening and hopefully tag up with friends old and new.

Thursday, March 8th

I'm moderating the Code Reuse panel of the Python Web Summit. Have you submitted a question yet?

In the evening we'll be helping assemble bags for the conference. That's always a blast.

Friday, March 9th

PyCon really begins! I'll be at the keynotes, and then the talks begin. These are some of the talks I'm really leaning towards watching:

The problem, of course, is that all the talks look awesome. Missing some of these talks is going to hurt.

In the evening we're going to the New Relic/Loggly/Skull Candy party and hang out at the (in)famous TIP BOF.

Saturday, March 10th

I'll be at the Consumer Notebook Startup Row booth all day! Come and hang out with us and all the other bright, new companies.

In the evening I'm hosting the PyCon Capoeira Open Space. We've got a seriously large room assigned for the event, and over twenty five people currently signed up to participate (there's still room for signups). Even if you don't want to play a musical instrument or learn/play at Capoeira, come anyway to watch. Some of the players there have some seriously amazing skills - I can assure you've seen them in the movies.

Sunday, March 11th

More talks!

Monday March 12 - Thursday, March 15

Sprints! Nothing set in stone yet, but some ideas I've had include:

Launch python.opencomparison.org for all of Python.
OpenComparison integration of PyPI OpenID, SourceForge OAUTH, and BitBucket OAUTH.
Improved OpenComparison integration of the Launchpad API.
Implement Gitorious API for OpenComparison.
Implement Text Based search for OpenComparison.
Hack on Mongo related technologies such as django-mongonaut and some other planned projects.

Selected for PyCon StartUp Row

2012-02-21T01:00:00Z

Me and Audrey have been working hard on Consumer Notebook, a Python/Django based project. We submitted it to PyCon StartUp row and found out this morning we've been accepted. Hooray!

From the PyCon StartUp Row winner's post, here is a little bit of what we're about:

Have you tried researching products online recently? Search engines are gamed by scammy marketers. Product review sites overwhelm you with ads, have unreliable reviews, or dryly compare raw product specs. Consumer Notebook is working to solve this problem. It is like Yelp for products, with product comparison grids inspired by the founders' open-source work on Django Packages and Open Comparison.

Just so you know, PyCon in North America is the biggest gathering for the international Python community. The conference this year is in Santa Clara, California, and is sold-out at 1500+ attendees, but could have easily sold out several times that number. The talks, tutorials, and events are going to be incredible, and I'm delighted to be part of the PyCon experience!

We look forward to sharing the StartUp Row with friends like Transifex, Python Packages, and Wedding Lovely.

Please check out Consumer Notebook right now and also visit our PyCon booth on Saturday, March 10th and we'll show you what we're doing.

Parsing MongoDB URI

2012-02-20T09:20:00Z

Rather than hard-code the configuration into a Python based settings file, when using a PaaS such as Heroku you want to pick up the MongoDB URI from the system settings. Here's what I do:

# get the dynamic elements from the MongoURI
import os
import re
r = r'^mongodb\:\/\/(?P<username>[_\w]+):(?P<password>[\w]+)@(?P<host>[\.\w]+):(?P<port>\d+)/(?P<database>[_\w]+)$'
regex = re.compile(r)
mongolab_url = os.environ['MONGOLAB_URI']
match = regex.search(mongolab_url)
data = match.groupdict()

# Save the data to settings
MONGO_HOST = data['host']
MONGO_PORT = int(data['port'])
MONGO_NAME = data['username']
MONGO_DATABASE = data['database']
MONGO_PASSWORD = data['password']

# Connect to MongoEngine
from mongoengine import connect as me_connect
me_connect(
    data['database'],
    host=data['host'],
    port=int(data['port']),
    username=data['username'],
    password=data['password'])

django-uni-form end of life

2012-02-18T01:00:00Z

I started on django-uni-form in January 2009. In order to use Pinax on an internal social network for NASA HQ, we had to render all content, including forms, Section 508 compliant. Rather than rewrite the html for all 50+ forms that existed in the Pinax 0.5.x framework at that time, I decided to minimize my work and automate things. James Tauber gave guidance and insight, my co-workers were supportive, and Jannis Leidel suggested the Uni-form library. The name Django Uni-Form was obvious, and lo the project was named.

Looking at the old, extremely deprecated Google Code site for django-uni-form, I see that the first commit happened on January 7th, 2009. That was for version 0.1, with some core code that was literally a merger between the Django form example on how to integrate divs into forms and the simplest template tag I could figure out.

The python code in uni_form/templatetags/uni_form.py:

from django.template import Context, Template
from django.template.loader import get_template
from django import template


register = template.Library()

@register.filter
def as_uni_form(form):
    template = get_template('templates/uni_form.html')
    c = Context({'form':form})

    return template.render(c)

The template tag code was nearly exactly copy/pasted from the starter Django docs on forms:

{% for field in form %}
    <div class="ctrlHolder {% if field.errors %}error{% endif %}">
        {% for error in field.errors %}
            <p class="errorField">
                <strong>{{ error }}</strong>
            </p>
        {% endfor %}
        {{ field.label_tag }}
        {{ field }}
        {% if field.help_text %}
        <p class="formHint">
            {{ field.help_text }}
        </p>
        {% endif %}

    </div>
{% endfor %}

Using it was trivial, you just wrote out:

{% load uni_form %}

<form>
    {{ form|as_uni_form }}
</form>

Days of django-uni-form

Leading up to PyCon 2009 James Tauber suggested some things that lead to the FormHelpers, and we hammered out the API on IRC. We knew it crossed the rigid lines between Model-View-Template, but sometimes it's advantageous to break a few rules and abstractions in order to get better things down the road

At PyCon 2009 with the mentoring of Jannis, James, and Brian Rosner, I moved the project from google code to Github. Jannis released it on PyPI and I followed the pattern he showed me for two years. Yeah, I learned tons under those guys.

After PyCon 2009 a pull request with the Layout helper was provided. It took some work to make it pass all the tests and use cases, but the end result was definition of form layout in the Python. This broke the rigid battle lines of Model-View-Template and left purists screaming in agony, but it certainly made working with forms in Django trivially easy.

Lots of people started to use the project across projects like Pinax and organizations like NASA, PBS, Discovery Channel, various newspapers and many others. Lots of pull requests came in and the features grew.

In 2010, Alice Rowland submitted the first Sphinx docs, and it was her work that really helped get me started on doing lots of Sphinx work.

And, all the way into 2011, pull requests for Django Form Sets started to come rolling in, and almost none were of acceptable quality. They never came with documentation, tests, and almost always broke existing tests really hard. Since I'm not a huge fan of Django FormSets, I didn't want to put in a ton of effort making them work. I believe one of them was pretty good, but life was crazy busy at the time and I let it slide. Apologies to whoever it was gave me a working FormSet pull request with documentation, tests, and working code.

Long periods were going by without new versions. I admit I often slow about accepting pull requests. Life was busy and reviewing the incoming code took a lot of time. Browser cross-checking, running tests, and more was really time consuming. I tried to get others to become co-leads on the project, but invariably they didn't have time to do it. Note: If someone asks you to co-lead something, respond in 24 hours.

Enter Miguel Araujo

After PyCon 2011, when there was some unpleasant stress in my life, I woke up cranky one morning and mouthed off on twitter to this guy who asked me to accept a pull request on django-uni-form. This guy tweeted back to me saying I ought to be nicer since I had a library people liked.

He was right.

I apologized to the guy (Miguel Araujo) and remembered my manners. Over the next couple of months we chatted via Twitter and Github's messaging system. He was smart, trustworthy, and passionate about everything he did. I knew I had found my co-lead. He responded promptly and I gave him commit rights.

Working together (with him doing the vast majority of the work), we moved the project into new releases. The architecture and design changed, driven by discussions we had together. The code was cleaned up, gnarly bits in there to support old versions of Python and Django kicked out, and the documentation revised. The project had new life!

The only blip I saw with Miguel is my own fault of sometimes being too nice as a project leader when it comes to accepting pull requests. I believe pull requests should be really atomic - for one thing and one thing only with support tests and documentation. Otherwise it becomes nigh impossible to incorporate them and these days I reject multi-purpose pull requests. One pull request in particular took a huge amount of debate and discussion to work in. I think after that Miguel is much better at being upfront at the beginning about rejecting pull requests with giant scopes.

During all this I asked Miguel to take over the project, he accepted, and I even blogged my announcement his role as project leader. Miguel is indeed very nice and after that fact he asked me to remain on board as co-lead.

We finally met in September of 2011 and co-presented on Advanced Django Form Usage at DjangoCon 2011. The deepest technical material we presented was authored by Miguel. During our research he uncovered at least one bug in Django and got an ancient bug closed. It was a great experience and I hope he'll co-present with me in the future.

django-uni-form is dead, long live django-crispy-forms

The upside of django-uni-form is that it grew in features organically thanks to my own needs and general community effort. The downside of django-uni-form is that it grew in features organically thanks to my own needs and general community effort. In any long running project there is cruft and weird patterns that start to hurt after a while. django-uni-form was no different.

So I'm making this absolutely official as of now. django-uni-form is at it's end of life. It's done and kaput. No more pull requests will be accepted and the issue tracker will be turned off shortly. Just so no one is mistaken:

django-uni-form is deprecated. Use django-crispy-forms

Miguel asked if he could start the project anew, under a different name. We both had been uncomfortable with the name django-uni-form for some time, especially since it had almost nothing to do with Uni-form anymore. In fact, I often using template overrides to avoid the Uni-form HTML layout - the most common alternative being Twitter Bootstrap.

We tossed around names for the project, but all of them were stupid, especially mine. We are both huge fans and users of django-floppyforms (HTML5 form widget app), so my fiancee, Audrey Roy, suggested django-crispy-forms. And lo, the project was named.

Right now django-crispy-forms has an improved API, better performance, and supports both Twitter bootstrap forms 2.0 and UniForm. Adding new form layouts will be easier, and feature controls will be better.

What you should be using now is django-crispy-forms. Don't worry about changing over as there are migration instructions on the excellent documentation.

Try it. You'll like it. :-)

Two years ago today

2012-02-17T09:20:00Z

The PyCon tutorial on Django in Depth was ending. I had been sitting next to my friend Barbara and we got up to go when I heard a feminine voice ask: "Are you bshaurette?" I turned and it was like I got punched in the gut.

It was the first time I met Audrey. I remember every detail of how she looked at that moment. The clothes she was wearing, the part in her hair, that her eyes met mine, and that they didn't turn away. I was immediately captivating, but fortunately remembered to act like a gentleman. I tossed in a casual invitation to her to join us for lunch, which I pulled off even though my heart was pounding. Thankfully she accepted.

Life has been pretty much awesome ever since.

That was the day I met the love of my life.

My new blog

2012-02-17T00:30:00Z

What I did to get it running:

pip install pelican
git clone git://github.com/pydanny/pydanny.github.com.git

My settings.py file:

AUTHOR = 'Daniel Greenfeld'
DISQUS_SITENAME = 'pydanny'
GITHUB_URL = 'https://github.com/pydanny'
GOOGLE_ANALYTICS='UA-18066389-2'
SITEURL = 'http://pydanny.github.com'
SITENAME = 'pydanny'
SOCIAL = (('twitter', 'http://twitter.com/pydanny'),
          ('github', 'https://github.com/pydanny'),
          ('facebook', 'http://www.facebook.com/daniel.greenfeld'),)
TAG_FEED = 'feeds/%s.atom.xml'
THEME='notmyidea'
TWITTER_USERNAME = 'pydanny'

How I push up entries and pages and themes:

pelican . -o . -s settings.py
git commit -am "blogging here"
git push

Results!

http://pydanny.github.com

Tried out Jekyll

2012-02-09T10:20:00Z

Why Jekyll?

I've had issues with Blogger for some time. After my fiancee, Audrey Roy, moved her blog to https://github.com/mojombo/jekyll, I was impressed enough to give it a try.

Why did it impress me?

Code highlighting made easy

I don't have to hand-craft HTML code to get google prettify in a post. I just stick in a simple macro of 'highlight python' called like a Django templatetag and I get:

name = 'Daniel Greenfeld'
for letter in name.split():
    print(letter)

This issue alone sums up why I don't do more blog posts with code.

I don't want to maintain my own blog site

I want to be able to write without connection

I need an internet connection to get my blogger posts to format right. With Jekyll, I can just type away.

Ability to publish via git

My http://pydanny-event-notes.rtfd.org has really exploded in my own usage and continued because it uses the same patterns I use in software development. I'm used to the pattern of using Git to push up content, so why use naked HTML? Sure, there are RST-to-HTML processors that I could use to generate that HTML, but they always require an some amount of manual correction. Jekyll, and it's alternatives,let me just write.

Why not Jekyll?

Jekyll is written in ruby. Nothing against ruby, but I can't trivially work in that language the way I can in Python. It's good to eat your own dogfood.

So I started looking at hyde, blogofile, and pelican as alternatives. More on that later.