Yesterday was, for all intents and purposes, a snow day. They closed the school down at 1. Of course, I had no classes anyway, just some work that could be done anywhere. But this was a snow day. You don’t do work. At least, not the work you’re supposed to.

Kyle, always being curious about the hardware side of things, sent me a link to the RoomWizard downloads page after fishing out the hardware specs elsewhere. There were two things that interested me–one was that you could download a firmware image. The other was that they had a PDF of how to use their API.

Wait… API? That means… it’d be trivial to write an interface to these things!

The problem is that the manual never mentions the actual address of the API, which is just accessed over HTTP and returns XML. They give a few examples–/rwconnector is used most often. But alas, /rwconnector on these throws a 404.

Somewhat discouraged, I started poking around the firmware image. It’s a .tar.gz, and extracts… a (fairly) normal Linux filesystem. Besides some juicy stuff that I hope admins are instructed to change (there are several privileged user accounts), I also found some neat stuff. For one, it’s based on SuSE, but a very trimmed-down version. And it’s basically a full-functioning Linux machine, including an SMTP server, Apache Tomcat, etc.

But then I hit gold. There’s a configuration file for Tomcat, which mentions one URL of /Connector. So I fired it up and tried it in on one of the systems. Bingo!

So then I read a bit more of the API manual. It’s actually very simple–you can retrieve, edit, and delete bookings. (The edit and booking doesn’t let you do anything you can’t do via the web interface, by the way, lest anyone think this is a security flaw.) You get an XML document back with results.

So then I had to figure out how to get PHP to parse XML. It turns out that PHP actually has several ways to do it, including SimpleXML and DOM objects. I spent a while learning it and by the end of the day, I had a prototype working that would get reservations for the next 24 hours and parse out the information. (Small tip–don’t try to “escape” colons when dealing with XML. They denote a namespace. When you get rb:name, for example, the tag name is just name, in the rb namespace. Knowing this a little sooner would have saved me about half an hour of, “This code is so simple! Why doesn’t it work?!”)

The next step is to insert all of this into an SQL database, and then write a nice viewer for it. And also to experiment with adding bookings, although that should just require changing a line of code.

I haven’t actually written code to do timing, but it feels like it’s 1-2 seconds for me to get the XML data back, which suggests that the bottleneck is in its little database. Short-term, I want to write myself a little interface that will parse all the data, cache it, and give me a faster interface. Long-term, I want to try to see if I can get the library to adopt this, and have it be the booking mechanism. You can store them to a local database, and then have a background process use the API to push reservations out to the respective RoomWizards, so that they continue to function normally. But when people view the page, it’ll just get it all from the local database, meaning that the whole “Get the listings via API” thing is no longer necessary. (Unless you want to rebuild the database in case of a disk failure!)

Criticizing Web Apps

As long as I’ve posted a lengthy diatribe about how awful the library room-booking web interface is, there are two more that drive me nuts.

We have a way of putting in work orders for maintenance. Last semester I tried to open one of our windows and it just fell out. This semester, we had three different light fixtures burn out in 2 days time. So you go online and put in a work order. This is a great thing to have web-based. Except they picked this insane system that opens multiple browser windows, resizes your browser (?!), uses copious JavaScript requiring you to double-click on links… And it only works in IE. Oh, and there are irritating things that could be fixed with one line of code… You log in with your student ID, which is eight-digits that inexplicably have an @ sign in front of them. So they have this big note on how you cannot use the at sign, you must only use your eight-digit number. One line of code could just strip it out if it was included.

Much like booking library rooms, submitting help tickets is a Programming 101 exercise. In fact, it’s easier than the library interface, because you don’t have to do time calculations. You have an employees table, a clients table, and a work table. Tasks get entered into work by the client, and the staff assigns an employee to it. And when it’s done, you set work.status to “Complete,” a simple ENUM field. This is like 45 minutes of coding, although I’d probably spend more time prettying up the interface.

Then there’s the computer help desk, another web app. For one thing, all the links to it point to an http:// URL. But if you actually use them, it barfs up an error that you must view it over a secure channel. Being a web dork, I just take “s” onto the end of “http” and life is golden. To someone who’s not so good with computers, and who’s already at wits’ end with their computer, they’re probably going to break down and cry, because even the help desk webpage doesn’t work for them.

This, too, only works in IE. In this case, they didn’t have copious bizarre crap (like requiring double-clicking on links), so I set Firefox to pretend it was IE. The page loads okay, but looks terrible, with nothing lining up right. IE and, well, the rest of the world, have differing views on how lots of things are done, but requiring IE really isn’t the best solution. Oh, and as an added bonus, they control your mouse cursor, preventing it from indicating links in any manner. This means that someone took time to write code that does nothing but decrease usability.

But worst of all, even if you use IE like they demand, if you actually try to click on any tickets to view them, you get taken to a random system with a long canonical hostname, which just throws you “HTTP 400 – Bad Request.”

