techno.blog("Dion")

I have seen a few people a little saddened by some of Obama’s recent moves, especially geeks on the FISA vote, which upset me too. It is wrong. We need new privacy policy.

As I thought about this, I started to think about expectations. By taking the higher ground, and telling us that he will do so, Obama has set himself a higher standard. This relates to me, as I have talked in the past about the higher standard that Google has to live up to thanks to “Don’t be evil” and other such things. As an employee, and a person, I actually like the somewhat constraining higher standards. It means that colleagues can’t take shortcuts, and things can’t sneak by… and if they do? Then we pay for it as a company. Our trust is tied to our business, which is tied to who we say we are.

The same is true for Obama. If McCain does something, sure we can use it as a talking point, but there is more leeway. Ah, he is an old school politician, that stuff just happens. Not with Obama. If he does anything that we don’t agree with, he can get jumped on by many sides. This can be hard as what one person thinks is moral, isn’t the same for another. He has a tough road ahead, but the benefits are that people believe in him and we will come to a new presidency with that Hope that we have been hearing about. With the entire RNC coming after him, the battle is just about to start.

What if he does get in? Those expectations get in too. The tone gets into the office. He could go to Iran and say “let’s put some history behind us and make a change that benefits all of us.” People will be more receptive to change, and boy do we need it. So, even if he isn’t as perfect as some make him out to be, he will have to live up to the image to survive, which means a better, stronger, president of the USA.

I also got to see a fantastic and entertaining talk at Google that is now on YouTube. The talk was by Dan Ariely, an MIT professor working on Behavioural Economics. Really though, it was one of those talks that reminds you that us humans…. we are animals man.

Professor Dan Ariely visits Google’s Mountain View, CA headquarters to discuss his book “Predictably Irrational: The Hidden Forces That Shape Our Decisions.” This event took place on July 1, 2008, as part of the Authors@Google series.

In a series of illuminating, often surprising experiments, MIT behavioral economist Dan Ariely refutes the common assumption that we behave in fundamentally rational ways. Blending everyday experience with groundbreaking research, Ariely explains how expectations, emotions, social norms, and other invisible, seemingly illogical forces skew our reasoning abilities. Not only do we make astonishingly simple mistakes every day, but we make the same types of mistakes, Ariely discovers. We consistently overpay, underestimate, and procrastinate. We fail to understand the profound effects of our emotions on what we want, and we overvalue what we already own. Yet these misguided behaviors are neither random nor senseless. They’re systematic and predictable—making us predictably irrational.

In the talk Dan shows so many cases of how we trick ourselves such as:

• Spouse: A group was given a questionnaire. Half of the group was asked to write down 10 things you love about your spouse. The other were asked to note just 3. When complete, the next question was about how long you think you will stay married. What is interesting is that the people who were asked to jot 10 things thought they would last a lot shorter than the group who only had to think of 3 because….. thinking of 10 things is hard!
• Signing: Asking someone to sign “what I am about to do is true” versus “What you just signed is true?” made a huge difference. Dan worked with an insurance, who did A/B testing on a form asking how many miles you drive and there was a drastic difference. It turns out that the majority of people lie, but just a little.
• Comparisons: Dan saw that The Economist had a purchase page that allowed you to choose between a Web version, print version, or both. The strange thing was that the both and print version were the same 129 pound price. With that comparison people were much more likely to choose ‘both’ than the cheaper Web only version. Take away the choice, and the game changes.

And this leads us to the tie in to politics. He showed that comparisons happen with people too. Showing three photos of “similarly attractive people”, where one of the photos was a slightly uglier version (via Photoshop) meant that people selected the good looking double way more frequently.

With this election we have a young up and coming chap, and an old geezer. If a third candidate came around who was a slightly worse old geezer it would help McCain…. maybe if Nader does well? Or what about running mates, how much of the look will matter there as well as policy?

Watch Dan’s talk. Great stuff.

Whenever you work on SEO for your Web site or application, what do you have to do? You have to test it. You have to make changes and watch what ends up in the index of search engines. Then you iterate on your task to get the correct and most relevant information in there.

