Planet Geek

Coconut gets a facelift

Ever since I first wrote Coconut, the web interface to CONGO, I've been using the same stylesheet. It was really my first foray into stylesheet-driven design and layout, and while it was a good first try, it was ugly as sin.

Last night I finally sat down to rewrite the stylesheet into something reasonably attractive. I got rid of the dark background and greytones, and the 'All Caps' font styles, and used more pastels.

I'm pretty happy with the result, but for the hundred or so folks who are used to the old look and feel, it'll be a dramatic change!

Dear Jboss. QA yer damned site.

Why is it so hard for any organization, from opensource on up, to understand it's a good idea to give the users information they want, in a form that's useable?

I zipped over to JBoss.org to see if there was an update to the 4.2 server I've been using for the last year. Sure enough, there's a 4.2.2 release that came out in October. Great, I wonder what changed?

Well, the downloads page has the new release on it, and a link to the release notes. Which, you'll note, is completely illegible because the lines are not wrapping. (I tested this in Firefox under Linux and Windows, Konqueror, and under IE6 in Windows. None of them make that page useable.)

Was it so hard for the JBoss release engineer to click on links and check if they worked? Apparently that capacity is beyond them. Sad.

Things I Learned about CONGO at Arisia

This year's Arisia, as previously noted, was special in that while I wasn't actively running registration, I was functioning as technical support and consultant for the process. There were a number of organizational, technical, and logistical challenges that came up, and I learned some interesting things.

Ahh, the printers. If there's anything that better personifies the challenges of running registration, it's dealing with the badge printers. I made a decision back when I first starting doing events in 2003, that badges for events should be printed on the fly, in realtime. When a person comes to the registration desk, they should be able to be checked in, and their badge should come right out of the printer. What this means is the system must be up, functional, and running at peak throughout the entire event.

I figured out at one point that I've run something like 50,000 attendees through CONGO and my printers. Some at large > 10,000 attendee events, and some events as small as 150. Every one of those events has it's own challenges. But in there, I got a very good handle on queue operation and throughput management. Badge printers only run at such and such a speed. If you're registering people faster than the badge printers are running, there'll be a backlog, etc etc. I've only had a serious backlog at the badge printers three times in all my time working events, and each time I've increased capacity and stability each time. That doesn't help the folks who had to wait in line (and in fact I've lost a major customer because of this), but it does make it so it won't happen again.

Until this past year, I had been using the same badge printers and print queuing system. Fargo Pro thermal printers. I have 3 of them, and for the most part, they're solid, hard working printers. At the last big event, I had all 3 running, but realized too late that the HP Jetdirect EX 3 Plus ethernet print server, which sounded like a dandy way to drive multiple printers... was in fact single threaded. It could handle only one print job at a time. So while I could have 3 printers hooked up, only one could be printing at any given moment. Needless to say, this was not an optimum solution

So over the last year, I've invested in replacing all my badge printers with Evolis thermal printers. I now own 2 Pebble3 printers, and a Dualys, all purchased off eBay. These printers are USB based, are much smaller and lighter than the Fargos, and are much much faster. Cycle time from power up to badge coming out is about 4 seconds (a Fargo, from a dead stop, would take about 12). We had used CONGO and Evolis printers at two other events already, but this was the first time they'd be under 'heavy load', and being pooled into a shared CUPS print destination

First, I have to say, it worked fine. We ran the event beautifully, but it turns out we were not running the printer pooling right. Due to the speed of the Evolis printers, it didn't matter, but because of some oddities in how CUPS assigns USB ports when a printer goes on or offline, we rarely had both printers in 'pool' mode for more than about a half an hour. Hopefully, I'll be able to figure this problem out going forward, but alas, it may be that a USB based printer pool, with identically named print devices, may not work well. There is no way to identify each printer - they're assigned dynamic printer port names as each device powers up. So printer 1 will become printer 2, etc etc. Adding to the issue is that it appears the Evolis printers take themselves completely offline if there is a problem. CUPS then removes the printer from the pool, and that printer no longer receives jobs, even if it's put back online. I need to go into the CUPS control panel, and re-add the printer. But which one is it? Printer 1 or Printer 2? Aaargh

Newer versions of the Evolis have ethernet ports built in, and I suspect the proper thing to do is start using them directly. But I already have a fairly heavy investment in these printers, so I'm not sure really what I'll do.

I have been doing some fairly heavy hacking on CONGO over the last year. I completely flushed out the horrific mess that was the badge printing interface, and replaced it with a generic layout mechanism that any registration operator can use to lay out the badge imagery. I also replaced the "draw the badge into a big GIF, and then print the GIF" way of doing things with a PDF library - the fonts look much better, text automatically wraps in blocks on the badge - a Major improvement.

Also along the line here I modified and cajoled CONGO into a configuration that will work properly on Windows machines, and documented the whole process on the CONGO wiki. These are just the next steps necessary to release CONGO into the opensource world.

Yep, you read that right. I'm finally opensourcing CONGO, under a new license. It's really time for other events, particularly fandom and gaming events, to have access to this system. Stay tuned for more info on that front. I still have to work out some of the license complexities, but it's definately coming

I bit the bullet and ditched LTSP for simply installing a mini Linux installation on each of the SFF PC's I had accumulated. I settled on Damn Small Linux for it's very simple installation and "It just plain works" desktop. I had high hopes for PuppyLinux, because of it's nice desktop and active community, but the project seems to be stalled, and I could not figure out how to do a hard disk install. After 2 hours of tinkering, I gave up. DamnSmallLinux installs from power on to "installed on the HD and ready" in about 11 minutes. Hard to argue with that.

There was some trepidation doing so much change just before the event, but I spent a fair amount of time in the basement, setting up each workstation, testing it's booting and configuration, and documenting all the settings. I was pretty comfortable.

Well, if you're going to revamp everything, why not do it whole hog? Endor, veteran of dozens of cons, and even being left in an airport, was due for a rebuild. Debian Etch came off, and Ubuntu Feisty went on. I kept all my data dumps, and spent a few days reconfiguring all the little things that had been bugging me through all these events. The primary goal was to make the server and workstations 'setup-able' by mere mortals. To that end, I...

• Made 'endor' boot up to a desktop, rather than a login screen
• Made the CONGO appserver start and stop automatically via a custom written /etc/init.d script
• Made sure the print queues came up by default
• Configured the workstations to boot cleanly and start up Firefox, with CONGO as their home page

With these changes, the folks running Registration had no problems setting up and tearing down the system. Even when someone mistakenly unplugged the server, they were able to bring things up without any intervention by me. This is in stark contrast to previous years, where manually starting and stopping the server was a complex process that I or one of my well trained cohorts had to do.

