My “roots” in the open source community come from the BSD side of the open source spectrum, my first major introduction being involvement with FreeBSD and OpenBSD. It is not surprising that my licensing preferences fall on the BSD (2 or 3 clause) or MIT licenses, the MIT license reading as follows:<blockquote><p>Copyright (c) [year] [copyright holders]

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</blockquote> I bring the subject up because I wanted to address a brief "kerfuffle" that occurred recently on the Eventlet mailing list with the maintainer of gevent, a fork/rewrite of Eventlet. Both projects are MIT licensed which gives anybody that would like to fork the source code of either project a great deal of leeway to hack about with the code, commercialize it, etc. **Disclaimer**: I personally am a fan of Eventlet, use it quite often, and have recently taking up maintaining Spawning, a WSGI server that supports multiple processes/threads, non-blocking I/O and graceful code reloading, built on top of Eventlet. The "kerfuffle" occurred after Ryan, the maintainer of Eventlet, took a few good modules from gevent; *shocking* as it may seem, a developer working with liberally licensed code took liberally licensed code from a similar project. The issue that the maintainer of gevent took with the incorporation of his code was all about attribution: > I don't mind you borrowing code from gevent, the license permits it. However, please make it clear where are you getting the code from. Upon first reading the email, I doubled over to the [eventlet source on Bitbucket](http://bitbucket.org/which_linden/eventlet/), checked the files that were incorporated into the codebase ([timeout.py](http://bitbucket.org/which_linden/eventlet/src/tip/eventlet/timeout.py) and [queue.py](http://bitbucket.org/which_linden/eventlet/src/tip/eventlet/queue.py))and sure enough the copyright attributing the original author were still in tact, surely this is a non-issue? Unfortunately not, license pedantry is an open source community past-time, right up their with drinking and shouting. When I replied mentioning that the copyrights were correctly in place, mentioning that both projects were MIT licensed so both constraints of the license were met, that is, the MIT license notice was included with the code. In essence the disagreement revolves around what the phrase "this permission notice shall be included" entail, my interpretation of the license is such that the MIT license itself shall be included, not the specific file with additions from one project to another; after sending off my mail, I received the following reply: > Ok, it's acceptable to use one LICENSE file but only if the copyright notice from gevent is present unchanged. > > That is, take the notice from here http://bitbucket.org/denis/gevent/src/tip/LICENSE (the line with the url), and put it into eventlet's LICENSE, on a separate line. (It's OK to add "Copyright (c) 2009-2010" before it to make it in line with others). > > That would settle it. Slightly pedantic in my opinion, the MIT license enumerates a line for copyright holders which has been hijacked for other information that the maintainer of gevent would like to propagate, I don't necessarily agree, but this is a mailing list not a court of law, so I'll allow it. The thread continues: > The license did not change. I've only updated the copyright notice to include the url of the project to protect against abusive borrowers, that's it. This is where I draw the line, go all in, plant my flag in the sand and other unnecessary metaphors. **Abusive borrowers?** Analyzing the semantics of the phrase alone makes my head hurt, I have a mental image of two old ladies wherein one says to the other: "may I borrow a cup of sugar, you horse-faced hunch-backed bucket of moron?" The rest of the email is full of similarly head-hurting quotes, for brevity I won't include them here (you can read the thread [in the archives](https://lists.secondlife.com/pipermail/eventletdev/2010-February/000731.html)). I'm simply dumbfounded by the ignorance of what the MIT license actually *means*, unlike the LGPL or the GPL license which were specifically drafted to protect against "abusive borrowers", such as Cisco, the MIT license is so open it's *almost* public domain. To a certain extent I can understand the emotions behind the thread on the mailing list, I don't agree with them. If you're seeking attribution past the copyright line in a header, than perhaps the "original" [4 clause BSD license](http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29) is for you, or perhaps the LGPL or GPL which give you more control over what happens to the source code you originate? If this is what you're after, the MIT license is the wrong license.

A few weekends ago ET and I had some engagement photos taken, I’m told this is normal, by the husband-and-wife team from Tibidabo Photography, Bob and Becky. The duo met us at one of my favorite spots in San Francisco: Duboce Ave and Buena Vista Ave East after which we ran around in Buena Vista Park taking a few shots, then down to Baker Beach. As much as I hate having my picture taken, they did a wonderful job and grabbed some really stellar shots.