So last night, I submitted a help desk ticket indicating that the help desk is broken. Because, frankly, it doesn’t work. All of its internal links take you to the wrong server (or, seemingly, the right server but with the wrong hostname), and that’s assuming you’re smart enough to get in, by understanding the error indicating that you need to use HTTPS, not HTTP.

Most of these things are sold as turnkey devices, it seems. Maybe I should start a company making them. Apparently, no technical expertise is required to do so.


Even though I got to a business school and am a management major, my real passion is working on websites.

We just build a new library here, for millions and millions of dollars. We use a tool called RoomWizard for booking rooms. We get a web-based interface to book library rooms. This is a great idea. Unfortunately, it’s so fraught with bugs that it borders on unusable.

The main “bug” is that it’s basically so slow that it’s unusable. I tried viewing the source, and it’s got a HUGE block of JavaScript that’s a pain to read. Most of the page is being generated on the fly with JavaScript. There are times when this is the best way to do something. This is not one of them.

My current understanding–I may be wrong, since I’m still trying to make sense of this–is that each of the touch-screen units on the wall is a webserver. It’s responsible for storing all of its reservations. So when you view the main page, JavaScript has you going out to each of the 20+ rooms and requesting their status. The problem is that this takes forever, probably at least 15 seconds. By the time the page has finished drawing, it’s about time for the 60-second refresh to kick in.

I did a bit of viewing headers. The main page is running on, but each individual room controller (probably like a 300 MHz embedded chip?) is running Apache Tomcat. Someone did a quick port scan and found that the devices have a lot of open ports–ftp, ssh, telnet (!), HTTP, and port 6000, which nmap guessed was X11. So I have a pretty good feeling these things are running embedded Linux.

Another problem is that there’s always one or two of the devices that, for whatever reason, are unreachable. So you get errors on those ones.

Booking conference rooms is like a Web Programming 101 interface. You get a basic introduction to SQL databases, and write a little interface. You could run this on an old 1 GHz PC with 128 MB of RAM and have pages load in fractions of a second, especially if you really knew how to configure a webserver. (Turn on APC and MySQL query caching, in this case, and you’re golden.) I cannot fathom why they thought it was a good idea to have a page make connections to 25 different little wall-mounted touchscreens. This places a big load on what have got to be underpowered little units, and is just a nightmare any way you look at it. I really see no benefit to what they’re doing.

Furthermore, this breaks off-campus connections, since you can’t connect to these units remotely.

You convert the wall-mounted RoomWizards from embedded webservers into a little web browser client, and they just pull down the data from the main server.

With a traditional, single database, it would also be easy to write a little search tool–“I need a room on Friday from 3:00 to 5:00.” This is a fairly simple SQL query. This is not a fairly simple question to ask 25 wall-mounted touchscreen things.

I’m tempted to write a little PHP script to go out, retrieve the data, and cache it. Essentially a hacked-together proxy…

Arresting Firefighters

This is wild. The fire truck pulls up to a car crash on the highway, and parks the truck to “shield” the emergency workers as they extract a victim from the car. The cop yells at the firefighter driving the fire truck to move so as to not obstruct traffic. The captain, who was actively working on the patient, yells for the fire truck to stay put, pointing out that they very deliberately parked that way for the safety of anyone involved. So the cop pulls the guy away from the patient and arrests him.

Of course, not all firefighters arrested are innocent.

Cold War

Anyone who’s learned about the Cold War will be familiar with the chilling fact (no pun intended…) that we came very close to a nuclear war.

But after reading things like this article, mixed with other anecdotes, I’m left wondering how on Earth we didn’t go to war… Accidentally. Both the U.S. and the Soviets, on multiple occasions, “detected” launches of nuclear weapons by the other, and came within seconds of retaliation before someone noticed something out of the ordinary.

Fortunately, the U.S. was very thorough the first time around, and quickly proved that the first “attack” they witnessed was caused by some guy inserting the wrong tape… In the case of the Soviets, the only reason they didn’t launch a counter-attack after their own false alert, it seems, was because the guy who was supposed to press the button disobeyed orders and went with his gut. (And boy are we glad!)

And there’s a further set of coincidences, really. After a flood of nonsensical data, officials discovered some problems. Apparently, one detection system was alternating between reporting some 2,000 incoming missiles and 0 incoming missiles. Because of the conflicting data, they turned to alternate systems, which also reported 0 incoming missiles, and it was traced to a hardware malfunction, with the 2,000 number just happening to match, by sheer luck (or lack thereof), internal checksums.

So they wrote some code to compare results from multiple systems. And not more than a few months later, the problem with the training tape occurred, when one of the systems began reporting more believable numbers of incoming missiles. (Apparently, a steadily increasing number.) The data “made sense,” but, because of the newly-implemented code to compare with other systems, they realized that it was just one system, and quickly isolated it to a case of someone sending “training data” as if it were live data. It’s almost a case of two wrongs making a right–had the first error not occurred, the safeguards wouldn’t have been implemented to catch the second error.

