Agile JavaScript Redux

Consider the following waterfall chart

Notice the red arrows and where they point.  Notice the numbers to the left of the red arrows.

The files that appear between and including arrows (1) and (2) are all JS files that were loaded during the same 0.078 seconds.

The files that appear between and including arrows (3) and (4) are all CSS files that were loaded during the same 0.034 seconds.

The files that appear between and including arrows (4) and (5) shows a CSS and a JS file that were loaded during the same 0.006 seconds.

The files that appear between and including arrows (5) and (6) shows where jQuery and some JS file that depend upon jQuery were loaded in series.

The difference between what took place between (1) and (5) and (5) and (6) is the difference between loading CSS and JS files in parallel versus loading them in series.

The standard behavior for just about every browser currently in-use is to load CSS and JS files in series which is to say CSS files will all be loaded one after the other in series all the while waiting until each file has been loaded before moving along to the next file in the list.  The exceptions to this is when a single CSS and single JS file can be both loaded at the same time which is what is shown between (4) and (5) in the graph above.  And of course we all know images and other files are always loaded in parallel per the HTTP 1.1 Spec.

The Magic

The magic being shown here is the same one being used by in the file called dynamic.js which is shown on the row just above (1) in the chart above and as you can see this file was loaded using the standard default behavior which was to load this JS file without loading any other JS files in parallel.

Why does this matter ?

The reason you might want to optimize the delivery of your CSS and JS files is the same reason we all want your visitors to have a really nice experience when using our sites.  When a page loads quickly the user can get on to using the site faster and this too helps the user to have a really nice experience so long as there are no glaring bugs along the way.

When 6 JS files are loaded during a really short 0.078 second burst we can say for sure those same 6 files would have required something like 6 times longer to load had no optimizations been used at-all.

For my money when CSS and JS files load faster the whole site just looks and feels slicker as opposed to a site that requires a really long time to load before the content can be used.

The Beauty

The beauty of all this is that one can use the optimizations or not, as-needed.

As you can see the files between (1) and (2) were loaded by simply tossing the requests to load those files to the four-winds, so to speak, with no regard as to when or it they would be loaded other than to simply make the requests.  The files that fall between (3) and (4) were loaded in much the same manner, with no regard as to what was to be done after each file was loaded.

The files that were loaded between (5) and (6) were loaded in series which means each succeeding file was loaded only after the preceding file had been loaded.  This was done to ensure jQuery Core had been loaded before the files that depend upon jQuery Core were loaded in case any of them required the use of jQuery.

Consider the following waterfall chart

Notice the differences between (5) and (6) in the second chart versus those from the first chart.

For the second chart the jQuery files were made to load in parallel as soon as the jQuery Core had been loaded.

The interesting thing about how jQuery was loaded in both instances is that the second chart records a slight increase in the time required to load this page versus the first chart even though the jQuery files were loaded in a more efficient manner the second time around.  The time difference could be simply an anomaly and not an indication of an increase in the time required to load this page.

The bottom line is…

When one has Agile Methods for loading JavaScript and CSS files one can optimize the load time for each page of content using code that is very easy to use and very easy to control.

You can choose to use the default behavior every browser knows how to use or you can control the manner in which those browsers load JS and CSS files.

The choice is yours as the developer of your site’s content.


VyperCloud™ Cloud OS based on Stackless Python 2.5 or Django 1.2

See the full Presentation here !  VyperCloud™

See the Executive Summary here ! VyperCloud

See the Patent Application for ezCluster (part of the technology base for VyperCloud™).

Imagine the impossible !

Realize the potential !

Get involved today !

Confuse, Block and Confound the Browser’s Cache

Confuse the Cache & Block the Cache

Serve your images through a single URI using HTML/JavaScript.


Only one image is ever cached – the last image that was served.


Do this right…

  • Set the response headers correctly to tell the browsers to not cache and not store your image.
  • Request all images through a single URI that does not specify the image file type such as “/get-image/”.
  • Block the typical human user’s ability to view the image via the URI by requiring the referrer to be the domain from which the image was served.
  • Clear the cached URI by sending an empty image as the last image that is served into a hidden image tag.

And whenever someone does manage to click on an image URI sitting in their browser’s cache they will not see the image whenever their browser gets around to showing the image using the browser because the server will not serve the image because the referrer will not be set correctly thus requiring the user to forge some request headers and this will at-least raise the bar a bit higher and keep the typical civilian user from seeing your prized images or other content you don’t wish to share with everybody unless they are Authenticated and logged-in to your SaaS offering.

