I was pleased with the results and would love to see one at least once a month. Let’s see what August brings.

I figured I would give it a shot and run a few tests through the Mechanical Turk and see how it stacked up against some more traditional market research options. I grabbed my latest business idea–viability untested–and set off for Amazon.

Testing Business Viability

It’s worth noting the startup I was working on was a subscription-based consumer service geared towards parents of younger children and their grandparents. As Lindsey described in her article you get no segmentation or guaranteed panel refinement on Mechanical Turk so I was at the mercy of self-selection. I specified in the task description I was looking for parents of children of a certain age and let it go.

I posed some very basic demographic questions (e.g. gender, age(s) of their children, age). Once I had some basic information on the respondents I probed if they face the problem my service intends to solve. Once I described the service, the survey asked how likely they would be to use it and how likely they would be to recommend it to others. There were also a few service-specific questions, some open-ended responses including, “why would you not use the service,” and a general thoughts and feedback form.

I actually had some fancier survey question types than I cared to implement through Amazon’s Mechanical Turk API so instead I hosted the survey over at SurveyMonkey and had the respondents enter a confirmation code into MTurk upon completion.

Results: Well look at that…

Not bad. MTurkers ended up providing fairly similar answers to those I received in the wilds. After some light data trimming the data sets were very similar. Responses to the “How likely would you be to use this service” question were pretty similar between the MTurk panel and my other groups; statistically there was about an 80% chance the response groups were pulled from the same population. The response patterns were slightly shifted, but the overall outcome was the same.

The data trimming was done to account for a  larger than expected number of MTurk respondents who were very price conscientious. Their responses described ongoing harsh economic conditions, the need to save money, and other general hardships. These folks were generally not represented or targeted in my other surveys.

As a bonus, the optional open-ended responses given by MTurk respondents were thoughtful and very useful. I was not expecting this level of detail. The optional open-ended question about general thoughts and feedback elicited a 47% response rate with an average of 40 words per response. That mean came with a standard deviation of 32 words per response–there were some really thoughtful responses in there.

Semifinal Thoughts

Would I use Amazon’s Mechanical Turk for this purpose again? I think so. It seems to be a good way to get a general feel for your idea and certainly grab some helpful feedback. The responses I received led me to believe it was a very thoughtful community.

In no way am I endorsing a survey of this type to be the entirety of your market research. This is a cheap and easy way to get some feelers out there and validate that you’re not (too) crazy. In the end it is still very important to get out there yourself and talk with potential customers early on.

FYI: The result of this work has become GlitterDuck. I am getting ready to start some pilot runs soon. If you are interested in learning more or becoming a beta tester please sign up over at the site.

After a day or two of toy and experimental projects I started missing one of my primary git utilities–Gitosis. Gitosis is a package that lets you and all your collaborators interact with your git repositories using a single user account over SSH. Gitosis manages user authentication and permissioning using a system of  shared keys without ever exposing actual shell functionality.

It took me a little while to find mercurial-server by LShift, which seems to be Mercurial’s equivalent to Gitosis. So, here is how I got Gitosis-style shared key repository management to work with Mercurial.

Installing Mercurial-Server on Ubuntu 9.10 (Karmic)

Luckily, Paul Crowley of LShift, the author of mercurial-server, has volunteered to manage a Debian package for Mercurial-Server, which makes our lives easier. Thanks!

Install the Mercurial-Server Package

Add the following line to your /etc/apt/sources.list file replacing the url with a mirror that’s appropriate for your location:

deb http://mirrors.kernel.org/ubuntu lucid main universe

$ sudo apt-get update
$ sudo apt-get install mercurial mercurial-server

OR, if you want to install the package manually outside of synaptics or apt you can download the .deb from http://packages.ubuntu.com/lucid/all/mercurial-server/download and then:

$ sudo dpkg -i mercurial-server_1.0.1-1_all.deb

Mercurial-Server should now be installed. Additionally, a new user hg has been created and will be used to manage all your interactions with your mercurial repositories.

Setting Up Mercurial-Server Administrator (root)

You now need to grant yourself administrator rights. All permissioning is done with keys, so you’ll need to copy your public key to mercurial-server’s admin keyring:

$ sudo cp id_rsa.pub /etc/mercurial-server/keys/root/YOURUSERNAME
$ sudo -u hg /usr/share/mercurial-server/refresh-auth

The second command refreshes mercurial-server’s authentication system–authorizing your account as an administrator. You’re good to go!

Managing Mercurial-Server

The hgadmin Repository

Just like gitosis’ gitosis-admin repository, mercurial-server’s functionality can be managed via hgadmin. Go ahead and clone the repo:

$ hg clone ssh://hg@MyMercurialServer/hgadmin

Adding New Users

With your hgadmin repository cloned you can now grant access to new users via their public keys

$ cd hgadmin
$ mkdir -p keys/users/
$ cp ~/kurt-key.pub keys/users/kurt
$ hg add
adding keys/users/kurt
$ hg commit -m "Added Kurt's public key"
$ hg push

You can also allow and organize multiple keys per user. In that scenario you create a directory of keys for each user:

$ cd hgadmin
$ mkdir -p keys/users/kurt
$ cp ~/kurt-home.pub keys/users/kurt/home
$ cp ~/kurt-work.pub keys/users/kurt/work
$ hg add
adding keys/users/kurt/home
adding keys/users/kurt/work
$ hg commit -m "Added keys for Kurt's home and work computers"
$ hg push

Creating New Repositories

As administrator, if you want to create a new repository you simple clone a mercurial project to a path on your mercurial-server. For example:

$ cd my_hg_proj
$ hg clone . ssh://hg@MyMercurialServer/my_hg_project

Now you and your collaborators can clone, push, and pull from the server’s repository just as we did with hgadmin. For example:

$ hg clone ssh://hg@MyMercurialServer/my_hg_project

Managing Repository Permissions

Now that you’ve created your repositories and added users you will want to manage permissions. Repository permissions can be managed through an hgadmin file called access.conf. I recommend reading the mercurial-server documentation for more information on managing security.

So far I’ve found mercurial-server to be a great way to collaborate with others on private repositories outside of Bitbucket. My hat off to Paul Crowley and LShift.

I was looking around for ways to keep Nose from searching for tests in certain directories. You see Nose is a nosey little critter that will scour every nook and cranny of your directory structure looking for unittests to run. Really, it wants your code to work and it loves making dots. But, see I knew better and knew if that little Nose test discoverer ventured down a few rabbit holes it would end up in a world of pain–segfaults or worse. I just wanted to avoid the whole mess and just have Nose exclude a few directories from its massive testhunt.

I asked a few people I know who use Nose regularly about my options. “Write your own plugin,” was the consensus. Nose’s architecture makes it very easy to write plugins for just about every aspect of its behavior…check out its plugin api. The project documentation is also very helpful in this regard.

I spent most of my time trying to figure out how to test my testing plugin. In the end it only took a couple of hours to go from Nose novice to having written a packaged, testable Nose plugin. So, here’s a quick example of how you would use this new nose-exclude plugin:

 $ ls test_dir
dir_with_tests    dir_with_bad_tests
there_be_dragons_here    more_tests

In this example, I want Nose to ignore a couple directories and not even bother searching them. You would run:

 $ nosetests --exclude-dir=test_dir/dir_with_bad_tests \
 --exclude-dir=test_dir/there_be_dragons_here test_dir

You could further specify to exclude subdirectories if you wanted that level of control. There is also an –exclude-dir-file= option available that allows you to specify a file containing paths to be excluded.

$ nosetests --exclude-dir-file=exclude_dirs.txt test_dir

nose-exclude is pretty simple and covers a fairly basic use case so hopefully others will find it useful. For now nose-exclude is available on bitbucket, but will be up on PyPI shortly.

Almost two years ago I was in a rather unlikely situation in that I was running a software engineering department containing both a C# team and a Python team. The Python group was focused on building scientific computing and NLP-type applications, whereas the C# team was focused on building web applications.

A few of us Python folks in the department had already started playing around with Django–building internal web applications and projects outside of work. It did not take long for us to realize the power of Django and how quickly we were able to produce high-quality applications with little effort. This was my (strong) impression, but in order to propose a corporate platform shift I was going to need some data to support my claims.

It slowly dawned on me that I had a perfect test bed. Here we had two teams using different technology stacks within the same department. The same department. That means they shared the same development processes, project management tools, quality control measures, defect management processes. Everything was the same between these groups except for the technologies. Perfect! So like any good manager I turned my teams into unwitting guinea pigs.

The Hypothesis

We can accomplish more with Python + Django than with C# + ASP.NET given the same amount of time without sacrificing quality

Measuring Productivity

For the sake of this study, I defined productivity as a normalized team velocity: how many story points were completed / developer / week. I record the normalized team velocity for each team’s sprint for later analysis.

For those of you unfamiliar with the concept story points I highly recommend Mike Cohn’s Agile Estimation and Planning.

WAIT! You can’t compare story points between teams!

I hear this a lot. Yes, you can. The problem is that most people do not bother creating a common scale or continually calibrate their estimations (within or between groups). Generally, it’s way more work than most groups need to deal with and it doesn’t deliver much utility to most groups so it isn’t often discussed or practiced.

The methods described below should outline the additional calibration work that was performed to ensure a common estimation scale between the two teams.

Methods

Both teams continued business as usual working on projects in parallel. Each sprint consisted of 3-4 developers. It is worth noting that Team ASP.NET did not make use of MS MVC Framework, but they did use Linq-to-SQL for its ORMy powers.

Special care was taken to maintain linkage between the two team’s effort estimates. During sprint planning, each team would use a common story point calibration reference when making estimates. In order to detect any potential deviations in calibration, during several planning poker sessions I included stories that had already been estimated during previous sprints or by the other team; no significant deviations were found.

At the end of each sprint I would calculate the normalized developer velocity ( # of completed story points / developer / week ). These values were recorded for both teams. It should be noted that only Django-based sprints were used in analysis for Team Python.

I recorded results for approximately 6 months.

Results

Normalized Developer Velocities: C# + ASP.NET and Python + Django

The above histogram shows the distribution of normalized velocities associated with each completed sprint. The table below summarizes the distribution of velocities associated each team.

The distribution of velocities between the two samples are similarly shaped, but have clear differences in their mean. The average velocity of a  C#/ASP.NET developer was found to be 5.8 story points/week. A Python/Django developer has an average velocity of 11.6 story points/week. Independent t-tests reveal these differences as being statistically significant (t(15) = 4.19, p<7.8e-4).

Discussions and Conclusion

Given our development processes we found the average productivity of a single Django developer to be equivalent to the output generated by two C# ASP.NET developers. Given equal-sized teams, Django allowed our developers to be twice as productive as our ASP.NET team.

I suspect these results may actually reflect a lower bound of the productivity differences. It should be noted that about half of the Team Python developers, while fluent in Python, had not used Django before. They quickly learned Django, but it is possible this fluency disparity may have caused an unintended bias in results–handicapping overall Django velocity.

Epilogue

The productivity differences quantified by our findings were then included as part of an overall rationale to shift web-based development platforms. Along with overall velocity differences, the costs associated with maintaining each environment were considered: OS licensing and database licensing for development and production environments, as well as costs associated with development tools. I’m happy to say we are now a Python and Django shop.

Updated:

Several good questions over at Hacker News

I presented Fabric as a tool that I use for automated deployment and maintenance of servers. I can publish and update multiple servers with differential instructions based on their defined roles (e.g. Apache web server, MySQL database server, Nginx server, etc.). We briefly touched on some other cool things you can do like database maintenance, database dumps, backups, Django contribs for remotely working with Model objects, and even toggling maintenance modes for your website.

The next part of the presentation dealt with another use I’ve found for Fabric: bootstrapping a server. The ease of automating distributed systems made Fabric an ideal tool for lightweight configuration of a newly installed OS. Go ahead and have it apt-get/yum/emerge whatever packages are going to be required–again as specified by its defined role. For instance, I have a few fabfiles that will prep an Ubuntu or a RHEL servers for serving Django apps with Nginx, Apache+mod_wsgi, and MySQL.

So, the most common questions and comments I’ve received have been along the lines of “Why not just build packages and meta packages for each server configuration?” This is absolutely an approach that one could take and a powerful one at that. I’ll be the first to admit I am not a packaging whiz so the thought of building a slew of .debs and then maybe parallel .rpms if we have to migrate to a new platform based on the client or project is not super appealing, but luckily I work with people smarter than myself who enjoy that sort of thing.

The sweet spot I’ve found for bootstrapping servers with Fabric is where your server configuration may not be final, the project maybe short term, you may still have to switch between distros, and you do not have access to VMs that can be cloned.  Fabric is lightweight and available for your more ephemeral projects that may not necessitate the effort required to build custom packages.

For instance, one place Fabric is handy is prepping Amazon EC2 servers for quick compute jobs. Now I could go ahead and create custom AMIs for every one-off project, but Fabric makes it easy to spin a server up and then bootstrap it with the required packages for a particular project. Nice and lightweight.

I would love to hear about other tools people are using out there. It was nice that after my presentation a bunch of people shared their tools and methods for bootstrapping servers. Og Maciel and other rPathers demonstrated rPath’s rBuilder Online and how it can be used to easily build packages and entire system images or VMs based on sets of packages and a few clicks. Tobias McNulty of the Caktus Consulting Group also demonstrated his work on Mallet, which can be used to quickly build and configure Debian-based servers. Mallet is also available through PyPI.

Overall a great turn out and I learned a lot. Thanks folks!

Thanks again to the Caktus Consulting Group, Carrboro Creative Coworking, MetaMetrics, Capstrat, Karen, and everyone who showed up to make the event happen.

I managed to be perfectly eclipsed in this picture…

We are organizing a Django sprint here in the Triangle on December 12th and 13th 2009 (Saturday & Sunday). The sprint is being hosted by Caktus Consulting Group over at Carrboro Creative Coworking.

The goal is to get folks familiar with the Django development process and knock out some features and tickets associated with the upcoming release of Django 1.2.

You can find more details on the Sprint Wiki: http://code.djangoproject.com/wiki/Sprint200912TriangleNC

Sign Up Here…

Sponsors

Thanks to Caktus Consulting Group, Carrboro Creative Coworking, and MetaMetrics for helping sponsor this event.

Hope to see you there!

We were anxiously looking forward to Alex Gaynor’s multidb efforts, but needed something in the near term to help our site scale. After looking at a few options, including building our own, we settled on Mike Malone’s django-multidb. I first heard about Mike’s django-multidb in his Scaling Django Presentation. It was a perfect solution for our needs: it gave us the ability to manage master-slave databases within Django, it was very simple, and offered just the right amount of flexibility.

The Problem

We started receiving sporadic UnicodeEncodeErrors. The tracebacks were reporting that the system was unable to encode certain Unicode strings into latin1. Latin1? Who wants latin1? We use utf8 as our standard character set for both Django and MySQL (client & server).

So where was this latin1 encoding request sneaking in from? No rogue .encode(‘latin1′)s were popping up in codebase searches. The Django MySQL backend certainly looked like it was doing its job, but we had to validate that the cursors being generated were in fact being set with the appropriate charset. We followed the path back and eventually started intercepting a few MySQLdb cursors. Once we started debugging and probing cursors it became clear that they were in fact using latin1 as the default character set.

You keep using that word. I do not think it means what you think it means.

I learned an interesting tidbit along the way that explains why it took us awhile to diagnose the problem. When you don’t specify a character set or encoding, MySQL’s default encoding is called “latin1″. Except by “latin1″ MySQL does not mean “latin1″ of ISO 8859-1 fame, but rather the Windows cp1252 code page. This occurs even though MySQL does know what cp1252 is and is fully capable of honoring that character set separately by name. Really.

So, imagine MySQLdb asking the MySQL server what charset it prefers and the server replies “latin1″. MySQLdb then says, “Awesome, I know latin1,” and they go on chatting and passing information. This works just fine until the MySQL server passes back a bytestring representing a string once stored in its database containing the Unicode entity U+2019 ( ’ ). This RIGHT SINGLE QUOTATION MARK can easily be encoded in cp1252, but it cannot be represented by latin1 (The real ISO 8859-1 one). MySQLdb receives the cp1252-encoded bytestring and attempts to decode as if it were latin1 and lo and behold it throws an exception for attempting the impossible.

Now imagine the encoding mess occurring within a SQL query. MySQLdb opens a connection with the server, agrees to communicate using the latin1 charset, and then prepares to send a query containing a right single smart quote (U+2019). It takes the Unicode query string and attempts to .encode(‘latin1′).  BLAM! Encoding error.

The Solution

The problem ended up being an inconspicuous bug in django-multidb that restored Django’s backend cursor settings to system defaults, which resulted in any preferred character sets being ignored. The latin1-cp1252 confusion was then free to crop up.  I know many folks including myself looked right over the code and bug many times without noticing. No worries. Mike Malone has already patched the django-multidb repository over at github. So, at this point you just need to update your project with the latest django-multidb code and you should be good to go.

Regarding the MySQL-MySQLdb latin1 debacle, it seems simple enough to make MySQLdb call MySQL’s bluff. Maybe another time…until then I think I will avoid this issue and stick with explicitly defining utf8 as my character set of choice.

Django’s growing popularity

First off, it’s important to note that Django adoption is growing nationwide. The included chart shows the number of posted “Django” jobs found on Indeed.com over the past few years. Notice a trend? Jacob Kaplan-Moss estimates the Django community may have grown somewhere on the order of 2-3x from 2007 to 2009. I definitely believe it and wouldn’t be surprised if it were higher. Between the volume of phone calls from recruiters and the number of people I run into using or talking about Django its popularity is definitely on the rise in the Triangle.

Django in Action

Here’s a short list of shops in the Triangle who use Django in their day-to-day development:

• MetaMetrics ( Lexile )
• Caktus Consulting Group
• Capstrat
• American Research Institute
• Semiconductor Research Corporation
• Viget Labs
• rPath

I know there are other closeted folks out there using Django without full corporate blessing or knowledge. If there are other groups out there who would like to make this list please let me know.

A Triangle Django Users Group?

A new Google Group TriDjUG (twitter: @TriDjUG) was recently created in order to help foster a healthy Django community. At the same time some good discussion erupted from the TriZPUG mailing list. Why bother splitting our local Python community? While the intention was never to split away, some good cases were made for operating under the umbrella of TriZPUG. Strengthen the Python community. One exciting sentiment that came from TriZPUG members was that non-Django Python users were interested in Django and wanted to learn more during regular TriZPUG meetings. That would give us a captive audience at an already catered and organized event. Sounds good.

Surely there is some Django-specific fun to be had… For starters, we’re looking to sponsor local Django-related sprints maybe including one for the upcoming Django 1.2 release. For our community building/growing merit badges a couple of us are developing a Django Bootcamp; let’s continue to grow.

So it sounds like it’s up to us local Djangonauts to step up, participate in TriZPUG, and build greater awareness. People want to hear about our technologies, so let’s share. If you have other ideas we’ld love to hear them. If you haven’t yet introduced yourself swing by the mailing list or irc (#trizpug) and say hello.