Moving to GitHub Pages

My blog has moved to my GitHub Pages.

The Long Tail of Software Reuse

I have been an enthusiastic user of open-source software for years, yet I have never really contributed to any project started by someone else, nor have I started anything but dead ends myself. I may be a control freak with a short span of attention, but too short for what? Another way of seeing things is that the open-source projects that I have started have been too ambitious given my limited resources of time, patience, and enthusiasm.

The open-source hosting services that I used before becoming a GitHub user, namely SourceForge.net and Google Code, are built for hosting medium to large projects, not for incubating small projects. At SourceForge.net, each new project is individually approved, and at Google Code, you have a lifetime creation limit of ten projects. Ten ideas are not a lot for a person to have in a lifetime. I must have started a hundred software projects over the years. Would SourceForge.net or Google Code have allowed me to create that many? I doubt it. But GitHub does. I can create as many repositories as I like, as long as I stay within my file quota. That is fertile ground indeed for the incubation and organic growth of software projects.

A couple of weeks ago, I looked through the code of Wormbane, a roguelike computer game that never made it past barely playable. Wormbane does however have working implementations of the A* search algorithm and a field-of-view algorithm, and I had even taken the time to write unit tests and demos before running out of steam. Extracting the algorithm implementations into separate projects and publishing them on GitHub as python-astar and python-fov has to rank among my best spent time as a software developer, yet at SourceForge.net or Google Code, I would not have bothered. There would have been too much overhead, both for the administrators and for me.

Hosting LuaRocks Repositories at GitHub

GitHub has recently started supporting clean URLs for raw file access. The old, cluttered kind of raw URLs looked like this:

http://github.com/elemel/rocks/tree/master/import-0.1-1.rockspec?raw=true

The new, clean kind looks like this:

http://github.com/elemel/rocks/raw/master/import-0.1-1.rockspec


The new kind of URL allows you to host LuaRocks repositories at GitHub. Mine is at:

http://github.com/elemel/rocks/raw/master

To create your own LuaRocks repository at GitHub, follow these steps:

1. Create a GitHub repository named e.g. rocks and change directory to your local clone of it.
   
2. Copy your rockspec files to your working directory.
   
3. Make a manifest: luarocks-admin make_manifest .
4. Stage (add), commit, and push your rockspec files and manifest to GitHub.
   
5. Add the raw URL string for your repository to the rocks_servers array in your config.lua file.

The tarball and zipball URLs of GitHub are convenient in rockspec files. For an example, see the rockspec file for import referred above. If you have trouble browsing a repository, try appending a slash to the URL.

Update: I have moved my LuaRocks repository to my GitHub Pages.

Moonshine Tickets at Lighthouse

Moonshine now uses the Lighthouse ticket tracking service. Here is a list of open tickets for Moonshine.

Moonshine Goes Githubwards

Moonshine, my new roguelike computer game, is now hosted at GitHub. The GitHub service gets everything right, though I miss the integrated issue tracker available in Trac and Google Code. For now, the Moonshine wiki will double as an issue tracker. Ruby on Rails, also hosted at GitHub, uses Lighthouse for issue tracking. Maybe Moonshine can use that too.

I am happy to finally use Git for a project. Git gets everything right too.

Take Me to the Moon

I am learning the Lua programming language, prompted in part by Steve Yegge's recent blog post The Universal Design Pattern. In his post, Steve summarizes a few well-known schools of modeling before introducing the lesser-known Prototype Pattern. A few years ago in a post to the DGD mailing list, Pär Winzell described a similar technique used in the Skotos mud library. So, at least two above-average programmers have recommended prototype-based programming for developing highly configurable games.

Never much for impulse control, I am ditching Wormbane, my second attempt at a roguelike computer game written in Python, in favor of a new roguelike in Lua. Although Lua first sparked my interest a couple of years ago, I had placed it in the same language category as Python, and I was already invested in Python. However, Lua is primarily a prototype-based language whereas Python is class-based. I will give Lua a try, though it seems that so far, I am spending most of my time implementing Lua versions of Python's builtin functions. Then again, I never really was against reinventing the wheel.

Didn't You Get the Memo?

I am competing in Google Code Jam. One of the practice problems available in the contest area is called Shopping Plan. The problem is to find the minimum cost for buying a number of items. Each item is available in one or more stores, possibly at different prices. Perishable items must be dropped off at the house before going to the next store. Driving around uses up gas, which is not as free as it used to be. My first attempt at a solution was a Python implementation of the A* search algorithm. The computer ran out of memory. In retrospect, I should have excluded the previously visited stores from the search state. A friend of mine attempted a brute force solution, also without success.

I read up on Shopping Plan in a couple of discussion group threads, where people suggested using either Dijkstra's algorithm (closely related to A*) or dynamic programming. I wrote a new Python program that memoized the minimum costs found so far. It worked. It was right. It was slow. I rewrote the program in C++. It was faster. I changed the program to store memoized costs using vectors instead of maps. It was fast.