Effective immediately, I’m extending an invitation to all Quiznos franchisees to contact me for employment as a Quiznos Cup Dancer. But here are my demands:

• I must wear the Quiznos cup (illustrated here).
• I must wear it for a single hour, after which I may and will terminate my employment.
• I must pay you, Quiznos, the hourly wage you would normally pay a Quiznos Cup Dancer.
• I must promise to commit my full efforts to provide the best Quiznos Cup Dance you have ever personally witnessed.

Contact me. I’m waiting. Little Caesars franchisees need not apply.

First, the sample application for queuing and caching. Keep in mind that images loaded into the application will be cached in the browser, so depending on what you’re wanting to test you may need to clear your browser cache between tests. Right-click the application to access the source.

Second, the presentation slides. Here they are as a “slidecast” but they’re a little different than the live ones. I think the live video will be made available shortly so if you’re looking for that check back later. Also, this slidecast was made through SlideShare and their audio-syncing tool is a little limiting so the audio might get unsynced for a moment. In any case, enjoy!

This year, yours truly will be presenting the topic Queue N Cache. With a name like that, I’m sure flexers worldwide will be scrambling for a seat. I know I know, you’re thinking, “Queuing and caching? That oughtta be a party.” No. It’s Queue *N* Cache and that’s one party that runs year-round. Oh sure, we’ll talk a little about the ho-hum of your grandma’s queues and caches, but this is where rubber meets the road with real-world projects and situations where queuing and caching can achieve greatness. Have you ever sat back and wondered:

• How could I improve user experience by paying more attention to the user’s focus?
• How could I have greater control over my service calls and asset loaders? Timeouts and retries? Call me crazy.
• How could I decrease memory usage and processing load by sharing image data?
• How could I increase responsiveness through improved data management?
• How could I show progress of shared image data in multiple locations?

If you can’t make it (Tuesday @ 2:30) or just can’t get enough, I’ll post my slides and code after the preso and you can dig in to your heart’s content. See you there!

Take the following XML:

<catalog xmlns:ah="http://aaronhardy.com/music">
	<cd>
		<title>Empire Burlesque</title>
		<artist ah:verified="false">Bob Dylan</artist>
		<country>USA</country>
		<company>Columbia</company>
		<price>10.90</price>
		<year>1985</year>
	</cd>
	<cd>
		<title>Hide your heart</title>
		<artist>Bonnie Tyler</artist>
		<country>UK</country>
		<company>CBS Records</company>
		<price>9.90</price>
		<year>1988</year>
	</cd>
	<cd>
		<title ah:verified="true">Greatest Hits</title>
		<artist>Dolly Parton</artist>
		<country>USA</country>
		<company>RCA</company>
		<price>9.90</price>
		<year>1982</year>
	</cd>
	<cd ah:verified="false">
		<title ah:verified="true">Still got the blues</title>
		<artist>Gary Moore</artist>
		<country>UK</country>
		<company>Virgin records</company>
		<price>10.20</price>
		<year>1990</year>
	</cd>
	<cd>
		<title>Eros</title>
		<artist>Eros Ramazzotti</artist>
		<country ah:verified="false">EU</country>
		<company>BMG</company>
		<price>9.90</price>
		<year>1997</year>
	</cd>
</catalog>

In this case I’m trying to find all nodes that have a “verified” attribute. Again, I don’t care if the attribute’s value is true or false. If the attribute weren’t in the “ah” namespace I would use this line of code:

var nodes:XMLList = myXML..*.(hasOwnProperty('@verified'));

However, when the attribute is in a namespace, it’s my understanding that hasOwnProperty() is no longer effective. At least those are my finding based on trial-and-error and online research. Instead, you can try this workaround:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="cc()">
	<mx:Script>
		<![CDATA[
			protected function cc():void
			{
				var myXML:XML = 
					<catalog xmlns:ah="http://aaronhardy.com/music">
						<cd>
							<title>Empire Burlesque</title>
							<artist ah:verified="false">Bob Dylan</artist>
							<country>USA</country>
							<company>Columbia</company>
							<price>10.90</price>
							<year>1985</year>
						</cd>
						<cd>
							<title>Hide your heart</title>
							<artist>Bonnie Tyler</artist>
							<country>UK</country>
							<company>CBS Records</company>
							<price>9.90</price>
							<year>1988</year>
						</cd>
						<cd>
							<title ah:verified="true">Greatest Hits</title>
							<artist>Dolly Parton</artist>
							<country>USA</country>
							<company>RCA</company>
							<price>9.90</price>
							<year>1982</year>
						</cd>
						<cd ah:verified="false">
							<title ah:verified="true">Still got the blues</title>
							<artist>Gary Moore</artist>
							<country>UK</country>
							<company>Virgin records</company>
							<price>10.20</price>
							<year>1990</year>
						</cd>
						<cd>
							<title>Eros</title>
							<artist>Eros Ramazzotti</artist>
							<country ah:verified="false">EU</country>
							<company>BMG</company>
							<price>9.90</price>
							<year>1997</year>
						</cd>
					</catalog>;
 
				var ns_ah:Namespace = new Namespace('http://aaronhardy.com/music');
				var verified:QName = new QName(ns_ah, 'verified');
				var nodes:XMLList = myXML..*.(attribute(verified).length() > 0);
				trace(nodes.toXMLString());
			}
		]]>
	</mx:Script>