Google announced that we now index SWF with a new algorithm, as does Yahoo!, in cooperation with Adobe.

The new SWF runner can “act like a human” and access elements and see what happens (e.g. click on a button). Immediately people worried that the tester could act like the Google Web Accelerator, and if you have a poorly designed application that had a [DELETE EVERYTHING] button it would get clicked and boom.

Aral Balkan asked if we are indexing too much and others went even further and randomly said don’t build your site in Flash.

The folks who came out saying that “now my internal files aren’t hidden!” are fooling themselves, as you can’t hide things via obscurity. To the real point though, if you are conservative you can use good ole robots.txt to disallow the search engine access to your SWF files.

Then, you can run some tests and see what happens. Just as everything else with SEO, you will need to play the game of seeing what happens as you make changes.

In the end, I want search engines to get a lot smarter at indexing this kind of content (ditto for rich Ajax applications) and we all need to work together to make that happen.

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

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

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.

I have had an interesting week to say the least. I had the pleasure of joining the Adobe On Air tour of Europe in Prague. It was my first time to the city, which is a beautiful blend of east and west Europe.

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?

Nick Johnson, of Google, has created a nice bridge service smtp2web.com: Allow App Engine apps to receive email.

This is perfect timing, as after my App Engine talk in Prague, a nice gent came up to me and asked for just this. He wanted to process email in his application and didn’t think he could.

One shortcoming of purely HTTP-based webapps such as App Engine is
that they can’t receive email. I know that some people are wanting to
create App Engine apps that do this, so I put together a service to
facilitate this. It runs as a standard SMTP server, and sends all the
email it receives via HTTP POST to a user-designated URL. It’s free to
use (but not to abuse)

To use the service, you setup an email account (say dalmaer@smtp2web.com) and a URL to point too. Of course, if you want an email on your own domain you could alias dalmaer@yourdomain.com to dalmaer@smtp2web.com).

Then, you would configure an App Engine controller to receive the email contents:

from google.appengine.ext import webapp
import email
 
class EmailHandler(webapp.RequestHandler):
  def post(self):
    sender = self.request.GET.get("from", "")
    recipient = self.request.GET.get("to", "")
    message = email.message_from_string(self.request.body)
    # Do stuff with the email message

The code for the service has also been released as open source on Google Code so you can check it out. You will find that it runs as a Twisted application:

from twisted.application import service
from twisted.application import internet
from twisted.enterprise import adbapi
 
import sys
import os
sys.path.append(os.path.dirname(__file__))
 
import smtp2web
 
application = service.Application("smtp2web Service")
 
settings = smtp2web.Settings(secret_key="<enter secret key here>",
                             state_file="state", master_host="localhost:8081")
 
smtpServerFactory = smtp2web.ESMTPFactory(settings)
smtpServerService = internet.TCPServer(2025, smtpServerFactory)
smtpServerService.setServiceParent(application)

Thanks for doing this Nick!

NOTE: Mailhook is another service (pay) that does something similar

I was really excited to launch the AJAX Libraries API (I know, I know, I hate typing “AJAX” too…. haven’t you seen the rotating header on Ajaxian? ;) at Google I/O this week.

The only problem with the timing was that at the same time that it was getting picked up by the trade rags, Wired, reddit, Slashdot, Ars Technica, etc…. I was busy getting prepared and working Google I/O! This made it hard to stay up on what was being said and really being there to comment etc.

All in all I was shocked at the level of response. I knew that developers would get it, but seeing tech journalists see value in something that isn’t flashy or even provide something “new” surprised me.

There have also been some really good comments, and tips such as this one showing a nice way to use the API side of the house (google.load vs. script src) and load your other libraries after.

I also like the Wordpress plugin that seamlessly mixes local development and “production”.

Steve Souders also had some good thoughts and stats.

The key though is what happens next. To get something out of the door for a version 1 release, you sometimes cut features and just get it out. We have some great libraries out there now, but I want to aggressively get more out. We are not trying to be king makers here. Ideally I would love a system where anyone can add their scripts, but this isn’t as easy as you would think. For one, how do you stop people from putting bad stuff on there (if you could upload anything, you could put god knows what there). One of the core goals is to have stable releases on the system only. We have to make sure that we have the rights to do this, which means that the libraries are open source in a way that we feel safe.