In my spurious free time I maintain a few Python modules (py-yajl, Cheetah, PyECC) and am semi-involved in a couple others (Django, Eventlet), only one of which properly supports Python 3. For the uninitiated, Python 3 is a backwards incompatible progression of the Python language and CPython implementation thereof, it’s represented significant challenges for the Python community insofar that supporting Python 2.xx, which is in wide deployment, and Python 3.xx simultaneously is difficult.

As it stands now my primary development environment is Python 2.6 on Linux/amd64, which means I get to take advantage of some of the nice things that were added to Python 3 and then back-ported to Python 2.6/2.7. Regular readers know about my undying love for Hudson, a Java-based continuous integration server, which I use to test and build all of the Python projects that I work on. While working this weekend I noticed that one of my C-based projects (py-yajl) was failing to link properly on Python 2.4 and 2.5. It might be easy to cut-off support for Python 2.4, which was first released over four years ago, there are still a number of heavy users of 2.4 (such as Slide), in fact it’s still the default /usr/bin/python on Red Hat Enterprise Linux 5. What makes this C-based module special, is that thanks to Travis, it runs properly on Python 3.1 as well. Since the Python C-API has been fairly stable through the 2 series into Python 3, maintaining a C-based module that supports multiple versions of Python.

In this case, it’s as easy as some simple pre-processor definitions:#if PY_MAJOR_VERSION >= 3 #define IS_PYTHON3 #endifWhich I can use further down the line to modify the handling some of the minor internal changes for Python 3:#ifdef IS_PYTHON3 result = _internal_decode((_YajlDecoder *)decoder, PyBytes_AsString(bufferstring), PyBytes_Size(bufferstring)); Py_XDECREF(bufferstring); #else result = _internal_decode((_YajlDecoder *)decoder, PyString_AsString(buffer), PyString_Size(buffer)); #endif

Not particularly pretty but it gets the job done, supporting all major versions of Python.

Python on Python

Writing modules in C is fun, can give you pretty good performance, but is not something you would want to do with a large package like Django (for example). Python is the language we all know and love to work with, a much more pleasant language to work with than C. If you build packages in pure Python, those packages have a much better chance running on top of IronPython or Jython, and the entire Python ecosystem is better for it.

A few weeks ago when I started to look deeper into the possibility of Cheetah support for Python 3, I found a process riddled with faults. First a disclaimer, Cheetah is almost ten years old; it’s one of the oldest Python projects I can think of that’s still chugging along. This translates into some very old looking code, most people who are new to the language aren’t familiar with some of the ways the language has changed in the past five years, let alone ten.

The current means of supporting Python 3 with pure Python packages is as follows:

1. Refactor the code enough such that 2to3 can process it
2. Run 2to3 over the codebase, with the -w option to literally write the changes to the files
3. Test your code on Python 3 (if it fails, go back to step 1)
4. Create a source tarball, post to PyPI, continue developing in Python 2.xx

I’m hoping you spotted the same problem with this model that I did, due to the reliance on 2to3 you are now trapped into always developing Python targeting Python 2. This model will never succeed in moving people to Python 3, regardless of what amazing improvements it contains (such as the Unladen Swallow work) because you cannot develop on a day-to-day basis with Python 3, it’s a magic conversion tool away.

Unlike with a C module for Python, I cannot #ifdef certain segments of code in and out, which forces me to constantly use 2to3 or fork my code and maintain two separate branches of my project, duplicating the work for every change. With Python 2 sticking around on the scene for years to come (I don;t believe 2.7 will be the last release) I cannot imagine either of these workflows making sense long term.

At a fundamental level, supporting Python 3 does not make sense for anybody developing modules, particularly open source ones. Despite Python 3 being “the future”, it is currently impossible to develop using Python 3, maintaining support for Python 2, which all of us have to do. With enterprise operating systems like Red Hat or SuSE only now starting to get on board with Python 2.5 and Python 2.6, you can be certain that we’re more than five years away from seeing Python 3 installed by default on any production machines.

And it's taken an eternity to graduate from "adorable peach fuzz" to "smudge of dirt" status, so leave me alone.

I figure by the time it grows long enough to where I stop getting carded for alcohol, my hair will be gray, thus defeating the purpose.

While I don’t carry a decent camera around with me, I’ve found that the camera in my Samsung Jack is usually decent enough if I can hold my hands still (rare). Ended up snapping a few photos today and wanted to post them with a little bit of story behind them.