</mx:Application>

Hope that helps someone!

Except me. Wikipedia defines insurance as “a form of risk management primarily used to hedge against the risk of a contingent loss. Insurance is defined as the equitable transfer of the risk of a loss, from one entity to another, in exchange for a premium, and can be thought of as a guaranteed and known small loss to prevent a large, possibly devastating loss.”

In other words, insurance is basically a big group of people that are willing to pay a little now to prevent the possibility of paying a large amount later due to some unfortunate, unforeseen occurrence. Insurance can exist because only a relatively small portion of insured are going to become critically injured or sick. From another perspective, this means that a majority of the insured are putting in more than they are taking out. But they keep putting money in because they know they may someday be one of the lucky losers. Not all the insured will or can be lucky losers; not enough money would exist to pay for the expenses. Insurance would cease to exist.

Some people, politicians or otherwise, feel it’s a discriminatory act to deny someone coverage because of a pre-existing condition. After all, someone with a disease has even greater need for insurance than someone who does not. While I agree, I do not agree they reserve the right to be granted insurance after having being diagnosed. Insurance is not a charity nor is it welfare. It is a hedge against risk and those who have been hedging for years should not be required to pay for someone who has failed to do so.

Let’s imagine this hypothetical scenario. One day the government drafts a program to help subsidize cars and has decided to fund it with approximately $3 billion. I know, I know, it’s a crazy stupid idea but stick with me. To make it sound a little more legitimate and family friendly we’ll call it something like Cash for Junkers. Since there are approximately 300 million citizens, the government has decided to pay for the program by randomly selecting one out of everyone 1,000 people to pay $10,000.

“Wow,” you say, “What if I’m the the lucky loser? I can’t afford a sudden $10,000 fee!” So you get together with some of your friends, family, and neighbors and find 999 other people that would like to spread out the risk. You figure that odds are one of you is going to be a lucky loser, so you each agree to put in $10. The lottery day comes and sure enough, one of your peeps is chosen to be a lucky loser. Lucky him–he’s only out $10! Soon after the lottery some of your other neighbors that decided not to put $10 into the pot come knocking on your door and say, “Hey, you know that ’spread the risk’ thing you were talking about doing? Can we join now?”

Hellz no! Does that seem “fair” to you? Does it seem “fair” to the other 999 that decided to hedge their risk? Regardless of your reason to not throw a Hamilton into the pot, you didn’t. And you’re not going to make other people pay because of it.

This is insurance. Why can people complain to no end about insurance companies not allowing pre-existing conditions? Because they can blame insurance companies, the facade, not the people who are already paying their dues. Can you find a big group of people that want to allow pre-existing conditions into their pot and pay more because of it? Then you start an insurance company.

Before you determine I’m a purely heartless soul, let me give you some background. My own family has sought a health insurance plan when going from a government-sponsored health plan (my wife was a teacher) to an individual plan (I was working for a start-up that didn’t have group insurance). And I was planning on knocking my wife up soon (which, by the way, qualifies as a pre-existing condition if I were to have knocked her up within one year of signing onto the new plan). For several years we were also only on the giving end of insurance–dumping money into the pot and hardly ever taking any out. On the other hand, over the last three months we’ve been the lucky losers and have taken out several times more from the pot than we’ve ever put in.

More than anything, I’m as frustrated as you are that changing jobs means changing health insurance plans and dealing with pre-existing conditions. But let’s not fight the wrong battle. Pre-existing conditions are not the problem, third-party pay systems are. Why can’t you stay in the same insurance pot when you change employers? Why do employers have anything to do with it anyway? If I never have a lapse in my health insurance plan, then I don’t have to worry about pre-existing conditions in the first place. Stay focused on the real problems, not the latest political cusswords.