That being said, we want to do a better job at getting feedback on the libraries that you want to see up there, so I am hoping to do something about that soon.

Lastly, there is room to do so much more. Steve Souders can help us with the performance side of things and has great ideas on how a loader could really add a lot of value here (e.g. choose how to add a script to the page depending on the use case). Then we can work with the browser vendors and see if there is a way to aggressively cache these libraries even more. Gears itself could also have a cache module that could do this. We need to think hard about how a hashing algorithm could work here, and make sure that it couldn’t be hijacked. Brendan has me scared there.

So, overall I am excited to see how we can build on this first release, and help the community further. Please let me know what you would like to see.

Check out more coverage in the news and across blogs.

I got to meet Aaron Spangler, one of a two man team that decided to use their 20% time at Google to build a indoor solar-powered calendar display that hooked into Google Calendar and once ever hour updates the epaper.

In the video he details his experience, and we show it in action. Fun stuff indeed, and here is some of the technical goodness:

The goal of Radish is to replace this manual process with a portable device that can wirelessly retrieve and display scheduled events for conference rooms. For Google, this would translate to a savings of about six reams of paper a day, not to mention the printer resources and manual labor required to deliver the paper schedules to the conference room doors. Aaron has also determined that about 20-30% of all reservations are changed during the day, hence the Radish also overcomes the static nature of a paper display with real-time data.

The Radish is a working prototype that is built entirely from scratch and assembled using generic, off-the-shelf hardware components. Custom firmware was written in C and assembly language.

The CPU of the Radish board prototype is programmed to manage power usage and to transfer and display data. The display of the Radish is a special LCD screen that maintains the downloaded image without consuming power.

The Radish is equipped with radio transmitters that uses the IEEE 802.15.4 protocol to send and receive data wirelessly. IEEE 802.15.4 is ideal for ubiquitous communication between devices within a wireless personal area network because of its focus on delivering low-cost and low-speed communciation.
This is why IEEE 802.15.4 is far more energy efficient (about 1mW per radio) than traditional Wi-Fi.

Radish uses the radio transmitters to ping and receive display data from an external server. This custom server fetches the set of event data pertaining to a conference room via the Google Calendar Data API. Using the Google Calendar Data API, the server is able to sync event data with Google Calendar. The event data is then processed into an image that is specifically sized for the LCD display. The MAC address of a Radish’s wireless receiver is used as the unique identifier for the room it represents.

All electronic components were selected with one important criterion: that they must be compliant with the Restriction of Hazardous Substances (RoHS) Directive which restricts the use of hazardous materials (mainly lead) within electronic equipment. Another major area of environmental focus was the power supply of the Radish, particularly how to efficiently and cleanly power the Radish around the clock. The Radish team members (Aaron and fellow engineer Matthew Wilson) made a point of not using batteries to power the device. Instead, their desire was to utilize natural, carbon-free energy.

After investigating various energy sources, the team decided to use solar energy. Attached to the Radish board is a solar panel that collects and stores solar energy. The solar panel of the Radish is capable of collecting any source of light energy, including normal office lights, hence it might be more appropriate to say that Radish is powered by ambient energy.

The Radish is normally in an ultra-low power sleep mode. The Cholesteric LCD screen can maintain the final image state even in sleep mode, the state in which Radish spends most of its time only periodically waking up to ping its server for updates. The gap between sleeping and waking is determined algorithmically depending on how much energy it currently has in storage. With the ingenuity of the power management algorithm, the Radish is exceedingly efficient with power usage. A fully charged Radish can be running continuously for 3-4 days with a guarantee of at least one daily update, even in low light conditions.

I was really excited when the Google I/O folks told me that Flight of the Conchords were going to be playing at the event.

I saw one of the chaps do standup in New York city, and he was hilarious.

I better get a back stage pass guys!

Oh, and I am speaking at the event with Ben, so give us a shout.