Offermann.us

Uh oh.

Marissa Mayer kicks off her speech by talking about artists and fashion designers creating custom background images to use on iGoogle home pages. This is what’s exciting at Google right now?

Minutes go by, and still more fluffy iGoogle talk. Now, I’m really worried…she’s going to crash and burn. I mean, she’s speaking at a conference for developers…and she’s talking about wallpaper?

Thankfully, once she really got going, her speech turned out to be quite entertaining and was filled with funny stories about the early days of Google.

Some tidbits:

• She once asked Sergey Brin to explain the spare design of the original Google home page:

  “We didn’t have a webmaster…and I don’t do HTML.”
  

• Early user testers would just stare at the Google home page…and not type anything into the search box.

  Why?

  They were waiting for the rest of the page to load.

  To solve this problem, Google had to add a footer, so people knew the home page was done loading.

  “Our copyright notice isn’t legally required.  It’s punctuation.”
  

• Every search query on Google hits between 700 to 1000 servers before serving the response. Think about that the next time your search results return in 0.09 seconds.

• “Design is becoming more of a science than an art.”

  They do tons of A/B Testing at Google, testing every tweak to the site on a small percentage of their users and then watching to see how it impacts their “Happiness Metrics”. Which means that they don’t have to guess which design or feature is better. They have numbers, hard evidence that one is better than another.

  Two examples:

  • Less white space around their logo made their users more satisfied.
  • Displaying more search results per query caused happiness to plummet, because adding even the tiniest fraction of a second to the page response time resulted in decreasing user satisfaction.

I’m at the Google IO Conference in San Francisco. It’s late at night…I’m still decompressing and trying to make sense of my notes from the day’s sessions.

I’ve put myself on a self-imposed “App Engine Only” track, so I haven’t really followed the news and announcements regarding Android, or OpenSocial, or Google Gears, or any other Google initiative.

Though they did show a way cool Android mobile phone demo in the Keynote. The phone had a built-in compass, so you could run the Google Maps application and look at the Street View, and then as you moved the phone, the Street View would sync to the new compass direction. In other words, as you moved the phone from North to South, the Street View photos would also pan from the North view to the South view. Spontaneous cheering from the crowd.

App Engine Talks

In any event, here are my takeaways from today:

• Use Django. Don’t use the one that’s bundled with App Engine (v. 0.96). No, check out the latest development version of Django from subversion (currently 0.97). What’s interesting is that even though Google App Engine ships with the webapp framework and with Django 0.96, Guido van Rossum chose to devote his talk to how to install and use Django 0.97 on Google App Engine. I was curious what that meant for webapp, so I asked if there was ever a reason to use webapp instead of Django. Guido’s answer was that webapp was simple and enabled you to get started very quickly. But, Django was more powerful.

• If you use the Datastore correctly, scaling comes for free. But, it takes a lot of work to use the datastore correctly. Further complicating the issue is that nobody knows exactly what “correctly” means yet.

• Pay special attention to Datastore writes. “Reads are cheap! Writes are expensive!” Every write is a serialized transaction that hits the disk. Rule of thumb says you can’t do more than ~100 seeks/sec, so that’s the upper limit for write speed.

• For high-contention write situations (like a counter), don’t write to a single, global counter class. Instead, use “sharded writes” where you write to several entities, and then sum the totals from all the shards to get the total count.

• Entity Groups are for transactions. I did not understand the point of parent-child hierarchies for entities before today, but now I see that their only purpose is to group entities that need to be changed together as a part of a transaction.

• The Datastore will not help you maintain data integrity. It’s entirely up to you, especially when you are updating or deleting entities with ReferenceProperties. Seeing the code examples today that showed how to handle deletes properly makes me appreciate how nice it is to have a relational DB handle this automatically.

• Don’t use count(). Ever. This was stressed in several presentations. Not only can it not count past 1000, but it also requires a scan of every entity, thereby using way too much processing power.

• You can’t use JOINs in queries, but you can utilize the foreign-key-like ReferenceProperty to associate entities and therefore, do JOIN-like queries on them. In Rafe Kaplan’s talk about “Working with Google App Engine Models”, he walked through one way to model one-to-many and many-to-many relationships. I found this particularly interesting, in that it demonstrates how to have a relatively normalized data model, directly contradicting the emerging idea that the best way to take advantage of the Datastore is aggressive de-normalization.

• The index.yaml file defines the composite keys needed for complex queries. All queries rely on the Indexes, which are separate BigTable tables. If a property value isn’t indexed, it can’t be found by a query. Now, that’s not a problem for querying by kind or single property values, since indexes are created for these automatically, but it is relevant for complex queries, since composite keys are not created automatically. (The dev server automatically updates the index.yaml file as complex queries are run in the dev environment, so as long as you test every query on dev, you’ll be fine.)

Several themes came up over and over in the Q&As that followed the talks:

• Maintaining Data Integrity, Especially over Time. How do I migrate data models? How do I delete columns, or rename columns? How do I rename classes? How can I make changes and not break data integrity? Nobody’s figured out good answers to these questions yet.

• Bulk Data Operations. How can I import and export large data sets? How can I bulk delete? The App Engine team stressed that they were well aware of this limitation.

• Full-Text Search. How can I do full-text search over my data? Shockingly, developers uniformly expect Google to be really good at full-text search…imagine that! Sadly, it’s not there yet, though Google engineers mentioned that there’s “currently a hack in place that kind of works”, and that they would provide this feature sometime in the future.

In his presentation on how the Datastore works under the hood, Ryan Barrett offhandedly mentioned the three big priorities for the Google App Engine Team right now:

1. Data Import/Export
2. Additional languages
3. Billing

All in all, the Google App Engine talks were fascinating. Using Datastore is so new, and it’s such a departure from using a relational DB, that it’s exciting to see everyone try to figure out how to best utilize it. Though, one thing I was struck by was how tentative some of the suggestions were from the Google engineers. I had expected that since they have several years of experience building applications on top of BigTable, that they would have created more definitive best practices for how to handle common data models and for maintaining data integrity. Perhaps it’s so new that even Google is still figuring out how best to work with it.

Portland’s second ever BarCamp (a free-form “unconference”) was held this weekend, and since there were no soccer or Little League games for me on Sunday, I was able to catch one day’s sessions.

Not knowing what to expect when I arrived, I quickly found an enthusiastic crowd, plentiful food (bagels stacked high and all the Bubble Tea you could drink), and lots of interesting sessions, with topics ranging from WordPress to CrossFit to Bikes to Patents to Predicting the Stock Market.

You are Your Twitter Name

As you register, you’re handed a badge so you can write your name and other key information. But, you don’t identify yourself by your email address, or your blog, or your domain name. Instead, at BarCamp Portland, your identity is your Twitter identity.

As I looked around at other people’s badges, I noticed that nearly everyone had a Twitter name.

I was surprised at how ubiquitous Twitter was. “What’s wrong with the alternatives?”, I wondered. Here’s my stab at some answers:

• Email. Too much spam. People suffer from email overload. Plus, there’s no way to learn more about someone if you have only their email address.
• Blog. Not everyone has a blog. It’s much easier to start twittering than it is to set up and maintain a blog.

Whatever the reason, Portland BarCampers have clearly chosen Twitter their default online profile.

Wordpress as CMS

I sat in on several WordPress-oriented sessions, and “Using WordPress as a CMS” was my favorite. Ben Hengst from Powell’s Books talked about they were using WordPress on powells.com.

The Powell’s Web site is made up of many different systems (some written in perl, some in PHP), and Wordpress currently only powers the PowellsBooks.Blog section of the site on the front-end. But, as the developers and Marketing folk began to use WordPress more and more, they found that it offered a simple interface for Marketing folk to input reusable content, and that it’s database structure could handle the different types of content they required. Ben said that using a combination of tags and categories gave them all the flexibility they needed.

So, now, they are inputting content with the WordPress Admin interface on the back-end, but then pulling that content from the WordPress database with the perl and PHP code that runs the rest of the site. In other words, much of the content that is entered in WordPress is never displayed by WordPress.

Random Observations

Sometimes it’s the little things that you see or hear about that make the event worthwhile.

• I heard the story of writing an innocent blog post about how you are unable to burp on demand…and watching a whole community of non-burpers spring up around it.
• Reid Beels was giving an overview of how to write a WordPress plugin…and then offhandedly demoed a really cool javascript photo display (hover over one photo and see how the rest of the photos evenly resize).
• I spotted someone wearing not only a Utilikilt, but Vibram Five Fingers shoes as well. A somewhat radical look…but he totally pulled it off.

(Or, An excuse to compile a bunch of links about myself for Mom…)

These days, you don’t even have to make an effort to be on the Internet. Even without starting a blog, you’ll find that your name, or your photo, or even a video of you, will somehow make its way onto the Web.

• All you have to do is work out at a gym.

  My gym is called Crossfit HEL. (Add an ‘L’ for an even more appropriate name…) Every time I complete a “Workout of the Day” (WOD), my time or score is posted on the CrossFit HEL blog. Sometimes, my photo is even posted.

• Or, you can just take an Olympic Weightlifting class. (I’m in the back row.)

  
  

• Or, you can take a class on making strawberry jam. (I’m the only guy in the video.)

I guess nowadays, there are no offline activities. All offline activities inevitably wind up online.

It’s all Aaron Hockley’s fault.

All last week, he’s been on Twitter relentlessly beating the drum for Portland bloggers to add OpenID support to their blogs.

So, I did.

And, he was right. Setting it up was a breeze with the Wordpress OpenID plugin. Now, thanks to Aaron, you can save yourself the trouble of typing in your name and email address when you leave a comment, so long as you have an OpenID account.

(If you don’t have an OpenID account, not to worry. Leaving a comment will work exactly as it did previously.)