We purchased the badges from a print shop in Texas, and I have to say, I'm totally satisfied with the results. The quality is excellent, and they were communicative and helpful. For once, I didn't have huge stress around the badges (previous events have seen us receiving badges with the wrong coating on them - when the badge is run through the printer, the thermal 'ink' doesn't stick to the badge. I've had 3 events where this has happened, and let me tell you, it's no fun.

We also used nylon 'clips' for each badge. These come in bags of 100 or 500 each, and unfortunately, some overly eager operator 'cleaned up' the area Friday night, which resulted, we suspect, in some clips being thrown away. Saturday late morning we realized we weren't going to make it with the current stock, and I made a quick emergency drive to my home in Natick, and picked up another bag full of clips. Yay for being nearby!

Ribbons and cleaning supplies went over fine, and changing the printer ribbons in mid-con went great. The Evolis printers take very simple ribbon assemblies, and each ribbon runs for 1000 prints. We changed out the ribbons in both printers on Friday evening, and after figuring out how to run the cleaning badge through one machine, we were all set for the weekend.

One thing I'm still kicking myself about is I did not bring any lanyards. I had tried to get an order of lanyards from one of my suppliers, but a comedy ensued where the sales rep quoted me a price that was 3x as expensive as what was on the website. Alas, it got too late, and I missed the opportunity. What made this doubly frustrating was when I was home getting the badge clips, I discovered a box of 1000 lanyards up on a storage shelf. Sheesh.

Now that the con is over, I'm ready for the next phase of work. I don't think there's a lot of need for change in the system layout (though moving the monitors to and from events is still a pain), but CONGO needs 'the next phase' of work. I'm already in mid-coding, and our Bugreports page still has a lot of open issues. But even with these known things, I have, in my head, a good idea of what the next steps are:

• Make a 'publically accessible' registration page, where attendees can visit and check on their registration status or register for events.
• Finish cleaning the codebase
• Finish documentation so 'those other than me' can use it
• Release the source
• Work on some more detailed reports and information analysis
• And, most importantly, start expanding CONGO into more event management areas. Manage events and panels as well as just plain registration. There's another application called Zambia, written by some Arisia folks, that interfaces loosely with CONGO that can manage panel subscriptions and brainstorming. We're working together to see if we can make the connection stronger and more stable.

For me, this was the most stable and best run convention yet, particularly for it's size. I feel like I've hit a stable plateau for the system and the software, and I'm ready to go to the next step.

This morning I slept late

Now, why is this remarkable?

Because I am at Arisia, and for the last 6 years or so, I've been running (or helping to run) registration. This means getting up very early Saturday morning to set up and run CONGO for the days registrations.

This year I'm not running reg. Oh, they're still using CONGO, but a few weeks of tunning, fiddling, and refining, and the system is now startable by mere mortals. I was still 'awake' at 8:45 (registration opened at 9), and I was waiting for the phone to ring with a problem... but it didn't ring. All went well, and I happily slept in until around 9:30.

In some ways, it's awfully nice. In others, I'm sort of mystified. What am I supposed to do with my time now?

Buy my printers!

I'm unloading my old badge printers to help finance upgrading to new, smaller, lighter printers from Evolis. This means the badge printers I've been using at conventions for the last couple years are up for sale.

See the Craigslist ad for details.

Zorching Memory Leaks. I Am Teh Stud

Tonight, I am Da Man.

It's rare I get to sit down and see, so directly, a problem in the code I'm working on. In this case, while running at Ubercon the other weekend, I noticed that CONGO was showing every sign of a memory leak. After a while I'd get sluggish performance, and eventually I'd get an OutOfMemory error from the JVM. Didn't look good.

This had me in somewhat of a panic, since Arisia is right around the corner, and I need the system stable and useable for the event. With the help of the wonderous tool that is JConsole, I was able to actually see the memory usage going up in the JVM as I worked with the server. There was definately a problem.

It turns out my hastily set up code to handle changes to my JDBC driver was not being handled correctly. Apparently with the old mm.mysql driver, SQL handles were automatically closed at the end of use. With the new Connector/J driver from MySQL, you had to explicitely issue a close() statement on any Statement, or the handle would never be freed. This was probably always the case, it was just my sloppy code and a twitch of the old driver that made it never come up.

Unfortunately, this necessitated changing just about every SQL call in the server, all 10,000 lines of it. It was long, painful, boring work. I had some help from blk, but it still took a good week of off-hour fiddling to finish the changes and do some basic regression tests.

Tonight, I made the last set of changes, did some basic runthroughs, and didn't have a single crash. With someone trembling fingers, I started up JConsole again, connected to the application server, and started working with CONGO. Registrant lookups, reports, modifications, creations, subscriptions, convention detail editing - throughout it all, JConsole happily continued showing the normal 'sawtooth' pattern of memory usage. Things would get allocated, used, and then the garbage collector would come along and reap the memory.

Success! I had successfully searched for, found, and fixed a major memory leak that was persistent throughout the code.

For those insisting on the details, here's a properly structured, Prepared, and appropriately exception-managed call to get a number from the database. (And, before I get abusive comments all over the place, the Exception handling here is VERY POOR, and will result in a clean result coming back from the method, even though the call may have crashed. I know, thank you, now go away).

private static int calcRegistered(int cid, String typeName) {
        PreparedStatement p = null;
        ResultSet rset = null;
        String sql = "SELECT count(*) AS total FROM reg_state " +
            "WHERE state_cid=? AND state_regtype=? " +
            "AND state_registered=1";
        int value = 0;
        try {
            p = cserver.Conn.prepareStatement(sql);
            p.setInt(1,cid);
            p.setString(2,typeName);
            rset = p.executeQuery();
            if (rset.next()) {
                value = rset.getInt("total");
                logger.debug("\tcalcRegistered: count for conference '" + cid + "', type '" +
                   typeName + "' is --: " + value);
            }
        }
        catch (Exception e) {
            dumpException(e);
        }
        finally {
            try { p.close(); }
            catch (Exception e) { dumpException(e); }
        }
        return value;
    }

I feel all geeklystudly.

Next is to start seriously hammering away at the buglist, and get a test environment set up so other CONGO users can test out the new Merge function against 'real' data. If all goes well, we'll roll this version into production in time to run Arisia.

Deep Breath.

Aaaaand, we're back.

What an insane couple of days. There's a whole series of posts brewing in my head right now, but I'll just touch on probably the one that's most on my mind.

Last week, I was in mid-preparation for Ubercon, an awesome gaming convention I regularly work down in NJ. CONGO has been pretty idle for the last few months as the summer is not a big time for conventions. With a week to go until Ubercon started, it was time to pull out all the hardware and make sure everything was working.

Well, unsurprisingly, it wasn't.

The first major issue was coming to the conclusion that endor, the venerable server of dozens of conventions, really wasn't going to handle Yet Another Apt Upgrade. It was still running on a baseline Debian Sarge install that had been upgraded a dozen times over the years, and finally, after enough apt tweaking had gone on, a dependency just wouldn't resolve, and the machine would not take new upgrades. It was time to nuke from orbit and reinstall the OS from an Ubuntu baseline.

No problem, sez I. I whip out my Gutsy Gibbon Ubuntu CD, do a quick database dump and backup, install Ubuntu, and restore my home directory and databases. Reinstalled CONGO, loaded the working databases and...

stopped.

See, CONGO was my first big Java application. And as such, it has some... intriguing ways of doing database work. And by 'intriguing' I mean butt-ass stupid. In particular, not using PreparedStatements for SQL commands, not checking for failed transactions, etc etc. While this was okay for a fairly static application, once you replace the entire OS underneath it, things start to get a little squirrely. And, well, we had squirrels aplenty.

So over the space of 3 days I basically had to rewrite every SQL interraction in CONGO, resulting in some fairly major code changes, and all of this 3 days before a con.

Add on top of this the fact that I'm also using a brand new printer from Evolis for the first time under Linux. There's a whole nother post about this experience, but it did bring yet another variable into play. Oh, and did I mention that I rewrote the print routine in CONGO to generate PDFs on the fly and use them for badge rendering? Yep, also new.

Needless to say, things were a little panicy leading up to the event. Fortunately, by Wednesday afternoon, I had things fairly well stabilized, the code worked, endor was stable and functioning properly, and I could start packing for the event with a clear conscience.

The end result? It all worked. The convention went fine, the printer behaved wonderfully, running badges twice as fast as my old Fargo printers, and we had only minor glitches through the weekend. There's still some work to do to get endor ready for larger events, but for a week that started out with totally broken software, an unuseable server, and an untested printing system, things went mighty well.

Onwards.

Of Systems and Services, Mame and Madmen...

It's been a challenging few days here at Chez Geek. In true journal fashion, here are the highlights, because I know my devoted readers are sitting on the edge of their seats, waiting for every geeky installment of my daily encounters with recalcitrant hardware, misconfigured servers, and twitchy environments.

Ahem.

Of Mame...
On Friday night I finished wiring the console. I'm short a half dozen buttons, so some functionality is missing, but I really wanted coin drop buttons. I picked up a couple small single-throw pushbuttons I had lying around, and wired them in with duct tape, so now I can 'drop coins' to get credits just by pushing a button on the console. Looks like ass, but it does work. I've ordered the new buttons, and they'll arrive in a couple days, and I wanted to play games NOW.

There's a whole post about things I'm learning regarding building a Mame cabinet, but that can wait. For now, I'm using deathstar, my MythTV box, as my 'mame front end'. MythGame is "okay" as far as interfaces. Mostly it's "okay" because it's actually working correctly, and works with the controller. I'm hoping to haul the entire setup to Ubercon this coming weekend, so minimizing fuss is a big win.

Of Stonekeep and Conventions...
Next weekend I'll be down at Ubercon in New Jersey. This of course means I need to get most of the CONGO system up and running to run badges. Unfortunately, endor is not behaving. After almost 4 years of constantly apt-getting and updating packages on it (Starting from a Debian 'woody' install), a series of packages failed miserably during an upgrade (I haven't really worked on it in about a year), and has left it in an unuseable state. I've backed the data off it, and reloaded Ubuntu Feisty Fawn on it. There's a bunch of configuration that still needs to be done, and that's making me nervous so close to an event. At least the install seems to have completed cleanly.

