Python Programming Toolbox

At this month's PyGTA meeting, we discussed what's in people's Python programming toolboxes. One surprise was that more than half the group did not use an IDE for development. Another surprise was that almost half the group used vim, making it the most common editor. It was a small group though so I wouldn't read too much into that statistic.

I found that my toolbox was not as full featured as some of the others. For example, I don't use tools to generate documentation from the code, whereas this seemed to be a common practice among the other programmers. It was an interesting discussion and I picked up a few ideas that might be worth exploring to see if they fit with my programing style.

Drive-By-Wire Systems

With Toyota's reputation for quality now sullied beyond repair, the "accelerator sticking" problem started as a loose floor mat issue, then turned into a mechanical problem, and is now a possible software bug in the drive-by-wire system. Of course that makes it even harder to investigate since you need good programmers to to do that kind of work. And it doesn't help when the safety authority apparently doesn't employ any software engineers. Let me guess, they'll probably out source the investigation. Perhaps even to the same people who wrote the code in first place!

OK, I'm just made up that last part, but it isn't completely impossible.

Missing The Obvious

I recently wrote about a problem in pip which was annoying me. Since then, I've looked for a work around but couldn't find one. At the last PyGTA meeting, I talked to Myles about it. When I explained how I used

pip install -e .

to install the application under development into the virtualenv, he noted that it was just like "development mode" in setuptools:

python setup.py devel

*facepalm* (which isn't easy when you wear glasses. ^^)

I don't know how I missed such an obvious answer. Thanks Myles.

Functional Programming In Python

At this month's PyGTA meeting we attempted to write a trivial application in Python using functional programming concepts. First, lets be clear: Python is not a natural language for functional programming. For one thing, the Python interpreter does not support the parallelism that a proper functional programming language will offer. However, it is possible to write in a functional style in Python, just don't expect much in return for your efforts.

The real difficulty was not Python itself but the group's lack of experience with functional programming. When you are used to using variables everywhere, it is actually quite difficult to write code that uses none. We commonly use varibales to save state and since functional programming is stateless, variables are a big no-no. In the end only Mike Fletcher got something that worked using functional programming techniques, but it still used a couple state variables, and so the program was not completely correct.

So what was learned from the experience? Functional programming is a lot harder than anyone thought. Next time someone waxes about how great a paradigm functional programming is, ask him to you show a real application he has written. If he hesitates, you can safely ignore everything he says.

BASH Programming

At the this month's GTALUG meeting, Chris F. A. Johnson gave a talk on BASH programming. Chris is one of our shell programming experts and is the author of Pro Bash Programming, so I knew the talk would be informative. While most of us write simple shell scripts for automate everyday tasks, Chris uses BASH for all his application development whether trivial or complex.

BASH never appealed to me as a general programming language for one reason only: it use too many special characters as syntactic sugar. It is the same reason I never took to Perl, TCL, and even Ruby. But that's just aesthetics and has nothing to do with the capabilities of the language. And, as Chris showed us tonight, BASH is plenty capable of doing everything that you might need for writing real world applications.

Skype After MPlayer

Since I started using Skype, it has always had a problem with video after running MPlayer. I managed to hit the right search terms today and finally found the answer. It seems MPlayer changes a XVideo attribute and then does not restore it before MPlayer terminates. Skype is not the only program that expects the XV_AUTOPAINT_COLORKEY attribute to be 1. After using the command

xvattr -a XV_AUTOPAINT_COLORKEY -v 1

to set the attribute back to 1, Skype video works.

MPlayer should restore configuration variables to the same state that it found it. It is just good behaviour. On the other hand, programs shouldn't expect that a user configurable attribute is always going have the correct value. I'm going to call it a draw and blame the bad programming on everyone. I was hoping it would be Skype's fault so I could blame the closed source program.

• https://developer.skype.com/jira/browse/SCL-350#action_27894
• http://ansuz.sooke.bc.ca/software/ogle-after-mplayer.php
  

Its Never Easy

I had another one of those days. I was making good progress for a while then ran into a wall again. I'm getting quite frustrated with these road blocks that are taking way too much time to work around. I have all the pieces in place for the LAMP server but getting everything working is another story.

One of the myths of using off-the-shelf components is that everything just works. I've always argued that if it takes a certain amount of effort to complete a project, that effort will still be expended no matter what tools, components, languages, etc., that you use. If you find some tool that lets you develop quickly, you will find that the projects become proportionately more complex. If you have a bunch of components, you will spend that effort making them work together.

I noticed this when I first used Developer Studio some some 15 years ago. Although it made make GUI design easier, I found that people nitpicked a lot more, so you wasted a lot of time tweaking the layouts, instead of writing the actual code. And Developer Studio was quite primitive compared to today's tools.

Code Cleanup

I was a little more productive today and managed to do some code cleanup on a personal project, TomsProjectUtil, which I use to create my project management environments. Code cleanup is never fun but is always necessary, especially before adding new functionality. One of the new features will call the chown() function which requires root privileges. However running as root introduces other problems so I'm going slowly. I'm hoping that I'll think of another way to do this so I can avoid running as root, but so far it seems the easiest approach.

Vim And Nose

Vim is probably not the most common editor amongst Python programmers, but I've been using Vim since the Amiga (about 15 years) and I have yet to find another editor I really like, notwithstanding the modal design inherited from vi, Vim's spiritual ancestor. I found an interesting plugin to integrate Vim and nose, a Python unit testing framework. Once the plugin (actually a pair of plugins, one for Vim, one for nose) is installed, you use ":make" to run your tests, and navigate through the errors with ":cc", ":cnext", and ":cprev". The system works great and shows that Vim is an effective editor for Python development.

Programming Mantras

The topic of this month's PyGTA meeting was programming mantras. With some groups, this might be a serious discussion of various programming methodologies. But this group is more relaxed, so the discussion was actually fun and lively, maybe even a little silly. :)

It was interesting how many people use methods from XP without realizing it. Or more accurately, XP just uses the methods that programmers have been always used, but in a more formal framework. I know people who have used XP and agile development successfully, but it seems to be too heavy for the small one man projects that are my bread and butter.

The one aspect of XP that I really like, is unit testing. I'm still learning how to write good unit tests, but I already noticed that it increases my confidence that the code I just wrote actually does what I think it does. I found that to write good unit tests, you really need to structure your code so that it is actually testable in small sections. And that's a good thing for your overall design anyway.

When Programming Was Fun

I'm a self-taught programmer. My first program was written on a TI-59 calculator. I hand assembled 6502 machine code on a SYM-1 single board computer before I wrote anything in a high level language. I never thought about the process much. I had an idea, thought for a while, and started coding. If the idea and thinking were good, the code would work, otherwise you started over. Designing software and coding were intricately connected and I never even considered separating the two.

When I started programming professionally, not much changed. I worked with people who had similar experience to mine. Except for the addition of a customer who set the broad requirements, the process we used was still the same. The programmer's always designed the software. It worked. We delivered working systems to customers and the programmer's had fun.

Then I started working with people who had more formal training in programming. Suddenly, design and coding were expected to be separate activities. My mind never really accepted that this was possible to solve a software problem by just talking and thinking about it. Programming became much harder and much less fun than it was before.

Lately I've been thinking about if it is possible to regain that old feeling of fun. Certainly, when I program for myself, it is fun. But is it possible to get the feeling back on paying projects?