Script Uncle

Simple Scaffolding for a Dojo Ajax Toolkit application

2012-01-02T08:56:00.000-08:00

I've been writing some simple exercises for workshop-style (or solo) training for Dojo Ajax Toolkit, focusing on the strength of Dojo - writing OO-JavaScript applications.

The first exercises is about using Dojo's (classical) require and simple namespacing to create simple widgets, but I've gotten repeated requests for a complete application skeleton - something I understand the need for and which would have helped me quite a bit some years ago as well.

Luckily now there are some. The guys at Sitepen have written some excellent articles (with much better layout :) here and here which you should definitely check out as well.

My aim here, though is to give you a scaffolding which contains all the structure you need to get started. I've included Dojo 1.7.1 in the latest exercise, which might seems staggeringly stupid, but the reason is that this part of the exercises will go into building and testing, where you actually have to have a downloaded copy.

The exercises (definitely a work in progress) can be found here; https://github.com/psvensson/Dojo-Ajax-Toolkit-Free-Training and here is the Description file of today's app scaffolding sample.

-----

This exercise show how to make a simple scaffolding of an application in Dojo.
It is not an exercise per se, but shows both a simple CSS layout and how to split up separate parts of the app into subclasses.

This time we are referencing a local copy of Dojo 1.7.1, since subsequent exercises will use both the DOH testing system and the build system, both which are used from the Dojo 'util' folder
and relies on parts of Dojo to run.

I'm still using the old (pre-AMD) style of declaring classes, so Dojo will warn about some things.

The goal is to show in a series of exercises how to create a simple single-page app with Dojo which is:

1. Object-oriented - splitting functionality across a small class-hierarchy and through a logical namespace
2. Using a sensible box model CSS layout
3. Turn-key, so you can just copy the structure and get going modifying stuff as you please.

The page sample.html require's just one class, which is the widget mycustom.MainApp

In the MainApp class, a template is declared which defines the uppermost layout of the application;

<div class="mycustom_box">
<div class="mycustom_top">
<div class="mycustom_left" dojoType="mycustom.navigator.ui.MenuBar"></div>
<div class="mycustom_right" dojoType="mycustom.common.ui.LoginWidget"></div>
</div>
<div class="mycustom_center">
<div dojoType="mycustom.navigator.ui.ViewPort"></div>
</div>
<div class="mycustom_bottom">
Bottom area
</div>
</div>

The application has three visual parts; A top part which contain a menu widget and a login/out widget, a central part which contains a viewport which can switch between different views, and a bottom part which contain information and links.

Since these different parts are defined in their separate classes, with their separate template files, you get an automatic modularization that makes it less likely that different programmers
step on each others toes when working together (or just one making a 10K lines long file...)

This is a very, very simple scaffolding example which does nothing at all, but is a minimalistic proof of concept of how to start your own non-trivial Dojo application.

The namespace is divided into the main parts 'common' - for classes that can be reused and are hopefully generic, and 'navigator' - for classes that are specifically implementing the logic of this application.

I have called it 'navigator' because Internets. I have meant it to be a small app that let you navigate some space of stuff.

How to build Large Web Applications, part I

2011-09-24T06:47:00.000-07:00

I've been busy the last two years building fairly intricate web apps for my customers and while it's a fun job it's also by necessity not public in the same way an open-source project is. The only comments I get and discussion I'm involved in are generally from my customers, so it's a bit of a closed loop.

When I met Paul Irish in May this year in San Francisco he asked me,' But what do you actually do?', which was a fair question but took me by surprise. I'm mostly known for .. being that Swedish guy. With some luck people know I prefer Dojo as well, but I guess that's about it.

So what do I do? I build web apps as an independent consultant. Sure, I arrange conferences and user group meetings too, but that's where my beer comes from, so to speak.

This series of posts is both written to share and discuss what I feel are best practices around building large web apps, from a developer perspective, but also to let people know what I do. Possibly with the secretly evil intent of getting new customers if anything I write seems to be useful :)

Let's begin with defining what a large web app is.

A large web app (according to me, but please challenge and/or add to the list of items);

Have composite views (showing both a static status area and a changing subview of items and lists, for example)
Have widgets that are variants of each other.
Have widgets that need to show up in dynamic configurations (e.g. a list of n, or each a always have a b except on Saturdays, ..)
Initializes communication with the server or service and caches some or all information.
Have widgets that need to change states, remember states and react to state changes in other widgets.

This list could go on and on, probably, but these are the most important things off the top of my head.
One of my customers had an existing, successful product that was built in .Net C#. It was a client-server system where the client had the following features;

Personal view of things going on, of various sorts.
List of personal things, arranged per time period in a tree structure, which showed a grid with the selected things.
Library of things of other people, arranged in a tree by both time period, user names and project names.
*very* complex search view where list of search queries could be build up dynamically and combined like date, project names but also other domain-specific (and visual) properties.
A thing editor which let the user compose a thing that was composed of various parts which could be dragged from a tab to the left and then changed according to their type and rearranged. There were parts like annotatable image, rich text, project reference, and so on.
Some of the parts needed access to the system clipboard for reading and writing, and some parts needed to start with and communicate with Excel. Several parts needed file access.
Lots of other, minor stuff.

And now, two years later, the Dojo/HTML5 version of the client have about 80% of the functionality of the old client (and some that it didn't) being sold to clients and everything. It's been quite a ride!

I realize that I both want to cover the story of the programs creation and 'how to make large web apps' at the same time. It probably is a bad idea, but let's anyway.

First of all, before digging into specific implementation I would like to talk about bare necessities. Stuff you just can't do without, stuff that if you are indeed left without it you will have to reinvent, poorly, and too late and botch things up completely. Yes, I have, and probably you too. But I didn't on this project(s) :)

Anyhoo, If we take the first list of things that define a large web app, the items leads to certain demands on your tooling and libraries of choice. First of all you need to have a clean widget abstraction to work with, one that clearly modularize your code and your markup. It also help tremendously if you have a widget lifecycle metaphor, which is handled for you and that you can plug in to when and if you need to.

Widget Abstraction

The widget abstraction should, at minimum do the following (lots of lists, sorry);

Separate code and markup, so you have a separate file or string for the markup of the widget
Make it possible to create widgets in classes that derive from each other, so you can have one grid baseclass, then a librarygrid that inherits from the basegrid, et.c.
Completely hide id allocation to elements and sub-widgets. By this I mean that the abstraction need to let you use symbolic names inside the markup (
) that are then used inside the widget class in lieu of id lookups.
Use markup replacement, so that parts of the markup is replaced with data in the widget class (
${foo}
will be replaced with this.foo in the widget before the widget is placed in the DOM)
Have a lifecycle so that when you create a widget, the widget "subsystem" / superclasses will call a number of functions on it that corresponds to the different event like a) init, b) before markup creation, c) after markup creation, d) before widget inserted into the DOM, et.c.

Dojo does all of this (as does several if it's peers (JavascriptMVC, Sproutcore, ExtJS, et.c.), but since the 'everything in a box' approach is a conceptual hard-sell, people generally want to use smaller and separate libraries that does just one thing, but well.

A good, but a little bit dated list of a couple of markup libraries can be found here. But markup libraries (like Mustache.js) only solves one of the problems.

Dojo

I'm going to cover a bit how Dojo works here, but please let me know in the comments if you know about stand-alone libraries for these functions. i would think that some are probably part of a larger library's class-system, but still.

When I create a widget using Dojo, I create two files. One is the JavaScript class (obv) whic inherits from another custom widget or directly from dijit._Widget (widget subsystem) and dijit._Templated (markup replacement and symbolic element/subwidget naming). It could look like this;

In the directory "my/custom" the file "widget.js";

dojo.provide("my.custom.widget");
dojo.require("dijit._Widget");
dojo.require("dijit._Templated");
dojo.declare(""my.custom.widget", [dijit._Widget, dijit._Templated],
{
templatePath: dojo.cache("my.custom", "widget.html"),
username: "nisse",
postCreate: function()

{

dojo.connect(this.mybutton, this, function(e)

{

console.log("Someone pressed me button, eh?");
}
}
});

The file "widget.html";

< div>

< button dojoAttachPoint="mybutton" >${username}< button >

<div / >

The 'postCreate' function on a widget is called (if present) just before the widget is placed in the DOM, but after all markup replacement have been done. We now have markup that contains a div with a button in it, and the content of the button reads 'nisse', since that was what the class variable 'username' contained.

To use the widget you just have the following things in you code;

dojo.require("my.custom.widget");
...
var foo = new my.custom.widget();
// Not mentioning argument passing or automatic placement in page stuff. it's just a widget in the wind right now

There a re lots of other things you can do, like automatic event wiring, but I hope this small example is just enough to make you think 'Hmm.. that could actually be kind of useful'.

I am not really touching on the namespacing either, which is a simple things that have had ridiculous positive effects on the development speed and stability. We'll get to that later.

What the widget will look like in the actual page is something like this;

< div>
<button id="mycustomwidget_0_mybutton">nisse</ button >

<div/ >

What's actually in the id is not important, the important thing is that the id is never visible to you (unless you really want to, but you don't. Why would you? The only thing you need is to get a reference to the node in question (in this case, to attach an event handler to it).

Also, what may be less apparent, is that when you customer want another widget just like it beside the first, you don't have to worry about widget id lookup code, you know that you abstraction will handle those details and just create a new one and smack it up - no problem.

There are tons of more things I'd like to fit in here, but I have to clean the house while parts of the family is playing Deus Ex (the original) and others are off galivanting with horses. Oh well..

Oh, right. I'll be doing a series of free, half-day Dojo-training events at Valtech in Sweden beginning the 13/10 2011. I'll post here (and on twitter etc) if you live nearby and want to learn the basics of creating custom Dojo widgets.

See you soon!

Bad, hairy, dangerous and irresponsible node+now+couch example

2011-04-09T08:05:00.000-07:00

What I feel is lacking many times when I want to learn a new piece of technology is smallest possible complete examples. I find many time how to interact with a new fancy database, or maybe how to communicate between client and server in a simpler, cooler way.

Very seldom do I find examples that do everything I need. What I want, ideally, when toying with a new piece of tech is the following;

1. Full instructions on how to set up any requirements, or at least pointers to good sources.
2. Example of client code, or at least how to get a basic web page up through or in parallel to this new something.
3. Example of how to call the service from whatever client should be used.
4. Example of how to take care of the client requests send on the server-side
5. Example on how to persist information and get it back again, even if that is not really part of the new tech.

What I like to convey, I think, is that there is need for examples that give a newbie a fully working service for all examples, since even a very simple assumption can be to hard to grok if you are new to a certain scene.

In general I'd think it is better to have working, fully stand-alone examples that one does not understand one bit, than to have an example that is a partial service that is easy to understand. The newbie is a coder after all, and as long he or she have a working example that can be thrown rocks at, eventually he or she will figure the stuff out.

As it happens I've just manages to create (what I hope is) such a thing. What I wanted was to use the new now.js socket.io client->server and server->client communications proxy. It's really sweet since it makes JSON-RPC calls really simple. it's like this;

1. Your web page loads the now.js script from your now-powered node.js serverside JavaScript server.
2. The server-script on the node side adds any property to the global 'everyone.now. object.
3. JavaScript in your page gets any property changes propagated to a proxy object called just 'now' on the client.
4. If the properties are functions, the client can call them, and the function call will be executed on th server. No setup code, no nothing. Just call the bloody function, thanks.
5. If the client (your webpage JS code) adds a function of its own the server can call that.
6. This is what you really, really want.

If the browser doesn't support socket.io, a flash wrapper will be used, but all else remain equal.

But then again, you really would want to have some database running wouldn't you? On the server-side, I mean. Couchdb, for example.

What I just did was create a very small, not very clean example that uses now.js, couchdb and cradle on node and a small index.html file which load the now.js script and shows how to call functions exposed back and forth.

The code looks like this;

 var url = require("url");  
 var sys = require("sys");  
 var path = require("path");  
 var fs = require("fs");  
 var inspect = require('eyes').inspector({styles: {all: 'magenta'}});  
 var cradle = require("cradle");  
 cradle.setup({host: "127.0.0.1", port: 5984});  
 var conn = new(cradle.Connection)();  
 var db = conn.database("abc");  
 db.create();  
 var yourHttpServer = require('http').createServer(function(req, response)  
 {  
  /* Serve your static files */  
  var uri = url.parse(req.url).pathname;  
   var filename = path.join(process.cwd(), uri);  
   path.exists(filename, function(exists) {  
     if(!exists) {  
       response.writeHead(404, {"Content-Type": "text/plain"});  
       response.write("404 Not Found\n");  
       response.end();  
       return;  
     }  
     fs.readFile(filename, "binary", function(err, file) {  
       if(err) {  
         response.writeHead(500, {"Content-Type": "text/plain"});  
         response.write(err + "\n");  
         response.end();  
         return;  
       }  
       response.statusCode =200;  
       response.write(file, "binary");  
       response.end();  
     });  
     });  
 });  
 yourHttpServer.listen(8080);  
 var everyone = require("now").initialize(yourHttpServer);  
 everyone.now.msg = "Welcome to TEH wicked nowjs JSON-RPC";  
 everyone.now.foo = function(arg,cb)  
 {  
     sys.puts("Foo called.. arg and everyone.now is...\n");  
     inspect(arg);  
     inspect(everyone.now);  
     db.get('clientlog', function(err, doc)  
     {  
         inspect(doc);  
         if(!doc)  
         {  
             db.save('clientlog', {log: []});  
         }  
         else  
         {  
             var arr = doc.log || [];  
             inspect(arr);  
             arr.push({date: new Date(), message: arg});  
             doc.log = arr;  
             db.save('clientlog', doc,  
             function(err, res)  
             {  
             // Handle success  
                 sys.puts("Error after save was : "+err);  
             })  
         }  
     });  
     cb( "server callback yo!");  
 }  
 everyone.now.bar = function(arg)  
 {  
     sys.puts("now.js function 'bar' called from client. args are..");  
     inspect(arg);  
 }

What you need to do to get this working is;

0. Don't have a lossy operating system.
1. Install couchdb and create a database named 'abc'

2. git clone node.js + npm;

git clone https://github.com/ry/node.git

git clone https://github.com/isaacs/npm.git

./configure and make install first node, then npm

3. npm install cradle (couchdb helper library)

4. npm install now (that thing I just talked about, sheesh)

5. npm install eyes (logging/inspect library)

6. Unzip the nowtest example zipfile somwhere and do 'node nowtest.js'

7. Go to http://localhost:8080/index.html

Ta-daa! :)

Or possibly not, since I just slammed this together. It's bound to have ugly, warty, beer-guzzling bugs. Please tell me about them so I can update the code and links. Thx!

Ethics and Employment - part 1

2010-11-02T08:23:00.000-07:00

I've been thinking about employment for quite some time. It's a large topic and way too easily sway into the marshlands of politics. The first time I thought hard on employment was a year and a half ago.

I realized that the company I worked for at the time didn't have the right connections to land the really cool JavaScript jobs which I was yearning for. I wanted to create true JavaScript apps and time and again I was shucked half on the side into a 'Web Project' where you had to massage the dark mystery horror server-side templates as per usual.

This was not very fun. I liked the people I was working with but not what I was doing.

The reason was the fact that I was sitting as a lame duck, wholly dependent on 'consultant routing' companies or my employer to give me something to do. Since they were basically blind to what a JavaScript client-side application was and I had few connections outside the people I happened to know, I was stuck in a loop.

After arranging my first conference (SWDC 2009), and subsequently starting the Google Technology user Group of Stockholm I met with a lot of new people, one of who became my first customer, since they did want to make a JavaScript application. Quite a large one as well - a port of an existing .Net client-server app, but where the client should be remade in JavaScript and 'HTML5' with IE8 as a lowest boundary browser.

I started my own company, took on the new customer and their project and I'm still working with them one year and four work packages later (albeit only two days a week, which was the idea at this point in the project). I had other customers as well, arranged another conference (Android Only) and generally made good money having a fair bit of fun :)

The reason I do is because two things happened (painfully evident, but still);

1) I finally managed to generate luck by meeting enough interesting people

2) I dared to bite.

And only recently have I realized what a sorry wretch I was before, not having any control over my working life and I felt that most possibly other people feel the same way. Generally, I've found out it's like this;

1) You don't need to be employed at a company to get to work at great project and make good money, you only need to know enough people.

And if you don't know enough people, that's fixable. I feel that everyone should have their own company and interact with other companies as equals. To be an employee at a company is really not neccessary. Other than you own, that is.

Another objection I have to being employed is that you get always get this half-decent salary that is capped, with your employer making as much money as possible on top of the cap, so to speak. I feel that employees should get a bigger share out of the profit they make.

I've been part of profit-sharing schemes on different companies I've worked for, but none have really made any lasting impressions. I feel that as a subject area expert (and consultant) you should get at least 50% of the profit you generate. If you're become better, this will (or should) reflect on a higher hourly rate and an automatically higher salary.

Having your own company gives you 100% of the profits of course, but not always as salary.
OK, so what are the downsides? Lots, of course, but nothing that actually counts if you compare it to slowly becoming an old irritable grouch who is forced to do things he hate most of his working time. For example;

1) Most of the time you only know about the next three months of revenue
2) You are completely dependent on your customers
3) You are completely epenedent on your customers paying you sort of on time
4) You have no money when you don't work (i.e. 'vacation')

So, in a nutshell, working on your own, you don't have any security whatsoever.

Let me tell you a secret: Neither have you when you're employed, rounded down.

The company can become bankrupt or on hard times, having to downsize as easy as your personal company would. The only difference between being an employee and owning your own company is that you actually have some control over the ship in the latter case.

Even though this I do believe that you shouldn't be employed I have had two moral dilemmas; First of all Google. I have been a bit of a Google fanboy and despite having had my own company, I've applied for some positions there. This is clearly scizophrenic so I really hope I've stopped with that sort of stuff now :)

The second moral dilemma has to do with employing people myself. Since I have quite a large network nowadays I get a lot of interesting offers that I rarely can do something about, being tied up in prior agreements.

So, the natural solution would be to hand over those projects to other one-man shows for a small commission. Now for the suprising part; I can't seem to find these other one-man shows. OK, yes, I know of one, two at the most. I've been talking to great employed people I know, urging them to start their own company and start receiving project from me, but inevitably they shirk away from that and continue doing sort-of boring stuf (IMO) in exchange for apparent safety.

This has led me to the very strange conclusion that if I want to give people projects, I have to employ them. OK, I *could* give the projects to the companies they work for now, but in most cases those companies are large, very executive and so on and so forth. I have a feeling I would not look good in the end, the projects having come to me sort of on a personal level. I would want to have some sort of responsibility.

So how do you employ people when you're against employment? :)

Stay tuned for next chapter.

Cheers,
PS

The problem-solving process in dynamic vs. static languages

2010-09-11T07:15:00.000-07:00

This post is about why not to used static languages. It will outline the creative process used when starting to attack a problem and implementing its solution in code, and why that very process is hindered greatly by static languages.

You know what I mean, when I say static languages (Java, Scala, C++, et.c.).

I know that I've read about similar ponderings to these on the web earlier but a) I can't find them right now and b) It struck me anew on a personal level when I tried to understand why I work so much quicker when developing code in a dynamic language (especially JavaScript).

The dynamic development process

When I start to formulate a solution to a problem in JavaScript, I focus on the algorithm, on the classes that operate on the data and their methods - on the flow of function calls between different parts of the system I build.

Most often I forget some details about the data being passed or of what kind of state I need to include in the arguments in calls between different classes. This is no big deal as I just create new objects on the fly as arguments or return values, sometimes currying them up as part of a filtering process.

This lets me stay 'in the zone' and focus on the problem I'm trying to solve. The data structures are pliable and can be changed in the same place as the code. I never need to bothered with what kind of data I'm juggling. I might do something like this;

foo.barMethod({size: x, noses: 17, frotz: {a:'b', c:'d'}}, this.somethingImportantAtTheMoment);

The first barMethod argument is an object. Just an object, could be anything. When I need to put more stuff in there, I do so. The object is so lightweight that it doesn't warrant its own class, it is really just a simple wrapper around some data I'm passing, pliable as my code for using it are right now in my problem-solving process.

The static development process

This might differ significantly in Scala which I must confess I haven't studied enough. Please let me know in the comments if so. But when working with Java, I very quickly run into the creation of (often hierarchical) the definition of data classes and interfaces.

Their properties are often complex, themselves objects, a couple of layers deep. Even though each data class is trivial, creating them takes me out of my creative zone, forcing me to make decisions around data that I'm not ready for yet. So naturally I put in the bare minimum of information.

Then when using and passing around these objects, I often find myself constricted by the fairly arbitrary member/property types I've chosen, whose management tend to bleed out into the code, in the form of casts, et.c (This should be an area where Scala does help, though).

When I change my strategies for my problem-solving logic, it impacts heavily on the contents and types of the data classes, even if the data and logic classes are the same. I need continually to pop out of problem-solving mode into yak-shaving mode to arrange the data to fit my new logic.

I have now realized why static people so often tout the importance of having refactoring zombie-dust-powers in their extensive IDEs. From my vantage point it seems like fixing a language deficiency.

But wait! What about all that evil terror that happens if you just create anonymous objects and functions mid-stride without any type enforcement? Well, for one thing - testing is key, and another thing - it has actually happened once or twice that I've had to hunt about in somebody else's code for what on earth they have put in an argument object.

Compared to the extreme pain of always having a static retriever biting my private parts, the problem of finding the dynamic bottle of beer in the living rooms has in my experience been an extremely fair trade-off.

YMMV, of course.

Comments?

A solid dyson sphere of Awesome; The JSConf experience

2010-05-01T09:22:00.000-07:00

A couple of weeks ago I attended the second US JSConf in Washington. It turned out to be a very good move indeed.

I can easily say that this was one of the best conferences I've been to, maybe the best one. The reasons are, I suggest, threefold;

