Facebook wanted “onerous terms that we could not agree to.”

but when I read this, in another time I was reading about other Onerous silly terms:

At our last Palm Developer Day, Ben and I discussed future APIs for webOS including “JavaScript services” as a way to write code that runs on the other side of the device service bus using JavaScript.

If you think about it, node delivers a services platform for the cloud, so is there a way that we could work together? We got together with Ryan Dahl of Node to try this out, and it turns out that node works fantastically well on a mobile device! Major kudos should go to the V8 team for creating a great VM and to Ryan for writing efficient code that scaled down from the cloud to the device.

Today we announce that node is part of webOS 2.0:

The popular Node.js runtime environment is built into webOS 2.0, which means that you can now develop not just webOS apps but also services in JavaScript. The active Node ecosystem is on hand to provide community support and a rapidly growing library of modules that you can use in your webOS services.

Besides powering the new Synergy APIs, JavaScript services strengthen webOS’s support for background processing and add new capabilities—like low-level networking, file system access, and binary data processing—to the web technology stack.

I am really excited about this move for us. The node community is top class. I get to see this time and time again, most recently over the weekend and this week as I judge the node knockout. There is magic in the air with Node. It feels like the Rails days. I remember being so happy to jump to Rails and get away from the heavy world of Enterprise Java. It was a breath of fresh air to not have to argue with folks about every piece of the stack. “What about JSF with HiveMind and Commons-Logging and ….” Argh! Too. Much. Choice. And, a logging abstraction above Log4J was hilarious :)

Node is low level, yet simple. It is more like Sinatra than Rails. The event-based opinions keep you in good stead, and with cloud solutions such as Heroku and no.de you have great deployment stories, unlike Rails back in the day.

If you check out the modules that are growing daily, and the fun real-time hacks from the knockout you will get a good feel for node.

It feels great to have webOS as the first mobile device that embeds node. With db8 we offer a JSON store than can sync to the cloud (e.g. sync with CouchDB). This stack is starting to look pretty great.

I remember growing up walking past grocers and butchers, and having my Mum stop by to get fresh meat and veg on a daily basis. I look back fondly on that experience, as I contrast it to the later years of mega-stores. When I came back to England for a year stint, a few years back, I was shocked to see that Tesco didn’t just sell food anymore, but had branched out to credit cards and gas and lots of crazy things.

The local stores have been wedged out.

On Sunday, I took my kids to the farmers market (happens most weekends), which is what had me think back to the local stores from my own childhood.

I worry about the food chain these days.

Another sector that I think about is app economies and app stores. I have talked about what an open marketplace could be and Pascal Finette of Mozilla Labs has been doing a lot of thinking in this area.

Fast forward a few months, and we see a new project in a very early stage. Vapour (github repo has been removed) is the Mozilla Labs project that is “An experiment around an Open Web App Store.” I am excited about the project for two reasons:

• Mozilla is uniquely positioned to deliver a marketplace that focuses on very different values than other companies
• I see check-ins from two amazing people: Michael Hanson (who did the amazing work around “people”) and Lloyd Hilaiel (who recently joined Mozilla. I tried to hire him there years back, and he waiting for me to leave. Hmm :)

Also, I got to hang with the OpenAppMkt chaps at the Node Knockout get together last night. They have only just begun, and think they will do some great things.

I evangelize the farmers market. I market it. I try to sell it.

I think of the Mozilla effort as the farmers market of app stores. The values are different. It isn’t just about values though, it will be about product. Many folk go to the farmers market because the goods are better. It is incredibly hard to compete with the likes of Walmart. They squeeze the market and force their vendors in a race to the bottom around price. This is the trick that Walmart can play. They can hold on to: “Look, we are giving everyone cheap goods!” It doesn’t matter what they do with China, or how they treat workers. Surely it is all for good if we can get things cheap right?

The same is happening with the major app stores. These platforms sell consumers with a fantastic user experience and looking after their users. No viruses. No “bad stuff”. Clean. They offer true value, but there is always a cost.

The app markets are as strong as wal-mart. I am excited to see new endeavors that change the game and deliver great user value, while also giving great freedom.

Twitter isn’t your audience. It’s your community. It’s easy to tell the difference: The guy on stage at the concert is in front of his audience. The people in the stands are in their community. When the concert is over the audience vanishes but the community continues; with or without the man on stage.