My bike route to the office takes me up and down Page St. which runs into Market St. just on the other side of Van Ness Ave. I never saw the accident or another car, I just saw a couple of cops and tow-truck guys standing around this flipped car on the turn from inbound Market St. onto Franklin St. I didn’t see any damage on the vehicle so I’m still quite puzzled how it was flipped and which direction it could have possibly been heading.

I picked these two figures up from Kid Robot for Apture’s Christmas Secret Santa, they ended up going to Josh who didn’t take them with him for whatever reason. I’ve since moved them to a more visible location (right below the Hudson dashboard).

Given the cloud cover that I normally ride home through I was quite surprised to see clear skies over Twin Peaks on my ride home. Of course, it is still February, so the clouds were still there, creeping along the ground.

Earlier this week I was checking out Pygame, pondering what I could possibly build with it that could keep me motivated enough to finish it. Motivation would like be the primary problem for me with any amount of game programming; I’m not a gamer, I don’t harbor a dislike of games, they’re just not something I typically spend time playing (I do like to play “haggard late night open-source hacker” though, that’s a fun one). Friday night I stumbled across an idea, ET likes to play (casual) games, perhaps we could write a game together; ask any engineer at EA or Ubisoft, there’s nothing more romantic than working on a game.

Talking over the idea with ET on the ride home from the office, we talked about creating a typing-oriented game and started to brainstorm. The tricky aspect of a typing-oriented game is you have to walk the fine line of “educational gaming”, that is to say, the game’s goal is not to teach the player how to type. That sucks. Contrasted to some other games where the means of progressing in some games is by solving a puzzle, killing noobs in others, in this game we wanted the player to progress through levels/situations with their typing ability (ET finds this fun, we do not have this in common).

Over pizza we discussed more about how the levels would work, I decided that I wanted to use stories/articles instead of random words for the “content” of the game. We settled on a couple fundamental concepts: the player would earn coins by correctly completing a words as the scrolled from right to left (similar to a ticker tape), they would lose coins if they made a mistake or could not keep up. After a player completed a level (i.e. a “story”) they would find themselves in a “store” of sorts, where they could purchase “tools” for future levels with their coins. The tools we decided would be a very important, as the player reached their upper bound of typing speed the utility of these various tools would necessary as a means of strategically conquering the level. One of the few things we didn’t particularly cover was the “end game”, whether the player would simply play increasingly more difficult levels (a la Tetris) or if they could actually “beat” the game. With at least the basics of the concept sketched out, it was time to start writing some code.

Starting with Pygame

It’s incredibly important to mention that I’ve never programmed a game before. Never-ever. From my work with network programming I was already familiar with the concept of the run-loop that’s pretty core to Pygame, but I had never really made use of any to animate objects on the screen or deal with handling any kind of events from mouse movements to key presses, etc. Fortunately I’m already a professional Python developer, so writing code wasn’t the difficult part so much as laying it out. Orienting things into classes to handle separate components such as animating text (which is a painful in Pygame, in my opinion) to keeping track of user-input.

Animating text across the screen wasn’t particularly difficult, with Pygame you first create your primary “surface” (i.e. the window) and then you can render things onto that surface. With text, you end up rendering a surface which contains your text, “hello world” which you then place onto the primary surface. Easy peasy thus far: import pygame surface = pygame.display.set_mode((640, 680), pygame.HWSURFACE | pygame.DOUBLEBUF) font = pygame.font.SysFont('Courier', 42) ### render(text, antialias, rgb color tuple font_surface = font.render('hello world', 0, (0, 0, 0)) ### draw `font_surface` onto `surface` at (x=0, y=0) start_x, start_y = 0, 0 surface.blit(font_surface, (start_x, start_y)) while True: ### Holy runloop batman pygame.display.update()

That was fun, I now have “hello world” rendered onto my screen, now to animate I suppose I’ll just render font_surface a little further right every iteration of the runloop, i.e. while True: ### Holy runloop batman surface.blit(font_surface, (start_x, start_y)) start_x += 0.5 pygame.display.update() This blurs the text however, so I then changed to: while True: ### Holy runloop batman surface.blit(font_surface, (start_x, start_y)) surface.fill((0, 0, 0)) start_x += 0.5 pygame.display.update() This will cause the (primary) surface to be repainted (washed over) every iteration of the runloop ensuring that the text will properly animate, drawing the text in one spot, wiping the surface then drawing it slightly further to the left, resulting in the scrolling animation. All’s fine and good until you determine that you want to have other elements on the screen and you also don’t want to redraw them every time around the carousel. I then discovered how to “fill” just one particular rectangle on the surface, i.e. the rectangle behind the text: text_w, text_h = font.size('hello world') while True: ### Holy runloop batman surface.blit(font_surface, (start_x, start_y)) surface.fill((0, 0, 0), rect=pygame.Rect(start_x, start_y, text_w, text_h)) start_x += 0.5 pygame.display.update()