Those are the two primary things on my mind these days. Oh, and in the background is ongoing Java work and the slow moving ahead of Mosaic Commons, but that's sort of the 'steady noise' bits. I'm just covering the highlights right now.

Head-Slap morning

Boy, nothing like realizing that one of your sites has not been serving up content for almost 2 months. The site is 'up', but any queries into it returned nothing. Very useful for a lookup/reference tool. :-/

One of these days I'll get a monitoring system in place that's more advanced than "Is the server up?"

Windows as a useable Java development environment?

Recently I had to spend a fair amount of time working on CONGO on a Windows XP platform. Stonekeep is doing doing it's first event where CONGO will be running entirely on Windows XP, so all the environmental stuff I'm used to having under Linux doesn't work, naturally. Things needed to be updated. This presented many challenges...

Normally I'd just import CONGO into Eclipse (where I've been doing most of my Windows development), and run with it, but CONGO was my first 'big' Java app, and, well, I made some poor design decisions that make moving it into a formal structured environment like Eclipse... somewhat problematic.

What I needed to do was set up my Windows XP environment to behave very in a similar fashion to my Linux environment, without trying to reproduce Linux-under-windows. I've gone the Cygwin route before (which tries to emulate a Unix environment completely), but I found the inconsistencies got in the way of being productive, and the installation overhead is enormous. So I needed a compromise.

The needs

There were several basic functions I needed to have in order to run the two sides of my application successfully. CONGO consists of a standalone 'application server' (called 'cserver') which runs in it's own standalone Java process, answering XMLRPC requests, and a PHP-based webclient called "Coconut", providing the user interface. To run both these pieces I needed Java, PHP, a webserver, a database, an installation tool, an editor, and a way to interact with my SVN repository.

The Tools

LAMP
A large part of my needs were covered with XAMPP, a bundled set of tools that provides LAMP functionality to a windows environment (WAMP?). With one swell foop, I had a PHP interpreter, an Apache webserver, and a MySQL instance, plus a database tool (phpMyAdmin).

The Compiler
Sun provided the appropriate JDK (Java Development Kit) to compile the application server as needed. I don't have a binary distribution of the code yet, so an installation consists of checking it out of SVN and compiling it. The JDK installed just fine (into C:\Program Files\Java\jdk-versionumble)

The Editor
For an editor, I chose to work with JEdit for a while. It's a pretty editor, and is completely Swing based. It has some annoying twitches, and I'm not sure if I'll continue using it in the long term, but for this event-cycle, it was fast, workable, and did the job just fine.

The Build Tool

Build tool - This is one of the sticking points for portability into Eclipse. I don't actually compile CONGO in a 'normal' fashion, and my class definitions are all screwed up. To address my odd setups, I use Ant, a very very good build tool specifically designed to work with Java projects. I had already been using Ant build scripts on my Linux installations, so having this available under Windows was a huge win.

I downloaded the Apache Ant binary distribution, and unpacked it. Because Ant is basically just a simple command line tool, it really doesn't have a Windows installation process, it just needs to be unzipped. I put it in C:\Program Files\ant.

The SVN Client

This one was a toss up. All my code is stored in an SVN repository on a remote machine in a colo facility. In order to check in and out code, I needed to have an SVN client on the machine.

The natural inclination would be to download the command line SVN client, which is available from Tigris.org, but that seemed to be me falling into the "it must be just like Linux!" mode, which I was trying to avoid. Instead, I opted to install Tortoise SVN, a tool that integrates SVN functionality right into the Windows explorer. This turned out to be an EXCELLENT choice. I found TortoiseSVN to be stable, fast, and eminently useable for my checkins and updates, without having a steep learning curve.

The Configuration

So far so good. I had all the tools I needed, but Windows isn't normally comfortable with command line only interaction. I could spend time configuring tools into JEdit like Ant Farm and the like, but that runs the risk of being distracted with some serious yak shaving, something I didn't have the time or the inclination for. Instead, I opted to set up Windows to handle command line use of Ant.

The primary challenge here was setting up the paths correctly. Under Linux, I'd simply add the path to my .profile and off I'd run. Under windows it's slightly more challenging. I found a handy little shortcut for doing a 'fast' path change similar to using $PATH in Linux:

In Linux:

$ cd /usr/ant
$ export PATH=$PATH:`pwd`

In Windows:

C:\> cd "\Program Files\ant\apache-ant-1.7\bin"
C:\Program Files\ant\apache-ant-1.7\bin> path=%path%;%cd%

This shortcut is a great way to make sure all the things work correctly before actually modifying the system. I did this for both the JDK and for Ant, and lo! I was able to do 'ant' commands, builds, and run my app. Hooray!

The last bit was to change my default system path under Windows to include these new directories. This was accomplished by following the tortuous path:
Right click on My Computer->Properties->Advanced->Environment Variables...
Then scrolling through the 'System Variables' until you find 'Path', click 'Edit', and append on the JDK and Ant binary home directories. Windows thoughtfully makes this input window only about 30 characters wide, without the option to resize, so expect to do a little scrolling. Phew. But this meant these paths were set every time I started up a CMD.exe shell

At the end of it all, I had a clean environment where I could not only run my appserver, but also use Firefox to access Coconut. Hooray!

Conclusions

It's hard to buck trends. There's no question that Windows is used for serious work, but many Linux users scoff at the concept of using Windows as a viable development environment unless you're doing Windows specific coding, such as .NET or Visual Studio type work. Much of this derision comes from the different approaches to environment. Windows tends to be pointy-clicky, doing a lot of 'assistance' to the developer. Linux programmers prefer command line editing and compilation (though that is rapidly changing as tools like Eclipse, IDEA, and Netbeans gain popularity). Regardless, this article shows it is possible to set up Windows for simple command line operation, with some of the benefits of a full GUI, without spending hours upon hours tweaking and installing random tools.

Lo, I am blocked

So I frequently park myself at the local Panera to partake of their free wireless, tasty coffee, and comfy chairs. It's also convenient that it's halfway between home and my son's school.

