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:
- Ringo is quite possibly the most conformant CommonJS implementation, certainly more conformant than Narwhal and Node.
- Ringo is *fast*. If you tried Narwhal/Rhino and found start up times lacking or module reloading unacceptably slow check out Ringo! You will be pleasantly surprised. And while v8 may be faster than Rhino, the JVM is still quite optimized for server side environments. (And btw, in a modern Web application, time spent running the server side script is a negligible percentage of the total request/response cycle. You should probably work on optimizing network issues, database interactions, client side rendering etc)
- Ringo is mature, stable and crash free. Ringo is the evolution of Helma, one of the first server side JavaScript platforms (more than 10 years in development). It's also based on the mature Java platform. Contrast this to reports of NodeJS crashes.
- Access to the gazillion of Java libraries. There is no merit in reinventing the wheel, just reuse code from the Java ecosystem. The integration between Java and JavaScript is seamless.
- Windows compatibility. OK, Windows sucks, but still, a lot of engineers use Windows as a development platform. Ringo apps work on Windows out of the box.
- Support for synchronous and asynchronous APIs. Use what's best for your application.
- Thanks to AppengineJS you can run your Ringo applications on Google's scalable infrastructure.
- The lead developer is extremely talented and friendly.
Stop drinking the Kool-Aid! Engineer your application on top of a mature, conformant and compatible platform: RingoJS.
Update: Removed a controversial link
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
The Web is the new UNIX,
UNIX is the new BIOS
George Moschovitis, 2010
Old time readers of my blog know that I regularly change the platform that I use. Lately, I was using Google's Blogger, but I wasn't happy with the layout. Before that, I used a lovely, custom-made, Ruby-based CMS. But since I am fed up with Ruby (after 8 years, no less) it was difficult to maintain.
Therefore, I decided to utilise my AppengineJS and Nitro open source projects to create a new platform for my blog. This new version is implemented in JavaScript, the language of the Web, and one of the languages I dig these days (the other being Haskell). Even though I am relatively pleased with the result (and the clean code behind it), there is a lot of work to be done, when I find the time.
In the meantime, please subscribe to my feed and check this blog often for interesting content. Oh, and bug reports are always welcome ;-)
Update: This blog is not based on the blog-gae example source code. In fact, the blog-gae example is outdated and does not reflect the latest improvements in Nitro and AppengineJS. Perhaps, I will release the mini CMS behind this blog as an example if there is sufficient demand...
When you resize an image in an HTML page, you get a pixelated mess, no bilinear filtering. I never understood that. And while WebGL, O3D, etc are cool, I always waited for an HTML rendering engine that utilizes my expensive GPU.
The wait, thanks to Microsoft, is over:
http://channel9.msdn.com/posts/Charles/IE-9-Surfing-on-the-GPU-with-D2D/
Now, this is a great feature!