The above quote was from hidden frequency, in a response to Leo Laporte’s Buzz Kill piece that discussed his feelings after he realized that his microblogging status updates weren’t getting through…. and no one had been telling him.

It is easy to see that. A lot of people are watching the river of updates in their Twitter client, and if someone stops throwing their own rocks in the river, you may not notice, and instead you will be checking out other rocks. As I often say if I find a bug in my code…. “no, that is a feature!”

I have created a balance with my followers so there is almost always something of value in my stream these days. I have found that I don’t use RSS readers anymore, as by the time I open them, I have already read the good stuff as friends have talked about it.

The HF considers my usage as a problem, but there isn’t one way to use Twitter or any social network. Users find crazy ways to surprise you with the ways they use their services. The beauty of Twitter (and other services) with lists, is that you can enjoy multiple usage patterns. I can watch the entire river hit me hard, or I can go off and read only close friends….. or only updates from web devs, or whatever hat I want to wear right then. It is the beginning of The River (which is much more than Twitter).

With Twitter I definitely feel much more connected to the community. The fact that we are all equals on there is fantastic, and it is easy to jump from community to community. Someone new reaches out, and you instantly have a new friend. So, Leo, don’t run away…. the world is listening, they just also happen to have other people they are listening to, too.

Dimitris Vardoulakis has created a Doctor. A Doctor for JavaScript that does static analysis on your code to tease out the type information and more.

This is fantastic work, and is something that we were dreaming of when we first planned Bespin. What if the cloud was constantly analyzing your code and returning type metadata back to the clients that were accessing it? That metadata can be used for tasks such as code completion and documentation.

Give it a try to see what comes out the other end. The samples show you a lot, such as polymorphism:

function id(x) { return x;}
id(42);
id('hello, doctor!');
 
// returns
id : function(<number | string>) → <number | string>

and prototypes:

function Rectangle(w, h) {
    this.w = w;
    this.h = h;
}
Rectangle.prototype.area = function() {
    return this.w * this.h;
};
var a = (new Rectangle(2, 3)).area();
 
// returns
Rectangle : function(number, number) → any
area : function() → number

and exceptions:

function findLargest(a) {
    if (a.length === 0) throw new Error('empty array');
    var max = a[0];
    for (var i = 1, l = a.length; i < l; i++)
        if (a[i] > max)
            max = a[i];
    return max;
}
function foo() {
    var a = [1,2,3];
    try {
        return findLargest(a);
    } catch (e) {
        return e.message;
    }
}
foo();
 
// returns
findLargest : function(Array[number]) → number
foo : function() → <number | string>

and callbacks:

function call(f, x) { return f(x); }
function add1(n) { return n + 1; }
function truncate(s) { return s.substring(0, s.length - 1); }
var n = call(add1, 41);
var s = call(truncate, 'abcd');
 
// returns
call : function(<function(number) → number | function(string) → string>, <number | string>) → <number | string>
add1 : function(number) → number
truncate : function(string) → string

Mike Shaver talked about the great work that is coming in JS land right now for Moz…. and it is showing. Can’t wait to see both Firefox and Bespin gain from this all!

When you look at the image above, the rasterized graphics look like crap, and the type looks great. We now live in a world where pinch and zoom is changing how your Web application is viewed. In the past we had to deal with different screen sizes, and browsers started to get smarter with their “zoom” going beyond “font size++”, but it isn’t like todays feeling that your users are pinching you, and you don’t know how hard.

The folk behind SVG all cheer. Those who enjoy Raphael as it gives you a nice API to that world, have also shown you this goodness for awhile. In Inkscape we have even have a decent tool:

An Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.

Inkscape supports many advanced SVG features (markers, clones, alpha blending, etc.) and great care is taken in designing a streamlined interface. It is very easy to edit nodes, perform complex path operations, trace bitmaps and much more. We also aim to maintain a thriving user and developer community by using open, community-oriented development.

There is even a new tool. Leonardo is a new vector drawing tool by Josh (note: who works in Developer Relations with me at H/Palm):

Leonardo is an open source vector drawing program for the 21st century. It focuses on common tasks like mockups, sketches, and presentations with a clean and consistent user interface. It is designed to be augmented by internet webservices and plugins created in several scripting languages.

