I found a large, mysterious box at my front door and there was an airplane in it ;-). It’s a Mountain Models Magpie, with both the slow flyer (SF) and sport wings. I unpacked everything and took some pictures.

I have actually been gearing up for this for a couple of weeks. I already have the radio (a Spektrum DX6), the motor and speed controller. The only bits still on the way are the battery and charger and they should be here by the weekend. Hopefully I’ll have the airplane built by the weekend.

The Magpie is a park flyer/trainer with a 46″ wing span (40″ for the sport wing) made from EPS and Depron. EPS is Styrofoam, like the cheap coolers you get at 7-11. Depron is a more finely textured foam, like that used in sign board or meat packing trays.

The manual (see a pdf copy here) recommends 5 Minute epoxy for bonding the foam parts together. I wasn’t too keen on using epoxy. I have used it in the past and it can be tricky. You have to mix it exactly 50/50 and with a 5 minute set time you have to work fast. It makes a very strong bond. Its also relatively heavy and weight doesn’t fly.

I looked for some alternatives and came up with Polyurethane glue in the form of Elmers Pro Bond / Ultimate. This stuff activates with water and can be cleaned up with soap and water before it sets (neat hu?). It foams and forms bubbles as it cures and tends to push the pieces you are gluing apart, not a good thing. As I had never used this kind of glue before I did 3 test pieces to see how it works. I did the first with too much glue and held it together with rubber bands. The second I used less glue and just pressed the foam blocks together. The third I used blue painters tape to hold the blocks and used even less glue.

The best results were with minimal glue and tape. The rubber bands bit into the EPS and twisted the blocks. The press fit blocks were pushed apart by the expanding foam. So use tape and use as little glue as possible. This stuff seems to set up stiff in about an hour and you probably have 15 mins of working time to set and tape the parts. The directions say to wait 24 hours for it to fully cure.

Enough about glue, on to construction.

The manual recommends cluing the wing halves together first. Doing the fuselage looked easier so I did that first. I used the painters tape to stick the cuttings from the taper on the rear fuselage back together. This make a sandwich and make everything uniform so when the two halves of the fuselage were glued and taped together they were as straight as possible.

I didn’t have a 44″ flat surface in my apartment to set up the wings on so I put my white board on the floor and covered the middle of it with Parchment Paper. Parchment paper is superior to wax paper in every way. Mosses himself couldn’t get from one side to the other. CA glue will actually bead up on it and refuse to set.

I did the slow fly wing first. Its a bit tricky to get the halves to meet up perfectly. I joined the bottom of the wing with lots of painters tape and then applied the glue to the joint. Then I flipped the wing upside down and placed it on a large tissue box so that the wing tips weren’t touching the ground. In that orientation gravity applies gently pressure to the bond to keep the parts together. The roll of tape and sanding block ad a little weight to the equation.

I’m going to let the parts cure overnight. Tomorrow, strapping tape…

Porco Rosso tickles me in a way that I enjoy entirely too much. Hayao Miyazaki is a genius, the modern equivalent of Walt Disney. If you have never seen his work I recommend Princess Mononoke as an introduction. Watch it and you will understand why cartoons are good for more than comedy.

Anyway, Proco Rosso I hadn’t seen until tonight. Its a movie about a fighter pilot in the post WWII era Mediterranean, who’s a Pig. He totally captured the way I felt about airplanes when I was a little boy. If you like that sort of thing you should dig up a copy and watch it.

On another note this reminded me of the Schneider Cup and the X-Prize and how the two are in no way similar. The Schneider Cup was an annual event and the X-Prize was a one time thing. The Cup was a race and people love to watch races. A race has the atmosphere of grease and engines and things that work well but not quite well enough. And with an annual event there is always next year to make a comeback. The new space race would be so much cooler if it was for maximum altitude or time above 100,000 feet.

Anyway, airplanes are cool. Old ones are double cool.

Indrio development took a back seat to some other more important real world stuff for a while. I’ll get into that at a later time but right now I’m gonna focus on Indrio.

Some parts of the iTunes API are shamefully slow. The Enumerator for ITrackCollection operates in n ² time. So the time it takes to walk the list grows quadratically with the length of the list. Iterating over the list with python and calling Item is actually faster that the enumerator. That was a bit of a shock. Item() is definitely n ², access at the end of the list is much slower than at the start of the list.

Even if Apple were to fix this we are talking about 5 seconds here which would give a max speedup of 2.2 seconds. Thats still too slow for search as you type. Besides, have you ever seen what happens when you drop a 5k rows worth of table into a web page? It won’t render correctly on anything.

The real solution is to page the results. This way access to the results is fast even in the worst case scenario at the end of a large list. This is what you would do in a real GUI application anyway. Never show the user more information that then can digest and Never do processing for anything you didn’t show the user.

The search for answers to Inrdio’s speed problems lead me down a path of optimizations that tightly coupled the iTunes stuff to the web server. Some of the optimizations were good but I’m not going to pay for them with bad architecture. So I took a step back and completely abstracted everything behind three classes: AudioPlayerInterface, TrackList, & Track.

The AudioPlayerInterface supports searching, queuing, and provides information about what songs will play/are playing. The TrackList supports the paged access to tracks, either from search results or from the playlist. Tracks are, of course, tracks with information like Artist, Title and so on.

In the iTunes implementation of TrackList is extremely fast. You construct a TrackList without having to iterate through the tracks. Then the web application module can get a page of tracks and compose them with the templating engine.

Access to Track data is done as its requested. The absolute minimum number of COM calls are made to render each template. The Track interface uses the wrapper pattern so its thin and fast. This way the tracks can support a large set of properties without having to copy each one into a temporary variable. The extra fields can be used by other templates, like the one that will render what playing now.

Expect a release (with code) as soon as I get the obvious bugs out.

DOM is a swell gal, she treats me all right, just so long as I take her out to her favourite restaurant; Firefox. When I get cheap and go for fast food at Internet Explorer, she’s not happy.

innerHTML is a read only property in IE for the table and tbody elements. Trying to set it causes a very nondescript error with a code of 0. Firefox isn’t totally off the hook either. With large sets of rows there are rendering errors at the bottom of the table if you don’t define a background color. I’m using prototype.js to insert the rows returned from an AJAX call. I kluged a fix for IE by inserting the entire table every time.

Performance building that table was very bad for large result sets (1k+ rows). Python had a built in profiler & CherryPy has profiler support. I totally love this, this rocks 1000% more than Java. Reading and building the data set from iTunes was about 1/10th the total execution time so something else was not very fast. Turns out it was a module for the template engine that only worked with 2.4. I upgraded everything to 2.4 and performance got drastically better.

Now the major bottleneck is with fetching values from iTunes via COM. Thats about 80% of the time is spent in __getattr__ and _ApplyTypes_. Thats the COM stuff translating returned values into Python types and the majority of that time is probably spent in iTunes. The stop gap to give reasonable performance is to limit the number of rendered results.  I picked a ‘magic’ number, 300, which renders in under 2 seconds on my system. This will suck if your trying to search for music by genre and there are 1K+ results for ‘Trance’ in your library. Some sort of paging solution may have to be used to get through a result set like that. I don’t really see that as a major usage pattern in my experience. People generally ask for music by title or artist and this turns out to be very specific and returns a limited number of results.