Flash done right and on Google App Engine

Often I criticize the usage of Flash for content centric pages, because often Flash is implemented in a way it causes a disastrous user experience (from arbitrarily resizing browser to sound which you can't turn off and fonts which you can't resize, just to mention the worst mistakes). Now I came across a new project, which advocates to do Flash the right way: gaeswf by Aral Balkan, a client and server side open source framework, based on a collection of best practices for using Flash on Google App Engine, in a way that Flash does NOT suck. The proof-of concept (live demo) implements techniques such as:

• Embedding Flash with SwfObject
• Deep linking (based on SwfAddress)
• Flash content that obeys browser text-size changes

Google App Engine Team fixing issues quickly

Toying around a bit today on Google App Engine, I found a minor issue (not security related, very easy to work around and only affecting Mac users) in an add-on for the actual SDK. Only 32 minutes after I reported the issue they had fixed it !

Amazon announced persistent storage for EC2

If Google App Engine does not provide enough flexibility for you, then there is some good news from Amazon: one of the missing pieces, persistent storage for EC2, has just been announced.

Exploring some lesser known Ajax GUI toolkits

I have only been exposed so far to Dojo and ExtJS, and I believe both are bleeding edge technology, provide a great user experience and are widely accepted. But there are about 50 more Ajax GUI toolkits out there. And some of them occasionally appear on my Google Ads, so out of curiosity I took a quick look at some randomly chosen ones:

• SmartClient Ajax GUI System: Lots of widgets, but they are all table based and look desktop-like, that makes it a very Web 1.0 experience.
• Icefaces: An Ajax GUI toolkit for integration into J2EE systems. Also lots of widgtes, looks a bit less desktop-like, but here as well I see tables (e.g. their tab container) where I think pure DIVs and a bit more CSS provide a better user experience (smother loading). I am not a J2EE guy (anymore), so I did not look closer at this product.
• Nitobi: Their website looks nice and well organized, so I head high expectations. But I switch randomly between browsers and at the time I tried the Nitobi demos, I was using Safari 3,1. Unfortunately I could not load the demo (then I tried on Firefox and there everything worked fine and looked good). But then came the ugly part: They provide a free trial version with a 30 day evaluation period and beyond that you are expected to buy a license, prices start at $ 429 US and go up to $ 3699 for the enterprise version !!!
• Telerik RadControls for ASP.NET: Even more expensive: prices start at $ 799 US. And you have to register on their site just to download the trial version. At least I could load the online demo, even on Safari. And it looks good, very good, nearly as good as ExtJS.

Lesson learned: there is a reason these Ajax GUI toolkits are lesser known !

Scaling down - the least talked about feature of GAE

It launched less than a week ago and now all over the blogosphere people are discussing the Google App Engine (GAE). Most talk is about scaling up, about potential lock-ins, even if the SDK is based on open source software. Only one thing where developers seem generally to agree: with Python, Google has made a good choice (maybe those not knowing Python yet but desperately looking forward to learn it, don't know that Python dictates line indention, actually the only thing I had difficulty to get used to). That is interesting by itself, because developers usually are highly opinionated in regard to programming languages. Or is it just the early adapter mentality which is more flexible ? Anyway - in this article I want to talk about something I haven't found mentioned yet at 100 other places:

scaling down

I see a growing number of businesses reducing or eliminating their IT department by using Google Apps (gmail & Co. on custom domain) for e-mail and other standard tasks covered by the Google Apps suite. Custom built applications for streamlining their non-standard, probably also simple but business specific work-flow has been beyond the budget of small organizations. So they used the available standard tools, which are often more complex than necessary for those tasks. But now the creation and especially the maintenance of custom built web applications is getting cheaper with GAE, because problems like authentication, deployment, high availability and even data redundancy (as probably-good-enough backup-strategy) are solved already and the cost for hosting gets completely eliminated (scaling down means just few concurrent users per application, little resource usage and the app will probably stay within the quotas for free usage of GAE). So the saved money from traditional in-house or outsourced IT administration, spent on development of custom applications will allow organization to improve their efficiency. And Google of course still will make good money with this scenario, because some companies will choose Google Apps Premier Edition over free/limited edition and will pay Google 50 $ per user account / per year.

Google App Engine - Niall Kennedy's summary

Great summary about the Google App engine, by Niall Kennedy. He even provides some insights about the people behind it, and according to his first hand knowledge, this is just the beginning of what Google is rolling out:

I met with the App Engine's team leads on Monday morning for an in-depth overview of the product, its features, and its limitations. Google has been working on the Google App Engine since at least March 2006 and has only just begun revealing some of its features.

Erlang R12B-2 released - with native PNG drawing

It's a bugfix release and I had no big expectations when scanning through the release notes, but then I spotted this:

--- percept-0.7 ------------------------------------------------------------

OTP-7162  Percept no longer depends on external c-libraries. The
    graphical rendering is now done via erlang code.

Thats huge, if you are interested in generating PNG images and don't wanna have dependencies on c-libraries (as you would have using my cairo wrapper erlycairo). Egd won't win any speed competition and has a limited feature set, but runs out of the box on any Erlang supported platform !

Google App Engine - Quotes and thougts

From the many blog posts about the Google App Engine, my favorite quote comes from Dave Winer:

Now, what Google announced is really exciting! I'm not kidding. It's even better than I hoped. Yes, it's only Python, but IBM's PC-DOS was only BASIC and Pascal when it first came out, and it didn't matter. Yeah, I preferred C, but I coded in Pascal because that's what you had to do to get an app running. What you're going to see here that you've never seen before is shrinkwrap net apps that scale that can be deployed by civillians. That's a mouthful, but that's what's coming. Why? Because here is a standardized platform that can be stamped out in the billions of units. Maybe Google can't do it, but the perception is that they can. Who is willing to stand up and say Google hasn't nailed scaling? What PCs did in the 80s, Google is doing now. PCs took the black magic out of owning a computer. Now Google is taking the black magic out of operating a scalable web app. Python is the new BASIC.

There were also lots of negative thoughts, e.g. Donna Bogatin:

Google’s latest attempt at Internet shock and awe replays the by now traditional Google routine of “giving away” Web services under the guise of disinterested benevolence while the Web cheers the supposed Googley revolutionary Internet disruption and forecasts doom for existing players, such as Amazon, for this example.
In typical Google fashion, though, “free” comes at a very high price. In fact, the Google App Engine product unveiled by the high-flying corporation is in contention for the scariest Google move to date.
Not only do startups using Google App Engine unwittingly put control of their businesses in the sole discretionary hands of Eric Schmidt and company, unwitting consumer users of Google App Engine hosted services automatically “share” all of their personal, proprietary data with Google, whether they really want to or not.

Generally people are comparing the App Engine with Amazon's AWS offerings and either seem to be interested in the one or the other. I think these two services can be combined for easy creating scalable web applications which go beyond what you can do with a limited amount of time and money, compared to the scenario where you would use just one of the services. Let me elaborate: For the simple, stateless stuff, for static and dynamic HTML pages and for persisting data, Google App Engine is perfect. For advanced stuff like Comet HTTP push, video streaming or batch processing, Amazon EC2 instances could be used on demand just for that.

Trying out Google App Engine

Yesterday night Google launched App Engine, a highly scalable web application platform, which has the potential to become a game changer. I was lucky to grab a developer account, which is currently tied to several limitations:

• only 10000 developer accounts available
• applications have to be coded in Python
• only three applications per developer
• bandwidth, storage and CPU usage limitations
• no road map, no info about future pricing model
  

On the other hand, it's free for now, you can use the Django open source web framework and template language, you can locally develop and test your app with the cross platform Google App Engine SDK (download size only 2.3 MB - on Mac OS X), you get a powerful administration interface at your Google account and most important, it is extremely easy to get started with, in no time you have a schema-less, database driven helloworld web application deployed on Google's server farm.

The internet users may start their own home business by having business deals with the global entrepreneurs. The different brands of computers have been manufacturing the latest and stylish models of different sizes and shapes for the computing clients. The main features of hosting plans of godaddy are reputable among the potential customers. You may get hosting services of high quality in affordable rates by joining powweb, reliable web host.

Skype and PostgreSQL database

PostgreSQL is my favorite open source relational database. Some time ago I wrote some experimental code (currently unmaintained) for integrating it with erlyweb. The guys at Skype seem to like PostgreSQL as well. In regard to the current Google Skype takeover rumors (or was it just a 1st of April joke which went out of control ?) and to this article: Skype Plans for PostgreSQL to Scale to 1 Billion Users, I took a look at the Skype open source projects and found a few interesting ones related to PostgreSQL:

• PL/Proxy: Horizontal data partitioning, based on a hashed database field (for distributing large amount of data among several physical servers).
• SkyTools: DB cluster management software for replication, message queues, fail over and Python integration.
• PgBouncer: connection pooling.
  

The most advanced features of backup software are very assistive for exclusive disaster recovery of data. The web site design services are also the main part of some hosting plans of the service providers. The benefits of affiliate marketing have been attracting a number of investors and entrepreneurs of this global business community rapidly. The webmaster is responsible for administering all web applications expertly.

Easy git on Emacs with emacs-git

I have been using emacs-git for the last few days and and it proved incredible useful. It let's you do interactively most of the basic git operations such as creating, cloning or importing a repository, it inidcates graphically the git status of the current file with a colored LED-like icon at the Emacs bottom status line and it also facilitates adding / removing files to the repo, ignoring files, tagging, merging and conflict resolution.
Emacs-git works only on Emacs (and not on X Emacs) and requires a very recent version of Emacs (I am using it on a nightly build of aquamacs, which is based on Emacs from CVS).

Emacs on Ajax with Steve Yegge's new js2-mode

Steve Yegge just released a new Javascript Emacs mode. I installed it and played around a bit and syntax highlighting and indention seemed to work perfectly. The feature list is impressive (copy-pasted from project page):

• it offers the usual features from other Emacs modes
• it supports the JavaScript language up through version 1.7
• it has a real recursive-descent parser
• it highlights syntax errors and underlines warnings
• it supports collapsing function-body and block-comment definitions
• it has some preliminary support for IMenu (to be improved soon)
• it knows about jsdoc and highlights tags in jsdoc comments
• it has a set of typing helpers to make editing easier

The best news comes now: according to his blog, this is just the beginning:

This is part of a larger project, in progress, to permit writing Emacs extensions in JavaScript instead of Emacs-Lisp. Lest ye judge: hey, some people swing that way. The larger project is well underway, but probably won't be out until late summer or early fall.

My new editing mode is called js2-mode, because eventually I plan to support JavaScript 2, also known as ECMAScript Edition 4. Currently, however, it only supports up through JavaScript 1.7, so the name is something of a misnomer for now.

Plenty of reason to switch back to Emacs for those like me who thought that TextMate was the future.

The Power of Javascript - by Glenn Vanderburg

Wanna listen to an in-depth introduction to Javascript, not just the technical but also the historical side ? Then this talk by Glenn Vanderburg recorded at JAOO 2007 is the right choice (direct link to the media - flash .flv video).

The talk mentions Douglas Crockford's famous article: The World's Most Misunderstood Programming Language from 2001. Just for completeness, here is Crockford's recent follow-up article: The World's Most Misunderstood Programming Language Has Become the World's Most Popular Programming Language.

What sucks most about the Mac

.. are those nearly weekly software updates which require a reboot. I didn't buy a Mac because I was influenced by those all-day-long digging mac fanboys, I bought it because I wanted to run some graphics and video editing software which is not available for Ubuntu Linux (my previous desktop system, from windows I stay away as far as possible) and for paying about twice the price compared to a similar Dell or noname hardware configuration capable of running Linux, I really expected a better user experience in every possible aspect, as promised in their glorified advertisement. But the requirement to reboot the machine for those nearly weekly minor updates really puts the Mac back into the stone age of computing !

Doloto - Javascript Rewriting paper by Microsoft

I just read the reseach paper (pdf) about Doloto a Microsoft project for speeding up Web 2.0 applications by serverside Javascript static code analysis, AST transformations and code splitting. They claim that with this technique the loading time of monolithic (all Javascript loaded at once) Ajax applications can be significantly reduced. In my opinion, a better approach is to build right away non-monolithic apps (Javascript libraries like dojo provide support for that).

Crary - A new Erlang lightweight web server

Beside of featherlight iserve and battle proved mochiweb (at MochiMedia), there is now an additional choice for lightweight Erlang HTTP servers: Crary, which shares similar design goals but provides a different interface. According to its author Scott Parish:

Crary, a HTTP server for the REST of us.

The intention is that its small enough and flexible enough to be used for most any HTTP server need. While it isn't a stand-alone system, nor does it have its own web-framework, these things can easily be built on top of crary. Crary should be easily embedded into the release of a larger application to provide a web interface or to create a web service interface.

Below a tiny little snippet illustrating how to write a hello world program with crary:

start() ->
crary:start(8080, {?MODULE, handler, []}).

handler(#crary_req{method = "GET", uri = #uri{path = "/favicon.ico"}} = Req) -> 
crary_dir_listing:write_file(Req, filename:join([my_doc_root(), "favicon.ico"]));                                                                 
handler(#crary_req{method = "GET", uri = #uri{path = "/test"}} = Req) -> 
crary:r(Req, ok, [{"content-type", "text/html"}], <<"hello world">);
handler(#crary_req{method = "GET"} = Req) -> 
crary:not_found(Req);
handler(Req) -> 
crary:not_implemented(Req).

To get your copy of crary just clone it from its git repository, or install it via erlware.

New YouTube player - Nice, but still not ready for HD screencasts

Geoff Stern, the Google guy who recently rewrote the YouTube player, just posted an interesting demo, mashing up the video player with the Google maps API, demonstrating the new player's Javascript integration capabilities.

Other examples out there:

• Chromeless player with Javascript user interface
• Chromeless drag & drop player

This brings new possibilities for screencasts (or video presentations / podcasts), for syncing the audio/video with text caption or any HTML content along the audio/video timeline. Now I am just waiting for YouTube not destroying anymore the HD quality of uploaded quicktime videos when they convert it to flash (requiring cumbersome hacks like this for online HD flash video), so that YouTube can eventually be used for high quality screencasts and video enabled online presentations.

Update: more chromeless players:

• ExtJS-styled

Erlang processes benchmarked against threads of other languages

We all know that the result of benchmarks are only significant for that specific piece of code which is getting tested, and usually the benchmark authors favorite products are tuned to outperform its competitors. Nevertheless, below a summary of a benchmark recently discussed on reddit. The benchmark itself is just a few lines of source code (at least in Erlang), spawning a bunch of processes and doing some simple message passing between those processes. Thread implementations in other languages:

• C (pthread - GNU gcc): 8.5 times slower
• Python: 15 x slower, 1.4 x more memory
• Java: 20 x slower, 5.8 x more memory
• Ruby: 282 x slower, 3.4 x more memory

More numbers, details and the benchmark source code in all the different languages at the language shootout site.

The gBrowser is coming - disguised as Google Gears

At least this is the impression I get when I take a look at the Google Gears developer documentation , especially the wiki pages with label DesignDoc and the discussions in the contributor mailing list. Here a few examples to illustrate what I am talking about and what will hopefully soon come to any browser near you:

• AudioAPI: Playback, Recording, Mixing and Editing of WAV, OGG and MP3 audio.
  
• LocationAPI: Provides geolocation.
• ImageManipulationAPI: mentioned in the BlobApi description.
• OpenGL vector drawing: discussed in this thread.

Upgrading existing browsers with Javascript APIs providing HTML5-compliant functionality is much better for a healthy, accessible, easy indexable and open standards oriented near future of the web, than relying on proprietary plugins such as the flashplayer for specific functions which can' t be provided by HTML/CSS/Javascript of todays browsers.

Podcast: Joe Armstrong on Erlang

I am currently listening to this Podcast by Joe Armstrong, creator of Erlang. It's a great overview and has lots of historic and other background information.
In case you are new to Erlang, and need something more entertaining and haven't seen yet the classic, "Monty Python" Erlang video, you must see it !