1) I have a personal, burning and possibly unhealthy interest in JavaScript.
2) The speakers were generally critical-mass awesome.
3) Track C - "The first rule of Track C is that you don't talk about Track C" - as Peter Higgins, president of the Dojo Ajax Toolkit has been known to tweet.

Track C meant hanging around the corridors of Hotel Palomar, pilfering beer from pirate chests and having interstellar discussions about programming. And joking. And talking about SF books. Epic.

The playfulness and allowing atmosphere was really great and everywhere you turned you met guys and gals that also arrange their own conferences, write their own frameworks, turns the web inside out (or upside down), and so on.

But last things first; After two days of extremely technical talks, games and panels, comes the final payoff - the keynote. What might the keynote bring, after node.js future directions, Sproutcore WYSIWYG editors, custom DSLs and JavaScript interpreters for Flash?

In a word: 'Bacon'. Aaron Quint gave a Bacon keynote. No, it's not a framework or scrum-derivate-du-jour, actual cured pigs belly, that's what.

Aaron is a foodie. He's a great Ruby and JS guy as well, but he is a very passionate foodie, and the level of passion and knowledge in his talk about making your own bacon, history of and how to barter it for microbrew was both entertaining and cheeky.

Actually, the cheek belongs to Chris Williams, Pirate Captain of JSConf who, as always, risks all by choosing a *non-programming* keynote for a programming conference. That in it self was almost as fun as seeing it. Naturally Passion is key, and Aaron did weave in some pseudo-code to refer to the different experience of making food and making code. But the core of the talk was, IMO, about what makes us tick, as foodies, as developers and as human beings.

Also, Chris actually planned JSConf together with his wife (who had a T-shirt with the text 'Pirate Pending' on), which was really nice and the very antithesis of Corporate.

Another cool thing about the conference was that over 100 people who sent in their abstracts didn't get chosen. Actually, that is just the way it is and neither here, nor there, but since many people *really* wanted to get a place speaking at JSConf and vented some steam on twitter, Kyle Simpson (@getify) proposed having a pre-conference conference, the so-called Scurvyconf, which was open for anyone who couldn't speak at the actual JSConf.

The sound at the pub where ScurvyConf was held was deafening, with drunk geeks shouting over each other and having a generally good time. So the speakers had a hard time getting heard. This was taken in stride however and even though the audience participation was varied, it was very empathic where it occurred.

At the end of the first day we were treated to a cruise on the Photomac sponsored by Yahoo! with wonderful food and long discussions with people from Disney, Microsoft (Really!) and SinnerSchraeder (Hi Holger!) ranging from how XSS really works to defensive synthetic biology and the open wetware foundation. A total blast.

I finally got to meet in person Justin Meyer, the creator of JavaScriptMVC who gave a great talk on its many strong points. My favorite is still the railsish generative scripts which creates client-side files for certain tasks (like consuming and displaying services). Justin was also the man who opened the bar in the wee hours of the morning on our way home from the final Google dinner night. Kudos for that (and spontaneous dancing to boot).

When we finally got home, the final night, the idea was to go to sleep immediately. The ever-present pirate party had other ideas, however.

There was vodkas and Guitar Hero and lots of falling into each other arms and crying, figuratively speaking, naturally.

We just had a great time. In fact, when I ran through airports the following morning, hungover like what have you, I was told that I had something hanging on my back. So I did. I let it hang all the way back to Sweden, and referred at least one person to Facebook who asked about it.

It turned out, when I looked at my pictures, that I was not the only one so inflicted.

I'll wrap this up now, and leave you with some more random pictures and a huge thanks to Chris and his pirate family for creating a completely stellar experience.

Super-simple authentication using Google Friend Connect

2010-02-28T07:42:00.000-08:00

I've been following Google friend Connect since it came out, since it's a very interesting API.

For me, what's interesting about it has always been that it takes care of the authentication for a site owner. This is not the basic use-case, mind you. The basic use cases seems to be the simple addition of site-separate, rich, social widgets.

This is by no mean bad, but the first thing I wanted to do with GFC was to just put up the first, simple 'join this site' widget, and then use the magic to let anyone who had a Google. Yahoo, AIM, OpenID, et.c. account just log in to my site, using a unique user id provided by Google.

This proved quite hard in the beginning, especially since you basically had to learn a lot of OpenSocial APIs just to do something non-trivial. Since a couple of months back, the GFC APIs has become richer and also simpler. The meaning of this blog post is to show you in a simple way how to leverage GFC for your own authentication, without breaking a sweat.

What you need to do is the following;

Register your site with GFC
Copy-paste in the HTML/Script code for the member gadget into your index.html page (This is done by selecting that gadget and choose to let the GFC page render the code including your site id in a copy-paste box. not terribly hard either).
Do nothing in particular, since the cookie will be send as part of each request to your server (even Ajax ones).
In your server, receive the cookie (looking like this: 'fcauth19038466278488110'), and call GFC from the server, suing the cookie, to get some info about the user.

Using the following code, I make sure that the opensocial API is loaded and that I get a callback when it feels ready. It's not really necessary, but might be of use if you need to access viewer or owner info in your page before or without talking to the server.


   google.load('friendconnect', '0.8');


google.friendconnect.container.loadOpenSocialApi(
{ 
      site: 'xxxxxxxxxxxxxxxxxxxx',
      onload: function() 
     { 
    var fcauth = dojo.cookie("fcauthxxxxxxxxxxxxxxxxxxxx");
    console.log("gfc onload fcauth cookie was '"+fcauth+"'");
    if(fcauth && fcauth != "undefined")
    {                    
        try
        {                  
            dojo.publish("ab_cookie", [fcauth]);          
        }
        catch(e)
        {
            console.log("ERROR in opensocial access.."+e);
        }
    }
}
});

Naturally, you can use an Ajax call inside the callback function directly. I've put all of my logic inside a custom Dojo widget, and if you're not using Dojo, you can do whatever you want.

On the server, which I've coded using node.js and fab, my handler function look like this;

Game.prototype.getUserInfo = function(fcauth, id, cb)
{
    // http://www.google.com/friendconnect/api/people/@owner/@self?fcauth=<your fcauth>
    log.info("getUserInfo called with fcauth='"+fcauth+"' and id='"+id+"'");
    if(!fcauth || fcauth == "undefined")
    {
        log.debug("Skipping null/unathorized request");    
    }
    else
    {
    
    var google = http.createClient(80, "www.google.com");
    var request = google.request("GET", "/friendconnect/api/people/@me/@self?fcauth="+fcauth, {"host": "www.google.com"});
    request.finish(function (response) 
    {        
        response.setBodyEncoding("utf8");
        response.addListener("body", function (chunk) 
        {
            sys.puts("BODY: " + chunk);
            var echunk = eval("("+chunk+")");
            if(cb) cb(echunk);
        });
    })
    }
}

You might choose Python or PHP on the server-side, but I hope that the code is fairly simple to understand. I have the specific code that extract the variables somewhere else, but the function is called with a couple of parameters, where one is 'cfauth'. This is the contents of the cookie set by GFC in the page before.

What the function does is call the GFC server with the cookie, using a special URL which gives back user information about the person just signed in using the cookie. We get back stuff that look like this;


{"entry":{"isViewer":true,"id":"16646299100122442145","thumbnailUrl":"http://www.google.com/friendconnect/profile/picture/9aOJATlcddBMuphbZq6wdLLqvyJr39BwuR60j67nPGv6LO8O_V3xho7gIoeH2juRoEm7jAOdl6_4RK4QAv5aFqD0zzg3TUxVAAZehjEoaEVTjeML9zwRyDFklaql_MxAznquk-Yhm63-ihZtryfA_T3tAwhWv4Szl12A1tZ3xfAa1jAdrE3it5Tx-fAbBW_qPZ3EE4DfALqLKmWC9hqXoXy9wI3rqzoS67CkgsTcU3CJM70ua9Z6OkIpFx7zi3dIXfIFawbodmOhKQ5A7_LeGA","photos":[{"value":"http://www.google.com/friendconnect/profile/picture/9aOJATlcddBMuphbZq6wdLLqvyJr39BwuR60j67nPGv6LNGCV3xho7gIoeH2juRoEm7jAOdl6_4RK11H5aFqDmikrg3TUxVAAZehjEoaEVTjeML9zwRyDFklaql_MxAznquk-Yhm63-ihZtryfA_T3tAwhWv4Szl12A1tZ3xfAa1jAdrE3it5Tx-fAbBW_qPZ3EE4DfALqLKmWC9hqcx0XswI3rqzoS67CkgsTcU3CJM70ua9Z6OkIpFuyzi3dIXfIFawbodmOhKQ5A7_LeGA","type":"thumbnail"}],"displayName":"psvensson"}}

I hope this helps someone, and apologies for not giving out all of my code, which is in a bit of flux.

[Swedish] rabatt till GTUG Stockholm medlemmar till Scandinavian Web Developer Conference 2010

2010-02-11T03:12:00.000-08:00

Den 2 och 3 Juni går SWDC2010 av stapeln på Skandia-teatern på Drottninggatan i Stockholm.

Konferensen för dig som vill lära dig det absolut senaste inom webb och mobilutveckling.

[Detta information har tidigare gåt ut till GTUG medlemmar, men är nu uppdaterat med mer rabatt och enklare biljettprocess]

De främsta internationella experterna inom Front-end utveckling, Mobil utveckling och JavaScript delar med sig av sina kunskaper.

DAG 1: Fokuserar på front-end utveckling och JavaScript

DAG 2: Fokuserar på programmering och utveckling av mobiltelefonapplikationer till framör allt iPhone och Android.

Du som har kommit på minst ett GTUG Stockholm möte får 875:- (25%) i rabatt på konferenspriset på 3500:- (ex.moms), alltså bara 2625:- för båda dagarna!

Erbjudandet gäller fram till den 15 Mars. För att använda dig av erbjudandet behöver du skicka ett mail från den epost-adress som är registrerad hos GTUG Stockholm till register@swdc-central.com

Som svar kommer du att få en engångskod som du använder under fältet "Coupons" på betalningstjänsten Stage HQ, som vi har länkat till från vår hemsida.

Mer information om konferensen finns att hämta på http://www.swdc-central.com

Bland våra 15 talare:

Tom Hughes-Croucher - Technical Evangelist/Innovation Lead på Yahoo! och expert på Accesibilitet och Web standarder.

Talar om : Mobile Data: How to avoid the latency trap when using web services.

Tom Blackmore har arbetat med geospatiell data hos hitta.se, varit projektledare för hitta.se's 3D-kartor, och håller en kurs i GIS på Mälardalens Unviersitet.

Talar om: Handling spatial data on the web.

Stefan Pettersson är konsult på Netlight AB som JavaScript/Front-End expert och har arbetat på några av Sveriges största sajter, bl.a. Aftonbladet.se.

Talar om: Developing Large-Scale JavaScript Websites.

Se http://www.swdc-central.com för en komplett lista över talare!

GTUG Meeting January 2010

2010-02-01T10:55:00.000-08:00

The January meeting got out of hand early on, as I got a semingly inocuous email message from a GTUG member asking if anyone from Google would be there to show the recently unveiled Nexus One phones.

I asnwered that I thought it unlikely, but that I would give it a shot, and then forward the request to Tommy at Google Sweden.

Not many minutes passed before I got a reply where he positively guaranteed that he or someone else would be present at the meeting, just the next week.

When people got to know about this, we had a deluge of registrations, and for the nth time I became really tired with LinkedIn's feature-lack of limits for the otherwise hadny events that I used to use for GTUGs. In all, 93 people registered on the double machine check-in me and Ottoboni provided for the evening.

First out was Ingemar Resare who talked about Google Apps integration, then came Tommy and Serge from the Google Office and totally winged an imprompty Nexus One presentation using their personal ones and answered hudnerds of questions.

I had to break somewhere in the possible middle of the question train since people started getting restless, eyehing the sandwhich trays (OK, so I was hungry, sue me :)

The food break was on the other hand a natural time for people to get to thold and try out the Nexus One themselves, with a Sandwhich or beer in the other, possibly both.

To the left here is Tommy describing the Nexus one's features.

For our last number, we got Peter Sönnergren who did an outstanding App Engine + Java talk which led to a lot of questions and I think perhaps the first real walkthrough for many present.

He was promptly talked to by the arranger of JFokus (which was due the very next week) and it turned out that he not only appeared on stage (together with Patrick Chanezon, I think) and also took over a Groove on App Engine session, sicne the Groovy guy had falled unexpectedly sick at the day of the talk. Talk about pivoting!

Gotta keep this short, but now you know what was going on. And actually, the next GTUG meeting is this Thursday - completely packed as well, since we will both host Spotify's Anders Bond who will talk about their Android development process, and as a little extra number..

An Actual Android Developer Codelab with breakout coding sessions and everything led by Reto and Billy from the Google Developer Advocate Android team. Check out their schedule here. Sweden is just part of the big show that's going down right now.

But we'll have a meeting in March as well - at the Google Sweden Office (allegedly).

Cheers,
PS

A new term for what we do

2009-12-29T04:49:00.001-08:00

I started a new part-time project a while ago where I was allowed to use the full power of thin server architecture and Dojo, where the back-end was written in PHP.

While talking about the architecture with the back-end developer (which was really impressed about the cleanness of using a SMD file to define the protocol contract between client and server) we compared experiences and realized that we were both programmers first and visual designers last, if at all.

Many times the customer or project owner have a very dim understanding of client-side development, which leads to bizarre ideas about the simplicity of implementing ideas in the browser. Most common is that JavaScript is seen as something to use as a last resort and that the entire user experience is seen as a series of 90s cardboard static HTML pages, mainly because it's simpler to conceptualize, I guess.

Working the majority of my time with web pages but never with visual design means that I need to find very advanced customers and project members who understand that there is a layer below the design, but not on the server.

And that's when the expert PHP developer I was working with (Henrik Hussfelt, no less) coined the term middle-end developer. I have never heard that before, and IMO it resonates with where I put myself in the value stack.

Could a new definition like middle-end be a tool to more precisely define the JavaScript programmers role; Not as someone who adds an event handler to a button, but someone who creates the actual client application, but not the markup template for it.

GTUG Stockholm meeting December 2009

2009-12-14T05:02:00.000-08:00

Like the happy crazy people we are, we had a GTUG meeting only days after the Android Hackathon. The upside of that was that we could have a recap for those unfortunates who didn't have the time or ability to attend.

About 30 people came, which is OK, but made me think maybe we should do the meetings bi-monthly instead of every month. Not sure either way, but I'll decide after next meeting.

The people who came were as always from a lot of different companies; Spotify, formerly of Spotify, Voddler, Qbranch and many others.

After my short introduction and talk on some new Google technologies (Mostly Closure) Tommy Widenflycht from Google Sweden did a talk on Google recruitment and then answered questions for a long time, handing out frisbees and hats to the best ones.

Apparently, there's a need for really talented Server-Side coders (C++/Java) and A/V Codec programmers in the Stockholm office (and elsewhere). If you feel that you fit the bill, contact me by direct email (psvensson@gmail.com) or comment this post and I'll make sure you get to talk to the right people.

Then it was time for the much-anticipated JavaScript on Android talk by Mikael Kindborg. I was really impressed with the research Mikael had done and what he had managed to do.

