Invalidation (request to repaint) on demand functionality change
Prior to this update, parts of the code that needed the display would request that the display updates itself with an invalidate command – something other old Delphi custom control writers would probably recognise. This was starting to become inefficient, and while I tried a few different ways of improving the performance – you know like using setTimeout and clearTimeout to prevent lots of redraws nothing really worked out.

The draw operation is now done in an setInterval callback which is set to fire every 40ms (basically equating to 25fps for draw). Yes, I know that all of you smarty pants out there will say this was obviously the way to go, but for some reason I thought I could implement an on-demand drawing system better (that maxed out at a 25fps draw rate). Anyway, lesson learned – the animation loop is in and it’s working really well.

Essentially, the invalidate command still exists and is used to inform a SLICK.Graphics.View (api doc to come) that something is actively requiring redraws (such as a panning or pinch zoom operation). That just triggers a flag that means we need to lay off heavy buffer redraws while this is going on.

Created a ViewLayer “class” in addition to View
Prior to this refactoring, the tiling and mapping classes extended the functionality contained in the View. However, things were starting to be come a little unwieldy and seperate drawing operations weren’t terribly well encapsulated. As such I introduced a ViewLayer to serve as a mechanism for encapsulating that draw code. Essentially, a ViewLayer has a z-index and can be buffered or unbuffered (i.e. it draws directly to the View canvas as opposed to an offscreen buffer, which is then drawn across). Since creating the ViewLayer class I have been able to encapsulate nicely a Radar Overlay, a cross hair Overlay, copyright text for the maps, etc and most importantly been able to implement zooming behaviour for the maps in a way that provides the experience that we are all used to (I’ll post more on this later). Anyway, I’m very happy with the result and if anyone want to checkout the code – feel free to have a look on Github. The following modules are probably of most interest:

• http://github.com/sidelab/slick/blob/master/src/js/graphics.js
• http://github.com/sidelab/slick/blob/master/src/js/tiling.js
• http://github.com/sidelab/slick/blob/master/src/js/mapping/ui.js

Right, onto implementing the RouteOverlay to enable displaying a route on a map…

Any questions, comments, etc, then feel free to leave something below or comment over on Github (I think you can do that)…

As someone who is passionate about cross platform mobile development when it came time to build a mapping application, I believed very strongly this could be done using cross-platform, web-based techniques. Additionally, I am complete agreement with http://jonathanstark.com/blog/>Jonathan Stark regarding his take on why you should write cross-platform mobile apps using web techniques. I’d recommend getting his book, BTW. Anyway, I’m getting off track – basically the goal is to write a mapping application in such a way that it could be deployed natively using any of the cross platform mobile frameworks out there. So what tools do you have to do that?

Well, I guess let’s start with what we do have. For the user interface we can probably choose either jQTouch or iUI (or Sencha Touch if you are currently* writing an opensource app). When the dust clears from Sencha’s unveiling I may try and do a comparison of the pros and cons of each of these, but not now – suffice to say they will all do the job quite nicely.

So, we got some UI elements, what else do we need – oooh I know, a map! Well mapping APIs are pretty much written in javascript so they should all work right, well, yes, kind of, but at the same time no. The current suite of javascript mapping toolkits are very much geared towards mouse driven interfaces and don’t really cater for touch interfaces (i.e. no pinch and zoom). And while I did hack around with javascript API of the deCarta mapping platform that is being used by my current client, it really didn’t cut the mustard. Why not? Well primarily, because the majority of those older API’s have had to cater for a lot of older browsers and to their credit they have done very impressive things to get online maps to where they are today – but it’s time to cut out the fat.

Enter SLICK
http://github.com/sidelab/slick
Slick was primarily born to create a HTML5 canvas based tiling map layer to meet the needs of the mapping application that I am currently writing. But I don’t like writing things that can only be used for one thing. As such, I’ve tried to nicely abstract and provide useful wrappers for capturing touch events and building sliding tiling interfaces of different kinds. I even started to write some UI components, but I’m going to rip those out because they don’t belong (I might create a SLICK UI lib, but we’ll see how we go).

In the first instance, Slick was very much built on jQuery (and it definitely still relies on it in certain places). I have, however, come to realize (through frustration) that building a dependency in like jQuery is a pretty dangerous thing and a simple thing like the different ways jQuery handles ajax calls between 1.3.2 and 1.4.2 can definitely stuff you around. As such, I am in the process of decoupling reliance on jQuery. I don’t love it any less, it’s just that Slick can’t need it. So what do I miss most about not have jQuery? Selectors – no, I miss them, but I can always integrate Sizzle. Really simple AJAX calls – no, they betrayed me ;( The thing I miss most in not having jQuery is jQuery.extend.

Enter GRUNT
http://github.com/sidelab/grunt
I need an extend mechanism, and while I searched for a javascript library that provided just the core requirements for building a javascript library (extend, ajax, etc) I couldn’t find one anywhere (please let me know if you know of one). As such, I started integrating some of the core useful jQuery stuff into Slick. Then I thought, hang on, I’m just doing what everyone else is doing, so I stopped. I then started removing core modules / functions that I was using from Slick and putting them into a new library that I have called Grunt (it does the Grunt work). The extend mechanism is implemented as per the jQuery one (if any brave souls think they can write a better, one I’d be happy to see the library forked). I’ve also implemented ajax handling from the ground up (which needs quite a bit more work). There’s some XPath wrappers and other stuff, so if you are interested, then have a look.

Use at your own risk
At the moment, both SLICK and GRUNT are very much works in progress. In the areas that I’m using them extensively they are both quite stable, but I expect that people will be able to break them with relative ease in different usage scenarios. If you are feeling brave / bored, however, I would love feedback on either library (GRUNT will likely die if I can find someone who has already invested effort in creating a similar base library). Additionally, once things get a little less busy for me (which is currently looking like sometime in 2012, I hope to put together some demos for Slick showing what it can do).

In the interim, feedback welcome.

Personally I’d love to see a strong Brisbane contingent hit Sydney and put a few teams together to showcase the talent that is kicking around up here, and all for a good cause. There’s definitely a few people that I have in mind, and yes, I’ll probably be hunting you down

Thanks to SquiggleMum for giving me the green light to go and participate in what I think is going to be an awesome experience – just having a look around at flights, it looks like it would be about $100 each way with Virgin Blue. But interested to see what other people can find around the place if we do manage to get a few people together.

Come on, you know you want to – register for the event. If you can’t go to the event, and still feel like making a difference to the world, maybe you should think about sponsoring a child through either Compassion or World Vision (both excellent Child Aid organisations).

Oh, and I forgot to mention, the event is free (thanks to some kind sponsors) with food and drink provided. Now, if you need more than that, you are just being hard to please.

Well, here we go, and just as a side note I’ve flip-flopped between windows and web programming so it’s going to be a mix of both.

Windows: Borland C++ Builder (C++)
Used for windows development. Clunky syntax and a very poor cousin compared to Delphi. It sucked almost as much as I did back then. While we owe a lot to C and C++, I doubt we owe very much to Borland’s variant.

Verdict: Forgettable

Windows: Borland Delphi
Anyone who knows me, knows not to get me started on Delphi. One of the great object-oriented programming languages + supporting toolkits of our time – largely due to the genius of Anders Hejlsberg. Sadly Delphi could never stand up against the momentum of Visual Basic, and has largely disappeared into history. Pity, it was simple to do the simple things and proportionally difficult to do the difficult things – you could even embed ASM if you were feeling ambitious.

Verdict: Unforgettable

Web: Perl
I certainly learned a lot about coding for the web from Perl, and while the language itself is not as popular today as it once was, it’s still pretty solid. As tempting as it is to write that the language is forgettable just to stir up a good friend of mine, Perl has done too much for the web just to belittle it for the sake of my own amusement (it was close though).

Verdict: Unforgettable

Web: Cold Fusion
I have to admit, I’m in two minds with regards to Cold Fusion. It was a language that didn’t really do anything too special out-of-the-box but what you could do was just super simple to do. Additionally, as the product did mature and became a J2EE web app you could do cool things like access java libraries, etc, so that was pretty nifty. Still, I think I could afford to forget…

Verdict: Forgettable

Web: ASP.NET
By rights, DOT.NET should have been the holy grail of web application development for me. The C# language was built by my old Delphi friend – Microsoft wooed him to the dark side and it promised a real re-thinking of application development in general. Somewhere along the way, though it seemed to lose it’s way. I got into ASP.NET at 2.0 and you could do some cool things then, but then Microsoft felt the need to implement AJAX coding in a completely half-baked way and I had flashbacks to the holy wars of Delphi vs Visual Basic. There is no doubt that .NET is a big deal, and I built some pretty good web apps using that technology, but it wasn’t thanks to the patterns and practices promoted by Microsoft. If you are going to code in .NET then I’d recommend checking out a local alt.net group for using the technology effectively.

Verdict: Forgettable

Web: Javascript
To close out the languages that I have coded in professionally, javascript definitely deserves a mention. It’s the poor orphan language that nobody thought would amount to anything but with some talented and outspoken people like John Resig and Douglas Crockford massaging, promoting and educating people how to use it, it’s become one of the great enablers of the modern web application. Honestly, whatever server-side language you decide to use, make sure you skill up in javascript. I’ve never trusted server-side javascript generators and even if you use them you should know what you are dealing with in terms of the code they generate. For some fun, why not check out server-side javascript goodness like node.js or jaxer.

Verdict: Unforgettable or Forget at your peril

The Potential Replacements

Currently I’m using (or looking at) the following languages, and only time will tell whether they will be deemed life-changing and unforgettable, or as Rimmer would say “languages I’ve met” (note: creative license).

• Python (with Django) – unforgettable for speed and general arrogance of the language
• Ruby – never intended to use, but things have a funny way of working out. Jury’s out.
• Groovy – definitely unforgettable – closures I love you. But not more than SquiggleMum – if that were true I’d be a dead man.
• <Insert unforgettable functional programming language here> – preferably not JVM based, suggestions welcome.

Feel free to step in and defend your beloved languages if you feel an injustice has been done, or leave your language baggage in the form of a comment.

Having just left a corporate environment in which I would occasionally get to chat with the CIO regarding the pros and cons of some current technology trends, such as cloud computing, which would also include discussions around the enterprise suitability of those solutions, I can tell you – accidents like this are going to have an impact.

It’s getting to the point now where people would call me a Google Fanboy. I’m passionate about Google’s AppEngine as one of the few solutions that has actually got cloud development and scalability right, I recently gave up my iPhone for an Android handset, and I’m genuinely interested and excited by new languages like go.

All this passion regarding the technical capability of these Google products is going to amount to very little, however, when I come to pitch an AppEngine solution to the corporate that have just left (which I had intended to do).

Whilst largely unrelated, the Google datascraping incident will only increase the level of distrust (or at least questions around security practices) around many of Google’s offerings – especially cloud solutions, and while the words in the official post from Google all make sense (and I hope genuine) will mean very little when the majority of articles already read “Google steals private data”.

From the official post:

The engineering team at Google works hard to earn your trust—and we are acutely aware that we failed badly here. We are profoundly sorry for this error and are determined to learn all the lessons we can from our mistake.

You bloody better. You’ve certainly made things tougher for me when it comes to pushing your solutions. Honestly, I’m not sure what’s required here. I don’t doubt that Google engineers rock, but it’s time for beta “features” such as Wifi data collection to be caught before releasing products into production environments.

… I think I just lost my fanboy status

This is part 1 of the wrap up from that week – a comparison of the native bridges for cross platform iPhone and Android web app development.

The three candidate frameworks that were compared last week were PhoneGap, RhoMobile and Appcelerator. Each of the products takes a slightly different approach to native device integration, so while all three appear very similar on the surface they do have distinct differences. The right platform for you will largely depend on the style of application you are building and your preferred coding style. Without further ado, let’s take a look at an overview of each of the frameworks. After that, we’ll have a look at which framework I have decided to take forward to develop a mapping application and why.

PhoneGap
phonegap.com
PhoneGap is a native bridging framework in the purest sense. It is an enabler for accessing the native capabilities of a multitude of devices using web technologies as much as possible. You can write web applications with hooks into the native capabilities of the device in your javascript code. Structure your application well and you should be able to support progressive enhancement using those additional native capabilities. Once you have done this, you should very easily be able to make your application available through both the device application stores and online at a url of your choosing.

Choose PhoneGap If…

• You are a writing (or have written) a mobile web application or site and want to access the native application stores and/or the native capabilities on a number of devices.
• You have experience with HTML / CSS / Javascript technologies, and the neither of the differential offerings in Rhodes (Rhomobile) or Titanium (Appcelerator) appeal to you.

Rhodes by Rhomobile
http://rhomobile.com/products/rhodes/
While in my previous post comparing mobile web frameworks I shyed away from Rhodes due to a preference for Python over Ruby, I gave it a more solid shot this time. While it took longer to gain familiarity with the framework due to the extensive use of Ruby and Rails-like architecture, once you get the hang of it you can definitely appreciate some of what Rhomobile are trying to provide you in a mobile application framework.

Whereas PhoneGap take a very bare-bones framework approach to a native bridging framework, Rhodes provides an architecture for building data-driven mobile apps that will be very familiar to developers who are familiar with Rails or similar MVC frameworks. Additionally, Rhomobile provide a number of additional services that can enable you to create a mobile application with supporting data stores without having to look beyond their RhoHub and RhoSync products. While I have a strong preference for using server-side solutions such as AppEngine for providing the remote component pieces of a mobile application, and wiring it all together myself, there are times when using something like RhoHub could definitely be appealing. There are some costs associated with using RhoHub though, so make sure you investigate these before jumping in boots and all.

Choose Rhodes If…

• You have experience with Rails and the Ruby language and are looking to create mobile applications.
• You are interested in created a data-driven mobile application and are looking for a framework that is geared strongly towards supporting those kind of apps.

Titanium Appcelerator
http://www.appcelerator.com/
Titanium is probably one of the most ambitious of the native bridges that I looked at in any sort of depth. Appcelerator’s pitch is slightly different to the other frameworks in that they are pushing to achieve Cross Platform Native Development – both for desktop and mobile operating systems. This is definitely a big task, given the progressive nature of the mobile SDKs especially. With the amount of work that is required to support native controls and application components on a device, Titanium doesn’t yet have the same breadth of device support that both PhoneGap and Rhodes have – currently they support both iPhone and Android, and a Blackberry beta is scheduled for release soon. I don’t consider this a problem right now, as I’m taking quite a blinkered view to cross platform support myself at this stage prioritizing iPhone and Android above all other platforms.

Coding in Titanium is definitely a pleasant experience, as development is done completely with javascript. Additionally, framework components make the task of developing the app quite a straightforward process with a nice UI for starting and logging in your applications while developing. Plus the buzz of seeing a native control created from writing javascript rather than Objective-C feels very good indeed.

Choose Titanium If…

• You really want to develop a cross-platform native mobile application using javascript, rather than Objective-C.
• Are focused primarily on iPhone and Android handsets (and soon Blackberry).

Impacts for a Mapping Application
While I started the week looking for something in one of the frameworks that would differentiate one framework from another for building a mapping application, I didn’t really find one in particular. Both Rhodes and Titanium are pushing the envelope and offer native mapping controls for various platforms (Rhodes does have wider device support currently), both implementations only provide support for displaying a map and pinning annotations on the map at a particular latitude and longitude. Satisfactory for some apps, but I need to go further than that.

Additionally, not suprisingly both frameworks support native maps for Google Maps only out of the box, and the complication I have is that in this instance I need to develop for the deCarta mapping platform (despite my love of other things Google – AppEngine, Android, Wave, etc).

Mobile Web Application Framework of Choice (for me)
Firstly, let me say this was not an easy decision to make, a number of factors contributed to my decision. Based on the evaluation I completed, my experience over the 5 days regarding what could be achieved in each of the frameworks and how, and additionally my understanding of each product’s roadmap moving forwards I will be going with (drum-roll please…): Rhodes. Here’s why:

• Despite not being a Rails user (or avid fan), what was offered through the MVC framework that underpins Rhodes does support the creation of scalable, maintainable cross-platform mobile web applications.
• Titanium provided quite a significant distraction with the access to native controls in their framework, until I sat back and remembered that wasn’t my core focus. Appcelerator are offering mobile cross platform native development, whereas my focus is on mobile cross platform web development. The titanium approach is very appealling right now, but in a couple of years I believe will be less necessary.
• While PhoneGap provides excellent component pieces for bridging a web application to the native capabilities of a device, the Rhodes architecture (once I had the hang of it) offerred a little more.
• Finally, and probably most importantly, I had some conversations with Adam Blum regarding the direction in which they are wanting to take Rhodes and Rhomobile in general. From those conversations, I was able to see some alignment between this application (and future application) goals and their roadmap – which is quite exciting.

Questions? Clarification?
If you have any questions, or if I haven’t provided enough detail on any of the points please feel free to leave a comment below. Additionally, if you are involved with development of either PhoneGap, Rhodes or Titanium and I have missed the mark on anything, please leave a comment below to clarify.

To add an extra layer of complexity I will be doing this using the deCarta Mapping Platform rather than Google Maps, as I’ve had some experience with the deCarta platform in the past and found it to be technically very good.

To get started, here is the rough schedule I have worked out for the week:

Day One and Two – Identify Best Fit for Purpose Cross Platform Toolkit

• High level investigation implementing mapping application in what I believe are the current top three cross-platform mobile frameworks:
  • PhoneGap
  • Appcelelerator
  • Rhomobile

  Basic goal is to have a simple tiling map display implemented using each toolkit. Ideally in the deCarta platform.

• Identify potential barriers for later-stage implementation, and push the boundaries a bit.

Day Three – UI Toolkit Investigation

• Investigate most suitable HTML UI toolkit for implementing a slick UI that behaves itself on both iPhone and Android. Current candidates are:
  • jQTouch
  • iUI

Day Four – Push “Most Promising” Platform
Based on the results of days one to three, push the selected development framework plus supporting mobile web UI (if required – would be of little use in Appcelerator) to try and anticipate future problems that might occur in a cross-platform approach to a mapping application.

Day Five – Compare back against deCarta Native iPhone API
deCarta do have an iPhone API available as a Beta – available from their devzone (registration required). Some comparisons will be done against the general feel of the iPhone native application vs a cross-platform alternative to determine if and where usability is compromised using a cross-platform approach.

I’ll be attempting to post an update of each day / phases results so if you wish to keep up-to-date with progress, please subscribe to the Distractable feed.

This feeling was confirmed for me today when I received an SMS titled “**IMPORTANT MESSAGE**” from my bank saying I need to contact them. While I’m not going to tell you who I bank with (it was one of the big four banks in Australia), I will take you through my experience and attempt to highlight the weak points in the approach, as well as suggest what I think could be done to improve the process.

The Current Customer to Bank Mobile Interaction
First we have the message from the bank highlighting to me there is a problem:

+61427xxxxxx:
**IMPORTANT MESSAGE**
Please call the Foobar Bank
urgently on 1800 xxx xxx
option 1, option 1 quoting
Ref No. 555M. Do not reply
via SMS to this message.

Right, ok. If I received an email like this, there would be a number of checks I should perform to attempt to determine the authenticity of the message. This would probably include at least the following:

• Check that the sender of the message is a recognized source
• Check that the call to action in the message is one that can be verified as valid.

OK, so let’s apply those checks:

Valid Sender Check: Even though I blanked out the sender phone number, I can assure you I did a search on the bank’s website for existence of this number, but could not find it. Admittedly it will be the phone number that is given to the SMS gateway at the bank, which no-one really thinks is important – yet/.

Trusted Call to Action: Applying the same search to the phone number that I was instructed to call, did turn up a reference to it on the bank’s website; however, the document retrieved was a news article that was dated 2002 and a lot can happen in 8 years.

Anyway, feeling wary but somewhat reassured that I had at least found the number on the bank’s website I gave them a call, proceeded through the prompts, waited on hold for a bit, and then finally talked to an operator. After greetings, etc, we got onto the process of identifying the problem and who I am (I’m definitely paraphrasing a bit here).

Problems with Bank’s current approach
Well it feels like stating the obvious, but here’s a quick summary.

• No evidence of the sender number anywhere on the bank’s website. Would it be so bad to put it somewhere on a page appropriately titled to provide some consumer confidence?
• Same with the call to action phone number. While it was on the website, it was in an old news release and I’m sure even banks let 1800 numbers lapse from time to time. Put in on the same page as the sender number.
• I was asked to provide my credit card number as the first piece of information required to validate my identity – surely there are other pieces of information that can be requested to validate this. Maybe ask for my full name to find the account. My address, last four digits on the card, date of birth can probably serve as lightweight validators, and I’m sure something else can provide some trust that I am who I say I am.

Mobile Phishing – Consumer Protection
As a consumer, I would definitely encourage you to check the numbers in the SMS. The way I did this was very simple, and just involves using doing a search in google for the number and telling google to only search one site in particular. The easiest way to do this I find, is supply the site command in the string. For example, if you wanted to find references to phishing on my site (there aren’t many) you would simply enter the search string below into google.

phishing site:.distractable.net

Apply the same technique to your banks website, using the the phone number formatted in a few different ways to see if you can find it. As I previously stated, you should be able to find the number in a current page on the site, and that would ideally be titled something that lets you the consumer know it’s a number that is used in SMS communications.

Closing Remarks
This experience that both businesses and consumers still have quite a bit to learn with regards to phishing (myself included) and while we are taking steps to tackle it in various channels, other channels are applying process that is archaic by comparison. Ironically, the section of the bank that sent the communication and was behind the call to action number was the bank’s “Security” section – honestly, I would expect better from one of Australia’s big four bank’s specialist security areas.

Implementing this stuff isn’t rocket science, and while I’m sure there will be conferences and junkets to discuss the impact of mobile devices on security, a lot can be done right now to improve the situation. Additionally, I’m definitely not a security expert – just a coder who doesn’t like to write apps that can be hackedcracked. If you have alternate views or similar stories, please feel free to comment below. We can probably even play guess the bank if you like

Other Reading

• Sonic Wall have a good phishing quiz which is worth having a look at – I definitely smiled when I hit question 4.
• The Sophos blog has a good article on an actual phishing scam that occurred in Texas.

Great job Amazon. In the past few years the lack of a geographically close (and thus virtually closer) hasn’t worried me too much, but as I am now starting an Australian software development company that provides services in the cloud – it does.

Both smaller companies and larger corporates are starting to consider the cloud for deployment of different types of services. While I certainly don’t expect that core enterprise systems will be deployed to the cloud by large conservative organisations just yet, there is a great deal of potential that can be gained from building certain application or services for cloud deployment.

For small businesses and innovative corporates in the US and Europe using cloud computing has been an option for some quite a few years now. For companies in the Asia Pacific region, however, there are still a few hurdles to overcome before it becomes truly viable. In my opinion for Australian business there are two things that still cause some wariness when it comes to cloud services:

Firstly, there is the network latency to reach their cloud architecture if it is hosted in either the US or Europe. In some cases having hosting in those regions is OK or even an advantage, but when you are primarily developing a service for a local market it really doesn’t make a lot of sense. With Amazon providing EC2 services in Singapore, that goes a long way to helping with latency from Australia and the rest of the region.

Secondly, there is the issue of privacy which from what I understand of the issue relates specifically to “Transborder data flows” in the the National Privacy Principles. Whether this is genuinely an issue from a legal standpoint is not something I can comment on. I can, however, confirm that I have observed that Australian corporates that I have been involved with would prefer to see personal information kept onshore.

Obviously, having the servers in Singapore won’t alleviate privacy concerns if you were to suggest storing customer data in the cloud. Considering alternative approaches for application construction, however, might enable the use of the cloud infrastructure without compromising on the security of data.

Designing applications with that kind of architecture will be something that I’ll be focusing on with Sidelab. With the amount of work that is required in the IT space over the next 10 years, it’s definitely time work smarter at building our applications for scalability, and I believe the cloud has a very important part to play in that.

Updated Response Time Graphs (1 minute Pingdom Check Interval)

Gaelyk Test App Response Times

Lift Test App Response Times

Python Test App Response Times

Python Test App Response Times Variant (1000ms max y-axis)

Reading the Updated Graphs
As you can see, the graphs this time around are presented slightly differently, with separate graphs for Grails, Lift and Python. Additionally, the graphs shown here showing data from Pingdom after setting a request interval of 1 minute as per Sean Gilligan’s suggestion. On each of the graphs, the line colouring is as follows:

• Red: The average response time for the 450 requests sampled
• Orange: The average response time + 2 standard deviations to help detecting the outliers
• Blue: The actual response time for the sample

So, what do the new graphs show us? Firstly, when doing an apples and apples comparison (see below for more information) with Gaelyk and Lift we can see that Gaelyk actually performs a little better. Whether or not this is going to be the case consistently I cannot say – but we can see that the Lift framework tests are producing loading requests more frequently. In reality, I believe this is a variable factor caused by sharding requests to different JVM instances and running the tests again could quite potentially yield different results.

Secondly, the Python response times still kick the pants off the JVM test apps, but please read on as I try to put some context around this statement as this isn’t an in-depth Python vs Java language performance shootout…

Clearing up a few things
Given some of the comments that I saw on Reddit, YCombinator, etc, I guess I should probably clear a few things up (or at least try):

• The original post wasn’t meant to be an in-depth comparison of language performance on Google AppEngine. Sorry if you felt that the title of the post misrepresented the content. The focus of the post was to demonstrate the impact of the “Loading Requests” on AppEngine – sadly titling the post probably wouldn’t have brought the problem to many people’s attention…
• As I point out in one of my comments on the previous post the original post paints Gaelyk in an undeservedly bad light, as I wasn’t really doing an “apples and apples” comparison between Gaelyk and Lift. The lift test site for the previous site was an established site as opposed to a fledgling. This has been rectified in these tests and I am now using a recently created Hello World Lift Testbed. This is particular important to me because…
• I consider both Groovy and the Gaelyk Groovy AppEngine Framework some of the most elegantly executed pieces of coding that I have seen. Basically, I really like both of them, and because of this I would be very happy if I could create scalable web applications on AppEngine using them.
• My definition of a scalable application, means that it performs as well if it is serving 1,000,000+ as it does if it is serving 1. Usually the challenge is catering for the 1,000,000+, however, with the situation here our application does not scale to a smaller number of users. I’m not sure how to get an application to 1,000,000+ users if it doesn’t perform well for a few.
• I don’t think Python is better than any JVM based language. Right now though it does offer faster baseline response times on AppEngine.

Conclusions
Loading requests are still a problem for JVM based sites / applications hosted on AppEngine. The good news is that the ability to reserve a JVM for your application is on the AppEngine Development Roadmap so hopefully we should see it in an upcoming release soon. Additionally, while not encouraged by the AppEngine team using a cron job or external service such as Pingdom to keep your application alive will help minimize the occurrence of loading requests, but you will have to make sure you are polling once a minute as once every 5 just doesn’t cut the mustard.

If, however, you are a Java/Groovy/Scala/etc user and have gotten to the point where you don’t think you can consider AppEngine for deploying your web site / application there are alternatives. One that was suggested to me was Stax which does look pretty good.

As for me, I’m definitely not at that point – I intend on pushing ahead with AppEngine as there aren’t too many cloud platforms that offer scalability to the point that AppEngine does – but that’s a conversation for another time. Additionally, I intend on trying to build a small tool to help keep your AppSpot application “warm” (despite the appengine’s team’s advice).

If you are interested in getting an update on this tool when it’s finished, or would like to keep in touch with AppEngine and other articles, please subscribe to the Distractable feed.

Update 2009-04-29:
I mentioned Stax as an alternative that is available to AppEngine for Cloud deployed Java apps, and it is probably worth noting that while it isn’t yet available, VMforce looks like a really interesting option too.