Yesterday, I stopped by just to get out of the heat. Since I had an hour to kill, I worked up my last blog post, put it together and posted it. So far so good. I traditionally look at the site at it's base URL (http://planet-geek.com/) just to make sure everything is okay. This time, apparently everything was NOT okay.

Apparently access to my blog has been blocked by the infamous Sonicwall 'content protection' system. Nice of them, eh?

Further research into this problem, by following their url, showed that I was not blocked for my abysmal spelling, my poor site layout, or my lack of meaningful content, but that I was simply classified as... pornography.

I had no idea geekitude had slipped so far into the internet's dark underworld.

Naturally, I immediately put in a request to have it reclassified, and demanded an explanation as to WHY my little corner of geekness has been classified as Pornography. Alas, Sonicwall doesn't provide such information, you may simply ask for a reclassification, and they might get around to it. In 8-10 days. What do you bet that I won't hear a thing from them in that timeframe?

If you'd like to grease the wheels against this idiocy, please go to Sonicwalls' ratings page, look up 'planet-geek.com', and request to have it reclassified as an "Information Technology" website.

I still would very much like to hear from Sonicwall, or from anyone else, who has had their site randomly excluded from anyone who uses their product, with no notification and no recourse except for a 'request for reclassification', why this occurs and what can be done about it. I'd also recommend that ANYONE who hosts or runs a website to plug their URL into that page and check to see if they're being blocked.

JBoss Release Grumpiness

This is a geek gripe. Particularly for Java programmers. If you're not doing JEE development, this probably won't make a lot of sense unless you like seeing open source companies being beaten up for version incompatibilities.

Hello, I'm Dave, and I'm a JBoss developer. (Hi Dave...)

Until recently, I was quite content with the series of tools available for JBoss4, and my chosen IDE, Eclipse. JBoss provided a lovely little plugin interface called JBoss IDE. I encourage people to click on that link, because you'll walk through a series of redirects until you land on a page that, amazingly, has no information on where to get JBoss IDE! How wonderful!

