After figuring out that I should use linum, I started the lisp code for emacs support for python code coverage from scratch. It felt a little like chaining generators. Write a small function, test it in the scratch window....

Notice the pretty red, and the *pycov* in the lower right. Code here

I continue to prefer Goaltimate for groups of 13 or less. It's a great game, one gets lots of touches and newbies, seasoned folks can play together. I think it improves new ultimate players throws better than ultimate does. It's great for warming up. We usually play until we have enough for ultimate. People continue to be skeptical before playing, and the majority comment something like this after playing:

• "That's a lot more fun than I thought it would be"
• "That's cool. Where did you get the hoop?"
• "I prefer this to ultimate"

Ok, only a few say the last one, but they have said it. Then there's the group of people who won't give goaltimate a chance. They'll either sit out and wait til there's 10 people and then want to jump to full field 5 on 5 ultimate, or they'll play grudgingly. There seems to be another small group of people who believe that goaltimate is too hard on their bodies (knees and ankles) who also won't play unless they've got 5 other people begging them to. But I'm digressing.

A complaint I've heard is that it takes too long to set up goaltimate. I don't think that's valid. (With the aluminum hoops it's even quicker). A field can be set up in about 2 minutes. Here's how:

How to set up a Goaltimate field

Step 1: Find a good field