Once I was able to get text properly scrolling across the screen, the rest of the afternoon of hacking was far easier. My confidence in my ability to grok Pygame in order to do what I wanted. I then set forth organizing my code into some logical classes, for example I created a LetterSpool class which would record the user’s progress through the current word, rendering it at the bottom-center of the screen and firing an event when the user hit the space bar (denoting the word “complete”), additionally I wrapped my text animation code into AnimatedWord so I could easily string words together to scroll across the screen in conjunction similar to a textual screensaver.

Not a whole lot more to write about with regards to my progress today, hooked up some music and basic sound effects which was trivial after looking at some sample code. Next I need to start addressing some more fundamentals for user-interaction: scoring and level-changing.

You can track the progress of the game “Typy” (pronounced: typey) on GitHub

My New Year’s resolution this year was incredibly generic insofar that I merely wanted to “write more.” No qualifications for what kind of writing that entailed, I simply want to become a better writer (or blogger), with technical subjects in particular I’d like to get better at writing in a fashion that is interesting, parse-able by novices and has sufficient “depth” to interest more technical readers. I’m not sure if I can define what being a “better writer” will entail or how I’ll know when I’m there, so for now I’m just trying to write good content. Considering my last post didn’t even pretend to ride the fence between opinionated-article and full-on rant, I think it’s safe to say that in order to accomplish my goal I need more venues for writing and more topics to write about.

One of those venues, which I’ve linked to before is the Apture Blog; I have written for the company blog already this year and chances are I will have another few posts go up as we tackle some of the technical challenges we’re currently facing (you can view my posts here). Unfortunately there’s only so many articles I can write for the Apture Blog without giving away any confidential information or turning it completely into a technical blog (hint: it’s not).

Looking around at a few of the open source communities that I’m involved in, two groups stick out: Eventlet and Hudson. Eventlet already has a blog and I’m certain my usage of Eventlet is not steady enough to warrant any kind of authoritative posts on the subject. The other, Hudson, is something I’ve used on a daily basis for almost a year and a half. Not only that, I run the @hudsonci twitter account and founded the #Hudson channel on Freenode, I’ve also tried my hand at developing some plugins for Hudson (which is written in Java). Suffice to say, I’m quite the little Hudson cheerleader.

When I floated the idea of an “official” blog for Hudson, which I would help drive, to Kohsuke and some other “core” developers of Hudson, the idea was well received and I set off getting Drupal configured, writing some preliminary content and getting ready for a launch of Continuous Blog. While my writing contributions thus far to Continuous Blog have been sparse, I’ve gotten to play the delightful role of Editor which is an entirely different experience unto itself.

I’m looking forward to seeing how this develops, I might end up writing for a few other blogs depending on interest and time, but for now my shenanigans can be found on:

• unethical blogger (duh)
• Continuous Blog
• The Apture Blog

There are few things I truly enjoy in life, things that warm my heart and make me smile from ear to ear, things like hot oatmeal and coffee, cell coverage in San Francisco, back scratches and not dying. If I didn’t commute every single day on my bicycle, I’d likely put “bike riding” on the list too but it’s hard to be ecstatic about something you start and finish every workday with (except for maybe some recreational yelling). For about 25 minutes every morning and 25 minutes every night, I’m a cyclist in San Francisco, nothing terribly unique, I am one of many cyclists in the city during rush hour and I have been noticing some things lately.

First of all, let me address my fellow cyclists. Some of you (you hopefully know who you are) are unadulterated, complete fucking-assholes. I understand that you don’t need a license to ride a bicycle but you still have to obey the rules of the road. Among other things this means you should be courteous to those you’re sharing the road with which includes:

• Using hand signals
• Yielding (you can use the dictionary on the iPhone that you’re pulling out at intersections to look up what that word means). Despite the ironic t-shirt you’re wearing underneath your hoodie, you are not “King of the World”.
• Riding on streets safe for bicycle use. I know you love to ride down Oak St. and Van Ness in rush hour but it does nothing but piss drivers off. There are typically less trafficked streets adjacent to busy streets which are preferred for cyclist use (such as Page and Market St.).
• Stopping at stop lights. I’m sure Gavin and the SFPD have given you an exemption from basic traffic laws but the drivers coming into the intersection don’t know that. You are making things dangerous for everybody around you on the road; stop it.

