Google App Engine gets hot-link protection !

What is a hot-link ?

A hot-link is one that comes from a domain other than the one that served the content.

Hot-linking is a problem because it allows people to leech bandwidth from others all the while using said content from a domain other than the one that originally served the content.

The Problem

The Google App Engine does not have the ability to inhibit hot-linking until today.

The Solution

Make it possible for hot-linking to be detected and stopped dead in its tracks by using the Google App Engine.

Ease of Implementation

Just contact Vyper Logix Corp via to get all the details.

Gain all the benefits of SalesForce by leveraging the Google App Engine is a great resource for those who wish to leverage the value one can find in the SalesForce offering however SalesForce has been rather guarded about how it seeks to lure people into using their platform as their primary web hosting provider.  SalesForce typically charges an arm and a leg for those who wish to use SalesForce as their hosting provider for their web presence.

It is possible to use the Google App Engine as the primary hosting provider, leverage the heck out of the Google App Engine to the point of being able to get 10 GB of transfer per day which means you can get 10x the typical limits set for a single Google App Engine App just by knowing how to proceed.

It is also more than possible to get all the benefits from SalesForce without having to host your content in the SalesForce Cloud.  This can be done with the Google App Engine directly or through the use of Flex 4 or similar related technologies.

It’s all a simple matter of writing some code once you have the level of understanding as how to get started as well as how to proceed.

Python makes all this possible.  Flex 4 makes it all look great !  Get the best of both worlds today !

SalesForce VisualForce and Flash

Every so often I am asked whether or not I can put a SWF onto a VisualForce web page in SalesForce.

As it turns-out, I do know how to do this.

The last time I was asked I said Flash SWFs can be plugged into a VisualForce web page as easily as any image could be and this has proven to be true, as if there was any doubt.

Step #1:

Get yourself a SalesForce account or get yourself a Free Developer’s account from

Step #2:

Create your VisualForce page as shown below.

Here we can see how to create a visualforce page using 3 easy mouse clicks.

Step #3:

Populate the visualforce page with the content required to embed a swf.  Don’t bother hot-linking to the SWF shown in this example the result will not be what you may expect unless you want to send visitors to the site that owns that SWF.

That’s all there is where the visualforce page is concerned.

Step #4:

Now let’s make a site, cannot expose a visualforce page to the outside world unless there is a site.

Again just 3 easy mouse clicks with some information entered when required and you have your site.

Step #5:

Now you need to get your visualforce page associated with your site.

And then…

And then…

And then…


Anyone who has evern embedded a SWF onto any kind of web page can embed a SWF into a visualforce web page.

Notice the SWF is not being served from SalesForce but it is being served from a CDN (Content Delivery Network) and this is the preferred method.

You could upload your SWF as a static resource as shown below:

But let’s face it, I would rather have more control over my static resources than this allows but that’s just me to be sure.

Either way, this is all easy stuff.

I will say the Flash support via Apex is rather limited but one can always craft some JavaScript to handle the embedding of a SWF and call it a day.

The page with the SWF can be seen via

The Agile LAMP Stack #2

The Agile LAMP Stack leverages the following technologies:

  • The Google App Engine (Django 1.1.1 apps) (100% Availability, 1 million hits & 1 GB per day transfer, Fault tolerance)
  • Ubuntu Linux 9.10 + Cherokee Web Server + FastCGI + Django 1.1.1 for those apps the Google App Engine cannot handle.

The Benefits:

  • No Cost Fault tolerance is the primary benefit.

Your back-end LAMP server may be down for maintenance or you may be rolling some updated code to your LAMP server and it is at these times when your Google App Engine app will be online and happily working.

Your back-end LAMP server can be used to handle AJAX REST requests for processing tasks the Google App Engine cannot handle such as uploading a ZIP file for processing of some kind or when you simply must have an FTP Server running or your own Mail Server or the like.

You can use your own LAMP server to store sensitive information in your own MySQL database, use the Google App Engine as a front-end server to handle requests for users who have not yet logged into your back-end LAMP server, etc.  This keeps Google out of reach of your valuable user data and prized back-end processing while maintaining 100% availability.

You could use Flex 4 to handle the encryption of your sensitive user data and then off-load processing to your back-end LAMP server when the Google App Engine is not able to handle your needs due to restrictions of certain API functions you may wish to use from the Python library or when you simply must roll your own Python extension you can do this using your own LAMP server.

  • The best of both worlds.

All the benefits of the Google App Engine with all the benefits of your own LAMP server.

Your site will handle far more traffic than your LAMP server could handle on it’s own.

You get 1 million hits per day and 1 GB transfer per day at no cost to you.

You get to leverage the full power of the Python language.

You get to grow beyond the confines of the Google App Engine without having to pay Google.