First he had compiled Rhino for the Dalvik VM and used that to parse incoming JavaScript string. So far, so good. To do that he had made a simple JavaScript app server called RhinoDroid (You can get it here from github) that made it simpler to push JS from an external source (like a browser, or in Mikael's case, the Squeak Smalltalk environment. That's was really cool in itself. What happened then I could have understood if I had thought about it, but I hadn't had the time.

Since all Android APIs (that has been compiled into the RhinoDroid app) are accessible by the JavaScript script when running, Mikael showed how he could build up a simple Android interface asynchronously, adding some buttons, which popped up on the Androdi screen, push those a bit - nothing happens.

Then send some JavaScript event handlers that bind to those buttons, which get dynamically evaluated and then the button do something. So he was building an Android UI - and changing it - in realtime. Think about that for a while.

The next talk was Johan Burell who did a run-down of the Android Hackathon the previous Saturday; Which apps had been created, which ones had _almost_ been created, and so on. Several people who had been present was in the audience as well, so we had some recaps and discussions about team @froderik's Android Hudson front-end and the other apps as well.

The last talk for the night was by Sony Ericsson's strategy manager Thomas Bailey, who did show and pass around an actual X10 Android phone. It's surprisingly and reassuringly heavy and a screen that is 'right' sized. The interesting parts of Thomas' talk was the fact that Sony Ericsson is starting their own Android App store, to be able to offer developers a more controlled environment to publish their apps to, and Sony Ericsson's signature apps (Organizing and formatting activity streams and media) which will exist only on their phones but can be extended using XML files, which will pop in future sources of contacts, media and other things, which is a neat concept in itself.

Our next meeting will be on January 14th, where we will cover the following topics:

Peter Svensson - State of the code (+some Dojo layout goodness)

Ingemar Resare - Google Apps use cases.

Peter Sönnergren - App Engine + Java

Johan Burell - Google Go (+ Android Cntrllr)

Leonard Axelsson - App Engine + Groovy

See you guys then, and a Merry Spaghettimas to you all!
Cheers,
PS

Full Brighton

2009-12-09T09:25:00.000-08:00

And actually, this blog *should* be about how to avoid common pitfalls when using Dojo widgets inside hidden ContentPanes (as when using Stack- or TabContainers), but I have a huge queue of, oh, two or so posts to go before that.

Todays topic is of course the unreasonably nice JavaScript conference in Brighton recently - Full Frontal.

I have never been to Brighton before, and one of the experience was walking about the city itself.

Which despite the pedestrian nature of above statement is not particularly easy, even if it's nice (sharing properties with several other activities I could think of..).

The reason for the lack of simplicity is that the city is actually at least two cities, which don't like each other very much and have crashed into one another in a desperate struggle to the very end, throwing streets and towers as you please, leaving the unwary resident in crossing with no less than three busy streets, often multiples of that, where two or more have steel railings to avoid being crossed in reasonable manners.

I had managed to hitch a ride out of the airport with @icaaq, or actually @icaaq's cousin, who was living with her family in Brighton since years back. After a quick freshening up in the Hotel room I managed to get to something I believe is the west end of Brighton which is chock-full of pubs, of which me and a motley crew of web developers, media folks, CEOs, CSS gurus and JavaScript madmen went to at least three (or so they say).

The evening was punctuated by Christian Heilman was nice enough to lead the way to the actual beach (at 2am) to see a work of art of some sort, where I managed to take a photo of him and Lieke Arendts of Ajax.org and Javelin fame (uppermost above).

The conference was set in a beautiful fin-de-last-but-last-again-ciecle cinema named Duke of York Cinema. You know what? All conferences should be in cinemas. Problem with ventilation? Nope. Too hot or cold? No way. A cinema is made for large number of people sitting for a long time looking at whatever's up on the stage. Perfect!

And was it great! One of the best things was that I wasn't even speaking. I had no last-minutes slides to perfect, no slow parts of my talk to worry about - nothing. I could just sit down and enjoy the show.

But even though JSConf.eu wins due to the sheer amount of good content, Full Frontal still manage to out-wattage JSConf.eu on the mere fact that it was *so* right in just one day, managing by luck or engineering to get almost every speaker not only be the right kind but sort of building upon each others talks.

Everything was good, but the absolute highlights for me was Jake Archibalds talk on JavaScript optimization. Not only for the hard data on what to do and not to do - between different browser, but he had a stunning presentation technique. First of all his slides were top-notch (can he possible be that skilled? Or do he have some secret connections in the Beeb's media departments?), and secondly he had a comic timing that made his talk the most fun-packed of the day.

He had this slide of a He-man doll, which he referred to as the power of the JavaScript VMs of the moderns browsers , but crossed with terminator (next slides showing he-man with Borg eye), and a crustacean forming a battlecrab! (bext slides showing a cyborged he-man doll with a large crab-like derierre), and so on. I don't make him credit, but it was really great.

The next best part was the closing act, where Simon Willison had ditched his prepared talk (something about web APIs) after seeing the presentations on JSConf the week earlier, and promptly slammed together his own talk on node.js, using fluffy rabbits, cute hamsters and octopuses (OK, just one octpus), to describe the difference between threaded event handling and event-callbacks.

The talk had just the same effect on Full Frontal. people whooped and became generally agitated about the idea to use their front-end kung-fu to start building heavy-hitting serve-side stuff as well. No new idea (and the Javelin guys were quietly commenting on their own KLOCs of C++ to make their own SSJS platform one of the speediest, doing essentially the same - and more), but the magic bullet here is one of perceived complexity; Noone in the room thought that they would have a hard time picking up node.js and try something out with it. Just as with CouchDB, it simple to explain and simple to use. Well, OK, I'll shut up about it for now, but expect me to be back on the topic!

Anyhoo.. the after-party was nice, full of back-clapping and camaraderie,and just the right size too. I think that the superpower of the current JavaScript movement that's building is twofold; people are super-amateurish and quirky, and also nice. Really, really nice.

Amateurism in really bright people means playfulness and a lowering of barriers, so that using hamsters for request is seen as OK - not very academical, but fun and getting the point across.

I'll definitely be back next year (there too :)

Cheers,
PS

GTUG Android Hackathon 28/11 2009

2009-12-01T10:17:00.000-08:00

Earlier this year, I had an idea for an all-day event for hacking on some Google technology. When I proposed this to the group at a GTUG meeting, I was reasonably certain that Wave was going to be chosen as the technology in question, and to my surprise instead Android took home most of the votes.

So, Android it was. No worries, though, as I'm a great friend of the platform - even though it is still officially restricted to Google's brand of Java, but more of that this Thursday when Mikael Kindborg will do a talk on JavaScript on the Android, among other talks (including Sony Ericsson's Strategy Manager Thomas Bailey).

The process running up to the Hackathon was almost Kafkanesque in nature. Not at the beginning, where Bwin Games agreed to host the Hackathon (on a Saturday) at their lavish premises in central Stockholm. Later, when it was apparent that the budget was rather tight at Q4 (in (yet another) year of recession) to provide dinner - something I felt was a necessity for an event stretching from 9.00am to 8.00pm.

After getting literally dozens of great leads after I reached out to the community, on twitter (I'm @psvensson) and beyond, I had as many as four different companies that tried to find resources within their organizations to no avail (but thanks for the effort nonetheless!). Finally I got a possible sponsor, but then it turned out that sponsorship is a sensitive issue and the company in question had agendas parallell to that of Bwin for providing the venue in the first place.

With only days left, I had to call in the cavalry and use my contacts at Google (Thanks Serge and Stephanie!) who agreed to take the bill for the dinner.

What? You want to know about the Hackathon and not my orgnaizational ramblings? Why didn't you say so? Here goes:

As many as 49 people had signed up for the Hackathon, 43 on LinkedIn and 6 by direct email, and after all was said and done 33 showed up, but what a group. We got people from Plusfoursix, Isotop, everbody from Appcorn (who had attended whole day iPhone developer event the day before), HiQ, COMBOL and many others.

Several people came just to see Dirk Groten, CTO from the progressive Augmented Reality company Layar, who had graciously agreed to come up to Stockholm and demonstrate how to build service and applicaitons with their system. Layar is just at the time of this writing about to reveal their new polygonal 3D service, which lets developers created fairly complex polygons at specific geographical locations, which ups the ante a bit.

After Dirk, we had a talk from our own Johan Burell, who had a thorough walk-through of the Rokon gaming library for Android, which provides a lot of simplifying wrappers for 2D gaming, which several of the groups later used.

After the talks were done, we had a light but satisfying wraps-based lunch provided by Bwin and then on to coding.

The atmosphere during the whole day was very open and friendly. Teams helped each other out on several occasions, fixing solutions to MapView dynamic updating to getting the current GPS position.

Also, there was (at least I had quite a few :) a lot of general discussions on and off, about whether it was amoral for Craigslist to provide free advertising, thus putting newspapers out of business, the recent split of the Squeak Smalltalk platform into Pharo, CouchDb REST musings and lots of other stuff.

What I mean to say is that these coders weren't your garden variety lockergnomes, these were hard people, OK? just saying :)

Some teams borrowed meeting rooms from Bwin to doodle on white boards, but most teams huddled down in groups, hacking intently as the dusk fell over Stockholm. Actually, dusk was all we had that day, steel-blue clouds and a mere thirty seconds or so of sun.

At the end of the day, each time got one minute - sometimes a verrry long minute - to present their application. After everyone had presented, everybody present (some people had to leave before the presentations) voted by raising their hands (only one vote per person) on the app they liked best - and one was not allowed to vote for ones own. As it turned out first price went to the Bwin team with their app "Crimesweeper", which got real-time police crime scene data, and mashed it up in a MapView, awarding points for players who visited the scene (vigilante.apk?)

The second-price winners had made a very creative game app which tracked the players and plotted them on each others screens, and provided a method for throwing virtual water baloons at each other.

Then one team had made a very useful Hudson front-end for Android where you could start Java build jobs and check their statuses.

One team had made almost a space shooter with the Rokon library, but due to time constraints it was actually a "space dodger" - tasteful nonetheless.
There was an app which demonstrated a CouchDB library for the Android, something really useful.

One app which was made by an attendee who was forced to leave before the voting (please comment if you remember who - thx!) made an app for kids learning words using images and rotating letters - which was very appreciated, but got few votes. Strange, but what do you do? :)

We had another app by single-team @sharj, which used the twitter API to get a random twitter user bio and let you follow if you liked it. In the future he means to add support for recommending users based on usage patterns.

And he got another one as well, which used the recent Google Movies API to list movies and to say which ones you were going to see, foursquare-style, of sorts.

@burre83's team made a rhythm-action app, which was surprisingly catchy, tempting the player to hit random parts of the screen in time to the music.

A couple of teams did not finish, but a couple came surprisingly far, given their ambitions.

What was interesting was that so many teams had such divergent ideas, and that so many attendees came without really any prior Android development experience - and still managed to produce runnable code!

The winners and the second place teams got each a book from Apress called "Pro Android" which in my opinion is the most comprehensive one out there. The winning team also got some really nice Google drinking bottles and my very last Android keyring trinkets,which were much appreciated.

This left me with a couple of books left (since Apress had sent me 10), which after due consideration was given to to teams which I felt needed them the most, for different reasons.:)

When everything was wrapping up, we decided to go down to the local pub Bishops Arms at Vasagatan for some beers and lots of discussion - some about Psytrance and scouting if I recall correctly.

In retrospect the day went very smooth, mostyl due to the playful professionalism of all present. Also, since most of the day was spent by the attendees hacking I had several hours on and off where I could blog about my adventures in Russia and other events that needed some writing.

This had been hanging over me for some time, and it felt really good to be in a position to do something about it, between coaching sessions and general discussions.

Something that really meant a lot to me was that three separate people, on separate occasions, went up to me and said how great they thought the event was and thanked me for arranging it. Me, who really didn't do much in particular, other than yakking and blogging :)

Thank you so much! ^-^

From Russia with ow!

2009-11-28T09:55:00.000-08:00

So, I had this meeting. The rationale behind it went something like this; Google will soon be releasing certifications and courses related to those certifications to developers. That mean not only 'learn how to administer adwords' but 'learn how to develop with the Maps API' or 'learn how to make a decent App Engine app in Python', that kind of stuff.

OK.

I was talking to Shannon, who is a training and documentation manager at Google, about starting up a Swedish Qualified Education Center focusing on hardcore development rather than administrative tasks. She was going to be in Europe in the beginning of November, together with Stephanie, my GTUG boss (and a lot of other people) doing the Google Developer Days in Prague and Moscow. I was going to go to Berlin the very day of the Prague GDD, so my only option was to met her in Moscow.

Now, Moscow isn't really Europe. At all. Whatsoever. Regretting my decision daily, I began the ridiculously Kafkan process of applying for a Visa for Russia. The most poignant memory of that was realizing that they would keep my passport for a whole week (no doubt shipping it by nuclear submarine to Irkutsk to be steamed open and copied to numerous spetsnaz operatives), which had me standing in line to get my passport back in the morning, the very same day I was flying to Berlin!

Also, I was home about 8 hours from Jsconf.eu before getting in the Taxi again, going to the plane that was taking me to Moscow, seeing my family only briefly. After arriving to the commandeered cinema where the GDD event took place, I recognize the Hookah lounge from pictures Stephanie has posted on twitter (which was very helpful).

I then try (after doing some panic work for one of my favourite clients, involving a Layar REST endpoint) to talk to Stephanie (pictured with wine above, which I served her and Shannon on a Gitub coaster, courtesy of the github developers I met at jsconf) and Shannon about my training center plans. However, the place is quite noise, and a lot of people come in and ask questions about Google things, mostly directed to me, not even being a Google employee - I'm just the unofficial PR manager :).

After the evening progresses (and I haven't even checked in to my fairly remote hotel yet, schlepping around my computer case), I get invited to a Google post-conference dinner with the speaker and arrangers of the day. It was really cool to meet and shake hands with some of the Wave team, the EMEA Sales manager (hi Timbo!), The PM for the V8 JS Engine (Hi Anders!) and lots of other really cool people.

Here's a pic where the Wave team respond to the "Who wants vodka?" call. And as you can see, the food was epic. Grilled cheeses, soups, sausages, blinies, pancakes, breads, pies and so on. Thank you (again, for the tenth time) so very, very much.

Naturally, there's no real time to talk shop during the dinner, so in the wee hours, Shannon and I agree to meet the next day at the Moscow sales offices instead. Great. No problem. The very nice Russian head of office (whose name I've forgot - sorry) helps me get into a cab on the street, where he negotiates price, direction, duration, associations and who knows what to put the driver in a customer-friendly mood.

However, after 45 minutes we start to veer out into industrial areas, spotty lighting, semi-rural fields and people sitting and drinking on the sidewalk. Here my driver stops and walks out of the car.

It turns out he's asking directions from the drinking people. Good call. Sort of. He gets back in, swerves around and starts backing up for a long, long way, going here and there after that in the adjoining industrial neighborhoods. It's in the middle of the night, the driver doesn't speak English and he don't know the way. Great.

Eventually, to spare you more details, he does manage to find the hotel, and I collapse in the surprisingly roomy 'suite', knowing that I have to get up in six hours to get to the actual meeting back in the city center. Woe to you oh earth and sea, et.c.

Then the taxi I managed to get hold of tries to renegotiate the price when we start driving, which gets me so mad, I scream at the driver to stop immediately and open my door without thinking of the consequences. We'travelling quite slowly, and the driver gets kind of upset - but so am I. After some intense broken English negotiations, I get the original price and our drive continue in a communal, surly silence.

When I arrive at the sales office, two things are apparent; 1) There's no Shannon working there (I know, she's from the MTV office) and there's no meeting scheduled (since it was agreed upon in the middle of the night), which makes the security-minded secretary less than open towards my feeble efforts in trying to stay in the office. Just when I really have to leave, before the situation becomes unbearable, Shannon calls the office. That first picture with me in front of the Google logo is taken in the sales office, which happened to be the wrong office. Time for another quick taxi across town..

It turns out that a quick dash across town takes almost an hour, at which time Shannon is 15 minutes away to take her own cab back to the airport. I do find time to get my picture taken in front of the other office's logo and steal up on some iced tea (thanks!).

In the end, we conduct a very interesting meeting in the very cab back to the airport, even if it finds me twiddling my thumbs for a number of hours, waiting for my own flight to come up.

It was a roller-coaster adventure, buffeted only by the kindness of Google employees along the way. I would have had a much rougher visit ion Moscow without access to the right people (including my own connections who picked me up at the airport; Hi Alexander!), but then again, without those very people it would never had crossed my mind to visit.

Cheers,
PS

November GTUG Stockholm Meeting

2009-11-28T06:35:00.000-08:00

My apologies for not having time to blog about this sooner (Hi Steph! :) but there you go. The 5/11

meeting was a bit shorter on attendance than what we were used to. It turned out quite that at the very same day, we had attendual interference from the week-long Öredev developer event, a local Java users group meeting and an open house day at The Royal Technical Highschool (IIRC), so we got somewhere between 40 and 50 people (of which only 30 or so registered - due to some people showing up a bit late, things happens).

The order of the day was yet another Wave demo with some focus on how a Wave bot works (I used the Wolfram Alpha source code), and a thorough 2-part talk by Jonas Burell on his upcoming open-source collaborative music-making Android application called Cntrllr.

Since I had two different speakers defaulted on their presentations for this meeting, I threw in a beta of my upcoming Jsconf.eu talk on dojox.gfx cross.browser 2D graphics.

As always there was a lot of great discussions over a broad range of subjects of beers and sandwiches in the pauses in between talks, and as always great and passionate people attending. Did I mention I like arranging these things? :)

Cheers,
PS

The German Connection

2009-11-24T12:45:00.000-08:00

Hoo boy, I'm still tired from Berlin :) Or maybe it's the accumulated trips that have caught up with me. Either way it has taken me some time to get around to unload the camera and sleep and work and.. oh wait, I just realized I had planned to post about the latest GTUG Stockholm meeting. Oh well, next up I guess.

I missed the original and first JSConf in Washington, since I had a client default on me at around that time. No nice experience, double so because of missed attendance.

I was dead set at not missing the European JSConf.eu at any price, and was more than happy when I was admitted as a speaker with my dojox.gfx talk. I had never been to Berlin before and to Germany only once, twenty years ago (yes I am that old!), so I had no idea what to expect, really.

Well, two things stuck me at once: 1) Berlin is *huge*, 2) It's also beautiful. Due to the first fact, you have to take Taxi everywhere (which generally a) lack onboard GPS and Maps R2D2, b) lack any card readers, forcing you to luggage around lots of Euros).

Oh, the conference? The conference was a huge success, but more than that it was immensely enjoyable. Day one had a great opening by Dion Almaer (now, as we all know, of Palm).

What I took away from most of the speeches is that I probably need to brush up on the noble art of making slides. Dion's presentation was fun, tons of fun, and also very nice to look at. What do I have? Slapped together pictures and pages of code. Not much fun that :) Actually, that was also a theme underlying much of Dion's speech,something I know but don't react enough on - sex sells, people want to have fun, et.c.

Some other notable talks was Remy's HTML5 presentation (mot least because it contained Sharks with lasers!), The cappuccino presentation by Francisco Tomalsky was also really good, but after a lot of head-wrangling I feel that I somehow still want to code my clients and that the WYSIWYG will only get in the way. Well, right, they had stellar support for hand-coding as well. OK, OK, I admit it, I'm just jealous. There, I said it, can we move on?

The CommonJS and Server-Side JavaScript in general lay as a barely audible hum throughout the two days of presentations. A comment from Malte on how he had used Joose on the server-side, the OpenAjax guys (Hi Lieke, Mike and everyone else from Javeline), naturally who made their very own SSJS VM, and lots of other comments in and around the talks made SSJS feel very present.

The natural focus of Server-Side would of course had been Kris Kowal's CommonJS talk, which was very good in itself, but what really dropped a bomb was @ryah's node.js unveiling. Naturally, as everybody (now) knows, node.js has been going on for over half a year, but it hasn't had lots of attention. Until now. What got our attention was the off-beat assertion by Ryan

that using thread-based logic was doing everything wrong.

He talked about how he had done quite a lot of advanced magic (with threads, inside node.js) to be able to expose system events, pipes, sockets and services to be handled by JavaScript callbacks- that is node.js.

By implementing non-blocking I/O and using event handlers instead of threads, the logic for common servers and services could be made much simpler.

He had a simple IRC server going, which was implemented in its entirety in JavaScript. I have done some of that before, having fiddled with 10gen's application server, but instead of living inside Rhino, node.js includes the Google V8 JavaScript VM, and exposes system services, such as streaming file operations and DNS lookup (non-blocking you see :).

I could go on, and probably will, but for the record, node.js was the mount everest peak ascent, or maybe Roswell crash of JSConf. Nothing will be the same ever again. But in a good way.

And the partying was excellent. I finally got to met the Uxebu Dojo folks, including Nikolai Onken (@nonken), PHP, github and jQuery people, including @paulca and @furf (who just had reinvented deferred's (something I've never done)) and lots and lots of other people, champion drinkers one and all.

Almost noone managed to get hit by quick bicycle ladies in the early morning, and most of us got some sleep between the two conference days, but it was a total blast. I had also a small request from @frebro who has designed my business cards - could I possibly take a photo of them in a cool setting? Not to let him down I shot them together with both Remy Sharp and

Douglas Crockford, who were nice enough to lend their star quality to my nefarious purposes.

The day I was travelling home, on Monday, I had planned to do some general shopping four hours before the plane should lift, and then take a quick taxi to the airport some two hour later. Little did I know that this specific Monday was the 20 year celebration of the fall of the Berlin wall, unification and so on. The traffic stood practically still. it took me nearly all of the time I had to get to the airport in time.

I arrived home late in the evening, fully aware that I was leaving for Moscow 10.20 the day after. but more of that in another blog post.

And that's me in the middle. The long-haired, thin guy without a beard.

Cheers,
PS

My JSConf presentation

2009-11-08T04:35:00.000-08:00

So, still a bit tired from yesterdays awesome Nokia-sponsored party at Homebase in Berlin, I managed to survive my presentation on dojox.gfx, cross-browsed native 2D graphics. I got a lot of comments from people afterwards that they had no idea that this existed, which made me even happier for my subject choice.

And without further ado, here's the slides:

Cheers,
PS

Yak Coiffures

2009-10-16T06:09:00.000-07:00

I am a very emotional and 'colorful' person and tend to rant quite a lot about things that I deem important. Lots of those happens to fall inside an body of supposed knowledge called 'software engineering'.

I am often talking about the importance to find ways to cut down the time being spent when developing a program that is not actual programming. Currently, I'm using 'find . -exec grep ..' in various parts of various repositories trying to understand how server-side templating is causing subtle bugs in a pedestrian, yet important web service, for a customer.

But never mind that. What I want to write about today is a simple rule to follow if you want to weigh your language and/or platform of choice in terms of complexity.

Assertion: Every step that produces an intermediate file creates complexity.

Example: A compiler takes source code files and generates binary files.

Why: Each step that converts files between formats must be managed and maintained.

This is pretty hard to object to. Really. If you use Java, you need to manage compilation by either an ant file or maven, or perhaps a custom shell-script. These need to be maintained. They will not be maintained. This will lead to grief.

If you need to package your generated files before deployment, the script for that needs to be maintained. See above.

These operations are hard to duck, but that doesn't mean you shouldn't try. Every time you get one extra dot between yourself and the final, running application, that dot needs to be maintained. And that means documenting it, integrating it into other subsystems, referring to it, checking it in, adding it to a repository, what have you. Every point.

Also, frequently, they will become stop-blocks that makes it impossible to do things, until they guy that does packaging comes in, et.c.

One of the simpler ways to minimize yak-shaving of this kind is to adopt a scripting-language as your server-side language. Whether it is Groovy, SSJS, Ruby, Python, PHP or anything else is beside the point, because the main point is this;

A scripting language gets compiled inside the VM.
A scripting language has at least two steps less complexity than a compiled one

So whatever you do, for future generations of programmers: Never, ever again use a compiled language, for any project, for any reason.

Just Say No! :)

Cheers,
PS

Todays status of the Wave (unofficial) Invitation Queue Tracker

2009-10-05T03:38:00.000-07:00

There's a Wave for people to track when their invites was sent out and when the recipients of the invites got it from Google. Since I have eight wandering invites myself, and a lot of people have asked about it, here's the current status of the tracking list:

First Nomination Sent— First Invitation Received (delay DD:HH:MM)
2009-09-30, 16:30 UTC — 2009-10-01, 08:20 UTC (00:15:50)
2009-09-30, 17:30 UTC — 2009-10-01, 04:20 UTC (00:10:50)
2009-09-30, 20:43 UTC — 2009-10-01, 08:44 UTC (00:12:01)
2009-10-01, 02:00 UTC — 2009-10-01, 23:30 UTC (00:21:30)
2009-10-01, 04:00 UTC — 2009-10-01, 23:07 UTC (00:19:07)
2009-10-01, 04:00 UTC — 2009-10-01, 22:07 UTC (00:18:07)
2009-10-01, 04:00 UTC — 2009-10-01, 23:00 UTC (00:19:00)
2009-10-01, 04:30 UTC —
2009-10-01, 05:10 UTC —
2009-10-01, 05:30 UTC —
2009-10-01, 06:45 UTC —
2009-10-01, 06:59 UTC —
2009-10-01, 07:00 UTC —
2009-10-01, 07:15 UTC —
2009-10-01, 09:00 UTC —
2009-10-01, 10:00 UTC —
2009-10-01, 11:45 UTC —
2009-10-01, 13:30 UTC —
2009-10-01, 16:30 UTC —
2009-10-01, 16:40 UTC —
2009-10-01, 18:00 UTC —
2009-10-02, 15:00 UTC —
2009-10-03, 00:30 UTC —
2009-10-04, 18:55 UTC —

[UPDATE 2009-10-6]

First Nomination Sent— First Invitation Received (delay DD:HH:MM)

2009-09-30, 16:30 UTC — 2009-10-01, 08:20 UTC (00:15:50)

2009-09-30, 17:30 UTC — 2009-10-01, 04:20 UTC (00:10:50)

2009-09-30, 20:43 UTC — 2009-10-01, 08:44 UTC (00:12:01)

2009-10-01, 02:00 UTC — 2009-10-01, 23:30 UTC (00:21:30)

2009-10-01, 03:00 UTC — 2009-10-01, 23:53 UTC (00:20:53)

2009-10-01, 04:00 UTC — 2009-10-01, 23:07 UTC (00:19:07)

2009-10-01, 04:00 UTC — 2009-10-01, 22:07 UTC (00:18:07)

2009-10-01, 04:00 UTC — 2009-10-01, 23:00 UTC (00:19:00)

2009-10-01, 04:30 UTC —

2009-10-01, 05:10 UTC — 2009-10-06, 06:27 UTC (05:01:17)

2009-10-01, 05:30 UTC —

2009-10-01, 06:45 UTC —

2009-10-01, 06:59 UTC —

2009-10-01, 07:00 UTC — 2009-10-06, 06:45 UTC (5 days)

2009-10-01, 07:15 UTC —

2009-10-01, 09:00 UTC —

2009-10-01, 10:00 UTC —

2009-10-01, 11:45 UTC —

2009-10-01, 13:20 UTC —

2009-10-01, 13:30 UTC —

2009-10-01, 15:30 UTC —

2009-10-01, 16:30 UTC —

2009-10-01, 16:40 UTC —

2009-10-01, 18:00 UTC —

2009-10-02, 14:00 UTC —

2009-10-02, 15:00 UTC —

2009-10-03, 00:30 UTC —

2009-10-04, 18:55 UTC —

[Update 3 2009-10-06 8.28pm CET+1]

First Nomination Sent— First Invitation Received (delay DD:HH:MM)

2009-09-30, 16:30 UTC — 2009-10-01, 08:20 UTC (00:15:50)

2009-09-30, 17:30 UTC — 2009-10-01, 04:20 UTC (00:10:50)

2009-09-30, 20:43 UTC — 2009-10-01, 08:44 UTC (00:12:01)

2009-10-01, 02:00 UTC — 2009-10-01, 23:30 UTC (00:21:30)

2009-10-01, 03:00 UTC — 2009-10-01, 23:53 UTC (00:20:53)

2009-10-01, 04:00 UTC — 2009-10-01, 23:07 UTC (00:19:07)

2009-10-01, 04:00 UTC — 2009-10-01, 22:07 UTC (00:18:07)

2009-10-01, 04:00 UTC — 2009-10-01, 23:00 UTC (00:19:00)

2009-10-01, 04:30 UTC — 2009-10-06, 01:31 UTC (4.9 days)

2009-10-01, 05:10 UTC — 2009-10-06, 06:27 UTC (05:01:17)

2009-10-01, 05:30 UTC — 2009-10-06, 07:00 UTC (05 days:01:30)

2009-10-01, 06:35 UTC —

2009-10-01, 06:45 UTC —

2009-10-01, 06:59 UTC —2009-10-06, 07:44 UTC (05:00:45)

2009-10-01, 07:00 UTC — 2009-10-06, 06:45 UTC (5 days)

2009-10-01, 07:00 UTC — 2009-10-06, 07:00 UTC (5 days)

2009-10-01, 07:15 UTC — 2009-10-06, 07:32 UTC (5 days)

2009-10-01, 08:10 UTC — 2009-10-06. 05:56 UTC (04:21:46)

2009-10-01, 09:00 UTC —

2009-10-01, 10:00 UTC —

2009-10-01, 11:45 UTC —

2009-10-01, 13:20 UTC —

2009-10-01, 13:30 UTC —

2009-10-01, 15:30 UTC —

2009-10-01, 16:30 UTC —

2009-10-01, 16:40 UTC —

2009-10-01, 18:00 UTC —

2009-10-02, 14:00 UTC —

2009-10-02, 15:00 UTC —

2009-10-03, 00:30 UTC —

2009-10-04, 18:55 UTC —

2009-10-06, 10:00 UTC —

2009-10-06, 12:55 UTC —

-----

[Update 2 2009-10-06]

First Nomination Sent— First Invitation Received (delay DD:HH:MM)

2009-09-30, 16:30 UTC — 2009-10-01, 08:20 UTC (00:15:50)

2009-09-30, 17:30 UTC — 2009-10-01, 04:20 UTC (00:10:50)

2009-09-30, 20:43 UTC — 2009-10-01, 08:44 UTC (00:12:01)

2009-10-01, 02:00 UTC — 2009-10-01, 23:30 UTC (00:21:30)

2009-10-01, 03:00 UTC — 2009-10-01, 23:53 UTC (00:20:53)

2009-10-01, 04:00 UTC — 2009-10-01, 23:07 UTC (00:19:07)

2009-10-01, 04:00 UTC — 2009-10-01, 22:07 UTC (00:18:07)

2009-10-01, 04:00 UTC — 2009-10-01, 23:00 UTC (00:19:00)

2009-10-01, 04:30 UTC —

2009-10-01, 05:10 UTC — 2009-10-06, 06:27 UTC (05:01:17)

2009-10-01, 05:30 UTC — 2009-10-06, 07:00 UTC (5 days)

2009-10-01, 06:45 UTC —

2009-10-01, 06:59 UTC —

2009-10-01, 07:00 UTC — 2009-10-06, 06:45 UTC (5 days)

2009-10-01, 07:00 UTC — 2009-10-06, 07:00 UTC (5 days)

2009-10-01, 07:15 UTC — 2009-10-06, 07:32 UTC (5 days)

2009-10-01, 09:00 UTC —

2009-10-01, 10:00 UTC —

2009-10-01, 11:45 UTC —

2009-10-01, 13:20 UTC —

2009-10-01, 13:30 UTC —

2009-10-01, 15:30 UTC —

2009-10-01, 16:30 UTC —

2009-10-01, 16:40 UTC —

2009-10-01, 18:00 UTC —

2009-10-02, 14:00 UTC —

2009-10-02, 15:00 UTC —

2009-10-03, 00:30 UTC —

2009-10-04, 18:55 UTC —

[Update 2009-10-07]

First Nomination Sent—First Invitation Received (delay DD:HH:MM)

2009-09-30 16:30 UTC — 2009-10-01 08:20 UTC (00:15:50)

2009-09-30 17:30 UTC — 2009-10-01 04:20 UTC (00:10:50)

2009-09-30 20:43 UTC — 2009-10-01 08:44 UTC (00:12:01)

2009-10-01 02:00 UTC — 2009-10-01 23:30 UTC (00:21:30)

2009-10-01 04:00 UTC — 2009-10-01 23:07 UTC (00:19:07)

2009-10-01 04:00 UTC — 2009-10-01 22:07 UTC (00:18:07)

2009-10-01 04:00 UTC — 2009-10-01 23:00 UTC (00:19:00)

2009-10-01 04:30 UTC — ?

2009-10-01 05:10 UTC — ?

2009-10-01 05:30 UTC — ?

2009-10-01 06:45 UTC — ?

2009-10-01 06:59 UTC — ?

2009-10-01 07:00 UTC — ?

2009-10-01 07:15 UTC — ?

2009-10-01 08:00 UTC — 2009-10-07 04:49 UTC (05:20:49)

2009-10-01 09:00 UTC — 2009-10-06 18:00 UTC (05:11:00)

2009-10-01 09:00 UTC —

2009-10-01 10:00 UTC — 2009-10-07 04:13 UTC (065:18:13?)

2009-10-01 11:45 UTC —

2009-10-01 12:00 UTC — 2009-10-07 06:30 UTC (05:18:30)

2009-10-01 13:30 UTC —

2009-10-01 16:30 UTC —

2009-10-01 16:40 UTC —

2009-10-01 18:00 UTC —

2009-10-01 23:00 UTC —

2009-10-02 15:00 UTC —

2009-10-03 00:30 UTC —

2009-10-04 18:55 UTC —

[Update 2009-10-08]

First Nomination Sent—First Invitation Received (delay DD:HH:MM)

2009-09-30 16:30 UTC — 2009-10-01 08:20 UTC (00:15:50)

2009-09-30 17:30 UTC — 2009-10-01 04:20 UTC (00:10:50)

2009-09-30 20:43 UTC — 2009-10-01 08:44 UTC (00:12:01)

2009-10-01 02:00 UTC — 2009-10-01 23:30 UTC (00:21:30)

2009-10-01 04:00 UTC — 2009-10-01 23:07 UTC (00:19:07)

2009-10-01 04:00 UTC — 2009-10-01 22:07 UTC (00:18:07)

2009-10-01 04:00 UTC — 2009-10-01 23:00 UTC (00:19:00)

2009-10-01 04:30 UTC — ?

2009-10-01 05:10 UTC — ?

2009-10-01 05:30 UTC — ?2009-10-06 07:00 UTC (05:01:30)

2009-10-01 06:35 UTC — 2009-10-07 16:19 UTC (06:09:44)

2009-10-01 06:45 UTC — ?

2009-10-01 06:59 UTC — ?

2009-10-01 07:00 UTC — ?

2009-10-01 07:15 UTC — ?

2009-10-01 08:00 UTC — 2009-10-07 04:49 UTC (05:20:49)

2009-10-01 09:00 UTC — 2009-10-06 18:00 UTC (05:11:00)

2009-10-01 09:00 UTC —

2009-10-01 10:00 UTC — 2009-10-07 04:13 UTC (065:18:13?)

2009-10-01 11:45 UTC —

2009-10-01 12:00 UTC — 2009-10-07 06:30 UTC (05:18:30)

2009-10-01 13:30 UTC — 2009-10-07 04:55 UTC (05:15:25)

2009-10-01 16:30 UTC —

2009-10-01 16:40 UTC —

2009-10-01 18:00 UTC —

2009-10-01 23:00 UTC —

2009-10-02 15:00 UTC —

2009-10-03 00:30 UTC —

2009-10-04 18:55 UTC —

-----

[Update 2009-10-09]

2009-09-30 16:30 UTC — 2009-10-01 08:20 UTC (00:15:50)

2009-09-30 17:30 UTC — 2009-10-01 04:20 UTC (00:10:50)

2009-09-30 20:43 UTC — 2009-10-01 08:44 UTC (00:12:01)

2009-10-01 02:00 UTC — 2009-10-01 23:30 UTC (00:21:30)

2009-10-01 04:00 UTC — 2009-10-01 23:07 UTC (00:19:07)

2009-10-01 04:00 UTC — 2009-10-01 22:07 UTC (00:18:07)

2009-10-01 04:00 UTC — 2009-10-01 23:00 UTC (00:19:00)

2009-10-01 04:30 UTC — ?

2009-10-01 05:10 UTC — ?2009-10-06 05:33 UTC (05:00:23)

2009-10-01 05:30 UTC — 2009-10-06 07:00 UTC (05:01:30)

2009-10-01 06:35 UTC — 2009-10-07 16:19 UTC (06:09:44)

2009-10-01 06:45 UTC — ?

2009-10-01 06:59 UTC — ?

2009-10-01 07:00 UTC — ?TC — ?

2009-10-01 07:15 UTC — ?

2009-10-01 08:00 UTC — 2009-10-07 046:49 UTC (05:2018:49)

2009-10-01 09:00 UTC — 2009-10-06 18:00 UTC (05:11:00)

2009-10-01 09:00 UTC —

2009-10-01 10:00 UTC — 2009-10-07 04:13 UTC (05:18:13)

2009-10-01 10:?? UTC — 2009-10-08 ??:?? UTC (07:??:??)

2009-10-01 11:45 UTC —

2009-10-01 12:00 UTC — 2009-10-07 06:30 UTC (05:18:30)

2009-10-01 13:30 UTC — 2009-10-07 04:44 UTC (05:15:15)

2009-10-01 13:30 UTC — 2009-10-07 04:55 UTC (05:15:25)

2009-10-01 14:30 UTC — 2009-10-09 04:00 UTC (07:13:30)

2009-10-01 16:00 UTC — 2009-10-09 01:30 UTC (07:09:30)

2009-10-01 16:30 UTC —

2009-10-01 16:40 UTC — 2009-10-08 22:50 UTC (07:06:10)

2009-10-01 18:00 UTC —

2009-10-01 19:30 UTC — 2009-10-09 01:17 UTC

2009-10-01 21:00 UTC — 2009-10-09 00:55 UTC (07:03:55)

2009-10-01 23:00 UTC — 2009-10-08 23:25 UTC (07:00:25)

2009-10-02 15:00 UTC —

2009-10-02 21:00 UTC — 2009-10-09 01:25 UTC

2009-10-02 06:30 UTC ---—

2009-10-03 00:30 UTC —

2009-10-04 18:55 UTC —

----------

[Update 2009-10-11]

First Nomination Sent—First Invitation Received (delay DD:HH:MM)

2009-09-30 16:30 UTC — 2009-10-01 08:20 UTC (00:15:50)

2009-09-30 17:30 UTC — 2009-10-01 04:20 UTC (00:10:50)

2009-09-30 20:43 UTC — 2009-10-01 08:44 UTC (00:12:01)

2009-10-01 02:00 UTC — 2009-10-01 23:30 UTC (00:21:30)

2009-10-01 04:00 UTC — 2009-10-01 23:07 UTC (00:19:07)

2009-10-01 04:00 UTC — 2009-10-01 22:07 UTC (00:18:07)

2009-10-01 04:00 UTC — 2009-10-01 23:00 UTC (00:19:00)

2009-10-01 04:30 UTC — ?

2009-10-01 05:10 UTC — 2009-10-06 05:33 UTC (05:00:23)

2009-10-01 05:30 UTC — 2009-10-06 07:00 UTC (05:01:30)

2009-10-01 06:35 UTC — 2009-10-07 16:19 UTC (06:09:44)

2009-10-01 06:45 UTC — ?

2009-10-01 06:59 UTC — ?

2009-10-01 07:00 UTC — ?

2009-10-01 07:15 UTC — ?

2009-10-01 08:00 UTC — 2009-10-07 06:49 UTC (05:18:49)

2009-10-01 09:00 UTC — 2009-10-06 18:00 UTC (05:11:00)

2009-10-01 09:00 UTC —

2009-10-01 10:00 UTC — 2009-10-07 04:13 UTC (05:18:13)

2009-10-01 10:?? UTC — 2009-10-08 ??:?? UTC (07:??:??)

2009-10-01 11:45 UTC —

2009-10-01 12:00 UTC — 2009-10-07 06:30 UTC (05:18:30)

2009-10-01 13:30 UTC — 2009-10-07 04:44 UTC (05:15:15)

2009-10-01 13:30 UTC — 2009-10-07 04:55 UTC (05:15:25)

2009-10-01 14:30 UTC — 2009-10-09 04:00 UTC (07:13:30)

2009-10-01 16:00 UTC — 2009-10-09 01:30 UTC (07:09:30)

2009-10-01 16:30 UTC —

2009-10-01 16:40 UTC — 2009-10-08 22:50 UTC (07:06:10)

2009-10-01 18:00 UTC — 2009-10-09 01:05 UTC

2009-10-01 19:30 UTC — 2009-10-09 01:17 UTC

2009-10-01 20:45 UTC — 2009-10-09 01:44 UTC (07:05:00)

2009-10-01 21:00 UTC — 2009-10-09 00:55 UTC (07:03:55)

2009-10-01 23:00 UTC — 2009-10-08 23:25 UTC (07:00:25)

2009-10-02 15:00 UTC — 2009-10-10 08:00 UTC

2009-10-02 15:30 UTC — 2009-10-11 14:30 UTC (08:23:00)

2009-10-02 21:00 UTC — 2009-10-09 01:25 UTC

2009-10-02 06:30 UTC —

2009-10-03 00:30 UTC — 2009-10-11 01:40 UTC (08:01:10)

2009-10-03 04:45 UTC — 2009-10-11 00:45 UTC (08:20:00)

2009-10-04 18:55 UTC —

2009-10-07 16:44 UTC — ?

------------

Note that this list is updated and maintained manually by people who want to share information, so I take no responsibility of the accuracy or completeness of the information in it. It does look like something hit the fan last Thursday which made everything stop invite-wise. My guess is that when whatever it is they're doing is finished, invites will start to appear again.

I'll update this post whenever I get new info on the status of Wave invites.

Cheers,
PS

GTUG Stockholm meeting 1/10 2009

2009-10-04T08:06:00.001-07:00

This last Thursday was incredible! I had hoped to get at least as many attendees as last time, but I got even more. I counted to 90 people sharp, but I might have missed one or two. Also, people lined up in front of the registration desk instead of bolting for the beer (as I would have). People were very nice, courteous and happy. Even when Google's Serge LaChapelle was unable to connect to the projector and was forced to switch to a smaller panel-mounted TV.

We got people from Bwin, Mindspring, Tieto, Skype, KTH, Skatteverket, Unibet and *lots* of other companies and organizations. Between the sessions we had discussions breaking out everywhere. Also interesting was that between 25-50% of the people present had done some or a lot of Android development, which only made the big announcement even nicer: Bwin Games AB will host GTUG Stockholm's Android Hackathon the 28/11. Details will be forthcoming during the coming week.

The schedule for our second GTUG Stockholm meeting was as follows:

17.30 - 18.00 Mingle. Register at the laptop.

18.00 - 18.10 Presentation Ottoboni / Peter S.

18.10 - 18.20 GTUG Stockholm news / pres.

18.20 - 19.00 Johan Nilsson, Bwin; Android/iGlaset

19.00 - 19.30 Break

19.30 - 20.00 Serge LaChapelle, Google, om Gmail Video Chat

20.00 - 20.30 Jacon Gyllenstierna, Enemy Unknown on OpenSocial

This was great since it cut my time talking down from pretty much the whole time, last time, to just presenting the event and the sepakers. Don't get me wrong, I love talking, but I feel that it is better for the community to have lots of different speakers with lots of different experiences.

First off was Johan Nilsson, from Bwin, who presented two useful Android apps he had made; STHLM Travelling and iGlaset. We got some good practical examples on what to do (and not to do) when developing an Android app and lots of good pointers to resources.

Then came Serge LaChapelle from Google Sweden, originally working for the Swedish company Marratech, which was bought by Google some years ago to use Marratech's technology to create what was to become Gmail video chat. Serge did a great presentation with a live video demonstration and dozens of technical questions asked by the attendees, like which was better of GMail chat and Skype (both have their strengths and weaknesses), How much overhead the new H264/SVC codec demand (1-2% CPU tops), why they don't use SIP (since they build everything on top of Gmail chat and XMPP, it felt cumbersome to create a separate infrastructure. Google have apparently really good internal oomph for juggling XMPP (pusubhubbub anyone?)).

Our last talk was Jacob Gyllenstierna from Enemy Unknown who did a great presentation on how OpenSocial works and how the cotnainer (web site) interacts with the OpenSocial apps. These guys are interesting because they are one of the few companies I know of that have created their own OpenSocial compatible platform (in Ruby, no less) and have OS applications created by the community which ties directly into their services. The also do consulting, if you have an OpenSocial project that you need developed. Normally I'd recommend myself, but these guys are just much tougher :).

One of the more interesting things that was brought up over beers after the main talks was that several people wanted some more business-oriented information, like someone who has implemented Google Apps for an existing customer, or sales-oriented certfication for different Google Products. Google does have some certifications available, and more will be forthcoming, but I will take this to heart and try to have some more nuggets avilable for the business oriented Google Entepreneur next time. promise!

[Update: More (and better.. ahem) pictures from @vilcans: http://www.flickr.com/photos/10185883@N05/sets/72157622370852645/ ]

1] Slides from Johan/Android

http://docs.google.com/present/view?id=djszmqj_2d584vcdw
2] Slides from Serge/GMail video chat
http://docs.google.com/fileview?id=0BxFzwqvEUKapOTFiMjI1NTYtMjU2ZC00MDA1LTkxMDAtZGZiZGZhYThiMzdh&hl=en
3] Slides from Jacob/OpenSocial

http://www.slideshare.net/jgyllenstierna/opensocial-gtug-stockholm-meeting-oct-1-2009

Presenting at JSConf.eu

2009-10-02T06:38:00.000-07:00

Wow! I will be presenting at JSConf, together with most of the really cool people I know. I'm really happy and proud to be chosen to attend this Battlestar Galactica Epic conference dedicated to just JavaScript, the best of the best. :)

You can peer at the bearded fellow in the presentation abstract here (I'll talk about the dojox.gfx and dojox.charting cross-browser graphics packages); http://jsconf.eu/2009/speaker/peter_svensson_-_using_dojoxgf.html but just in case, the text is copied below;

Peter Svensson will give us deep insights into real-time 2D graphics in the browser.

The Dojo Ajax Toolkit has a multitude of different features that help save time for the harried JavaScript developer. One of the most powerful and yet least known is the Canvas like dojox.gfx API, which adapts itself to the browser's 2D capabilities. It can use VML, SVG, Canvas and Silverlight, depending on what the browser supports. On top of the dojox.gfx library is also built the dojox.charting API which leverages the cross-browser graphics of dojox.gfx to provide snappy, versatile, themable and configurable charting with tooltips, dynamic scaling and general eventing.

Peter's Bio
Peter Svensson is an entrepreneur and Java developer turned Ajax and JavaScript evangelist.
He is a contributor to the Dojo Ajax Toolkit and author of the book "Learning Dojo". When not talking at conferences, he's busy developing his company "Hermit Village" with competences ranging from Dojo, Android, and App Engine to OpenSocial, Layar and Google Friend Connect. He is also the organizer of the Scandinavian Web Developer Conferences and the Google Technology User Group for Stockholm, Sweden.

---

What? There was an equally Epic Google technology User Group - Stockholm meeting last night, with over 90 people present. True, but this has been a hectic week and I really need to sleep first before attempting that post. Coming during the weekend though. Films at eleven. beep.

jQuery workshop in Stockholm with Remy Sharp

2009-09-17T03:46:00.000-07:00

For the first time in Stockholm, Sweden. Hermit Village in conjunction with Left Logic proudly presents a 1-day workshop with the acclaimed jQuery contributor Remy Sharp.

The workshop will be held October 22 at DFS, Vasagatan 8-10 in Stockholm, right across the central station.

Remy Sharp is a world-class JavaScript and jQuery guru who not only speaks at, ut organizes his own conferences.

Read more about him here, and check out the upcoming Full Frontal JavaScript conference here.

Workshop details:

You'll be learning jQuery from a practical point of view: what you can use out of the box to quickly get effects and interaction live in to your wireframes, prototypes and web sites. The aim *isn't* to teach you JavaScript, but to teach you what you need to know to be able to leverage jQuery to do your bidding.

The workshop will cover topics such as:

JavaScript & debugging basics: how to fake it as a JavaScripter
Progressive enhancement & Graceful degradation - what's what
jQuery: how do bend the DOM to your will
Effect and animations - things that go whizz bang!
Ajax: it's even simpler than you think
Using jQuery UI for instant widgets, for zero work

The workshop audience is aimed at beginners to intermediates - and it's very hands on!

We'll start with covering the basics of JavaScript so that you have a good grounding and you can fake your way through coding. This will include anonymous functions, scope, context (what 'this' means in different places) and objects. Then we'll move on to tabbing systems, how they work, how to recognise them when they don't look like tabbing systems, and then on to the juicier stuff such as effects, Ajax and jQuery UI.

To register for this workshop, mail organizer Peter Svensson at psvensson@gmail.com

The price for this one-day event is €495, but if you register before October 1, you will get an early-bird price at €400.

Also, BYOL (Bring your own laptop)

Cheers,
PS

Striking our on my own - while remaining employed

2009-09-16T01:46:00.000-07:00

Into the loking-glass

After a long period of medium-sized soul searching, I am finally starting my own company.

What's funny is that I'm not quitting the company I work for, Nethouse, which I had fully expected when drawing the plans for my new venture.

I have been employed by Nethouse (a Swedish consultancy firm) for over four years and I even though the colleagues that have left the company, have done so on amicable terms, starting what could be interpreted as a competitor (...) made me take measures to be able to jump ship very soon, as I could not count on applause from my boss and current company.

Unexpected support

Now, what happened was that we had a complete mind-opener of a conversation. Far from being cross (I would suspect that my boss had anticipated some sort of move on my part), he was very reasonable and suggested that I continue to work part-time for Nethouse, but in a business development position instead, as they/we are moving towards a new positioning in the market (which I wholly support and am actually quite exited about).

Coopetition

So will I or won't I compete with my current/former company? Well, for over two years I have been the only one in the company with an inclination and competency in front-end web development, since Nethouse has vey much been a .Net shop with some Java inroads - the classical consultancy company, in fact.

So my new clients are mostly international, which I have garnered through this blog and various conference appearances during the last years. Our clientele don't really overlap, so to speak. On the other hand, my expert knowledge is handy for some local customers as well, even if there is not yet so much demand for cutting-edge Dojo front-end applications in Sweden.

Happy start

All in allm this only proves that you can never predict what will happen when you make a sea-change, neither who will be your friend.

So on November 1, I will start on my new company (tentatively named Hermit Village - after the Monty Python skit, and the interconnectedness of actually single individuals that the Internet provides), working 75% with my newfound customers and the rest with secret plan X for Nethouse world domination (it's large, we'll fit all of us :)

And by them, I promise to cut down to only ten or so side-projects. Really!

Cheers,
PS

First GTUG Stockholm meeting!

2009-09-07T01:37:00.000-07:00

After lots of preparation, sleepless nights and thrown in as a happy spanner in the midst of all other activities, the first GTUG Stockholm meeting managed to fly off the runway without as much as a single missing wing or fuselage.

I was on place at Ottoboni as early as possible, since I have had many years as an instructor, wise to the ways simple things can take a long time to fix in the last minute.

Ottoboni have floor 12 and 13 in a very 1998 kind of building. Lots of glass, space and white, wide tables. Nice.

Here's the final schedule for the evening:

17.30 - 18.00 Mingle. Getting machinery to work :)

18.00 - 18.10 Presentation Ottoboni /Google /Peter S.

18.10 - 18.45 Google Code. APIs and stuff!

18.45 - 19.15 Beer break (and some food)

19.15 - 19.45 Google Wave presentation / demo

19.45 - 20.00 Break

20.00 - 20.30 Android development (AR)

20.30 - Later Chat, breakout sessions, beer.

Me and Markus from Ottoboni dashed back and forth to aarrange chairs, tables, cables and whatnot. On a ussgenstion form Markus I created a quick Google doc which I shared with him, and which he opened on a portable inside the enterance to let people register themselves, and it worked! Or it worked somehwat, because it wasn't easy to find the portable among all the people pouring in, but we got almost 40 people registering themselves as GTUGers among somwhere above 60 attendees, which quite OK in my book.

Above sits half of our participants, waiting for me to stop taking pictures and get on with it already.

We got Daniel Rytterstöm from Google Sweden (right) to annoint our first meeting, and Markus Blomkvist from ottoboni (left) welcomed everyone to the posh venue. In between them we see a cautious-looking local JavaScript hero Robert Nyman.

We were actually supposed to have an Engineer from Google to speak on some topics, but he had to pull the plug on some Gmail servers (just joking! :) so I had to speak for the entire event (as usual), but at least I couldn't complain over the quality of the speakers..

During the evening I took a poll on what theme people would like to have for our upcoming (TBA) hackathon, and I must admit I was siltenly rooting for a Wave hackathon, the overwhelming majority opted for an Android hackathon (which is really, really OK as well, naturally) and we're now trying to uncover the identity of a Google Sweden employee who is a truly savvy Android developer and can help me talk between hacks at that event. more to come on that one.

I want to thank Ottoboni for being such gracious hosts, for Google Sweden for delivering such large quantities of beer and wonderful, varied, small sandwhiches (watchamacallits) to the event, and of course all of you who attended.

Måns Jonasson (who helped me demo Wave) have some variable quality videos from the event taken from his non-Android mobile phone, and can be viewed here; http://bambuser.com/channel/MungoBBQ/broadcast/256538 (Watch out for that bearded fellow in the last one)

The morning after, I was whisked off to a two-day conference, so I felt I missed a lot of tweets and other commentary, but in all I felt that the event was well received. The next time will be October 1st, and I will put up a LinkedIn event for that as well, and mail out to all of you who registered in good time.

Also note that all GTUGers can get up to 40% discounts on any Oreilly, Apress or Packtpub book, if you mail me about it (I have teh s3cret c0de), since GTUG Stockholm (thanks to Stephanie at Google) is a User group for all three publishers.

Thanks!!

[Update: Ottoboni has a post up at their site with some more info and way better pictures: http://www.ottoboni.se/sv/Bloggen/Sveriges-forsta-Google-Technology-User-Group/]

Cheers,
PS

The Joys of Android

2009-08-29T02:50:00.000-07:00

Positive feedback:

Instead of continuing to bash the flotsam of obsolete programming languages like I did last week, today I'm going to describe a really nice experience I just had in the programming department instead; Developing an Andoid application.

Enter the Client:

The specification that my client had was clear; He wanted a demo/PoC of a smartphone application (iPhone or Android) that among other things first showed a Google map of an area with some markers on it, and when one of the markers was clicked, it would switch to augmented reality mode (AR) to display the markers in an overlay on top of what the camera in the phone dislay, so that people can orient towards points of interests in 3D using local landmarks.

And it was supposed to be done in under ten days. It sounded crazy hard to do, and at first I asked a couple of iPhone developers I knew if they could take it on, but they had their hands full, so I did some more research to see if I could do it myself.

Layar to the rescue:

It turned out that a very interesting Dutch company called Layar, which develops an Augmented Reality service by the same name. That's right, it's a service. That means that if you can get your user to download their (free) app from the Android appstore (iPhone support is coming soon, as a high priority), you can create your own headless REST service which pop up among available AR layers to choose from.

Here's a list of the currently created layers. If you get a quick idea of what you could use an AR layer for, it's probably already been implemented :) so check there first.

That means that 'all' I had to do was to create an android app that showed a map, and when clicked started the Layar app and pointed it to a special layer that I could create once I got my deveoper keys from Layar.

Luckily, I had just formed the Stockholm GTUG( Google Technology User Group), which among other things was eligible to receive review copies of books from O'reilly, Pragmatic Press and others, so I had several good Android books to browse through. Then I went out and bought myself a HTC Magic with extra toppings and flat rate internet.

SDK impression:

I used (naturally) Eclipse 3.4 with the spanking new 1.5v3 Android SDK which contained Google API support for maps and other things. It was very easy to get started, despite using Java. The APIs for various funcitons were mostly sane, meaning that they could be used without creating four extra levels of classes and the methods you really wanted to have for convenience sake were there, instead of missing so you had to write them yourself (classic Java).

My first try in developing the app used an internal webkit inside an Android app. I was really happy to find examples on how to do this in one of the books, since that meant that I could focus on effective development (in JavaScript) for a brwoser pretending to be a 'desktop' application.

I managed very quickly to embed a Google map in the 'internal' web page, and writing a shim that let me call Java methods from JS (and vice versa) was very straightforward.

The downside of this method was that (at least for the HTC Hero) it took over 15 seconds for the app to initialize. If tha map hadn't been the first screen, I could probably have used a background thread for webkit initialization, but I ended up ditching the browser method - despite its clear advantages.

Instead I found a View (A view is a kind of layout manager, which organizes other content for the Android app) called the MapView. I recommend following the 'official' example (which has a few typos in it), here. This view demanded a special application key from google code (You can get one here), which turns out to be a critical piece to do right. The problem is not obtaining the key, but to use the right public key from you SDK when applying for one.

Killer Keys:

There's a default keystore created for you when you install the Android SDK which has no password, and using the signature of that results in a developer key which only works inside a debug version of an app, so if you generated an .apk file and sign it using another keystore, the maps API key in your app will not work.

This is really simple and sound straightforward when I write it here, but when you're developing, it is very simple to forget to change codes and/or to forget which key signature to use when applying for one. This in itself would be very simple to spot if you get an error, which you don't.

What happens is that your markers show up at the correct place in the mapview, but the map is clean, consisting of just a thin grid of grey lines. The first times you see this, you immediately think that you have made a coding error, since the mapview do actually force you to create extra classes, implement extra methods and do the work that you really needed support for yourself - in a true, classical Java style.

So if you ever get those gray lines - I'd give you a 90% chance of having used the wrong keys somwhere. Just so you know, OK?

Once I got the mapview working, I needed to trap the screenpresses, so I could launch the Layar app. This is where Android started to shine. For every application in Android you can define different 'Intents' which are for all effective purposes 'Events'. So in an (ugh) external XML file, you define which intent string your app listens for and which class and method handles those intents.

Effective use of Events:

This means that each an devery app has an intent that starts it. This also means that it's possible to define intents that the app traps and handles before it has even been started (and which can start it on demand). I used this as a finishing touch, letting the app listen to incoming SMS, searching for a keyword. When it found the keywork it sent a message to the intent that started the main application. Worked like a charm :)

I also used this method when starting the Layar app. By browing through the log that I got from a shell that displayed ./adb logcat from my physical device (The HTC Hero) over USB, I saw the classname for the Layar App (com.sprx.layar), which I then used to create a new activity object, like this;

Intent intent = new Intent();

intent.setClassName("com.sprx.layar", "com.sprx.layar.Main");

...

intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);

this.startActivity(intent);

And that's how an app start's other apps in Android. Pretty simple, isn't it?

Layar works like this;

1) You apply for a developer key here.

2) You login to Layar and create and name you first layer.

3) In the new and named layer, you point out a lot of things, but most important is the url that this new layer will get its POIs (Points Of Interests, for you non-mapping geeks ) from.

4) You implement the REST based service at the required url.

5) You download a special developer version of Layar, where you can enter you developer key and which will show all your dev layers in a specific tab inside the app.

6) Load your layer. Scream, curse, despair, check logs, read up on coordinates. Check in Google Earth. repeat.

7) Success!

REST assured:

Item number (4) here sounds ominous, but it really isn't. I naturally implemented the service in Googel App Engine vanilla python. It took all of two hours to register, create, upload and get something visible, and part of that time was dinner. There was two reasons that this went fast; a) I was only doing a demo, so all POIs I returned was hardwired into the source code, b) you really only need to implemenet GET, since Layar only ever (for now :-P ) reads info from your backend.

I had a lot of small troubles converting coordinates and making them show correctly in my layer, and almsot all of them was due to rounding errors or plain stupidity on my part. When I started checking all coordinates I sent back in Google Earth (where you can just enter degree coordinates into the search field) and I found myself north of Scotland or in Dubai, I had an easier time finding my bugs.

I managed to deliver the PoC app on record time, fixing design erros quickly due to the web-based nature of both App Engine and the Layaer adminstrative interface. I'm actually a bit on an Augmented Reality tear at the moment and will present and demo the app on out first GTUG meeting next Thursday. Now for some more coding :)

Cheers,
PS

Software Complexity in Practice

2009-08-16T01:24:00.000-07:00

I had a minor epiphany last week, but have been having too much to do until now to blog about it. It revolved around the now quite common (for those who have made the effort to learn a second (or third) language properly) question:

Why does x takes longer to implement in Java than in my-scripting-language-of-choice?

And what goes for implementation also goes for maintaince, et.c.

Having had the opportunity (..) for the last two months (OK, I had a four week vacation in there somwhere :) to work with a system that was based on using Maven for everything server-side, it struck me how dangerous it is to use compiling languages at all. Listen to this;

The services ( that I am working with, in Java) are generic to a fault, and use Spring applicationContext.xml files to hold specific information such as hostnames, DAOs and a host of other stuff. Now, I have nothing in principle against using config files for properties, but when the property files start to contain logic and 'mixins' for the rest of the program, things start to get fishy.

By 'fishy' I mean hard to maintain.

So we have the following;

1) Java code which is quite generic _and_ depentent on Spring to work.

2) an applicationContext.xml file which partly describe which classes to compile in (to the Java program)

3) A maven pom.xml file which perform magic on the applciationContext.xml file (and other things) to force things like development and test environments for the service in question.

The basic premis is to be able to move the code and use it somwhere else, and just change config files. The basic problem is that the config files are (as always) not documented, even though they are now completely logically intermeshed with the code they are acting upon.

This means that if you are making a very minor change to a part of a service, the risk is high that you need to understand how the configurations files interact with your new code. This is not very modular.

Also, I suspect that one of the reasons one want to do this is to be able to use the oh-so-smart dependency injection to be able to hot-wire in new behavior in the Java classes, even after (gasp) they are compiled. This behavior being defined in various configuration files, naturally.

Duck typed languages doesn't need dependency injection (magically replacing or inserting chunks of actual logic on the fly) because they alrady have that functionality.

This means that that the Java community (and others..) have taken 5-7 years to work around a big problem and finally (some years ago) had a great system for dependency injection. The reason for this workaround is that Java is a compiled language. The compiled class-files were _supposed_ to be static and non-dynamic. It's the whole point. Errors and general no-nos were supposed to be caught at compile time. It's that kind of language.

So, many years later one finally have a solution to all this, and it's not even needed if you're using a Python, Ruby or JavaScript (et.c.) since it's an inherent part of the language. If you want to add a new functon to an object, at any time, on a lark, you just write;

foo.newfunc = function(a,b){ .....}

Now, I could have put the logic for that in a configuration file, but then I would have to have some kind of framework which read that file, which would make my work as a programmer more complex. And it's here that my little epiphany comes back into the story, namely;

1) For every extra configuration-file that link out from the file that contain the code, complexity increases dramatically.

What I mean by 'link out from' I mean that the code might be dependent on configuration file x, which in turn might be dependent on configuration file y (See maven -> Spring -> Code example above). Also 'dramatically' is not a very specific number, but since there are next to no research in this area it's all I can do to argue that all logic you can keep inside your code files lead to less complexity, even though it might lead to less flexibility.

OK, hold the horses, you might say now, all this Java-bashing is making me dizzy (thanks, that was my intention :); isn't the whole point with Java (et.c.) that the additional security of exception-checking, static typing and public/private/protected access guard you from making a lot of horrible mistakes? If we would using these flimsy little scripting languages, we would all be lost!

Well, here's another rub of mine: Static typing is supposed to help me make less mistakes. I have coded in JavaScript almost exclusively for the last three years (and almost exclusively in Java four years before that), and in all the JavaScript code I have written, not once have I sat down and cried silently, wishing for someone to hand me enforced static typing for JavaScript. It has not bogged me down, it has not made me confused, in reality it has made me more productive.

How is that? I have a creeping feeling that these 'safety features' are more good in formal proving of things than in actual engineering of stuff.

For example, I was able to quickly write a (qute shabby, but working) REST service implementation in only a page or two of (server-side) JavaScript code. The main reason for that is IMO that I didn't need to jump through hoops either creating complex class-hierarchies for the data - or- casting myself to high heaven and back - or - generating miles of try/catch code which I knew was not really needed. Sometimes the code bombed, I checked the logs, added a try/catch, and later removed it when I had fixed the problem.

So, as Steve Yegge correctly has pointed out at great length, javaScript (etc) lead to dramatically reduced Lines of Code in a program. Mostly due to the non-existence of enforced 'security'. And here is a more specific thing to chew on;

1) All security features of a programming language does not confer the same amount of benefits.

This ties back to my unspecific 'dramatical' level of complexity above. There simply does not exist any research in this area, which is sorely needed.

My point here is that for a given security feature of a langauge, you receive a certain level of benefits, but it also costs you an amount of flexibility. These are all realtive values for now. But from my personal experience, the following has become more and more glaringly obvious;

1) The lack of a security feature from a language gives more benefits from increased flexibility than the secutiry feature gave when present.

So if I use a language which already have duck-typing, I don't need dependency injection, and I don't need to manage that injection. Moreover, if I need to manage the duck-typing in any way, I might as well do it in the scripting language itself, since there is no compilation step, thus reducing complexity from linked configuration files. I can keep all logic in the code.

All comments welcome :)

Cheers,
PS

Google Technology User Group - Stockholm, Sweden

2009-08-06T00:33:00.000-07:00

OK, so summer is over. The spring became a sprint for me with customer and voluntary projects crowding me from all sides, a little conference to arrange and a new major customer to get accustomed to.

In the middle of all this, I still tried to find some worthwhile monthly communal activity, maybe not so far-out as functional alcoholics, but still good fun.

So while I was gearing up this idea, trying to flesh it out, suddenly Google, of all people, sprung the excellent idea of starting Google Technology User Groups, GTUGs for short. I grabbed the Stockholm spot within minutes, naturally :)

If you're interested in GTUGs but happen to live far from Stockholm, Sweden, I've heard that there are some oher cities around the world, where GTUGs have ben known to form, go find one for yourself, or better yet, start your own.

Starting a GTUG doesn't mean that you have to becoma part of Google, or even know anyone who works there, it's basically a worldwide coders club, where we can share each others presentations, get some T-shirts or other schwag, if we're lucky, and teach each other about Google related APIs and other technologies.

Our first meeting will be the 3/9, graciously hosted at Ottoboni at Skanstull in Stockholm. The homepage for the GTUG is here, and we currently have speaker for OpenSocial and getting started on Android development.

If you are interested in coming, please comment on this post, so we know how many people to arrange for. Thx!!

[Update: There's now also a LinkedIn group for those of you who use it: http://events.linkedin.com/Google-Technology-User-Group-Stockholm/pub/105365]

I'll see you there :)

Cheers,
PS

Sista rycket inför SWDC2009

2009-05-19T01:41:00.000-07:00

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,

Promotion for "Learning Dojo"

2009-05-12T23:55:00.000-07:00

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

2009-04-08T05:30:00.000-07:00

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

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

2009-03-27T04:23:00.000-07:00

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 :)

2009-03-10T06:20:00.000-07:00

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

2009-02-22T05:15:00.001-08:00

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

2009-01-23T00:48:00.000-08:00

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

Upcoming talks

2009-01-13T04:18:00.001-08:00

So, it is a new year which brings new conferences with it. Yesterday I sent out three proposals to three different conferences, and just one day after, one of them answered! Yay!

The conference in question is Web Tech Exchange 2009 in London, May 14-15, and my talk is on the second day, entitled "Leveraging dojo.data to build scalable enterprise applications". It does sound very interesting, doesn't it? :) Now all I have to do is write the actual talk as well.

But first of all I will do a free Dojo workshop at Svenska Dataföreningen this Thursday (15/1). I'll be covering basic Dojo widgets and how you take a simple page and add some stylish Dojo magic to it, maybe some data integration or dojox.charting if there's time for it. You have to register for it and bring your own machine. Oh, and have a local web server of some sort and download the Dojo 1.2.3 source distro as well.

Later this month I'll be holding an intense but character-building talk on Thin Server Architecture at the Swedish jFokus event, Januari 28-29.

Outstanding are stil my proposals for O'reillys OSCON2009 in San José and the NextWeb Conference in Hamburg. And do know that I need help with funding to get across the water, just so yo know. Thx! ^_^

If you want me to speak at your event, or need a workshop/course in Dojo for your company or organization, feel free to mail me at the address in the left column, or twit me at http://www.twitter.com/psvensson

Cheers,
PS

[UPDATE]

Apparently, I will not be speaking at the jFokus event in Stockholm as I initially thought. I was urged to submit a proposal last fall by the organizers, which apparently didn't look as urgent when it came down to it :)

It might have something to do with me having broken up with Java and the event is _about_ Java. Maybe. Anyway, if you still want me to talk about thing server and all that jazz in Stockholm, please let me know and I'll arrange another venue if there's enough interest. The mail address is as always on the right side of the blog.

Thx.

What makes Dojo diferent?

2009-01-10T03:37:00.000-08:00

Dojo (and also Ext, IIRC) have a couple of semi-unique features, being proper data abstractions in the client layer and extendable, hierarchical widgets systems.

I know Dojo best, so I'll use that as an example;

Data abstraction means a separate API layer between widgets (or other classes) and the actual data. All dojo.data datastores (as they are called) have the same kind of API, but manages access to data differently. For example theres one store called ItemFileReadStore, which just read in a JSON object from an url and provide it as a bag of items to widgets.

Let's say that you use this data store to provide data to a combobox which implements type-ahead (which the Dojo one does). After testing you want to have a more advance data store which only fetches some items at a time (because the amount of data on the server is too large to load at once) and caches it. That means switching to the JsonRestStore, which uses the same API as the first one, et.c.

Here are some good articles that give more meat on dojo.data;

http://www.sitepen.com/blog/2008/06/13/restful-json-dojo-data/

The widget system in Dojo let you define custom widgets and place them on the page, using a single element with special properties. Dojo scans for these elements and look up the widget definition (in a JavaScript file and the HTML template for the widget (pointed out by the JavaScript file).

Dojo then calls special functions in the widget class according to lifecycle events, and also manage unique id creation for html template elements, instantiation of subwidgets, et.c.

Dojo uses this system for all its own widgets internally, and many custom widget projects I do for customers start out with subclassing an existing widget (using Dojo's pseudo- OO). The reason this work so well is that Dojo have proper namespacing, which also correspond (but can be overridden) to directory hierarchies, so class/widget lookup is both straightforward and understandable.

At the moment jQuery have no data abstraction or widget subsystem (unless I've misunderstood jQuery UI completely, in which case I would very much like to be corrected :), and neither have YUI.

Now I've done it again. :) This is my next blog post, apparently.

Cheers,
PS

A possible solution for siteful user authentication in friend connect

2009-01-08T04:04:00.000-08:00

I just posted this to the gfc mailing list, but since it relates to my earlier post on google friend connect authentication, I'll recap here;

At the moment it's not possible to use a makreRequest call back to your server with the id and general data for the current vieweing gfc user, through Google's servers using SIGNED authentication. What that would mean is that googles servers guarantees that the data is correct and stamps it in a way, since they recently authenticated the user themselves.

Google _is_ prioritizing this, so we'll probably see a new release of the GFC API's that allows for this quite soon.

But what if you want to get the friend connect user id of the viewer anyway?

Although, having thought about this a bit, a weaker kind of security can be had if you just decide to trust the scripts running in the page.

1) You store your own custom xml file describing your own opensocial gadget on your server
2) You store the page containing the gadget on your own server.
3) When the page is loaded, it first load GFC from google's servers
4) The it tells GFC to load your custom opensocial gadget _through_ googles servers, acting as a proxy.
5) You could in essence generate the xml file containing the widget in a server-side template (ugh!) which contains a unique session cookie you keep track of on the server
6) When the widget snarfs viewer info et,c, and send it back to your server again, through googles server, using makeRequest, it also passes on the magic cookie
7) Then you might be reasonably certain that you haven't been fooled around with.

However, anything coming from the client should be treated with great scepticism, even if cookie is correct, the data collected might have been tempered with, resulting that you associate an action with the wrong user id. Still, I think this is a reasonably safe solution.

Cheers,
PS

Google Friend Connect site authentication

2008-12-18T01:22:00.000-08:00

OK. Here's the deal:

I want to use GFC to authenticate users for my site.

It sounds like it should be doable, right? I think it is, but at the moment it's kind of hard. In fact it's so hard (or I'm so soft) that I haven't been able to do it (yet). Let recap a bit what it is GFC (Google Friend Connect) does;

1. If you enable GFC for your site, you can add GFC widgets which let people comment and rate the page you add the widgets to and interact in various ways. You can also add any custom OpenSocial widget you like (AFAIK)

2. One of the widgets you must have is the login widget which let anybody 'join' your site. When they do so, Google open up a separate window which let them choose their method of authentication; Google, Yahoo, OpenId, et.c., with various suboptions in Google's case).

3. Now Google keeps track of unique users that act on the widgets on your site, let them unjoin, log in and out, and so on.

4. The original identity provider (Google, Yahoo, et.c.) is still used as always for changing password, user info, et.c.

This is really great. The immediate thought when realizing how things work is that you want somehow to leverage this great new functionality that Google provide: To have a secure, authenticated site where you don't need to manage anyones identity, password changes, et.c.

So, I started trying to do so.

The first easy thing was to create a custom OpenSocial widget on my own site, that I pull in using the custom widget option on the 'social gadgets selection' on the GFC admin site; http://www.google.com/friendconnect .

What happens is that you let GFC generate a HTML snippet that loads an open social script from google, which in turn pulls in your script - through - google's proxy server. In any event, the script resides on a directory on your server, and get to land on you page (which was just recently in another directory) and can then suddenly utilize all GFC magic - check the id and name of current viewer, his/hers friend list, et.c. Neat.

But.

If you just post this info back to your server using standard Ajax - and trust the info you get - you're lost. How can you be sure that it really was your script that send that info? No, you need to make Google's GFC server send certified info back to your server about the current viewer.

Luckily enough, there's an OpenSocial call called (..) makeRequest, which makes an ajax call through the Container (Googl'es GFC servers, in this case, since Google/GFC is the Container. The Container would normally be LinkedIn, MySpace, Orkut, et.c.) to any given destination. For example your server, which actually hosts the page where the GFC widgets are hopping about.

http://code.google.com/apis/opensocial/docs/0.8/reference/gadgets/#gadgets.io.makeRequest

Is a great place to learn what can be done with this. For one thing, you can send back some good info. My simple OpenSocial script did just this, and made sure to begin in a nice and easy manner, not forcing any encryption, using AuthorizationType.NONE, like this;

...
...
var params = {};
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT;
params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.NONE;
params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 5;
var url = "http://xxxxxxxxxxxxx";
console.log("calling url... '"+url+"'");
gadgets.io.makeRequest(url, reqcb, params);
};

function reqcb(data)
{
console.log("reqcb called....");
console.dir(data);
}
...
...

And this works well. Looking more carefully into the link above, one reads the following:

If opt_params[gadgets.io.RequestParameters.AUTHORIZATION] is set to gadgets.io.AuthorizationType.SIGNED, the container needs to vouch for the user's identity to the destination server. The container does this by doing the following:

Removing any request parameters with names that begin with oauth, xoauth, or opensocial (case insensitive).
Adding the following parameters to the request query string:

opensocial_viewer_id
Optional.
The ID of the current viewer, which matches the getId() value on the viewer person object.
opensocial_owner_id
Required.
The ID of the current owner, which matches the getId() value on the owner person object.
opensocial_app_url
Required.
The URL of the application making the request. Containers may alias multiple application URLs to a single canonical application URL in the case where an application changes URLs.
opensocial_instance_id
Optional.
An opaque identifier used to distinguish between multiple instances of the same application in a single container. If a container does not allow multiple instances of the same application to coexist, this parameter may be omitted. The combination of opensocial_app_url and opensocial_instance_id uniquely identify an instance of an application in a container.
opensocial_app_id
Optional.
An opaque identifier for the application, unique to a particular container. Containers that wish to maintain backwards compatibility with the opensocial-0.7 specification may include this parameter.
xoauth_public_key
Optional.
An opaque identifier for the public key used to sign the request. This parameter may be omitted by containers that do not use public keys to sign requests, or if the container arranges other means of key distribution with the target of the request.
Signing the resulting request according to section 9 of the OAuth specification.

So, if I could use a SIGNED request instead, the GFC proxy servers would add all the info I need and crave for my service, especially a guaranteed identity of the current page viewer. Using this unique id in my tables gives me to power to associate this identity with anything I'd like on my site. Ok. Fine.

What happens when I use SIGNED? Well, the callback function always gets back the verbose, detailed and informative error message "404: Not found", in a JSON object, but still..

Now you might think that I don't know the first thing about public cryptography, signing requests and tossing certificates about in the rich and useful variety of almost-compatible formats the joyful and friendly cooperation between related companies in the beginning of this century gave rise to, but you'd be wrong.

I can't call myself an expert (any longer), but I have quite a good working knowledge of the above. the problem here is that the documentation makes references to the public certificate of the container, which the receiving service need to verify.

great, but the Container is GFC. Where's their certificate? Maybe this is obvious, I don't know. It isn't for me, anyway. Reading another page which digs deep in the OAuth spec, I find a links I've never seen before, which let me register sites with google and deploy their public certificates;

http://code.google.com/intl/sv-SE/apis/gdata/articles/oauth.html

Has some links that lead to the registration page for web-based applications;

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

So I do just that, and use the OAuth playground;

http://googlecodesamples.com/oauth_playground/

to verify that things (seem to work).

Now, I'm not sure that my site, not being an OpenSocial container (surely!) need to register a certificate with Google, but just in case this was needed to make the SIGNED request work, I did so and played around with it.

No luck. The result stays the same; "404: not found". Great.

What I (and possibly **ALL** other site owners starting to use GFC) need, is some information. Anything of the below will be fine, if not else to give some info back to the community instead of the usual Google no-walling;

1. Here's a simple example which demonstrates how to write a simple OS gadget which post back the current viewers unique id and info.
2. Rick caught the flu last week and haven't had the time to write the example. We'll get on it in a couple of weeks.
3. We'll never give that information, stupid Englishmen! Go and boil your bottoms, sons of a silly person!
4. It's impossible to do what you want. Go back to bed.
5. Wow, that's an interesting idea. We hadn't thought of that! We'll get back to you..

Having emptied my reservoir of frustrated incompetence, I must end with stating the fact that despite all the trouble I've had in trying to get the site authentication to work, I've at least got my money's worth :)

[UPDATE]

Kevin Marks commented on one of my posts on the open social mailing list that GFC does not support signed requests at the moment. We got a number 4!! Yay! Thanks for the info, and let's hope that this gets added real soon.

Cheers,
PS

Towards a better integration of i18n in Dojo widgets

2008-12-13T11:30:00.000-08:00

Maybe this is old hat to some, but I've been doing some research into i18n and come up with what I think is an interesting way to get better integration with internationalization in layout containers.

To recap, Dojo has, and uses internally, an internationalization system which makes sure that the Cancel button button read 'Anulla' if your browser says that your locale is 'it', and so on.

I have been thinking about various ways of making the use of i18n more dynamic. My first stab at this was a small widget, which could be embedded in a page (at any amount of places) which treated its innerHTML as a key string to be looked up in the i18n system and exchanged for the actual message du jour.

This was a rather heavyweight solution (and I also wrongly used dojo.requireLocalization inside the widget, instead of by the dojo.require statements where it should be. It was just insane to do that every time an instance of the widget was created, but that's how I roll :), and was unable to handle translations of html properties, like the title="" inside an anchor element, for example.

I then thought of extending dijit._Templated (the superclass of all Dojo widgets whichuses 'normal templates) to do roughly the same for all all widget templates. But somehow it felt not really spot on for my problem.

What I had, was a number of pages, which I had been translating to a number of hmtl 'snippet' files, which only contained the markup for what they wanted to do - no body, header or stuff like that. They are used inside ContentPanes which are managed in turn by a StackContainer, which simulates page transitions but within preloaded html snippet, getting you a mighty quick site where all parts are already loaded in the browser,but only one shown at a time.

Each of these 'pages' have a lot of text, which should be translated, as well as a number of title="" and related element properties which also should be translated, so having a solution which only worked for widget templates would only solve part of the problem.

SP what Idid was to create a widget which sublassed dijit.ContentPane, and which overrode the function called when the pane is done loading remote content (the file containing the html snippet), onDownloadEnd.

dojo.provide("layout.TranslationPane");

dojo.require("dijit.layout.ContentPane");
dojo.require("dojo.i18n");

dojo.declare("layout.TranslationPane", dijit.layout.ContentPane,
{
onDownloadEnd: function(pane)
{
console.log("layout.TranslationPane callback onDownloadEnd called.");
var html = this._getContentAttr();
var res = dojo.i18n.getLocalization("layout", "salutations");
html = dojo.string.substitute(html, res);
this._isDownloaded = true;
this.setContent(html);
}
});

Not much code? No, that's because I solve my problems a) at the machine they appear, b) in JavaScript, and c) on the shoulders of Dojo. So there.

That leave me with snippet files which contain any number of ${title_of_stuff} anywhere at all, since the 'page' is treated as a string.

I think that this would be a great thing to add to ContentPane permanently, with a couple of extra properties to it, which would point out locale overide and (not optional) the name of the package and translation file to use for any ${keywords} appearing in the markup loaded.

WDYT?

Cheers,
PS

Sample chapter from my new book - Layout

2008-12-01T10:32:00.000-08:00

Promotion is a strange thing.

I mean, I have written this book and it would be nice if people read it.

However, I'm no marketing expert and despite appearances, tend to be a bit dismissive of my achievements.

Having said that, let me tell you what's great about the book I wrote;

1) It's just 250 pages long

2) It covers dojo.data in the most approachable way I could write about it - not common :)

3) It delves into as many parts of dojox as I could muster, not just the usual stuff but DragPanes, ExpandoPanes and GridContainers, with examples and tutorials as well.

4) Uses a lot of the actual (svn) source code of Dojo to show and explain different kinds of funcitonality.

5) Describes the creation of custom Dojo widgets at every opportunity.

6) Heavily opinionated.

That's not enough for you, eh? OK, grab a sample chapter on layout right here, and tell me what you think. No really, please mail me so I get some feedback on how usable it is to actually learn Dojo, since that's what the title is about, isn't it?

Cheers,

The power of Dojo i18n

2008-11-25T10:48:00.000-08:00

I had said at an early stage that I was going to use Dojos i18n system to translate snippets of text in World Change Network. Now that the time came to actually implement it, I realized I had some learning to do to get all bits and pieces right. As it turned out, using Dojos i18n system for you own purposes is really simple.

If you take a look at the unit test for i18n at http://download.dojotoolkit.org/current-stable/dojo-release-1.2.2/dojo/tests/i18n.js you see that it uses three major tricks;

1. Load the i18n strings bundle of your choice using dojo.requireLocalization("tests","salutations",locale);

2. Get a specific bundle using var salutaions = dojo.i18n.getLocalization("tests", "salutations", "en");

3. Get the specific string for a given key using salutations['hello'];

Let's check the arguments for number (1) and (2; Only the first two are needed, which describe the dojo package to look for bundles in and the name of the bundle. If you want to specify another locale than the one the browser declares, it can be added as third argument, "sv" for Swedish, when the browser would say "en-us", et.c.

All well and good, but where do we put our different version of strings? As it turns out, in the dojo/test directory a directory named 'nls' can be found. In the root of that is a file called 'salutations.js'. This is the default key-value translation that i18n falls back on if the locale cannot be found.

Then comes a host of subdirectories ; zh, nl, il, dk, de, et.c et.c., one for each locale (that you want or can define). In each of these is a separate 'salutations.js' containing locale-specific resources.

The file format look like this;

{

it: "Italian",

ja: "Japanese",

ko: "Korean",

......

hello: "Hello",

dojo: "Dojo",

hello_dojo: "${hello}, ${dojo}!",

file_not_found:"The file you requested, ${0}, is not found."

}

for the default file, and like this in the 'it' subdirectory;

{

it: "italiano",

hello: "Ciao"

}

And that's it.

I began creating a small naive custom widget, which subtituted the content of the element where it is declared with the localized string found for the content used as key. It's not very fast, but simple to understand and use.

dojo.provide("layout.translate");

dojo.require("dijit._Templated");

dojo.require("dijit._Widget");

dojo.require("dojo.i18n");

dojo.declare("layout.translate", [ dijit._Widget ],

{

widgetsInTemplate : false,

string : "",

postCreate: function()

{

if (!this.string)

{

this.string = this.domNode.innerHTML;

}

console.log("postCreate for layout.translate called. locale == '"+dojo.locale+"'");

dojo.requireLocalization("layout", "salutations");

var res = dojo.i18n.getLocalization("layout", "salutations");

console.log("Translation key was '"+this.string+"'");

var str = res[this.string];

this.domNode.innerHTML = str;

}

});

Note that I just copied the whole nls directory from dojo/test for my own uses, and edited the files, leaving the original filename intact, just in case :) A better way of utilizing i18n would be to have a base class for all custom widgets, which read in a i18n bundle, and injects all keys into each class, so that every subclass has a lot of this._i18n_command_delete (If we have a naming convention that let all i18n keys begin with '_i18n_' for example).

Then we could have all custom widget templates just sprinkle their markup with a lot of ${_i18n_command_delete} and so on, which would pull in the current value of that 'this' property of the widget when it is rendered in the page.

Hmm....

Come to think of it, it seems to be possible for this to be put inside dijit._Widget, or possibly _Templated, which would make it spread to all custom widgets automatically. The only thing needed would be to prepend '_i18n_' to all key names, so that 'command_delete' inside a bundle file would become this_i18n_command_delete in the widget.

One would also need to have a convention that this only worked if the developer put a 'nls' directory under the package directory where widgets of a certain package are declared, following the order declared earlier.

Actually, this would be a pretty neat idea. Just my fault for using a blog post instead of TRAC to add feature requests! Oh, you mean I could do it myself? OK, I'll add it to the queue :)

Cheers,
PS

Codebits 2008

2008-11-17T04:47:00.000-08:00

Last Wednesday I flew down to Lissabon to attend and talk at the SAPO Codebits conference. I had a really great time, meeting a lot of people I've only tweeted or mailed with before.

As always, Lissabon is a treat. People are helpful and very respectful. A colleague made a very spot on question today when I told him about the trip: "Would you like to go back there again soon", to which I would empathically answer Yes! :)

Many times, when you've spent a couple of days in a city you get kind of fed up on the experience, but Lissabon is not one of those towns.

It didn't hurt one bit that I left a cold and rainy Stockholm landing in a sunny and warm (17-20 degrees centigrade) Lissabon.

The Hotel (Galé 'Opera') and the venue were located in an area just alongside the 'Docas', an hours walk or so from the city centre but with a lot of rustique ambience all of its own.

I had so many things to attend to before leaving that I was only partially read up on the conference and my fellow speakers. It turned out that the conference was much larger that I had anticipated with a host of Portugals finest hackers.

In many ways the Codebits conferenc felt like Google I/O; A lot of multi-coloured couches, interesting lighting, free soda and coffee and the ability to turn to _anyone_ at random and strike up a conversation which revolved around important and interesting things, with the person in questions be able to understand you and bring his or her own into the discussion like nothing to it.

One of my personal surprises was that Mário Valente, who I knew only as a very smart person with a stupendously correct view of the current trends in web development, as well as a extremely decent Python and JavaScript hacker. It turned out he started Portugal's first ISP as well as a couple of other successful ventures - and is also in the middle of something bigger, more of which perhaps later..

We had been planning on doing some SSJS hacking during the conference but I got entangled in some late minutes changes to my book and Mário had both teaching and business issues to attend to, so it reamined a very good idea. Mário had some really good inpout on the current problems of Server-Side JavaScript efforts; 1) There's no 'killer' framework (yet) for SSJS, 2) If one were to create on, it would not be portable, due to the fact that the system APIs that RHino exposes are not the same that Spidermonkey (for example) does.

