Last week they announced an Adobe AIR version, and Ryan quickly commented saying:

For a while they were using Gears as a way to store those passwords on the client but they’ve just recently switched over to using Adobe AIR.

One of the reasons given was Safari support for Gears. You have to do a build for Safari which is not what we want, and we are working with the Apple team to clean things up and have a really nice Safari plugin. Unfortunately, Safari doesn’t have a plugin model, so you always feel like you are doing some hack using unsupported mechanisms like Input Managers. Grr, come on Apple, play nice with others! :)

At the same time, Air support for the Encrypted File store (a very nice feature!) doesn’t work on Linux yet (I am sure that will be fixed soon too).

Of course, the solution isn’t Gears vs. AIR. They aren’t really competing here! The Gears users of the product started to get vocal and we quickly saw Gears support added again.

There are two very different use cases:

• Users who want to be using Passpack in the browser, who happen to want to use functionality such as offline, or any other Gears component
• Users who want a desktop-like application, outside of the browser. This is where the AIR application fits in.

So, both can make sense for Passpack. In other cases, one of the choices could make sense.

I also expect to see more joint applications. Gears functionality is working into HTML5 the standard, which will end up in WebKit (as Apple is great in that regard), and AIR uses…. WebKit as its renderer!

I really hope that AIR will be able to bridge to those APIs, and you get the best of all worlds. I would love to use the Workerpool API from within an AIR application that is doing a lot of JavaScript work for example.

ShareThis

I ended up on a wild goose chase that ended up having a simple solution.

Imagine one section of an application that is a canvas element, and another piece that is a input type="text". I wanted a way to jump between the two with a keystroke, e.g. Ctrl-J for jump.

Jumping from the canvas element to textbox was fine, but it wouldn’t work on the way back. I was trying to $('canvas').focus() but it wouldn’t work.

initMouseEvent

I stupidly thought that I should just simulate the click on the canvas element, since that was working just fine for me.

We are pretty fortunate that the ability to kick off true events programatically is bound into the event model itself.

This means that I could:

if (document.createEvent) {
   var evt = document.createEvent('MouseEvents');
   evt.initMouseEvent('click',
            true,     // Click events bubble
            true,     // and they can be cancelled
            document.defaultView,  // Use the default view
            1,        // Just a single click
            0,        // Don't bother with coordinates
            0,
            0,
            0,
            false,    // Don't apply any key modifiers
            false,
            false,
            false,
            0,        // 0 - left, 1 - middle, 2 - right
            null);    // Click events don't have any targets other than
                      // the recipient of the click
 $('canvas').dispatchEvent(evt);
}

This only slightly worked. I could test that the click was going through. I would add an onclick handler to canvas and it would fire just fine. However, something weird was happening. The focus was still in the textbox even with this click happening (which didn’t happen when I actually clicked on the darn thing).

Events from within events

Since the click was working, why not just force the blur on the textbox?

var events = document.createEvent('HTMLEvents');
var blur = events.initEvent('blur', false, false);
his.dispatchEvent(blur);

But that got me:

Component returned failure code: 0×80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent…..]

Hmm, on wait. This was happening from within an onkeypress handler and it appears that you can’t do this in a nested way. A setTimeout(..) to push it off until later didn’t make it any happier either.

tabindex=0

As I looked at this mess, I quickly realised that I had been unravelling a string, and I should take a step back.

I talked to Alex Russell, and he immediately said “erm, and you made sure that tabindex was set on the canvas element?”

Doh, it wasn’t. This is why the focus method (which did exist) didn’t do anything. I quickly added tabindex=-1 and now I could simply $('canvas').focus() and lo-and-behold it would focus!

Event.stop(e)

Great, the home stretch. I took the test and put it on the live code and it… still didn’t quite work. God damn it.

I took another step back.

A global key handler was set via document.onkeydown that was handling the world. When it saw a Ctrl-J it would short circuit and give focus to the textbox. The textbox has its own onkeydown that would do the opposite. A global flag held the state of global/textbox.

This is the problem. I had mucked up the event propogation, so in the case of jumping from textbox to canvas it would first go through the textbox handler, but after it was done it would STILL run the global handler which would kick it right back!

I just needed to e.stopProgagation(), or even better Event.stop(e) to stop any default action too.

Phew, all that running around to get back to square one. Now it works, and it reminded me of how the simplest things can be tricky.

ShareThis

There is a role in the developer team at Google called Developer Advocate, and I consider myself an honorary one of those.

What is interesting, is how the name has had an effect. When the group kicked off, we really didn’t like the term ‘evangelist’. The religious connotation is so strong isn’t it? It also feels like an evangelist is going to run around with his particular religion, and will be trying to persuade you to join, without really listening.

An advocate on the other hand sounds just a touch different. 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.

Then you put it together: Developer Advocate and a funny thing happens. What does that mean? At first people think that you are advocating to developers, but it is also very important to think about the other connotation. You think about being an advocate of the developer.

What does this mean? It means that when you are in a meeting with your product group, you are their mouth piece. What do they think of the products? the APIs? What are they asking for? You get to almost be an outsider on the inside.