Leverage the Google App Engine

Google gives you 10 Apps for FREE.

Each App has certain limits before you have to pay Google for more.

This means you really get to play with 10 million hits per day and 10 GB transfer per day in addition to 10 times the other limits normally enjoyed by a single app.

How can you make a single App use all 10 app slots at the same time ?

Well this is where some secret sauce comes into play.

Some years ago I happened to learn how to do this very thing using just a little bit of JavaScript code however this same thing could be done in an elastic manner using Flex 4 or virtually any other technology or technique.

Needless to say, the end result would allow you to grow your Google App Engine based site using no more than the FREE services from Google in an elastic manner and all without anyone knowing what you are doing or how it is being done.

In the meantime, you can salivate over the possibilities of realizing the benefits of what Google is offering you at no cost.

As soon as you become aware of the fact that your app has reached one of the limits and your app has been denied or may be denied because of this before you reach for the switch to begin paying Google you can begin using the next App slot to double the limits with minimal effort.  Rinse, wash and repeat until your monster app is cruising along at 10 million hits per day and 10 GB per day transfer.  All you need to know is “how” to make this magic happen.

Who knows, Google might not even mind the creative use of your prized Cloud.

Google might not mind the creative use of their cloud…  their difficulty would be to devise a way to detect when this level of creativity is being used and because of this I am sure they simply do not care.

In the event Google does care about this one could still design a way to get around their ability to detect this sort of thing without causing problems for everybody else who is also using the Google App Engine. has the same problem, by the way.  If you know how to get what you want from those who provide services in the Cloud you can get what you want for FREE.

Which design is more Agile ?

Is an MVC design that uses only 3 objects more or less Agile than an MVC design that does the same work using 50 objects ?

Consider the problem

Consider the problem of coding a menu for a rather large site using Flex 3.

My design was to code 3 objects each of which used MVC.

The other chap wanted to code 50 objects to do the same work.

My design required something like 4 hours to prototype.

The other chap spent several months building his site menu also known as a Global Nav.

The timeline for this development effort was slated as being 3 months by the time all the players were assembled; there was one Java guy, one JavaScript guy, one CSS guy and 2 Flex guys of which I was one.

One can assume when one is given a task for which one must spend 3 months working on it the method that person chooses to use will consume all available time and thus the chap who wanted to use the 50 object hyper-complex MVC model won even though the simpler 3 object design would have accomplished the goal much faster at a lower cost with less effort.

So the real question is:   Is 3 Objects more or less Agile than 50 objects ?

For me, 3 Objects is far more Agile than 50 Objects but that’s just me.

When I was 3 years old I was taught how to count beginning with the number 1.  For me 3 is 2 more than 1 but 47 less than 50.

For some, like this Flex coder who just had to produce 50 objects to get his MVC model work work, 50 was the smallest number he could think of.  But again, when you have 3 months to play with and somebody, like Verizon Wireless is paying for you to work and you can make people believe your 50 objects is great simply because it uses MVC you might just be tempted to go along with the notion that 50 objects is the best design.

When I was a child, I was taught the shortest distance between 2 points is a straight line.

For some, the shortest distance is one most circuitous route full of twists and turns – never mind taking the straight line between the beginning and the ending.

How to sand-bag your team-mates without seeming to do so.

So let’s imagine you are getting away with coding those 50 objects simply because you are using MVC and you have managed to make those who are managing the effort go along for the ride and you really want to get rid of some of the others who were also employed to work along-side you but you cannot ask anyone to let someone go…  You might choose to build in some extra code to make the other person’s task that much more difficult, and so this was done.

When the task could have been done faster by simply referring to a JSON data model this fellow chose to make copies of the JSON data model within his code rather than simply pass references to the JSON data model directly.  But again, when you have 3 months to kill the devil will find work to do for idle hands.

Anyone who needs to ask questions will generally be classified as being unskilled so if you can get there first with working code that requires your team-mates to ask questions you will gain some prestige at the expense of others.  This cannot be done when one uses a rather simple model that requires the use of only 3 objects.  Nobody would need to ask any questions when there are only 3 objects to learn and one cannot make oneself seem more important when one produces only 3 objects.

The guy who was doing the JavaScript did his work likewise except he wanted to make sure the Flex-based SWF never say the light of day; again a subtle way of sand-bagging others on the team.  His claim to fame was to code an interval and then ignore others telling him how to resolve this issue until it was too late and so every so often one does not see the SWF when viewing beginning on 03-28-2010.  Bear in mind the original design was to ensure the SWF-based Global Nav always appears whenever the browser has a Flash Player because this goal was not accomplished, close because it works most of the time but every so often this goal is simply not accomplished.

If you really want your project to be Agile then make it Agile all the way.