Easy enough. How about multiple loaders? Lets say you have a group of 10 images and you’d like to show progress for all the images collectively. Because you have 10 different images you also have 10 different URLLoader instances (or Loader instances, whatever suits your fancy)–one for each image. Math would say that you divide the sum of bytesLoaded by the sum of bytesTotal and that gives you the percentage complete. Two issues arise:

(1) The progress indicator really shouldn’t be involved with handling all these loaders and tallying their numbers. Its purpose is to display the percentage loaded and it should stick to what it does best.

(2) One important thing to know about ActionScript classes that expose progress information is that the bytesTotal property is not populated until the server responds to the request (until the HTTP headers are received). This makes things a little more complex. Let’s say the first loader begins loading an image and it gets a few bytes loaded in. At this point we for sure know how many total bytes the loader eventually will have loaded, but the other loaders may still be waiting for a response from the server and therefore their bytesTotal properties are still hanging out at 0. What’s your denominator to determine overall percentage? One option is to know the total number of bytes for each image before the loading process begins. This information would need to be available beforehand through some sort of service call. The more simple and usually sufficient approach is to take the number of completed loaders divided by the total number of loaders to determine the percentage loaded. It’s not as granular as dealing with bytes, but it can be a good alternative for showing overall progress.

Below is a class I use to simplify this process and consolidate different objects that provide progress information. Instances of information-providing classes such as LoaderInfo and URLLoader are registered using the register() method. As the loaders progress, the percentLoaded property is updated and progress events are dispatched. If only a single loader is registered, percentLoaded will reflect bytesLoaded/bytesTotal. If multiple loaders are registered, percentLoaded will reflect loaders complete/loaders total. When all loaders have completed loading, a complete event is dispatched. Enjoy!

