chrishowie.com

I’ve abandoned my idea of creating an AJAX interface for the time being. It is a cool idea but I think I can do much better by writing a proper application.

The Linux FICS interface scene is rather weak. eboard is about the best there is in terms of usability, and it has its share of problems. xboard is there for the minimalists who want their interface to provide a chess board only. When compared with the powerful and extensible interfaces available for Windows it’s rather a shame there’s nothing similar for Linux.

So I’ve decided to take the name I was going to use for my web interface and apply it to a new Linux interface. Building on Mono.Addins, I’ve already got an interface that can be extended in several key ways. Addins can, for example, provide new text highlighting classes or classes that can manipulate the console text buffer in interesting ways.

Using a tip from jonp in #mono, I have now come up with an extensible preferences system that does not suck, based on XLinq. Addins can simply subclass PreferenceContainer, slap on a few attributes, and they have an easy-to-use set of strongly typed preferences that get automatically serialized to XML. Right now only the basic primitive types and strings are supported, but this will be extended later to include things like arrays, lists, and XLinq objects. Thanks to Mono.Addins and some more support classes I wrote, addins can also provide Gtk# widgets that get embedded into the application preferences window. By writing very little code, addin authors can persist their settings and provide the user with a convenient way to change them.

I’m still lacking a chess board though. If anyone likes writing custom widgets and feels comfortable working on this project let me know. The sources will be made public in the coming weeks after I’ve had a chance to polish them and set consistent style guidelines.

I’ve been getting back into chess recently, and my favorite online community is the Free Internet Chess Server (FICS). There are a wealth of free and open interfaces available for download, but they all have one thing in common: you have to download them. At my workplace this is a no-no, but over my lunch break it would be nice to get in a few games. If I forget my laptop then I have no way to play.

Enter Gazebo. I started this project last Friday night, so it’s only been about two days. Still, what I have right now is rather impressive for that amount of time. At face value, the current version is not very representative of the time that’s gone into the project so far, and for a very good reason.

The HTTP protocol used by web servers was not engineered around the idea that you’d establish a long-lasting connection with the server. It’s better suited for quick request-response cycles. Because of this, the PHP web service has no good way to maintain a connection to FICS.

The solution I came up with for this problem is simple, yet very involved. A daemon script (yes, written in PHP…) listens on a UNIX socket for connections from the PHP web service script. If a new FICS session is requested, it creates a new session and returns some authentication parameters to the web service. On every request to the service, another connection to the daemon is made over the UNIX socket, the session attached to with the authentication parameters, and some action taken, like “write this to the network socket” or “tell me when you get new data from the network socket” or even “close the network socket and destroy the session.” The daemon essentially acts as a super-proxy that persists the network sockets and enables access to all of them from one UNIX socket.

Yes, it’s kinda ugly. But it also works incredibly well. There is still some tuning to be done, but behold the awesomeness of what is essentially in-browser, color-coded telnet:

I’ve been reading up on Douglas Crockford’s Code Conventions for the JavaScript Programming Language and I agree with most of them, but I definitely have a bone to pick with one of them: “All variables/functions should be declared before they are used.”

This sounds good in theory, and is probably a good programming practice. However, in JavaScript we frequently use callbacks to implement asynchronous calls, due to the fact that JavaScript is single-threaded. Code like this is common:

function BeginProcess(data) {
    // process data
    DoDataProcess({
        'data': data,
        'onComplete': EndProcess
    });
}

function EndProcess() {
    alert('The process is done');
}

Think AJAX in particular. This kind of thing is commonplace. However, declaring things before we use them means we have two options. We can either swap the functions around, or we can declare var EndProcess; at the top of the script. The latter reminds me too much of C, where you have to declare function prototypes ahead of time if you want to write them in any order you want. The former is just incredibly confusing. Consider how that would look:

function EndProcess() {
    alert('The process is done');
}

function BeginProcess(data) {
    // process data
    DoDataProcess({
        'data': data,
        'onComplete': EndProcess
    });
}

This is horrible. The natural code flow is broken. You now have to start at the last function and read it, then go up to read the next part. This is the same reason that top-posting sucks and bottom-posting makes sense. If those functions were both longer than a screen, you have to scroll to the bottom of the script, then up to the function header. Then read down to find “EndProcess” and say “what’s that?” Then scroll up to find EndHeader, then back down to read it. The human mind has not been conditioned to read this way.

Consider this quote from the linked article on top-posting:

Top-posting makes posts incomprehensible. Firstly: In normal conversations, one does not answer to something that has not yet been said. So it is unclear to reply to the top, whilst the original message is at the bottom. Secondly: In western society a book is normally read from top to bottom. Top-posting forces one to stray from this convention: Reading some at the top, skipping to the bottom to read the question, and going back to the top to continue. This annoyance increases even more than linear with the number of top-posts in the message. If someone replies to a thread and you forgot what the thread was all about, or that thread was incomplete for some reasons, it will be quite tiresome to rapidly understand what the thread was all about, due to bad posting and irrelevant text which has not been removed.

Given a suitably large enough application (like the one I am working on right now) this means that I either need about 200 var statements at the top of my program to indicate every class I am defining, and the same within each class to indicate each private function, or I have to reorder them. Both are unwieldy. One is unnecessarily verbose, while the other is horrible to read and breaks the natural flow of the code. Your initialization function winds up at the very bottom of the script, then you have to work your way up to see what is going on.

Crockford seems like a pretty intelligent guy, but I’ve yet to see any extensive code samples that show how he gets around this problem. Thoughts?

I’ve been up to a lot of little things recently but haven’t undertaken any projects big enough to warrant a whole fancy blog post. I figured I might as well summarize what I’ve been up to.

I’m doing a project at school that improves the experience of on-campus tutors and their clients. They’d been using Moodle workshops to allow clients to submit content to tutors, and recording hours manually on timecards. Moodle will still be involved, but the tutors will now interact primarily with a web application I’ve been coding that will track their hours for them, as well as fulfill some clerical roles, such as preventing two tutors from working on the same paper. (Previously this was done more or less manually by updating the workshop submission title. Not a terribly fun way to track that kind of stuff.)

This project has me up to my neck in JavaScript, a language I’ve long held in contempt. However, after reading up on some patterns and watching a talk or two my mind has been completely changed. In fact, I enjoy coding in JavaScript now. I enjoy it a lot. When you know what you are doing (and what to avoid) all the frustration and general icky feelings associated with working in the language disappear. What’s left is an incredibly pure, lightning-fast web application. A maintainable one too. Who knew JavaScript could do that?

Some other semi-random facts:

• I’m getting married in 91 days. (See that counter in the right column? Yup, that one. If you’ve been wondering what that’s counting down to, now you know.)
• I’ve recently revived the RTS gaming genre on my system by reinstalling Age of Empires 3. I don’t recall why I stopped playing, but I shouldn’t have.
• In case anyone wonders why I haven’t been on WoW for a while, it’s because I let my subscription expire. That was over six months ago, I think. Honestly I have not missed it. There are more fun games out there, and they don’t require a monthly fee. Team Fortress 2 is an especially good option if you like class-based games and first-person shooters.

That’s all for now, I guess. Stay tuned for some more developments on Banshee.OpenVP in the coming weeks.

I spent some of Tuesday porting some of my older OpenVP visualizations from XML-serialized scripted effect presets to “real” preset classes, and committed them to Banshee.OpenVP. The results:

Hopefully, anyway.

I spent some time this last week (probably over 15 hours total) giving the Banshee visualization pipeline another overhaul. In the process of doing this I finally filed a bug I found in the spectrum GStreamer element that I’ve been trying to work around for a long time.

Even though Sebastian was able to fix this specific bug, another crept up, which he did fix, but it became apparent to me that using the spectrum element was the wrong approach. I won’t go into too many details, but it made disabling and re-enabling the pipeline incredibly tricky and required a buffer of spectrum slices that had to be synchronized with a mutex since it was being accessed by three threads.

Sebastian gave me some pointers on using libgstfft directly, and this has reduced the amount of code required to do spectrum analysis while making it less laggy and less of a hack.

I’m told this patch (and possibly Banshee.OpenVP) will be going into Banshee 1.6. Sweet.

Mandatory screen shot of the new code and of the new Voiceprint visualization in Banshee.OpenVP:

Update 2009-01-22: I had to revise the patch to fix a segfault caused by a race and to eliminate some timing issues with thawing synchronization. The link to the patch has been updated.

I got the replacement for my defective laptop display on Saturday and got around to installing it last night. So far everything looks good. There are no defective pixels as far as I can tell and, as a bonus, it’s a matte display instead of the glossy one that came with my laptop. Woot!

I stumbled across this bit of Apple awesomeness today. If you look at the huge splash image, you’ll note this text to the right of the mouse:

Touch-sensitive technology detects right and left click.

Oh? I’m sorry, I was under the impression that you manipulated mice with telepathy, not with touch! What a revolutionary invention!

So here’s the timeline as I see it:

1. Apple comes out with their first Mac with one mouse button to make things simple, because two buttons on a mouse is too much.
2. People complain, so they come out with a two-button mouse. People associate those with PCs and hate them.
3. Some years later, Apple invents a mouse that looks like it has one button but behaves like it has two, due to fancy “touch-sensitivity.”
4. Apple fanboys everywhere rejoice that they can now do two things with their mouse without being seen with a two-button mouse.

