Bug Finding vs Bug Fixing

Recently at both my job and projects I've been paying attention to, I realized that I really enjoy QA; maybe even more than hacking on features or fixing bugs.

I've come to realize that, if you construct your application in proper iterations, you can do QA testing at any phase of a project. Sometimes I just don't have the spare time to dig into the codebase, implement features, and keep up with goals and progression, but I'd love to contribute, even if it's at a distance. Sometimes you will find overlooked bugs that are so glaring that you don't need knowledge of the deepest, darkest recesses of the codebase.

But if you keep finding hard bugs, people won't like you. ;)

Speeding up Perl Functions in XS

For the longest time I was scared to mess around with XS, but I started messing around with XS in my free time the past couple of days. I've been using Term::VT102 as my sandbox. I am using this for two reasons: (a) I use it pretty heavily in some of my software and would enjoy some speedups, and (b) the code looks like it can be ported to XS without much resistance once I have the tuits.

One of my current goals is to make an entire port of Term::VT102 in XS (Term::VT102::XS). It is progressing very slowly. However, in an act of impatience, I took a current copy of Term::VT102 and converted one of its functions to XS to see how much faster it was. I replaced



...with...



and ran a test script through Devel::NYTProf.

The pure-perl version ran in this much time (9.44s is the time in line):

The XS version ran in this much time:

A speedup that reduced the amount of time in that sub to nearly one ninth the time! Believe it or not, this function was one of the more expensive calls in my project code. I know I cheated by requiring $self for the XS function (rendering it completely incompatible but I don't know how to overload it quite yet), but I hope that doesn't make too much of a difference, speed-wise. If it speeds up a single function to 12% of the time (inclusive), imagine how much faster it will be with the entire thing ported to XS.

Termcast on the Web (screencast follow-up)

Here is a follow-up screencast demonstrating the tools I discussed in the previous post. Contact me directly if you want to try it out or see it demonstrated live!



Termcast on the Web from Jason May on Vimeo.

Termcast on the Web

The History of Termcast
In the NetHack community, people like to broadcast their games over telnet so others can watch, learn, and/or be impressed. Some wanted to broadcast more than just NetHack games.

Thus, termcast was born.

Anything one could do on a shell, one could do on termcast.  This allowed for activities like showing off tricks in a favorite editor, the thought process of the broadcaster when writing in a programming language, knowledge of various shell commands, CompSci homework, installation processes, the list goes on.

Branching from Telnet

One day while goofing off on CPAN, I discovered HTML::FromANSI, which does just what it sounds like: turn ANSI into HTML. This immediately inspired me to write a proof-of-concept of a web-based termcast. I have never dealt with VT emulators before, so I had no idea if this would even work. So I hacked on something that had a single listening socket, to which I used doy++'s App::Termcast to connect. It served a single page that used a javascript setInterval() timer to update every 0.2s or so. And when I ran it, it worked! It rendered very slowly and killed my CPU, but who cares: I could see the terminal display update live as I did things on the connected terminal!  Though, it seemed pretty daunting to make this in any way efficient, so I gave up on continuing any work on it.

Until now.

Termcast on the web with true streaming
I am now working on App::Termcast::Server and its web component, App::Termcast::Server::Web. It uses clkao++'s Web::Hippie, which utilizes a nice selection of modern streaming tools for the web to process communication from server to client, such as WebSockets, MXHR and (long) polling. It will transparently choose one depending on what the connecting browser supports. For instance, at the time of this writing, Chrome and Safari supports WebSockets, but Firefox doesn't, so the javascript would choose MXHR polling to do the heavy lifting in Firefox.

I am still trying different things out with the application. My first implementation involved a table with 80 <td>s inside 24 <tr>s, with javascript updating individual rows. The process of changing the foreground color and value of the cell (not to mention up to 1920 at the same time, it was a huge bottleneck, so I decided to learn HTML5 and use that if the browser supported it. Now it uses <canvas> and updates cells with the whole different logic from the table implementation, and is noticeably faster to render on-the-fly as well.

I think I am quickly catching up to the functionality of the original termcast application. Though, in my opinion, one of my killer features is the ability to resize your terminal and see the terminal on the web application change sizes as well, so you don't have to assume 80x24 or anything.

I am happy with the progress I am making with the web component of App::Termcast::Server, but I hope others will start writing other components for it. I started on a telnet component, but it doesn't really work. Also, I wrote a small IRC bot (currently somewhat brittle) that announces termcast connections, which is pretty neat.

As always, I am happy to get feedback, and feel free to contribute in any way you can.

Patches welcome!

IRSSI -> Growl

I whipped up a quick hack to give me growl alerts for irssi highlighting. It is pretty horrible, gross, and yucky, but it works well enough for me. I thought I'd share in case people don't care so much about how grotesque this is.

On my server running irssi, I wrote this irssi script:

On my macbook where I get growl messages I wrote this shell script:

...and ran it in cron on my macbook:

* * * * * /path/to/growl-alerts.sh myhost.org

AppleScript with iTerm

One thing I liked in Gnome (maybe just Compiz?) was the option how the terminal windows tiled as you spawned new ones. However, I no longer use Linux on any of my workstations. At home I use a MacBook, iTerm being my terminal emulator of choice. Much to my dismay, iTerm spawns at each corner of the screen by default, like so:

Some people prefer this; I don't. I wanted my terms to spawn along the center of the screen. I looked through the preferences and found no easy solution. Then the power user in me spoke up. I can solve this with AppleScript! ...kind of!

So I ended up with this. I have it in a .scpt file that I can easily call with Quicksilver and load up four terms, just like this:

AberMUD: A Perl MUD Framework

I have been working on a Perl MUD framework called AberMUD. Most of the core server logic is in a separate framework I called MUD. Though the framework is called AberMUD, I am mostly basing the framework on the Dirt code-bases, which are just a variant of the original AberMUD, but a very good one in my opinion. I think it would be great if people used MUD to build other bases like DikuMUD and TinyMUD, and brew up a framework of their own. I know I am itching to write one.

I played on MUDs a lot in my teenage years. It has always been a dream of mine to write a framework that makes it very easy for other people to crank out robust MUDs. With the rise in popularity of modern gaming, MUDs are a dying culture. I am hoping to keep it alive by making a convenient framework and hopefully a community to back it.

I am also using AberMUD to learn a lot of new cool things in the Perl universe. Listed are some modules that currently make this project really easy and fun to expand:

• Moose - OO with meta-object and role capabilities
• Bread::Board - Wires all the MUD components together for easy object construction
• KiokuDB - seamless, persistent OODBM for storing all the MUD data
• Path::Dispatcher - Great dispatching tools for command parsing
• POE - Convenient socket-oriented tools to prevent reinventing the wheel

I may use other cool modules in the future like HTTP::Engine or something like it to build a web interface for managing components of the universe, like locations and objects.

AberMUD and MUD are both on Github for anybody to peruse and clone.

http://github.com/jasonmay/mud

http://github.com/jasonmay/abermud

Documentation is still sketchy but I will make it a lot more verbose once the framework starts to settle. Feel free to give feedback!