I now have code running on planes somewhere in the world at 30,000 feet in the sky. Please don't be alarmed, I can't crash your plane ;)
Although, I should put some easter eggs in that the php community can enjoy when they fly. When I first started here at Panasonic I was overwhelmed with the amount of resources that actually go into an in-flight entertainment system. Video/Audio departments, how studios actually charge for the ability to show their movies. The Q/A Process alone is pretty interesting. You never quite think about what your web server should do when it senses turbulence(almost everything is written to RAM to prevent data loss in case of turbulent disk writes).

The downside to the system is the unbelievably slow hardware I have to deal with(233mhz, no video drivers). The main interface with the customer is via a touch screen LCD monitor. I work on the crew side, so my applications are developed so the crew can control the system. They can assign video/audio, make announcements, they can see when you press that little button to bug them. I was able to make sure we used Firefox as our Kiosk web browser. I had some experience with the platform and knew the power that Firefox could bring to the table.

One of the first challenges I tackled while I was here was to address the need for a fully event driven system. For example, if I'm playing video on one kiosk machine the other crew machine should exactly match that UI step by step. We had thought about polling however it just seemed like such a cop out, hacky solution, being I controlled the WHOLE environment. I like to think about my traffic as a human conversation. Imagine someone asking you for today's date every second. "hey Jim what's the date?" "hey Jim what's the date?" ugh leave me alone I can't hear you over all this video traffic!!! When the date changes I'll tell you! Now that is why I chose to look into the server push option. Let's let the server tell us when data changes.

Ok, so how do we do that? well in firefox there is the multi-part option of an XMLHTTP request. It will keep a connection alive much like an open iframe and allow a server script to continually loop, pushing out new data. What I didn't like about that when we tested was the scalability of the system. Remember, I have SLOOOOOOOOW boxes and a ton of network traffic with audio and video being streamed to 400+ seats. It still didn't meet my conversation requirement completely. It would be like someone coming into your room and saying "Ok, do you have data? No? Well I'm going to sit in your room, stare at you and wait until you do". We'll that's annoying too. How about when I have data I will give you a call and give you what I have? I can move on with my life and not worry about you being annoying.

That lead to the birth of a basic web server as a firefox extension. It listens on a certain port and takes and acts on live events in the system over TCP(UDP support probably in the future). When the plane takes off that's a "weight off wheels" event. That event then fires into my browser, through my framework, to client code that's observing that event. You could be looking at the screen and the whole UI just seems to be moving on it's own. Quite interesting.

On the backend of the system all the communications are done via XML and JSON using PHP. I wouldn't have even stayed this long if I couldn't use php5's simpleXML functions. I've done alot of xml work in php4 and it makes me want to cry. XML parsing in php5 is to php4 what the beatles are to vanilla ice. Unit testing has also saved my ass many a time here. I'm in charge of writing the framework on which many applications can be built on and tap into the system easily. If I break something, that cascades to dozens of airline programs. I can't have that. SimpleTest has been a mainstay of my development since Day 1. I try and practice test driven development as much as possible. I truly believe it lends itself to cleaner, more maintainable, more scalable code. On the JavaScript side I've been using JSUnit to unit test all of the javascript code in the framework. Don't be the guy that breaks the build!

Some of the interesting performance issues we've had to address have been with javascript and images. The system is a total desktop like ajax web application. The MyBic( http://www.litfuel.net/mybic ) PHP/AJAX framework has performed flawlessly for our kiosk apps. There is only one page reload and that app could be running for weeks at a time. I've had to build in a custom garbage collector in javascript that will run through all the modules and figure out their last usage time, etc and clean up the objects they've created. This is to avoid bloating the memory allocation. Another performance boost was pre-loading all of the javascript on the initial page load that the system would need. Instead of running the js through the js engine on each page request, it's all preloaded into memory which dramatically speeds up responsiveness in the system. The pre-loading of the JS scripts is controlled by the framework which can determine what kind of machine it's on to either do the preload on slow systems or dynamic loads on faster systems. Images were a major problem as well. The original design (which was gorgeous from a 3rd party) had alot of fancy images and backgrounds. When tested on the 233mhz system it resulted in page load times of 2-5 minutes PER PAGE. Kind of unacceptable, yea. The solution was to take advantage of Firefox's border radius css abilities and create a completely css/html based UI. Using simple borders, backgrounds and text colors we were able to get a pretty decent UI that performed in under a second. We'll add in support for faster machines later.

I was going to talk about the handheld solution using Minimo however this is running too damn long. Maybe another day. That's basically a small summary of my past year. I've left about about a million things I wanted to discuss but I'll save those for future articles.

Ready for More?

Follow Me @jimplush