I’ve taken my first plunge into TDD today. Yesterday I read (skimmed) the book Test Driven Development by Example by Kent Beck. In the second section of the book Kent gave a step by step example of how to develop the xUnit testing framework in python. At the end of the section he recommended implementing your own version of xUnit for whatever language you will be testing so you can learn the methodology.

I considered using some of the existing PHP testing frameworks – but they were all rather large (>100k) and both included a lot of features I couldn’t see myself using. So I forged ahead with Kent’s advice and wrote my own testing framework, which I named “Testing”. The final results are:

testing.php – 2440 bytes – the Testing class
tests.php – 2508 bytes – the tests for testing the Testing class (say that 5x fast!)
run.php – 161 bytes – a couple lines of php to run the Testing tests

It was a challenging task, as I’ve not done TDD before, and I found it took me about 3-4 tries to actually “get it”. The first few times I just scrabbled at not knowing where to start. The 3rd time I ended up implementing the Testing class “the old fashioned way” – but then realized I was supposed to be using TDD – so I reimplemented it using TDD. The interesting bit is that by reimplementing it using TDD I was forced to make my testing framework testable – so I had to add in logging facilities early on in the process. I also uncovered several bugs while re-writing it.

All in all, it seems like TDD will be a useful tool in the project I’m working on – will keep you posted.

I’m a big fan of rapid development. I’m also a big fan of the programming languages that I use … but every now and then I come across a use case where my language of choice just isn’t cutting it. And what’s the only obvious solution? Design my own language in 48 hours!

I like the 48 hour restriction because that means I won’t waste more than one weekend of my life trying this. I honestly believe that the people in charge of the languages I use are doing a great job. It’s just that now and again I have the desire to try and make one myself. And if it turns out to be a waste of time, at least it was only 48 hours 🙂

I’ll likely be trying to make some language similar to python and lua – with a special focus on making it easy to integrate into C.

I’ve spent a bit of time fooling with javascript this past weekend. It really is okay, but I came across a few scoping gotcha. Scoping defaults to global, so

function fnc1() { a = 5; } fnc1(); alert("a: "+a);

Will show you that a is 5. I’m more used to languages that default to a local scope. To get variables into a local scope in javascript, this example should be written as:

b = null; function fnc2() { var b = 5; } fnc2(); alert("b: "+b);

Will show you that b is null – as expected.

I’ve been using open source software for well over 10 years. Here are some stories of times when I’ve had brief interactions with communities regarding “bugs”.

Back in 2001, I tried to submit a “bug report” to the php project – I had discovered that in certain cases a function worked slightly different than advertised. My report was dismissed with an RTFM and flagged as “Bogus”. I was a bit put-off by their response, as I had RTFM (and demonstrated that clearly in my report.) The problem with my report is that I was complaining about an edge case that wasn’t really a bug. It just wasn’t worth their time to really understand what I was getting at.

In 2003, I submitted a bug report to the dosbox project – I discovered several games that I wanted to work with the software that didn’t. I offered my help in fixing the bug. My report was greeted with open arms, my offer to help fix the bug lead the maintainers to give me tips on how to troubleshoot the issue. Not being an accomplished ASM debugger I wasn’t able to get very far in my work. They saw that I had given it “the ol’ college try” and were happy to fix it for me. (I decided to sweeten the deal for them with a small donation to the project.)

Earlier this year, I had some trouble with rsync. I was losing connections part way through the backups. I realized that it probably wasn’t an issue with rsync but with my connections. I read over all the help information and found nothing addressing my issue on the rsync website. After talking with a few of my sysadmin contacts, they were able to help me track the issue down to a problem with my ssh setup (which was using default settings.) I was then able to write up an informative message to the rsync mailing list suggesting an addition to their FAQ which I felt would save people in similar situations hours of research. They updated the FAQ with the information I provided.