I predict that next year Apple will invent:

• Touch-sensitive keyboards,
• precision air-compressing speakers,
• and light-emitting monitors.

Oh, and by the way, the price tag on that fancy touch-sensitivity? $70.

Switching to a new web host is always fun. I spent most of Monday and Tuesday trying to get the Subversion client and Apache module installed and working. Today I tinkered with Sendmail enough to get it doing what I want.

Installing Subversion was much more tricky than it seemed at first. My host has libapr 0.9.4 installed, but Subversion requires at least 0.9.7 since earlier versions can corrupt fsfs repositories (which is the type I prefer). I tried 1.3.3 and ran into some interesting problems.

The core issue was that 0.9.4 was in /usr/lib, and the dynamic linker was grabbing that one for Apache before 1.3.3 was loaded for the Subversion module. Since 0.9.4 was loaded first, and 0.9.4 and 1.3.3 share symbols, some of the functions the Subversion module calls were being incorrectly linked to the 0.9.4 version, which presumably is not ABI-compatible since the major version number differs. This resulted in segmentation faults on every request to the server, effectively taking down my website. In order for this to work I would have to get the dynamic linker to take 1.3.3 first, but then Apache would have the same issue — using an ABI-incompatible version of a library it was linked against.

So I got 0.9.17 and installed that, then ran into another dilemma. 0.9.4 is in /usr/lib, so it gets priority. The dynamic linker was still loading 0.9.4 first and loading 0.9.17 when Apache loaded the Subversion module. This means that the module, while linked against 0.9.17, would effectively use 0.9.4. So corruption of fsfs repositories would still be a possibility.

This is where a bit of the weirdness begins. My host gives me write permissions on just about every directory, including /usr/bin and /usr/sbin. But for some reason, not /usr/lib. So I couldn’t just divert the libapr-0.so symlink over to 0.9.17. I was stuck here for a while, mulling the issue over.

A few hours later I returned to the problem with an idea: /etc/ld.so.config. This is where the list of library directories are stored, and the first ones listed get searched first. /usr/local/lib was at the top, followed by /usr/lib. Since I installed libapr in an alternate prefix (/usr/local/apr), I had two options: symlink to 0.9.17 from /usr/local/lib, or add /usr/local/apr/lib to /etc/ld.so.config. Yes — /etc/ld.so.config was writable, and /usr/lib was not. Go figure.

I decided to add my libapr path instead of symlinking. And now all is well in the Apache world.

That describes the last two days. Today I had the unpleasant task of trying to convince sendmail that mail for chrishowie.com should not be delivered to local mailboxes on the web server, since I don’t use my host’s mail service. After poking around with sendmail.cf for an hour or two and not making any headway I joined #sendmail on Freenode and requested help. Between all the comments about how my server’s hostname should be www.chrishowie.com and not chrishowie.com (something that’s out of my power to change) I got some pointers that lead to a new, minimal, and working sendmail configuration:

OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
FEATURE(`stickyhost')dnl
FEATURE(`nullclient',`chrishowie.com')dnl
undefine(`ALIAS_FILE')dnl

Ta-da. Now all email sent from the server goes through my domain’s real mail servers.

That’s the last thing I had to do to get my hosting where it should be. At this point I consider migration to the new host complete. Now I can return to coding that C# networking stack…

It’s that time of the year again… when I get to relax after completing finals. It looks like I’m going to pass everything too, which is a pretty big deal since I literally cannot fail any class I’m enrolled in and still graduate in May. So now that I have some time to myself, here’s what I plan to do:

• Prototype a web application for a Moodle-based tutoring system that I’ve been developing for my university. This really isn’t “me stuff” but I enjoy a good PHP+JavaScript+AJAX coding session.
• Try to work some more on OpenVP. I recently looked at some of the old visualizations I wrote for Winamp 2′s Advanced Visualization Studio plugin. Wow… OpenVP has some ground to cover. My goal is to port some of my better visualizations (which are loads better than I remembered them being) to OpenVP for the very first release as part of Banshee.
• Try this again and report the results to C.J..
• Try the newest PulseAudio with the Flash 10 beta. Hopefully the problems I’ve been having were resolved by now.
• Ship my defective laptop display back to the eBay seller for a replacement. According to him, having two defective pixels doesn’t qualify for a Dell warranty replacement (four are required — the ‘tards), but he is going to replace it with another from his stock. Seems like a nice guy. He’s got a store on eBay if you feel like browsing.
• Probably some other stuff I forgot already.