package com.aaronhardy.utils
{
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IEventDispatcher;
	import flash.events.IOErrorEvent;
	import flash.events.ProgressEvent;
	import flash.utils.setTimeout;
 
	[Event(name="progress", type="flash.events.ProgressEvent")]
	[Event(name="complete", type="flash.events.Event")]
	/**
	 * A object which consolidates a group of objects that provide progress information.  Types
	 * of objects include UrlLoader and LoaderInfo objects. This allows a simple way for displaying
	 * overall progress for multiple loaders.
	 * 
	 * When a single loader is registered, the percentLoaded is simply the bytes loaded divided by
	 * the bytes total for the loader.  When there are multiple loaders registered, percentLoaded
	 * reflects the number of loaders completed divided by the total number of registered loaders.
	 * The reason why using multiple loaders is less accurate is because a loader does not know
	 * how many bytes it will be loading until the first response from the server.
	 * This means that we can't determine the total number of bytes to be loaded
	 * for all registered loaders up front.
	 */
	public class BatchLoaderInfo extends EventDispatcher
	{
		[Bindable]
		/**
		 * The percentage of all registered loaders which are loaded.
		 * When there is a single loader, this is simply the bytes loaded divided by the bytes total
		 * for the loader.  When there are multiple loaders, this is the number of loaders
		 * which have completed their loading process divided by the total number of registered
		 * loaders.  This value is between 0 and 1.
		 * @see doUpdateStats
		 */
		public var percentLoaded:Number;
 
		/**
		 * @private
		 * Registered loaders.
		 */
		protected var loaders:Array = [];
 
		/**
		 * Registers a loader with the registry.
		 * @param loader Any object that dispatches ProgressEvent.PROGRESS, Event.COMPLETE, and
		 * IOErrorEvent.IO_ERROR events as well as provides bytesLoaded and bytesTotal properties.
		 * Examples include UrlLoader or LoaderInfo objects.
		 */
		public function register(loader:IEventDispatcher):void
		{
			if (loaders.indexOf(loader) == -1)
			{
				loaders.push(loader);
				loader.addEventListener(ProgressEvent.PROGRESS, loaderProgressHandler);
				loader.addEventListener(Event.COMPLETE, loaderCompleteHandler);
				loader.addEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler);
				updateStats();
			}
		}
 
		/**
		 * Unregisters a loader from the registry.
		 * @param loader Any object that dispatches ProgressEvent.PROGRESS, Event.COMPLETE, and
		 * IOErrorEvent.IO_ERROR events as well as provides bytesLoaded and bytesTotal properties.
		 * Examples include UrlLoader or LoaderInfo objects.
		 */
		public function unregister(loader:IEventDispatcher):void
		{
			if (loaders.indexOf(loader) > -1)
			{
				loaders.splice(loaders.indexOf(loader), 1);
				loader.removeEventListener(ProgressEvent.PROGRESS, loaderProgressHandler);
				loader.removeEventListener(Event.COMPLETE, loaderCompleteHandler);
				loader.removeEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler);
				updateStats();
			}
		}
 
		/**
		 * Unregisters all the currently registered loaders.
		 */
		public function unregisterAll():void
		{
			// Use a copy of the loaders array because the original loaders array will be
			// manipulated as we loop through removing loaders.
			var loaders:Array = loaders.slice();
			for each (var loader:IEventDispatcher in loaders)
			{
				unregister(loader);
			}
		}
 
		/**
		 * Updates stats when progress events are dispatched.
		 */
		protected function loaderProgressHandler(event:ProgressEvent):void
		{
			updateStats();
		}
 
		/**
		 * Updates stats when complete events are dispatched.
		 */
		protected function loaderCompleteHandler(event:Event):void
		{
			updateStats();
		}
 
		/**
		 * Updates stats when error events are dispatched.
		 */
		protected function loaderErrorHandler(event:IOErrorEvent):void
		{
			// Because the loader will never reach a complete state because of the error,
			// we'll unregister the loader now.
			unregister(IEventDispatcher(event.target));
			updateStats();
		}
 
		/**
		 * Whether stats are flagged to be updated.
		 */
		protected var statsNeedUpdating:Boolean = false;
 
		/**
		 * Marks that we need to update stats.  We delay the actual updating of the stats
		 * until the next frame as a type of invalidation/validation cycle like the Flex components
		 * go through.  This is to avoid duplicate calls to the stat updating logic within a
		 * single render.
		 */
		protected function updateStats():void
		{
			if (!statsNeedUpdating)
			{
				statsNeedUpdating = true;
				setTimeout(doUpdateStats, 0);
			}
		}
 
		/**
		 * Updates percentLoaded stats.  When there is a single loader, this is simply the bytes 
		 * loaded divided by the bytes total for the loader.  When there are multiple loaders, this 
		 * is the number of loaders which have completed their loading process divided by the total 
		 * number of registered loaders.  The reason we can't go off bytes when there are multiple
		 * loaders is because a loader's totalBytes is only populated once it has made its initial
		 * request to the server.  This means the third loader might  not make its initial request 
		 * until the first request has returned. This means we don't know our grand total number 
		 * of bytes at the beginning, which is imperative to have to make an accurate 
		 * bytesLoaded/bytesTotal calculation.
		 */
		protected function doUpdateStats():void
		{
			if (statsNeedUpdating)
			{
				// See the asdoc for this function to understand why we have these different cases.
				if (loaders.length > 1)
				{
					var loadersComplete:uint = 0;
 
					for each (var loader:Object in loaders)
					{
						// bytesTotal is only populated (greater than 0) once the loader has made 
						// its request to the server.
						if (loader.bytesTotal > 0 && loader.bytesLoaded == loader.bytesTotal)
						{
							loadersComplete++;
						}
					}
 
					if (loaders.length == 0)
					{
						percentLoaded = 1;
					}
					else
					{
						percentLoaded = loadersComplete / loaders.length;
					}
				}
				else if (loaders.length == 1)
				{
					// bytesTotal is only populated (greater than 0) once the loader has made 
					// its request to the server.
					if (loaders[0].bytesTotal > 0)
					{
						percentLoaded = loaders[0].bytesLoaded / loaders[0].bytesTotal; 
					}
					else
					{
						percentLoaded = 0;
					}
				}
				else
				{
					percentLoaded = 1;
				}
 
				dispatchEvent(new ProgressEvent(ProgressEvent.PROGRESS));
 
				// If all the loaders we have registered have completed loading, we'll
				// unregister all of them and dispatch a complete event.
				if (percentLoaded == 1)
				{
					unregisterAll();
					dispatchEvent(new Event(Event.COMPLETE));
				}
 
				// Reset the flag.
				statsNeedUpdating = false
			}
		}
	}
}

A while back, Guitar Hero hit the gaming industry by storm and kids flocked to learning the guitar. Sure, it wasn’t a real guitar, but it was still an instrument of sorts and kids were still learning hand-eye-ear coordination, rhythm, and other music essentials. The game was a huge success, bringing in over $1 billion in sales in the first 26 months and set an industry record.

