Makai's Blog

I came across this blog post on the Python Ecosystem while reading Hacker News yesterday. What a fantastic post. Highly recommended reading for aspiring Python developers.

Link: Python Ecosystem

To understand Django, it helps to know its origins and how the framework has evolved. Django’s developers have added many features since the framework’s 1.0 release back in September 2008. Some of the major additions include aggregation support in the ORM, multi-database support, CSRF protection, a messaging framework, and many improvements to the models framework. This post outlines the major framework changes Django has gone through from 1.0 through the current stable 1.3 release. The intention for 1.x releases is that only minor code changes are necessary to transition Django projects from one version to another.

Django 1.0

(1.0 SVN Revision 8961, 1.0.4 SVN Revision 11613) [1]

Django 1.0 was released September 3, 2008 after a three year public incubation period and a total of five years of development [2]. Release 1.0 included features that are still core to the framework today, including the Model-Template-View (MTV) architecture, Object-Relational Mapper (ORM) models, explicit URL resolution with regular expression support, and a lightweight template system.

Django 1.1 

(1.1 SVN Revision 11366, 1.1.4 SVN Revision 15477)

Django 1.1 was released Jul 29, 2009, just shy of 11 months after the official 1.0 release [3]. Version 1.1 included the following new features:

1. Aggregate query support in the built-in object relational mapper
2. Improvements to models
3. Better support for unit testing through client object’s support functions
4. URL namespaces

Django 1.2

(1.2 SVN Revision 13285, 1.2.5 SVN Revision 15476)

Django 1.2 was released May 17, 2010, approximately 10 months after the 1.1 release [4]. Major features added to Django in this release:

1. Mandatory Cross Site Request Forgery protection for POSTs
2. Support for more than one database in a single Django project
3. Model validation based on the existing Forms validation mechanism
4. User messages support through sessions and cookies
5. Configurable email backends

Django 1.3 

(1.3 SVN Revision 15906, 1.3.1 SVN Revision 16771)

Django 1.3 was released on March 23, 2011 [5]. New features in Django 1.3 included:

1. Class-based views
2. Support for Python’s standard logging mechanisms
3. A new contrib app for serving static files

Django 1.4 and Beyond

There is currently no release date set for Django 1.4 although work continues in the public development branch. Django 1.4 will drop support for Python 2.4. The motivation behind the change is to use more context managers, a creation from Python 2.5, and make the internal Django code better. I wrote a post on Django 1.4 and how one of the Django core committers, Alex Gaynor, sees Django 1.4.

[1] Django SVN Revision 8961

[2] Django 1.0 Release Announcement

[3] Django 1.1 Release Announcement

[4] Django 1.2 Release Announcement

[5] Django 1.3 Release Announcement

I’m currently working on moving from my traditional Apache/mod_wsgi set up on Ubuntu to the new Django-serving community favorite, Gunicorn/Nginx.

I found the following links very beneficial for getting an initial set up going locally then moving over my production servers to the new configuration:

1. Run Django apps using Gunicorn and nginx (Easy set up)
2. Lessons Learned From The Dash: Easy Django Deployment (Another easy set up post)
3. Deploying Django (more detailed post on Django deployments and the stages heavily trafficked sites go through)
4. Preferred Django Stacks (Hacker News comments on what tools to use for a preferred stack)
5. How Yipit Deploys Django (this was really helpful for figuring out how Chef fits into Django deployment and it gave me another excuse to spend some time learning Ruby even though most of my work is done in Django)

Python Weekly has provided me a lot of value over the past couple of weeks. I originally found out about the newsletter on Hacker News. I thought, “I’ll try one newsletter then unsubscribe if it’s not worth my time.”

Boy have I been pleasantly surprised. There are loads of great articles on Django deployments, best practices for settings.py configurations, interesting pip packages, and tips on Python programming best practices.

Thanks to the curator for putting together what has quickly become a must-read for Python developers.

You can check out an example newsletter and sign up at http://www.pythonweekly.com/.

My primary piece of advice to college students who are computer science majors is this: double major.

Computer science is great for understanding how computers work, programming, and learning the theory of computation. But where it really matters is how you apply those principles to real world problems that exist outside the computer science field.

If you double major, you’ll be exposed to a different discipline and begin to understand its problems. Hopefully down the road you can use your computer science knowledge to create solutions to those problems and produce real value in that field.

That’s my 2 cents for college computer science majors coming from someone who’s far enough outside of school to have some perspective on how you can produce value.

I do the majority of my development work on virtualized Ubuntu instances to closely mimic my production deployment environment. Today I needed to access a Django server running on the VirtualBox instance from my host operating system (Windows 7).

I was simply using the built-in Django server (manage.py runserver) running on a high-level port instead of deploying to Apache or gunicorn. To do a pass through with this set up, use the following 3 steps:

1. Change the VirtualBox network adapter (Devices -> Network Adapter -> Adapter 1) to “Bridged Adapter” instead of NAT.
2. Inside the virtualized OS, run ifconfig -a to see the new inet addr (mine happened to be http://10.38.1.119.
3. Use the python manage.py runserver 10.38.1.119:8000 command (with your new IP address and the port above 1024 you want to run on) to run the Django server and allow external access

Now you should be able to access the Django server from your host OS through the browser at 10.38.1.119:8000 (again, replace with your specific IP and port number).

References:

[1] How to connect from Windows 7 to localhost on Ubuntu VirtualBox

[2] VirtualBox accessing ubuntu localhost thread

I needed push notification support for the Android C2DM platform for a Django project, but Urban Airship’s Python libraries only supported iOS push notifications.

So I forked the code on Github, modified it to incorporate support for C2DM APIDs. There’s an outstanding pull request (just issued) so hopefully it gets integrated back into Urban Airship’s official original master branch.

Thanks to Excella Consulting for allowing me to contribute this code back to the community!

There’s been a spat of links on Hacker News lately about the failings of MongoDB and 10gen (see links at the end). I see this as a very good thing, not because I want NoSQL in general and MongoDB in particular to fail, but because it is a sign of maturation. Developers are doing really interesting work with MongoDB and they are hitting the limits of the technology. There’s criticism of 10gen’s working process and concern over implementation choices.

If these concerns are addressed, MongoDB will be a much better, more mature product in the long run. We can only hope that CouchDB, Riak, and other document-oriented data stores receive the same amount of attention and feedback to address their unique sets of issues.

[1] Failing with MongoDB

[2] Don’t Use MongoDB

[3] We’re Back! …so long MongoDB

I recently realized I’m constantly looking for a fix. Not from an external drug or chemical substance, but from flow. I get flow most commonly from programming, although I’ve felt it before while writing and working out.

It’s scary though because I am constantly hungry for flow. If I haven’t had it in awhile I go looking for it. I browse Hacker News and Reddit Programming looking for new languages and libraries to learn. Recently I picked up Stripe and it provided a fix for awhile, just like Clojure, Hadoop, and other tools and languages before them.

But on some level I feel like an addict. Wikipedia describes addiction as 

… a continued involvement with a substance or activity despite the negative consequences associated with it.

Does the lack of (obvious) negative consequences make what feels like an addiction okay? Is the fact that I am constantly learning to try to get into flow make it alright since it makes me better at my software development job? On the surface these seem like good things to do, but maybe there’s something out of balance when you’re constantly looking for the fix.