• vector drawing with bezier curves and geometric primitives
• reusable symbols stored in a sidebar
• integrated creative commons Flickr search
• building simple multi-page presentations
• export to PNG, HTML, SVG, Email, and Twitter.

Do you think about vectors more these days?

I remember talking to a friend who joined Google and the Wave (then Walkabout) teams in Sydney. He talked about how he was excited to push the Web in crazy new ways and that he was shocked at how far they had gone. He also said “but I have no idea if people will use this.”

Google-haters will make fun of the fact that Wave hasn’t been a commercial success. “See! They are a 2 hit wonder! Search and Ads!” However, I think that Eric’s spin rings partly true. Google had the balls to do it. They let Lars and an awesome set of engineers take a run and rethinking the way that we communicate.

This is an incredibly hard proposition. Many people live in their email (I know, I know, the kids live in FB mail right?). I find myself loving a Gmail plugin whilst never getting into Wave. Incremental, evolutionary improvement often wins on the Web. The revolutions are hard, but that doesn’t mean that people should stop trying them… and Google has the $ and the need to scale their businesses.

Wave, as well as giving great demo, has brought a lot of cool technology into the commons. Other projects like Novell Pulse and the like are using it. When I was working on Bespin I really wanted to see a world in which Bespin could run on top of the operational transform abilities of Wave. Good things will come of Wave. The engineers have learned a ton, and that will go throughout the company to their other products. Making Gmail incrementally better will be huge. There is the large Google Buzz team making a run for social (a touch play when competitors have massive mindshare and user bases).

I also wonder about Etherpad. That great team shipped off to Sydney to join Wave. I love Etherpad. I still use it at typewith.me and at other clones when that goes down. The vision of Etherpad was smaller than Wave, but incredibly useful. I hope those guys land well. The entire Wave team is top drawer. They were ahead of the game this time around …. and timing is everything.

I can’t tell you how much I love Rapportive, the service that makes Gmail better by taking away the ads, and adding in useful information about the sender (teh social).

I have played with “social email” type plugins before, but they always tried to do too much, and rarely anything useful. Email is important to people. You tend to live in it. So, if you have an “add-on” the best thing to do is to quietly whisper useful information into the email users ear as they go about their business.

Once you install Rapportive, your email life instantly changes for the better. When I get an email from someone new I suddenly get a face to the name (via the profile picture), a feel for who they are (from their social updates), and more.

There are other fun side effects. I have had a few spammers de-cloaked for example. In general I feel like I have a leg up in a new conversation. Email feels different to me. I would hate to have it taken away…. which is a great sign.

The team behind Rapportive is equally awesome. They came from the great hacker dojo of Y Combinator, and other investors have come in behind that…. including Mr. Gmail himself.

The reason that I am actually writing this email though, is their service on behalf of their service.

There are a series of emails that I get that come from the same email. A lot of them fall into my “notifications” tag: Follows from Twitter, messages from Facebook, comments from Wordpress, plans from Plancast, etc.

Until recently, Rapportive hadn’t really done much for me there. Then, the team started to show information from the website of some of the companies behind these messages. I then reached out and said, what I really wanted was more meat that could be gleaned from the email. My use case was Twitter. When someone follows me, the more info I have on them, the more likely I am to follow them back. Twitter improved their template email a few weeks back (although for some reason it seems to have reverted for me recently?) but they don’t put in recent tweets from the person. I can see why: spammers would LOOOOOVE that feature. However, I would love to see it as I decide if I should reciprocate the follow! Rapportive could dip into the email content, parse out the fact that @foo has followed me, and show me their Tweets.

I don’t even think it was a full 24 hours later, and @rahulvohra their CEO, let me know that the feature was in place. I tested it…. and it was.

How about that for service.

ps. I love that Rapportive is an extensible platform. You can write “Rapplets” which are plugins for that right bar. E.g. load in Crunchbase information. I do find that some of these bug me when they say “Bob not found on …” when I would rather just not see anything.

I have a bunch of ideas for Rapplets, and after the great response from the team, I have every incentive to writeup thoughts on how to make the service better too. If you use Gmail, you should get this plugin.

pps. It is great timing for someone to build this service. We have had good ole microformats for awhile, and now with Web Finger integration here and there, let alone various services that key off of email, it is coming together that you can actually get a lot of good info based on just an email address.

