The Back Room

We have a Flash application that takes an input from a bar code scanner via serial keys in windows. Each time a ticket is read by the scanner, it’s translated into a keyboard input, and that is sent to the Flash application. The application can then analyze the string of characters, validate them through php with a Microsoft SQL database, and return whatever info we need. It’s a good example of integrating Flash with an external input device – the scanner. Although the scanner we’re using requires a few pieces of software to send keyboard command (because of the way it works with the touchscreen), most just emulate a keyboard input when an item is scanned.

Because what we’re making has to work hundreds of times a day, every day, we needed a way to do some solid stress testing. It wasn’t practical to have one of us sit in front of a computer with a ticket and scan it every 5 seconds to make sure that our application and the hardware were functioning properly. So, Charles came up with the idea to trigger a small servo motor to scan a ticket every XX number of seconds. In about two hours, he had the device you see below. It is pretty utilitarian, but  the main function is to just make sure the ticket scans properly, so it doesn’t have to be too sexy. The program is actually a modified version of the servo motor example that ships with the Make Controller that we have used in a few exhibits. The controller is pretty handy for connecting Flash to all sorts of external devices.

We’re not showing the actual program we’re testing, but instead you can see the input from the scanner appear on notepad. It helped us assure that our software could take the continuous input of thousands of scans a day and still be functioning well.

A panel of lights being controlled via ethernet

In relation to the line of work we are in, our Flash applications don’t normally fit into the mainstream web application paradigm.  Often we interface with special hardware, touch screens, and systems with more than one monitor in non-standard orientations.  We also have to ensure that our applications can run non-stop for a minimum of a full day and potentially seven days a week.

One of the Many Test Setups

In order to try and simulate the final production environment, when developing software; Bruce and I like to test applications on the hardware it will be run on in situ for several days at a time.  On one corner of the desk that I work at, we have a big three touch screen configuration that we often hook machines into for testing.

Monitoring the Hardware Using a Webcam

Recently while testing large touch screen monitors, the company pool table was occupied for several days with 40-inch vertical monitors and their associated computers.

For situations requiring interaction with hardware such as a telegraph, we will often isolate the piece of hardware in our studio and run it for days while controlling it via the local network.  A cool way of monitoring the hardware being tested in the studio from our office in the backroom is to use a webcam and Red5.  In the images I am using Red5s sample broadcast and subscriber applications.