Choose to use professionals who know the value of using fewer objects to get the work accomplished.

Choose to use professionals who know that 3 is more Agile than 50.

Choose to use professionals who know that a straight-line is the shortest path.

Simpler designs are more profitable than more complex designs.

Simpler designs are more powerful than more complex designs.

Professionals who can work with others while supporting the whole team are worth more than those that cannot, for whatever reason.

The Agile LAMP Stack !

Apache 2.2 is Out !

The Agile LAMP Stack does NOT include Apache 2.2 !

Apache 2.2 is too big and to slow to be Agile.

Apache 2.2 consumes way too much RAM relative to the performance it offers.

Cherokee Web Server or Tornado is Agile !

Both the Cherokee Web Server and Tornado Web Server are Agile because:

  • They both use far less RAM than Apache 2.2 !
  • They both handle far more web traffic per second than Apache 2.2 !
  • Tornado is said to out-perform Cherokee because Tornado is said to be non-blocking but then so is Cherokee.
  • Cherokee as a slick GUI-based Administrator and is pretty easy to install and use.
  • Tornado is not so slick but may be a better choice if performance is the goal.
  • Everything you can do with Apache 2.2 can be more easily done with Cherokee Web Server !

Python is Agile !

Python is more Agile than PHP by an easy factor of 5x or more !

Django makes Python-based web apps very easy to develop and deploy.

Python has the Wing IDE that makes Python development as dynamic and free-flowing as possible.

Why use the Wing IDE ?  Easy, it’s that Debug Probe that does it for those who are serious about their Python development.  With the Debug Probe one can continue developing Python code interactively by testing what-if scenarios long after the break-point has been reached.  Every other Python IDE has not yet achieved this level of sophistication and ease of use.

Python is a dynamic language but PHP is not !

Python is a dynamic language but Java is not !

Python code can be deployed to a hot web server but Java cannot !

Try deploying an EAR or WAR to a hot web server (one that is currently handling traffic) and the typical Java deployment system will shut-down the web server long enough to complete the deployment.

Try deploying your Django app to a hot web server and the process is seamless with no need to shut-down the web server or restart your FastCGI procs.  Sync your Model objects to your database and you are back in biz.

Python Scales using Agile Techniques !

If you can configure a single server to handle upwards of 30 million hits per day you can reduce the number of web servers your Enterprise uses and save money.

Try salivating over an Agile LAMP Stack that can handle 385 requests per second using only 100 MB of RAM and very little CPU power and then calculate how many hits per day this turns into and then try to figure-out how many hits per day your typical very busy website handles relative to the investment they had to make to achieve their numbers and you might be surprised.

Your typical very busy website that handles 300 million hits per day might have something like 250 web servers in their server farm especially if they are using something like Perl or PHP or Java.  This same 300 million hits per day could be handled by a single web server running the Agile LAMP-stack being discussed in this article.  Sure there is something to be said about having more than one web server because you won’t want to put all your eggs in a single basket but there is also something to be said about being wasteful.  The fact is you will get more success from deploying Python to a FAWN (Fast Array of Whimpy Nodes) than might be achieved by deploying PHP or Java to that same FAWN architecture.

The Agile LAMP Stack Revealed

L = Linux or more specifically Ubuntu Linux.

A = Cherokee Web Server or Tornado Web Server but any web server that is based on Stackless Python would be far more Agile.

M = MySQL.

P = Python with Django.

Agile JavaScript !

What makes JavaScript Agile ?

JavaScript is Agile when it deploys to your visitors using optimized techniques.

What makes JavaScript deployment optimized ?

When browsers are able to download your JavaScript content in parallel rather than serially.

Typical Browser Behaviors for JavaScript and CSS

Typically browsers will download each JavaScript and CSS file and then stop while each individual file is being downloaded.  This can take a lot of time especially when there are a large number of files or when each file is rather large.

Once you are able to optimize the delivery of your JavaScript and CSS you will notice a significant decrease in load times for your web pages.

Web pages that required 15 seconds before being optimized can load in half that time or less.  Lower the time required to load your web pages and you increase the enjoyment of your content, it’s just that simple.

Consider this following waterfall chart.

Notice line 2, this file loaded using the typical browser behavior which is to download the JavaScript while doing nothing else at the same time.

Now notice lines 4, 5 and 6 – here we can clearly see 2 CSS files and 1 JavScript file being loaded in parallel with the larger CSS being loaded while a smaller CSS file and a fairly large JavaScript file were loaded using the same amount of time as the larger CSS file. This is not the typical behavior for your typical browser.

How was this web page optimized ?

Very simply the dynamic.js file was loaded first because it contains some useful code that allows CSS and JavaScript files to be loaded in parallel.

CSS files are loaded the same as image files through the use of dynamic.js; using this model CSS files are simply loaded in parallel without any consideration as to what may be dependent upon whether or not they are loaded and this technique works very well.

JavaScript files are also loaded in parallel but in such a manner so as to allow this type of content to have dependencies with other JavaScript files.  A callback method is used to allow the next set of actions to be issued as soon as the JavaScript file has been loaded.  This allows jQuery to be loaded in parallel with CSS and other JavaScript files such that as soon as all the required JavaScript files have been loaded jQuery can be used with complete confidence that jQuery is ready and able to be used.

Some JavaScript programmers might want to use an interval that waits for jQuery to be loaded and ready but doing so is wasteful and not even required.  The cleaner approach is to use a callback method because doing so is less error prone and will always produce a cleaner crisper performance.

Consider the following Waterfall Chart

As before, line 2 is the only JavaScript that loads using the default browser behavior and nothing else was being done while this file was loaded.

This time lines 4, 5, 6 and 7 were all loaded in parallel during the time line 6 was being loaded.  Lines 4 and 5 are both CSS files and were loaded during the same 134 ms time-frame.  Line 6 is a rather large JavaScript file that contains jQuery.  Line 7 is swfObject.js which is used to load and embed SWF files.  As you can see, swfObject and jQuery were both loaded at the same time while both CSS files were being loaded.

What changed from the first waterfall to the second ?

The first waterfall was produced by causing jQuery to load before swfObject but only after swfObject had been loaded.

The second waterfall decoupled jQuery and swfObject by causing swfObject to begin loading before jQuery was requested with no dependency between jQuery and swfObject.  The callback for swfObject causes the SWF to be loaded and embedded while jQuery is being loaded.

The second scenario is a better experience than the first although the results are pretty subtle.

Enhanced SWF Loading

Along the way swfObject.js was also loaded in parallel and a SWF file was embedded after all the required JavaScript files were loaded by the browser.  The SWF was compiled using Flex Builder 4 using RSL’s for the Flex Framework and this produces a nicely optimized SWF that performs very well.  It should be noted the SWF is being loaded in a secure manner that hides the details of the actual SWF from view.  Try as you might you may not be able to determine the source of the SWF and therefore you may not be able to grab the actual SWF and this makes the use of the actual SWF more secure than might be otherwise.  The SWF you can see at which is a 3D rotating globe is not the SWF that will appear if your browser’s cache.  The SWF that appears in the browser’s cache is just a wrapper that knows how to load the actual SWF.  The fact that we expose the URL for the actual SWF in the source for this web page is something that could have just as easily been obscured using encryption for situations where the identity of the actual SWF might need to be hidden from view.

Additionally you may notice the right-click menu has been replaced by the SWF using a bit of JavaScript code.  The default menu is not all that pleasing anyway so why not replace it ?!?

Why do any of this optimization stuff ?

The reason one performs optimization is to make the user experience better than might otherwise be possible.

Sure, it is easier to allow the browser to do its thing because eventually the web page will be rendered and the user will be able to see what has appeared in the browser, no worries here.

For me, having spent about an hour just about 16 months ago to work-out what it takes to get my CSS and JavaScript optimized after having spent about 10 minutes with some Google information one Saturday morning… well not I don’t have to be concerned about whether my CSS and JavaScript files are handled in any other manner other than to use the code you can find in the dynamic.js script file.

For others, they might need to build some more elaborate methods for getting their CSS and JavaScript files into a single file for each where they end-up with a single CSS file and a single JavaScript file but their technique, as slick as it seems, means the CSS and JavaScript will still load using the typical browser behavior which admittedly will load a single CSS and single JavaScript file at the same time – my method means I have more control over when my files are loaded and I can use lazy-loading techniques to load my files after document ready if required to do so.

If you can use iFrames…

Some people don’t like iFrames because they have been deemed as being “evil” by those who just don’t spend enough time working with them.

You could just as easily load your JavaScripts using individual iFrames, one for each JavaScript file and then allow the iFrames to push the code they loaded into the parent DOM which results in loading your scripts faster because they can all be loaded in parallel.

The iFrame technique is a longer way to go to get the same thing accomplished versus the dynamic.js method outlined in this article but whatever it takes to get the work done works for me so long as I get to use the techniques I enjoy using.

Images can all be lazy-loaded too

The nice thing about loading image assets is that they can all be loaded in a lazy manner which means loading them only when they are needed or after document is ready, if the goal is to get your SWF content loaded faster than might otherwise be possible.

Optimized web pages are just more Agile

Why stop at using the Agile method to get your code developed ?  Why not make your web pages more Agile by allowing the browser to work for you rather than against you.

Maybe someday someone will produce a browser that can optimize how content is loaded but for now this is something a human being must do if it is to happen at-all.

%d bloggers like this: