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.
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!
I 'm not in the mood for a long post, so here are random thoughts in aggregate form:
f8
The new Facebook Social Plugins are FriendConnect done right. FriendConnect has so much potential yet the current implementation leaves a lot to be desired (to say the least). Moreover, the Graph/OpenGraph APIs are a bold step forward towards the machine readable Web (Web 3.0 / Semantic Web if you will). The 'Like' button is an obvious (yet powerful) idea that Google should have implemented a long time ago.
π is wrong
I always thought that 'π' should be the number known as '2π'. Then 'π' would be the perimeter of the unit circle, angle measurements would be more intuitive (90 degrees == π/4, 180 degrees == π/2, 360 degrees = π, ie a full 'cycle' is π radians) and a lot of formulas would be simplified:
p = πr, ie scale the unit perimeter by the radius,
sin(x+π) = sin(x), ie the period of the trigonometric functions is π,
etc. At the moment π is the sum of the angles in a triangle and the perimeter of a circle of with a diameter equal to 1 (doesn't this look awkward to you?). Read 'π is wrong' for a better treatment of the argument.
iPhoneOS TOS
The latest iPhoneOS TOS made a lot of developers angry. I don't agree. One of the problems in our profession is what I call a Babel situation: So many different languages and platforms hinder cooperation. Finding and integrating engineers into a software development team is a pain. Thus, having a single platform (iPhoneOS), a single system language (Objective C) and single scripting/application language (JavaScript) is refreshing.
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.
OK, I am sold, Google's social stream app just rocks! The Internet is ..buzzing with rave reviews and really what is there not to like: no lame 160 char limitation, in-line media support, integration with GMail, recommendation and filtering algorithms, auto discovery of the social graph, etc. All packaged with an intuitive user interface.
But the real benefit is the use of Open Standards. New York Times nailed this perfectly:
Google Buzz data can be syndicated out to other services using the standard data formats called Atom, Activity Streams, MediaRSS and PubSubHubbub. That couldn't be more different from Facebook. Google has taken open data standards to battle against a marketplace of competitors that are closed and proprietary to varying degrees. This is a very big deal.
Compare this to Facebook's closed garden and Twitter's ad-hoc (and badly designed/integrated) APIs. Just reuse your ATOM parser, leverage Pubsubhubbub's webhook model and you are off. more
Inspired by a recent Wired article (Kill your Blog) and given the fact that my hectic daily schedule prohibits such leisures as free time, I decided to experiment with a new blogging format, which I call 'Aggregates': collections of 2-3 short and succinct stories in a single article combo. Without further ado let me continue with the first such 'Aggregate'.
--
Don't get me wrong, I truly admire Google's technical achievements. However, I am afraid that Google's '20 percent time' scheme may have negative side-effects. Different teams work in isolation without a solid engineering framework. Their output is often convoluted and incompatible: multiple VM's (V8, Dalvik), inconsistent coding conventions and different implementation languages, overly complex specifications (OpenSocial), non standard approaches to common problems, NIH syndrome, etc. Have a look at Amazon's (AWS) services for a stark contrast: well engineered, standards compliant APIs, 'genetically engineered' to work together. A developer's nirvana.
--
I was blown away by the first promotional videos of the forthcoming Nokia N97. The hardware looks irresistibly sexy: the screen 'pops open' with a clever and efficient mechanism, the diagonal button is an ingenious touch, and (being an old hacker) I love the full-size keyboard. But the real surprise is the software: I strongly believe that an iGoogle style (and allow me to say 'Wii channel'-like) User Interface is the way to go. The old 'desktop' paradigm used by Android belongs to the 70's.
Go on, behold what must be one of the first G1 phones to surface in Greece:
more