Given the hours I work, I’m typically riding home in the dark, where I’ve noticed a group of people who don’t share the same love of “not dying” as I do. I’m going to call them the “Suicide Cyclists.” This group of morons never cease to disappoint, without fail you’ll see one or two of them riding down a busy street (like Market St.) with no lights and no helmet. Some vindictive part of me really would like to see a car accidentally hit one of them. I don’t want them to seriously injure or kill anybody, just a light enough tap to send them to the ground and bump their head just hard enough to knock some god-damn sense into it.

There are parts of my bike ride where I might even crash into one of these Suicide Cyclists, places where I’m riding on a two-way bike path (through a poorly lit park) or where I’m turning at an intersection. If through some unfortunate turn of events we crash into each other, the cyclist wearing a dark sweatshirt with no helmet or lights on their bicycle, and me, with my plethora of lights and hand signals, you can be certain that the next thing that’s going to happen is assault with a U-Lock against some poor schmuck who’s too stupid to ride on the right side of the bike path in the dark.

To be honest, I can deal with the immense number of drivers not paying enough attention to the bike lanes, red lights or speed limits, the majority of the time cars do not cut through intersections, sidewalks, parks and everywhere else. Their trajectories are far more predictable than some jerk riding his fixie with his corduroy bike cap where ever he damn well pleases.

Grumble.

Some users of Hudson have already started to notice a subtle addition to the latest release, 1.343, a new background watermark image.

The commit message (r26728) from Kohsuke, the incredibly talented founder and maintainer of the Hudson project, adds a bit of sadness to the whole affair:<blockquote>In tribute to Sun Microsystems and all my colleagues who had to go today. I hope the community would forgive me for doing this. </blockquote>

Given the incredible speed at which the tech industry grows and moves, it’s easy to forget that there are a number of talented engineers that have spent their careers at Sun building technologies that have helped change the face of modern computing, regardless of whether or not Sun could figure out how to sell them: SunOS/Solaris, Java, DTrace, SPARC 64-bit chips, Sun Grid Engine, JRuby, the W3C XML specification, ZFS, OpenOffice (acquisition), MySQL (acquisition), and VirtualBox (acquisition).

As a corporation, I personally think Sun was a failure, as a foundation of engineering in Silicon Valley, I think Sun has been quite successful.

To those that are being pushed out as part of the merger with Oracle, I want to sincerely thank you for your contributions to computing and wish you the best of luck. Here’s the “full” version of the image, which I found via @jtnl’s TwitPic stream:

One of my most favorite sites on the internet, reddit, took some downtime this evening while doing some infrastructure (both hardware and software) upgrades. On their down-page, the reddit team invited everybody to join the #redditdowntime channel on the Freenode network, ostensibly to help users pass the time waiting for their pics and IAMAs to come back online.

Shortly after reddit started their scheduled outage, I joined the channel to pass the time while I debated what I should do with my evening. Within minutes the channel was flooded with a number of users, varying between spouting reddit memes in caps. link-spamming or engaging in casual chit-chat. I complained to one of the ops and fairly well-known-to-redditors employee: jedberg about the lack of moderation and he nearly instantly gave me +o (ops) in the channel. Not one to take my ops duty lightly, I started kicking spammers, warning habitual caps-lock users and tried to keep things generally civil through the deluge of messages consuming the channel.

Towards the end of the scheduled outage, some automated link-spamming started to appear and once it started it triggered more and more link-spamming. Clearly whatever was behind the bit.ly link was responsible for the self-propagating nature of the spamming. While the other moderators and myself tried to keep up with banning people I used wget to fetch the destination of the clearly malicious bit.ly URL to determine what we were dealing with. What I found is one of the more clever bits of JavaScript I think I’ve seen in recent months.

After bringing the site back up for a few minutes, reddit had to take it back down after noticing some problems with the upgrade, so another flood of users filled into the #redditdowntime channel and the link-spamming got worse. The most interesting aspect of the JavaScript in the code snippet below is how simple it is, I’ve commented it up a bit to help explain what’s actually going on:

DIGG ROOLZ! REDDIT DROOLZ!

</code>