That is the power of the developer advocate role, and why it can be such a fun one at companies.

Of course, I don’t even need to tell you that we are hiring for this position in the US and elsewhere in the world :)

NOTE: Right after I posted this I saw that Jeremy Z had a post titled Two Tech Jobs: Technology Evangelist and Network Operations

ShareThis

Dare is back to blogging, which I like to see. His latest piece though is about a so-called exodus of Googlers going to Microsoft.

NOTE: An exodus is:

a departure or emigration, usually of a large number of people

He notes a couple of blogs talking about a move, including Danny Thorpe and Sergey Solyanik. I am sure there are more, but an exodus is a bit rough. However, I could quite as easily discuss the number of Microsoft, Yahoo!, Apple (insert other companies) folks that I get to work with at Google. The problem is that this is meaningless. We are looking at the micro-level, through our lens working in our areas at our companies.

I am sure that in the coming week, there we will be some musical chairs at companies as large as ours. That is the way the world turns. Many people move on, they try new things, they want to work on something else etc. Especially in this day and age.

How about we get back to technology again, and look at the great work that all of these companies are doing. All the industry wants to talk about with respect to Yahoo! is some executives leaving. However, I have met with a lot of Yahoo! engineers in the last few weeks and they are working on exciting projects. Yahoo! has a LOT of users. They are a great company, born of the Web, and they never seem to get the credit their deserve. How many websites have you created with that many users? Phenomenal.

Dare, your company is doing great things too. I would be much more excited to hear more about that side of things, than employee counting. I would be much more excited to see our companies work together to progress the Web, as well as competing in various industries.

Enough SOAP opera, let’s give it a REST (sorry….). I normally don’t get into these kind of topics, but the general talk has been grating me recently, and I want to hear something fresh and new.

I have been playing with some Web technology and have been astonished at how far it has come in many ways. There is still a long way to go, and much we can all improve, but I am pretty jazzed about the technology whilst at the same time frustrated with the non-tech talk.

Maybe it is a time to get a bunch of engineers together and talk tech… maybe in Hawaii? Anyone in? :)

ShareThis

Why did I do this?

I was brainstorming functionality for a Twitter client with James Strachan (he is working on gtwit) and we talked about how annoying tinyurl / is.gd / snurl / you name it URLs are. They don’t tell you where you are going, and you could get Rick Rolled (if you are lucky) or much much worse.

So, I wanted to create a library, and one client (Greasemonkey) to test it out. Then anyone else could use it too to resolve directly from their Web pages.

How does it work

You load up the JavaScript via script src and then you can call resolve, passing the URL and a callback that will get the result. A few examples:

// Simple version
Endpoint.resolve('http://snurl.com/2luj3', function(url) { 
  alert(url); 
});
 
// Using the original URL to work out if it has changed
Endpoint.resolve(
  document.getElementById('testurl').value, 
  function(url, orig) { 
    alert(url); 
    alert(Endpoint.isRedirecting(url, orig));
  }
);
 
// How it is used in the Twitter Endpoint Resolver
Endpoint.resolve(url, function(resulturl, originalurl) {
  if (!Endpoint.isRedirecting(resulturl, originalurl)) return;
 
  newtext = newtext.replace(originalurl, resulturl, "g");
  jQuery(el).html(newtext);
});

Under the hood, a bunch of stuff is happening. I would love to be able to just use XMLHttpRequest to dynamically hit the URL and look at the headers, but the same-origin policy stops me.

This is why I have the server proxy, which returns a JSONP callback.

When you call resolve(url, callback) the script tag is created on the fly and added to the DOM. The callback function is all handled to allow multiple calls, and then the chain unravels.

Here you can see it all in action, showing how my Twitter stream will go through and the URLs will dynamically change from their tinyurl versions to whereyouaregoing.com:

I wanted to use App Engine to host the server proxy, but unfortunately I can’t work out how to do that yet. You have access to the URLFetch API to access resources from App Engine. Unfortunately for me, one of the features is that it understands redirects and just goes on through to the full resource itself, with no way to get the endpoint from the headers in the response.

It was also interesting to read Steve Gilmor talk about these services all be it in a post that is hard to actually understand ;)

Also, Simon Willison just put up a simple service on App Engine, json-time, that “exposes Python’s pytz timezone library over JSON.” I think that we will see a lot of these types of mini-Web services hosted on App Engine. Taking Python utility and making services from its goodness is an obvious choice.

ShareThis

If you like this application now, you will love how it runs if you were using a modern browser

This happens if a non-Grade A browser is detected. We can even go further and push a new version of the browser the person is using. For example, if someone comes in with IE 6, we prominently show IE 7, and then also offer Firefox 3, Opera 9.5, Safari 3.1 for Windows.

As Web developers we have put in so much time just to make sure that IE 6 runs our application well. This is like writing desktop software that runs well on an 8 year old machine!

It hasn’t mattered all that much until the last year or so, as now we are developing richer and richer Web applications.

As I look at apps like Gmail, Mobile Me, 280 Slides, Yahoo! Mail, etc etc…. I say screw it. People upgrade their computers when they want to run things faster, why can’t we ask them to upgrade their browsers.