Web developers have to walk around dragging a ball and chain. It is fantastic that we have a ridiculous install base (browsers, the Web runtimes) and a dynamic language in JavaScript.

The ball and chain though is the fact that we have to care so much about the payload of the application that we write. Less code means less bytes to download, and less for the JS runtime to load up.

This has bad consequences:

• You are tempted to write hard to understand code
• You have to balance functionality and code size much more than other environments
• You end up getting tricky and come up with ways to dynamically load modules on demand
• All of this time is time not spent on the app logic.

When you run into a problem like this in computer science what do you do? Build an abstraction!

GWT has done a great job here. It’s very nature requires a compilation step, and once you have to deal with that step…. you can do a lot at build time to change the above dynamics.

For example:

• You can write nice explicit source code, and trust that the compiler will output optimized JS (which can look as ugly as sin for all anyone cares)
• Your application can get faster with a new release of GWT, as the compiler gets better
• A lot of advanced techniques such as code splitting, and deferred binding can be applied to allow logic to apply at build time as well as runtime.

Ignoring GWT, when you write a pure JS application for the Web, you are writing a cross platform application. Unlike clean portable C, you don’t have that compilation step to do clean up work for you on each platform, so you end up with a lot of runtime conditional logic.

You try to do object detection rather than user agent conditional, but still, you end up both downloading the code necessary to run in all environments, and you have the overhead of loading and executing that code.

Chances are you are smart and don’t do if() checks all the time, but maybe do so once when loading up. For large chunks of big differences, maybe you do something like:

var Foo = (sometest) ? function() {
    // do it like this
} : function() {
    // do it like that
};

If you take a look at some parts of popular JavaScript frameworks, you see that they are abstractions or fixes for various browsers. As browsers have stepped up to the plate recently, they have fixed a lot, and suddenly you take a step back. A lot of frameworks have a chunk of code to give us the ability to do smart things with CSS querying. Modern browsers support querySelectorAll (even with some bugs) and getElementsByClassName so a lot of the code is un-needed…. unless you care about the old browsers.

We shouldn’t have to download all of that cruft on the other side of the if() statement when we don’t use it!

The GWT compiler can output versions of your application targeted to a given browser. Only the fastest, minimal code, will get sent down. Deferred binding goes far beyond just browser type (can deal w/ locales and much more) too.

GWT isn’t the only horse in this race though.

Alex Russell started to sprinkle in some directives to Dojo that would enable you to do a build that is WebKit targeted. A major use case for all of this is making sure that you are sending down lean code in the mobile space. It can matter everywhere, but when you are dealing with grown up walkie talkies…. you want to really optimize.

And this brings us to YUI. I was really excited to see some of the features in the YUI 3.2.0 preview release. Great stuff for touch/gesture support, but what stood out for me was “YUI’s intrinsic Loader now supports capability-based loading”. A-ha!

I poked around the source to see how it was used. Here is one fake example that shows how it works. When you boot up YUI you can add in “conditions” which are in charge of working out whether to load something. You can currently tie on to user agent, or write a test function:

YUI({
    modules: {
        lib2: {
            requires: ['yui'],
            fullpath: 'js/lib2.js',
            condition: {
                trigger: 'node-base',
                ua: 'gecko'
            }
        },
 
        lib3: {
            requires: ['yui'],
            fullpath: 'js/lib3.js',
            condition: {
                trigger: 'event-base',
                test: function(Y, req) {
                    return Y.UA.gecko;
                }
            }
        }
    }
 
}).use('node', function (Y) { .... });

The YUI team uses this themselves to only load certain ugly DOM stuff for IE6 when needed:

"dom-style-ie": {
    "condition": {
        "trigger": "dom-style", 
        "ua": "ie"
    }, 
    "requires": [
        "dom-style"
    ]
},
 
YUI.add('dom-style-ie', function(Y) {
    // ....
});

This makes a ton of sense, especially for the libraries themselves to do this work. They are the ones that do the heavy lifting of cross browser ugliness, all to allow us to write to an API that works.

Beyond that, we can then ourselves split out code if it becomes a performance issue.

Of course, the value of the test() function is that you can do capability based testing (not just user agent testing…. hence the name!). This means that you can do a test say for Canvas support (as Zach mentions in the comments) document.createElement(’canvas’).getContext, and load up excanvas or another shim library if it doesn’t exist.

