I can access T-Mobile UK WiFi HotSpots with my T-Mobile Mobile Broadband account (I have a 3G USB stick) but I find the signing in process rather painful. It goes something like this:

I have to remember my phone number (I never call my USB Stick so I've never memorized it) and type in my crazy long password (which I have, apparently memorized). This means that I bring up dashboard, copy my phone number from a sticky note, paste it into the form and then type my password and remember to tick the checkbox so that I agree to T-Mobile's terms and conditions for the millionth time.

Needless to say, this gets old fast.

So, I took a little time out and built a little AIR app to automate the process. You can install it using the AIR badge (works on Mac, Windows, and Linux), above, and you can see it in action in the screencast below.

I hope someone else out there finds it useful and T-Mobile, if you're listening, get in touch with me at aral@aralbalkan.com if you'd me to make an app like this for you guys.

Update: Exactly 11 minutes after I tweeted about this, Nate Beck from T-Mobile US contacted me and, before the night is over, the app is getting prepped for an internal demo at T-Mobile US next week.

Moral of the story? Never underestimate the power of the Twitternets or the importance of apps, even simple ones, that improve user experience. :)

I just whipped up an AIR app that should make it easier for people who don't have a Turkish keyboard but need to occasionally type in Turkish to use Turkish characters. Yes, it's a niche app :)

The reason I made it? In 140 characters from earlier tonight:

Emailed my mom in Turkish & apparently wrote "I don't fuck myself" instead of "I don't stress myself out" by not using Turkish characters.

(Sorry, mom!)

After my tweet, Alper Çuğun tweeted:

@aral Ouch! Any clue where to put those couple rarely used characters for easy access? Character palette doesn't really cut it.

And that gave me the idea for the app! A few hours later (mostly spent on prettying it up and packaging it up), I give you the nichest app ever! :)

To use TurkishCharactersAIR, either click the buttons or simply switch to the app and type the closest corresponding Latin character to the one you want and the Turkish version will be copied to the system's clipboard.

Note: It's late and I've only tested this on OS X. Please let me know if you test it on Windows or Linux.

Shoutouts to:

• Graviti for his awesome AIR Custom Chrome.
• Nahuel Foronda for his beautiful Brownie AIR theme and to ScaleNine for being the catalyst for such themes to be created.
• Peter Elst for his excellent AIR Badge WordPress plugin and to Grant Skinner for making the original custom install badge for AIR (by the way, the dimensions of the image for the badge are 205x170 — didn't see that stated anywhere!)

I'm happy to announce that there's quite an important update to Gaebar that brings with it some essential bug fixes and should help shave quite a bit of time off of your restores.

I've also created a new project called gaebar-gaed-skeleton on GitHub that gives you an empty Google App Engine Django (Helper) project with Gaebar pre-installed to start you off when creating your own applications.

Here's a list of changes in Beta 2:

• Fixed: All required properties, including references should work correctly now. Required properties would raise an exception during the restore process in Beta 1.
• Refactored: We are no longer using actual entity references (which was unnecessary) but keys to create reference properties. This means that creation order of references doesn’t matter any more (thanks to Pete Koomen who explained all this to me in an email ages ago; it only just sunk in, Pete!)
• New feature: Due to above changes, the restore process is now one-pass, not two. This means that restores should now take considerably less time.
• Refactored: I moved the functional tests out to their own GitHub module since they were being shared by both the gaebar-gaed and gaebar-aep test apps. This will make maintaining them much easier.

I want to thank Jonathan Ricketson for alerting me in the comments earlier today that the Beta 1 release was not handling required properties correctly (thanks, Jonathan). I also want to thank Thomas Bohmbach, Jr. for providing feedback and helping me test.

You can download Gaebar Beta 2 and the other Gaebar projects from my GitHub account.

If you'd like to learn more about Gaebar, please see my original announcement, which contains a screencast showing Gaebar (albeit Beta 1) in use.

As always, I value your bug reports, comments, and suggestions so please feel free to leave a comment and let me know of your experiences with Gaebar.

Update: Beta 2 Released! See the Gaebar Beta 2 announcement.

Here's my Christmas present for the Google App Engine community: Google App Engine Backup and Restore (or Gaebar, for short).

Gaebar is an easy-to-use, standalone Django application that you can plug in to your existing Google App Engine Django or app-engine-patch-based Django applications on Google App Engine to give them datastore backup and restore functionality.

For a quick overview of Gaebar, watch the screencast, above. For the impatient, links to the project pages where you can download Gaebar follow.

Downloads

Gaebar is hosted on GitHub. You can either download archives or clone the repository (or install Gaebar as a git submodule) via git. Alongside the Gaebar project itself are two sample applications — one built on Google App Engine Django and the other on app-engine-patch — that contain the Gaebar functional test suite. The functional test suite tests every datatype supported by Google App Engine as well as references, Expandos, and ancestor relationships.

Please make sure you read the readme files after downloading the projects for installation and usage instructions.

• Gaebar: http://github.com/aral/gaebar/tree/master
• Gaebar-gaed: http://github.com/aral/gaebar-gaed/tree/master
• Gaebar-aep: http://github.com/aral/gaebar-aep/tree/master

What you can do with Gaebar

• Backup your deployment application's datastore for safekeeping.
• Restore that backup on your local development server for testing with real data during development.
• Restore that backup to a different Google App Engine application and use that application as a staging application much in the same way you would use a staging server in traditional development.

(You can, of course, also backup and restore your local development datastore as well as your staging application, etc.)

I've got a huge datastore, will Gaebar work for me?

Congratulations on the impressive size of your datastore! The answer should be "yes!" The largest datastore I've tested it with is the <head> web conference datastore. The latest backup had 18, 969 rows from 14 models backed up into 225 code shards.

What's a staging application?

A staging application is a new Google App Engine concept made possible by Gaebar. Basically, if your application is myapp.appspot.com, you can use a separate application (say, myapp-staging.appspot.com) in the same way as you would use a staging server in traditional development.

Your staging application can let you try out new features and test with real data without having your users see your changes until you are ready to deploy to your main application.

In fact, it's a perfect staging environment since it is identical to your deployment environment. For an example of this, see the screencast.

How Gaebar works

Gaebar backs up the data in your datastore to Python code. It restores your data by running the generated Python code.

Since a backup is a long running process, and since Google App Engine doesn't support long-running processes, Gaebar fakes a long running process by breaking up the backup and restore processes into bite-sized chunks and repeatedly hitting the server via Ajax calls.

By default, Gaebar backs up 5 rows at a time to avoid the short term CPU and 10-second call duration quotas and splits the generated code into code shards of approx. 300KB to avoid the 1MB limit on objects. You can change these defaults in the views.py file if your app has higher quotas and you want faster backups and restores.

Once a backup of a remote server is complete, Gaebar automatically hits your local development server. From there on, the local development server makes a series of calls to the remote server to download the backup files (code shards) from the remote server. Once the backup is complete, you will see a new backup folder in gaebar/backups with the contents of your backup.

Here's an example of some generated backup code from the Google App Engine Django test application (updated for the upcoming Beta 2 release):

import pickle
from google.appengine.api.datastore import datastore_types
from app1.models import *
from app2.models import *
 
def row_0(app_name):
	existing_entity = Profile.get(datastore_types.Key.from_path('Profile', 1, _app=app_name))
	if existing_entity:
		existing_entity.delete()
	profile_0 = Profile(key_name="id1", friends = pickle.loads('(lp0\n.'), in_relationship_with = pickle.loads('N.'), full_name = pickle.loads('VPaul Booth\np0\n.'))
	profile_0.put()
 
def row_1(app_name):
	existing_entity = Profile.get(datastore_types.Key.from_path('Profile', 2, _app=app_name))
	if existing_entity:
		existing_entity.delete()
	profile_1 = Profile(key_name="id2", full_name = pickle.loads('VAral Balkan\np0\n.'), friends = [datastore_types.Key.from_path('Profile', u'stephalicious', _app=app_name), datastore_types.Key.from_path('Profile', 'id1', _app=app_name)], in_relationship_with = datastore_types.Key.from_path('Profile', u'stephalicious', _app=app_name))
	profile_1.put()

To restore, you simply deploy your application, along with the backup folder, to your deployment environment and hit the Restore button in Gaebar. (If you have a large datastore both the backup and restore processes will take a long time, especially when restoring to a local development server.)

The restore process simply calls each of the generated row functions and each row function restores a single row into the datastore.

A note on the screencast

When mentioning how to install Gaebar, I left out that you also need to add the URL mapping for Gaebar to your application's urls.py. That, along with the rest of the installation instructions are in the readme.txt file, which I highly recommend that you peruse.

Have your say!

As in all things, my approach to blog posts is that they should evolve over time and your feedback is invaluable in achieving this by helping me fix factual errors, fill in details, and expand the original post.

What do you think of Gaebar? Have you run into any issues that need fixing? Do you have other suggestions on how to improve it? Or do you, perhaps, have a patch to send me that adds Webapp support or some other feature? Leave me a comment and let me know!

Gaebar is a Naklab™ production released under GNU GPL v3 and sponsored by the <head> web conference.

All changes in this version are server-side:

• All requests apart from those to the PyAMF gateway go through the IndexHandler class. The app.yaml file no longer maps /examples/.* URLs to the various example SWF applications. In other words, the SWF apps are simply handler classes now, not separate WSGI applications. The PyAMF gateway remains a separate WSGI application.
• Pulled out the server-side deep linking code from the initial example to a new BaseSWFHandler class in the new gaeswf package. The handlers for all SWF examples will extend this class and call the handleDeepLink() method to have regular deep links automatically converted to SWFAddress deep links.
• Removed the unnecessary examples and initial packages and placed all examples in the root of the examples package.
• Added 404 handling. Unknown URLs no longer fail silently.
• main.html template is now known as base.html.
• Added simple.html template for handlers that want to use base.html without the need for a separate template that extends it.

Enjoy!

Update: I've updated the online version to 1.23 to change the 404 photo. I realized this morning that the original Creative Commons-licensed photo I had found on Flickr did not belong to the user who had published it on their account.)

A quick list of changes:

• Pulled out BaseView and BaseApplication classes.
• Simplified service calls. You no longer have to use Service.call() and pass a reference to the view instance. Just use execute("service.method", arg1, arg2, ...).
• Fixed a bug where the app was remembering the initial deep link on logout. Logouts now take you to the root of your Flash app.

The big change is that I've pulled out base application functionality so that your Application class now only contains logic specific to your particular application and not to GAE SWF applications in general.

Check out The GAE SWF Project on appspot.