So we were thinking along the lines of arranging for a standard SSJS low-level API, based on the Java-APs exposed by Rhino (Mário's idea) so that SSJS implementors would have a stable platform to work from.

Also we're planning to do a thorough survey of the cloud or no-cloud SSJS frameworks available today to rank and get inspired by best-of-breed features.

My talk? It went OK. I managed to miss speaking to anyone in charge which meant I didn't get a headset, which meant I had to hulk under my 20.1 Inch portable Acer 9920, due to the fact that the only other mic was welded to the pulpet.

No worries though. Expect that I had the wrong settings for the TV-out in Kubuntu and had to turn my head for every slide to orient myself, having no other feedback on the screen. And I got a call in the middle, having forgot to turn off my phone, but other than that, sure things went OK.

I also had a great time speaking to Jan Lehnardt from CouchDB about REST, Dojo, Erlang and (of course) CouchDB.

On the speakers dinner I happened to sit across Mitch Altman who had a great number of things to say on all subjects possible, from electronics, dairy products and Brian Eno to art, music, war and interesting people in general. I tried to chip in with some good comments and since this is as good time as any, the books I spoke about was 'My war gone by, I miss you so' (horrible title, one of the best books I've read - not nearly as gory as you might think) by Anthony Loyd, A year of swollen appendices by Brian Eno and On a faraway beach by David Sheppard.

Another member of the table proved to have alarmingly good knowledge of the inner workings of russian botnet 'corporations', the current evolution of 'black' insurance and business agreements concerning buying and seelling botnet services, the 'double-NAT-with-homebrew-VM' solution of todays malware containers and the trend towrds the botnets becoming more of a symbiotic affair from the earlier parasitic standpoint, what with the automatic patching and maintenance that must be provided to ensure smooth runnings. A horror ride, to be sure, but not the less fascinating for that.

Actually, I spoke to so many, most of you had no cards, but please mail me if you want to stay in contact (my address is to the side on this page).

In all I met an enourmous amount of friendly and interesting people (Celso, João, Jack and everyone else) that it'll probably take me weeks to sort out the experience.

Thanks a lot to everybody involved!

A reasonably complicated custom Dojo widget example

2008-11-05T04:55:00.000-08:00

I get a lot of questions from people on how to do this and that with Dojo, sometimes very specific and sometimes about how to approach problems in general. I don't really consider myself experienced to speak about all things Dojo, I'm actually just more of a fanboy.

Most of my answers, though, boil down to some basic things, were the most common is : make a custom widget. This is key, but seemingly missing from many frameworks/toolkits today. I feel like there has been three kind of 'generations' in JavaScript usage in the browser in recent years, and many of the flame-wars and misunderstandings might be due to the fact that people have a lot of misaligned assumptions when speaking of JavaScript programming. In my view the different generations or stages has been the following;

1. JavaScript inlined in the page - Netscape 4/ IE3 kludgery [Animal House - foodfight scene]
2. Clean html with consistent and meaningful styling and classifications with all JavaScript logic in a couple of separate files which operate on said markup, transforming it, attaching event handlers, et.c. - jQuery [2001 - space shuttle approach to twin-wheel space station].
3. Client-side hierarchical components with modularized logic and templates - Dojo [Basic Instict - the single crotch frame].

First of all I'd like to say that jQuery might have a modularized templating system, where you separate widget markup from logic - I'm not experienced enough in it (yet) to tell. Please comment if you have some good references. Then I'd like to say that both Ext and JavascriptMVC has excellent templating systems for their components - in a very similar vein to what Dojo has (again, AFAIK). But I had to choose one good example out of each group, or at least it felt that way.

What do you gain by writing custom components all the time? It seems awfully complicated, doesn't it?

OK. what do you gain (in Dojo). Let's see;

1. You get an enforced structure that help you separate view and logic inside the widget.
2. You get opinionated support from the framework for automatic id generation, coupling markup elements to widget references and widget lifecycle management (certain named functions get called at certain times).
3. You get _guarantees_ that the widget is hermetically sealed, unless you do something completely stupid. This means you can take it out from one place and put it somewhere else, or change your mind about having three and putting in four instead. No colissions, no overlaps.
4. Widgets markup html snippet templates can themselves (at least in Dojo) contain other generally arbitrary widgets,. Turtles, all the way down, basically.
5. The whole mélange can be expressed in the HTML file that is actually loaded by the user with one (1) div.

But other than that, I suppose, not much.

Since I really only know Dojo, I will be using that in my example. Let's say that I want to have a widget with dynamically generated JavaScript-only 2D charts, where the charts can be dragged and dropped and reordered just like iGoogle or similar pages. Wouldn't that be cool?

Let's start with the target HTML file, which look like this:

I begin by loading some Dojo CSS stuff and the actual toolkit base itself from AOL's CDN (Google would have worked as well, of course). Then I have to configure the djConfig variable a bit so that Dojo find the local files for the widget referenced later, even though it is loaded cross-domain.

The dojo.require statements check if the referenced classes are available, and if not resolves them and load them (since the custom component 'multichart.main' is not part of dojo, I needed to point out where to find it in the modulePaths setting in djConfig earlier.

Then as just one, albeit fat, div tag, I define the draggable multichart container. As you see dojo uses custom HTML properties to let its parser instantiate widgets declared in markup (All widgets can also be created programmatically in the classical style, of course). the dojoType property declare a widget which must be loaded already. All other properties after that are inserted as 'this' properties of the instantiated widget class, if it has declared those names already. Works smoothly, truly.

I basically just pass one argument which is an associative array of names and values. The idea is that the names become title string on the charts, and the values point out urls where json data is provided to generate the charts.

The test file foo.txt looks like this:

{
series:
{
series1: [{x: 1, y: 0.2}, {x: 2, y: 0.5}, {x: 3, y: 1.2}, {x: 4, y: 0.3}],
series2: [{x: 1, y: 0.5}, {x: 2, y: 1.0}, {x: 3, y: 0.9}, {x: 4, y: 1.7}]
}
}

So nothing magic, just a json object with a property 'series' and one or more series of numbers, following the standard way of feeding the dojox.chart API.

But back to the custom widget. Since I declared that Dojo should look for widgets beginning with 'multichart' in the directory of the same name in the directory that the HTML file was loaded from, I place a file called 'main.js' there. Which looks like this;

dojo.provide("multichart.main");

dojo.require("dijit._Templated");
dojo.require("dijit._Widget");

dojo.require("dijit.layout.ContentPane");
dojo.require("dojox.layout.GridContainer");

dojo.require("multichart.chart");

dojo.declare("multichart.main", [ dijit._Widget, dijit._Templated ],
{
templatePath : dojo.moduleUrl("multichart","templates/main.html"),
widgetsInTemplate : true,

content : {}, // name - url pairs to make draggable charts out of. Must be passed from calling script / page
columns : 3, // How many columns we want to have in the GridContainer

constructor: function()
{
console.log("constructor for multichart.main called");
},

postCreate: function()
{
console.log("postCreate for multichart.main called mycontainer is "+this.test);
this.gc = new dojox.layout.GridContainer(
{
nbZones: this.columns,
opacity: 0.7, // For avatars of dragged components
allowAutoScroll: true,
hasResizableColumns: false,
isAutoOrganized : true,
withHandles: true,
acceptTypes: ["multichart.chart"] // This property must always be present, and can take any kind of widget, including your own
}, this.test);
this.gc.startup(); // When creating some dojox widgets programmtaically, you must manually call the startup() function, to make sure it's properly intialized
var i = 0; // Count for which column we'll place each chart in
var p = 0; // Count for which row we'll place a chart in
for(var name in this.content)
{
var url = this.content[name];
var chart = new multichart.chart({name: name, url:url}); // Create a custom chart with the given name and url
console.log("adding chart "+chart+" to zone "+i+", place "+p);
this.gc.addService(chart, i, p); // Add the chart to the GridContainer (This function will be called addChild in the future, for conformance with similar containers.
i++;
if (i > this.columns-1) // Go to next row if we've hit the end of the columns
{
i = 0;
p++;
}
}
}

});

It begins by telling Dojo that it contain the class 'multichart.main', then follow a lot of requiremenets which otherwise would have to be present in the main HTML file. Then follows the widget class declaration.

As you can see it inherits from two superclasses; _Widget which contain the widget subsystem logic and _Templated, which managed html template snippets.

Note the 'content' and 'columns' properties which, since they are defined here, can be passed from a markup declaration(or from a programmatic creation where the arguments gets passed in an object literal as first argument to the constructor). This also gives me a good place to put default values which will stand if not overwritten (such as 'columns').

postCreate gets called when the widget is ready for action, and here is where I usually put most of my init code. What this widget does is to create a Dojo component which mimics an iGoogle page and let the user drag, drop and rearrange all other Dojo widgets inside it. Then it loops over the argument and create any number of yet another custom component, 'multichart.chart', which is also present in the same directory.

Each widget which derive from _Tenplated can also define a html template inside a string or in an external file. I usually use external files when developing, and then use DOjo's offline build system to inline templates, compress, concatenate files inot one, et.c.

If you want to se the widget in action for yourself, you can download it as an archive here. You might also be interested in my upcoming book "Learning Dojo" where it it explained more fully, along with numerous other examples :) OK, I admit it, this whole post was mostly a shameless plug for the book, but partly I wanted to define the playing field a bit as well.

Cheers,
PS

How to define a front-end developer

2008-11-02T01:39:00.000-07:00

Devoting myself (or allowing myself to be dragged away by the carneval in childish glee) to Ajax and JavaScript the last years has changed the way I've looked at the composition of software teams and of projects. Today, the breakdown is glaringly obvious to me. But since it is the result of a kind of private mental jorney what is obvious to me need not be so to someone else.

I'm talking about the emerging role of the front-end developer, of course. Big deal you might say, I know what that guy does, but I'm not completely sure that everyobdy agree on that, hence this post.

In the days of yore, what you did on a computer was program, period. Then came specializations of different kinds, like a dot painted on an expanding baloon becomes a circle. And still the expansion continues.

The traditional breakdown of duties in web-related projects has been in browser-specific things and server-specific things. That's actually very good, since this breakdown at least in part acknowledges the client as an entity. The role of the front-end (browser) team has been to create and manage the design and looks of the application, whereas the back-end team create and manage _all_ application logic, including client states (open trees, selected tabs, et.c.).

The front-end team was to be called designers, with en emphasis on producing HTML/CSS templates and all the Photoshop magic required for the quiltwork of images needed to give an illusion of a real application.

Later on these designers were asked to do some dynamic scripting to produce effects of various kinds, effectively becoming programmers in a way, even though their original vocation was that of esthetics and visual design. I don't say you can't mix the two,I'm just saying that in my experience the two fields draw two different personalities.

And on the other end, since the server-based frameworks need to slice, pickle and transform the provided templates into something that their server-side templating system can use, they get exposed to a lot of borderline design descisions, which is not something they originally signed up for either.

The result is that there is suddenly a risk that people are required and/or forced to make decisions and produce work for which they have both a minor talent in and doesn't really feel like, personally.

But that is a dicsussion of whether or not to use Thin Server Architecture (or any of its synonyms and special cases), so let's assume that we have a sane architecture with a cleanly separated front-end and back-end (REST or RESTish, preferrably), how do we look for talent in this brave new world?

Looking at ads for front-end developers shows a plethora of confusion. First of all the same kind of job might be defined as a designer, UI expert, Ajax developer, front-end programmer, Web designer, JavaScript programmer or any permutations thereof, many of which can be applied to a true designer role as well.

Looking at the skill set that the front-end developer should have we find that he or she must be a veteran of all major US armed conflicts since WWII, be able to design, build and fly a commercial airliner, have discovered at least three different cures for cancer (of which at least should have received the nobel price in either of Medicine, Physics or Chemistry) and also be the founder of two or more major schools of painting, including cubism.

It seems that people are both a little desperate and a little confused. Let me try to make things clearer.

In todays world, we need to have a good designer. The word designer will only be used in a classical sense, i.e. visual design. Skill-set: HTML/CSS, Photoshop/Gimp/whatnot, Usability, Fonts, Color theory, et.c. Secondary skills: JavaScript, HTTP, Networking fundamentals, some Server-side language.

Then we have the elusive front-end developer. Skill-set: HTML/CSS, JavaScript, Ajax, , HTTP, Networking (latency, routing, distributed storage and processing, security), REST, XML (to argument against its use), SOAP/WSDL (see last comment). Secondary skills: Usability, some Server-side langauge.

The only changed thing with the skill-sets for the back-end team is that they no longer are forced to understand HTML/CSS and a smattering of JS, since there is no longer any server-side templates to massage.

On of my pet peeves is that there is an architect onboard, but he or she has launched the project without many times even decided on which Ajax toolkit to use. It's comparable to launching a project without having specified which back-end to use (Java? Python? Perhaps SSJS?).

Granted, in many cases the project has _not_ launched and the ad is for someone to come in as a front-end lead for the very prupose of evaulating and recommending technologies to use in the client layer, but there's still enough 'wild card' ads out there to make my hairs stand on end (all three of them).

Ok, rant over. I guess what I want to say is that the world is getting larger and more detailed at the same time, and that if you are searching for talent, you have better know what you are looking for, and take the time to be as specific as you can.

Cheers,

Google Summer of Code 2008 [GSoC2008]

2008-10-29T06:04:00.000-07:00

One of the three highlights of this young, long-haired gentleman's trip to California was to participate in the GSoC 2008 conference. Earlier this year I had been asked to become a mentor for the Dojo foundation. As you might know Google gives out enormous amounts of money each year to Open Source organization all over the world, earmarked for students so that they can afford to work on a project for their organization during the summer.

This in itself is really cool and generates (deservedly) no small amount of goodwill for Google. Being a mentor I was invited, along with some 200 other people to the conference. At first it felt a bit strange to have an open source conference. I mean, it felt like having a conference on wearing pants. It's a given, more or less. The only times I normally reflect on Open Source licensing is when I see someone walking down the street sporting a nekkid lower half.

Most, if not all of the focus of an Open Source software developer surely lies in the application or service being created. However, when arriving at the conference I suddenly understood the reason for the conference. Naturally the focus was on Open Source Software, and some of the sessions did indeed focus on project management and licensing issues, but the whole point of the conference was to get to meet the best and the brightest developers in the world - or so it felt at least.

Most people don't code at all. Of those who code a fair share, say at least 50%, just code as if it was any other kind of job. No real enthusiasm. Of those who are somewhat enthusiastic, there's maybe one in ten who are _really_ enthusiastic about programming. Of those maybe again 1/10 have the inclination or assertiveness to actually engage themselves in a public Open Source project, and of them not many decide to take on the responsibility of being a mentor (of which I could have made a much better job, actually, but more on that in some later post).

Anyway, those were the guys I met. But before the conference there was a traditional Thai dinner in downtown Mountain View. The way to the restaurant look a bit like this from the train station:

There was a lot of happy confusion, assertive Leslie Hawthorns all over the place and a resounding call to arms for the following beer bash at a nearby establishment built for this very purpose. The volume of all these programmers talking at the same time was positively deafening, despite some truly outrageously tasty local beer. I'm so sorry that I never remember names, but I hope you know who you are! Please mail me if you want to get in contact.

I met the project manager for the NTP project and was surprised to hear that something that is relied on by so many and used daily for a number of purposes is not getting the economic attention it really deserves. I met a lot of guys from Germany working on MoinMoin, and another that worked on Zope (which I have actually tried out). There was Boombox an Open Source project to replace the OS on an iPod (and other things), several ambitious bio-CMS systems (I'm a reformed molecular biologist hobbyist myself :) and tons of other people.

The party went on into the night and I was nearly unable to manage a late night dry martini at the hotel when I got home, where I had a long discussion with a couple from Alaska who liked to travel a lot (he was a geologist and she was a M&A specialist, which gave me a feeling that they were probably able to. Traveling can be exhausting in my opinion, but here were climbers of Kilimanjaro who would not agree :). They were also really nice people) discussing Obama (Yes!), various economic conundrums and how to pronounce Göteborg and whether the city in question resides in Sweden or Denmark (the former).

Sadly, since I had to be back home on Sunday, I had to leave on Saturday, leaving me only with four hours of conference. With a rapid taxi out to MTV I decided to make the most of it, and made a great number of good contacts, some with people who agreed with me that we must have met before, but could not recall when (it's just half a world away, really). Tons of good discussions on Dojo and on implenetations of REST and general information managemenet. Thanks everyone I met. It was a pleasure talking to all of you!

ANd then there was the scale-model (surely?) of the X1 spaceship. And the lebansese buffet, and the juice bars, and the Testing onThe Toilet posters (on the toilet), and the general Googly atmosphere.

Anyway, most of all; Thanks 1.0E6 to Leslie Hawthorn and Chris diBona (and the rest of the crew) for creating a wonderful experience and creative climate for all of us. And for the Google frisbees. I snacthed two to give to the kids when I got home, who were duly impressed and commenced wrecking our living room immediately :)

Cheers,
PS

Tech Talk on Thin Server Architecture and Dojo at Google

2008-10-28T07:22:00.000-07:00

While I was in the neighborhood, I managed to get invited to do a tech talk at Google's Mountain View offices this last Friday. I tried to describe the drawbacks with traditional server-centric web frameworks and to use Dojo as an example of how to build true client applications which lead to an increased efficiency for the development team and hence to lower production and maintenance costs.

People were in general very nice but razor-sharp and to the point. Very good discussions afterward focusing on build systems and SEO issues.
Here's the slides themselves;

And here is the Youtube video of my presentation as it is;

Alex Martelli was there as well, and had to comment on the size of my computer :) Erk Arvidsson who should have been my presenter (since I was so nervous I jus got up and presented myself as I usually do, sorry Erik!) took some pictures of relative computer sizes between mine and Alex's;

AjaxWorld 2008 impressions III

2008-10-28T05:10:00.001-07:00

Trying to catch up with recent events from last week. Above a shot of the comfortable room at the Sainte Claire picturing the authors own small and portable Acer 9920 and a jug of local adult beverage.

One of the talks that I had anticipated most was Chris Keene's WaveMaker presentation where WaveMaker's cloud strategy would be unveiled. Chris made away with a very thorough and Monty Python themed presentation of the state of the cloud space today, with pros and cons of diferent solutions and wit a special focus on Amazon's EC2/S3 offerings.

The reason for the Amazon focus is of cours that WaveMaker is building its own service on top of it. The presentation was unfortunately not so focussed on what WaveMaker's service would look like or work, but on clouds in more general terms. I do hope that they follow some of my suggestions and make the service more of a 'live' development environment than an IDE that happens to be on the web. Time will tell. Sometime in November the site will go live.

WaveMaker is superficially like Smartclient, TIBCO GI and Bungee labs connect (and MS popfly, et.c.)
What separates Wa veMaker from Smartclient, for example, is that Smartclient is entirely neutral towards the kind of backend being used, whereas WaveMaker projects are exportable as stand-alone WAR arhives, to be dropped in any Java-based app-server of your choice. If you have a more mixed environment, Smartclient might be a better choice, but if you run a Java-only shop WaveMaker will mean much quicker deployment.

This is also what separates WaveMaker from Bungee labs (and likes), which push PaaS (Platform As A Service) where they host and manage they produced apps in pretty much the same way Google App Engine does (Except it doesn't come with any IDE). What WaveMaker brings to the table is the possibility of choice (something Chris did emphasize very well) where you can begin hosting your own application, then move it onto (say) an EC2 virtual machine, only to take it back in-house again when the corporate infrastructure or security requirements have changed. It seems that this will only be made simpler with the coming cloud service. We'll wait and see.

AjaxWorld 2008 impressions II

2008-10-27T04:00:00.000-07:00

AjaxWorld had nearly all available conference space at the Fairmont Hotel in San José, connected by miles of carpeted classical Hotel vestibules. All talks had ample room for attending listeners, but the amount present varied (as it does) betwee different talks.

One interesting fact was that there was two different talks on server-side JavaScript; One from Jaxer and one from the Phobos project. The Jaxer demo was very good. The presenter Ian Selby made a small REST server implementation while we sat there, database tables and all. Sure, he was well prepared but still. The amount of code was very small. All portions that accessed was database was one line each. That's the way it's supposed to be, really.

I do hope that Jaxer moves away from the server-side templating stuff and instead emphasize the really nice platform and infrastructure they have in place. Cooking DOM JS on the server and pushing the rendered results to the client when JS is unavailable or wrong version is an edge-case at best, and if no JS is present, ten attaching event-handlers won't be possible anway, so in practice (having mulled this over the course of some months) I feel that there is little that a server-side DOM processingcan do that can't be done with plain CSS anyway. Please correct me if I'm wrong :)

The other Server-side JavaScript talk was by Roberto Chinnici who made an excellent presentation of the Phobos SSJS framework. In theory Jaxer and Phobo does pretty much the same thing, but Phobos is much more focussed on language integration. I think that Jaxer has something similar, but OOTB phobos can call and use any Java library or class as well as spawn JavaScript threads. Not hurting whatsoever is a (coming?) port of ActiveRecord from ruby and a low-level implementation of Gears (wich also works with Jaxer, btw).

Something that was mentioned as a feature, jMaki made me perk my ears up. I checked jMaki out briefly a year or so ago and felt pretty certain that it was something tied to JSF, which made it rabidly uniteresting from my point of view. Luckily Greg Murray, the creator of jMaki was also present and could now refute that fact. jMaki is apparently something quite separate which can be used with Java, Ruby, PHP and now also SSJS.

All well and good, surely. But what does it do? Quite. jMaki is a cross-toolkit switchboard. What that means is that you can use a from created in Dojo, attach its events to a table from YUI which readsits data using data abstractions from Ext. Is that hot or what??? In the examples available there is always some pesky server-side component needed with generic sounding names at every turn, but it does seem at his point that jMaki is not dependent ona server-side component and of so, it is pure gold.

I also saw a presentation by Brent Hamby and Geof Hendrey from nextdb.net which takes my thin server architecture one further step: no server architecture! They have a database service which can be used directly from an ajax page with full transport security. The have a model which is similar to Kerberos, where tickets are issues and encryped by the server, which also includes rules of use which must be preserved.

Netxdb.net also have an administrative interface where you can define queries and users, in a very simple manner. If you have an applicationwhere you can put most of the logic on the client and only use a data store + security, it's a very interesting solution.

All talks were recorded, but it will take up to five weeks until we can see them online (including mine), so I'll post the links to that later.

Cheers,
PS

AjaxWorld 2008 impressions I

2008-10-22T13:46:00.000-07:00

This is the first in a series of post on what I saw, talked about and experienced on the AjaxWorld conference this year in San José. The conference has just ended and I'm sitting in the hotel room after a nice crabcake burger and a glass of wine and will soon head off to Mountain View in search for a SF bookstore.

Anyway.

My impressions of the conference as a whole and of the state of the industry (which one might hope would have a correlation) is that the world is being split in two. Luckily, most people isn't particularly interested in the bad part :) What I mean by that is that a seizable portion of the talks and booths revolved around products that continue to pile complexity upon complexity on the developers to shield them from the browser.

I'm primarily talking about Oracle and Icefaces here, of course. But also talks on GWT and PHP-generated server-side templates for JS did their best to muddle the waters. Of course, this is not really fair in my part, since everyone is trying their best to solve the problems as best they can. If it so happens that someone has struck upon a substandard architecture and haven't had time to think through all the angles, it's certainly not because of malign intent.

On the whole I was happily surprised to see a lot of companies present whose products and talks were attracting a lot of attention, who were in essence advocating thin server solutions across the border, wholesale. Smartclient from isomorphic has grown a _lot_ since I checked it out a year or so ago.

They have basically built 50% of Dojo all by themselves, for their client side framework, and I couldn't help but thinking: Agnostics what a waste! How much time it must have taken them. And then immediately: Wow, that's really smart, we should have that in Dojo :) What I was most impressed with was their efficient focus in metadata. Nowadays we have JSON-Schema, which was not a luxury they had when they started out, of course. They have a tool which let you import schemas of different formats, though, so JSON-Schema support is probably on their radar.

Why is schemas so important? Well, they have many (all?) components schema-aware, so that if you attach a schema to a Form component, up pops a form with the correct fields, date fields have a datepicker, int fields have validations for integer values and so on. Also, the form gets generated by itself, of course, and can be remaking itself dynamically. Why don't we have such a thing in Dojo? Actually, there's no reason at all, but right now I'm blogging. Also their grids work in the same way, and have a couple of extra features like sort fields which can be enabled for any column (filters).

My only gripe with Smartclient is that the web-based IDE is non-free (but they have a 60-day demo), and also that they have written a whole new toolkit instead of leveraging jQuery, Dojo, Ext or something. Their toolkit is LGPL and all, but still think that it would have been simpler if they hadn't been so monolithic. Now, I _am_ just grumbling. the Smartclient DIE was absolutely wonderful with tons of smart components and a clean separation o f concern between the client being created and the services it consumes. Very good.

UPDATE: As @ckendrik points out in the comments below, when the first versions of Smartclient were created, no toolkits were available (2001), which explains both the long list of features and the reason for a homegrown solution. I'm not at all suggesting that Smartclient is fracturing the framework space. It is actually very uncommon for companies with similar products to actually leverage an existing framework; Appcelerator, TIBCO, et.c. have their own frameworks as well. This is very much alleviated by the fact that many companies are starting to provide bridges to other frameworks; Smartclient have extension for GWT interaction, for example.

Coming up: " jMaki - buried treasure", "WaveMakers upcoming massive cloud gambit", "Lessons learned around Mars" and finally "SSJS - the only way forward".

Your trusted uncle in San José,
PS

Codebits in Portugal

2008-10-15T07:13:00.000-07:00

My presentation for Codebits in Lissabon, Portugal just came up. I hope not too many people go to both AjaxWorld and Codebits this year :)
http://codebits.sapo.pt/intra/s/speaker/10

Thanks 1.0E6 for Mário Valente for recommending me as a speaker. I haven't been in Portugal for over ten years!

Cheers,
PS

Academic exercises

2008-10-15T06:11:00.000-07:00

A couple of weeks ago I was invited to speak for Bleking Tekniska Högskola (BTH) here in Sweden on the subject of Thin Server Architecture, which was something I just couldn't turn down, even though I'm in deep in several other things at the moment.

At my suggestion, I also made a couple of slides with exercises for the students in basic Dojo widgetry. Then I rememberd how confused I had been when I began to learn Dojo and the peculiarities of JavaScript like closures and Object Literals and such things, so I had to do some quick slides on those as well.

A lot o thanks goes out also to Stuart Langridge, whose presentation "secret of javascript closures" I was able to use, instead of writing my own :) It saved a lot of time.

All in all I was surprised in how many of the students that understood what I said, that was able to (or wanted to) follow the exercises and came up with good questions, and also had already seen the crockford vids on 'advanced javascript'. These guys were really up to speed! OK, they had only worked with jQuery/Mootools concatenation style toolkits before, so the relatively 'classic' coding style of Dojo was something new.

What I also realized is how truly huge Dojo is, when I tried to do a quick feature rundown. The 2D cross-browser Gfx, the charting support, fx and easings. Especially the animations was fun to show, as they're really completely generic and can be used to morph from one CSS class to another, or to change color, or to move an element on the page, according to the easing rules which determine how fast or slow to change the values over time. That's really slick.

Thanks to all the students (and teacher) for having me, and having tried this out I can say that I'm now officially prepared to teach at other places as well :)

Cheers,
PS

Conferences come in groups

2008-10-07T10:50:00.000-07:00

I'm trying to find time each day to finish my presentation for AjaxWorld, which I'll present the 20th this month in San José. I've got permission from Kris Zyp from Sitepen and Ganesh Prasad of SOFEA fame to loan their pictures for various slides, so there's hope that I'll have something more than text in it!

The title of the presentation is "Practical Thin Server Architecture with Dojo" and I hope to live up to the title, even though I won't be doing more than talk and dance.

I spoke to Leslie hawthorn at Google when I visited the Open Source Offices (and got a spanking nice T-shirt :) this summer about doing a tech talk (apparently called 'Google MTV' internally) on the subject of Thin Server Architecture, which I just got confirmed. It's the 24th October in the middle of the raging Summer of Code unconference (which I'll also hopefully attend).

That's two talks of the same kind the same week, which is OK. But what happened two weeks ago was that I got a mail from Mattias Schertell at Blekinge Tekniska Högskola (A technical unversity in Southern Sweden) which wondered if I could do a day of workshops and talks around the subjects (TSA and Dojo), which I accepted, and I'll fly there Tuesday next week. I have to remake a couple of exercises I've been writing a while ago this weekend, to get them up to Dojo 1.2 speed. Mental not to self and all that.

Then a friend asked if I couldn't speak at a Swedish conference (on Ajax, et.c.) also next week, the 16th, which I could, so that's another engagement right there. There's another conference by the same organization in early 2009 as well, so...

Anyway, completely unconnected comes an email from Pedro, a Portuguese organizer for the codebits 2008 conference in November this year which also invites me to speak, and how can I say no to that!

So all in all it seems that my future is filled with glaring lights, repetitions and pointed questions :)

On the plus side, my next chapter to be rewritten in response to proofreading for the book is due as far out as October 19, which feel really far off at the moment. I've managed to do some coding on World Change Network, but still hope to get the new menu working properly and to have the CRUD tables skinned to spec.

While evaluating WaveMaker 4 for my client, I tried to create a custom component that wrapped dojox.charting which I managed (with some help from WM personell - thx!) to accept complex json objects as data series input and switch both chart type and color theme on the fly. Pretty neat actually, and not so hard as I thought. It's open source as well, so mail me if you want it!

Cheers,
PS

Return of the WaveMaker

2008-09-20T01:27:00.000-07:00

I had reason to pick up WaveMaker again recently for a customer project. I knew that a version 4 had been released and had been meaning to check it out for a while, but I had a lot of other things calling my attention all the time.

As you might remember WaveMaker is a web-based IDE which let you drag and drop a nice UI and connect tables, trees and other things to backend services, like databases, web services and even POJO Java classes. And this in itself is nice, but the big deal is that everything is done with very few clicks in the IDE, it's all running from your own local machine (if you want, you might have a separate development machine for this, but it's in your control, is what I mean) and it produces a stand-alone WAR file that you can drop into JBoss or Tomcat or whatever to get your stuff up and running.

I really like RAD, when it works. WaveMaker had some problems in the 3.x release in making connections between UI components and backend services easy to understand, and this has thankfully become much better in the 4.x release.

Still, WaveMaker has two major drabacks, for me;

1) It has no cloud. OK, this is wildly unfair, I know. But I'm comparing against GAE, and possible Jaxer all the time. What hapens if I manage to build something that has to support millions of request? Do I have to wrestle AWS again? Argh!

2) It requires Java to runt the backend. Custom logic can thankfully be done in any language, as long as it exposed as any (almost) kind of web service, WSDL, RESTish, et.c, but the server is done in Java, and require a container. What would be very nice is if you could separate the excellent front-end IDE from the services it depends on from the backend, and build alternate backends. Maybe a python backend? ?? ?? :)

I've been looking at ways to use WaveMaker with SSJS (Server-Side JavaScript) the last days, on my off time, and it is definitely doable. I donwloaded the Rhino jar from Mozilla, which is the standard Java-based JavaScript engine (http://www.mozilla.org/rhino/download.html), and put it in the lib directory in my WaveMaker project folder. Then I copied and pasted one of the examples which comes along with Rhino that shows how to evaluate a Java String as JavaScript, into the WaveMaker Wizard which help you create new services from a simple POJO. And it compiled and smiled, just like that :)

The next step is to make it do something useful, and to tie the output of the service to an UI component, maybe a textfield, to see that it works. And what we have then is a DIY SSJS in conjunction with WaveMaker's excellent frontend. Since WM has a well defined server-side Java ASPI as well, exposing those objects to JavaScript should be fairly easy, since you'd probably want to interact with it at some point.

Then I got thinking about possible backend alternatives again, and noticed that Kris Zyp's SSJS persevere framework has been accepted into the Dojo foundation. Persevere is really cool, but has no IDE as such, and depend on the developer knowing well how to consume RESTish webs ervices from a JavaScript(Ajax client, very close to TSA/SOFEA ideals :)

What it has in spades is database rubberification and exposal through REST services. It can connect to a number of different databases, and present all actions (even schema modifications and table management) in the same kind of REST metaphor as you would present adding a new row or modfying a column.

Persevere has a lot of feature overlap with WaveMakers backend, but that's really very positive, since there's not so much more to add (I hope :). Unfortunately, Persevere also require a Java backend, running on Rhino itself, but it could still be a nice addition.

Possibly, WaveMaker could also add a SMD (Simple Method Descripton) web service generation to the list of existing services it can consume, which would make Persevere melt right in.

What I would really want is a SSJS cloud which is toolkit agnostic, with the WaveMaker IDE as ... well, IDE and management console. The current contenders for the SSJS cloud throne are mostly (10gen, for example) forcing their own platform, and making it impossible to import JavaScript from other sources (Say, Dojo). Or if not, they force you to whip out your credit-card before getting any access (Jaxer).

I think it's really sad that Jaxer does not provide a free entry-level poking-around alternative for their cloud. Google App Engine (OK, quite some more resources) and others can do it, and it really feels like a bad slice of an otherwise gorgeous apple pie.

I began with praising WaveMaker, then being unreasonable with them, then yammered at the state of SSJS in general. Coherent? Certainly not! :) Also, I really like Jaxer as well, but I think that they really should not push away customers like that. Everything else point in the other direction(I.e. really cool and very interesting), so not giving people the opportunity to check out the wares before ponying up (The amount is insignificant, actually, from this point of view) feels wrong.

Cheers,
PS

Strange summer and other things

2008-08-26T04:55:00.000-07:00

What did you do on your summer vacation? Mine was kind of hectic. I came in contact with a group of people who was in the process of creating a startup and was searching for a front-end lead. The idea sounded strange but I was wowed by the talent that sat at the table. We were people from all around the world; Sweden (obviously :), Pakistan, France, Canada and USA.

I had a complete blast with designing the front-end stuff and interacting and brainstorm with all the other guys and girls on the team. Wives were involved (under NDA's naturally) and ideas spawned at any hour of the days - dinner tables, while jogging - you name it.

Unfortunately I got more and more restless with what I felt was something that would not solve itself automatically; the end-user proposition, especially in light of similar services and/or services filling similar purposes. I might be wrong, but I feel that the end-user experience and value proposition must be central to a service, and by definition that includes its relation to its context (i.e. similarity neighborhood). I was so at odds with the rest of the team that I finally decided to quit rather than get into debates all the time.

This was not an easy decision, but in retrospect I still feel, the best one. It feels very sad to become part of a dynamic supersmart group fro a month and then willingly close the door on it, but that's what I did. OK, I'm still involved in some side-projects that are indirectly needed, but I'm not 'in' any longer.

So, that was quite a ride, and I'm still reeling from it. The positive side is that I now have more time on my hands (i.e. almost none) than before, so that finishing my book at least become a possibility. That is a good thing.

I'm also working on two things that is on my conscience;

1) Get back to finishing the fine editor for JavaScript as a Dojo component, so that I can finish my Bunkai editor so I can deliver it this decade to the Sling project (and any other project needing a rowser-based source code editor with pluggable resource managers.

2) Finish the simple Dojo / App Engine mockup for World Change Network before taking the family to dinner with the founder this Friday :) Might be a priority, really.

Other than that Dojo 1.2 is creeping ominously closer to being released (no thanks to me, I might add), and if you haven't checked out the truly cool new features, just look at the following;

Just-what-you-always-wanted DOM text effects; explosiong, slicings, you name it!

A eclipse/Croquet-sqeuak object browser / drill-down list. MIGHTILY useful

Insanely cool dynamic 2D charts with events, sliding pies and onmousovers with quivering data points. Mmmm..

And of course a lot more, but these are my personal favorites. The last two come from my personal stash, a cross-domain built svn 1.2, reasonably updated. Feel free to use it if you want to play with 1.2 but don't want to wait for AOL or Dojo to put up a build. Use same instructions as for AOL.

Continuing the Dojo trend, make sure to take a look at WaveMaker's latest release (with surfing board and everything :). As you all know WaveMaker is an open-source web-based IDE that let you create Ajaxified applications point-and-click style, with a WAR-file as result. Simple component bindings to SQL tables and/or Web Services as well.

Really cool, actually. If you're into Java, that is. I wonder what would happen if they took that front-end and put it on rails or App engine?? Hmm...

And I'm also gearing up for talking at AjaxWorld this October. I really hope that Red (at the Google Open Source programs office) will find a spot to do a tech talk that week, since it's going to be a summer of code party then as well.

Anyway, if you're in San José in October 20-25, please ping me for a beer ot two :)

Oh! And don't miss Kris Zyp's devastatingly spot-on article on client / server programming on the web.

Cheers,
PS

Twitter and Gears

2008-06-23T12:43:00.000-07:00

OK, this is probably tangential to the book I should be writing on right now (20 pages to go until Sunday. Argh!), but it _is_ Dojo.

Twitter is more like a kind of weather than a service. It goes well at times, and at times it does not. Many times I wish I just could search through old tweets, or sort them quickly in some ways not intended by twitter.

I've actually thought; why not use Gears to store all twits and then just use a Dojo Grid to show them. Separating download and presentation in a perceivable way could actually be a feature of a twitter client.

Most probably someone has already done this and much better than I, but anyway, I've actually made it work .. sort of :)

So if anyone know if this has already been done, please mail me or comment here. Once the stuff is in the google gears store I thought I'd add a MIT Simile timeline to splunk it up a bit as well.

Cheers,
PS

From Google with Love

2008-06-03T03:20:00.000-07:00

After a grueling 17 hour flight from Stockholm, bouncing once in Chicago, we (me and my family) arrived at SFO and shortly after, Hotel Triton at Grant Avenue and Bush. The kids started hopping around between the beds like grasshoppers while the poor parents attempted some sort of controlled landing. The room was very nice, if a bit on the small side.

After a couple of obligatory days of spending on the obvious tourist activities (having a great time all the same, especially the kids. I really recommend SF as a place to go for vacation) I went to the Dojo Dinner that was arranged the day before Google I/O.

It was really cool to meet people I've only had e-mail contact with before, like Alex Russel and Dylan Schieman, among others. We had a great Vietnamese dinner which sort of turned into a vehicle for party-crashing the Wordpress release party a few blocks away. At the Dinner were also three really nice Dojo specialists all the way from Bògota (Sorry, I have to type this in at lunch and don't remember everyones names atm).

Nice room (The Pókemon pillow was ours).

Kids grasshoppering.

Having acquired the secret password for the WordPress bar left me in a lot of interesting conversations, listening in on the FLickr guy, the Wordpress guy and also Rohit Khare who had something new up his sleeve, more of which probably later.

Next morning it was time to get to the Moscone center for some serious Googling. I was at the right place sort of) with twenty minutes to spare. This was Moscone center;

Hmm. No Google logos there, eh? OK, this was a really _big_ affair. The entrance might just as well be on the other side, right? I started to walk around the center, keeping a brisk pace, looking out for sign of any convention, Google or no.

As it turned out, the next side of the building was clearly a 'side' with no real official entrances, turning up the hopes for the 'other end', as it were.

Much to my chagrin, the other side was just that, leaving me in an even worse spot. Each side of the building was perhaps 400-500 meters, and the only thing I could do now was to go back to the side where I started. There again I noticed that the building _way_ over the other side of the street also had "Moscone" signs. After managing the street, I finally got hold of a person who directed me to yet another building, Moscone "West", which was barely visible from where we were standing. It was pure luck Google had not set up shop in Moscone South, Egypt.

I was not alone in attending Google I/O;

The keynote was good, except for the GWT guys trying to bash on JavaScript and only managing an empty clapping sound. It's about 55 minutes in. I have liked GWT a bit on general principles before and I still think it is a great solution. Unfortunately it is a solution to a problem the doesn't exist.

Then I went to get an introduction to Python by Guide himself! Is that cool or what? He's like me European, well built (...), humorous and wonderfully opinionated. Most things I've read up on before, but he got in a lot of history, examples, et.c. between the lines so it was really great.

Also, I managed to meet up with Kirk Wilson, CEO of World Change Network, to plan the next release of the system. The general idea is to create a reputation-based project store and exchange, focusing on solving problems for people in developing countries. The reason for this is that there might in many cases exist tried-out processes for certain problems (donating blood, managing around corrupt officials, seeking legal help, et.c.) that the people in need of them are not aware about.

Also, the system will contain basic project management, supporting coaching and helping from all of over the world. I think of it as aid by donating project management rather than money. I'm sure Kirk can put it more eloquently, but that's a fair summary from my point of view, I suppose :)

The party was a smash hit of Olympic proportions. Dozens of linked arcade games, chocolate fountains, Googlers somersaulting in dragged together heaps of bean bags, beer, wine and ale of exotic brands (and Steam ale, yes :), Sushi, pastas, mashed potatoes and gravy.. and the flight of the Concords. I didn't think I would find them funny, but they were. They were also very good musicians.

I think I went to an English pub after that, with some people in the real-estate business (those cards left at home again, sorry!) with Swedish ancestries.

The next day went by in a blur, finally coalescing into the acquisition of a Google Gears Beta T-shirt! Yay! And also the devastating wit and vehemence of Steve Yegge.

He gave a good rundown on his server-side (SSJS) JavaScript work at Google, and on his plans to release the Ruby on Rails in JavaScript framework Rhino's Not Ruby (RnR) Real Soon Now. For all those present who still hasn't got it, he gave ample examples and conjecture for why dynamic beats static when it comes to choosing language, and why late binding and JIT's beats the living daylight out of static compiling. In all a wonderful talk, if too short.

If you read this, Steve, remember that you've _almost_ promised to come to Stockholm and give a (longer) speech later this year :) Just so you don't forget.

After Google I/O wound down, Kirk was the perfect host, giving us a truly great tour of San Francisco; the Golden gate, the Yacht club, the park, height-ashbury, et.c. After we very deposited, light as feathers in the restaurant Viva!, recommended by Mats Henricsson, devouring the Pescatore pasta and then enjoying a quiet walk home to the hotel through Chinatown.

Being a mentor for Dojo in the Google Summer of Code 2008 program, I was invited to a lunch at the googleplex by the indefatigable Leslie Hawthorn, of Google Open Source Programs Office. I must really thank her for being able to acquiesce to my request to bring the whole family. They actually had T-shirts in the kids sizes.

When we got home to Sweden again, we found out that our daughter had been collecting gravel from the path outside building 43 and put in the jacket pocket of my wife, so now we have four very precious Google Stones at home, possibly with the same effects upon basic charateristics as AD&D IOUN stones.

Also, the food was indeed great, and Leslie had this great T-shirt in commemoration of the day when they had the author of xkcd on a Tech Talk. They had baked him a cake the shape of the internet! :)

Going to San Francisco

2008-05-22T05:27:00.000-07:00

So, this Saturday me and the rest of the family (sans cats) will blast off from Arlanda airport, Stockholm, bounce at O'Hare in Chicago and land 17 hours later in San Francisco.

The reason for this extravagance is Google I/O, which I'll be attending. I haven't made up my mind yet what sessions I'll be going to. All seems to be a hard option :)

Anyway. It was almost ten years since I last was in SF; so it'll be great to be back again. If you know of any really nice kid-friendly restaurants (apart from the Pier and McD!) and/or know of any geek-friendly activities in the neighborhood, please comment or mail me directly (see address in the sidebar).

The main problem is to find another Hotel where we can buy admission to use the pool, since ours don't have any. The reason for that is that it's hard to explain to a six-year old girl why there's no pool in the Hotel, that's why :) I've bought Naruto's for her brother, so he'll be OK.

Cheers,
PS

The elusive Dojo Treetable

2008-05-15T00:52:00.000-07:00

I just got a mail from David Silvestre, who asked me about how to go about building a Dojo Treetable. You know, the sortable table thingy where you can expand and collapse each level just like a tree, but it still retain all columns for everything it shows?
Anyway, I had do one of those last winter, for a project, and spent a large amount of time trying make Dojo's existing Grid and/or Tree usable to do what I wanted, and ultimately failed.

Here's my short notes on how (to the best of my recollectionary faculties) I did it;

I found a couple existing treetables, especially one for jQuery, but in the end I had to make one myself to understand what I was doing. I recommend you to do the same.

Overview;

1) Create a simple custom widget (see my ultra-light tutorial here; http://docs.google.com/Presentation?id=dfxgjqrf_78fr7h6sd7
2) Create a table (remember to use , et.c. otherwise IE will barf :) in the template for it
3) You have a hierarchy of data (an xml document, no doubt).
4) Use dojox.xml.DomParser to get a traversable object (still horrible but hey) of the XML. (I have some examples on how to use it if you need)
5) Create an array of object trees out of the xml object. I mad an array indexed on 'name', where I created an 'artist' object and stuck it there, and under that I stuck and 'album', followed by 'song' object. You get the picture.
6) When the array is done, you parse it (could possible by done in one step, I guess) and create an image and a subtable, and add that to the single td of the overall table
7) I recurse the object tree for each array object, and create a new image and table, which gets tucked inside the single td of the parent table, until there are no more object levels.
8) I now have a table with a table in in with a table in it, et.c.
9) The image (+ or -) beside the table has an onclick handler which shows or hides the table it is handling. Thus you can get smooth animations and hide/show all or some things that you already have open, according to which level you click the image on.

Now that I've written it out, it does sound a bit harder than it felt, but the hard part is realy to parse the xml data and create a usable structure. After that it's (just) a recursive table making function. Sort of :)

Actually, I think I'll post this to my blog, since it's at least a rough sketch for someone else in your position.

Hmm.. Maybe this could be a real Dojo component. Maybe.. err.. in autumn :)

Cheers,
PS

Teaching === Learning

2008-05-12T00:07:00.000-07:00

I spent most of the 90's teaching various networking technologies to people (Novell's NDS, Microsoft's passive directory, TPC/IP, et.c). And if there's one thing I learned from that experience(except what a challenge some students can be :) is that you just think you know something until you've tried to teach it.

And conversely, after having survived a dozen courses you can finally say that you've mastered the subject (for the level you're teaching, naturally). It's not enough to read the books over and over, and it's not even enough to work with it day in and out (though it's even better). If you're not forced to take one step back and actually formulate a personal theory about how things work, you'll never truly grasp a subject.

There's no magic here, only a specific level of effort and - maybe - will. One always strive to do the least in any given situation. I would classify this as a property tied not to Swedes in general or even humans in general, but to all life, period.

So the trick is to put oneself in a situation where above an beyond call of duty become the least possible effort. That way is to write a book :)

I thought I knew a bit or two about Dojo before i began, but that's nothing compared to what I know now. Unfortunately that's still meager catch compared to what I now see available. Well, I won't die bored, that's for sure.

This weekend I finished chapter three of "Learning Dojo", which would be an overview of how Dijits (Dojo's widgets) work. What struck me was that I found a lot of things that I've been looking for, but have had to hack brute force the last year.

For instance, if you're creating a custom widget (and, let's face it, that's the way you work) you often want to access the DOM nodes in the template for various reasons, from you widget class. I had resorted to misuse the basic template variable substitution in Dojo, which lets you use ${} syntax in the HTML template of a widget to directly insert 'this' level variables. My templates looked a bit like this;

div id="${id}_dialog" dojotype="dijit.Dialog"\>div id="${id}_dialog" dojoType="dijit.Dialog"\>...\/div

This will lead Dojo to automatically insert the id property of the widget into the variable, so that if the id we had given our custom widget was 'foo', this node now had an id of 'foo_dialog', which modularized stuff in a good manner, so as to not collide with other instances of the same custom widget in the page, et.c.

When I started writing about attach points, I realized I was very unsure about how they worked. I re-read the online documentation and couldn't really make heads or tails of it. Finally I started testing ideas of how attach points might work in a small test widget.

What I did was the following;

div dojoAttachPoint="dialog" dojoType="dijit.Dialog"\>...\/div

And then I suddenly had a new property in my widget class called 'dialog', or 'this.dialog'. Strange huh? :) As it turned out attach points was what I had been doing all along, only slicker and truly integrated. They work for ordinary DOM nodes in the templates as well, the property just is a reference to the DOM node instead of the widget.

I learned a lot more things during the course of writing the chapter, but I'll get to them in another post. The attach point conundrum has been bugging me or quite a while, so I just wanted to blog about it for some for chap who like me, really needs it but doesn't grok the online dox :)