Using modernizr and ilk, we could build out “plugins” for YUI that auto load based on common capabilities. You can imagine running a YUI build, having it detect that you are using a capability, and then automatically load up a plugin that has the condition all loaded up. What a great user experience as a developer!

Maybe it makes sense to come up with a common pattern and conventions for dealing with this issue. How do you name your CSS/JS? Do we setup server side hooks so we don’t even need loaders necessarily?

I can certainly see a day where you may be asking the Google Ajax Library service for jquery.js, but it is returning jquery.ie.js to you.

I consider myself a developer who happens to love community, evangelism, and advocacy.

When I put on the developer relations hat, I am constantly asking myself what value these roles have, and how to add more value to the process.

When I was working at Google, a certain engineering manager made it very clear that he felt advocacy and evangelism added close to zero value. His position was that you if you build a great product, developers will come. Rather than lash out, I keep that in the back of my mind, and think about how to make that view incorrect.

I keep coming back to Ohm’s law which explains the relationship between current, potential difference, and resistance and the laws of electricity.

I still remember the crazy physics teacher that I had that would scream:

“It’s the volts that jolt but the amps will kill ya!”

He would then kindly put kids through an experiment to get close to showing the truth behind that statement.

If you think of this law as a pipe and water flowing through it, there is the radius of said pipe, how fast the water is being pushed through it, and the resistance of the pipe.

How does this relate to developers and developer advocacy?

To reference the afore mentioned engineering manager, he has some truth. I feel like developer evangelism can help with the “push” (the volts). However, if you take the best developer relations crew… a crew that can push hard… they won’t be able to reach any potential if the pipe is tiny small, and the friction of the tools, APIs, platform, or economics provide.

Thus, the most important thing that you can do for a developer oriented initiative is first create a fantastic pipe. The pipe should have as little friction as possible, and should be as large as possible. Probably the most important way to achieve those goals is to provide developers with:

• A fantastic economic opportunity. Let’s face it, if Apple restricted developers so they had to use punch cards to build iOS apps, we would still have a lot of apps :) Same goes for Facebook etc. Even though when you look at the numbers on even those platforms, success is a “hit based” economy, the hits do so well that many developers get in the water for their change
• A chance to do something different. Create a platform with unique capabilities and the opportunity for developers to create something very different, and that itself will be a draw. New companies and products can be created where they didn’t exist. Nokia had (and has) a boatload of phones. At JavaOne for years a Sun exec would get up and say “developer a J2ME app and you can reach BILLLLLLLIONS of devices!” Few did in the scale that we see with so called “smartphones”. You just couldn’t create anything interesting or compelling (oh, and there are the carrier gateway issues of that time too)
• Make your platform fun and generative. This is a sub-bullet of the last one in many ways. But, if you a developer can have a great time creating on top of your building blocks, great things will happen, and the network effect can flow.

Now, evangelism comes in as a way to:

• Let developers KNOW about your fantastic economic opportunity, their chance to do something different, and how productive and fun it is to develop on.
• With tools, samples, articles, conferences, and community in general…. help lower the friction for these things. Give developers a leg up.

This push can have a huge effect. Good evangelism will also create external evangelists who share your excitement and vision ending up with a nice network effect.

Only half the story

But evangelism is only a piece of the story. The reason that I like the term “developer advocate” so much (and why I posted on this topic) is because it shows the other side of the coin. You are the third party developers representative back at your platform company. You are letting the internal teams understand their needs. And, you get to be part of that community:

“I can advocate something, and part of that will hopefully be heavily listening, and participating in the open community. Of course, these are just words, and you have to make this happen. We could call ourselves evangelists and do a lot of listening, or become advocates and do none. The word choice though does make you think about what you should be doing.
More importantly, in my opinion, is the word developer. Rather than talking just about technology, we are talking about humans who use it. This again makes you feel like you need to be more part of the community, working with developers on their level.”

Every now and then I reflect on Ohm’s law (it helps to watch the current of a stream in the mountains as I have been able to do in Colorado this week!), and think about how me and my team can both relieve friction and push harder for developers on the platform.

I have been at HP for a week or so now, and thus it was a great opportunity to think about how we can come together as a team to do just this. I think that I will be personally changing what I do, and I can’t wait to work with the community, the internal engineers, and the product chaps as we take webOS to the next level.