gmosx

I had a very annoying problem lately. The deployment of my app to GAE was failing randomly with mysterious errors like this:

com.google.apphosting.utils.config.AbstractConfigXmlReader getTopLevelNode SEVERE: Received IOException parsing the input stream for /home/.../war/WEB-INF/web.xml java.net.ConnectException: Connection timed out         at java.net.PlainSocketImpl.socketConnect(Native Method)  ... SEVERE: Received exception processing /home/.../war/WEB-INF/web.xml com.google.apphosting.utils.config.AppEngineConfigException: Received IOException parsing the input stream for /home/.../war/WEB-INF/web.xml         at com.google.apphosting.utils.config.AbstractConfigXmlReader.getTopLevelNode( AbstractConfigXmlReader.java: 210) 

After an extended googling session I unearthed a solution from this helpful discussion thread. Just replace the doctype declaration in your web.xml file

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"     "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app>

with the following updated version:

<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web=" http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  version="2.5">

That's all, one click deployment is working reliably again!

You worked hard. Your application works like a charm, the concept rocks, the graphics are great, the client is happy. Still, you know there is one more thing to do: test with the dreaded Internet Explorer.

In your case, the app is a standard Facebook iframe application. You went to great lengths to make sure it stays compatible with IE (that means modern CSS/HTML techniques are off limits). Tough luck, you have to try harder my friend. You see, the application does not work at all! With no error message whatsoever.

Oh, wait a minute, there is a stupid eye icon in the status bar. Once you click it you realize that IE is actually blocking Facebook's authentication cookie! In the default security setting, no less. You are royally screwed.

To make a long story short, here is a 'voodoo' solution, offered by a mastermind friend:

response.setHeader("P3P","CP='IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT'");

For the hairy details, get educated by the pros. Groovy!

A few days ago, I needed to center a mini site horizontally *and* vertically (don't you just love client requests?). It 's easy to tackle the horizontal axis using CSS:

<style>
.hcenter {
  margin: auto;
  width: 320px;
  height: 240px;
}
</style>
<div class="hcenter">Horizontally centered text</div>

On the contrary, I thought that CSS can't handle vertical centering (at least in a cross-browser compatible way) and a quick Google session ended fruitless as well. Instead, I wrote a small script to programmatically center the div inside the window. It took a couple of revisions to support resizing, eliminate flickering, ensure cross-browser compatibility, etc. but eventually I got it right.

Today though, I rediscovered an old trick:

<style>
.center {
  position: absolute;
  width: 320px;
  height: 240px;
  top: 50%;
  left: 50%;
  margin-top: -120px;
  margin-left: -160px;
}
</style>
<div class="center">Horizontal and vertical centered text is possible.</div>

Duh!

I ♥ no.de

by gmosx, at 27 Sep 2010

A few days ago, Joyent unveiled the public beta of their NodeJS-based platform-as-a-service contender. Well, this service rocks! From the great no.de domain name to the RESTful procurement/management API and the git-powered deployment, everything radiates coolness.

Even though I posted my hearts to the API end-point (/♥ !!), I haven't received any coupons in return. So there is no review for you. However, the elegant simplicity of the API (combined with the clean-slate design of the underlying NodeJS infrastructure) lights my geeky heart (pun intended).

I am not a NodeJS fan-boy. These days I am evaluating Java/GWT (so far I am positively surprised but I 'll reserve my final judgement for a future post). So, you understand, like everyone who feels overwhelmed by the complexity of the Java ecosystem, I can appreciate a refreshingly simple alternative.

Last year, Google released the Closure suite of tools for JavaScript development. It seemed too good to be true. A robust client-side JavaScript toolkit and UI framework was just what I missed in my stack.

I quickly downloaded the distribution and, like the rest of the world, was immediately disappointed: The source looked like Java, with long name spaces and getters/setters everywhere. The compiler looked interesting but difficult to setup and integrate in the build process. The templating engine looked ugly and required a compile step. I switched back to jQuery faster than you can say 'crap'.

The problem is I wasn't fond of jQuery either. It 's great for improving the interactivity of a page or adding special effects but leaves a lot to be desired when you are building a business-oriented Web application. As I am working on a series of Web applications for deployment through Google Apps Marketplace I decided to give Closure a second chance... more

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!