Python Wars

Python Wars Solo was the result of a few hours effort roughly duplicating a text-based Star Trek game I wrote back in 1980-1981. I wrote the game in Apple ][ basic, and it had you 'fly' the USS Enterprise against up to nine Klingon ships. You could fire phasers, launch photon torpedoes, take evasive actions, and it seemed pretty fun. Beating one was a piece of cake. Three was a fun challenge. Five was tough. Seven was done only a few times. Nine was never done. The game was simple, fast, easy to learn, and tons of fun. Back in High School it was one of the games traded on floppy disks during the computer club so I considered it a success.

Back in 2007 I decided to try and reconstruct the software. One thing I did was was write most of it in one quick code dash of near stupidity. My theory was that it would more closely match the feel of my efforts as as 15 year old wrestling with Apple ][ basic without the benefits of a manual.

Some changes from the original:

* Rather than name it after the Star Trek universe, I named it a bit generically.
* Switched from phasers to a spinal mount weapon like what they used so wonderfully in Babylon 5.
* Changed from photon torpedoes to missiles.

The result worked, and was fun to play in dribs and drabs. The code is embarrassing, but that was kind of the point.

http://code.google.com/p/python-wars/wiki/PythonWarsSolo1

Do a svn checkout (svn checkout http://python-wars.googlecode.com/svn/trunk/ python-wars-read-only), and then python go.py. Don't laugh too hard!

I'm toying with moving this this over to Github and even doing a formal release. That would be really funny.

21 more posts to go!

Code I'll reuse

When I'm evaluating a package to use in my work or play I tend to look at five things. I think many of my on-line colleagues look at a similar list. If its missing too many of these things then odds are I'll go somewhere else for my needs or roll my own.

Documentation
Did the author bother with a README file? How about some sphinx documentation? How complete it it? Does it get me started and give a few basic examples?

I'm okay with typos and mistakes. These happen. But I want to see

Licensing
Everyone has their own idea of what they like for licenses. I like the MIT/BSD thing. I can understand the attraction to LGPL and GPL although they aren't for me. What I can't stand and won't use are monstrosities like GPL/Commercial used by such libraries as ExtJs.

Want to make money off your software? Easy... let anyone use it and charge for support. Worked damn well for communities and companies like Python, Django, Plone, various Linux distributions (Redhat anyone?), etc...

Eggification
Is your software constructed so that it can be installed via easy_install or pip? And yes, this is a bit of mild embarrassment for me, so I'm happy enough to eggify other people's work.

Tests
Do you have tests? Even a nearly empty tests file or folder? How about a test application? If you have no tests then your package is suspect. How do I know it will work independently of your personal computer?

Code Quality
Does the code smell bad? Can it be easily extended? If its innovative but the code needs work is it on a DVCS so more people can easily contribute?

22 more posts to go!

What I love about Python

A ways back I wrote about eight things I don't like about python. I'm in a good mood today so I'm writing about what I love about python.

Typing
Let's imagine I have long, blond hair and am named Goldilocks.

Goldilocks tried the first language and everything was rigid and method overloading was painful. Too static!

Goldilocks tried the second language and everything was too loose and crazy. Evaluators could fool you into thinking different types equaled each other, causing many false positives. Too loose!

Goldilocks tried the third language and it had some rigidity but not too much. Method overloading was so easy you did it without thinking. Evaluation gotchas were non-existent. Wonderfully dynamic and strong!

Everything is an object

To be honest, most of the time we don't care that everything is an object. We just code. However, when it counts, it just makes life so wonderful.

Intelligently named built-in functions and keywords

The functions like help(), print, list(), file(), dict(), and most other things are named elegantly and simply. Print is obvious; put, say, or echo are not.

Um... so maybe dir() and zip() are not very clear.

Whitespace
I love proper indentation. When I look at other people's code in other languages, first thing I do is start fixing their indentation issues. Python makes that so much easier for me.

Competing web frameworks

When I was first playing with Python I heard people gripe that the volume of web frameworks in Python is a bad thing. I wasn't so sure then and now I completely disagree. Competition is a good thing, and friendly competition is even better. Otherwise things go stale and the community suffers.

Python's web framework designers tend to get along really well. While the community leaned this way I believe that Mark Ramm has been instrumental in keeping things friendly.

The Community
Most of the time the python community is the best. They are open minded, smart, willing to learn, and willing to teach. And no one makes too much fun of my gushing man-crush on Guido.

23 more posts to go!

Eating your own dogfood

Since way back in 2007 when I blogged about JSON and Python I've used blogspot as my blog engine. I've never been completely happy with it because it didn't easily support code coloration. Still, it worked, had great up time, and I got used to it.

Recently though on twitter I've been getting a few dings about using python to host my blog. And since I've now captured pydanny.com and pydanny.net it makes even more sense. I toyed a few times with writing my own blog engine but while I've done it for my job, I never wanted to do it for myself.

So I've been shopping around for what I consider the best blog engine for me. I had a lot of great options thanks to a blog engine query asked in April. In the end we just extended the Pinax blog engine with a few widgets and that was good enough. Anyway, recently I started to look at those again as viable options.

However, one more option presented itself. Kevin Fricovsky's Mingus. It has everything I want in a blog, and also seems to closely follow what I would like to think I would have done in my blog. That is, to say, he fetched bits and pieces from all over the Django ecosphere and assembled them into one universal whole. Yup, I like it a lot.

So my plan is over the next week or so is to set it up on a Webfaction account and start blogging from there.

24 more posts to go! (I'm behind on days but plan to make it up with posts)

Foxpro

In the 1990s I was working for a small company doing a mix of help desk support, system administration, and development. I hated the help desk work, didn't like navigating Windows for system administration, but liked development. Even though development was Foxpro.

Yup, Foxpro. All of my Foxpro work was on Foxpro 2.6 for DOS. A few people in the office were working with Visual Foxpro 5 and 6, which meant a Visual Basic style IDE and whatever object model Foxpro adopted. But I was working in the DOS shell and that seemed easier. At the time I thought a fancy IDE was better, and wasn't until around 2003 that I changed my mind on that subject.

So anyway Foxpro was on the decrease even back in the 1990s. It took a bit of work and some luck to get out of the Foxpro closet. Fortunately I made it out. Yet I still have a soft spot for the language and too. My guess is that it is merely nostalgia for a different time in my life, and if I actually looked at Foxpro I would feel ill.

25 more days to go!

Crashing is fun

When we code we should be catching specific errors. Non-specific errors that you don't anticipate should be recorded in logs and hopefully researched. In theory, eventually you'll catch every error, right?

Today I was cycling along the Custis trail in Arlington, Virginia going around 22-23 miles an hour. Two cyclists were ahead of me and going much, much slower. As I came up to them I called out 'on your left' because on Virginia trails you always pass in the left lane. One of the cyclists then turned into the left lane. The other cyclist stayed in their lane.

Crap.

I hit my brakes but knew I couldn't slow down in time. On the left was a concrete sound barrier. On the right was a ditch several feet deep. So I went to the right. As my front wheel went off the path I unclipped my shoes and leapt off into the air. I'm not sure how fast I was going at that point so I'll say 18 miles an hour.

For decades I've practiced tumbling and falling down on various surfaces. The concept is that you'll get thrown, tripped, swept, or simply stumble and preparing for it is like catching the exception that is your own body when you lose control of your center of balance.

So when it came time for me to fall about 6 feet at about 18 miles an hour I was prepared. What could have been painful ended up being an awesome bit of fun that shocked the hell out of some other cyclists behind me. I rolled out of the fall and jumped up laughing.

My exception handling worked!

26 more posts to go!

Pycon talks and tutorials

At the Pycon in February 2010 myself and James Tauber will be presenting both a half-day tutorial on Pinax and a 30 minute Pinax tutorial. I'm delighted, honored, and admittedly a bit scared. Not scared enough that I won't be able to function, but scared enough to stay edgy. I've given talks and presentations before, but never before such a group of people that I respect and admire. The short tutorial I've done, although it is changing (and for the better). The long tutorial will be a lot of work, but we've got four months to finish our preparations.

Besides our Pinax stuff, there will be a lot of really incredible material at this conference. In fact, the times I will be working at this conference, I fear something will be scheduled that will be the talk of a lifetime. Indeed, there were a few times I hoped our Pinax proposals would be discarded because so many of the Pycon proposals were just unbelievably awesome.

On that note, I want to thank the other members of the pycon-pc group who contributed their hard work and time to figuring out which talks would be presented. Dozens of people reviewed the presented material using the Pycon website (note: these reviews will be made accessible to the authors of the proposed talks). By my unscientific count at least 2 dozen participated in the IRC meetings to determine who made the final list.

Quick Pycon Talk workflow

1. Talks reviewed on pycon site. Talks with at least one champion got moved to next stage. Talks without champions but no negative votes also got moved to next stage.
2. IRC discussions on each talk. Champions argued for the talks. If champion not available on IRC someone else would champion the talk. Brandon Rhodes and Doug Hellmann did a fantastic job as substitute champions. Yay/Nay votes then counted for simple majority.
3. When we had too many talks we used a Pycon Thunderdome method of whittling things down. Three-to-five talks of similiar bent were listed together then each person named the ones they wanted to keep. The ones with least votes were removed.
   

Some serious stars in the process were: Jesse Noller who busted serious hiney as chairman, Doug Napoleone provided incredibly responsive technical support for the site, plus Doug Hellmann and Brandon Rhodes for amazing levels of participation. So many others I respect were there in the web reviews or IRC that it was like a python geek fanboy's fantasy. What was also wonderful was how the reviewers would vote for, and often champion, for things that competed with their own pet project. This sense of keeping alive friendly competition was wonderful and demonstrated the solidarity of the Python community.

Some of us had talks in the system. We all left the meetings during those times. If a talk didn't make it through, there were no hard feelings. We just crossed our fingers and hoped for the best. Some people who participated quite a lot had their talks canned, so favorites certainly were not played.

Unfortunately, some talks did not make the cut that I think would have been outstanding contributions. There were times I felt real disappointment when something did not make it through. Unfortunately, as much as I believe the people in the pycon-pc meetings should follow my every whim, they do not.

Some were suggested to be resubmitted as tutorials. Any talk that did not make it through should be submitted as a poster session. Heck, if your talk got refused you can always present it in the open hallway track!

27 more posts to go!

Update: Doug Napoleone corrected me in that we only make the reviews public to the specific talk authors.