A benefit of goaltimate is that it can be played in smaller areas. I've played inside in basketball courts. Can't do that with ultimate. Also, nice large grassy areas tend to get chewed up quickly. But smaller ones not so much. So you can usually play goaltimate on a better field (often it's right next to the ultimate field).

Step 2: Step up the hoop stakes

Because the hoop is fixed in size, it's important that it be set up the correct distance of 18 feet. Here's an easy way to do it. If you got a pvc set (with 8 pieces) connect 4 of them. That will be 16 feet long, so stick a foot on each side and you've pretty much got 18 feet. If you've got the nicer aluminum poles, find the middle and mark it with a sharpie. Here's an illustration that should make it pretty clear.

Setting up the pole is a two person job. (As is taking it down). Have a person on both ends of the pole and put both ends on the stakes at the same time. People seem to be wary of making the pole bend, but it will do it.

Step 3: Goal line cones

The goal line cones are set inline with the hoop, 3 feet away from each stake, making them 24 feet apart from each other.

Step 4: Back goal cone

From the hoop take 8 paces back (I'm assuming your paces are 3 feet), and drop a cone. Note that the depth of the goal is the same as the width of the front cones. It seems that some like shallow endzones (perhaps the intent is to make the goal actually be a semi circle, which it is not). The full endzone opens things up a little and allows for more endzone throw possibilities. Here's an image:(The rest of the images are top down) (Note that the regulation field image (the circular one) doesn't have the endzone scaled correctly)

Step 5: Finish the goal cones

From the back cone I work my way around with 3 more cones on each side.

Step 6: Make the "crease" (optional)

If your players tend to goaltend a lot and don't like the 3 second rule (or just step out if front of the hoop and poach there), you can make the crease in front. The rules specify that you can't hang out in the area 1 yard in front of the goal either.

Step 7: Set up clear/2 point line

From here on out I'm no longer "regulation". I've never seen a circular field in the different games I've played at. Most are either rectangular or boundless. When we play indoors, we play rectangular (obviously), and we play without boundaries outside.

Regulation calls for a clear line of 30 yards that arcs out from the hoop. And then a 2 point line (that is parallel to the goal line) at 20 yards out. Again we normally just set up four cones about 20 yards back for a clear/2 point line. The distance of 20 yards can be tweaked depending on energy levels, number of players or field size.

Another (non-regulation) tweak that we add is a cone about 10 feet behind the endzone. This is the "no-clear" area. If the disc ends up behind it on a turnover, you don't need to clear. Some people are confused in that they think they can clear it there as well. NO! If they pick it up behind the cone, then they are cleared, otherwise the only way to clear is the normal clear line.

Here's another illustration with dashed lines indicating what the cones are meant to

Other tweaks

We normally play 3 on 3 or 4 on 4. If we've got more people, then we'll sub on error. What that means is if you throw an uncatcheable throw, or you drop a catcheable throw, you sub out. This tends to give everyone a pretty fair playing time.

I've posted previously about how to make hoops. My original PVC set got a crack yesterday as a player collided with the hoop (must have blended in with the white snow). I'm a fan of the aluminum hoops (which I also have). They are better in every way; lighter, smaller, easier to store, easier to setup, easier to take down, and more durable. Why weren't we using them yesterday you ask? Because my friend who has (permanently borrowed) my PVC set arrived first....

My brother has a good anecdote about using OpenGL. It allowed him to take software that he had written 12 years ago and easily port it to both the iphone and python in about 2 days (1 day each). This would have been impossible had he used DirectX (not that it existed then, but you get the point).

I spent this morning trying out promise. Promise is a project that hints at speeding up native python by decorating functions. From the README:

That seems like a quite a novel idea for dynamic languages. So I figured I'd try it out on some work that pulls a bunch of numbers from a db and runs some calculations on then. To get rid of the db overhead of querying, I cached all the db results during a "pump prime" initial query. Then I timed the calculation 4 times and stored the result. I then used lsprofcalltree.py and kcachegrind to find out which of my functions were taking the most time.

Now how to invoke promise? The docs are sparse, basically there is a readme and a few testcases. Luckily the folks on reddit had pointed to an .odp slideshow. In the slideshow functions are decorated with the following decorators:

Since I was writing a testcase for speed measurements (and I wasn't quite sure which decorator to use for my functions) I just did the following (sensible_func names have been changed):

def promisize():
    import promise
    sensible_funcs = [slow_func1, slow_func2, slow_func3]
    for sensible in sensible_funcs:
        try:
            sensible = promise.pure()(sensible)
        except TypeError:
            sensible = promise.sensible()(sensible)
        except AttributeError:
            pass
    promise.sensible()(globals())

Promise does some checking on your code and complains for various reasons. I hit an issue with **kw in one of my functions (pure functions can't contain them for some reason, seems like a lack of implementation rather than a theoretical reason. But I use **kw a bit so hopefully this is resolved). So now that my code is "promisized", I loop over the same calculation and time it as well as compare it to the normal version (to make sure that promise isn't breaking anything). One function was "sensible", all the rest came out as "pure".

The good news? Promise didn't break anything! The bad news? There aren't any nice charts! That's because the lines would overlap each other. Promise appears to have no effect on the speed of my code. When I run the same code with psyco, I get 10-15% improvement.

While, the promise of promise was good, either I'm doing something wrong, or my code isn't amenable to their speed tweeks. I'd like some more examples on when/why to use which decorators. Also, some speedup. Alas, I guess I'll need to keep waiting for PyPy to deliver...

In the spirit of the Planet Python 2009 meme, I'm doing a more general review (that still includes Python).

Work

Work was pretty busy this year, which is good, things are looking well for 2010. In the spirit of Google's 20% projects, we just released, Battle for Vesta. I only had a minor role in this, but it has been fun to see it progress. There was even a Python port done along the way (perhaps a post on that later). If you've got an iphone and like 3d space shooters, give it a try.

I had some fun with some smaller contracts. Implementing a youtube-lite site in Django. I've also been doing some really cool prototyping work for next-gen smart phone interfaces, using Pylons. In addition our flagship product appears to be gaining attention, we'll see how it fares in the new year.

The main technologies used this year have been Pylons, django, YUI, hacked xlwt, postgres, and matplotlib (plus the iphone project). I've dabbled a tiny bit in iui and jqtouch. I keep wanting to use jquery, but am pretty heavily invested in yui (have a custom widget that isn't available elsewhere), and hence am reticent to mix toolkits. I should overcome this fear though, cause I think jquery will be more succinct for a lot of my js stuff.

Though I program heavily in both JavaScript and Python, I still find myself getting annoyed with JavaScript. The closure soup mess that hacks everything together just gets to me. Couple that with everyone doing things differently, browser incompatibilities and poor environments leaves me scratching my head...

Side projects

I got a github account this year, and have been putting some projects on it. Pykeyview is a nice little OSD for showing keystrokes during presentations/screencasts. Sadly recent versions of X have borked the RECORD extension. Once that gets fixed and I have some time I'd like to do some emacs screencasts.

Inkscape Image Slicer is an Inkscape plugin that allows for slicing of images. I made it a while ago, but I've been fixing it up, hoping for inclusion in .48. I use it almost weekly for work and also when doing graphics for presentations. Give it a try if you're interested in that sort of stuff and comment on the bug to see if we can get it included in Inkscape proper.

rst2odp is another project that I continually hack as needed. It converts restructured text to open office slides. 2009 saw some external patches! Damian Conway reviewed my slides at OSCON and commented that they were quite beautiful. I didn't tell him that they were computer generated. I'll probably hack as needed again this year. Perhaps use github and push patches back to the docutils svn. Though I've also been thinking about rst2emacs.... (there's not enough time), which I think would be cool for demoing/live coding/etc. Bruce has an inline Python interpreter, but to me it just makes sense to go all out if you want that and use emacs. With ttf support in 23 it couldn't be too much uglier than s5.

I've started hacking on emacs code coverage support for Python. It needs help, my elisp is poor, and there isn't enough time. Perhaps, I'll sprint on this at PyCon. I'd also like to get Python support into Emacs Starter Kit, hence my fork of the project.

Pushed a patch to argparse for support of unix hierarchy (ie pulling configuration information from env and config files). Hopefully its status moves from accepted to closed ;)

Wrote a simple math program for my daughter's XO. Need to post the code as well as make it harder for her now...

Conferences

Presented at SCALE, PyCON, OSCON and UTOSC on Python Scripting, Wiimotes and Code Coverage.

Mitch Altman saves the lightsaber. Photo by Pınar Özger

Books read

Read a few technical books this year:

• CSS: The Missing Manual This might be one of the best technical books I've read. Perhaps it was because McFarland so clearly explained concepts that I've struggled with. I've read other CSS books, and they made me want to pull my hair out. This was a great read. If you are interested in CSS this is the book for you. My only complaints are lack of explaining css manipulation with javascript (I think it's relevant coming from a developer, perhaps not so much from a designer), no coverage on css sprites (again my inkscape slicer works well for making these :), and perhaps it's getting outdated with CSS3 support coming out in many browsers. (Though it does cover some CSS3 stuff). (Yeah I know, I need to apply this book to my blog....)
• Physical Database Design I got this book from the folks at Datascaler. It talks about Indexes, Materialized View, Query Plans, Clustering, Range Partitioning, OS Tweaking, OLAP and Denormalization. It has good introductory coverage of these topics. My only complaint is that it focuses on commercial db's, Oracle, DB2 and SQL Server. It be nice to get Postgres in there, but much of the information is platform agnostic. A NOSQL version of this book might be interesting, as it seems to be the fad of the day.
• Learning Emacs In my quest to become more proficient at emacs I read this book. I picked up a few keystrokes along the way. It seems a little dated and it's coverage of elisp was a little lighter than I would have liked.