If you have a simple content site, then it is fine to support everyone, but as you build rich apps, maybe it is time NOT to be a crutch and support these browsers.

It is interesting to note that Mobile Me doesn’t support IE 6. People have shouted at the SproutCore chaps, but SproutCore actually DOES support IE 6. Interesting huh?

If Apple can do it… who next?

ShareThis

I may, or may not, agree with the opinions of Steve Yegge

Being an employee of a large company is interesting. If you work for companies like Apple, Microsoft, Yahoo!, and many others, you will have some of the same experiences. You represent the company. You hang out at a wedding and someone finds out “oh, you work for Google.” You wonder what is coming next. Should I have remembered me t-shirt that says “Just because I work for Google doesn’t mean I will fix your computer”? Will you get the “can you fix this one issue with my Gmail” thought? Or, the “man your search ruuuuules”, or the “Are you big brother?”

I have learned not to be at all defensive if I get asked questions about privacy and data. In fact, just last week, one of the nice chaps who created Masterplan The Movie showed up to an event in Munich. He kindly said hello and we started to talk about some of the issues. I think that he may have expected me to get defensive.

The problem is that I can’t “prove” that Google believes in its “Don’t be evil” mantra. I personally believe in it, and have seen it in action on a daily basis, but you may not have. How could you just take my word? What I can do is ask you to look at our actions, both in the past, and in the future. Google’s entire business model requires trust. You could switch from google.com to another search engine very easily indeed. There is no lockin there. So, we need to provide you the best search results available, and we need you to trust us that this is the case.

Trust came up the other day when someone blogged about the Ajax Libraries API launch. As you know, the launch was all about how we are hosting popular open source JavaScript libraries, and the skeptics quickly wondered why Google would do that. “What is their business motive.” One chap pondered on the fact that if we were delivering jquery.js to him, we could put any old JavaScript in there to do anything we wanted. Maybe we would add some kind of tracking to help us target ads.

Again, rather than arguing “hey we are good guys”, it was easier to talk about reasons why that may not make sense.

For example, a lot of sites use Google Analytics, and embed urchin.js in their pages. A lot of sites. We could do anything we want there too, but why would we. If we got caught out can you imagine the blogosphere. Arrington would be shouting bloody murder about Google. We would lose trust, and that would hurt.

Some may grow frustrated with the skeptics, but I applaud it. There are a lot of people from within that are pushing boundaries. Internal Googlers are not shy about calling fowl if they see it happen. With people watching every move of Google, especially with the high bar that we set with the motto, we are more likely to truly do the right thing. If we step over the line, people are there to shout back and us, and that keeps us honest.

So, thanks for the skeptics. I won’t try to persuade you how good we are at Google, just keep on watching.

ShareThis

I found myself talking about App Engine on the On Air tour, so I decided to change the example to not store the data locally with Gears, but instead to save it away into the cloud via App Engine.

Why did people want to hear about App Engine at an Adobe conference? I think that Jonathan Schwartz got it when he mentioned rich internet back-ends. As you build rich clients, you suddenly realise that the promised benefits of web services can kick into gear nicely.

Back to the sample. The architecture change was quite simple. Where I was doing a local DB save, I would call a back-end service such as /loadcontacts or /savecontact depending on the task.

You can view and download the full App Engine project code for this sample, and you can see it running live on App Engine

Check out the video below, or view the high quality version (recommended) to see the code walk through, and the various tools that App Engine gives you to develop, debug, and monitor your application running at a few thousand feet.

ShareThis

The Adobe mini-conference was held at a great brewery, and we got the tour the night before. The Czech folks take their beer seriously, and they are the inventors of Budweiser, but don’t hold that against them…. their Budvar is actually good (and not like having sex in a canoe!)

After checking out the taps, we got to taste the beer, which ran smooth. Holding the actual event at a brewery also means that you open up the taps in the afternoon, which gets the crowd in a good mood indeed.

After train rides shared with women and their pets, I got to another place known for beer. Sitting in the Biergartens of Munich, with full Litre jugs to wash down the Currywurst. It was bitter sweat to soak up the Euro 2008 footy action, what with our lads not being there at all.

The event was fun again, as I got to talk more about App Engine to the crowd:

After a week of beer, I found myself back state-side and on a bus full of Googlers to Napa for an offsite. We ended up at Del Dotto Vineyards where the owner took us on a wild ride of fine wine.

Right at the beginning you will hear him say:

“You guys here do software and that kind of stuff? This is going to blow your mind”

This was one of the finest meals and wine tastings that I have ever had. I can’t recommend it enough! Now, I am ready for some water for the coming week…. until I head to Mexico and Sao Paulo, which will mean Margs and Caipirinha?

ShareThis

Above is a picture of my iPhone at my house right now. It is infuriating to have ridiculously poor coverage living in Palo Alto. I have had full bars at the top of mountains, but in the center of Silicon Valley I have one? Are you freaking kidding me?

This is why I can’t wait for VoIP on iPhone 2.0, so I can stick my nose at AT&T as I make decent quality calls from home.

ShareThis