Sista rycket inför SWDC2009

Jag fick just reda på av DFS att vi stänger dörrarna i morgon för registreringar till Scandinavian Web Developer Conference 2009. Så om ni har funderat på att ta del av världens Webutvecklar-stjärnor på Måndag, registrera er _nu_ :)

http://www.swdc2009.com

Mvh,

PS

Promotion for "Learning Dojo"

Here's a little something for anyone wavering about getting "Learning Dojo" or not.  To get a 12% discount, do the following;

1.) Visit the book page: http://www.packtpub.com/tutorial-for-building-interactive-interfaces-with-dojo/book.

2.) Click the "ADD TO CART" button to add the book to your shopping cart.

3.) Enter your promotion code: Dojo2688 in the Promotion Code field in your shopping cart, and click the Update button. The discounted price should now be reflected in your order.

Cheers,
PS

Rhino JavaScript working on App Engine Java Edition

I was super-excited this morning, when I saw the announcement that Google had released a Java version of their App Engine environment. My heart sank a bit when I read that they had a class white-list for security reasons, and told myself that I wouldn't be surprised if that means that you cant run Server-side JavaScript at all.

However, after reading Ola Bini's quick article on how to enable JRuby, I felt that it might be doable, after all, JS doesn't even have Threads (which more or less thankfully are disabled in GAE). It _should_ work.  

So I went and downloaded the eclipse plugin, created a new project, which came with its own "Hello World" servlet and dropped the Mozilla labs JS version 1.7 jar (from the Dojo Ajax Toolkit's util/shrinksafe folder) into the lib/ folder of the GAE project, added some paths here and there -- and it worked.

I tried something really simple like this;

...

String s = "var foo = {foo: 17, bar: 4711}; foo.foo;";

Object result = cx.evaluateString(scope, s, "", 1, null);

resp.getWriter().println(Context.toString(result));

...

And out I got a 

17

:)

I just saw that Google has limited the Java GAE SDK for the 10 first to register. I guess Sweden was the right place to be :)  If you want to see my sample project, you can download it from here;

http://genericwitticism.com/rhino.zip

Cheers,
PS

Small clouds - Large clouds

So, I attended this seminar recently, in which the usual suspects were paraded in front of a saucer-eyed audience; There was Amazon, Salesforce, local hopes and established players in equal measures. The first presentation was by a Swedish guy named Joakim Lindbom, CTO at Cap Gemini in Sweden - a really sharp guy, by the way.

His talk was about Amazon EC2, and I had heard a lot of it before, but not everything. Joakim focused on the architectural choices that Amazon had made when creating their different services, being an architect himself. He argued successfully the common knowledge that it really isn't possible to scale a relational database to do what Amazon have to do, and that the same apply to services.

In general a cloud-based architecture means that you use a distributed queueing service both to store incoming requests and to communicate between system parts. Yes, a kind of ESB, if you will, but simple!

It also means using schemaless databases that don't mind adding another column even though there's already 1.0E9 items in the table. 

And then it struck me; If it is absolutely critical to use ___SIMPLE___ (meaning non-complex, OK?) services which are both asynchronous (queued, event-driven) and dynamically or non-typed, to be able to build a system over a certain size - why is this not critical when building smaller system?

Or, to phrase the questions differently; How comes it is possible to build systems that does not comply with these traits, since they have been proven to be just critical? Size, is the answer of course.

But to expand that answer is to get to the core of the problem; Smaller sized systems can skimp on doing things right, because it doesn't show up until they get larger. And what small system doesn't?

So, essentially, what has been discovered to be critical in building large-scaled 'cloud' systems is just as essential in building smaller system, it just isn't as evident. Which of course can be translated as saying that it isn't critical. And, no, sure, it isn't critical. But what I'm saying is that even smaller system will by necessity cost less to build, if built according to the same principles the larger-scale system use, if nothing else but the simple fact that they will grow over time.

One of the successes of Erlang has been the reational approach to distributed proecessing; Since interprocess communication in Erlang is message-based, putting those messages on a bus á la Amazon's simple queue service, will be transparent to the processes using it, and also, those very processes need not know where they are and can so be safely dotted out in the cloud somewhere.

Imagine if someone would do that kind of stuff to another cool language, maybe one with first-class and anonymous functions, duck-typing (Simple, 'schemaless'), closures and late binding (i.e. easy to code in), like ... JavaScript? Maybe someone already has? :) 

No wait, nobody has to, right. It usable that way right off the bat. 

Have a nice weekend all y'all.

Cheers,
PS

Google Friend Connect Public Key finally released :)

Yes! After months of general agonizing and a feeling that everything I knew about security *might* be wrong, Google releases the public key for the certificate that signs the signed requests coming from custom GFC gadgets back to your server.

Arne Rooman-Kurrik (at Google) posted the certificate to the OpenSocial mailing list yesterday, and it looks like this;

-----BEGIN CERTIFICATE-----
MIICSjCCAbOgAwIBAgIJAKy5FQe8xe

W/MA0GCSqGSIb3DQEBBQUAMCMxITAfBgNV
BAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNvbTAeFw0wODEyMTkxOTQ3NDlaFw0w
OTEyMTkxOTQ3NDlaMCMxITAfBgNVBAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvvHLRIP0tKwFGExqfIOf25Ad
2WHq/Oz4CuuspA75pvXg5+w9E4P5oMNmGNENO7LAA+xSrXLND+FdDg4STH/5FW0Y
ycPhw7LvqsefQwnntn1oHGTYffWRPbovHZBDcCBJZ2cgzXnmsXG9D7rO06fikTaa
6aSw1mVt7sFvwZDegEkCAwEAAaOBhTCBgjAdBgNVHQ4EFgQUITh3OCFLiiyTPEsq
LKmuALCpfXwwUwYDVR0jBEwwSoAUITh3OCFLiiyTPEsqLKmuALCpfXyhJ6QlMCMx
ITAfBgNVBAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNvbYIJAKy5FQe8xeW/MAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAvnVl15uganMvEwABVxRwMAys
ICPuzrxvdgAHXDl1/FCv68CEbTatHYPHBTLiY66DL8HICWwFuIx4j0DTuj6IWHRG
iP2BFvtcRvogURixojA+JXsvIjafoShzqAioDptVUx1aIHM+af3B5zE6+wDVmRUz
1WeG3BvhoqPq1pUdWig=
-----END CERTIFICATE-----

It was later verified to work by a guy called videomap (should work at Google).

For old readers of my blog the magnitude of this event is simple to understand, but just to be sure, it goes like this;

1) You think that GFC is kind of cool. You put a gadget (or several) on the pages of your site, Google manages login, authentication, friend management et.c and people can chat , rate and have fun on your pages.
2) You realize that allthoug people are having fun there is zero (0) interactivity between the GFC gadgets and your site, and/or
3) You would really like to know the unique user id of the GFC loggged in user that sees you page right now.

So, you..

4) Learn how to create a custom GFC gadget (Exactly like creating a custom OpenSocial gadgets. Just grab one of the smallest sample code files, and you're done. Well, you have to get the 'wrappin' HTML for it from the GFC admin console for your site. Whatever).
5) You put the gadget on your ite in a nice, shiny directory
6) You enter the wrapping code in your page that loads you custom gadget *through* Google's GFC servers.
7) You browse through the OpenSocial 8.x AP docs and realize that you need to do a makeRequest() call back to an url of your server, getting the usr id (and picture) is dead simple, so you have that already in the other hand.
8) Yay, Your custom gadget actually send back the info! Great.

But then you realize...

9) Anythion on your page could actually have sent back that info. A malign ad might inject some script which runs and just send back 0000 or something. Translation: You can't trust informatiuon sent from the client.
10) You find a great option to makeRequest in the OpenSocial API called SIGNED requests. This will make the container (the GFC server in this case) sign the data you send. But also add signed and correct user ids for the viewer and owner of the current data. Yay!

It doesn't work. Until..

11) It suddenly does, a couple of weeks ago GFC decides to activate SIGNED requests. Wild joy. Everything seems ok.

Until

12) You realize you don't have the public key the GFC uses, so you can't actually verify that some *other* server on the internet tries to look like it is a GFC server and feed you false data. Eugh.

But then

13) They did publish the public key (Above), so now the circle is finally closed. We can now use GFC as a universal login mechanism, get a unique user id back to our server,a nd connect that to any data we choose.

Thanks Google!!!


Cheers,
PS

Google Friend Connect finally support signed request

Why is that a big deal?

Here's the short answer; Now you can get the viewer id of a user loading your page and send it back to your server in a trusted way.

Before (up to two weeks ago, when I last tried it) it was only possible to send back info from the web page in an untrusted way.

What I mean by that is that you could load a custom opensocial gadget, which got the viewer id using the opensocial api, and then proceeded to use the opensocial makeRequest() call to route that information back to an url on your server. However, since this information orgiginated in the browser, potentially someone might somehow get a malign script to run on your page (from an ad, perhaps) and make up any old id, to then send back to your server.

In the opensocial specification, there is different modes of makeRequest, of which one is to make a signed request. To describe a signed request, I've drawn a small diagram above. Let's walk through it, and return to the signed request in a little while.

Let's say that you have copied in some Google Friend Connect gadgets on one of your pages, by registering your site with GFC, noting your sites code, and so on, the first thing that happens is that a person going to you site loads your page (1). In your page lies the gfc gadget references, which load the gadgets themselves from the GFC proxy servers (I call them proxies since much of what they do is route information back and forth third parties) (2). If this is the first time the users has been to the site and/or the user have not 'joined' the site on a GC sense, he/she may now proceed to do so (still (2)).

Now you have written your own, custom opensocial gadget, which is also loaded into the page in (2). It probably resides on your server, but could actually be loaded from any server on the internet. That gadget does the following;

a) Get the id of the viewer
b) tell the gfc/opensocial JavaScript api that is loaded to post the data to an url on your server. Two weeks ago, this could only be done without authentication.

This will send the data (viewer id) first to the gfc proxies(3), which will then route it forward to your server (4).
On your server is a special script that parses the post data out from the HTTP request (5).

The only thing that has changed now is that the makeRequest call can use the authentication mode gadgets.io.AuthorizationType.SIGNED, which will result in a 'stamp' made by the gfc proxies as the message passes through them. This is what it looks like in a small PHP script I wrote to collect the incoming signed info;


2009-02-22 12:41:36>---------------------> id=82146293318299142645, nick=psvensson
2009-02-22 12:41:36> post param -- the_user_id -> 32146007816295742145
2009-02-22 12:41:36> post param -- the_user_nickname -> psvensson
2009-02-22 12:41:36> get param -- opensocial_owner_id -> 03600513378691222179
2009-02-22 12:41:36> get param -- opensocial_viewer_id -> 78096296444182405045
2009-02-22 12:41:36> get param -- opensocial_app_id -> 09127246177732455082
2009-02-22 12:41:36> get param -- opensocial_app_url -> http://xxxyyyzzz.com/osaccess.xml
2009-02-22 12:41:36> get param -- xoauth_signature_publickey -> pub.1008283802.-8019269915578004945822.cer
2009-02-22 12:41:36> get param -- oauth_version -> 1.0
2009-02-22 12:41:36> get param -- oauth_timestamp -> 981102302897
2009-02-22 12:41:36> get param -- oauth_consumer_key -> friendconnect.google.com
2009-02-22 12:41:36> get param -- oauth_signature_method -> RSA-SHA1
2009-02-22 12:41:36> get param -- oauth_nonce -> 01831428822001149500
2009-02-22 12:41:36> get param -- oauth_signature -> MviLJcsxuU2tN9hQTkMEqZrEaC7ZUX31Cz7HH17I00vT2q8NJWH28OzvDab1Cl,01YtetX+Yln/IkuTj+I11SzFwZu5aXQda5D9HBeq+zjdxwWfuLGo62AaMjm5lvJGwWrMW6q+vm33MVOFWecxuXzSPmDfsCE9Tyf+b3M=

Numbers and other stuff are messed with a bit, due to posting :) But the thing is that two weeks ago, only the two POST lines were getting though, and any signed request returned and error in th browser.

This is the dawn of maybe not a new era, but a new eralischimo. Now you can use trusted user ids without having to manage the users, changing password, creating capthcas (and keeping up with the bots), listing friends and manage those connections, et.c. Now you just slam a gadget on the page, and get an id back you can trust. Not half bad eh?

Cheers,
PS

[UPDATE]

OK, this is a bit silly. There is more to this than just using signed makeRequests :) The reason I forgot this, is that the magic sauce was something I added in desperation some time ago when I tried to make signed requests work; I added a certificate to my domain using google accounts;

https://www.google.com/accounts/ManageDomains

Where you can upload a x.509 certificate that you can associate with your domain. The process is explained in more detail here;

http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html

Including how to generate x.509 certs from scratch on Windows and Linux (Maybe mac as well).

Using Dojo to implement the 12 standard screen patterns

I really enjoyed reading Theresa Neil's article just recently on the 12 standard screen layout types. She gave a lot of examples, but what I found lacking was some nice templates that could be used if you wanted to jump right in and implement one or two of the patterns. I've been meaning to write a post about Dojo's Layout containers for a while now, so my initial idea was to provide Dojo examples to each of the 12 screen patterns.



As it turns out, not all patterns exist today as plain off-the-shelf examples, I decided to skip some of the patterns, since my blogging time is a bit limited, and just bite the bullets that I can quickly show.

Since we've just concluded that I'm really lazy, It will come as no suprise that I'll just provide links (where possible) to existing Dojo unit tests, that can be copied straight off (possibly changing where the css and js loads from, but I assume you're familiar with such procedures)

1. Master/Detail

[Would be simple to do with StackContainer. I have a releated, flipped example here, which loads html page snippets using Ajax and flip them over 'hypercard'-like when menu selection changes]

2. Column Browse.

There's actually a faily new Dojo widget that provides this 'mac explorer' kind of cuntionality. Data source riven and all. Verry snappy :)

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/widget/tests/test_RollingList.html

3. Search / Results

This pattern is of course the perfect fit for Dojo's DataGrid with filtering queries to the data store from where it draws its contents; Note that the example uses Google's cross-domain JS API to get the data which the grid is filled with;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/data/demos/demo_GoogleSearchStore_Grid.html

4. Filter DataSet.

This is also a tricky one to find as-is. Several data stores in Dojo support complex queries, and creating a filtering panel that let the user apply filters to the tiems retrieved from the data store is not particlarly hard. Mail me or comment here if you really want an example, and I'll post one later.

5. Form

No worries here. There's forms galore;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dijit/tests/form/Form.html

6. Palette / Canvas

Due to Dojo's unique cross-browser native 2D api, which detect if it should use SVG, VML, Canvas or Silverlight, there are several other DOjo API's which utilizes this for charting and other things. There'sfor example an excellent Sketching API which support manipulations of SVG files, as well as a related example in the dojox.gfx section. I chose these tests because they both provide a palette / canvas like experience, involving actual graphics. You should also check out openJacob's draw2D if you are the least interested in that kind of stuff :)

7. Dashboard.

This patterns has me a bit confused. Except for the charting / graphing widgets it seems to me to be similar to a form or something. Perhaps an assymetric DataGrid. Let's focus on the charting then. There are several good dojox.charting examples available, all which build on the work of dojox.gfx.

8. Spreadsheet

This is again a prime candidate for DataGrid, depending on whether to implement a real spreadheet or just look a bit like one. No exmaple included.

9. Wizard

OK, there's no widget for this - exactly- though the pattern would be fairly simple to implement. Again, mail or comment if you really want an exact copy of the pattern in Dojo. Meanwhile, here _is_ a Wizard widget, but it only shows one 'scren' of the wizard at any one time;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/widget/tests/test_Wizard.html

10. Q:A

I'm not really sure I get this one exactly. It is just #1 but over-confident, or what?

11. Parallel Panels

These we've got. and in spades. There's the obvious AccordionContainer, the classical TabContainer, as well as the fully hackable StackContainer.

12. Interactive Model.

This one covers quite a wide area. The emphasis seem to be on graphical interaction, which I'll have to get back to you for, because now it's time for lunch :)

Cheers,
PS