Hardware/Software

My main system is a ThinkPad T61p running Gentoo. I've got 4gb and am running 64bit. Wow, I've been using Gentoo since 2002 (or 2001?). For the most part it works well. My biggest complaint is flakiness of flash on 64 bits (blame pandora). I run windows in a VirtualBox because I've yet to get L2TP vpn working in Linux. I also run the Android live cd in VirtualBox (much faster than the emulator).

People complain about linux hardware support, but I've been very happy with my ThinkPads (knock on wood). Suspend works, wifi, graphics, external monitors just work.

I'm connected to a 24 inch Dell that seems to work well, except for the occasional horizontal ghosting (tweaking the VGA cable seems to help). I'm been running the Awesome tiling window manager all year, and have few complaints with it. (It makes my computer harder for others to use which I guess is a mixed blessing).

I also traded in my Microsoft ergonomic keyboard for a Unicomp Endurapro buckling spring keyboard. I'm quite pleased with it, as are most people who try it out. Though it is loud, which complicates the occasional early/late work hours.

An Intel Solid State harddrive was in my laptop for a while this year. I was very happy with that. If your application is seek heavy (which many db's are), you will love the order or two magnitude of improvement in seek times.

As far as software, I'm running konsole, akregator, emacs, firefox, chromium, VirtualBox, OpenOffice, okular, and exhaile.

Am running Ubuntu on servers and other laptops. I like the flexibility of gentoo, though it has an overhead with it that I don't want on other computers.

Blogs/Sites

I'm contemplated signing up for twitter various times this year. I feel like it could be useful but also a distraction. How do people deal with this? I've already got 60+ blogs on my feed reader (about 12 planets). Couple that with surfing reddit (which doesn't support feeds very well) and you can sink a lot of time into following others. Facebook is less of a temptation, since I view it as a bigger time sink with less value. (Though it would have come in useful a handful of times...)

I've got a few scripts at work that I think are getting hairy. Not in the code smell sense, but rather in the maintenance of forking sense. They are batch scripts (run on weekly/daily intervals) customized to a users environment. They work but as I get more users I don't want to have to deal with customized forks of the master script. I want to abstract out this customization to a higher level. Plus some users will need different scripts executed at pre/post intervals depending on their situation.

In thinking about this a little, I think what I what is a library of (python) functions and scripts (bash/executable/etc). Then for each user I want to compose these scripts/functions in a state machine specific to them. Each user will have a smaller, hopefully legible (hacking graphviz visualization will be simple) definition file that creates the master script (or state machine). I should be able to 'run' the state machine, or subgraphs of it. This is probably overkill for simple scripts or one-offs, but I'm not really dealing with that now.

I'm calling this ScriptMachine.

Comments/questions welcomed

Spent a while this morning trying to print out xmas labels from a spreadsheet. If you have a spreadsheet containing address information, the first thing to do is create an odb database from it. My wife's Ubuntu Karmic didn't have the ability to create dbs, so I did it on my gentoo machine. The previous instructions lack one small detail that was necessary for me. They don't tell you how to "register" the new db. If the db isn't registered it won't show up on the New->Labels db selection dropdown.

Ok, a confession, the db creation wizard offers to register the db when you create it. It asks "Do you want to register the database in OpenOffice.org?" I figured that was a phone-home type registration so being a semi-privacy wary user I unchecked it. In reality I should have kept this checked.

To "register" the database you created from the spreadsheet (after the fact), use View->Data Sources (on a normal document), then right click "Registered databases ..." and add the new db you just created. Pretty straightforward.

Perform a mail merge using that db. Again this was pretty easy but I had alignment issues. After printing test pages (and going through the label creation process many times), the easiest was to get the labels aligned, was to edit the "Label text" (note I did this within the Label wizard and not on the "document" that it produces) and add a black space before the text and indent each line by 4 spaces (YMMV, I was using 8160 labels and printing on linux). Adjusting the margins messed up the label columns (got 2 instead of 3).

The last issue was printer jamming. Using more than one Office Depot 8160 Inkjet Mailing Label jammed my Samsung ML-2010. So feed them individually.

And print them on the correct side, duh!

When I do this next year, it should be a breeze now!

Code coverage gets a bad rap. People say it's meaningless. In my "Managing Complexity" talk at PyCon 2008, I made the analogy that code coverage was like a shield. One is exposed where the shield doesn't cover. But just because you have shield doesn't mean that your shield is any good. You could be battling against a fire breathing dragon with a WOODEN shield (smart one Wiglaf). Your exposed areas could be dead code (which the literature says is more likely to cause bugs) or code that is hard to test.

This last point, code that is hard to test was hit home to me over the weekend when I spent some time going over Miško Hevery's blog about testability. While perusing the site and some of his presos, it hit me that 100% code coverage (and I'm talking about the line/statement variety here) indicates something else. That your code is testable. If you can't get 100% coverage, then you are probably violating some of the 10 things that make code hard to test. I especially appreciate the Law of Demeter analogy he uses, (paraphrasing) "You don't give the cashier your wallet when they tell your lunch costs $5.98. You give them the money (or the credit card)". So if you are struggling getting the coverage numbers you want, you probably need to use dependency injection to get rid of that Law of Demeter violation....

Of course, now that Python has branch coverage. we can get to work on some of the interesting things that you get from path coverage. Oh yeah, editor support would be nice too.