It turns out that JBoss (now wholly owned by Redhat has pulled JBoss IDE in favor of another Eclipse plugin called Exadel. Fantastic, a new IDE plugin that has a lot more functionality than JBoss-IDE ever had. Lets take a look!

An hour later, and Exadel is installed and running and grand. But. Wait a moment, the latest version of the JBoss application server is 4.2-GA. That's General Availability. Meaning the platform is released and is the recommended system for users.

Exadel has no configuration support for 4.2-GA. Only for 4.0.x releases.

And JBoss-IDE has been pulled completely (and even it's '2.0.0-beta' version, the most recent version they posted, did not support 4.2).

"Must be coming out shortly." So I mailed off to Exadel tech support asking if there was 4.2 support in the works, or when it will come out.

I get a direct, and undeniable response from them:

Dave Belfer-Shevett wrote:
> > Exadel Support Team wrote:
>> > > Exadel Studio Pro is going to be re branded as Red Hat Developer Studio in
>> > > later summer. Red Hat Developer Studio will support JBoss 4.2 .
> >
> > So the answer is "no, it does not support 4.2 now, and won't until late
> > summer" ?

That's correct.

-The Exadel Team

Excuse me, but WHAT THE F??? We've pulled the old IDE toolset. We've released a new product. But you CAN'T USE IT WITH OUR IDE TOOLS! Hahahahha! And you won't for a couple months. Sorry bout that, have a nice day.

There are workarounds. You can run the jboss server externally in a windows shell and deploy to it. This is a painful arrangement, but I guess I have no choice?

Thanks for leaving us all in the lurch, JBoss.

MySQL Geekery du jour. Cannot open file error.

This one is going out to the world in general, because it took me 2 hours of googling to find it, and I want to lessen some poor other slobs pain...

MySQL , in this case on a Debian Etch (stable) install, has a limit set on the number of files that can be opened in the mysqld server. Apparently when you start getting close to this limit, like doing something that opens a LOT of tables at once, you start bumping into it. This article describes how to fix this.

For me this happened when trying to do a 'mysqldump' of the Drupal 5.0 installation we have. Drupal 5 can put all the sites tables into a single database instance. Of course, that means when you do the mysqldump, if you have a large number of sites, you're dumping a large number of tables.

Like, say, 530.

In the default configuration, this causes mysqldump to barf with an unhelpful message like this:

dbs@boomer:~$ mysqldump -uroot -p drupal5 > /tmp/drupal5.dump
Password: 
mysqldump: Got error: 1016: Can't open file: './drupal5/sierraterm_data.frm' (errno: 24) when using LOCK TABLES

The actual file name can vary, depending on at what point the limit was hit.

To fix this, a change to the my.cnf file (on Debian distributions, this is in /etc/mysql) needs to be made. In the [mysqld] section, add:

open-files-limit=15000

You'll need to restart mysqld to make the change active.

Once this change is done, your dump should proceed normally.

(A big nod to the folks on #mysql on Freenode for nudging me in the right direction on this one)

Getting a release out the door

It feels good when you finally push a release of a product out the door.

The last 2 months I've been spending a chunk of time doing updates on Keystone. It's always fascinating working on code that is pushing 10 years old, seeing things I remember writing during the dotcom boom, and finding other tidbits that make me go "What the HECK was I thinking?"

This release is interesting in that much of the work was pay-for contract updates from a customer who wanted to see some bugs fixed and a few enhancements added in. It's nice working on something you enjoy, and getting paid for it as well.

The code is just about ready for it's next major overhaul though. I'm trying to get up the gumption to rip out the entire database back end code and replace it with ADODB. I wrote my own database abstraction layer back in, oh, 1998-ish, but really, the world has moved on a bit since then. It's time to move with the times.

Good things aligning.

It's easy to gripe and moan and stone-kick when doing business travel. While it's become routine for me, it's really easy to fall into the "man this sucks. I miss my family" mindset. But this trip, I tried to schedule it carefully, work out what I was trying to accomplish, and stay focused on what needed to be done.

So here I am, on my way home, and generally, things worked out okay...

• In three days, I got an enormous amount of JEE development and design done. Much code was checked in, it works, and the client is happy.
• Designs I implemented almost two years ago in this project are coming to fruition. This week was the first time we discussed implementing the first application on the framework I designed. Everyone is excited.
• Clipper continues to be a faithful companion, despite it's handicap of running Windows.
• On the way home, I'm able to stop at one of my favorite food establishments, and partake in a beef burger ritual.
• Double bonus - said restaurant has an open WAP nearby. Thank you whoever you are.
• From nowhere, a paying client has contracted with Stonekeep to do a series of large updates to Keystone. Wootie!
• Mosaic is preparing for the final signoff on the design of our homes this Sunday. This is a huge step - it's where we tell the architects "Go!" and step back to watch the fun.

All in all, a mighty good week. Now all I have to do is drive home in the rain. Fortunately, that's what XM is for.

The Seven Tools that Linux Needs to Have A Chance on the Desktop

Don't get me wrong, I love Linux. It's everything I wanted from an OS. Speed, flexibility, games, eye candy, productivity, and powerful development tools. But there are certain things it lacks that remain as barriers to wider adoption.

The grand daddy of third party applications for Windows, Photoshop from Adobe, is the de facto standard for graphics editing. Designers use it to mock up websites, photographers use it to modify their artwork, it is the tool to end all tools for graphics manipulation.

But what about The Gimp? Yes, there is a very powerful tool out, in the form of the Gimp, arguably the most complete and useful tool to come out of the Gnome project. (In fact, much of The Gimp was used as the basis for Gnome, notably GTK). Gimp has gone through many updates and truly is the most polished of the available apps. In this, Gimp can be considered a useful replacement for Photoshop, incorporating many of the features that PS provides. But it isn't Photoshop. Just as Photoshop's interface can seem impossible to fathom to the regular user, Gimp's toolset is just as complex. While they both have similar feature sets, the learning curve for both is quite steep, and there are far more Photoshop users than there are Gimp users - at least in the professional market.

In this, there can be no argument. There are no applications for Linux that have the depth of support and comprehensive abilities of Quicken and Quickbooks from Intuit. There are several attempts going on in the form of GnuCash and others, but none come close to the functionality level of these tools. Entire businesses base their very existence on these applications, not only as a desktop tool but an online resource for money management.

The Intuit applications are one example where a rewrite to mimic functionality would not be sufficient. There must be industry support for the file formats, the online services, and the support infrastructure behind the applications to make it a viable choice for a small business to make. As it stands now, that structure is not available to a Linux user. In financial applications, unlike desktop applications such as word processors and spreadsheets, years of historical data is frequently stored within the application. A user invests in the software and the company behind it. Very few opensource applications can provide the long term guarantee of support and service required by a personal and/or business financial application.

Love it, hate it, despise it, consider it the root of all evil; however you like to approach it, there is no denying that Microsoft Office is the lynchpin of Microsoft's hold on the desktop market. The comprehensive software suite is the carrot by which any user will naturally migrate toward Windows as a desktop environment. "I'll use any machine as long as I can email my word documents around and do group scheduling." That simple statement unfortunately only has one answer, and that's Microsoft Office, and from there, that means Outlook.

Because of this reality, there is zero chance Microsoft will every port Office to Linux. It is not a paying environment (unlike the Mac where users will happily pay Microsoft for the application), and supporting Linux as a desktop environment will only hurt Microsoft's hold on the desktop. Also because of this, the Office problem is one that has gotten the most attention among opensource developers and, it must be said, commercial ventures.

On the opensource side, OpenOffice is the clear leader in Office-like applications. Spreadsheet, presentation manager, word processor, graphics editor - they're all there, and to a large degree, they work fairly well, even with Microsoft documents - a fact that is not lost on the software giant. Microsoft knows that compatable tools will hurt their market position, which is one of the reasons they vehemently oppose the Open Document Format (ODF). Why pay a thousand dollars for an Office suite from Microsoft when an opensource version can work just fine on the same files?

Unfortunately, OpenOffice has some serious deficiencies, not the least of which is performance. Microsoft has had 15 years to tune and tweak Office, and has hundreds of developers whose job it is to make Office fast, stable, and useable. The OpenOffice developers have no such luxury, and the application suffers because of it. Tasks that can take a few second under Excel may take 3 minutes under OpenOffice Calc.

And then there's the the Outlook problem. First, in terms of 'pleasure to use' - Outlook is a bad email client. Microsoft has attempted, in one application, to appeal to all users from the stay at home dad up through the Fortune 1000 installations, all within the same program. The result is a muddied, difficult to use, enormous application that, unfortunately, CAN do everything, it just does it all poorly. Most of the functionality in Outlook can be replicated in other email clients, and there are thousands available. The one thing that has never been reproduced to the level that Outlook provides is scheduling. The lack of an OpenSource, usable, shareable calendar system for Linux is the final nail in the 'Not available for business' sign across the Linux desktop. Outlook's group scheduling functionality, when coupled with an Exchange server, is unparalleled. Yes, there are plugins for clients like Evolution that can talk to an exchange server, but that still requires the Exchange server. The net win is zero, and can be argued to be a loss because a Windows box is still required for Exchange, and Windows client is still required to configure and maintain the Exchange server. Where is the win?

What? Skype? Cmon, there already is Skype for Linux! Sure there is, but as anyone who has worked on the Windows version will tell you, the differences between the two versions are noticeable in one huge issue. The Linux version of Skype does not support video.

It could be argued that Video under Linux is hardly an advanced, well supported technology. But with the wide ranging availability of v4linux, and well documented support for various webcams, it's inexcusable for Skype, two years after providing a Linux version of its software, has not provided a working video interface.

In the world of multiprotocol clients for Windows, Trillian has come out on top as the best supported, most frequently updated, and arguably most profitable package around. Supporting all of the major chat systems (Yahoo, MSN, ICQ, Jabber, and IRC), all within an easy to use interface, Trillian has become the default client for a sizeable portion of the community that wishes to not be wedded to only one IM system.

But again the cry goes out. What about GAIM^H^H^H^HPidgin? It does all these protocols just fine, why not use it? Friends, I encourage you to sit down with a Trillian user, and suggest to them to try GAIM. The interface is laughably primitive, so wrapped up in its Gnome roots that the developers are blind to how painful it is to use for someone not intimately familiar with Gnome already. I've tried on numerous occasions to use Gaim to try and unify my two primary communication mediums (IRC with X-Chat, and Jabber-Client-Du-Jour for others), and each time I've found myself chewing the furniture over the idiocy and outright painfulness of GAIM's interface. Perhaps now, with the legal issues with AOL out of the way, there may be hope for updated versions, but I believe Cerulean Studios is missing out on a golden opportunity to get into the Linux market by not providing a version for Linux.

Object-based drawing and charting. Many companies revolve their businesses around Visio drawings. There's really no decent alternative for Linux, and Visio has adamantly refused to allow compatable applications to be developed.

This is a generic category. Lets face it, compared with Windows, Linux is a poor gaming platform. Sure there are some ports for some great games, and the folks on the Wine project have made fantastic leaps in providing a runtime environment on a Linux host for playing the most popular games, but... they're not native. Getting World of Warcraft to run under Linux can be a long frustrating experience, which begs the question "why bother?"

Certainly Microsoft has a hand in keeping the Windows platform viable for gaming, primarily in the form of DirectX, a licensed multimedia interface that many (actually, most) of the game developers adhere to. Windows provides the hardware interface to the devices, DirectX provides the API to the games. It would be great if DirectX were available for Linux, which would make porting the games easier. I don't need to explain that pipe dream.

Many times the media has proclaimed "This is the year of Linux on the desktop!" and, to be fair, Linux has made great inroads here. Many governments are questioning the monolithic "single vendor" problem with Windows and are looking for alternatives. It's a great challenge to these organizations, as there is little lure to Linux on the desktop other than throwing off the yoke of subservience to Microsoft, and until either these applications are made available or viable alternatives are around, Microsoft will never really be displaced as king of the desktop.

Boston and Boston Metro Coffeeshops

As part of my somewhat nomadic working style, I like getting out and about and spending time in local coffeeshops and restaurants. I can do 98% of my business from my laptop, therefore all I need is a comfortable environment, free wireless, and a good supply of coffee.The problem is, trying to actually FIND decent establishments to fill this need can be a real challenge. I'm not talking about Starbucks here - I'd rather support local businesses and encourage free wireless.

So in an effort to help out others with similar pursuits, here's a list of free wireless coffeeshops and / or businesses that I've found comfortable for telecommuting or just 'out of home' work.

• Continental Cafe
  Location / Website: Acton
  Private coffee shop, very comfortable, includes a deli.
• Diesel Cafe
  Location / Website: Davis Square, Somerville (Warning: annoying flash website with sound :-/ )
  The current mecca point for Somerville / Cambridge area bohemians. Note - Diesel's wireless is NOT actually free. But it's a good place nonetheless.
• Crown Plaza
  Location / Website: Natick, on Rt 9
  In-lobby comfortable seating, and a bar / restaurant along one side. Comfortable for meetings, work, and quietly getting things done.
• Panera Bread
  Panera has many locations all over Boston, see this page to find one near you. Most have free wireless. I personally use the ones in Natick, Marlborough, and Burlington.
• Bear Rock Cafe
  Location / Website: Leominster
  I found this place while over visiting my mom's in Leominster. Interestingly, it was all of 40' away from a Starbucks, but had free wireless and a full deli, and was doing good business.
• Cafe Ziba
  Location / Website: Rt 2a in Acton
  I've never actually been here, but it was recommended.
• The Java Room
  Location / Website: Chelmsford
  A nice shop out on 495, comfortable and good coffee.

If you know of others in the area, leave them in comments, and I'll continue updating the list...

Subversion + SSH - Close but no banana

About a year ago, I switched my primary source code control system from the venerable old CVS to the (relatively) new kid on the block, Subversion. On the whole, I've been ecstatically happy with the system. It patched many of the ridiculous problems with CVS, and added on things that opensource community has been asking for for ages (like 'rename'), but never made it into CVS.

Now I have all my projects stored in SVN, and my main client is using it as well for their code (they've chosen to go with SVN and are planning to End Of Life their VSS server - to the dismay of no one).

Subclipse
One of the best tools that made this switchover workable (aside from SVN's similarity CVS in many respects, particularly on the command line) is the Subclipse plugin for Eclipse. Subclipse provides a great easy to use interface into SVN servers, giving all the functionaly one would have on the command line via a very simple, tightly integrated GUI.

One thing that had been bugging me, however, was the access methodology I was using to get to my (remote) SVN server. It involved setting up a tunnel in SecureCRT (though Putty can do it as well), and then telling subclipse to use my 'svn://localhost/stonekeep' repository.

While doing some surfing, I found that Subclipse supports the svn+ssh syntax for specifying the repository. "Great!" says I, "I won't need to set up the tunnel each time!"

A few more fiddles, a pleasant discovery of a configuration screen in Subclipse, and I had an SVN over SSH connection to my repository, even using my ssh key pair.

Danger, Will Robinson!
But wait! All is not well. When I tried to browse the repository from Subclipse, I quickly hit this error:

Could not open file system at /var/lib/svn/stonekeep (13)Permission Denied: Berkley DB Error while opening environment for file system /var/lib/svn/stonekeep/db:

This vexed me, because I had been having no problems accessing the repository locally on the server, and over my ssh tunnel. Both used the locally running 'svnserve' on the repository host, so why wasn't the svn+ssh connection using it?

The answer comes in the SVN documentation, and via a little research:

What's happening here is that the Subversion client is invoking a local ssh process, connecting to host.example.com, authenticating as the user harry, then spawning a private svnserve process on the remote machine, running as the user harry. The svnserve command is being invoked in tunnel mode (-t) and all network protocol is being “tunneled” over the encrypted connection by ssh, the tunnel-agent. svnserve is aware that it's running as the user harry, and if the client performs a commit, the authenticated username will be attributed as the author of the new revision.

When running over a tunnel, authorization is primarily controlled by operating system permissions to the repository's database files; it's very much the same as if Harry were accessing the repository directly via a file:/// URL.

The Problem With This
I'm really unhappy with this model. The problem is that now the user must have read/write access to the entire repository tree. When using a local socket connection (or one over ssh via a normal tunnel), the Subclipse client connects directly to the svnserve process running on the repository box, and interactions with the server happen under that processes ownership.

The svn+ssh protocol does not use the svnserver on the target machine. It tunnels the command to a user-invoked svnserve process, and that process must have read-write access to the repository.

"Well gosh, that doesn't seem too bad. What's the issue?"

The issue is that to make this methodology work, I have to give the user read/write access to the repository tree. Meaning, they could happily type 'rm -rf /var/lib/svn' and destroy the entire repository. Even worse, the configuration files (including the password / access file, which has passwords in plaintext) must be made available to the general users.

Why svn+ssh doesn't simply make a local socket connection to the svnserve process already running, I don't know. But I can find no way to make that happen.

The fix?
As far as I can tell, there really is no direct fix for this. There are various workarounds, which the SVN documentation discusses, including setting up an 'svn user' for the svn+ssh logins, and the possibility of using unix groups for permissions, but I feel that if you have a listening socket server on your repository host, you should use it, not introduce a second methodology and have to jump through hoops to implement it.

For now, I have to abandon the svn+ssh possibility, and go back to my hand-configured socket tunnels. There's no real loss here - they work remarkably well, are very secure, and quite stable. The slight annoyance of having to open up a SecureCRT session before doing work in Eclipse is just that - a slight annoyance. I've dealt up until now, and I'll just continue to deal.

Jabber: I return to the fold.

Quite a while back, I was a fairly avid user of Jabber, the XML based open source messaging system. This was mostly during the Yahoo / MSN / AIM / ICQ 'instant messaging' wars, where each company was trying to push their own system for the hearts and keyboards of the world.

It turned out apparently that marketshare in messaging really wasn't the panacea they had all hoped it was, and the "YOU VILL USE OUR MESSAGE SYZTEM, AND YOU VILL LIHK IT!" approach many of the vendors were pushing has taken a back seat to other business models, like, say, making a good product.

I had no real need for a strong IM platform for a few years, as most of my communication was either done in e-mail or over IRC, but recently I've been spending a fair amount of time in IM with a my client down in New Jersey. As they are primarily a Microsoft shop, they naturally opted for Windows Live Messenger. With a somewhat heavy heart, I installed the Messenger client, and started using it fairly regularly.

In short, it sucks. First, Microsoft seems to be in this model of "Oh, we realize that the Windows interface is butt ugly, so we'll redo the interface again, in sort of a hacked up interface-inside-an-interface model." I first saw this with the Windows Media Player, which has an infuriatingly obtuse interface, while it tries to be 'super-hip'. WLM is just as bad, but it tries to be an effective business tool (shared whiteboards, VOIP, etc) while also trying to be something kids want to play with (online games, cute icons and sounds, etc). The resulting mishmash makes me feel like I'm trying to do business over a speak n spell.

It was time to go back and see if I could use the MSN network, which my customer was wedded to, with a client that didn't suck. A few years ago, this was problematic, as the various IM providers were occasionally blocking certain servers from connecting. (AIM is in fact still doing this for the big public Jabber servers, and Yahoo has a long history of actively blocking non-Yahoo clients.) Recently, the IM providers have backed off their rabid territorialism, and third party clients are easier to work with.

I once again considered multi-protocol clients such as Trillian and GAIM, but to me they solve the problem the wrong way. They make one piece of software that can talk all the different server protocols. Jabber does it differently. It's up to the SERVER to connect to all the providers. You just need to run one client that talks Jabber, and the server does the rest.

My Jabber server has been running without maintenance for over a year, and I was using it occasionally for Yahoo and AIM connections, but now I needed to make the MSN gateway active as well. Fortunately, it was just a matter of apt-getting the msn gateway tools, and enabling it in the server configuration.

Now I'm back - I have a single Jabber client (at the moment I'm using Exodus, which IMHO is the best Jabber client on Windows), and it is happily showing me contacts from MSN, Yahoo, AIM, and Jabber. My old contact lists happily repopulated (they're stored on the server, not on the client), and off I go.

It's been pleasant to note that other services are coming onto the Jabber network, including Google Talk (A jabber system), and LJ Chat for the Livejournal folks - also Jabber.

And, as I type this note, I'm getting messages from the MSN-based folks I mentioned earlier, and Exodus is happily showing them as simple Jabber messages. Joy!

Are you on a Jabber network? Say hi! My Jabber ID (JID) is 'dbs@jabber.stonekeep.com'.

Keystone 0.90.20 released!

After spending a ton of time hacking on Keystone, I decided to drop a new release. Info on it is on the new page at Stonekeep.com.

I'm really looking for bug and stress testers. If you've used ticketing systems before, and want to run Keystone through and open up bugs and issues, I'd love to have your help. Let me know!

All hail USB rechargers!

Gosh, the fellow who figured out that USB devices had enough oomph on the bus to recharge the plethora of mobile geek devices we carry around should get some sort of award. With these gadgets, I've lowered the number of small chargers and other hardware I need to haul around with me when travelling. Here's a couple basics...

My bluetooth headphones have a small Mini-B style plug where the microphone normally plugs in. Pop out the mic, and plug in your Type-A to Mini-B cable in, and voila! It recharges! Conveniently, this cable is the same one I use to download images from my Olympus C770 camera, so there's the first 'combination of functions' solution.

By far the most useful item is charge and sync cable for my Treo. First, it allows hot-syncing between the Treo and clipper. I'm forever losing sync cables and getting lost in the maze of wiring on my desk. This cable not only syncs, but it -retracts- into a the size of a keyfob. No tangling! It lives happily in my backpack pocket. That alone would be handy, but it also charges the Treo from the USB port. Yep, no more carrying another charger around, I just need this one cable. Hooray! As I type, the Treo is sitting on the desk next to me happily vampiring off some of clippers' spare wattage.

What am I missing? Not a lot. I'd like a decent USB based charger for the battery in my camera, but that is probably not too likely, alas. As it is, I've been able to limit my power supply portage to just the laptop brick, which is fine by me. Besides, on cold nights, that brick makes a dandy foot warmer.

Redhat geekery and, of course, swag!

Got to attend a Redhat presentation today on virtualization. They were pushing a lot of very interesting stuff, and while the marketing drivel was in fact kept to a minimum, they did pitch RHEL5 pretty hard, as well as their relationship with Intel.

Of course, the important stuff is the SWAG! Today's haul was a 256meg stainless pen drive - all in all, one of the better bits I've seen at presentations. It's stocked with all the presentation data, so that's nice, and it's sort of pretty.

I have to admit, part of the goal of this was successful with me. The stuff going on with Xen and RHEL is pretty impressive, including cluster management and 'paravirtualization' (basically environments that realize they're virtualized, and can be managed easily via standard API's). Moving forward on platform design for my clients and for my own hosting stuff, I'll take RHEL into serious consideration (and not just because they said at the meeting here that RHEL5 will be Yum based, not up2date).

The drawback is that the Xen stuff doesn't really support Windows as virtual guests. For that I'll need to focus on VMware. (The other option is naturally Microsoft Virtual Whatever, which, in my experience, has been frighteningly unstable and buggy. I can't boot my Kubuntu CD into it (installation locks up), and I've had serious keyboard issues even trying to configure the installer. I'll hold off on a full rant against this until I've tried vmware, but at the moment, I'm unimpressed with Virtual PC.

Can lightning strike twice?

About 10 years ago, I started writing an application that would have a profound impact on my life. Keystone started out a simple problem tracker, grew into a mature product that was getting 3000+ downloads everytime I did an update (about once every 3 months), and was ultimately sold to a DotCom that basically killed it in its tracks. That sale let me have a few toys and was a high point of the dotcom bubble for me.

3 years ago I re-aquired the rights to the application from the failed dotcom, and set about upgrading the vastly outdated software. My user base had for the most part wandered away to other applications, but there was still interest and heck, it was my application, I wanted to do things with it.

But other projects were taking precedence, and Keystone languished.

On a recent trip down to DC, I had the opportunity to spend 7 uninterrupted hours on the train, each direction, with nothing but a laptop and a music library to keep me company. After trying to get my current projects working, I settled back into "well, maybe I'll work on Keystone some more."

In those 2 train rides, I did more upgrading, tinkering, and fixing in Keystone than I've done in the last 3 years. I revived the contact manager and fixed all the dependency problems. I continued the changes needed to bring a PHP application, written in 1995, up to 2006 standards. Keystone is over 12,000 lines of code - not a trivial application, but not so huge that it is an unassailable target.

The question is - why do this? Sure, part of it is 'this is my baby, I want to see it succeed', but in the back of my head, the question burbles... "Can lightning strike twice?" - can I make this a successful opensource application again?

I'm certainly not deluding myself into thinking "THIS WILL BE THE NEXT KILLER APP!" - that's a foolish and unrealistic mindset. But can I bring it back to where people are using it, they like it, they contribute suggestions and fixes, and the application continues to grow?

I'd like to think I can. But the code still needs a lot of work, and there are some design decisions that will most likely require huge chunks of code being ripped out at the roots (database connection methodology has advanced SIGNIFICANTLY since 1995).

It's a nice dream, I sort of miss my users. Maybe they'll come back.

Travels

What is it about New Jersey? Here I am, back again, this time for more than just visiting a client. It's been almost a week since I've been home, and it begins to wear. But enough of the that, let's see what's been going on.

First of all, there was Ubercon. This is the 8th event I've done for them, starting with our snowbound adventures in the beginning of 2003. Many of the original folks who were at that event still come to the con, both as staff and as attendees. It's settled into a close community of gamers, focusing on what they love most - Gaming. Sure there's the smattering of costuming, artists, and movies, but the vast majority of the people there are there to play games. Board games, card games, miniatures, LAN games... 24 hrs a day for 3 days, gaming gaming gaming. Ubercon was the first place I ever played Settlers of Catan and Icehouse, was my first exposure to Unreal Tournament, and was the place I first saw Guitar Hero.

All in all the event went fine. With help from blk, we worked all the hours necessary, got at least one nice dinner out, and generally had an enjoyable time. Once again the Myth box was on prominent display, and many games of DigDug, Contra and SmashTV were played. I think there's a future in making the machine easier to work with - console buttons for coin drops, player starts, and an easier selection mechanism. I would have liked to have left the machine alone and had people come up to play it more often, but alas, it was too prone to twitchy behavior and random joystick resets.

Of course, Ubercon came to an end, and I had to go on to the next reason I'm here. My work for this client is coming along fine, with development proceeding apace. Nothing really riveting to tell here, but when away from the convention and spending a lot of time on my own, I get a chance to think about being here, and to write down some of the things I see...

I present to you my NJ ponderings...

What's that you say? Pizza? Boston has plenty of pizza! What's your problem? Hah, I say. Boston has a mere shadow of proper cheesey goodness. NJ is home to the thin-crust style pizza. None of the heavy crust, grease laden horrors that populate the Beantown. Here, any pizzaria has decent thincrust pizza. I frequent my favorite spot every day for lunch, trying to get my fill. In my youth, when I lived in Trenton, a certain pizzaria saw me every day or every other day for dinner. I was quite the regular, and gained a reputation for '4 slices!' - after which I'd happily park myself in a booth and read half a book in the space of 2 hours. Such was my social life.

Oddly, when I brought up my pizza fascination with one of the fellows at my clients' office, he pointed out that Boston does indeed have a source of thincrust pizza. Papa Gino's. In the interest of full disclosure, I do in fact eat there on occasion, but sadly, it can't compete with small-shop pizza in the garden state.

Only recently did I find out this chain is more widespread than I had realized. Around 1993 I found a Fuddruckers near Edison when I was working for Unipress Software as a sysadmin. We'd make regular forays out for half pound ground beef burgers. Not sure exactly what made them so tasty, but they were sure good eatins. This trip I scheduled my drive from Ubercon down to Princeton to give me time to stop by that particularly restaurant on Route 1, and it was as tasty as I remember it. Delish.

The great DunkinDonuts epidemic hasn't quite reached New Jersey yet. This has thrown off much of my morning routine, as given any opportunity, I'll happily get a DD coffee and a bagel for breakfast (or lunch, or dinner, or a snack or...). In Boston, DDs are like mileposts. You can actually navigate by them ("Yeah, go down 3 DD's, turn right, up 4 DD's, and we're on the left.") Here? Not so much. I've found only one within a 10 mile radius of my hotel, and alas, it's on the opposite side of the office. Sad.

New Jersey is a study in contrasts in many ways. Noting that I did in fact grow up here, my view of the state has always been somewhat bucolic. I grew up on a horse farm in a very rural area. Cows, horses, etc were the normal views, and getting around on trailbikes and snowmobiles was the norm. We could wander for miles in streams and woods exploring in any direction, just avoiding houses every once in a while. The first leg of this trip was spent in Secaucus, near Giants Stadium. There are fewer places displaying a harsher contrast against the locale of my youth than Secaucus. Perhaps Elizabeth (those who are familiar with the area will know Elizabeth by it's high refinery - to - human ratio). After 4 days there, coming down to the Princeton area was a rather dramatic change. Here in Princeton, fall is in full swing. It is cool, breezy, the leaves are bright yellows and oranges, and there's just a hint of winter coming. Such a contrast to the industrial squalor of Secaucus.

My arrangements in the Princeton area are usually set up for the Chauncey Conference Center, part of the Educational Testing Service, or ETS. I'm sure not a few readers frowned at the mention of ETS, as this company is the originator of the SATs, the bane of many a high school college-student-hopeful. At the moment, I'm sitting in the Chauncey Conference Center lounge, in front of a lovely fire in a natural stone fireplace, in a large comfortable leather chair. Over the fireplace is a portrait of man in his early 60s, holding a pipe, with a loose, comfortable smile. This man is Henry Chauncey, the founder of ETS way back in the day.

Why is this of note? When my family moved from Long Island to New Jersey when I was about 6, we rented a house in Ringoes, NJ, about 8 miles from here, for a little over a year. During that time, I got to be friends with our neighbor and his family. He had a daughter named Sarah who was just my age, and another daughter. His wife I remember only fleetingly - I know she died around that time from cancer, but I don't know if it was during the time I was around. The fathers picture now is in front of me above the fireplace.

I spent a lot of time in the Chauncey household - Sarah and I had a lot of fun playing and just enjoying having a friend right next door. Mr. Chauncey (as I knew him) was always kind and had a lovely rolling voice. My memories of him were of a quiet, gentle man with a strong voice and the omnipresent smell of pipesmoke. His office was the epitomal intellectual / businessman's home office. Heavy panelling, books books books in floor to ceiling shelves, a huge desk with a fantastic leather chair behind it, and of course, his pipes.

One particular memory I have of being at his house was spending time in the fields around the house, riding on this wonderful machine he had. A late 1940's Ford 8N tractor. My first experience with these wonderful machines was sitting in his lap as he taught me to drive, and told me that keeping my foot on the clutch pedal was a bad idea "Nope, don't do that, that's called riding the clutch."

It's odd now sitting in front of his painting, enjoying some of what he helped build. I kept in touch with his daughter Sarah off and on over the years, and as I understand it, Mr. Chauncey lived late into his 90s, still active and travelling around the world with his daughter. I understand he finally passed away sometime around 1995.

Ubercon Time!

It's that time of year again. Next week I'll be heading down to Ubercon for our bi-yearly gaming geekfest.

I've been doing this event from the beginning, and have had a ball every time. Lots of great gaming (card, board, and LAN), and great folks to hang out with. If you like tabletop gaming, LAN gaming, console gaming, or just geek-gaming-hangingout, this is the place to be.

I credit Ubercon for getting me into DDR, Unreal Tournament, and Settlers. It was the first (and in reality only) place I've played Guitar Hero.

Hope to see folks there!

An old programmer...

... can learn new tricks?

As part of my current contract, my employers are embracing new procedures and techniques for application development. While the normal buzzwords of "EXTREME PROGRAMMING" and "Agile Development" are being bandied about, they're not being whole-hog embraced, with the managers marching zombie-like into an undeliverable product schedule. We're trying new techniques such as scrum product development, and utlitizing sprints to structure short-term deliverables and milestones.

Since I got the core of my production programming experience with this same company almost 18 years ago, when there were only 3 employees, me being number 3, I find it fascinating to see the same programmers trying new tacks to take on the complexity of developing modern code.

In the Good Old days, our entire code base was perhaps 80,000 lines. One developer easily understood every aspect of the application, and could comfortably keep up with customer and internal needs. The current codebase is over a million lines and growing, and no one programmer understands it all. This is not a disaster story, it is one companies' normal evolution as they grow and expand. In this case, they have lucked out to have a person in charge who is not only a brilliant programmer, but also an open-minded manager and a good communicator. He recognized the pitfalls of 20 years of development on his product line, and is making careful, planned, and deliberate changes to the company's development methodology.

Of course, the panic element for this is... the changes being applied involve shifting their platform onto a framework I designed for them over the last 18 months. No pressure, really. It's only the future of this company and it's 20-some odd employees, not to mention the respect and 20 years good will of the owner. The same owner who gave a young programmer his first production development position.

Seen on Craigslist...

From the job postings group:

Sr. Web Developer - "Open Source Guru"
For consideration please send resume in Word format.

Barcamp Boston! June 3-4, Maynard

Looks like I'll be doing registration work for Barcamp Boston at Monster.com's offices in Maynard. BarCamp is an un-conference - a sort of on the fly get together for geeks to talk about geeky stuff and hang out. Sounds like fun, and sounds like an opportunity to talk about CONGO to an appreciative audience.

This is a pretty low-key event, but if you have something you like to present, or just want to come by and help with reg and yammer about various linux-y things, cmon down!

Travelling in Style

This week I'm on the road to scenic Pittsburgh for a few days. While there are various wonderful aspects of this trip, there is also the bonus of being to test out various geeky projects that have been percolating around.

VOIP! VOIP!
The first biggie was finally exploring VOIP clients under Linux. I had tinkered with Wengophone a bit, but the Linux version of it didn't seem particularly well suited for general VOIP operations. This week I downloaded and installed Twinklephone (one of the oddest names for a FOSS application I've found to date), and set it up.

One of the big wins for twinkle is that it supports ALSA devices directly. This is a boon in particular for me because it avoids the "/dev/dsp is already in use by another application" problems that so plagued other sound applications.

Once twinkle was installed (since hunter runs Kubuntu, all I needed to do was 'apt-get install twinkle'), it was just a matter of specifying my VOIP providers hostname and account information, and voila! I was online. I can place or receive calls while listening to music, from anywhere. At the moment, I'm on a wireless connection in Pittsburgh, connected to my VOIP account, able to receive and send calls directly from the laptop. Outstanding.

"Okay, so it's another VOIP client. Whatever." - Actually, I think it's more than that. It's not just a VOIP client, it's also an integrated KDE app. When twinkle runs under KDE, it integrates directly into the other KOffice applications, most importantly KAddressBook. This means when I sync my Treo to my desktop system, all the phone numbers and addresses I keep are also available to twinkle, without having to import, export, or whatever.

ACPI Actually Works
The other big win was one of those mysteries that happens with a 'dynamically' updating OS, as most Debian-like systems are. A year or so ago I was curious whether I could suspend / hibernate my laptop just lke every other laptop in the world. Alas, this met with... abject failure. Lockups of the machine, failed reboots, etc. The ACPI tools in Linux were just not ready for prime time.

Last night I decided to try again. In KDE, I clicked on my power icon, and selected 'Hibernate'. The system quietly shut itself down, turned on the little moon LED, and that was it. I closed the lid, waited a few minutes, then opened it again. Sure enough, it powered up cleanly, restored my session, and I was bac