A bit later in this year, I submitted a small patch to rsync fixing a trivial problem with building in a certain hosting environment. This message went ignored. Since it was a one line fix for a problem which likely only happens to me, it seems that may have been the right response on their part. (Especially since, thinking over it, my patch may very well be the wrong thing to do for most environments.)

All that to say, from my experience it really seems that the more I put into reports and patches the more likely I am to see results and a positive response.*

*read this if you haven’t: How to Report Bugs Effectively

A day in advance I’ve completed my pyweek entry! And, to be honest, my pyweek entry was more the completion of the pug.gui than the “game” I made. Some final stats on pug:

• gui.py is 31360 bytes
• theme.py is 7428 bytes
• 16 widgets included in the core

The theme is easily extensible – while maintaining separation from the Widget core. Themes can respond to events (play Sound effects), have per-frame loops (shrink/grow/change colors), and be styled using the CSS Box model. Here’s a couple fun screenshots:

The default theme:

The “game” with even more custom theme and Widgets:

I decided not to actually enter my entry into the pyweek judging mainly because it wasn’t a game, but also my “non-game” was utilizing pug, which wasn’t released a month ago (per pyweek rules for personal library usage.)

On a more “game design” topic, I’m a lot more comfortable creating arcade games, as that’s more my style. Games that involve your typical “gui widgets” just don’t excite me very much. The rational behind creating pug is that games do need good menus and options screens for the times when you aren’t playing the actual game. Many of my “core” widget choices are based on the primary use case I have for pug.

Since pug still isn’t up to the 32k limit, I’m likely to add in joystick support as well as add more information into the docstrings. There are a number of widgets I could include, but I don’t feel that the primary use case allows for those. (Users will be free to create “contrib” widgets to be placed into the “contrib” folder and will not be supported by me. I might even add in some “contrib” widgets – a secondary use case is quick game dev / level making tools. You need file pickers and dialogs for those – both of which I’ve developed for pug already.)

If you want to give pug a whirl: svn://www.imitationpickles.org/pug/trunk

-Phil

I’ve been working on a re-write of my pygame based gui PGU. I found, that as PGU grew larger I was less inclined to maintain it. It became harder to add new features and harder to maintain existing ones. At present, PGU is pretty stable, but it’s also pretty large and likely not going to change.

While working on Galcon, I added the ability for users to add their own python mods to the game. I wanted to give the users the ability to add their own option screens using a simple gui system, which, just for giggles, I decided to make sure it was less than 32k of code. After I had written this system “gui.py” it occurred to me that not only was the API simpler than PGU it also had most of the features PGU had! (As well as quite a few PGU didn’t have.) My simple 32k gui.py was rivaling my 250k pgu.gui!

I came up with a theory of sorts: “Any useful library can be written in 64k or less.” Of course, I wouldn’t swear by that, but I figured I’d give it a try. I’m working on getting more functionality than PGU had into my new PUG library. So far so well, I’m keeping the gui.py <= 32k and the theme.py <= 8k. So far I have a cleaner API with more features than the original PGU. However, keeping it smaller than 32k requires me to make quite a few trade-offs. I can't have all the features I included in PGU. The real challenge now is deciding “is this feature important for almost all games, or is it a bit frivolous” … I’m sort of cheating by putting those frivolous widgets into a contrib/ folder. At the same time, it’s helping me keep the core small and maintainable. Anything found in the contrib/ folder may very well be quite useful, but I can also claim it is unsupported and not have to worry about it.

My arbitrary rules for PUG development:

• the code in pug/ must be <= 64k
• gui.py <= 32k
• theme.py <= 8k
• code must be readable
• names must be readable
• use 4 spaces for tabs
• must include complete docstrings

A number of those rules are in place to keep me from “cheating” to get the file smaller. I hope to wrap up a useable version today .. and then begin working on my pyweek entry!

If anyone is brave and wants to try the alpha: svn://www.imitationpickles.org/pug/trunk

-Phil