After the utterly disappointing final episode of Lost I promised to never again waste time on stupid TV series. Then, a good friend of mine pointed me to IT Crowd, a hilarious parody of the 'impedance mismatch' between geeks and their managers. Without further ado, let me introduce you with a short video:
Oh, and don't forget to check this out! Feels like Deja Vu, right?
AppengineJS is a port of the App Engine Python SDK to JavaScript. While we have taken great pains to closely emulate the Python APIs, given the fact that AppengineJS is actually powered by the App Engine Java SDK, it is difficult to emulate the directory structure of Python Web applications. The developer has to maintain a standard Servlet directory organization, with WEB-INF, web.xml, etc. That's a show-stopper for complexity-averse developers.
Not any more! The latest version of the Java SDK (1.3.5) introduces undocumented support for app.yaml, cron.yaml and the rest of the Python's SDK configuration files. The dev_appserver utility, automatically generates and maintains the WEB-INF directory from these configuration files, making simplified file organizations a reality.
I have updated the standard AppengineJS examples (appengine-example and appengine-blog-example) to demonstrate what is possible with app.yaml. I am sure you will find the updated examples much easier to understand. More information about app.yaml in the Java SDK can be found here.
During the initialization of a Web application, Nitro performs a scan of the src/root directory and constructs a sitemap. The Path middleware leverages this structure to intelligently split incoming request paths to the corresponding scriptName and pathInfo components.
The scriptName component is the path of the JSGI application that will handle the request. If the Render middleware is used, the template path is also derived from scriptName. The pathInfo component stores the extra postfix of the request. Let's use an example to demonstrate the concept:
Given the directory structure (sitemap):
/src/root/articles.js
/src/root/articles/view.js
Nitro automagically splits the request path:
/articles/12339
into:
scriptName: /articles
pathInfo: /12339
since /src/root/articles/12339.js does not exist.
We can use the pathInfo component to implement nice, RESTful URLs... more
One of the fringe benefits of Google App Engine is the comprehensive administration control panel you get for free. From your application dashboard you have access to the datastore, logs, cron jobs, task queues, blobs, etc. You can set permissions, blacklist ips and switch between multiple (concurrently running!) versions of your app.
Arguably, the Datastore viewer/editor is one of the more interesting features of the admin interface. It 's also seriously flawed: it handles the entities as 'atoms', yet in real life entities participate in complex entity structures. More often than not, a change in one entity affects other entities in the 'graph'. The lack of support for life cycle events in the current version of the Datastore viewer renders it incapable of capturing such complex entity relations.
What do I mean by life cycle events? Events like entity creation, entity update and entity deletion. Mainstream ORM systems popularised callbacks like oncreate, onupdate, ondelete. Introducing such callbacks in the Java and Python APIs may be easy, but things get messy when you consider the ecosystem of alternative language implementations based on the Java API: developers using alternative languages would be forced to use Java to write the callbacks.
There is a more robust solution though. Google App Engine already leverages the power of webhooks in such APIs as taskqueue, email, xmpp and more. Webhooks can elegantly solve the life cycle management problem as well: when an entity is created, updated or deleted through the Datastore viewer a corresponding webhook is triggered. Let's say the user is playing with Article entities, the webhooks uris could be:
http://myapp.com/_ah/admin/datastore/le/Article/create/{key}
http://myapp.com/_ah/admin/datastore/le/Article/update/{key}
http://myapp.com/_ah/admin/datastore/le/Article/delete/{key}
Slightly more work than callbacks, but still simple and effective. If there is an even better solution, I would love to hear about it in the comments section.
Update: I want to make clear that this is a proposal not an actual feature!
Unless you 've been living in a cave for the last year, you know that server side (better: 'general purpose') JavaScript is all the rage. Everything started with CommonJS: the emerging standard spawned an ecosystem of compatible implementations competing against each other while advancing the JavaScript state of the art.
Then, NodeJS happened: An async only JavaScript platform, powered by V8, not really interested in CommonJS conformance. RY (the new DHH) managed to grab the attention of the developer community with cool marketing, leaving other implementations in the shadows. One such great implementation that deserves more attention is RingoJS.
Some time ago I switched from Narwhal to Ringo and never looked back. I strongly believe that Ringo is the preeminent CommonJS implementation. Here is why:
Stop drinking the Kool-Aid! Engineer your application on top of a mature, conformant and compatible platform: RingoJS.
Update: Removed a controversial link
Yesterday, a post in Hackernews generated considerable interest on AppengineJS, my port of the App Engine Python SDK to JavaScript. The interest was so intense that managed to drain the free quota of the project's site. I guess 'slashdotting' (or should I call this 'newhacking') is the price to pay for the extra publicity.
Some interesting questions were asked in the comments section, so I would like to address some issues and clarify some points:
1. Why use JavaScript instead of Python on App Engine?
If you already know Python, stick to the Python SDK. If you don't want to learn Python and know JavaScript (every single web developer is at least familiar with JavaScript) give AppengineJS a try.
2. Why is JavaScript a great language?
Let the master answer this one:
The World's Most Misunderstood Programming Language
Crockford on JavaScript
Personally, after about 8 years of Ruby programming I don't regret switching to JavaScript. I love the prototypal inheritance, the object literal notation, closures, the C syntax, etc.
3. Why is JavaScript especially suited for Web Applications
Like it or not, JavaScript is the language of the Web just like C is the language of Unix.
The fact that JavaScript is the only language that runs natively on browsers allows you to reuse code across server and client side. And I don't mean just simple form validation code. I use the same template engine at both sides, I use jquery/sizzle at server side for web scraping, I use same jsgi-client code to send http requests at both sides, I use a Canvas-API compatible renderer to generate SVG at server side, I render ajax content at server side for search engine robots and more.
Working exclusively with JavaScript across your app, eliminates the mental context switch required by two separate languages. Oh, did I mention it's much easier to find JavaScript developers (than Python or Ruby developers) for your team?
4. Why does App Engine rock?
Platform as a service changes everything. Of course, App Engine may have the occasional outage or technical problem, but I really dig the fact that Google developers (not my team) are fixing the issue. Quite incredibly, App Engine eliminates the need for system administration, database tuning, security updates, secondary servers setup (email, xmpp, memcache, nginx/apache, squid, etc), etc. When I used Amazon EC2, I almost lost my data twice due to hardware problems on my virtual server. Even though the heroic efforts of the support team saved my ass, I still had to spend a night setting up a new virtual server. There are no servers to fail in App Engine, I love that!
5. Yeah, but isn't Datastore slow?
Datastore is not a relational database, it's a different beast altogether. You have to design your app form scratch with the Datastore in mind. Here are some useful links:
Mastering the datastore
Building Scalable, Complex Apps on App Engine
The Datastore may be slower than, say, MySQL for toy applications (but this can be mitigated through memcache) but the massively distributed, scalable architecture will pay dividends when (eventually) your data explodes.
6. Why not use NodeJS?
Well, NodeJS is a valid, if over hyped, solution. But it only helps you come up with a toy application. With 'toy' I mean an application that runs on your laptop or your staging server. For a production app you need deployment processes, multi version processes, system setup, server tuning, database scaling, backup processes, security policies, monitoring, profiling, admin console etc, etc. App Engine is the easiest way to go from toy to production (though Heroku-Node may provide a viable alternative).
Be open minded and give AppengineJS a try, you may like what you 'll see.
Well, the first day of Google I/O turned out to be better than expected! Especially on the App Engine front there are some extremely positive surprises:
To tell you the truth, given the latest developments in the AWS world, I was afraid that I 've bet on the wrong horse. NOT any more!
In Google we trust!
Another six months, another version of Ubuntu. As always, there are some improvements, as always I hoped to see more. The first thing to grab your attention is the new theme. I am not impressed. To tell you the truth, I liked the old 9.10 theme and wallpapers. Quite incredibly the old theme is no longer available in 10.04, wtf? On the positive side this is the first useful dark theme. It still needs a lot of polish though.
Supposedly, Lynx is much faster, but I didn't notice a considerably shorter boot time. Thankfully, the problems with my PC's WiFi chipset seem to be fixed. The two column view in Nautilus is useful, Gnome journal is interesting and I found an effective auto-completion plugin in GEdit (at last). Moreover, Flash 10.1, as integrated in the latest version of Chrome, works flawlessly.
All in all, there is definite progress, but I am afraid Ubuntu will share the fate of OpenOffice: to be rendered irrelevant by the Web.
Now, this is a man with a mission. The notion that the search for a Unified Theory can be reduced to a search in the computational space is interesting.
About a year ago, I switched from AWS to Google App Engine (GAE). To be frank, GAE is a beta quality service, in stark contrast with the mature and elegantly designed Amazon offering. On the other hand, GAE is a higher level service with a killer benefit: it renders system administration obsolete! The are no servers to administrate, no network connections to monitor, no extra services (mail, image processing, backup, etc) to setup and you certainly don't need a DBA to scale the Datastore. Horizontal scaling is automatically catered for and deployment is a no-brainer.
Still, this service needs a lot of improvement. Here are some features I would like to see, sooner rather than later:
Firewall API
The API should allow for easy blocking of dos attacks and restricting access to annoying users and wild robots.
Full Text Search
Come on, this is Google!
Map Reduce
Again, this is Google. Map Reduce is totally required in NoSQL environments (like Datastore).
Asynchronous Datastore calls
Async URLFetch is a great first step, but async Datastore calls would dramatically improve the performance of typical applications.
Support for Servlet 3.0 async model
End to end support for async would allow for implementation of NodeJS-style frameworks on top of GAE.
Blobstore API improvements
This API seems half-baked at the moment. I would like to see a more intuitive, S3-like interface. Better integration with the Image API and support for ETags would be desirable.
Release the source code of the Java SDK
Google already releases the source code of the Python SDK. Releasing the source code of the Java SDK would be extremely helpful for developers of alternative language SDKs (like AppEngineJS).
Multitenancy
Support for multitenancy in the Datastore would trigger an explosion of Web applications on the platform. Moreover, an improved Google Apps Marketplace would be a catalyst in the creation of a viable ecosystem.