Images can be served through a single URI by telling the server to serve a series of images as an ordered series of images where each request to the “/get-image/” URI results in the next image in the series being served.  You can write some JavaScript code using jQuery, for instance, to create some HTML content on the fly with the last image going into a non-visual image tag just to clear the cached image (there will be only one).

Response headers will have to be tweaked to ensure the browser will fetch from the server rather than using the cached image but again this is not all that difficult.  Make sure you don’t use some funky trick like appending some random value to the end of the URI because this will not only bust the cache and hit the server, it will also result in every single image being potentially cached even if the Response headers are set to force the browser to not cache and not store each image.

Why bother with any of this anyway ?!?

If your site offers any kind of SaaS or other service your customers are paying for, for instance, then you might very well want to care about what ends-up in the browser’s cache.

The better method

Use Flash or Flex to fetch your images using AMF2 or AMF3 or some other method that forces the bits and bytes of each image to be transmitted in a format other than the native format most browsers know how to cache.

Use a socket client running in the SWF to make a dynamic connection with the server.

The SWF does not even have to be visible unless this is the desired use-case for your Flash talents.

If there is no Flash Player then fail-over to using the techniques listed above that don’t use flash otherwise use Flash and enjoy your ability to show your content to your end-user without allowing them to grab your content from their browser’s cache.


Make Image Assets Secure

When you want your customers to have access to certain images or other assets only when they are online and logged-in you would be hard-pressed to ensure this is the case unless…

You know how to make your Images and other assets secure from offline use.

Introducing SecureImage(tm)

SecureImage(tm) make images (.JPG, .PNG and .GIF) files unable to be viewed unless they are being viewed from a particular domain.

SecureImage(tm) is ideal for any use-case where people are not supposed to be able to see certain assets such as images, videos or documents when they are not logged-in.

SecureImage(tm) is ideal for the use-case where the user community must be logged-in and authenticated in order to use certain assets.

Consider the Online Training Use-Case

When Online Training is being offered for users who are authenticated the organization offering the training might want to ensure offline use of their materials will not be allowed and as we all know FireFox is an ideal browser for those who want to see offline content because this one browser more than the others makes offline use of materials very easy.

When the Online Training materials are being viewed offline they should be unavailable and invisible to the casual user.

How does SecureImage(tm) work ?

Let’s just say the primary function of SecureImage(tm) is to disallow access unless the items being protected by SecureImage(tm) are being viewed from a single known domain.

SecureImage(tm) ensures the protected assets are being served from the single known domain and that this single known domain is serving the content under the control of a single known authority.

Simply spoofing the single known domain would not be good enough however it is not difficult to hide the URI for those assets being protected by SecureImage(tm) by serving those assets via Flash/Flex where the URI is never exposed to the user.

SecureImage(tm) also employs the use of a “key” that is requested by each asset whenever the single known domain is present; the value of the “key” is encrypted and signed with a temporal signature ensuring it cannot be reused outside the scope of a sliding window of time.

Those who wish to spoof the SecureImage(tm) system would have to know the single known domain for each asset along with the value of the “key” and the method that was used to sign this key.

Additionally SecureImage(tm) employs the use of SWF Obfuscation to further make it very difficult if not impossible for those who wish to reverse engineer the assets being protected by SecureImage(tm) from being able to do so.

Ease of Use

SecureImage(tm) can be deployed by anyone who can operate the Flex Compiler as each asset is wrapped by a SWF by embedding the asset into a SWF.

The trade-off is bandwidth as one is trading a larger asset for security.  Those who have assets they wish to protect from offline use would probably not mind the bandwidth cost.

Flex Layers Demo (Video)

Flex App Layers showing 3 Distinct Layers

This Flex App shows 3 distinct layers running in the Flex App.

Flex Layers Demo (Video)

Skin your Flex App Faster using Layers !

Skinning a Flex App using the Adobe Flex approved methods can take a lot of time !

You have to create image assets for every little control and widget you wish to use in your app and this can take quite the amount of time compared with the alternative.

What’s the alternative ?

Use Layers !

Layers ?

Yes, Layers !

What’s a Layer in Flex and how do I use it ?

We should all know about Layers in Flash Apps, right ?   If you don’t know what a Layer is at-all then go and do some research because this article will make absolutely no sense to you whatsoever.

Canvas is a Layer in Flex !

The Canvas Object is a Layer !

Canvas objects when placed on the stage will stack one on top of the previous.

Place something on a Canvas that is behind another Canvas and you will begin to build Layers of Content.

Place your Skin as either a static image or a SWF in a Canvas behind your App and you will have skinned that page of content.