Oh, and there exists a slightly-creepy website dedicated to the Russian who decided to trust his gut over the myriad indications that we were attacking


I’m a long-term radio geek, and I’ve realized that the technology interests me more than actually using it. Having worked with lots and lots of radios (I realized that I have three sitting on my desk, all of which I have used in the past 30 minutes), I’ve concluded that I’d like to start a radio company. Our motto would be, “Our radios don’t suck.”

One of my radios is a ham radio, which is front-panel programmable (FPP), meaning that you can punch in frequencies on the keypad. This is pretty common with ham radios. By contrast, land-mobile radios (things that, say, a police officer would carry) very rarely have FPP capability; in fact, the FCC frowns on certifying radios with that capability, except for certain federal agencies that need to be able to reprogram their radios in the field. However, it’s often offered as a software add-on. But even using the ham radio, it’s really hard to use. Part of the problem is that the radio’s probably a decade old, and the print on the keypad has worn off. So I’m guessing at what buttons do.

There are very few radios with a graphic LCD. Dot-matrix LCDs almost seem cutting-edge in the radio world. By contrast, try to find a cell phone that doesn’t have a big color LCD on it. I have an old Garmin GPS III, and still admire that screen. I think it’s four shades of gray, and fairly high resolution. It’s a nice graphic LCD. It’s so much easier to use, and introduces stuff like the ability to “arrow” around a screen, as opposed to trying to use obscure key combinations. I’d actually love to see something like a 2″ by 2″ e-ink display (which, in addition to looking amazing, would reduce power usage), but it’d be a pain since it’s slow to redraw.

Motorola’s MDC1200 technology is practically ubiquitious in the public safety industry, transmitting a 1200 bps data burst containing a four-digit identifier. This could be so easily improved. Put a little $20 GPS chip in it, and have it transmit GPS coordinates on each transmission. (You could also include stuff like battery level, if on a portable, and information on received signal strength. The latter would be useful to run in the background and plot a map of the radio system’s reach.)

Programming is always a pain. Some of Motorola’s radios are programmed in ways that are so obscure that they border on comical. (I think the goal there is security.) I want to write an XML file for my radio. Put a USB port on the side of the radio. Let me hook it up to a computer, or just plug a thumb drive in and reprogram from that. But consider bigger problems, though. Boston PD switched to an “improved” channel lineup last year. Apparently they worked for weeks to pull radios in at the end of a shift, load up the new set of data, but leave the radios set to old configuration, until all the radios had the new programming in them. And then, at a quiet time one day, they broadcast a message telling officers how to switch to the new configuration. Over-the-air programming is possible, but it’s generally used in some specific situations. (OTACS, Motorola’s Over The Air Channel Steering, to direct a radio to switch to a particular channel, and OTAR, Over the Air Rekeying, to send new encryption keys to the radios.) Why not let the system send out bursts of programming data when the radio system is idle, loading up new programming data in the background, until they’re ready? Obviously, all of these programming things need some security constraints, but that’s trivial to implement.

I’m pretty confident that software-defined radio is going to become ubiquitous in the next decade, but no one’s really making use of it yet, except for uber-geeks in labs. APCO’s Project 25 digital voice (IMBE) has emerged as a standard in digital voice, but it’s meant to be made obsolete in the future by a “Phase II” implementation. Various other technologies have come and gone, such as Motorola’s VSELP. And there exist myriad trunking protocols for larger networks. I want to embrace SDR and use it in everything, “future-proofing” radios. (Of course companies have an incentive to not future-proof their hardware, forcing people to upgrade… But you can still make your money on selling software upgrades!)

Oh, and put an SD slot on the darn thing. Record the audio it receives, letting people play back transmissions they miss. Or host applications. (Or, permit programming!)


GRE, a (radio) scanner company that makes a lot of the scanners Radio Shack sells, also sells some under their own name.

This new one advertises an “Intuitive ‘Object Oriented’ User Interface Design,” which brings all the fun of OOP to a GUI. The picture of the radio reads “Press NEW to create objects,” and has three softkeys, labeled “NEW,” “EDIT,” and “GLOB.”

I’ll reserve final judgment until I play around with one, but, on the surface, this seems anything but intuitive.

World News

Several things of note have happened in the past 24 hours:

  • In Pakistan, the PPP and the PML-N, the former being Benazir Bhutto’s party and the latter being on with apparent similarities, won by a landslide in elections, which were a remarkably peaceful event. There is already talk (albeit just rumors) about the possibility of the impeachment of dictator Musharraf. It’s far too early to know the full effects, but some are suggesting that this is a very good sign for democracy.
  • Fidel Castro has stepped down. The article is quick to note that this doesn’t mean that democracy is around the corner–a new leader will be appointed by Cuban parliament, only because Castro said he didn’t want to be named as the next leader. Possible replacements are reported to be Castro’s brother, with some discussing the possibility of a surprise appointment of a “generational gap” leader, Castro’s current VP (who is 56).
  • Kosovo has declared its independence from Serbia.