Why such a difference in my experience learning how to play the piano years ago and kids learning the pseudo-guitar with Guitar Hero? Guitar Hero provides objectivity, benchmarking, competition, and addiction. You can play with your friends in a fun atmosphere. Piano Marvel takes these concepts and applies them to learning the piano. Students play along to accompaniment, see exactly which notes they hit and when they hit them, and earn trophies as they complete increasingly difficult exercises. They can practice whenever they choose and can even battle it out with their piano-playing comrades.

Now to the gushy technical stuff.

First, Piano Marvel is built using Adobe AIR and Java. Adobe AIR provides the high level of interactivity needed for such an application. Java provides the ability to communicate with a MIDI keyboard. Both are bridged using Merapi–AIR talks to Java, Java talks to AIR. All are deployed onto the user’s desktop with a single installer. Both Windows and Mac are supported.

Second, all the exercise content can be easily managed by the administrator. Let’s say the administrator wants to add an exercise. He plays a little ditty in Finale using his keyboard, saves the musical notation as a MusicXML file, saves the accompaniment in MIDI format, and uploads both files using an online admin panel. The next time students log in, they have a new exercise to conquer.

Third, all music notation is dynamic. In other words, an exercise is not just a big graphic of sheet music. Instead, MusicXML is loaded from the server at runtime. The XML is immediately parsed and notes, accidentals, lines, dots, and all notation the user sees is drawn to the screen at that moment. Resize the window and the music is redrawn, not simply scaled, to fit into the available space in the most elegant and readable way possible. Because the MusicXML is very comprehensive in describing a musical piece, we can also use the XML to determine pitch and timing for evaluating a user’s performance.

Fourth, the user can tweak the tempo, only play a portion of an exercise, toggle accompaniment and metronome sounds, get note hints, watch tutorial videos, and more.

Fifth, the application was recently nominated as an Adobe Max 2009 Awards finalist in the education category. Yeah, we’re kind of a big deal.

If that isn’t enough, you can watch my ugly cakehole yack about Piano Marvel below:

You can use a free demo account to get hooked then pay a low monthly fee after your trial period is over. If you check it out using this link you’ll only pay $12/month if you choose to sign up. That’s less than the gas you’d pay to visit a piano teacher. All you need is a MIDI keyboard and a MIDI-to-USB adapter to get started.

Here are several screenshots of the app and its features. Props go out to Nate Ross for letting me steal his screenshots and captions.

Create a rich interactive music notation engine.

Display immediate feedback on all correct and incorrect notes that were played.

Have the ability to specify tempo, make music selections, and toggle fun accompaniment and metronome playback.

Create an environment that makes playing the piano addictive and entertaining

As a primer, the app challenges your singing abilities by allowing you to sing along with Kelly karaoke style. You’re able to sing songs from her latest album, All I Ever Wanted, and then be scored based on pitch and timing. If you’ve got singing skillz with a z then you might just win a chance to sing at Kelly Clarkson’s soundcheck, win tickets to the show, and go to a meet & greet event.

Props back to Josh Buhler for gracing me with his singing abilities while testing the app. Or so he says it was for testing anyway…

So there you go. Buy it and try out your singing abilities. Then send me a message from your iPhone telling me how exhilarating it was and make sure it says “sent from my iPhone” so I become increasingly more jealous. Enjoy!

Available Properties
value - The number value represented by the current knob rotation.
minimum - The value if the knob were turned counter-clockwise as far as possible.
maximum - The value if the knob were turned clockwise as far as possible.
zeroAngle - The angle, in degrees, representing the minimum value (-180 to 180).
maxRotation - The number of degrees from the zero angle the knob is allowed to rotate clockwise (0 to 360).
snapToCursor - If true, the knob will rotate to the cursor as soon as the user mouses down.
allowLooping - If true, this allows the user to continue rotating the knob clockwise past the max angle, eventually forcing the knob to cross over to the minimum angle. Likewise the user can continue rotating the knob counter-clockwise past the min angle and the knob will eventually cross over to the maximum angle. This can be particularly useful when maxRotation is 360 degrees and the user should be able to go around and around.

Skin Parts
backgroundSkin - This is anything around or behind the knob which does not rotate (e.g., tick marks, labels, etc.)
thumbSkin - This is the part of the knob which the user manipulates. In the real world, this would be “the knob” itself–the tactile part you would turn with your hand.

Exhibit A
Have at it! Right-click to view the source. Post a comment if you have a question.