The Layers that appear on top of your skin can define button shapes and regions your users can click as-if they are buttons.

So How Does one Canvas get behind another ?

Simply put each Canvas you place on the stage forms a Layer.

Place Canvas objects of the same size on the stage and you have formed Layers.

Consider the following: (This is Flash Builder 4 code…)

<s:Application xmlns:fx=”;
minWidth=”384″ minHeight=”640″ maxWidth=”384″ maxHeight=”640″ width=”384″ height=”640″

<mx:Canvas id=”canvas” width=”100%” height=”100%” borderColor=”black” borderStyle=”outset” horizontalScrollPolicy=”off” verticalScrollPolicy=”off” creationComplete=”canvas_creationCompleteHandler(event)”/>


With the following code:

This code shows 2 Canvas objects with one placed behind another.

Notice the overlap between the Backdrop object (this is a Canvas) and the UIComponent.  The Backdrop will appear behind the UIComponent.

You can place any visual element behind another.

Canvas objects are translucent by default.

Translucent or see-through until something is drawn or some other visual element is shown.

Your backdrops can be dynamically loaded at runtime across the Internet or embedded into your App !

Your backdrops can be Flash SWF files !

Your backdrops can be animated !

Mouse Events can be bubbled from your App into the Backdrop !

Keep in mind any SWF placed on the Flex stage integrates into the Stage and has access to the entire Stage !

Your backdrop SWF can walk around your Flex stage or just sit there and look pretty.

Play around this this and you too will see the value of using backdrops for your Flex Apps.

Skin your Flex Apps faster and easier or simply add some Flash to your Flex-based game Wireframes using very little effort.

Working Demo:

The following is an image from the wireframe for this game that shows a backdrop from an image placed behind the playing board using the techniques shown above as a proof of concept.

Any visual elements can be placed behind any other visual elements using Flex or Flash for that matter.  Flash makes it easier to separate visual elements into layers however Flex provides a slick method for handling layers also but only for those who know how to master the full capabilities of Flex.

The backdrop can be loaded from a URL or can be embedded into the SWF or can be a SWF or any number of SWF files.

This is simply a working demo and not the final game.

Responsability-Driven Object-Oriented Design is just Easier than MVC !

Object-Oriented Design is just Easier than MVC !

MVC will always lead to code bloat  and this is just a fact.

OOP will always lead to getting designs up and running faster and easier.  Case in point is this project.

Why waste time coding all that Model-View-Controller baggage when all one needs to do is focus on the Objects and their Responsibilities ?!?

Some people love MVC for the sake of MVC !

And this is the worst approach anyone could take with any project !

Loving anything for the sake of is wasteful should not be used.

Every single project is different and every single approach to every single project should be different.

This game is composed of a “wireframe” that has been coded to be a very small handful of Objects and only those objects that are required to make this game functional.  Had this game been coded using MVC I would have had to code 3 sets of objects with a whole lot more code to service the connections between the Model, the View and the Controller.

The OOP Approach takes less time to code

There is a Model.

There is a Controller.

And there is a View to be sure, all 3 must exists for every App.

The OOP approach is simpler than MVC because it requires only the smallest set of objects to be created and maintained. All things being equal the smallest set of objects will be the easier to build and maintain.

The Controller is built into the OOP design.

The Model is built into the OOP design.

The View is built into the OOP design.

Each Object is programmed to perform only those actions for which it has direct responsibility while cooperating with the other Objects.

There is no need for the View to issue messages to the Controller just to talk with the Model when OOP is being used.  There is a Controller and it does talk to the Model to be sure and the Controller does get messages from the View – the difference here is that MVC is built into the Objects rather than MVC being coded as separate objects.  Each Object can have its own MVC working within it and each MVC can communicate with the other Objects that each have their own MVC, as required to make the Application function.

OOP Rocks !

Object-Oriented Responsibility-driven Programming will always produce working code faster than the standard MVC programming model.

Object-Oriented Responsibility-driven Programming makes use of MVC it just does so in a more concise manner.

If you want to save time and money on your projects you might want to consider using Object-Oriented Responsibility-driven Programming rather than straight-up MVC.  When it is my time and money I will always use whatever technique gets me working code faster and at a lower cost than might have been required otherwise and let’s face it folks game programming while being fun and be costly for some to undertake.

Any wireframe can be dressed-up to look like anything the designer wants that wireframe to look like and when you know the tricks of the trade you can quickly and easily do this, as an individual.

From Concept to Game in less than a Week !

Beat that with straight-up MVC, if you can !

%d bloggers like this: