But it took me quite a while to get Eclipse to recognise jsp properly and luckily I finally found a solution!

http://stackoverflow.com/questions/3112497/jsp-file-not-working-for-google-app-engine-guestbook-tutorial

But that wasn’t all. It’s been a while since I last tinkered with the appengine and all its configurations and i kept getting a 503, service_unavailable error. After an hour of staring at my web.xml file, I noticed I didn’t specify the exact path to my servlet *doh!* Let this be a lesson to all.

That is all for this post – nothing interesting to report but do stay tuned for something exciting soon =)

WindowsKey + #Number
This seems quite good for power users which have to manage huge number of applications simultaneously. What this feature does is it’ll select the #N’th application which is on your taskbar. If the application is already selected, it’ll minimise. If its minimised, it’ll restore it. And if its not selected, it’ll select it and bring it to focus. Nifty =)

So if say, you have Firefox, Chrome and IE on your taskbar (in that order) WKey+1 will open Firefox. WKey+2, and you’ll pull up Chrome. WKey+2 with Chrome selected will minimise it.

How does it manage grouped items I hear you ask…
Pressing WKey+#Number will cycle through the items. Thus, this means the minimise feature doesn’t work for grouped items but such a minor setback (WKey+DownArrow will minimise a selected window)

So go ahead and play with them, it’s a shame such features aren’t really advertised cos I think this is a good feature.

However, my efforts were not completely faultless… Because of the way I structured things (all my demo modules on a single page) and the way channels work (only one channel per page), I clearly needed to either

1. Put the demos on separate pages; or,
2. Have the channel at the top ‘live demo’ page and filter to the relevant module.

I didn’t quite want to have each demo on a separate page, so I opted for option 2. Thus, my Shoutbox and Collaba-Doodle share the same channel token. However, the message which is sent is encoded and interpreted differently based on the ‘msgType’ of the message.

I also set up a basic ChannelListener which can register listeners based on the msgType and then act upon that data. A simple solution which works for now but there’s definately a trade off with this approach

1. We either have to parse the message multiple times in each module and accept or ignore the message; or,
2. Out top level ‘live demo’ page knows exactly about each of its children and what msgType message they expect.

Given my LiveDemo is still quite small, opting for the first option seemed again, the easiest option and required the least amount of work in order to test the power of channels.

Finally I’ve been wondering how to close connections to remove the clientID from our table and it seems windowCloseEvent() solved my problems – called when the user navigates away from the page or the window is closed, we thus send a last message to the server telling it to close the socket and remove the clientID.

And thus the circle is complete – create a socket > send message > recieve updates > close socket. Cool. What next??

So I decided to give it a try, but in order to not break my existing collaba-doodle, I made a shoutbox. If anyone has noticed, I’ve always had the shoutbox on my showcase but it was only a place to vent your spleen into the void of nothing-ness. So to make it useful, I added the channel service to create a real shoutbox which broadcasts to other users.

When the module loads up, I give the user a random ID (it’s not perfectly unique as I’m only using a simple number generator and not checking for collisions) – as we’re only testing proof of concepts with this showcase, not devloping perfect applications. So with that ID, we send it to the server to generate a ‘token’ for the user which acts as the unique socket connection that will be used by the server to communicate with the client. The server logs the ID so it knows to send future messages to them.

I set up the channel on the client side using the gwt-gae-channel library as it makes life much easier than having to fiddle with javascript. Once the connection has been established, the user is free to send messages. When a message is sent, an RPC is invoked to the server with the sender’s ID and the message. The server then looks at its table of established connections and passes the message onto all connected clients. Done. A simple shoutbox (or chatroom, which ever you want to call it).

Now that is done, there’s definately things which can be added like ‘rooms’ as chatting with +100 people would be chaotic [albeit fun]. But after this simple experiment with channels, I can try to incorporate the ideas to my Collaba-Doodle =)

It’s on the showcase now to play around with: ajt HYPHEN showcase DOT appspot DOT com

When playing with my Collaba-Doodle, I’m realising I need something similar for the doodle canvas which can possibly be update by lots of collaborators simultaneously and thus the need for a ‘sharded doodle canvas’ becomes more and more apparent.

I was already using the sharding approach to track how many visitors my showcase was retrieving, so adapting it for a doodle canvas wouldn’t be too difficult. The main problem was that if I wanted to shard even more objects, I’d have go through the process of creating lots of sharded’elements’ copying and pasting lots of code which more or less does the same thing bar a few changes. So I decided to try a more generic approach to sharding – ‘Composite Sharding’  for reasons which will become apparent shortly. (I’m also 90% sure this is not a novel approach but I couldn’t find anything useful on the topic from some searches, so I’m putting it out here)

Many developers are familiar with the composite design pattern, where a parent and its children share the same interface, allowing both objects (from the user’s perspective) to be treated as a single object but behind the scenes, the object handles the delegation to children (if any). I tried to do something similar with my parent shard (ShardedElement) and the children shards (Shard).

So, my ShardedDoodle and DoodleShard would implement some Doodle Interface (IDoodle – not related to ‘the fruit’ products) and have:

• addChanges(ChangesFromUser)
• getChanges(startTimeOfChanges)

We can see, that this composite sharding approach will work as adding changes can occur to a single Doodle shard independantly. When retrieving the changes, we traverse all doodle shards and get the changes from each shard to give us all the relevant changes.

To make my life easier, I templated and abstracted out all the base code for sharding into the three main components:

• ShardedElement<T extends Shard>: abstract class, handles storing and retriving of shards. Subclasses should extend and implement an ElementInterface.
• ShardCounter: class which handles book-keeping of shards matching the ShardElement name. This object is internal to a shardedElement and is never exposed.
• Shard: abstract class which handles storing and retriving of data from the datastore. Subclasses should extend and implement an ElementInterface.

In my Doodle Canvas example above:

• DoodleShard extends Shard implements IDoodle
• ShardedDoodle extends ShardedElement<DoodleShard> implements IDoodle

And that’s really all there is to it. Because most of the grunt work is handled by the ShardedElement we can simple get a random shard via getShard() and do PUT operations on it or we can get all the shards getShards() and do GET operations on them.

I’m looking forward to seeing how well this works in other scenarios besides counting and my doodle canvas… maybe I’ll try the guestbook =P

I’ll put the code up for this at one point in time…

Anyway digressing from the main point, I remember playing around with a flash-based web application a few years ago which acted like a fridge magnet board – it had numerous objects ‘stuck’ to it and could be manipulated by anyone who joined. It was really fun (despite the some what unusually high volume of people trying to write ‘male genitalia’ on it – you get the picture).

So I thought to myself, how about I try to push it one step further and have a collaborative white board where all the user has are the white board markers. Essentially, giving them an empty canvas to doodle random things on. And thus spawned ‘Collaba-doodle’ a (HTML5) canvas where anyone with access to the board can write something on it.

The currently prototyped version is on my showcase for all to play around with. However, it has the following features (for now):

Anyway, you get the picture.. there’s limitations with it now as its a simple proof of concept. And, despite being limited in functionality it is actually quite fun to play around with. I wonder what interesting images will come out of it – perhaps I should also add a gallery for this?…

As mentioned very briefly, I’m trying this new HTML5 canvas and luckily, GWT provides us with a canvas component to use =) This makes life much MUCH easier – Construct the canvas object, test to see if it exists (if it doesn’t, the browser doesn’t support HTML5 canvas yet). Then, we need to get a Context2D object (akin to the Java Graphics2D object). It is thought this Context2D object that we perform all out ‘fillRect’, ‘fillArc’ etc… methods to actually draw stuff on the canvas – all fairly trivial.

Behind the scenes we simply keep a log of the user’s current ‘pen stroke’ (what they are drawing with a single click). These get sent to the server and added to the main canvas object (preference given to the later strokes – obviously). Periodically, the server returns a list of strokes which have been written to the main canvas object since the last update and applies the changes to the user’s canvas. Simple enough? A crude and naive solution but one which tests proof of concept – Collaba-Doodle =)

Now… not sure what to tinker around with next or whether I should try to further optimise the Collaba-Doodle… Whatever it is, there are plenty of things to try and it is clear that GAE+GWT is a solution ftw.

Add [uname]-test AT 3 DOT latest DOT [uname]-test DOT appspot DOT com to any XMPP complient client (such as gtalk) to see the baby in action =)

My eventual long term life goal is to have a chatbot capable of conversing appropriately with humans. Note: I am NOT trying to make a chatbot which is as intelligent as a human (nor attempt to pass the turing test/Loebner prize), just one which can converse purely for entertainment/killing time. Similar to the ‘cleverbot‘ which rides on the net – do check it out though its quite fun to play around with XD

Another thing I’ve been playing around with is the Google Maps and Spreadsheet API. If anything the Spreadsheet API seems quite powerful and can be a lightweight (in terms of infrastructure cost) alternative to an actual database storage solution. I’ve managed to play around with some of the map and spreadsheet examples and developed my first javascript ‘web application’ which loads a bunch of locations from a spreadsheet and place them on a map. Nothing overly exciting or ground-breaking and it was meerly the result of piecing together the various pieces floating around. ajt-showcase DOT appspot DOT com is where the example resides.

On that note, time to do a plug for that spot =P That my friends is where I shall be showcasing various ideas and projects – a type of portfolio page. I figured it would be good to finally show off some of the things I’ve done. The page is by no means complete and things will be slowly added to it over time =)

With the recent influx of free time, I figured it would be best to learn and hone some new skills and dive into the world of app/web development. Obviously I’m using the term ‘app’ slightly differently to the round white fruit’s naming of an application on their magical phones or slate. Anyway, GAE I’ve found makes it very easy to create and deploy apps using their infrastructure and GWT helps build those apps using various widgets like buttons and input fields to create a desktop-like browser application.

Not sure what all that is about? Well, its not hard to notice that in the last few years, the web has transitioned very quickly into what is known as Web 2.0 with the introduction of AJAX . Go to almost any website and you’ll see that any action you perform now occurs immediately and doesn’t require the entire web page to refresh (as it once did traditionally). Even this blog I’m writing on allows me to move various windows about all seamlessly – it really is quite amazing.

Ok, enough ranting. The main reason for wanting to explore these solutions by Google is that I’ve been fortunate enough to play around with a lesser known tool known as Morfik. Possibly a pre-cursor to the Web2.0 model, Morfik was simple enough to use and developing web applications was almost akin to developing traditional desktop solutions. It was quite amazing what these guys have pulled off. Seemingly a few years later, GWT was announced but the push for it has not been as strong (possibly due to patent issues?).

Anyway, after installing the AppEngine and GWT SDK plug-ins for Eclipse, I moved onto playing around with the sample applications given. Click the magical run (or debug) button, and it’ll create a local instance of your app which you can point your browser to to see how your app will look and execute when it is actually deployed. This is very useful given the deployment times can range depending on the size of your application.

Moving on, I wanted to learn a bit more than just running the sample application. I stumbled across these tutorials, albeit slightly dated the main concepts were still relevant and split up into a nice 3 part tutorial for people with attention spans of a goldfish. Google’s StockWatcher tutorial is also a good place to start =)

Once I was happy testing my applications locally, obviously the next step was to deploy the application and show it off to my friends (who wouldn’t want to?). Using the Eclipse plugin certainly makes things easy: A simple click of a button and entering of user settings (such as application name and location) and the app begins to travel across the wire. Once complete, the app is available instantly to you for you to interact with and pass around to everyone – very cool indeed =)

One things I like about the deployment is that you can deploy different versions of your application and decide which one you want to be executing as the default. Useful for wanting to try out new versions without affecting the stable. Alternatively, I’ve decided to have a test location and deploy different apps as ‘different versions’ so I can essentially have multiple applications running under the same domain, though a prefix identifier is necessary to navigate to the specific one, for testing I don’t really care.

Currently I’m play around with the various services available such as messaging (email and chat) as well as standard web app serving. Most of these can be found at ‘[uname]-test ^ appspot * com‘ where uname is the same as this blog’s. The content serving from there is obviously volatile and will change at any time and simply serves as a place for me to test random things.

For now I’ll leave it there cos the blog post is getting to long which means less people will be bothered to read it. More progress updates to ensue! In the future I’ll try keep the word count to less than 500 (excluding notes)

*Yes, I know its bad to reference wikipedia but seriously, its a good source of information and the vast majority of people will trust it over a random page I’ve found.

Get it here from EpicWar
http://www.epicwar.com/maps/129210/

‘Why is it not version 1.0 or 0.1, or some smarter starting number?’ you may ask yourself. The reason is that internally I’m keeping tabs on version numbers and that just happened to be the version number I was currently up to which seemed relatively playable and able to be distributed.

The release is more of a stress test for any potential player scaling problems, cos I’ve never actually had the chance to test is with the full 8 players =P

Anyway, go grab it and any suggestions, ideas or general feedback is hugely appreciated ^^ Hopefully I’ll be able to keep maintaining it (I’d actually like to clean up some of the trigger logics and clean up potential memory leaks at some stage)

[Edit: As of 27-04-10 we've hit 1762 downloads ^^ I think that's alright for a first map wouldn't you say? I've added a slightly boring minimap preview image]

[Edit: Looking back a year, as of today (03-05-11) we have 2723 downloads - cool! I'm thinking I should move it into StarCraft II though]

Minimap preview

The first project was a version of pong where the paddles could be controlled by the user via some coloured objects. This turned out fairly well after a few hours of tinkering and getting a feel for pygame’s camera and mask modules.

Just a quick run through of how it all works is probably appropriate here:

1. Get the colours of the two objects which will be used to control the paddles – On screen, are two boxes which show where the paddles will start. The user places their COLOURED object of choice in each box. Once satisfied, the user registers these colours and proceeds to playing the game. Registration occurs by taking the average colour of the pixels within the paddle. This roughly corresponds to the colour of our object

2. Moving the coloured object up and down (close to where the corresponding paddle is) affects the paddle.We detect this object through colour blobing – finding pixels of similar (to some threshold) colour and then connecting them (pygame has a mask module for this which makes it slightly easier).

Some minor tweaks were used to make the paddles move as smooth as possible:

• When searching for the colour, we pick the blob which is closest to the previous location of the paddle, as this prevents the paddle from jumping up and down from background noise. Also, more often than not, the user is moving the paddle gradually anyway.
• We only search the left and right quarters of the screen for our colour to eliminate junk in the middle. The player should be moving their object as close to their paddles as possible
• A minimum blob size is required and thus, the user either needs a big object or has to play fairly close to the camera. Noise elimination was the reasoning for this choice.

And for those interested in playing around with it, I’ll upload the source a bit later in the week =)

Edit: Source code and game (Note: Requires at least python 2.5 and pygame 1.9)