For Halloween, I had wired the bushes in front of my house with a dozen or so pairs of blinking LED eyes. Each pair of eyes blinked at their own rate–all powered by an Arduino. After building these centrally-wired daemonic bush entities I wanted to be able to deploy a few more in remote bushes and trees without having to wire them up to an Arduino. So I turned to my good friend the 555 timer chip. 555 timers for the uninitiated are a very versatile integrated circuit that can be used in a variety of timer-related circuits.

I was looking to achieve a very specific blinking pattern and was having a hard time figuring out the optimal set of components to use. There are tons of calculators out there for figuring out the characteristics of a 555 circuit based on the values of the components you use. If you’ve ever tried using one of these calculators for this sort of project it can be very frustrating. I don’t actually care what the components’ values are; I’m usually not thinking about that side of the equations at all. What I really care about are the timing characteristics of the circuit in terms of how long a signal is high and how long it is low. I want my “on time” to be X seconds and I want my “off time” to be Y seconds. You figure out what components I need to plug in to get that behavior.

Most of the existing 555 calculators I was able to find take the component values (e.g. R1= 100k, R2= 150k) and then compute the frequency, time_high, duty cycle, etc. I would rather think about the behavior I’m after and plug in the time_high and time_low and receive the values of the components I should use to achieve such a circuit.

Hang on. Let’s turn the real world dial up one more notch. It just so happens, I don’t have a resistor measured at 183.45 Ohms to achieve the specific oscillation I desire. Maybe we could constrain the calculator to only consider component values for components I actually have in my possession. Give me the best possible fit for the components that I do have (or can get my hands on).

So, I whipped up a simple Python tool to help me optimize my component selection to best achieve my desired blinking pattern. Here is an example snippet that solves the 555 timing equations using my inventory of components and my desired signal characteristics:

from optimize_555.opt import optimize
target_high = 42  #42 seconds on
target_low = 15 #15 seconds off
R1, R2, C, time_high, time_low = optimize(target_high, target_low)

This results in a timing circuit that goes high for 45.7 seconds and then has a 15.2 second low. And the best part of it is it’s accomplished using components that I have in-stock. R1 is 200KOhm, R2 is 100KOhm, and C is 220uF. The system defaults to a set of commonly available components, but you can override and define your own inventory.

In its current form its a very thin wrapper around some basic SciPy functions. You can check it out over at github. If there is some interest, I hope to expose it through a web interface at some point to make it more accessible to non-programming, electronic hobbyists. Hope it helps and happy blinking!

The post Python and the 555 Blinking Eyes in the Bushes appeared first on Kurt Grandis.

Ingress is a new augmented reality game created by Google’s Niantic Labs. Imagine a cross between Pac Man, Foursquare, Geocaching, and Capture the Flag all rolled into one app on your phone. You run around town looking at a Google Map-like view gathering energy so that you can capture and defend geographically-distributed portals against an enemy faction.

Luckily, I walked away from my first big Ingress encounter unscathed, unfrisked, and undetained. But, I’m now picturing very different scenarios in the near future with people suspiciously circling buildings, eyes glued to their phones that occasionally make scary, threatening, futuristic sounds. Just ask the Mooninites or that student wearing art composed of exposed electronics, but it doesn’t seem to take much to freak people out these days.

Mooninite device that people freaked out about: http://en.wikipedia.org/wiki/2007_Boston_bomb_scare . Image from Wikipedia.

The game has placed portals on a number of sites that the broader citizen base may not appreciate seeing trampled including federal buildings, libraries, and even some public middle school grounds. Fire departments also appear to be a very popular location for portals. One fire department with a portal I investigated could not be hacked without driving or walking up into their parking lot, potentially blocking their garage. I took a moment to talk with the on-duty firefighter at the station to get his take on the game and to see if anyone had notified them that their station would now be a part of some geeky capture the flag game. Nope. He hadn’t heard of it and while he sounded intrigued by the concept he did not like the idea of increased traffic pulling into their parking lot. As a local homeowner, I have to agree.

The game is still in beta and perhaps one goal is to identify some of these concerns before unleashing the nerd hordes. Suspected terrorist and arsonist concerns aside, this has been a pretty entertaining game. I’ve hoped for an augmented reality game like this for awhile and I think the folks at Niantic Labs have done a great job. It’s even provided enough motivation for me to get a little extra exercise in as I take walking breaks to hack and recharge portals. I don’t know how the game dynamics will change or scale once more people join the action, but it definitely has my attention for the time being.

Just think twice if Google tells you to visit the local fire department at night and lets revisit portal placement. Make good life choices.

Snapshot of Ingress activity in Durham (Nov 2012)

The post Ingress: Dangers and First Impressions appeared first on Kurt Grandis.

It’s been awhile since my last real update and a lot’s been going on. First, the good people of Popular Mechanics reached out to me earlier this year about the squirrel/sentry gun project and did a little write-up about it in their September 2012 issue. Having grown up on Popular Mechanics it was very cool and flattering. (I’m still tempted to send away for plans to build a flying ship out of ordinary household vacuum cleaners.) I think my favorite part was getting a cartoon rendering of myself. And to all the people who write to me about their ongoing wildlife battles: stay strong!

Since my last real update, I also left my amazing team to start a new adventure. I am now the Director of Technology at Pruvop. As a digital products laboratory we work on a wide-range of projects, from building functional prototypes for early-stage startups to helping larger organizations streamline their internal processes by integrating intelligent automation software. I’m back in the mud again, designing and building all sorts of cool projects in Downtown Durham.  It has been great being surrounded by a cross-functional team (marketing, business, developers) who all appreciate the strengths of agile and lean methodologies.

I hope to be able to share some new developments in the coming months!

The post Hello World Update appeared first on Kurt Grandis.

We just wrapped up the inaugural PyCarolinas conference. I know I had a good time and it was great to see so many people in attendance not only from the southeast, but from across the US with even some international attendees.

Professor Gary Bishop of the Department of Computer Science at UNC Chapel Hill gave our first keynote on Saturday touching on accessibility and enabling technologies. It was an inspiring call to action. We as developers have tremendous power at our fingertips to make a difference in the lives of countless individuals around the world. Just do it and make it happen. Leave the committees out of it.

Lynn Root gave Sunday’s keynote, where she shared her experiences in joining and building communities. My favorite take away here on the simplicity of community and solidarity was, “Hey! You’re a nerd. I’m a nerd. Let’s hang out. Kthbai.”

Barry Peddycord III’s talk about Python in computer science education sparked a lot of offline discussion, which struck close to home given some of the educational technology initiatives I’m working on.

I missed Michael DeHaan’s talk on Ansible, but it did put it on my radar. While, I’ve made healthy use of Chef, Puppet, (and fabric), they’ve never felt just right and I would gladly jump ship to a better solution.  So, I hope to check it out in the next few days.

I was cursing Fred Alger after his talk, Sysadmining Python to the Moon, for planting the seed that maybe I could build something and send it to the edge of space–it’s possible. Just what I need. It was a fun, inspiring talk and while I hope I can shake its effects, I have a feeling I may be revisiting it. You can check out his presentation materials over on github.

François Dion gave a fun and passionate talk about Raspberry Pis, their use in exciting kids, and how to seriously soup them up with all sorts of add-ons. I plan on following his work over at his Raspberry-Python blog.

David Ray and Julia Elman from Caktus also had great talks about working with designers, which sparked some good discussion. David presented django-comps, which looks like a simple, yet handy tool for serving a directory of static-y html files from a Django project. The idea is you can have a designer work within the same source repo as the project proper as they start building out comps/templates.  This is an ideal setup for integrated rapid prototyping. Your project’s defined comps directory will show a list view of the available pages from which you can drill down. You can also easily zip things up for delivery to a client for offline review. I’m looking forward to checking this one out.

Another nice nugget came care of a lightning talk given by Simeon Franklin (@simeonfranklin). If you find yourself using optparse: stop. No really. Check out docopt. It looks like it may take a tremendous amount of pain out of writing command line utilities.

I think the first PyCarolinas event went swimmingly. A huge thanks to Calvin Spealman, Chris Calloway, UNC, the PSF, all the volunteers and the sponsors for making it happen. I’m already looking forward to next year’s!

PyCarolinas Attendees https://twitter.com/PyCarolinas/status/260075547537833984

The post PyCarolinas Redux appeared first on Kurt Grandis.

I gave my PyCon talk this weekend–“Militarizing Your Backyard With Python: Computer Vision and the Squirrel Hordes.” I was not prepared for the number of people who caught me after the talk and throughout the conference telling me about their own battles. Thanks again for all the recommendations about how to improve my firepower, tracking, and classification accuracy.

As requested I’ve posted the presentation on SlideShare and here’s the final squirrel encounter video and the actual PyCon Presentation.

One great resource that was really helpful for getting ideas about sentry guns is Project Sentry Gun. There is Wiring and Processing code to get you started as well as a premade Arduino shield if you’re interested. The folks at Servocity were also very helpful in sizing servos for my project.

As time permits, I’ll post some additional articles detailing the various steps of my project that folks seem to be interested in.

Thanks all. Good luck and don’t get captured.

The post Recap of the Squirrel Hordes appeared first on Kurt Grandis.

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

The post Python Hack Night #3 appeared first on Kurt Grandis.

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.

The post Surveying Mechanical Turk to Validate a Startup Idea appeared first on Kurt Grandis.

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.

The post Gitosis for Mercurial appeared first on Kurt Grandis.

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.

The post Get Your Nose Out Of There! appeared first on Kurt Grandis.

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

The post Python + Django vs. C# + ASP.NET: Productivity Showdown appeared first on Kurt Grandis.