pamela fox's blog

Website Monitoring Services

2012-01-17T08:51:00.000-08:00

After posting the iPhone app for EatDifferent in the App store last week, I've seen a noticeable increase in new user signups — despite the fact that there's no signup through the app itself, only through the website. That means more traffic to the App Engine hosted webapp, and unfortunately last night, it meant more traffic than my webapp was configured to handle. My webapp went over quota at around 10:30pm and served 503s until midnight, at which point the App Engine quotas reset and it started fresh. I was sleeping at the time, blissfully unaware that it was over quota, and I didn't find out until the next morning, thanks to a personal email from a friend and early user.

Why didn't I find out? Well, I have a lot of error logging in my app, but 503s don't actually trigger the error logging, since that logging is in the app code itself, so I didn't see any errors come through my inbox. Most webapps are like that — when their host goes down, their logging goes down with it — so that's why many website monitoring services exist. These services live outside of your webapp (hopefully on a different hosting system altogether), ping it every so often to make sure its returning HTTP 200s as expected, and alert you when it's not. I knew about such services, but of course, I didn't think to set myself up with one until after I needed it. You live, you learn.

After beating myself up for a few hours in the morning, I started investigating website monitoring services — and by investigating, I mean that I asked my Twitter followers for their recommendations. Here's what they suggested:

All of those services offer standard downtime monitoring, but some of them also offer performance monitoring and offer their service as an API or SaaS. For my purposes, I wanted something easy and free, and since it doesn't hurt to have multiple monitoring services, I went with UptimeRobot and a Pingdom free plan. They both offer alerts over email, SMS, and Twitter, plus Pingdom offers an Android app with push notifications. It was easy to set them up, and (its funny saying this about a service) hopefully, I will never have to hear from them... But just in case, I'm glad they're around!

Testing Facebook Login with Selenium

2012-01-16T18:55:00.000-08:00

On EatDifferent, I give users two options for signing up: Facebook, for people that like the convenience of using FB to sign in everywhere, and email+password, for people that hate Facebook. I see about 50/50 usage for these options, so they are both equally important — which means testing both of them are equally important.

Until today, however, I only had integration tests for email signup and login, because, well, I was afraid. All I have to do for email login testing is enter a few text fields, but for Facebook testing, I would need to navigate to the Facebook popup window and manipulate *their* DOM, and I would need a test user account that was really and a truly a test user (and not my cat, who actually is surprisingly active on Facebook). As I was making some changes that affected Facebook users today, I decided it was time to face my fears. Good thing I did, because testing Facebook login turned out to be pretty easy. Read on to see how I did it...

Create a Test User

In the land of old, creating a test Facebook user meant digging up an old email address and signing up with your cat's details. That kind of sucked, since you only have so many old email addresses, and it wasn't exactly Facebook TOU-friendly. Thankfully, Facebook introduced a way earlier this year to create multiple test users, both programmatically and from the developer dashboard. For the purpose of my tests, I only need one test user, so I created him semi-manually with these steps:

Go to http://developers.facebook.com/apps, and select your app. Click 'Edit app' and then 'Roles' on the left-hand side.
Under 'Test Users', click 'Add'. Select '1' and don't select 'Authorize this app' (if your purpose is to test authorization).
Once created, click 'Modify' in the 'Test Users' section. You'll see a table with information about the test user, like their name (which you can change to something snappier, like "Sharky Shark" :) and ID.
Now you need to find out the user's password, so you can enter that with Selenium. First, get an access token for your app by putting this URL in the browser and replacing the client_id and client_secret with your app key and app secret:
```
https://graph.facebook.com/oauth/access_token?client_id=APP_KEY&client_secret=APP_SECRET&grant_type=client_credentials
```
Now paste this URL in the browser, replacing the ID with your test user ID, access_token with the string you just got, and password with your desired test password:
```
https://graph.facebook.com/TEST_USER_ID?password=TEST_PASSWORD&method=post&access_token=ACCESS_TOKEN
```
Click 'Login' in the users table so that you're logged into Facebook as them. Visit their profile, take note of their email address, and change any desired fields (depending on what your app uses - I gave mine a profile pic and location).

Presto, now you have a test user.

Test the Facebook Popup

For my integration tests, I use Selenium with its Python API and Python's unittest module.

For my FacebookTests test case, I extend my BaseTests class and add two test methods, one for testing authorization and the other for testing login.

Those test methods use the FacebookDom helper class (an extension of my DomHelper class) for finding and manipulating the Facebook window and DOM. Note that after the user has granted the authorization, Facebook will no longer ask for authorization unless the user specifically revokes it - so my do_authorize_flow function checks to see if the auth button is actually there before trying to click it.

Ta-da, now you have a tested Facebook authorization and login flow! Some may argue that you shouldn't try to test 3rd party APIs because they may go down or be flaky or such and that you should mock them out instead, but I'm of the philosophy that integration tests should try to mimic the production environment as much as possible. And hey, I want to know if Facebook goes down, changes their response, or becomes flaky.

Ada Lovelace Day: Women that Inspire Me

2011-10-07T12:46:00.000-07:00

Today is Ada Lovelace Day, a day to celebrate the women of math, science, and technology, and the challenge today is to write a blog post highlighting a woman that inspires us. I blogged an interview with my mum a few years ago (the first woman in tech I ever knew!), so this year, I thought I'd highlight a few women that inspire me today.

Sara Chipps:
Sara started GirlDevelopIt in New York, with the goal of getting more women in web development by actually teaching them how to do it. She inspired me to run a GirlDevelopIt in Sydney, and I still remember those months as some of my favorite down under. In addition to being the force behind GDI, Sara still develops - just yesterday, she wrote an uber-useful Chrome extension that I installed instantly.

Follow Sara online: Twitter | Google+ | sarajchipps.com
Gina Trapani:
I first knew of Gina for starting lifehacker, a popular blog of tips for using tech and optimizing your digital life (and the biggest source of traffic for my little Profane Game). I then knew her as the author of "The Complete Guide to Google Wave", an attempt to explain how to use Wave to the average joe. I was on the Wave team then, and I knew that was no small feat. And now, I know her as a developer, working on an open-source web app for social media analysis. Blogger, author, coder, speaker - Gina does it all.

Follow Gina online: Twitter | Google+ | ginatrapani.org
Leigh Fonseca:
I met Leigh just this week, at the WITI Next-Gen Summit, where Leigh and I talked to high school girls about how we got into tech and why we love it. Leigh started off with a history degree, but when she realized she had a thing for analyzing customer data, she started data science departments at Rhapsody and then BookRenter, where she is now. Most companies don't have data scientists nor realize they need one, so Leigh is paving the way for others with her interest. When she's not analyzing data, she's preparing for triathlons. Impressive.

Follow Leigh online: Twitter | Google+ | dataparty.blogspot.com
Kendall Ronzano:
I also met Kendall this week - she's actually one of the girls that Leigh and I talked to at the conference. She's a high school junior who's already started programming for her robotics team (C++!) and wants to learn more. She's also set a fun challenge for herself: build a house. I hope Kendall represents the next generation of women in tech!

So, who inspires you?

WDCNZ: The Developer Experience

2011-08-03T21:16:00.000-07:00

Last month, I had the honor of giving the first talk of the day at WDCNZ, a new conference in Wellington, New Zealand. WDCNZ was the brainchild of Owen Evans, one of the lead developers at Xero, and his goal in putting it together was to provide a full day of technical talks for web developers and to bring the local web development community together. I wanted to give a talk that would be interesting to web developers of all different sorts, and also would be something I'm passionate about myself - so I decided to give a talk around a topic I wrote a handbook about and discussed in recent blog posts - "The Developer Experience."

For my talk, I wanted to explain what I think of as "developer experience", motivate people to really care about it, and give concrete examples of what makes for a great experience. It was an interesting talk to prepare and give, and hopefully gets other people thinking about the topic and giving similar talks in the future. I've embedded the slides and video below so you can watch for yourself what I said. Thank you to WDCNZ for giving me the opportunity to give the talk and for an awesome conference!

The Developer Experience (Slides)

The Developer Experience from WDCNZ on Vimeo.

So, what am I, exactly?

2011-05-16T12:03:00.000-07:00

Lately I have struggled to find a good answer to the question "So, what are you?". When I was a kid, nobody asked me that - I was just a kid. At the most, they'd ask me what grade I was in, and that was easy. Then, in my first (and only) job at Google, when people asked me that, I could answer with my job title. But now that I'm not a kid or a Google employee, I'm not quite sure what I am.

My standard response has been "web developer." I do web development, I go to all the web development events, and all the people I helped as a Googler were web developers. But I'm not convinced, and I become less convinced the more I am approached by people looking for "web developers" thinking that I fit the bill. I know this doesn't bode well for my job opportunities in the future, but I don't think I'm actually a "web developer", at least not the kind they are looking for.

See, when I do web development, I do it because it is the best way that I know to turn an idea into something tangible; I don't do it purely for the joy of programming. I don't dream of spending all day coding, I dream instead of making things that I enjoy, and maybe a few others too. In fact, I don't think I would be happy spending all day programming for months on end; I like too many other aspects of making things. I want to write about them, I want to brainstorm them, I want to tell the world about them. I want to spend equal parts of my life using the different parts of my brain, and I want to be able to share creations with the world as a result of that synergy.

Why does it matter what I am, anyway? Well, first, I need an answer for all the people that I meet now, who want to be able to fit me into a nice bucket in their head. But, second, I need to figure out what I'm doing next in life. If I am a web developer, then I should probably join a new company, learn more web skills, and increase my knowledge there. But if I am not - and I suspect as much - maybe I should be picking a different path. I have done many side projects, and now it might be time for me to pick an idea and make it my main project, to see how far I can take it and how many people I can share it with. Or, put in the more usual terms of today's web world, perhaps I should become a (co-)founder.

I am not 100% sure of this - part of me is worried that I don't have the focus to pick one idea and stay with it, part of me is worried that I'll pick the wrong idea, and part of me is worried that I'm not business-oriented enough to make something profitable. But the other part of me thinks that I should find out or I risk spending the rest of my life wondering.

Reading My Way to Better Design

2011-05-13T10:34:00.000-07:00

I realized recently that I am completely capable of coding up a website frontend, but I struggle to make that website frontend look really good. My webdesign tends to be either too simple (“austere” is how one observer described it) or too tacky (my love for everything 80s seeps into all parts of my life). I was okay with this before when I was just making developer-facing demos, but now I’m at a stage where I want to make user-facing webapps, and I want the users to experience them and think “Wow, slick.”

So, I’ve set out to acquire a better taste in design, and I decided one way to do that is to surround myself on a daily basis with examples of great design. After Google’ing around and reading this HackerNews thread, I set up a folder in my Google Reader of 10 design-related blogs, and I now spend every morning reading through the posts (after drooling over my recipes feed, of course). It’s a great mix of topics, ranging from web design how-tos to well-designed physical products. It's hard for me to quantify if my design skills are improving, but I am at least thinking much more about it than before and acknowledging its importance.

If you want to do the same as me, you can subscribe to my folder feed or subscribe to the individual blogs listed below:

Please let me know in the comments if you have other suggestions for great blogs to read (and books too, while you’re at it).

No, Really, I'm Shy: My Ignite I/O Talk

2011-05-11T05:59:00.000-07:00

As many of you know, I'm kind of an Ignite junkie. I love the format - 5 minutes, 20 slides, 15 seconds auto-advance - and I love that I can use that format to talk about topics that I can't fill a whole hour with. At this year's Google I/O 2011 Ignite show, I got to give a talk on something that I think about a lot: my shyness. Most people don't believe me when I tell I am actually quite shy at my core, and so I dedicated my five minutes to explaining what shyness is to me and how I workaround it. The talk went well, and multiple folks approached me afterwards about their own shyness and hacks around it. Mission accomplished!

You can watch the video on Youtube - I'm at 24:09:

And/or you can read the slides on Slideshare:

No, Really, I'm Shy

Roundup: Developer Documentation Generators

2011-05-06T15:43:00.000-07:00

While researching what developers love about their favorite API documentation sets for my last post, I also investigated what tools the API teams use to generate the documentation. Some teams just hand-write HTML, but most use code-based generators for the references and/or some sort of markdown for writing the guides. A good tool or toolset should make it easy to update the reference for every API release (outdated documentation should be avoided at all costs) and painless to write documentation about how to use the API (writing is one of those tasks that people put off - the less obstacles there are, the better). Based on my experience, here are the questions you should be asking when picking a tool:

What is the input for the tool?
- Does it run over code and/or supplementary files? It's great to use a tool to automate your reference generation, but even better if you can use the same tool to write your developer's guide as well.
- What languages will it process? If your API is written in multiple languages (like Flurry, the company I did this research for), you probably want to pick a tool that will work over all of them so you can have a consistent process and output.
- What style of comments does it parse? If you're already using comments to instruct your compiler, you won't want to use a different format just for the docs.
What is the output for the tool? HTML is a must, even better if it can do multi-page and single-page. PDF and other formats can also be quite useful.
What is it written in? It needs to work in your development environment, and ideally hook into your build system.
How easy is it to customize for your needs? The ideal tool includes easy customization options that don't require digging into the code, but is also open-source in case they don't do it for you.

To give you an idea of (just a fraction of) what's out there, here is a breakdown of the documentation tools used by the APIs from the last post.

Multi-Language Generators

Tool	Input files	Input language	Input comments	Output	Written in?	Examples
Natural Docs	In code or other files	C#, Perl, AS2, partial support for other languages.	JavaDoc, or custom "natural syntax"	HTML	Perl	jqPlot, Users list
Doxygen	In code or other files	C++, C, Java, Objective-C, Python, IDL, Fortran, VHDL, PHP, C#	JavaDoc or QT style, with some support for other styles	HTML, TEX, RTF, PS, PDF, ...	C++	KDE, Users list
docco	In code	CoffeeScript, JS, Ruby, Python	Markdown	HTML	CoffeeScript	data.js and drops.coffee
Sphinx	In code or other files	Python, C/C++	RST	HTML, TEX, PDF	Python	Python, Django
DocBook	Generated from XML files	XML		HTML, PDF, CHM, RTF, ...	PHP	PHP.net

Single Language Generators

Tool	Input files	Input language	Input comments	Output	Written in?	Examples
JavaDoc	In code	Java	JavaDoc	HTML	Java	Android
joDoc	In code or other files	JS	Markdown	HTML	Perl	PhoneGap
JSDoc 3	In code	JS	JSDoc	HTML	Java/JS	None yet, in beta.
JSDoc 2 (JsDoc-toolkit)	In code	JS	JSDoc	HTML	Java/JS	Google Maps API v3
JSDuck	In code	JS	Markdown, HTML, some JSDoc tags	HTML	Ruby	Ext-JS 4
ErlDocs	In code	Erlang		HTML	Erlang	ErlDocs.com

If you're interested in exploring tools further, check out the Documentation Generators section of my Developer Support handbook and this nearly comprehensive comparison of documentation generators from Wikipedia. There are always new tools being built out there by developers not quite satisfied by the current offerings and going at it their own way - and that's a great thing for all of us.

Let me know in the comments what tools you use (or are building yourself!) and your experience with them.

Roundup: The Best Developer Docs

2011-05-05T10:08:00.000-07:00

As I mentioned in my previous post on "What makes a good Developer Experience?", I'm currently consulting with Flurry to advise them on improving their developer experience. They're starting with a revamp of their documentation and API reference. Per what I wrote in the Documentation chapter from the Developer Support Handbook, good documentation should include tutorial style content, an API reference, and sample code, and should be fully linkable and searchable.

To confirm that my criteria for good docs aligns with what developers in the wild think, I conducted an informal survey on Twitter asking developers for their favorite and least favorite docs. I reviewed their picks, and as I guessed, here's what was common amongst the favorites:

Easy navigation: everything linked, clear table of contents, every page just takes 1-2 clicks to get to. Example: Yii.
Easy search:. prominent search box with autocomplete for method/class names. Example: Sencha.
Reference *and* guide: most offer both a technical breakdown of every part of the API (the reference) as well as a step-by-step narrative guide for using the API. Example: Twilio.
Inline code samples: in the reference, every class/method comes with example code below the definition, and sometimes that code can even be run in the browser. (Or for HTTP APIs, sample request and responses in every data format are offered). Example: CoffeeScript.
Comments: a threaded comment system on every page, for developers to discuss issues or usage. Example: jQuery.

And here are some cool bonus features from the favorites (that may not work for everyone):

Community edits: The Mozilla Developer Center lets anyone login and edit the information themselves.
Feedback loop: The PhoneGap docs prompt the developers to give them feedback on every page, and they use that to improve the docs.

Many of the favorites are written by the engineers themselves, which likely keeps them more up to date and accurate (and proves that engineers can write!).

The least favorite documentation sets typically suffer from basic usability issues, like lack of search or deep links. When you're writing documentation, you need to remember that your developers won't benefit from it unless they can find it - searchability and linkability should be a top priority.

I've rounded up the documentation sets in the tables below, with links, short description (including how they were generated, if known), and a thumbnail. I've also embedded a slideshow of the screenshots. Feel free to comment with your own opinions on what makes for a great set of developer docs!

Screenshots

Rave Reviews

Ordered by popularity, these documentation sets received all positive reviews. Great work!

jQuery	One page for each method. Includes code examples and discussion. Manually written.
Django	One page for each topic, narrative tutorial-like structure. Generated with RST and Sphinx, More info here.
PHP	One page for each method, includes examples and comments. Generated with DocBook (XML), More info here.
CoffeeScript	One page developer's guide with interactive code examples in each section.
Twilio	One page for each topic, includes example requests and responses for REST API and example XML for XML API. Manually written by the engineers.
Mozilla Developer Center	One page for each topic, includes example code, encourages community edits. Uses wiki/social CMS system, MindTouch
PhoneGap	One page for each class, includes both short and long example code, and a popup feedback widget. Uses joDoc for automated generation.
Backbone.js	One page for each method (and example code), with framed (but still linkable) navigation. Manually written.
Yii	One page for each class, lots of internal linking, prominent search with autocomplete. Includes code samples and links to original source code. Generated with custom, open-source PHP tool.
NodeJS	One page for each topic, or can be viewed all on one single page. Includes code examples for each method. Generated using doctool and Markdown.
Play! Framework	Includes step-by-step tutorial and developer's guide (no reference).
Sencha ExtJS	One page for each class, highly linked, inline code examples, and search with auto-complete. Generated using JSDuck and Markdown.
SimpleGeo	Organized by topic with one page for each. Written in a narrative form and includes code examples. Generated using Django and templates, More info here.
Twitter	One page for each API endpoint ("resource"), with example request and responses in XML/ATOM/JSON. Partially generated from code, manually curated by engineers.
Android	Javadoc style, with ability to change language and API level, plus search with auto-complete. Incudes tutorial style articles as well. Generated from code using JavaDoc.

Mixed Reviews

These documentation sets had both positive and negative reviews. (What works for one developer doesn't always work for another).

Python	One page for each topic, with embedded references and code examples. Complaints: no search/comments. Generated using Sphinx and RST.
Facebook	A mix of reference style docs, articles, and github-hosted readmes. Includes search and (Facebook) comments. Complaints: too loosely organized.

Not-So-Great Reviews

These documentation sets had all negative reviews. (Well, they can always improve!)

Ruby	Javadoc style with framesets. Complaints: can't be searched or linked, no per-topic organization. Generated from code using RDoc.
Amazon Products API	Frameset docs, both tutorial and reference style. Complaints: takes many clicks to find the reference, provided sample code does not work.
Paypal	Includes articles and reference docs. Complaints: instructions are dumbed down, deprecated information isn't marked as such, there are too many places to find a piece of information, not enough example code.
OpenLayers	Wiki and reference. Complaints: No code examples, hard to find docs. Generated using NaturalDocs.
CouchDB	Wiki with articles by topic. Complaints: Hard to navigate. Uses the MoinMoin wiki engine.

What makes a good "developer experience"?

2011-04-28T21:18:00.000-07:00

(Short version: To help me answer this question, fill out this survey. Thanks!)

We are all quite familiar with the term "user experience" (UX) because as developers, we are typically spending our time developing products that we want people to use, and we want the UX to be positive so that they continue using them. However, we are now in the age of web APIs and developer platforms, and increasingly more of us are spending our time developing products for developers themselves to use.

Just like with user products, we want the "developer experience" (DX) to be positive so they continue developing on top of our service, and so they feel good relying on us to be part of their app's technology stack. When we talk about user experience, we focus on the usability of the user interface and the various user actions (like sign-in, search, share). A developer experience is very different, though, and when we talk about it, we should be focusing on the usability of the API and the developing-and-debugging experience. How does a developer first learn about your service? Where do they go when they need help? How easy is it for them to develop arbitrary apps on top of it? Can they use it successfully in their preferred environment? Those are the sort of questions that we need to ask to figure out what the developer experience is like.

Developer experience is important and non-trivial, but unfortunately, it's been nowhere near as discussed as user experience - a quick Google search yielded mostly this one article from UXMag. When I worked in developer relations at Google, we were basically tasked with designing the DX for our APIs and tools, and when I wrote up the Developer Support Handbook, I was attempting to document some of what I learnt from my years on the Maps and Wave APIs. That handbook only talks about some aspects of the experience - it doesn't talk about API usability at all - and it's only based on my own limited experience. I know that there is much more to be documented and discussed, and that there are many different types of developers and developer services out there, and just as with UX, there may not be just one set of DX principles that fits everything.

Why do I bring this up? A few weeks ago, I met with a mobile analytics company called Flurry to discuss their developer experience and how they can improve it to better support their current developers and encourage future developers. I gave them my own opinions, but I really would love to hear the opinions of more developers to give me a broader perspective. To find out what you guys think about what makes a positive developer experience, I've put together a short survey. Please fill it out if you have the time, or feel free to leave comments on this post. Thank you for your thoughts and for caring about what it means to have a good developer experience.

SF jQuery Conference 2011: My Learnings

2011-04-17T13:44:00.000-07:00

For the last 5 years, I've really only attended conferences that I was speaking at or somehow representing Google at, and I was always paid by Google to attend. This past weekend, I convinced myself to pay out of my own pocket to attend a conference for the first time, and it was completely worth it.

jQCon was a 2-day event in the Microsoft Mountain View campus with a wide range of well-known speakers, like Nicholas Zakas, Steve Souders, Paul Irish, and of course, John Resig, plus equally skilled but lesser known contributors to the world of jQuery and JavaScript programming. It was a great way to learn new techniques and tools for client-side web app development from the people that are doing it 24/7 for some of the biggest sites on the web.

I personally gravitated to the more mobile-oriented talks, as I've recently become interested in mobile webapp development (I finally use my phone here!) and have been using jQuery mobile for the next version of SpeakerMeter. I learnt a lot about how people are currently writing mobile webapps, and more importantly, I realized that this is a rapidly changing area, particularly as the line between desktop and mobile becomes increasingly blurry. I was hoping to find the "one true way" of making a HTML5 mobile webapp, but I've realized instead that I need to try the current ways out there (like PhoneGap + jQuery Mobile) and be ready for that to change.

I took notes throughout the talks on tips and resources, and am sharing them here both for my own reference and to give you an idea of what was discussed. I look forward to learning more at the next jQCon, whenever that may be. :)

Day 1:

jQuery Mobile (Todd Parker & Scott Jehl)

Many developers are using jQuery Mobile in combination with PhoneGap to deploy mobile-optimized webapps.
jQuery Mobile now supports more mobile browsers, including Kindle Webkit.
The jQuery Mobile team put a lot of work into making all the controls accessible.
The team is working on an improvement that will include better URLs (hash-less) for browsers that support it (HTML5 pushState).
The team made sure that it was easy for developers to make custom themes/colors, and they want more developers to take advantage of that.
Browse the jQuery Mobile gallery to see what other developers have done.
The M Project is an open source project to make it easier to make mobile webapps with jQuery mobile.
The team recommends specifically optimizing the UI for iPad/tablets and not just using the standard narrow mobile layout. They hope in the future that the framework can do more of that for developers.
CSS3 media queries can be used to change the UI for different device sizes.
jQuery Mobile can be used with grids frameworks (can be useful for tablet layout).

Mobile Performance (Steve Souders)

Its better to have your site be fast when users first experience it - study showed slow sites lost users (and it took a while for them to come back).
Use Blaze.io for seeing the mobile performance of your site (like webpagetest.org).
Use PCAP Web Performance Analyzer to analyze performance of websites (can be used locally).
Use JDRop with mobile bookmarklets to store performance data in the cloud for later analysis.
Use data URIs and localStorage for better mobile performance.

Progressive Enhancement 2.0 - Because the Web isn't Print (Nicholas Zakas)

Read: "Understanding Progressive Enhancement"
"The relationship between a web browser and a webpage is like a television and a TV show."
Examples of progressive enhancement in the real world: escalators and electric toothbrush.
Websites don't need to look exactly the same in every browser.
Don't try so hard to make old browsers do what new browsers can (consider effort versus value) - like rounded corners, drop shadows, and gradients.
Developers use multiple browsers, but most users only use one browser - they won't know if the experience is different.
Progressively enhance for browsers that support newer technology - Facebook chat is an example of a progressive enhancement.

Integrating Code Quality tools into your jQuery Development Workflow (Anton Kovalyov )

JSHint is the alternative to JSLint - does not enforce so many "crocklamations" by default.
Recommends using git precommit and postcommit hooks for running JSHint, to make sure all team members are using it. Break the build if it errors.
Many community-written addons for integrating JSHint with IDEs. He likes Sublime.
Read: Perfection Kills, A minute with Brendan

Prototyping and Unit Testing with Mockjax & mockJSON (Elijah Manor)

MockJAX is a jQuery plugin for simulating AJAX requests and responses.
MockJSON is a library for generating random JSON responses based on JSON templates. Works well with MockJAX.

Day 2:

Filling the HTML5 & CSS3 Gaps with Polyfills and Shims (Rey Bango)

Rey is both a Microsoft employee and a jQuery team member - MS is a big supporter of jQuery.
A "polyfill" mimics a standard/future API and makes it work in older browsers, whereas a "shim" provides an arbitrary API for achieving some functionality. "Polyfill" was named by Remy Sharp after the British term for spackling - it's like filling holes in old browser cracks.
When you are using a polyfill or shim, vet them carefully: see how many developers are working on them, how frequently they update them, etc.
Long list of polyfills and shims.

How jQuery is helping Pixar to make their movies (Philip Floetotto)

Pixar is a big Python user. For their project management system, they used Django for the backend and jQuery for the frontend.
They built their UI on top of the TableSorter plugin.

Presentational jQuery (Doug Neiner)

Be concious of when you use linked stylesheets vs. STYLE tags vs. inline style setting. Never use jQuery to set initial state. Reduce use of .css() as much as possible.
"Use selectors like you run errands" - try to do as much in one call as you can.
Experiment with easing (on different properties) for better animations.

Breakout Session: jQuery Mobile

Much discussion on using jQuery Mobile to build static sites that are deployed as WebViews inside of native apps.

Advantage of PhoneGap over Titanium is that it deploys to more mobile platforms.
Phone Gap Build lets you deploy mobile apps without needing to download anything.
Use something like JSON Template or Handlebars for client-side templating of the jQuery mobile headers and footers.
Use HT Track or Hyde to use Django templates locally and still output a static site.
Recommended reading: Responsive Web Design.

The Middle Way: Developing Hybrid Mobile Apps (Alex Kessinger)

Use localStorage to store data locally, and use LRU to stay under the 5MB size limit.
If using AppCache, inline everything (CSS, JS, HTML) so everything stays in sync in the cache.
For a better user experience, render *anything* to the user first (versus nothing), even fake DIVs.
For easier mobile debugging, try JSConsole.
OpenAppMkt is a marketplace specifically for mobile-optimized webapps.

Breakout Session: CouchDB + jQuery

Wrote a small JQuery & CouchDB app (with this view).

Creating mind-blowing UX - "Building great user experiences with the help of jQuery" (Darcy Clarke)

User experience is about emotions - you want your users to have positive emotions when using your site. Surprise is an emotion that can be either positive or negative.
Inspirational design agencies: F-I, Zurb, Blitz

Twenty Questions (With Myself)

2011-04-13T22:57:00.000-07:00

It's always fun to answer questions about yourself - remember those "About Me" books you would fill out as a kid? Well, I do, and I loved them, so when people ask me if I'm up for an interview, I always say yes. I recently answered a series of long & short questions for a Mexican development agency's internal newsletter, and since that newsletter isn't online, I figured I'd share them here instead. Enjoy!

Short Questions

Linux, Mac or Windows? Mac. I was raised in a Windows-using family - back when Macs weren’t Unix-based, but I recently converted to Mac and love it.
Twitter or blog? Both. I like the challenge of expressing something in 140 characteres, but I also like to write up my experiences and projects in much longer blog form.
iPhone or Android? Android...only because I got free Android phones from Google. I’d happily accept a free iPhone if it were to come my way. :)
Bread or tortilla? Neither. I’ve recently stopped eating grains of any sort (as they’re not actually that good for you). I miss tortilla more than bread though - growing up in Los Angeles, I was raised on quesadillas!
Wine or tequila? Wine. I save tequila-drinking for when I’m in Mexico and can drink the good stuff. :)
Day or night? Day. I’m afraid of the dark.
Warm weather or cold weather? Warm.
Sunny or rainy? Sunny! The rain is only fun if there’s a hot bath waiting for you at home.

What is your favorite…

Book: I can’t come up with just one. My favorite book genre is short stories, and Roald Dahl has some of the best stories out there.
Gadget: Kindle. It stays charged forever, and since I hate charging things, that makes it my favorite thing.
Videogame: Puzzle Pirates. I don’t play it anymore, but it’s the only game that I’ve come close to an addiction with.
Programming Language: JavaScript. It’s weird, but it works.
Browser: Chrome.

Tell us how did you get your first computer, and what age were you?

I don’t actually remember a time when we didn’t own a computer - since my parents were effectively computer scientists since the day I was born, we always had computers in the house. I first remember using DOS to play a “Garfield” and a “Dinosaurs” game, and then we upgraded to Windows 3.1.

Why did you choose to be a programmer?

I was always very in to computers as a kid- I loved using them to make posters and to browse the web. When I discovered programming - specifically web programming - I loved them even more. I made fun little games, I made a “cyberclub,” and I made websites for everything I did.

When it came time to deciding what to major in at college, I found it easy to pick Computer Science. I knew that no matter where my interests went, I could use my computer science skills to complement those interests, and I knew that I could always get a job with those skills.

As a programmer/developer, what is the thing that motivates you the most?

I like the ability to make something, and to easily share that something. If I wasn’t a programmer, I think I would be an artist of some sort, so that I could fulfill my need to create that way.

In which programming language do you feel the most comfortable on?

I am generally the most comfortable in “scripting languages,” and these days, I am the most familiar with JavaScript. I have always been attracted to scripting languages over compiled languages because I love the speed at which you can develop with them, and I find them generally more approachable.

On the server, I tend to use Python, but would love to try out using JavaScript there as well. I like the idea of getting to use the same language for both the frontend and the backend. The lines are blurring between them, so it makes sense for the language to be the same.

Do you have a hobby that is not related to technology?

Lately, I’ve gotten really into cooking. I’ve discovered that I get a similar creative rush from cooking as I do from coding. When I cook a meal, I get to enjoy the end result, I get to share it with whoever is around me, and I get to share with the world how I did it. When I code an app, I get to use the app, share it with other users, and open-source the code.

The main difference between cooking and coding: far fewer bug reports, and no long-term maintenance required!

How do you feel as a woman that works in a predominantly male environment?

I usually don’t think about it that much. I grew up around a lot of males - I had a brother with a lot of male friends, and I tended to make a lot of male friends myself. So, I didn’t find it that weird in college or work to be surrounded by males, and in fact, I somewhat preferred it.

(I wrote a much longer blog post about this here.)

Do you feel that you had to break the gender barrier or any stereotype because you are a woman in order to be considered a good programmer?

I have to admit, I don’t actually think I’m a great programmer. I think I’m a pretty good programmer, but not great. I am able to achieve beyond my core programming skills because of my ability to combine multiple skills, my desire to create, and my desire to share my knowledge with others.

I do often wish that I was a crazy-good programmer like my colleagues and peers, and I think to myself that I should take some classes or read some books to increase my skills...but then I think that I’m pretty happy with my diverse skillset.

I do sometimes feel as if I have to break stereotypes when I am giving talks to new audiences, as some people see a girl on stage and immediately assume she’s not going to talk technical. By the end of the talk, they know better. :)

What's your achievement that you feel the most proud of?

Looking over the past five years, I am most proud of my “teaching moments” - the times when I taught someone something new, and could see their knowledge grow as a result. I’m sure I had many virtual teaching moments with developers in forums, but I am most proud of the in-person moments with students in classes. There’s something very real and very gratifying about watching students grow from the first day of a class to the very end.

How do you do to keep your life under balance, I mean, keep learning, spend time with your family and friends, work hard, etc?

I don’t. My father is a workaholic, and he instilled a similar work ethic in me. When I am working, I’m putting all of myself into that, and I find it hard to justify making time for family and friends. I instead wait for them to force me to make time for them, and if they force me, well, I can’t say no.

I recently left my job, and I’m looking forward to finally putting friends and family first, at least for a few months. In the end, it’s the people that you remember more than the work anyway.

What projects do you have in mind for the near future?

Generally, I want to make apps that I would use, and if I’m lucky, a few other people would use as well. As I am currently obsessed with food and nutrition, I am experimenting in that area to see what apps might make it easier for me to eat healthily, to cook delicious meals, and to share nutrition information with others.

My basic strategy is this: Every day, when I encounter a situation that would be made better with an app, I write down the app idea. If I end up writing down an app idea multiple times, well, there’s a good chance I will make it.

What I Want in a Recipe Blogging Platform

2011-03-24T18:01:00.000-07:00

After spending years subsisting on the food from Google cafes and fast food restaurants, I finally got into cooking my own meals - and I can't believe I didn't discover the joys of cooking before. Right now, I'm mostly following other people's recipes from their personal blogs (which I've aggregated in this portal), but I've started to experiment with my own variations and concoctions as well. Both to share my newfound love of cooking and to document my experiments, I decided I should start my own food-centered blog.

Before I could start my blog though, I had to pick a blogging platform. Given the number of food bloggers out there, I assumed there'd be one platform that stood above the rest and was the go-to for food bloggers - but alas, there wasn't. Of the 100 blogs that I subscribe to, 52 use WordPress (either .com or .org version), 34 use Blogger, 1 uses Tumblr, 1 uses Posterous, and the rest are custom built sites. Of those platforms, the only one that offers any food-related functionality would be a WordPress.org installation with recipe-related plugins, but given that a Wordpress install involves money and technical knowledge, it's unlikely that many of these amateur recipe bloggers would be using that.

Instead, each of these bloggers start with a generic blogging platform and do their best to munge it into a recipe blogging platform. Some get quite far, some not at all, and many end up somewhere in the middle. It's not a good situation for recipe bloggers - they have to spend time re-inventing the wheel when they could be spending that time making delicious food - and it's not a good situation for their readers- they must struggle to make sense of the different user experience on each recipe blog.

This is why I think the web needs a recipe blogging platform. Based on my experience as both a consumer and producer of recipe blogs, here are the features that I would want:

Recipe Index: The traditional way to browse a blog is to scroll through the most recent 10 posts, click, scroll through next 10, and so on. This is a bad way to browse recipes. Instead, users want to see a recipe index, typically broken down by meal types, like this one (which includes a legend) or this one (which includes photos). The platform should auto-update the index every time an author posted a new recipe, and the categorization would be based on post tags.
Recipe Microformats: Google now shows some recipe results using "rich snippets", based on microformats or microdata that it finds in the HTML when it crawls. Many big sites have adopted these formats, since it's easy to apply across their database-generated recipe pages, but most amateur bloggers don't have the technical know-how or the time to work out the HTML each time. The platform should include a widget (like this Chrome extension) for inserting a recipe with structured information, and make sure it adheres to the SEO best practices.
Printable recipes: It seems like a simple thing, but across all the blogs, I see readers constantly asking for an easy way to print just the recipe in a post, so they can sit it next to their stove while they cook. The platform should stick a "print" button on each post that formats it cookbook-style.
Recommended Cookbooks/Gear: Some recipe bloggers include a page or link to an Amazon store with their favorite cookbooks or kitchen accessories. It's a great way for them to share what they themselves use, and to make a bit of extra revenue off their hobby. The platform should faciliate that.
E-Book Generation: Once a recipe blogger builds up a sizeable collection of recipes and readers, they might want to generate an e-book of their recipes, like the reader-created cookbooks from Mark's Daily Apple and they may want to monetize off that e-book. For whatever reason, people will pay for the same content that's available online for free when it's in an e-book form, presumably because it's easier to consume or appears more professional, and if people will pay, then recipe bloggers should be able to take advantage of that. The platform should have a way of generating e-books (or even real books) and making it easy to purchase them, perhaps through Lulu.
Food-related Themes: As we've learnt on the web, everyone likes to theme their web presence. When I searched on both Tumblr and Blogger, I found close to 0 food themes, and had to go for the "nature-y" themes instead. A recipe platform should be filled with themes that make your mouth water and fills you with dreams of bacon fairies.
Step-by-step Photos: Many recipe bloggers include photos that show each step of a recipe, in addition to the final result, like in this recipe. The platform should make it easy to include these in the formatted recipe wizard and it could provide a slideshow-like view of the recipe, similar to what's offered on instructables.com.

The platform could also do more in terms of community - making it easy for readers to find other blogs they might like, making it easy for people to comment on recipe posts with links to their own variation, and perhaps bringing in ratings & reviews for the recipes.

This platform could either be a brand new platform, or it could be a bundle of recipe-blogging tools that can complement existing blogging platforms. A brand new platform would have more flexibility in its functionality, but it would also need to re-create the functionality already mastered by existing platforms and it would need to offer migration tools, whereas a set of complementary tools could start being used today by existing and new recipe bloggers. The best thing could be a hybrid of both options.

Since recipe bloggers at least start off as hobbyists (and many remain that way), such a platform or set of tools should start off as free or affordable, and offer premium features (like the e-book generation) for the more invested bloggers.

I'm a web developer myself, so I could go ahead and make this platform tomorrow, but I'm not sure it's what I want to spend all my time on and I think it deserves to be worked on by a fully invested team for a good amount of time. You can't just throw a blogging platform out into the world, abandon it, and expect it to flourish. A blogging platform is all about the users, and when you create a webapp that is user-powered, you need to spend time listening to your users, improving it to better meet their needs, and growing the user base.

So why have I written this post? I'm hoping that either 1) someone is already working on this and will take my feedback into account, 2) someone will be inspired to make this their baby, 3) someone will tell me this already exists. Now, I'm going to sit back and wait for one of those three to happen...and maybe cook some recipes in the meantime. :)

The Developer Support Handbook (aka How I Did My Job)

2011-03-23T05:40:00.000-07:00

When I started at Google, I was among the first handful of people in the Developer Relations team (then called "Developer Operations"). We were new to this area at Google, but I'd say that the whole tech world was fairly new to it as well. Web APIs were just becoming a big thing, and web companies were just learning about how to support and grow the diverse community of developers using their APIs. We didn't have much of a precedent about how to do our job, so we made stuff up along the way and iterated on whatever worked. There is still experimentation going on, but much of how Google works with developers today is based on learnings from those early times (where "early" equals a mere 4 years ago - the web world moves at a rather fast pace).

As I once said on Twitter, my personal policy is to "document the f*k out of everything." I like to document things - particularly processes - both because I am forgetful and like to have a reference to remind myself how to do things, and because I am a huge believer in sharing knowledge. When you share your knowledge with the world, you potentially make someone else's life easier and you also make sure that you're not the single point-of-failure for that knowledge.

So, a few years ago, I started documenting (nearly) everything that I had learnt in doing developer support at Google, figuring that both future colleagues and even non-Googlers might be interested in the learnings. As it turns out, there was a lot in my head that I wanted to get onto paper, and the documentation turned into a multi-chapter, multi-section affair, covering topics like documentation, forum support, issue tracking, communication, and nurturing top developers. You can read it all online at developer-support-handbook.org, and if you want, you can even check out its RST source and build it using Sphinx.

I am not particularly proud of the handbook as a writing piece - I had never written anything so long before, and I found it quite difficult to keep a consistent voice and format, and to present the information succinctly. But, I do think the handbook does a good job of showing what "developer support" really entails, and gives you an idea for the kind of debates you'd face in such a role. If you only read one part of it, please read the introduction, as it outlines the guiding principles behind the recommendations in the handbook, and behind the way I did my job. (Hint: The #1 principle is to care about your developers. :)

I have since moved on from developer relations at Google, but as a developer myself, I still care deeply about how companies treat their developers and I hope to see more people talking about what it means to have well-designed APIs and to support thriving developer ecosystems. For example, Christian Heilmann put together the fantastic Developer Evangelist handbook during his time at Yahoo!, and it covers how to write great code samples and give great talks. I hope to see more writing, talks, and even conferences happening in this area in the future. Developer Relations is a tricky mix of communication and technology, and it deserves a closer look.

Sightseeing in Sydney: What to See, Eat, Drink, and Yell

2011-03-22T17:51:00.001-07:00

When I used to live in Sydney (way back 1 month ago), I often gave sightseeing tips to visiting Googlers, and I figured I'd share some of them here:

Visit the aquarium: There are lots of weird Aussie animals, like dugongs, sidenecked turtles, and platypi. It's a good option for a rainy day.
Go "gold class" at the movie theater: It's a pricier ticket to sit in a special theater with a small number of plush throne-like seats and waiters that bring you drinks and snacks. It makes you feel damn special.
Take walks: You must do the classic Bondi to Coogee walk (watch out for the cemetary on the way, & skim the waters for dolphins). But there are tons more cool walks to do around the rather long and windy coast of Sydney. I recommend taking the ferry up to Watson's Bay and following this path. It takes you past the suicide cliff, then winds through an eerie forest with huge spiders, and ends up at a cute little beach.
Taste wine: I didn't like wine before coming to Australia, but after being properly introduced to it by the Aussies, I now love it. You should try wines in the restaurants, but you should also tour wineries. From Sydney, it is a short trip to Hunter Valley for some pretty good wines. I took this van tour with a few friends.
Eat at the Sydney fish market: Go in the morning or at lunch, order some oysters and raw fish, and eat it outside. Warning: you must defend your food against the seagulls. They are fierce.
Try traditional "Aussie" foods: eat something made out of kangaroo (like a burger, which is fairly common), eat wedges with sour cream & sweet chili sauce (at any pub), tim-tams (if you like sweets), oysters, and savory pies with mash and peas (most famously served at Harry's Cafe de Wheels).

Oh, and my final tip? When you see a drunk Aussie walking down the street, yell "Aussie, Aussie, Aussie" at him (pronounced "Ozzie, ozzie, ozzie"). If he's a proper Aussie, he'll respond back with a raucous "Oy, oy, oy." Works nearly every time, and it always cracks me up.

StartupBus: What I Learnt & What I Loved

2011-03-22T08:21:00.000-07:00

I've participated & organized in many different programming events over the years, but nothing as crazy as StartupBus, an idea dreamed up by Aussie Elias Bizannes (who I met at StartupCamp, a similar event). Across the country on March 8th, a mix of developers, designers, & business dev'ers boarded buses headed to Austin, Texas. We pitched ideas on the morning of the first day, formed teams over lunch, and spent the next two days coming up with a prototype. When we arrived in Austin, just in time for the start of SXSW interactive, selected teams got to pitch their startups at the semi-finals (our team SpeakerMeter made it there!) and the finals (but not there), hoping to interest VCs in the potential success of their startups.

It was an incredible learning experience to be a part of StartupBus, and a great way to enjoy a different side of SXSW.

What I Learnt:

It's good to go slow.
When you say "make a startup in 48 hours", the typical reaction is "wow, that's not much time." But actually, we're really only coding the prototype, and most programming events these days are shorter than that. When you're not worried about fully working functionality or doing things "the right way", you can actually build quite a lot of functionality in that amount of time.

So, in fact, I felt like we were going at a much more relaxed pace on the StartupBus than at typical hackathons, and I appreciated that pace. It gave us time to actually think about what we were doing, time to debate the business plan, time to have long discussions with Xero's designer Philip about the idea, and time to completely revise the interface after that discussion. It also gave us time to take more leisurely meals, where we could get to know eachother more. (Remember: we were strangers, and now we were people spending 3 days squished next to eachother on a bus. Bonding's a good thing.)
It is difficult to make webapps without a good internet connection - for more reasons than you'd think.
I knew that we'd be driving through uninhabited desert for most of the trip with questionable WIFI, so I tried not to propose a startups that would be too reliant on internet resources - but that's hard to do, there are few web startups these day that don't build on existing data and services. Our startup brought in Twitter and SXSW data, so we had to test that functionality at high connectivity times.

But I realized that I use the internet for much more than just connecting code to external websites when I'm building a webapp - I use it extensively for documentation and for problem-solving. Normally, a framework question can be answered in just a few minutes with a Google search, but with flaky wifi, that seemingly quick process can take minutes on end. If I was doing this next year, I'd download all possible framework documentation to disk, and maybe also download all of stackoverflow. :)
Market research - even the most unscientific & untargeted - can be damn useful.

When we stopped by in Santa Monica, the conductors gave us a challenge: walk around the streets and record video of at least three market research interviews with strangers. This admittedly freaked me out; I am quite shy by nature and hate to impose myself on other people - approaching strangers to ask them questions is the epitome of what I am afraid of doing. But, it's a part of the startup experience, so I grabbed my more balls-y teammate and hit the streets.

We had multiple folks turn our requests for an interview done, but we actually had just as many people stop and chat to us for several minutes. They were all university students (I guess they're all happy for an excuse to postpone doing assignments), so they were not a diverse market segment or even our target market segment, but they still gave us great insight into the design and intent of our startup. In fact, if I'd really listened closely to them, I might have pivoted the startup into an entirely university-oriented one - but I stuck with the original goal of solving my own problem, not theirs.

Now that I see the utility of just a bit of market research, I'm working on a survey to send out to our target market, and we're going to use the results of that survey to figure out our next steps. (Yes, I'm still working on our startup idea, as one of my numerous side projects.)

There is a difference between making a webapp and making a startup.
I love making webapps - it's so easy these days to create something out of nothing (well, where nothing = existing libraries, frameworks, and APIs), and it's easy to share your creation with the world. But a webapp alone is not a startup. A startup is a team of people trying to make a product (often a webapp) that will gain users & be profitable in some way - and those last two parts are not trivial. So we didn't just spend time on the bus coding, we also spent time marketing (tweeting & blogging), doing the market research, coming up with a business plan, and drafting our pitch.

In retrospect, we probably could have done more of the startup stuff and less of the coding, and been more successful in terms of our visibility. It's easy for anyone to make a webapp, but it's hard for webapps to gain users that they can then be profitable from, and StartupBus is a great opportunity for potentially useful webapps to gain press and users as a result.

I went on StartupBus partially to figure out if I want to enter the startup world, or if I am content to stay in the webapp world. I still haven't quite figured that out, but at least I'm very aware that there is a difference between them.

What I Loved:

I am now a part of the StartupBus community - and hopefully always will be.
The StartupBus founder, Elias, always likes to say that StartupBus is not so much about the actual startups made, but about the community that forms as result. The 3 days on the bus and 5 days at SXSW are an excuse for like-minded hackers & entepreneurs to get to know eachother over a common experience. At SXSW, even if I didn't technically know someone, I knew I could approach them if they were wearing their StartupBus badge. Now, going forward, we feel comfortable approaching each other for business advice, for a place to crash during other tech events, for co-founder possibilities, and of course, just for hanging out.

Regardless of what I decide about the startup world, it's great to be a part of this incredibly passionate & intelligent community.

Similarity Web 2.0: Remaking My First Mashup, 5 Years Later

2011-03-20T09:55:00.000-07:00

One fateful summer five years ago, I accidentally stumbled upon the world of Web APIs - starting with the Amazon E-Commerce API. I was supposed to be working on a research project, but I couldn't resist the potential of the API. Amazon's catalog & functionality at my fingertips? And I could do whatever I wanted with it? I just had to play with it.

So I made my very first mashup: the Similarity Web. It's an app that uses the Amazon ItemLookup & SimilarityLookup API calls to let you find a book & visualize the web of books similar to it. It was a fun little app, and it even made me some money in referrals - especially after marketing guru Seth Godin linked to the "Purple Cow" web in his blog. Unfortunately, as it happens, Amazon deprecated the version of the ECS API that I was using, and the app stopped working. It's been on my to-do list for the last few years to revive it.

Well, thanks to my former employer, I found an excuse to do just that. Google is holding a contest for free I/O tickets, and a few Fridays ago, they held the App Engine contest. After I made it through Round 1 (deploying a Fibonacci JSON-RPC service), I was presented with the Round II challenge: make an app that uses one of their more advanced APIs - blobstore, task queue, pipeline, mapper. I knew that I could use task queues in a couple different ways in Similarity Web, so at 5pm on that Friday, I started remaking it from scratch and at noon on Saturday, I submitted the fully functional remake.

Much has changed in web development in the last 5 years - both in what I personally use and what the world uses - so I thought it'd be interesting to compare the technology stack for each version of the Similarity Web.

Hosting	LiquidWeb (shared hosting)	App Engine
Backend Language	PHP	Python
Amazon API	Raw HTTP calls	Bottlenose wrapper library
Data Storage	Filesystem	Non-relational Datastore
Data Format	XML	JSON
Frontend Language	Pure JS	JS + jQuery
Visualization	Flash (AS2)	JavaScript InfoVis Toolkit

The general trend? The app is built on more scalable infrastructure, more web-friendly formats and standards, and more pre-existing libraries; it was faster to develop and works in more environments than before. Web development is getting better and better. Oh, and yes, I did get a Google I/O ticket! :)

QuizCards: Learning While You Wait

2011-02-28T21:28:00.000-08:00

As a computer user and programmer, I find myself with many "waiting" moments - seconds at a time where I am waiting for a page to load, waiting for code to compile, waiting for an app to deploy. I usually find myself using those waiting moments to read through the latest tweets in my Twitter app - but I thought to myself the other day that there must be a better use of that time. What can I do in a few seconds that might actually benefit me, instead of filling my head with mostly noise? (Not to hate on Twitter - but I think you know what I mean.) Well, I can learn something - I can learn something that only takes a few seconds - like a word or a fact.

That idea is what led me to create the QuizCards Chrome extensions - interactive flash cards that are only a click away in your browser. When you install the extension, it sticks an icon in your Chrome browser bar (next to the wrench), and when you click that icon, a flash card pops up.

Depending on your settings, you can answer it via multiple-choice (easiest), type-in with autocomplete, or type-in with no autocomplete (hardest).

Once you answer it, it tells you if you were right or wrong, and it keeps track of your statistics for that word. Behind the scenes, it uses the Leitner card learning system for figuring out which cards to show you next, so that it quizzes you more on the cards you know the least.

There are many flash cards websites out there, but what I like about my extensions is their convenience, and their omnipresence. I don't have to remember to type in a URL, I just have to click the icon when I have a few extra moments. I feel a lot better now using my time to increase my linguistic and geographic knowledge than to increase my knowledge of tweets. And now when I do read tweets, I can spend more time to find the gems and respond to the ones that interest me.

As for the flash cards topics: I started with World Capitals, since I'm frequently called out for not knowing world geography (despite having worked on Maps for 3 years), and then made German vocab, Spanish vocab, and U.S. Capitals versions. I now have an easy way of generating flash cards for any topic, provided I can easily get the question/answer data, so let me know if there's a particular topic that you'd like to learn, QuizCards-style. (If you're technical, you can also check out the code and read the README for instructions on making your own).

You can see all of them at QuizCards.info, and install whichever interests you. Give it a go! :)

Translation Telephone: Having Fun with Language

2011-02-15T09:43:00.000-08:00

When I was a kid, I remember we often played this game we called "Telephone" where you'd sit in a circle, whisper a sentence into someone's ear, and they would try to understand what you said and whisper it to the next person. At the end, the original person would reveal both the original sentence and the final sentence. It was funny because the sentence would often mutate and take on new meanings at different points in the circle, depending on the interpretation skills of the listeners.

Well, since that game was fun, but I am sadly no longer surrounded by willing circles of friends, I wrote an online variation called "Translation Telephone". Instead of using the interpretation skills of a circle friends, it uses the translation skills of Google Translate. After you give it a starting phrase, it translates that from one random language to another, and finally translates it back into the original language. The phrase often changes meaning into something that makes no sense or sometimes makes so much sense that it seems like a philosopher poet is underlying the system.

For example, here ae some of my favorite transformations by Translation Telephone:

It has a new take on inspirational quotes:
"Life is like a box of chocolates. You will never know what you are going to get." →
"Life is like a box of chocolates. You know how it is."
It has its own opinion on political matters:
"Capitalism: God's way of determining who is smart and who is poor." →
Capitalism: the path of God, what a smart decision that was wrong.
It has as many interpretations of Shakespeare as a college English class:
"To be. Or not to be. That is the question." →
"Challenges of life and death"
"Me. There is no question."
"World War II, EAR ICQ, or even worse, Sam songs"

As you can see, the funniest results are when you enter an inspirational phrase or quote that purports an opinion, as it has its way of inversing or changing the meaning in surprising ways.

Just like in our real-life game of Telephone, there are often certain mutation points in the chain where the meaning changes more, and those points tend to be where the languages are the most different from eachother, or where they introduce words with ambiguous meanings. To make it easier for people to see where those mutations happen, I added an option to view each step translated back to the original language.

For example, I was surprised to see "You are my love" transform into "I have children", but when I viewed the translations at each step, I realized it translated Portuguese "Tenho uma querida" (I have a darling) into "Ich habe ein Baby!" (I have a baby), and "baby" has the same ambiguous meaning in German as English. Be careful who you call your baby!

I'm not the only one to come up with this idea - there's a "Bad Translator" site which translates from 10 to 50 languages, and there's also someone who did something similar with the same name on their personal blog a few years ago. I have tried to add more to this idea, however, by making every translation shareable and by letting users browse the recent and popular translations. At the request of an eager user, I've also created a Chrome extension that gives you a right click menu for translating highlighted text.

To quote a review of the extension, "Translation Telephone was already a wonderful way to waste time. Now I can do it without thinking. You've destroyed any hope I ever had of being productive in my lifetime. Thank you!"

I hope you also find Translation Telephone to be a wonderful way to waste time - and maybe a little educational too. :)

Goodbye, Google; Hello, World!

2011-02-11T14:55:00.000-08:00

Just over four years ago, I started working in one of the coolest departments at one of the best companies on the web: Google Developer Relations. My job was to help developers be successful with our APIs, whatever it took. Sometimes that meant "grunt work" like spending hours trying to figure out why our API was broken in IE6, and sometimes that meant more glamorous things like traveling to exotic countries to talk about our API. Either way, it was time well spent when I could see the end result: developers doing awesome things with Google APIs.

It was the first and only job I've ever had, and it was the perfect job for me. I got to do so many things that I love: make things (mashups), teach people (developers) and learn things (web technology). But, as you've probably figured out from the past tense, it is no longer my job.

I could come up with many explanations for why I decided to leave Google, but it boils down to this: I'm ready for the next adventure.

What About…?

I don't want you to worry that I've left anything at Google in an abandoned state, so here's a rundown of what I've worked on and who's on it now:

Maps API: Unbeknownst to the developers that still email me every day (even today!), I actually stopped working on the Maps API a year and a half ago. The Maps API team is now quite large and includes multiple support engineers that you'll see around the forums, like the very talented Chris and Luke.
Wave API: Since Google decided not to continue the Wave project, the Wave APIs are effectively deprecated. Most of Wave is now open-source and is moving into the skilful hands of the Apache community.
Shared Spaces: Along with several other former Wave team members, I helped launch this in Labs a few months ago. My colleagues will continue working on the ideas in that project and hopefully integrating the collaborative platform into other Google products.
Google Sydney Developer Relations: When I came to Google Sydney, I was the only person working in Developer Relations here, and we didn't have much of a connection to the local developer scene. I decided to fix that by running events and meeting the developers here (who, as it turns out, are incredibly smart and sincere). There's now a whole Developer Relations crew in the office - Andrew on Go, Brett on Blogger, Nick on App Engine, Chris & Luke on Maps - and I know they'll do a great job continuing to connect with the local developers.

What's Next…?

I'm going nowhere in particular, or put another way, I'm going everywhere. I want to pursue the ideas in my head, I want to travel to the places I've never been, I want to see the people I haven't seen in years, I want to learn new things, I want to see where life takes me.

I know, I know, that's vague - but on purpose. I want to make no plans, so that I can explore all the possibilities and see what makes me the happiest. Oh, and one of those possibilities includes becoming a hippie, which totally works into the "no plans" plan.

I do have to somewhat decide on my location, since it appears that governments aren't into the "live wherever the hell you want with no paperwork or employment" idea. So for now, I will move back to the states, and likely live in San Francisco for a bit. (Yes, I'm a geek and I mapped where my friends live - based on marker density, San Francisco is the optimal place to live for maximum friend visitation.)

Thank You

There were many things I loved about my job, but the thing I loved the best was the developers. I met so many different developers doing so many different things from so many different countries. To all the developers out there, thank you for constantly inspiring and impressing me, and thank you for making my four years on this job such a fulfilling experience.

And I'm Off!

To quote the greatest comic strip of all time, "It's a magical world, Hobbes, ol' buddy… Let's go exploring!"

Actually Healthy Alternatives to Carb Comforts

2011-01-27T04:14:00.000-08:00

According to the latest research (and a lot of the books I've been reading, like "The Primal Blueprint" and "Why We Get Fat"), the most likely culprit for obesity and related health problems is carbohydrates.

Unfortunately for those of us trying to get healthy, some of the foods that are highest in carbohydrates are also the foods that are staples of the western diet - bread, rice, and potatoes. If you're anything like me, you grew up on that stuff and can't imagine a life without them. But listen, here's the thing: most of the time that you're eating them, they're just an accessory - it's a holding device for our toppings, it's a convenient scooping device for our tips, it's an absorbing texture for our sauces. It doesn't make sense to consume excessive, unhealthy carbohydrates if they're just there as an accessory.

Thankfully, clever people out there have figured out *actually* healthy alternatives for those accessories, like "cauliflower rice" and "zucchini bread." You can find the recipes for many of the alternatives online, but I discovered them through my new favorite cookbook, Jane Kennedy's "OMG! I can eat that?" I'm making my way through the cookbook now, and thought I would share some of what I've tried so far. Since not all of you will get the cookbook, I've linked each alternative to a similar recipe online. Try them out - you might not like all of them, but atleast you'll be aware that there are less carbalicious options out there for your favorite foods.

If you like...	Then try:
Rice	Cauliflower Rice

	I whip up a batch whenever I've made curry, like the beef/pumpkin one shown here, or my new favorite, Coconut Shrimp Curry.
Mashed Potatoes	Cauliflower Mash

	I like to eat it with pan-fried steak and asparagus; it's a great texture complement.
Potato Chips	Zucchini Chips

	I make this as an afternoon snack, and dip them in homemade aioli on the side.
Pizza Crust	Zucchini Pizza Crust

	We piled our "crusts" high with yummy veggie and meat toppings.
Pita Bread	Zucchini Pita

	I used the same pizza crust recipe to make pitas for some Lamb Souvlaki.

New for Google Shared Spaces: Improved Interface, Inbox, Chrome Extension, & Embedding

2011-01-19T20:28:00.000-08:00

Since launching Google Shared Spaces in Labs less than a month ago, we've been making fast iterations on the app - pushing an average of one new release each day.

We purposefully launched Shared Spaces with the bare minimum set of features, so that we could listen to users and developers about what features they most want and need in order to benefit from this app, then implement the most desired features.

Here's a rundown of the improvements we've made - try them out and let us know what you think!

Better, Resizeable Interface

We worked with Cameron Adams, the user interface designer behind Google Wave and cool projects like VisibleTweets, to come up with a sleeker interface for Shared Spaces. We also drew a lot of inspiration from EtherPad, a similar tool for real-time textual collaboration.

Besides subtle style changes, the new interface moves the chat to the right-hand side and adds a full screen button, so users can work on wider width gadgets like the popular ConceptDraw MindWave mind mapping tool.

(For those of you who hadn't seen it, here's a screenshot of the old interface.)

Inbox

We launched with no way of keeping track of your spaces, figuring users could bookmark the ones they were interested in, a la Etherpad. But users (rightly) didn't want to have to worry about keeping track of their space URLs, they wanted to have a list of all their spaces in one place.

At the same time as the interface redesign, we added a universal header with your login information and a "My Spaces" link. That takes you to a list of your most recently modified spaces, with the option to view all of them and the ability to hide any of them. We know it's not a full-featured inbox like GMail's, but we think it's a sufficient way for users to manage their spaces while we build out other features.

Chrome Extension

Personally, I love to use Chrome extensions as a way to keep tabs on what's happening in my favorite communication tools without actually having to open them in a new window - Twitter, GMail, Wave, etc.

So, we created a Chrome extension that both gives you a mini view of the gallery for quick space creation and a list of your most recently modified spaces. When someone modifies a space that you're on, the extension badge changes to let you know.

Embedding

We live in a web where everyone, from developers to users, want to be able to mash their favorite products together. Our users asked us for the ability to embed their spaces in their webpages, on their Google Sites, and in iGoogle.

For the typical case of embedding on a webpage, we launched an embed wizard that lets you tick some options and then generate a JavaScript code snippet (similar to Google Web Elements). For the Google properties (where JavaScript isn't allowed, but gadgets are), we automatically generate a gadget for each space, and we give users the URL of the gadget that they can then insert in their site or dashboard. For either method, users can click "Embed" in the space to get started.

Why I Love(d) Wave

2010-12-29T12:04:00.000-08:00

Note: I originally wrote this post in August, but decided not to publish it until now. I've left the text as it was then.

As recently announced on the Google blog, Google has decided to discontinue Wave as a standalone project. As many of you know, I worked on Wave for the last year, as an advocate and support engineer for the APIs, and well, as you can imagine, I'm quite disappointed right now.

I know that one of our failings in growing Wave usership was the inability to properly articulate what Wave is good for, and I think part of the reason is that Wave can't be simply compared to any existing service. Wave is a flexible and generic platform, one that can be used for groups discussion, for diary entries, for event commentary, for surveys. Of course, there are existing solutions for doing each of those things - but there is not one solution that does all of them. The thing I loved about Wave is that I could start a wave about a topic, and that wave could evolve from a survey to a discussion to a photo album (like when I asked folks what color I should dye my hair next), or be a combination of all three at once. I didn't have to know at the beginning what it would be, I didn't have to carefully weigh all the different options, I could just start a wave and see what it became. There are of course reasons for using specialized tools, like when you absolutely must have pristine formatting in a Word Document, but when you're collaborating with your group of colleagues or community of developers, I've found it's better 99% of the time to have the flexibility of Wave than the specialized features of 10 different services at once. That's why I will find it hard to stop using Wave (and I hope I don't have to), because I would have to replace it with myriad different tools.

Because Wave is this flexible, we realized from the beginning that it should also be extendible, so that users could customize Wave for their own particular needs, and combine its conversational features with their own processes. Sure, you can do event planning with just text, but throw in a date picker gadget, RSVP gadgets and maps, and you've made planning that much more compelling. You can write your blog post drafts with just the native features of Wave, but after you throw in an approval gadget and blog post publishing robot, you've got a full blog post workflow in Wave, one that can be easily shared with your colleagues.

On the Wave engineering team, we had started to build extensions to streamline our own internal processes. For example, we have a system on the team where a different group of people are on-call each week, and it is their job to respond to the pages and alerts about server issues, and escalate them to other folks if they can't handle them. To supplement this system, we would create an on-call wave each week, and the on-call engineers could paste the alerts into that wave, ask questions about them, and anyone following the wave could discuss the alerts with them. To enhance this system, one of my colleagues wrote a robot that 1) created the new on-call wave each week on a chron job, adding the relevant people based on calendar entries, 2) added links to all the current server admin pages, and 3) pulled the alerts directly into the wave. So, now, we have what amounts to a semi-automated system, where a piece of software does what it's good at (bringing in structured data), and humans do what they're good at (conversing on top of that data). It really shows off the power of Wave to combine structure plus free-form conversation; to combine data plus humans.

In Wave developer relations, we built multiple extensions to enhance our interactions with external developers. For example, we have a gallery of third-party extensions in Wave, and since we wanted that gallery to contain only user-friendly extensions, we created an App Engine app for developers to submit their extensions to the gallery. The app worked okay for storing the structured data about the pending submissions, but it was not conducive to having lengthy discussions about various aspects of an extension. As soon as I got the chance, I moved the process to Wave. Now, developers create a new submission wave, a robot fills it in with questions and fields, they answer the questions and click a button to share it with the review team. We add our own comments, and then click a button that physically puts it into the gallery. With the new wave-based process, we can get into inline discussions about their answers, I can start up private replies with my colleagues to ask for their unfiltered opinion, and we can attach images to show what we see or would like to see in the UI. We ended up with much better extensions, because we were able to have such fast and meaningful conversations -- and we didn't lose any of the structured data along the way.

My job is all about communication and collaboration, and that is what Wave excels in. The more I used Wave, the more I saw how Wave could make my job better, and the more I fell in love with the power and potential of Wave. I hope that the ideas of Wave keep going, whether through other Google products or the ever-growing Wave open-source community, because I don't want to live in a world without them.

Triaging Issues: The Wave-y Way

2010-12-28T16:58:00.001-08:00

Note: This blog post was originally written to be posted on the Google Wave blog, but did not make it out before the cancellation of Wave. I am posting it here in case it is useful to Wave open-source developers in the future.

In developer relations, one of our core roles is to respond to the bugs and feature requests for our APIs, and we do it both because hearing what developers want helps us shape our APIs, and because understanding the bugs that developers encounter is one of the best ways to deeply understand an API. As a general rule, we try to respond to all new issues within a week of their filing, and we usually accomplish this by holding a weekly triage meeting with colleagues to review new issues. Back when I worked on the Maps APIs, we were all in the same office, so we'd just crowd around a table with our laptops and mash through the bugs. But, now, on the Wave APIs team, my colleagues are spread entirely across the world, with me in Australia and them in both coasts of the United States. So, we needed a new way to triage, and being on the Wave team, we went the obvious route: use Wave!

For our first weekly meeting, we simply met in a wave and pasted the untriaged issues ("Status-New") from our Google code issue tracker into the wave. Then we'd look at the issues and reply beneath the ones we were checking out to lay dibs on them, so we worked on whatever bugs were most up our technical alleys. While we were researching a particular bug and had questions about it, we could start an inline conversation beneath the bug, so in the end, we could both work in parallel and in collaboration. This way, we were able to both triage many bugs and feel confident in our triaging, since we could bounce ideas off colleagues easily during the process.

After the first meeting, I started thinking that I could probably whip something together with our APIs that would streamline the triage process even more, and maybe make it possible for other teams to follow the same process. Around the same time, the project hosting team announced an Issue Tracker data API - perfect timing!

So, with the powers of the Wave Robots API and Issue Tracker API Python client libraries combined, I wrote the Bug Triagey robot. When you add Triagey to a wave, the bot titles the wave with the current date and inserts a configuration gadget. That gadget lets you pick a triage template, or create a new one. In a template, you just need to specify the Google code project, the Status label, and optionally, a label to sort by. For example, my Wave APIs template specifies "google-wave-resources", "New", and "ApiType", as we try to categorize our issues by sub-APIs, and each of us specialize in different APIs.

After you're happy with the template, the bot loads the sorted issues into the wave, and puts dibs buttons under each one, so you can indicate if you're "Looking at" or if you've "Responded to" an issue. After clicking a button, Triagey changes the button to show your username, and after clicking the "respond" button, Triagey strikes the issue out. That way, it's easy for you to review the issues in the wave and immediately see which issues haven't been triaged yet, and who's working on what. And just like before, you can start inline conversations to discuss the bugs you're working on.

Triagey is one of my favorite examples of how you can use Wave to combine automation and conversation to make collaboration easier and more efficient, and of how you can hold multiple structured conversations in a wave. To try it out yourself, install it from this wave. To modify it for your own use (like to triage other items) or to see how it was built, grab the code from the samples gallery.

Using App Engine to Turn Emails into waves

2010-12-28T16:01:00.000-08:00

When I first discovered Google Wave and started working on its APIs, I realized that Wave had the potential to be a universal inbox one day, using the robots API to collect notifications from all the different inboxes and services that I use. I've since realized that many legacy services don't provide notification APIs but many of them do provide a common integration point - email - letting you specify an email address, and then sending new information to that address. Well, as it turns out, it's very easy to create an app in App Engine that can receive email at particular addresses, and then process that email. Using this technique, I can realize my dream of a universal inbox, by simply forwarding all my services to an AppEngine-powered email address, and appending the email content to a wave in my account.

So, I created the Mail Digester bot to do just that, and open-sourced the code for all of you to base your own mail-receiving robots on. The app starts with a handler for all inbound emails, so it receives emails sent to any [address]@maildigester-bot.appspot.com. It then creates or finds the digest wave for the particular address, and appends a blip with the content of the email, converting any HTML emails to text. For example, if I send an email to "myemailupdates@maildigester-bot.appspot.com", and the app can't find any digest associated with "myemailupdates", it will create a new digest wave and add my wave address. The next time that I send an email to that address, it will find the wave in the datastore, and append a blip to it with the converted email. I wrote it this way so that I could easily create different addresses for different purposes and subscribe to a few different waves.

Once I created the robot, I set to work seeing how many services I could bring into Wave via email notifications. First, I set an address as the issue notification email for the google-wave-resources Google code project, so I could have a digest wave for all the issue updates. Next, I added another address as a member of the Google-Wave-API google group, so I could have another digest wave for new group messages. Finally, I set another address as a Gmail forwarding address, piping all my inboxed emails into a third digest wave. I still need to pop out to Gmail or other services when I need to reply, but in fact, now that I do all my team and community collaboration inside Wave, I find I only need to respond once a day or so.

Using the same principle of using a robot to respond to emails, several of my colleagues have built robots to respond to specific types of notifications. For example, one Wave engineer wrote an on-call robot that parses incoming pages from email and appends them to our weekly on-call wave, so that it's easy for us to discuss the contents of the page. Another food-loving colleague wrote a bot that turns the daily menus into waves, adding images of the food and rating widgets.

Though it at first feels odd to be using email as an integral part of a wave robot, responding to email is actually a great way to integrate Wave with existing services in your organization and even add a collaboration layer on top of them.

Issue Tracking in Wave

2010-12-28T15:52:00.000-08:00

Like most folks in the software development field, we spend a fair bit of our time on the Google Wave team tracking bugs and feature requests. At Google, we use an internal tool for tracking issues, and that tool lets us set some initial info about the bug, choose its status from a set of options, set its priority level, and assign it to a colleague. From there on out, we can append comments to the issue to discuss it further. The tool works well as a way of tracking the status of bugs across many projects and people, but it doesn't work as well for working through bugs quickly, or for having more complex conversations on requests. On the other hand, Google Wave, works really well for collaborative debugging, since you can easily paste code in, attach files, and comment on each other's code, and of course, it works great have for having conversations that diverge into multiple threads. I really wanted a way to have the best of both worlds: the structured input of our tool, plus the collaborative conversations of a wave. So, we worked with a team to create the Issue Tracky extension to do just that.

When you install Issue Tracky, you'll see both a new item in your "New Wave" drop down and an icon on your toolbar. You can use the former to create a new issue report from scratch, or you can select text in a wave and click the toolbar icon to turn it into an issue. In either case, a robot will fill the wave in with a title and info gadget, where you can pick the issue type, priority level, and assign the issue to a colleague. From there, you can add a description using all the Wave editing tools you're used to, attaching files or pasting formatted code, and then add your colleagues to the wave to discuss the issue.

The robot will automatically tag the wave based on the information in the gadget, so that you can create saved searches for all of the bugs assigned to you (e.g. "type-bug assignee-pamelafox") or all of the high priority requests ("type-request priority-1"), and easily browse through them in weekly reviews or triage meetings.

We've created a generic version of the Issue Tracky tool that anyone can play with, but we've also open-sourced the code, because we think that this is the kind of extension that companies will want to both use and customize for their own use, perhaps by integrating it with existing systems or changing the gadget to collect different pieces of information. To get started with your own version of it, download the code and follow the instructions in the readme. If you have any questions or want to share how you've extended the codebase, stop by the forum.

We hope this helps you have more productive discussions on the issues in your projects, and better collaboration with your teams. Enjoy!

Google Shared Spaces: How We Made It

2010-12-28T14:41:00.000-08:00

In my last post, I talked about why we made Google Shared Spaces. Now I want to talk about how we made it, as I think it may surprise a few folks. Much of the press about Shared Spaces claims that it is built off "Wave technology", when in fact, the only piece of Wave technology that Shared Spaces utilizes is the Javascript Wave Gadgets API. Since what we set out to make was really pretty simple, we decided to start from scratch and use a combination of open-source frameworks and publicly available APIs.

We use Python App Engine as the hosting platform, and Django 1.0 for the templates & request handling. We embed the gadgets in the pages using the iGoogle Gadget Renderer (a deployed version of the open-source Shindig server), the gadgets communicate with the page using the Wave Gadgets JavaScript API (now open-sourced), and the page communicates with the server using the Channel API (App Engine's approach to COMET). For AJAX processing and UI features, We use the Google-hosted jQuery. For authentication, we use the Twitter API, Yahoo API, and Google Buzz API. For the comments and ratings in the gadgets gallery, we use Disqus threads.

By starting from scratch while reusing the relevant technologies out there, we were able to build the first version pretty quickly (within a few weeks), and we're also able to iterate quickly now (new releases every couple days). While the open-sourced codebase for Wave is around 250,000 lines of code, the codebase for Shared Spaces is now about 5,000. Wave is a complex technology encompassing multiple algorithms, backends, and interfaces, while Shared Spaces is a user-facing app that uses just one small part of that technology and is developed by a small team. If you pick the right tools for the right job, you can do a lot with a little. :)

Google Shared Spaces: Why We Made It

2010-12-28T12:41:00.000-08:00

Last week, just in time for the holidays, we released a Google Labs project called Google Shared Spaces. "We" is actually just a few people working in our 20% time: Douwe Osinga - former Wave API tech lead, Jon Tirsen - former Wave contacts tech lead, Vadim Gerasimov - former Gadgets API engineer, and myself - former Wave API developer advocate. As you can see, we all came from the Wave team, where we saw firsthand the ways that users used Wave and the ways that developers used the Wave APIs. Wave was a lot of things to many people, and there are a lot of directions that you could take the ideas in it. After Wave was cancelled by Google, a small team has been working on open-sourcing it for the past 5 months, so developers can start building off the Wave technology stack, as a whole or as bits & pieces, to take it in the direction of their vision.

The four of us were personally interested in seeing what we could make with just the gadgets part of the stack. The Wave Gadgets API is a simple but powerful API -- it combines the open-source gadgets API with a basic JavaScript API for modifying a shared state (hash map) & retrieving participants information. With just a shared hash map, developers were able to make an astonishing array of gadgets - multi-player games, collaborative diagramming apps, date-picking utilities, even a Flash-like animation tool. In fact, developers made gadgets that were basically full-featured webapps, and they would take up the entirety of the Wave interface when you were using them. Developers weren't using Wave for its conversational abilities at that point -- they were just using it for the collaborative space that it enabled. Some of the developers even added a chat feature to their gadget, as users didn't want to have to scroll down past the gadget to converse with the other participants.

The Diagram Editor gadget:

When we saw this happening while Wave was still an ongoing project, we thought of various ways we could improve the Wave UI for these app experiences: full-screen modes, split scrollbars, chat mode. But with Wave cancelled, we thought about how we could start from scratch to create an experience that centered around these collaborative gadgets. At the same time, we wanted to experiment with other aspects of the Wave experience, like the sharing & permissions model. And thus, Shared Spaces was born.

Shared Spaces is entirely centered on the gadgets. The landing page is a list of featured gadgets, and each of them offers a button to "Create a space". Once you click that, you're prompted to login with either your Google, Yahoo!, or Twitter account. (We didn't see any reason to limit authentication to just Google, particularly since people might want to use Shared Spaces to collaborative with communities outside their Google sphere). You're then taken to a "space" with a list of participants (just you, to start), the selected gadget, a chat area, and a bunch of share buttons. Once you share the URL with other folks, whether via email, IM, or microblogging, you'll see the other participants show up in the list, and all of you can collaborate on the gadget together - whether that's a game of Sudoku, an RSVP gadget, or a drawing board. Much of the experience is similar to the Etherpad experience, where you can create a collaborative pad with one click, chat on the side, and share that pad by URL; I sometimes think of it as "Etherpad for gadgets."

The Yes/No/Maybe gadget:

We've launched Shared Spaces with what we deemed the minimal features necessary because this is very much an experiment; we want to see how users use this, what they want out of it, and what direction it may go in. Perhaps it will become a full product, or perhaps it will be integrated into existing Google products. And hey, maybe it will inspire non-Google companies to use similar technology in their products. The web is increasingly about collaboration, and I think it is always a good thing to experiment in how all of us can make collaboration easier. :)

The Costa Rica Surf Camp Experience

2010-12-26T20:57:00.001-08:00

I was born in California, but after an unfortunate decision from my dad, I ended up growing up in the cold confines of Syracuse, New York. I huddled for warmth in the glow of our many computers and eventually became a computer geek like my dad, but I often wondered what I would have become had I grown up in southern California instead -- and because it just looks so awesome in the movies, I always imagined myself as a surfer chick. I'm pretty happy as a computer geek these days, but I like to keep my options open, so I figured I should eventually take the first step to surfer chickdom: learning to surf.

Even though I've lived in California multiple times in my life, and lived in the surf kingdom of Sydney for the last two years, I somehow have never managed to get my ass on a surfboard. At one point, I figured it was just one of those things that I swore I'd always try and never actually do. (You gotta have a few of those). But in November, I serendipitously discovered that my colleague had the same wish -- and the same amount of vacation days -- and within a matter of weeks, we had arranged a weeklong trip to the Green Iguana Surf Camp in Costa Rica. We were deciding between Mexico, Australia, and Costa Rica, but eventually picked the latter because a friend recommended it, and because I've been to Costa Rica twice before & have something of a massive crush on that country. (Plus, I miss speaking Spanish - it's a beautiful language and there aren't many opportunities to practice it in Sydney).

We arrived in the surf camp in Costa Rica on December 12 and left on December 20th, and we had an amazing time in that week. We of course spent several hours each day learning to surf -- practicing the basics of the "pop-and-hop" -- and washing off in the local waterfalls after (they're as common as pubs are in Sydney). But we also spent a lot of time just enjoying the local culture, like:

The food: We'd usually start our meals with an appetizer of "patacones" (triple fried smashed plaintains) & guacomole, then continue on with a "casado" (rice, beans, and a protein) or a full fried red snapper. After surfing, we'd visit a street stand & pick up a ceviche -- raw fish that cooks itself from the acids in a cup of lemon juice. On "Tuna Tuesday" at the local pub, we had seared tuna in wasabi sauce, and it was the most delicious tuna that I've ever tasted - it melted in my mouth. Apparently Tuesday was the day they received the fresh tuna, and they wanted to sell it while it was fresh. It sure was! For snacks throughout the day, we'd walk up to our favorite fruit shop and have them cut up a pineapple (with sprinkled salt on it!) or a mango.

The wildlife: We saw lizards everywhere we went, including the largish "Ctenosaurs" which enjoy sunning themselves on hotel & restaurant roofs (and have an awesome dinosaur-sounding name). We also visited the local reptile park, Reptilandia, and wandered around it drinking Rum & Cokes from a can & marveling in a rather tipsy way at the rather large reptiles ("OMG ANACONDA!"). Thankfully, we didn't actually see much sealife during the surfing lessons, besides the crabs scuttling to-and-from all the holes in the beach. I was happy to imagine that I was surfing in a scary-animal-free zone. :) During one visit to a fruit stand, we found ourself feeding all our banana to a very adorable but aggressive Pizote (he showed us both his claws & his puppy dog face). On our last day there, we went horseback riding on a beach, and listened to the local birds calling in the trees (there's one that makes a sound like laughter, and it basically sounded like he was laughing at us the whole time.. as if I wasn't already lacking in confidence).

The nightlife: I was surprised to discover that our little town of Playa Dominical actually had a pretty thriving nightlife. Our first outing was to a Karaoke night, where the locals sang love ballad after love ballad (I say "love", but in fact most of the lyrics of the songs were much more about jealousy and rage), and we sang American classics, like "Total Eclipse of the Heart" and "I want to hold your hand". Our next outing was "Ladies Night," and the club was absolutely packed. The DJ, who we'd happened to befriend on our first day, played a mix of reggae, hiphop, house, reggaeton, and salsa. I loved dancing to that blend of genres, and I even had fun when a local led me in a salsa dance (I don't usually do partner dancing). We went out a few more times after that, and it was always a really fun atmosphere.

And most importantly...

The people: Before we embarked on this experience, we thought it would mostly just be us two, and that we'd do a lot of solitary reflection and all that deep stuff. But pretty much as soon as we arrived there, we met the crew that would occupy our days going forwards: our fellow surf campers - about 7 people our age and a family with highly entertaining 8-yr-old & 3 yr-old-boys, our surf instructors - 6 guys from ages 15 to 55, plus the family that runs the camp. We had a lot of fun learning to surf & experiencing the local culture with that crew, but in addition to them, we also met many friendly locals -- like the boy that cut up our fruit every day or the taxi driver that snacked with us after our horseback ride.

In short, I loved every minute of the surf camp experience, even the ones where I was battling the saltwater in my eyes & trying desperately to catch a wave, and I'm so thankful to the people of Playa Dominical that made it a warm & welcoming place.

And, oh, yeah, I found out that I'm not that great of a surfer. Back to geeking I go! :)

Reuseable HTML & CSS Teaching Materials

2010-12-05T01:40:00.000-08:00

When I decided to bring GDI to Australia and kickstart it with an HTML & CSS mini-course, I had a side goal: create reusable teaching materials. There are a huge number of online resources to help you learn web development, but there are few bundled sets of resources that can be used together to actually teach a topic to a class of students. (Or, atleast, few that I could find). I set out to make materials that I could CC-license and share with potential teachers, so that they could focus on customizing and delivering the materials instead of preparing them from scratch (which takes a surprising amount of time).

Since delivering the materials a few months back, I have cleaned them up and theyre now online here, at a nice friendly URL:
http://www.teaching-materials.org/htmlcss/

To see what's there, you can click through the various lesson links. To actually get started re-using the material yourself, you can download the linked zip file, or if you want an easy way to host it online for your class, you can even download the website files from github and deploy them to App Engine or your own server.

If you do end up delivering the course (or some version of it), I would love to hear about it. We need more HTML & CSS teaching in the world!

How I Bleach My Hair

2010-11-26T23:10:00.000-08:00

As many people know, I am a fan of coloring my hair. It's a form of self expression and all that good stuff. Since my hair is naturally a thick dark brown (shh, don't tell my colleagues, they think I have no natural hair color), I have to bleach it before dying it most colors (except black). I'm not really a fan of salons because I don't like talking to strangers for hours, so I tend to do it myself. Since other people sometimes get inspired by my hair experimentations and want tips, I'm going to share my technique here.

First, when it comes to bleaching, I do not use one of those kits with pretty people on the front. The kits are handy because they come with all the supplies you need and very specific instructions, but I find that they are not very strong - even the ones that purport to be the strongest.

Instead, I start with bleach powder and 40 volume creme developer. The "volume" refers to the strength of the developer, and "40 volume" is the strongest that you'll find. I'm currently using Fudge brand developer and powder, which I got from the hair supplies shop at Harbourside Mall in Sydney, Australia. If you're in the US, you may want to check out Manic Panic's 40 volume bleach kit instead.

I then put on cheap latex gloves and mix 1 part powder with 2 parts developer in a tupperware container (leftover from too much takeaway). If you don't mix enough, no worries, you can easily mix more later.

Then I rub the mix over my hair, starting at the ends. Instructions always have you do the roots last, and as it turns out, that's because the chemicals process faster when they're close to the head, because your head is so warm and heats them up.

When I think that I've got everything covered (don't forget the back of your head), I go and watch a TV show for a half hour or hour. I'm used to the slight burning sensation of bleach so I tend to let it stay on for longer, but if it bothers you, you can rinse it out after just 30 minutes.

After I rinse it out and dry it, I check out how white it became, and if I missed any spots (not usually).

If it is still a bit yellow (as is natural with hair) and I am trying to dye it blue or just go for the very white look, then I wait for it to dry and then put a purple toner on it. A purple toner is basically a light purple hair dye that counters the natural yellow hues in human hair - so it does sometimes make your hair a bit purple-y if you overdo it (but I like that). I use one of two options these days: Fudge purple toner, or Schwarzkopf LIVE Color Silver toner.

If I really care about maintaining the whiteness of the color, then I sometimes invest in toning shampoo, which is basically like shampoo with a little purple hair dye in it.

And that's it... happy bleaching!

GirlDevelopIt Sydney: Round 1, A Success!

2010-11-09T10:28:00.000-08:00

As I posted in August, GirlDevelopIt is an initiative to increase the number of women in tech through low-cost programming workshops. It was created in New York and is thriving there (on their 27th class now!), and I wanted to try bringing it here to Sydney, Australia.

Our tireless TAs

We started here with the basics, a 5-lesson course on HTML & CSS, with the hope of expanding to more topics if there was enough interest. We ended up filling the room with 40 eager female students from varied backgrounds - like marketing, travel, advertising, and photography - plus 6 super talented teaching assistants of various expertise - like SEO, startups, and standards. At the end of the course, students put together their own personal website to show what they'd learnt, and it was awesome seeing the unique webpages that each of them put together.

All in all, I would call this experiment a success, and I'm excited to see the momentum continue. We have an upcoming lecture with 30 RSVPs, we have a new offer of sponsorship (thanks to ThoughtWorks), and more importantly, we have 60 members in our meetup group who are all ready and willing to become women developers.

So, if you're keen and looking to help, here's a wishlist for things that would be awesome:

We could use spare laptops for the workshops, if you have any old ones lying around. They typically just need a web browser like Chrome and a text editor like Notepad++.
We would love for a hosting company to provide students in the courses with FTP accounts and a teeny amount of disk space. We used my server for the last round, but we couldn't do more than 8 simultaneous logins on mine, so it was not ideal.
We can currently get 10 free books from O'Reilly for each course, but if we had a sponsor (like a bookstore) that would provide free books for every student (~40), that would be just amazing.
We would love to have GDI branded t-shirts to give to the students, to help them feel proud of their involvement and to spread the message.

We can always use more women students and teachers, of course, so join the group if you're keen to get involved. Onwards and upwards. :)

Thanks to Kate Carruthers for the embedded photo.

"No Boys Allowed"...And Why I Like It

2010-11-01T05:49:00.000-07:00

We just wrapped up our first Girl Develop It course in Sydney tonight. When I was first planning the course, I had males ask if they could be students and TAs, and after some consideration, I said no to them.

Part of me wanted to prove that we could pull it off with an all female ensemble. We ended up enrolling 40 female students, bringing us to full room capacity (daisy-chained power cords, ftw!), and enlisting the help of 6 highly skilled female teaching assistants, from web standards wizards to JS experts. I thus concluded that lack of "womanpower" was clearly not an issue.

The other part of me wanted to see if we could indeed have a better learning environment by having it be all female, as we suggest is the case on the Girl Develop It website. I was the teacher in this course, so I can only give my perspective from the front of the room. But, I have to say, I liked it. I am a straight woman, so when I am giving talks to the mostly all-male crowds at most tech events, I sense a small part of me is trying to impress a small part of them ("that way"). It's not something I'm very conscious of, as I'm usually fairly empassioned by the ideas my talk, but it is there nonetheless. When I am speaking to a group of all females, I am motivated only by the desire to educate them and not by any hidden desires. I played the part of the teacher in this course, but at the same time, I am also a student in an Afro-Brazilian dance class which is largely female. Similar to my reasoning for enjoying the absence of boys in the web dev course, I find that I enjoy the dance classes more when it is just us girls. I can shake my hips without worrying subconciously about impressing the boys in the class and having my performance affected by subsequent nervousness.

On a related note, it's nice to be in an environment where we can talk girl stuff and bring up "risque" topics without worrying about making boys feel awkward or wondering if they'll misinterpret our language. In dance class, we often make up rhymes about our "boobs", "hips", and "asses", and they help us learn the move... but it always feels a bit odd to teach them to boys too. That sort of thing doesn't happen as often in the web development course situation (well, maybe during the after-drinks :), but it's nice to have that kind of environment just-in-case.

Finally, it's cool to meet local women. I have to admit that I'm not that great at making friends with girls (I grew up more around males), so I typically only make them when I'm forced to. Being in an entirely female room definitely helps as a forcing function. :) I met a bunch of awesome girls during this course and the dance class who I probably wouldnt've met otherwise, and I'm looking forward to seeing more of them.

I know there are people who may argue that it is sexist to not allow boys into the classes, but I think that if you are going to go the "no boys" route, you should go all the way or you risk losing some of the benefits completely. This doesn't mean that I think every thing should be all girls - I will be actively encouraging the GDI students to come to mixed meetups, workshops, and user groups. It just means that I do see benefits to single-gender groups in some situations, atleast from my own personal perspective.

An Unofficial Guide to Geeking It Up Around Sydney

2010-10-21T17:58:00.000-07:00

Before I came to live in Sydney, I actually spent a day googling for information on the Sydney developer scene, learning about the local startups, user groups, and mailing lists. I didn't know anyone in Sydney, and I wanted to make sure I both had a way to get to know locals (make new friends!) and also figure out what sort of Google developer events I should organize. In just my first weekend in Sydney, I attended BarCamp Sydney 4 and met many of the people that I'm friends with today, and since then, I've attended something like 50 local meetups, "drink-ups", hackathons, and conferences.

I think it's really fun to attend events from a get-to-know-others perspective and really useful to attend events from a learn-what-others-are-doing perspective, and I want to make sure every Sydney developer is aware of the events going on around them. So, for last night's Girl Geeks Dinner lightning talks, I put together a short preso on the local developer scene, and I've embedded it below. Hope to see you at an upcoming event!

Sydney International Food Festival Maps

2010-10-13T23:42:00.001-07:00

Every year, Sydney has this awesome International Food Festival filled with food events and deals on meals at local restaurants. In particular, they have this "Lets do lunch" deal where you can get nice lunchtime meals at fancy restaurants for $35, and I usually like to get some colleagues together to hit up some of the restaurants. Unfortunately, they never have a map visualizing the locations of all the restaurants, and it's hard to find the places near my work.

So, every year, I make a map of the restaurants. Per request of @MorselsMusings, I've also made maps of the Cocktails, High Tea and Sugar Hit deals. The deals last until the end of October, so check them out now while you have time!

If you're a developer and wondering how I whipped these together, here's the short version: 1) I used Dapper to get a CSV of the name, description, and link from the main page, 2) I converted those into a Google spreadsheet and used the importXML function to get the address from the individual restaurant page, 3) I published the sheets and got the latitude/longitude coordinates using my Spreadsheets Geocoding tool, 4) I made the maps using my Spreadsheets Maps API wizard. It is a bit of a process, but as I spend half my life doing this sort of thing, it doesn't actually take very long (< hour).

Happy fooding!

lscache: A localStorage-based, memcache-inspired library

2010-10-13T22:29:00.000-07:00

Over the past few years, I've developed a fair few Python App Engine apps, and I've come to have a huge admiration for memcache. The memcache API is incredibly simple, but at the same time, it's a very powerful way of making my apps scale better with increased user demand. The first time I wrote an App Engine app, it went over quota in the first 6 hours. After adding memcache support in, it never went over 1% of quota ever.

When I'm writing client-side apps, I find myself yearning for something like memcache to reduce my number of asynchronous server requests. HTML5 does offer the localStorage API for setting and getting key/value strings, but that API has no notion of an expiration date. It's great to be able to store copies of my data locally, but most of the time, I also want to be able to expire that data after some amount of time (5mins, 1hour, 1 day). So, I wrote a simple library called "lscache" that wraps on top of localStorage, but adds on the notion of expiration. Here's what it looks like to set and get some data:

lscache.set('somedata', {'name': 'Pamela'}, 60);
if (lscache.get('somedata')) {
  console.log(lscache.get('somedata').name);
}

The library lets you store pretty much anything, like a string, number, or object. The localStorage API only stores strings itself (though according to the spec, that should change soon), but the library uses JSON.parse and JSON.stringify to try to store non-string objects. There are some objects that can't be stringified, like the Document object in an XMLHttpRequest, in which case you need to convert them to a simple JSON object yourself first.

The library stores the expiration time in a separate key, and when you try to retrieve a key, it will only return it if the current time is before the expiration time (and will remove it otherwise). It calculates the time using the JavaScript Date object, so it is subject to error if the user futzes with their clock - but if they do, it just means the objects will be cached for a bit less or a bit longer than expected, and the world probably won't fall over. And those silly people should stop futzing with their clock. :)

If the user's browser doesn't support localStorage, the library just won't store anything and will return null when trying to retrieve objects. This works wonderfully with the memcache style of coding, where you never assume that anything is stored, and always fall back to re-retrieving that data if it's not stored. People with "older" browsers will simply get a not-as-speedy performance.

I've pushed the lscache code to a github repo (my first!), and also published a demo of the functionality. I originally wrote lscache to speed up the performance of the XMLHttpRequests in a Chrome extension popup, but as that extension isn't published yet, I've also incorporated it into my public RageTube mashup to cache the JSON results of the Dapper and Youtube APIs.

Check out the library, and if you have any suggestions for improvements, feel free to fork. :)

SydJS: JavaScript Libraries Panel Roundup

2010-10-13T16:13:00.000-07:00

At last night's monthly meeting of Sydney JavaScript developers, the organizers tried a different format: the panel. I will admit I was a little wary of the format choice, as I've heard a lot of commentary about panels not being so great (and I've attended SXSW, which seemed to re-inforce that) -- but I think it turned out quite well. The panel had a range of JS developers that represented different libraries, and articulated their differences in opinion in constructive ways.

The panelists were:

James McGill, Google, Maps API
Dan Nadasi, Google, Closure (@DanielNadasi)
Matthew Sain, Yahoo!7, YUI 2
Tom Hughes Croucher, Yahoo!, YUI 3 (@sh1mmer)
Dmitry Baranovskiy, Sencha, Raphael (@DmitryBaranovsk)
Evan Trimboli, Sencha, Sencha
Julio Ody Cesar, Awesome By Design, jQuery (@julio_ody)
Jared Wyles, Atlassian, AUI (@rioter)

(Photo courtesy of halans - Check out his other SydJS pics.)

I typed up notes during the panel on the questions and answers, and am sharing a paraphrased version of those notes here. I didn't type anything word-for-word, and I missed some of the answers, so don't consider this to be 100% faithful. But perhaps it's useful for folks who want to remember what was discussed last night, or see the kind of questions that were asked at the panel.

Q: Can your libraries be loaded asynchronously, and if not, how do you sleep at night?
Tom: YUI was designed with that in mind from the beginning. It's the only way of loading it. James: The Maps API does it automatically - developer only includes the bootstrap and the API pulls the full library in after. All APIs should do it automatically, otherwise developers won't usually bother.

Q: How do you test the Maps API offline?
James: You must mock, and trust that we've designed our API in a way that makes for reliable mocks (we have). Check out the Closure mocking framework, based on EasyMock.

Q: Why doesn't Google use Raphael for SVG?
James: The Maps API only uses paths, and it isn't that hard to get paths working cross-browser. When you use a library, you're putting performance in someone else's hands, and the Maps API can't afford to do that.

Q: What do you think of CoffeeScript?
Julio: CoffeeScript is not equal to JavaScript. Different languages appeal to different people.
Tom: I talked with Douglas Crockford, and he actually likes CoffeeScript, and thinks that maybe we should have done JS that way (if we could have). But now, even if we could reinvent JS, even if we could make it better, it would be a separate language. JS is winning right now, not because it's the best language ever, but because it's the language of the web. So we should stick with JS.
Dmitry: There is real life, and there is play. I like to play- I like canvas- but I don't use canvas in real projects because it doesn't work in IE. It's not real life. It'd be sad if there was a CoffeeScript programmer that did not also know JavaScript.

Q: What's the purpose of the Closure inspector?
Daniel: It is easier to debug your Closure code before it has been obfuscated, and that's what you normally do. Some bugs, however, only occur after obfuscation, and the Closure inspector is useful for debugging the post-obfuscation bugs. Sometimes those happen when using the advanced compiler options with symbol exporting.

Q: How will we develope JS in the future?
Julio: We will see more modularization, where every page has its own miniframework, its own collection of modules used by the page.
Jared: We will see JS in the server more.
Evan: We will also see JS in the desktop.
Dmitry: We will have better IDEs for developing JS.
Tom: We will have better code, and new features of the language (like strict mode) that encourage developers to write better code.

Q: Do you support touch events in your frameworks?
All: Yes.
James: Currently, it's not too difficult to support touch events since the mobile browsers all followed Apple's lead in implementing them and the API is the same. But, in 8 days, Microsoft is going to release Windows Phone 7, which bundles a ported version of the IE7 browser, and we don't have any idea what touch events will look like. Mobile development is going to get significantly more interesting; we're going from a 1 browser field to a 2 browser field.

Q: What place do UI frameworks like Yuki and ExtJS have - should we be using them, and are they accessible?
Tom: ( Re accessibility) Frameworks should use ARIA for accessibility, which marks up the page to give screen readers additional info. The fact that most screen readers don't support JS is a technology failure. There's nothing inherent about JS which means it can't be supported. Current accessibility guidelines put the onus on the screen readers. Modern readers like Jaws 7 do support JS. Pick a framework that supports ARIA.
Tom: (Re frameworks) Rebecca Murphy has written recently about the problems with using jQuery for enterprise sites. With libraries lik jQuery and Prototype, people tend to write DOM-focused code. With libraries YUI and Closure, people write component-based code. jQuery has done a good job of getting people started with JS and making it easy to get your site going, but when you're building full apps, the component-based architecture with its inheritance and modules works better. DOM-style architecture gets ugly fast.
Nadasi: Part of the reason we use component-based approach in Closure is because it works better at scale. In base.js, goog.inherits lets classes inherit from other classes easier. The ability to inherit is better for distributed development, for having many developers working off the same codebase.

Q: I come from a Java/C++ background, where tooling support is important. In moving to JS, I'm missing the tools. A lot of the times, I feel like I'm guessing-and-checking. Are you guys keeping secrets from us, or is that the way it is?

Julio: I work with Ruby as much as JS, and it has really nice testing tools - the best of any language I've seen. I hope JS will have similar tools somedays.
James: Maybe you should check out Closure compiler. It lets you enforce static typing, which is like testing for a dynamic language - it will catch half the errors. But, in defense of JS, what other development environment lets you inspect your UI, change your UI on the fly, and reflect the changes back?
Dan: Keep in mind that the cost of implementing static typing is that you lose dynamic typing. Static typing can be great for development at scale, but it deprives you of some flexibility.
Tom: I recommend SpeedTracer from Google for performance checking, Firebug for Firefox, and Visual Studio Debugger for IE.
Buchanan (audience): We would love more tools for JS, but on the other hand, I've never lost a day of development due to my IDE refusing to work.

Q: Do we need libraries now? Browsers are better, JS is easier cross-browser.
Julio: We're not at the stage yet where cross-browser isn't an issue.
James: When you're getting started with building an app, you can use libraries to take care of the hard parts for you. But once you start getting significant users, like we did with the Maps API, you'll understand their specific usage patterns, and you will find it better to write your own code that optimizes for their use case.

Q: What was the design problem you were trying to fix when building your library?
Matthew: We designed YUI for the frontpage of yahoo.com, and then decided to open-source it for others to use.
Dmitry: IE has a problem with speed, it's very slow, and it has a problem with DOM, it's just fucked up.

Q: Should we use jslint?
All: Yes.

Q: What would you do better if you were starting over?
Dan: With Closure, we would design API from the start instead of adding bits and pieces. The API is surprisingly consistent, likely due to having the same 2 code reviewers throughout, but it could be better. The documentation is shit. Michael Bolin's book fills in the gaps, but you shouldn't need to read a book to understand how to use it.
James: I would design the code to make it testable first, because it's hard to go back and make something testable. If I really wanted to hate my life, I would code everything in IE6 and get it working reasonable there, and *then* see how awesome it performed in other browsers.
Evan: Augmenting the prototype of basic objects (Array, String, etc) was not a good idea.

Generating Slides from a Spreadsheet

2010-10-07T22:17:00.000-07:00

Lately, I've been playing around with the HTML5 slides deck from slides.html5rocks.com. A few months ago at the GTUG campout, I hacked together an App Engine app for generating HTML5 slide decks. Last week, in preparation for my GDD Tokyo talk on Google's JavaScript APIs, I wrote a client-side mashup that generates an HTML5 slide deck based on data in a published Google spreadsheet, and used it both as my actual slides and as a demo for the talk.

There are some definite benefits to writing your slide content in a spreadsheet:

You can look at the revision history of just your content (instead of a confusing mix of code and content)
You can share the spreadsheet with other people, and collaborate on the content with them.
You can print the content for easy studying.
You can create alternate views of the same content, like differently themed slide viewers or slide viewers that show additional columns of information.

Of course, there are disadvantages as well - primarily the fact that Google Spreadsheets wasn't designed as a content management system, and it isn't terribly easy to author multi-line content in the cells.

In case any of you do want to try using a spreadsheet to build your slides, I've made a generalized version of the viewer that will work with any public spreadsheet.

To get started, create a spreadsheet with three columns, 'type', 'title', and 'content'. The type can either be 'intro', 'normal', or 'section', and the title and content can be any text (inc. HTML tags). For example, check out this sample spreadsheet.

Next, publish that spreadsheet using the "Share -> Publish" menu in Google Spreadsheets, grab the key from the URL in the browser, and pass that as the key parameter to the generic slides viewer. For example, here's the URL for the sample spreadsheet:
http://imagine-it.org/sslides/slideshow.html?key=tp1JIiBR7gyKgOKUMDk4d_g

As a bonus feature, you can also include a 'narration' column in your spreadsheet, and display that narration below the slides by passing 'narration=on' to the viewer. For example, here's the Japan talk with narration on:
http://imagine-it.org/sslides/slideshow.html?key=0Ah0xU81penP1dDZWcmxjUjdhOTMyOGxxWXAxMnpKUWc&narration=on

As usual, I will keep experimenting with HTML-based slide viewers until I find the holy grail, so stay tuned! :)

History of Client-side Web API Technology

2010-10-05T05:04:00.000-07:00

As part of GDD Tokyo last week, I gave a talk on Google's "client-side Web APIs". That phrase is a bit of a mouthful (and not a common one), so here's what I mean by it: An "API" is a way for one piece of software to interact with another piece of software, a "Web API" is a way for one website to interact with another website, and a "client-side Web API" allows a website to interact with another website purely using client-side technology. For example, Google's client-side Web APIs include the Charts API (image-based), the AJAX Search APIs (JavaScript-based) and the Gadgets API (iframe-based).

Both because I needed a way to explain the underlying technology behind our APIs and because I found it interesting, I started that talk with an intro to the history of client-side Web API technology -- the series of milestones in the evolution of the web that brought us to where we are today.

I was just a wee lass when the web was young, so I've cobbled this history together by reading old blog posts, mailing lists, tutorials, and press releases. (And yes, it is a bit Google-biased, since I have more access/knowledge of our history than others). I'm posting it here in hopes that others will learn from it and others will teach me more about the early web. Please let me know in the comments if you have corrections or additions.

It all started with...

1990: HTML

In 1990, Tim Berners-Lee created the first prototype web browser and HTML page, and you can actually still view that page today.

At this point, HTML was capable only of text and links, so we could link to other server's data, but we had no way of including it in our own page.

1993: IMG

3 years later, Marc Andreesen was working on the NCSA Mosaic Browser and realized they wanted a way to include images on webpages - so he proposed the IMG tag, implemented it, shipped the browser, and it's stayed to this day. That is a typical story for how HTML gains a new tag - someone needs it and implements it, others copy it, and eventually its considered part of the standard.

The IMG tag could point to image resources on external servers anywhere on the web, so it was actually the first way you could bring data from other servers onto your page, though the data had to be in image form.

Perhaps the first commonplace use of the IMG tag as an API of sorts was for "hit counters." People would put hit counters on their sites to track visitors, and each counter was actually just an IMG tag pointing at a server, passing in an ID parameter.

1995: JavaScript

In 1995, Netscape and Sun teamed together to introduce JavaScript, a language they predicted would transform the web. At the time they introduced it, JavaScript could only really programmatically do the things you could already do in HTML - like programmatically creating IMG tags -- but it was an important step towards making client-side APIs more possible.

1996: IFRAME

In 1996, Microsoft introduced the IFRAME element. The IFRAME element could embed another webpage on your page, which is one way of bringing in another server in a simplistic manner. It could also be hacked to bring data asynchronously into a page from the same server, similar to what XMLHR would make possible later.

1996: Flash

In 1996, Macromedia launched the Flash Player plugin. The EMBED or OBJECT tags could now be used to embed a SWF file from anywhere on the web. Flash embeds meant we could embed something more interactive than just an image, like a game or animation.

1999: XMLHttpRequest

In 1999, Microsoft innovated again by introducing the XMLHttpRequest object in JavaScript. XMLHttpRequest could make a request to your server, get data back from it, process the data, and render it into the page however it liked. By default, you could only bring data in from your own server using XMLHttpRequest. With particular security settings in IE only, you could actually bring data in from other servers.

XMLHttpRequest was important in getting people to think about getting data into webpages, and making them consider the possibility of getting data from servers other than their own.

2004-5: GMail, Google Maps

In 2004, Google launched GMail, the first popular web application that relied upon XMLHttpRequest/IFRAME for asynchronous data retrieval from the server, and really showed off what was possible with those technologies. In 2005, Google launched Google Maps, which used the same technology to transform online maps into an interactive experience.

Feb. 2005: "AJAX"

Around the same time, Jesse James Garrett coined the term "AJAX" to describe the new GMail-style of applications which fetch data asynchronously using XMLHR and reduce the time users spend waiting on page loads. After he coined the term and popular JS libraries built in support for XMLHR, it quickly rose in popularity amongst web developers as the new, right way to build web applications.

We were still limited to using AJAX to just getting data from our own domain, however.

June 2005: Google Maps API

A few months later, Google launched version 1 of the Google Maps API, the first JavaScript API by Google and also one of the first JS APIs by a big company. This first API was really a JavaScript library that would dynamically create IMGs for each map tile, position them with CSS, and make it easy to add control DIVs and marker IMGs. Developers would typically use the Maps API in conjunction with AJAX requests to get map data from databases on their server.

Dec. 2005: "JSONP"

In December 2005, Bob Ippolitto wrote a blog post describing a technique he named "JSONP", which used ("hacked") the SCRIPT tag to asynchronously bring data in from other servers.

Finally, with JSONP, we had a way to bring data in from another server without using a server ourselves - as long as that server provides JSONP-compatible output.

May 2006: Google AJAX Search API

Next year, Google launched the Google AJAX Search API, which let you embed a Google search box on your site and display the results there, without ever having to leave the site. Since this API needed to get data from Google servers while being used on any domain, it used JSONP behind the scenes and wrapped it up in some JavaScript functions.

This was one of the first APIs that used JSONP to let developers get data from other servers and include it on their site, and paved the way for others.

And that bring us to...

Present-day: Client-side Web API Technology

Thanks to the contributions to HTML/JS over the years, we now have these technologies to power client-side Web APIs:

Images
Iframes
JavaScript
JSONP
Flash

Note: It has been pointed out in comments that other plugin technologies are also important in this history, and used as or inside APIs, like Java Applets and Silverlight. ActiveX scripting also has a part. We do not use these particular technologies in Google client-side Web APIs, but I will look into their history and update this when I have the chance.

RageTube: Using APIs to Bring Music Video Playlists Online

2010-09-22T20:43:00.001-07:00

As I've mentioned in other posts, I have a thing for music videos. Whenever I visit a new foreign country, I try to find the local music videos channel and learn about their culture entirely through hours glued to the channel (it kind of works!). In Australia, I eventually discovered Rage, a 6-hour long stretch of music videos that plays every Friday night, Saturday morning, and Saturday night (midnight to 6am!). I did my best to reorganize my life so that I could catch atleast one of the 6-hour stretches each weekend, but alas, I eventually acquired hobbies and the semblance of a social life. At the same time, I've been increasingly disappointed with my worktime music options here — I can't use Pandora (US only), can't use Spotify (Europe only), and have had mixed success with Grooveshark. So, I decided to kill two birds with one stone, and make a mashup that'd let me watch Rage during the day in the form of Youtube music videos: RageTube!

To use RageTube, you provide a URL to any playlist from the Rage archives and it will take care of finding music videos on Youtube for all of the songs and playing through the list one at-a-time. You can skip through songs you don't like with the "Next" button, or you can click ahead or back to videos that you want to watch immediately. Plus, if you want to remember what songs you liked (or hated!), you can click the "Yay", "Meh", or "Nay" ratings widget and see your rating displayed in the playlist. That makes it even easier to find favorite videos to skip to later.

I wrote RageTube on a Monday morning and after sharing it on Twitter, I've discovered that there are quite a few Rage fans that are happy to have a way to enjoy Rage at work, including a few of my Australian colleagues abroad that never get the chance to watch Rage on TV anymore. I've added a few features since the initial version, like the ratings widgets, share-by-URL, and support for older playlists, but I still have much room to improve it, like by adding a playlist picker and playlist ratings.

Now, I have to admit I didn't write RageTube just because I needed a better music option at work — I also plan to use it as a demo in my upcoming GDD Tokyo Talk to showcase how much is possible with just the Google JavaScript APIs. The entire mashup is client-side - one HTML and 2 JS files - and it relies on 3 different JS APIs as well as some HTML5 functionality.

For those interested, here's how it works behind the scenes:

When you enter a URL, I send that URL through open.dapper.net, service that screen-scrapes websites and gives you the desired nodes in the format of your choice. I fetch the JSON format using a lightweight JSONP library. I store the song and title in an internal JS array and render them out as a scrollable list.
```
var dappUrl = 'http://open.dapper.net/transform.php';
var params = {'dappName': dappName, 'transformer': 'JSON', 'applyToUrl': playlistUrl}
JSONP.get(dappUrl, params, function(json) {
  ....
});
```

I then try to play the first song, and when I discover that there's no youtube ID stored in in the internal array (as will be the case for the first song), I use the Youtube JSON-C API to find the first matching video.

var query = song.artist + ' ' + song.title;
var searchUrl = 'http://gdata.youtube.com/feeds/api/videos';
var params = {'v': '2',  'alt': 'jsonc',  'q': query}
JSONP.get(searchUrl, params, function(json) {
  song.results = json.data.items;
  song.youtubeId = json.data.items[0].id;
  ...
});

The first time that I play a video, I embed the Youtube player SWF in the page using SWFObject, specifying a few parameters that will make it possible for me to use JavaScript to interact with that player later using the Youtube Player API.

var params = {allowScriptAccess: 'always', allowFullScreen: 'true'};
var atts = {id: 'youtubeplayer'};
swfobject.embedSWF('http://www.youtube.com/v/' + song.youtubeId +
 '?autoplay=1&fs=1&enablejsapi=1&playerapiid=ytplayer',
 'videoBlock', '425', '356', '8', null, null, params, atts);

Once I get programmatic access to the player, I register a callback so that I know whenever the player changes status (started/paused/ended).

function onYouTubePlayerReady(playerId) {
  youtubePlayer = document.getElementById(playerId);
  youtubePlayer.addEventListener('onStateChange', 'onYouTubePlayerStateChange');
}

When the video ends, I play the next song. (I've already got the Youtube ID for the next song because I always search for the next video whenever I start playing a video.)
```
function onYouTubePlayerStateChange(newState) {
  if (newState == 0) {
    currentSong++;
    playNext();
  }
}
```

To let users rate each video, I use a localStorage-based doodad that I wrote for another music video mashup.

likerCol.appendChild(LIKER.createLikerMini(song.id));
...
likerBlock.appendChild(LIKER.createLiker(song.id));

Happy RageTube'ing!

Embedding Feed Gadgets in Google Sites

2010-09-20T00:30:00.001-07:00

Today, I spent a few hours re-organizing waveprotocol.org to be easier to navigate. As part of that re-org, I wanted to also make it clear to people visiting the site that the protocol is in active development by showing them the activity from our discussion group and code repository. Since both the group and project offer ATOM feeds, I figured I could just embed a gadget to show the latest posts from the feeds.
After spending a good half hour trying to find a gadget that would do just that, I gave up and wrote one myself. And now you can use the gadget yourself if you're in a similar situation. :)

Using the Gadget

Here's how you can actually embed the gadget on your site:

Put the target page in editing mode. Open the "Insert" menu and select the final "More gadgets" option.
Select "Add gadget by URL" in the sidebar of the dialog.
Enter this URL in the input box:
http://pamelafox-samplecode.googlecode.com/svn/trunk/feedgadget/feedgadget.xml
Enter the URL to your feed in the "Feed" input box in "Setup your gadget". The feed must be either an ATOM or RSS feed.
Customize the width, height, and title as desired.

Tip: If you want to embed multiple gadgets next to eachother, change your page layout to a multi-column view and stick a gadget in each column.

Finding Feeds

Here are some tips for finding feed URLs for various Google properties:

Blogger: Scroll to the bottom of the blog and click "Posts (ATOM)" link. Here's an example blogger feed URL:
http://otherfancystuff.blogspot.com/feeds/posts/default
Google Groups: Click the orange "XML" image at the bottom of the group home. You can pick from various feeds - the "15 new messages" ATOM feed works well in my experience. Here's an example group feed URL:
http://groups.google.com/group/wave-protocol/feed/atom_v1_0_msgs.xml
Google Code Projects: Click the "Feeds" link on the sidebar of the project front page. You can pick from various feeds, depending if you want to show all activity or limit to just issues/downloads/etc. Here's an example project feed activity URL:
http://code.google.com/feeds/p/wave-protocol/updates/basic
Google Sites: Each site has an associated feed for recent updates. There's not a good way to find the link to that feed, but you can construct it easily by adding "activity.xml" to the site URL. Here's an example site updates feed URL:
http://www.waveprotocol.org/activity.xml

About the Gadget

For developers, here's some information about how the gadget works.

The gadget uses the AJAX Feeds API and the google.feeds.FeedControl class, and of course, it uses the gadgets API. It's actually a nice example of how to write a simple gadget that uses a Google API and user preferences:

<Module>
    <ModulePrefs title="Feed Control" height="400"/>
    <UserPref name="feedurl" display_name="Feed" default_value="https://groups.google.com/group/wave-protocol/feed/atom_v1_0_msgs.xml"/>
     <Content type="html"><![CDATA[ 
     <div id="feed" style="font-size: small;"></div>
     <script type="text/javascript" src="http://www.google.com/jsapi"></script>
     <script type="text/javascript">
     google.load("feeds", "1");
   

     function initialize() {
       var prefs = new gadgets.Prefs();
       var feedControl = new google.feeds.FeedControl();
       feedControl.addFeed(prefs.getString("feedurl"), "");
       feedControl.draw(document.getElementById("feed"), {});
     }
     google.setOnLoadCallback(initialize);
     </script>
     ]]>
    </Content>
</Module>

Using OAuth with Spreadsheets API on Django/AppEngine

2010-09-15T01:36:00.001-07:00

In a previous blog post, I showed how to import a published spreadsheet feed into an App Engine datastore by just grabbing the JSON. For another project I'm working on, I need to be able to import a *private* spreadsheet into an App Engine datastore. Because of the need to authenticate the user (via the multiple steps of the ever-so-elegant OAuth dance), this importing requires much more finagling.

With the help of my trusty colleague Vic Fryzel, I've put together a set of Django views that use the Python GData Client Library and should run on both App Engine Django, and with some modification for token storage, other Django stacks. I'll walkthrough the views here.

There are four URL handlers required, two for token requests, one for actually importing the spreadsheet, and one to manage the flow:

urlpatterns = patterns('',  
  (r'^get_oauth_token', 'importer.views.get_oauth_token'),
  (r'^get_access_token', 'importer.views.get_access_token'),
  (r'^import_spreadsheet', 'importer.views.import_spreadsheet'),
  (r'^$', 'importer.views.main_page'),
)

When the user visits the main page, they are asked to login so that the app can remember their auth tokens, and if they are already logged in, they are redirected to the first token handler:

def main_page(request):  
  if not users.get_current_user():
    return HttpResponseRedirect(users.create_login_url(request.build_absolute_uri()))

  access_token = gdata.gauth.AeLoad(ACCESS_TOKEN)
  if not isinstance(access_token, gdata.gauth.OAuthHmacToken):
    return HttpResponseRedirect('/importer/get_oauth_token')

In this first step of the OAuth dance, the app requests an oauth token for the specified scope (Spreadsheets), key/secret (anonymous, as I haven't registered my app), and a callback URL to my app. It saves that token to the App Engine datastore using a convenience function in the client library. Then it redirects the user to the authorization URL for that token, and the user is presented with the "Grant access" screen.

def get_oauth_token(request):
    oauth_callback_url = 'http://%s:%s/importer/get_access_token' %
        (request.META.get('SERVER_NAME'), request.META.get('SERVER_PORT'))
    request_token = client.GetOAuthToken(SCOPES, oauth_callback_url,
        CONSUMER_KEY, consumer_secret=CONSUMER_SECRET)
    gdata.gauth.AeSave(request_token, REQUEST_TOKEN)

    authorization_url = request_token.generate_authorization_url()
   return HttpResponseRedirect(authorization_url)

When the user returns from the authorization screen to the callback handler, the app retrieves the original token, asks Google to upgrade that to an access token, and saves the access token to the App Engine datastore again.

def get_access_token(request):  
  saved_request_token = gdata.gauth.AeLoad(REQUEST_TOKEN)
  request_token = gdata.gauth.AuthorizeRequestToken(saved_request_token,
      request.build_absolute_uri())
  access_token = client.GetAccessToken(request_token)
  gdata.gauth.AeSave(access_token, ACCESS_TOKEN)
  return HttpResponseRedirect('/importer/')

The user is then redirected to the main page, and since it sees that there is now an access token for the user, it shows the user an input box for providing a spreadsheets URL. When it knows the spreadsheets URL, it retrieves the list feed for that spreadsheet and saves each row as an entity in the datastore.

def import_spreadsheet(request): 
  import re
  import models

  client.auth_token = gdata.gauth.AeLoad(ACCESS_TOKEN)

  spreadsheet = request.GET.get('spreadsheet')
  if spreadsheet.find('google.com') > -1:
    spreadsheet_key = re.search('key=([^(?|&)]*)', spreadsheet).group(1)
  else:
    spreadsheet_key = spreadsheet
  worksheet_id = 'od6'
  list_feed = 'https://spreadsheets.google.com/feeds/list/%s/%s/private/values' %
      (spreadsheet_key, worksheet_id)
  feed = client.get_feed(list_feed,
                         desired_class=gdata.spreadsheets.data.ListsFeed)
  for row in feed.entry:
    firstname = row.get_value('firstname')
    lastname = row.get_value('lastname')
    email = row.get_value('email')
    person = models.Person(firstname=firstname, lastname=lastname, email=email)
    person.save()

  return HttpResponse('Saved %s rows' % str(len(feed.entry)))

Using that code, the end result is going from this spreadsheet...

... to these datastore entities:

To see the full code (with inline comments), check it out from my repository or download the zip.

For simplicity's sake, this sample shows the simplest possible import. In my actual project, I am also creating an entity that represents the entire spreadsheet, and the entity for each row refer to that entity. In addition, I have code to convert from the spreadsheets strings to other model types like dates.

Hopefully this project can serve as a basis for other developers using spreadsheets as an import source for their apps. Enjoy!

Porting from an App Engine RequestHandler to a Django View

2010-09-12T16:58:00.000-07:00

For whatever reason, I've found myself porting Python App Engine apps over from App Engine's "django-esque" webapp framework to true django 1.0 with views.py, urls.py, and the like.

Besides learning about how urls.py and views.py work, I had to do some research to figure out how some of the webapp-isms translated to django-isms, so I thought I'd post my findings here in a table comparing the two:

Webapp	Django
author = self.request.get('author')	What you use depends on how specific you want to be about where parameter was passed: author = request.GET.get('author') author = request.POST.get('author') author = request.REQUEST.get('author')
class MyRequestHandler(RequestHandler): def get(self): # Do stuff def post(self): # Do other stuff	def handle_request(request): if request.method == 'GET': # do stuff elif request.method == 'POST': # do other stuff
host = self.request.host	host = request.get_host()
url = self.request.uri	url = request.build_absolute_uri(request.path)
query_string = request.query_string	query_string = request.META['QUERY_STRING']
self.error(500)	return HttpResponse(status=500) or from django.http import HttpResponseServerError return HttpResponseServerError()
self.redirect('/gallery')	from django.http import HttpResponseRedirect return HttpResponseRedirect('/gallery')
path = os.path.join(os.path.dirname(__file__), 'index.html') self.response.out.write(template.render(path, template_values))	from django.shortcuts import render_to_response render_to_response('index.html', path) Or, if for some reason you need the in-between products of that shortcut (like the generated string), you can use the longer version: from django.template.loader import get_template from django.template import Context t = get_template('index.html') html = t.render(Context(template_values)) return HttpResponse(html)
self.response.headers['Content-Type'] = 'application/atom+xml' self.response.out.write(xml_string)	return HttpResponse(xml, mimetype='application/atom+xml')

If you have suggestions for better "transformations", please let me know. I'm fairly new to Django and am happy to learn more about the right way to do things.

Teaching & Using Google Data APIs @ USYD

2010-09-09T16:44:00.001-07:00

As I've posted on other blogs, I always love the idea of teaching Web APIs to university students and finding ways to use them in class assignments. Today, I visited the University of Sydney (USYD) and saw multiple ways that they're using APIs in education, and I'd like to share them here.

First, I gave a guest talk to an Object-Oriented Frameworks class on "Google Data APIs & the Google Docs API". For the next two months, the students in that class will be working on group projects with an education theme and combining the technologies they've studied, and I hope to show up on their demo day and see some cool examples of API usage.

After the talk, I went to lunch with the professor's research team, and watched videos about some really neat education & API related projects they're working on: iWrite, a system for submitting assignments as a doc & getting instructor feedback, and Glosser, a system for automatically creating questions about papers to make students think more about them; and for analyzing contributions of group members to a paper. Both of these use Google Data APIs in conjunction with the students' USYD Google Apps accounts, and are great examples of how research, APIs, and Google products can interact.

Though the Google Data APIs are not as "sexy" as our other APIs, they are incredibly useful and great teaching tools since they span across many Google products and build on existing web technologies like XML, ATOM, OAuth, and the HTTP protocol. They're also particularly useful for students at Google Apps enabled universities, since they can be used to create applications for accessing and modifying data in the Google Apps suite that they use daily.

When I was a TA at my old university (USC), we used Google docs and spreadsheets in our classes for keeping tabs on group work, and I used the APIs to automate processes for the professor. That was right before USC actually became a Google Apps domain -- if I was there as a TA or student now, I'd probably spend all day hacking on Google data APIs and App Engine to make cool apps for classes and clubs, and trying to get my classmates to join the fun.

Anyway, it was great to see how USYD is using our APIs across both their classes and research. Let me know if your university is up to anything similar! :)

Putting Europopped on the Map

2010-09-03T16:22:00.001-07:00

After spending 3 years of my life making Maps API mashups, I now have a bit of an addiction. Whenever I see geographic information, I have this uncontrollable urge to visualize that information on a map. So when I started reading Europopped.com, a blog that chronicles awesome and awful music videos from European countries, I also started imagining how I could show those blog posts on a map. Last night, between episodes of Arrested development and True Blood (a balanced TV diet), I realized my fantasies: Europopped: On the Map.

Here's a step-by-step of how the mashup works:

It uses the JavaScript Maps API v3 to create a map centered on Europe.
It queries the Posterous API to retrieve all the tags and tag counts for the blog.
It creates markers for each of the tags, using latitude/longitude coordinates stored in the JS, and showing the tag count on top of each marker.
When you click on a particular country marker, it queries the Posterous API for all the posts for that tag.
It creates a sidebar of links for each post, and setting a click listener that embeds the video for each post in the infowindow.

Here are some tips for how I made it quickly:

I used my Spreadsheets Geocoder wizard to get the coordinates for all of the countries, and used a spreadsheet formula to generate JSON from my geocoded spreadsheet.
I used getlatlon.com to find the ideal map center.
I used MapIconMaker Wizard to generate a template marker image URL for my markers, and passesd the tag count into that image URL to change the number for each country.
I used my CenterBox control class from another project to create a centered info box instead of the typical infowindow.
I used regexpal.com to test the regular expression that extracted the Youtube URLs.
I used my Posterous JSON API proxy for all of the API calls.

That's why I love APIs and the web -- once you're aware of them, they make it possible to quickly create new ways to use and explore the data and sites that you love.

Happy EuroPopping! :)

How to Pretty-Print Code Snippets in Blogger

2010-08-31T05:36:00.000-07:00

I often want to include snippets of code in my instructional blog posts, so to make my blog posts easier to read, I decided to add syntax-highlighting to my blog tonight. There are various syntax highlighting solutions out there, but we use google-code-prettify on code.google.com and it's worked well enough there, so I went with what I knew.

Here's how I added it to my Blogger blog:

Click the Design tab and "Edit HTML".

After the meta tab in the HTML, paste these two includes for the JS and CSS:

<link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css' rel='stylesheet' type='text/css'/>
<script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js' type='text/javascript'/>

Search for script - for me, there's a script tag near the bottom of the page. In that script tag, put this javascript call:
```
prettyPrint();
```
If that tag doesn't exist, then just create a script tag at the bottom yourself.
Now, whenever you're posting, add the prettyprint class to your pre or code tags:
```
<pre class="prettyprint">
var i = 2 + 4;
</pre>
```

To see examples of where I've used this, check out JSON API for Posterous for Python snippets or the Google APIs Timeline for JS snippets.

For more details on using the prettify library, see the readme.

A JSON API for Posterous

2010-08-30T16:51:00.001-07:00

I recently became mildly obsessed with Europopped.com, a blog that highlights both really catchy & horribly tacky music videos from all over Europe, and I've started thinking up mashups to fuel my obsession. So, I looked up the API for Posterous.com, the blogging platform that powers Europopped, and discovered that its API is not quite as mashup-friendly as I hoped. They do offer an API for retrieving public feeds without authentication -- the first thing I looked for -- but the API result output is a custom XML format -- not optimal for client-side mashups. I was expecting to find an API output that was either ATOM-based, so I could pipe it through existing Feed->JS proxies like the Google AJAX Feeds API, or even better, an API output in JSON with support for callback parameters. The documentation indicates the API is still under development, however, so hopefully they will soon go down one or both of those routes.

But in the meantime, I decided to remedy their lack of a JSON output with a quick App Engine app to proxy API requests, convert the XML to JSON, and return it.

First, the end result:

If I wanted to use the Posterous API to get the last 50 posts from the Europopped blog, I'd fetch this URL and it would return XML for each post:

http://posterous.com/api/readposts?hostname=europopped&num_posts=50

To use my proxied JSON API to get those 50 posts, I'd fetch this URL:

http://posterous-js.appspot.com/api/readposts?hostname=europopped&num_posts=50

Tip: Install the JSONView extension for Chrome to see the result pretty-printed.

Notice that the only difference is the domain name -- I wanted the proxied API to mirror the actual API as much as possible, to make it easy to figure out the URLs to construct from the documentation, and to make it easy to port to an actual JSON offering from Posterous in the future, on the assumption that actually happens. :)

If I want to get the same JSON wrapped in a callback, to use it inside a webpage, I'd fetch this URL:

http://posterous-js.appspot.com/api/readposts?hostname=europopped&num_posts=50&callback=loadPosts

Now, the code behind it:

I've checked in the two files it took to write the proxy on App Engine for Python, and I'll step through them here.

First, I set up a URL handler to direct all /api requests to my api.py script:

application: posterous-js
version: 1
runtime: python
api_version: 1
handlers:
- url: /api/.*
  script: api.py

Then, in api.py, I directed all requests to be handled by ApiHandler, a webapp.RequestHandler class.In that class, I reconstruct the URL for the Posterous API request:

  url = 'http://posterous.com' + self.request.path + '?' + self.request.query_string

Then I check memcache to see if I've already fetched that request recently (in last 5 minutes):

   cached_result = memcache.get(url)
    if cached_result:
      dict = simplejson.loads(cached_result)
    else:
      dict = self.convert_results(url)

If I didn't find it in cache, then I'll call a function to fetch the URL and convert specified top-level tags in the XML to JSON:

  result = urlfetch.fetch(url, deadline=10)
  if result.status_code == 200:
      dom = minidom.parseString(result.content)
      errors = dom.getElementsByTagName('err')
      if errors:
        dict = {'error': errors[0].getAttribute('msg')}
      elif url.find('readposts') > -1:
        dict = self.convert_dom(dom, 'post')
      elif url.find('gettags') > -1:
        dict = self.convert_dom(dom, 'tag')
      elif url.find('getsites') > -1:
        dict = self.convert_dom(dom, 'site')

I convert from XML to JSON using the minidom library, converting each tag to a JSON key and recording the text data or CDATA as the JSON value. This technique means that I don't actually convert any nested XML tags, but in the Posterous API, that only means that my output is missing the comments information for posts, which is the least interesting information for me.

 def convert_dom(self, dom, tag_name):
    dict = {}
    top_nodes = dom.getElementsByTagName(tag_name)
    nodes_list = []
    for top_node in top_nodes:
      child_dict = {}
      for child_node in top_node.childNodes:
        if child_node.nodeType != child_node.TEXT_NODE:
          child_dict[child_node.tagName] = child_node.firstChild.wholeText
      nodes_list.append(child_dict)
    dict[tag_name] = nodes_list
    return dict

Finally, after getting the JSON representing the API call, I output it to the screen with the appropriate mime-type and wrap it in a callback, if specified:

      json = simplejson.dumps(dict)
      memcache.set(url, json, 300)
      callback = self.request.get('callback')
      self.response.headers['Content-Type'] = 'application/json'
      if callback:
        self.response.out.write(callback + '(' + json + ')')
      else:
        self.response.out.write(json)

It's a quick hack and one that I hope to see replaced by the official Posterous API, but it's cool that it was so easy to do and now I can move on to actually making the Europopped mashup of my dreams. :)

Girl Develop It: Teaching Web Programming to Women

2010-08-29T18:17:00.001-07:00

A few months ago, Sara Chipps and I ended up on the same list of "Hacker Women on Twitter", and I followed the link from her bio to the Girl Develop it (GDI) project. The mission of GDI is to lessen the gender gap on the web by getting more women to develop software, and they're going about that by offering low-cost web programming courses to women in their local area (New York City). Some of those women might become web developers themselves, but even if most of them don't, they will hopefully inspire the women around them (like daughters and friends) to think about going down that road. Of all the various attempts to get more girls in computing, this one is my favorite. It may take time -- it may even take generations -- but it's worth a shot.

So, I'm bringing GDI to Sydney, and kickstarting it with an introductory series on HTML & CSS, which will take place in 5 classes over 3 weeks at our local Google office. The series will be run like an actual course, in that students are expected to attend every class, to do homework, and to do a small final project (a personal website).

I'm currently in the midst of creating the curriculum, using my HTML5-based slides making application, and am hoping to make it fun, practical, and re-usable. :)

Here's where you come in:

If you're a local female looking to learn those topics, then you can read more and register from the GDI Sydney page.
If you're a local female that's keen to help others learn these topics, then we'd love to have you as a teaching assistant for the course. Just send me an email or wave (pamela.fox@).
If you're just curious to see how it goes, then subscribe to the main GDI blog.

Thanks so much to Sara for supporting the Sydney version of GDI. I'm excited to see how this goes and to meet the first class of students!

Importing data from Spreadsheets to App Engine

2010-08-25T21:55:00.001-07:00

Google App Engine provides the remote_api mechanism for uploading and downloading data from the datastore. It's handy and lets you import different types of data, but requires a certain amount of setup, and well, sometimes I'm lazy and don't feel like going through that setup. So, another way that you can easily import data into your datastore is to store it in a Google spreadsheet, publish the sheet, and write a handler to import the spreadsheet rows as datastore entities.

For example, I created a spreadsheet to store information on Wave extensions, using one column for the URL and another column to indicate if they're featured or not.

Then, I published that spreadsheet using the Share->Publish menu, and constructed a URL for the JSON database-like output:

https://spreadsheets.google.com/feeds/list/0Ah0xU81penP1dDNwSFROSU5KVlFRbmo5cERsTElKTGc/od6/public/values?alt=json

To get the URL for your own public spreadsheet, just change the spreadsheet key (the long string there) and the worksheet ID (the first sheet is always 'od6').

That JSON includes an array of entry objects, and each entry object contains an object for each of the columns, e.g.

[...
 gsx$url: {$t: "http://api.rucksack.com/hostelwithme.xml"},
 gsx$featured: {$t: "yes"}
..]

Note: Column headers are stripped of whitespace and lowercased when converted to keys in the JSON feed, so I always just start off with them that way in the spreadsheet to make it painless to find them in the JSON.

Now, I write a simple handler that will pull in that JSON, parse each entry object, and convert them into datastore entities.

class ImportAppsActionHandler(BaseHandler):
 """ Handler for importing existing apps."""

 def get(self):
   user = users.get_current_user()
   # Need admin access to import
   if not user.is_current_user_admin():
     self.error(403)
   # Fetch JSON of published spreadsheet
   url = "http://spreadsheets.google.com/feeds/list/0Ah0xU81penP1dDNwSFROSU5KVlFRbmo5cERsTElKTGc/od6/public/values?alt=json"
   result = urlfetch.fetch(url)
   if result.status_code == 200:
     feed_obj = simplejson.loads(result.content)
     if "feed" in feed_obj:
       entries = feed_obj["feed"]["entry"]
       # Make an Application entity for each entry in feed
       for entry in entries:
         url = entry['gsx$url']['$t']
         featured = entry['gsx$featured']['$t']
         app = models.Application()
         app.url = url
         app.moderation_status = models.Application.MOD_APPROVED
         app.AddAuthor(user)
         app.AddMetadata()
         app.put()

   # Clear the memcache
   memcache.flush_all()

When I visit that handler, it imports the data, and works both on the local devapp server and the public server in the same way.

There are various caveats to this technique, of course. First, your spreadsheet needs to be published. If you wanted to do it with a private spreadsheet, for more sensitive data, you would need to use the full spreadsheets API and do an authentication dance. Second, your handler is limited to the typical 30 seconds limit for an App Engine request. If you wanted to use it to import many rows of data, you'd probably want to split it up across multiple requests by using the deferred task queue or re-directing with pagination.

But, hey, it was useful for my situation, so maybe it's useful for one more situation out there in the world. :)

Tip for Networking at Conferences: Be a Speaker!

2010-08-24T14:13:00.001-07:00

Most people don't realize it, but I am incredibly shy -- they don't realize it because I've also spent a long time being shy, and have developed various "workarounds" because I know that it's healthy for me to interact with people and that it's not healthy for me to be a hermit (though tempting).

One of the situations where I find it quite easy for my shy-ness to take over is at conference, where I'm surrounded by hundreds of people that I don't know, and I think perhaps that some of them would be interesting conversational partners, but I haven't the slightest idea who, and how to approach them.

So, I work around it -- by being a speaker. By speaking at a conference, I make it so that there is atleast a room full of people that now have an excuse to talk to me, and I have something to talk with them about. That's a room-full more of people than when I was wandering around aimlessly through the halls before the talk!

Now, I know, it's not possible to be a speaker at every conference you go to. But, many conferences (atleast the cool ones) offer lightning talk sessions which can be signed-up for on the day of the event -- and many people have atleast one interesting or funny topic they can talk about for 5 minutes.

Whether you're a pre-slotted speaker or a lightning talk speaker, try to get your speaking slot on the first day. First, of course, that will mean you'll be able to relax after your talk and enjoy more of the conference, and second, that means that the room-ful of people will know of you sooner, and have more time to strike up a conversation with you.

And, hey, if any of you ever see me wandering around a conference (or sneaking into a bathroom to hide from all the intimidating people), stop by and say "hi". :)

5lide: HTML5-based Slides Maker

2010-08-22T17:14:00.001-07:00

At last week's GTUG campout, a 3-day long HTML5 hackathon, I signed up to be a TA for the weekend. That meant I spent most of my time wandering around answering random questions and helping developers debug their hacks. But, I can't be surrounded by a bunch of people hacking on cool shit and not join in myself -- it's just way too tempting. So, on Friday night, after coming home from the pitches and discovering that drinking 2 Dr. Pepper's was not in fact a good way to avoid jet lag, I stayed up into the wee hours hacking on an idea I'd been brewing for a few weeks.

As some of you know from my posts about Prezi and Ignite, I am a fan of alternative slide formats and presentation techniques. In my work as both a student and a developer advocate, I have made a massive number of Powerpoint presentations, and I do believe there is much room for improvement and room for experimentation. So, whenever I spot a new slide format in the wild, I get excited to try it out myself.

Early last year, the HTML5 advocates started using a set of slides that both showed off HTML5 features and were written in HTML5 - so they could do interactive samples and harness the power of HTML5 at the same time. (And by HTML5, I mostly mean rounded corners and CSS transitions :). They recently created a generic stripped-down version for anyone to modify and use in the HTML5 studio, but I wanted to take it a step further than that. I wanted to be able to store my slide data in a database and pull that into the slides template dynamically, so that I could work on my slide content separate from my presentation and easily create multiple slidesets without coding the base HTML each time. Thus began my hack!

Since I had limited time to work on the app, I looked around for a sample application to start off with. One of the things I love about App Engine (well, atleast the Python version) is that when I find an open-sourced app similar to the one in my head, I can get it downloaded and deployed in just a few minutes. In the google-app-engine-samples project, I discovered the tasks app by the great Bret Taylor. The tasks app lets users sign in and create different task lists, where every list has a re-orderable set of tasks. The similarity to my app design was uncanny, and ridiculously convenient. With some simple search and replace, the tasks app became a slides app, letting users create different slide sets, where every slide set has a re-orderable set of slides. (See what I mean?) Then I added the more slide-oriented features: I turned the generic HTML5 slide deck into a django template that pulled in the data, I added a "theme" option for each slide deck and used a different CSS for each theme ("party", "ballerina", and "android"), and I created a notion of a slide type for each slide (either the intro, transition, or body).

I demoed the app in this form on demo night, and as usual, I haven't had time to add anything else to it since then. I'd like to add an "import from docs" as the next feature, as I have a few slidesets I want to bring over. I also think the slide editing interface could use some love and re-thinking, as it's really just a re-skinned task list editing interface right now. I have open-sourced all of the code here, as I'd love for other people to play around with it and maybe submit some patches (hint hint).

Happy 5lide-ing! :)

Google APIs Timeline: Behind the Scenes

2010-08-22T05:43:00.000-07:00

As part of my recent series of talks on the landscape of the Google APIs, I started off with a timeline showing the history of our APIs, from just 10 APIs in 2005 to over 80 now, with many launches and a few deprecations along the way. That timeline, appropriately, is itself a quick mashup of our APIs, and I thought I'd spend a few minutes talking about how I made it here.

First, I needed the data on our APIs over time. Unfortunately, we don't offer an API for querying our API existence over time (as awesomely meta as that would be), so I had to go the painstakingly manual route. I used the Internet Wayback Machine, a website that lets you view cached versions of other websites at various times. We launched code.google.com in March 2005 (and by we, I mean Chris Dibona), and the machine cached many versions since that first version. By looking at a combination of the listings on the apis.html page and the launch announcements on the front page, I could figure out roughly which APIs we introduced when.

Next, I needed a place to store that data. Well, as some of you know, I'm a massive fan of using Google Spreadsheets as a lightweight database, so I created a worksheet with a few columns (date, APIs added) and filled that in as I browsed the code.google.com of yore (and got a bit nostalgic along the way).

Finally, I wanted to visualize the data in a cool way. I had used the Annotated Timeline from Google Chart Tools for the Wave Visualizer mashup last month, and I figured this was another good use of it. It's the same timeline that's used by Google Finance to show stock trends compared to news stories, and similar to the timeline used by Google Trends. Though the timeline itself is a Flash SWF, it is exposed via a Javascript API.

Now, to put it together, I just needed to pull in the spreadsheets data and feed that into the timeline.

I brought in the spreadsheets data using the JSONP technique, dynamically appending a script tag with the src attribute set to the JSON output of the spreadsheets API, and specifying a callback function to be passed the JSON data. Note that I used the "values" projection for the feed, as that treats the worksheet as a database and returns the named columns as values in the JSON.

function appendSpreadsheet() {
  var script = document.createElement('script');
  script.src = 'http://spreadsheets.google.com/feeds/list/0Ah0xU81penP1dE1TNnpscHdYYU5qSU5GZldLM1VMMVE/od6/public/values?alt=json-in-script&callback=onSpreadsheetLoad';
  document.body.appendChild(script);
}

In the callback function, I parse through the rows of the spreadsheets feed and add them as rows to a DataTable object. I then create the AnnotatedTimeline object and ask it to draw that data.

 function onSpreadsheetLoad(json) {
  var rows = json.feed.entry || [];
  var data = new google.visualization.DataTable();
  data.addColumn('date', 'Date');
  data.addColumn('number', 'Total APIs');
  data.addColumn('string', 'Changes');
  data.addRows(rows.length);
        
  for (var i = 0; i < rows.length; i++) {
    var row = rows[i];
    var year = parseInt(row['gsx$year']['$t']);
    var month = parseInt(row['gsx$month']['$t']);
    var day = parseInt(row['gsx$day']['$t']);
    var total = parseFloat(row['gsx$apitotal']['$t']);
    var info = row['gsx$info']['$t'];
    data.setValue(i, 0, new Date(year, month, day));
    data.setValue(i, 1, total);
    data.setValue(i, 2, info);
  }
        
  var annotatedtimeline = new google.visualization.AnnotatedTimeLine(
     document.getElementById('visualization'));
  annotatedtimeline.draw(data, {'displayAnnotations': true});
}

And with that (and some fiddling with the timeline options), I had an interactive timeline:

It's a pretty simple mashup that only took a few hours to put together (99% of which was data collection), and an example of how you can easily combine a couple of our APIs in interesting ways. Happy mashing! :)

Android Painting Apps: A Review

2010-08-09T10:54:00.000-07:00

Here is my preliminary review of 3 painting apps designed for the Android platform. Please suggest other ones or other opinions on these.

Note: I am not a professional artist, just an amateur doodler. :)

Differentiating Features:

Paint Stroke Texture: Every app seems to implement their own stroking mechanism, so texture varies - and is important.
Brush Size Picker: It's nice if you can quickly change/toggle sizes. You cycle through a lot of brush sizes when painting.
Color Picker: It's important that you can pick shades of colors, like a human flesh tone.
Undo/Redo: It's very easy to make mistakes while using a clunky finger on a small screen, so having an undo is essential to refining paintings.
Import (load from gallery): If you can bring in existing pictures from the gallery, then you can fork your previous paintings or paint on top of photos (like drawing moustaches on your colleagues).
Export (save to gallery): You always want to be able to save your paintings out, so you can keep an archive of them, tweet them, save them to your online photo albums, etc.

FingerPaint Pro

Paint Stroke: Each stroke has a highlight + a shadow to it, like it's really a 3-dimensional stroke. It makes an interesting effect, but also makes it hard to do large blocks of color. I like the challenge of that though.
Brush Size Picker: A nice UI that cycles between sizes with a single tap.
Color Picker: A full H/S/V color picker with every color possible.
Undo/Redo: Not supported.
Import: Supported.
Export: Supported.
Conclusion: I find this paint texture so fascinating that I find myself using this the most. If this app implemented undo/redo, an eye dropper tool, and perhaps a bit of flexibility with the texture (to enable solid blobs of color), then it would really be my favorite app.

Examples:

Eye of the Mummy

Ice Cream in the Sky

Kids Paint App

Paint Stroke: Each stroke is of a random thickness and color.
Brush Size Picker: Not supported.
Color Picker: Not supported.
Undo/Redo: Not supported.
Import: Not supported.
Export: Supported.
Conclusion: It is cute to play with, and it is interesting to see what one comes up with, but it will be frustrating for anyone with a particular goal in mind. (And I think most people acquire a goal after fiddling for a while, and a sudden change in stroke color can so easily squash goals here). I admire the different take, though.

Example:

Eye

Magic Marker

Paint Stroke: Each stroke is actually white, with a colored glow around it (for a neon effect).
Brush Size Picker: Clicking on the current brush size pops up other sizes to pick from.
Color Picker: 8 swatches and a basic wheel. Shades not supported.
Undo/Redo: Supported.
Import: Supported.
Export: Supported.
Conclusion: This app has a specific type of artistry in mind, and it delivers all the basic features needed to make the artists experience a good one. It would be great to see some additional pizazz in the future- like sparkles or brush shapes - but this is a great start for a unique vision.

Example:

Magic Mercure

DoodleDroid

Paint Stroke: You can pick a variety of different textures, and some of them produce a nice effect of varying thickness.
Brush Size Picker: The stroke adjustment dialog lets you pick a "base width" and "tip width", as well as a transparency.
Color Picker: You can basically pick any color ever, using two different types of pickers. You can also use an eyedrop tool to pick an existing color from the app.
Undo/Redo: Not supported. :(
Import: Supported.
Export: Supported.
Conclusion: This app is probably the best painting app, because you have so much flexibility in the paint stroke, from texture to color, and with enough layers and patience, you can create some quite detailed paintings. The huge missing feature is the Undo, and with the absence of that, it's hard to go from a good painting to a great painting.

Alan

How to pick & prepare an Ignite talk

2010-08-08T21:08:00.001-07:00

I am now somewhat of an Ignite veteran. I've given talks at multiple Ignites, including Ignite Spatial (for GIS folks) and Google I/O Ignite (for hard core developers). I don't necessarily give the best talk, but I usually give a talk that goes over well. So, I thought I'd share my personal technique for creating an Ignite talk, as it can be a bit different from typical talks.

When I think of a topic for an Ignite talk, I look for one with the following characteristics:

Something that mixes humor, inspiration, information
Something I'm personally passionate about
Something that tells a story or has a narrative

Then, once I've decided the topic, I need to actually create the talk. I typically take these steps:

Spend a week simply thinking about the topic, hearing yourself talk about it in my head. It's a great way to spend the morning commute, and a great way to make sure that the flow of the talk will be natural once it's down on paper.
Create a text document. I usually draft in Wave these days, so that I can share it with my friend and ask for comments, but otherwise any old editor will do - some folks even use real-life things like post-its. The important thing is that it should be a format that allows you to iterate easily.
Write down a list of all the bits of information you potentially want to communicate, and order them according to what feels natural.
See if you are at or around 20 bits of information, where a bit is about 2-3 sentences (you may want to time yourself to see what your personal pace of communication is, and calibrate that #). If you have too many, think about what point to cut, or what details to leave. If you have too little, think about what else you might communicate - maybe more backstory, a calls to action, or an anecdote.
Say this talk to yourself. Say it to a friend. See if it feels natural, that everything transitions together, and that it's similar to the way you might spontaneously tell these bits of information. That will make it easier to deliver.
Start thinking about the visualization of your information bits. If you've got 5 bits in a row that you have no idea how to visualize, you may want to re-think those bits. Eventually, each bit will need a picture.
Keep playing around with the talk, moving bits of information around, moving them in and out, until you get to a point where it just feels right, and you're at the right # of slides.
Create a powerpoint (or keynote) presentation.
Insert a text box on each slide that contains the text for that slide. Position it below the slides.
Start filling in the visuals. They might be photos that you've taken, images from the web (like iStockPhoto or CC-licensed Flickr pics), or hand-drawn doodles. Try and make them be something that jives with the audience, but also jives your memory about the content of the slide.
Add short headers to each slide, if you want. Position them near the top of the slide, as the bottom is often hard for the audience to see. Try to avoid adding any text besides a header -- you don't want to distract audience members from what you're saying, and you don't want to make them feel they're reading off your talk.
Move the slide text up to the bottom of the slide.
Set the animation settings for auto-advance every 15 seconds.
Start practicing the talk. Since the slide text is visible, you get to view the text while practicing. After each practice, go back and make any tweaks to the text, change anything that didn't feel right, went too long, etc.
Once you feel comfortable, move the slide text below the slides, and practice the talk that way multiple times. This is the test that most nearly mimics the actual event characteristics.
Create a text document with all of your slide text, and print it out. You can now carry it around and practice it to yourself when you have the chance, like at the bathroom at the venue. :)
Go to Ignite! Drink water. Give the talk. Be excited.

Create a version of the slides that's consumable by non-Ignite attendees by moving the slide text box back onto the bottom of the slides. Upload it to Scribd, Slideshare, Google docs, and share it on Twitter, Facebook, etc. People love to read through these short slidesets, and with the transcript pasted on, the slides will actually make sense.

My past Ignite talks:

A World of Words

Collaborative Mapping with Google Wave

I'm a Barbie Girl in a CS World (or watch the video)

Why I Like Prezi

2010-08-06T08:17:00.000-07:00

In my life, I have given a *lot* of presentations. In high school, they were presentations on group projects. In university, they were presentations on research projects. At Google, they're presentations on how to use our APIs. When I first started giving presentations, I used Powerpoint, like everyone else. But I kept thinking there must be a better way, and I experimented with other options - flash interfaces, interactive Javascript apps. Then I discovered Prezi, and it has become my presentation tool of choice.

Prezi is an online tool for creating presentations — but it's not just a Powerpoint clone, like the Zoho or Google offering. When you first create a Prezi, you're greeted with a blank canvas and a small toolbox. You can write text, insert images, and draw arrows. You can draw frames (visible or hidden) around bits of content, and then you can define a path from one frame to the next frame. That path is your presentation. It's like being able to draw your thoughts on a whiteboard, and then instructing a camera where to go and what to zoom into. It's a simple idea, but I love it. Here's why:

It forces me to "shape" my presentation. A slide deck is always linear in form, with no obvious structure of ideas inside of it. Each of my Prezis has a structure, and each structure is different. The structure is visual, but it supports a conceptual structure. One structure might be 3 main ideas, with rows of ideas for each one. Another might be 1 main idea, with a circular branching of subideas. Having a structure helps me to have more of a point to my presentations, and to realize the core ideas of them.
It makes it easy to go from brainstorming stage to presentation stage, all in the same tool. I can write a bunch of thoughts, insert some images, and easily move them around, cluster them, re-order them, etc. I can figure out the structure of my presentation by looking at what I have laid out, and seeing how they fit together. Some people do this process with post-its, but I like being able to do it with a digital canvas.
It works well for explaining concepts that make more sense with a diagram, because you can basically make your entire presentation be the diagram — and then you can just fly around that diagram, pointing out the flow and zooming into the important bits. For example, I used pseudo diagrams inside the robots API and gadgets API prezis to explain the API <-> server interaction.

Prezi isn't perfect, of course. I've made several feature requests, and have a list of others. There are the small requests, like wanting higher quality images and a code style for embedded snippets, and there are also the big picture requests. I want to be able to link prezis inside of prezis, so that I can make "components" of presentations, and easily zoom from one to the other. I want to be able to create multiple paths for a given prezi, so that I can skip over bits for some audiences, and emphasize them for others. Hell, I'd love if I could have one canvas that had every bit of possible content on a topic, and I could use that one canvas for 20 different presentations. I don't know that Prezi will ever implement these ideas, but I have more faith in them doing so than any other presentation tool, since they are making a point of thinking different.

Generally, I just love the fact that somebody is thinking different about presentation tools. There are so many people out there that are giving presentations every day, so as a society, we owe it to ourselves to invest more thought into how we do presentations. That's why I also like events like Ignite and Webjam, because they are challenging people to rethink the timing aspect of presentations.

(Not to talk about Wave all the time, but—)

My love for Prezi is similar to my love for Wave. Prezi is re-thinking presentations. Wave is re-thinking communication. Prezi gives me a blank canvas that can turn into a presentation of any shape. Wave gives me a blank wave that can turn into a document or conversation of any structure. Both of them are unfinished, but both have a bright future, and even if they don't succeed, they're successfully challenging the traditions of today.

How-to: 80s-ify your geek shirt!

2010-07-23T18:31:00.001-07:00

I've created my first "instructable" on the technique I use for modding my t-shirts. Check it out here!

Sydney MCA: Notable Artists

2010-07-18T04:07:00.000-07:00

GTUG Campout: A weekend of HTML5 in 11+ Cities!

2010-07-14T06:25:00.000-07:00

To quote the organizer:

"GTUG Campout is an annual weekend-long event where Google Technology User Group members have an opportunity to design, develop, and demo a complete application over the course of three days. This year, the theme will be HTML5. The event kicks off on Friday, August 13th, where ideas and teams will come together. Teams will then have the rest of the weekend to build their HTML5 applications before presenting their work to the public on Sunday evening."

The campout is so far scheduled to happen in GTUGs in 11 cities:

I will be in the bay area around that time anyway, so I'm going to join in on the SF Bay meetup. As I've done other hacking weekends and seen Wave is pretty useful for these kind of things, I'm going to put together a Wave-based forum and team wikis for the weekend. If you're participating in the campout, stay tuned for details on those!

Hacking weekends are always a lot of fun, and HTML5 is freaking awesome, so I encourage you to join at the city nearest you, or hey, just reserve that weekend for hacking and join in virtually!

Developer Relations Explained (The Nerdy Way)

2009-11-12T14:06:00.000-08:00

I often find it hard to answer the question, "So, what do you do at Google?" I find it hardest when that question is asked by someone completely outside the tech field, like a face-painter or a taxi driver, but it is hard even to explain to techies. It's not as simple as saying that I'm a tester, a software engineer, a product manager, or a support staff, because it's a crazy awesome combination of all the above. I'm in developer relations, and there are an awful lot of ways to relate to developers. We write articles and blog posts, create sample code and one-off projects, maintain open-source projects, respond to forum posts, triage bugs, speak at conferences, meet with partners, and generally do what needs to get done.

One way of explaining our various roles in developer relations is to break it down into two parts: first, the type of developers that we support, and second, the particular developer product(s) that we support. For example, I generally support long-tail developers, and I supported the Maps APIs for the first 3 years, and now I'm supporting the Wave APIs. Some of my colleagues support our higher-touch partners or even our paying customers, and their role involves more 1-on-1 meetings and emails. You can play with the little app below to experiment with more configurations of products and developer types:

Currently, in developer relations, we have one of two specific titles: "Developer Programs Engineer" and "Developer Advocate". Basically, the DPE supports the long-tail and the DA supports the high-touch partners. It doesn't really split as even as that in reality, but that's the basic idea.

So, that brings me to the real reason for this post. We are now hiring DPEs and DAs. The jobs site only lists positions for Mountain View and New York, but there are also scattered positions around the world, in places like Australia, China, and India. It's a fun challenge to figure out how best to relate to developers using our growing number of developer products (including the just-released Go language), and we can always benefit from having a broad range of opinions and skills represented on our team. If you're interested, apply! :)

Being a Girl in CS Doesn't Suck

2009-10-28T05:39:00.000-07:00

When I posted last week about an experience with gender bias in "Should I Defend My Cred?", some of the re-tweets basically implied that post was proof that it sucks being a girl in CS. Well, I want to clarify that it doesn't suck. It's actually pretty freaking awesome.

What rocks:

Working with mostly guys.
I'm sorry, girls, but I've always gotten along better with guys, ever since I was in elementary school. It's probably because I didn't quite fit into the girl mold (or any mold) back then, and thus girls were hesitant to accept me, while guys didn't really care as long as I was willing to shoot cannons with them. I know a lot of other girls in CS who say the same thing - that they're mostly friends with guys - and actually, those are the girls that I get along with best. So, yes, I should learn how to get along better with girls. But in the meantime, I'll always feel more comfortable working with guys.
"Working" with mostly guys.
I once famously said "I only date guys who program in derivatives of ECMAScript". Well, it's kind of true. I prefer dating guys in tech because I have more stuff to talk about with them, so it's pretty handy that the tech industry is mostly guys. And yes, there is a bit of truth in the phrase often applied to guys in CS: "The goods are odd, but the odds are good"...but I'm pretty sure that the ratio of good guys is still in my favour. It's nice to be in an industry where I constantly encounter so many potential mates, and I don't have to rely on meeting random guys in a bar (which appears to be the dating preference of choice amongst adults, ick).
Being recognizable.
As a girl amidst a sea of guys, I'm pretty easy to find. At a conference, all someone has to say is "find the girl with the red|blue|pink hair", and they can make a positive match pretty quickly. This easy recognition means that I can connect with more of the developers that want to talk to me. It can sometimes cause problems when people remember me better than I remember them (there's a limit to the number of white guys I can store in my head at once), but they are usually quite forgiving.
Getting more opportunities.
Okay, I'm still not 100% sure how I feel about affirmative action.. except that I bet it's worked for me, and that I've probably benefited greatly from it. I remember asking my high school English teacher to review my college essay (which revolved around toilet flushing), and he glanced it over and said, "Well, you're applying as a girl in CS with a high SAT score, right? This shouldn't matter much."
When an employer or university is comparing 2 equally skilled people, it makes sense that they select the one that increases the diversity of their staff/student body/conference/etc. Diversity is a good thing for teams, and it just so happens that the easiest way to measure diversity is by looking at aspects like race or gender. Theoretically, affirmative action could also applied be to hobbies and interests, and I could be selected due to my intense passion for 80s music (which actually does come up surprisingly often in my talks and demos). Until that happens, I will take advantage of the opportunities that I get by being a girl, and trust that I am not being given opportunities that I don't deserve.

What sucks:

Not enough chick flicks.
I'm pretty sure I would have more excuses to watch romantic comedies if I hung out with more girls. But oh well, I'll just schedule a few more 12 hour trans-pacific flights.
Too little dancing.
Guys don't generally go out dancing as their night activity of choice, at least not guys in western cultures. They tend to prefer a night of tipsy talk at a pub. I sometimes wish that I was a rock star or celebrity, and got to spend every night clubbing in exotic places... but until I acquire any sort of stage talent whatsoever, I think I'll settle with tricking guys into going to pubs with good music.

What really sucks:

Being afraid to admit all that.
As a girl in CS, I am meant to have a very particular opinion about girls in CS. I feel that I risk being viewed as a traitor if I express other opinions. So, I generally try not to express any at all, and just go on my merry way. But, I now worry that other girls may feel the same fear, and that it is cowardly of me to keep my opinions to myself. Now, it's up to you to express your opinions, whatever they may be.

Joomla & Google Wave: The Possibilities

2009-10-21T17:17:00.000-07:00

Last weekend, I presented a talk on Google Wave to Joomla Day Sydney, and then proposed various ways that Joomla and and the Wave APIs could be used together. I've summarized them below, and would love to hear ideas from Joomla developers on other types of integration.

Using Wave to Produce Joomla Content

Embedded Waves

You might decide that instead of static HTML for a particular article, you want to embed a Wave and enable real-time collaboration. An enterprising developer has already written a Joomla plugin that uses the Embed API and makes it easy to embed Waves in articles, so you can use that.

For example, I can create a Wave with the content of the Joomla Day home page:

Then, in my Joomla instance, I can install the plugin and insert this code in an article:

{googlewave srv=http://wave.google.com/a/wavesandbox.com/|id=wavesandbox.com!w+FspA8QgYA|width=100%|height=600px|fsize=12px|bg=#FFF|ffamily=Georgia}

And then it would produce a page like this:

Note: Only people with accounts for the embedded server will be able to view the Wave, and only if they are a participant or the Wave is public to that whole server. In the future, we hope to allow for another type of public waves that can be viewed anonymously.

You may be creeped out by the idea of anyone being able to edit the Wave, and maybe you don't really want a full conversation on the page. That brings us to the second option.

Exported Waves

If you want to use the collaborative nature of Wave to create your articles, but then still use static HTML for your articles, then you could write a robot to export from Wave into Joomla or a Joomla-compatible format.

For example, the Exporty bot listens for changes in a blip, extracts the contents of the root blip, and stores it in its App Engine datastore. Then, it renders that as HTML at a URL, and when someone requests that HTML, it displays the blip if its Wave was public, and otherwise it asks the user to sign in and checks if they are a participant of the Wave.

So, I can create a Wave with the content of the article, add the co-authors, and then add Exporty-bot:

Then I can create an iframe pointing at the HTML in my article content:

<iframe src="http://exporty-bot.appspot.com/export?waveId=wavesandbox.com!w%252B7w-1O4JSA" width="100%" height="700" frameborder="0"></iframe>

And then it would produce a page like this:

A more elegant solution would involve eliminating the iframe and baking the content into the page. But I will leave it to someone more experienced with Joomla to figure out best way to do that.

Using Wave to Extract Joomla Content

Using robots and gadgets, you can find ways to bring in content from your Joomla site.

For example, a user of your site could use Wave to subscribe to changes in the site. The RSSy bot lets you specify an RSS feed and updates the Wave with blips for each new item in the feed.

So, you can create a new wave, add RSSybot, and specify the RSS from a Joomla site:

The resulting Wave looks like this:

This bot doesn't do the best job at handling the HTML in the feed, but you could improve that to insert iframes with the HTML, or convert the HTML into a Wave-compatible block of text with annotations for the styles.

Should I Defend My Cred? (...Yes)

2009-10-21T08:23:00.001-07:00

Tonight, I gave another Ignite talk on "Google Wave & Collaborative Mapping"/. The talk went well, and it was a great opportunity to hear what other people are thinking of doing with Wave. But, something interesting happened after...

I was asked by a speaker to basically defend my cred- as he looked at my appearance (a short green skirt & t-shirt), saw that I gave a presentation that glossed over the technical details, and assumed that I wasn't that technical. When I explained to him that I actually do write code, he was fairly taken aback. He then recommended that I start off each presentation by clarifying my level of knowledge, and getting "respect" from the audience. His basic theory is that girls are not respected as technical peers until they sufficiently prove themselves, and apparently, particularly not if the girl is decent looking. Now, I want to explore that theory further (outside of the noisiness and distractions of the crowded pub).

When I was in high school, I participated in MUN (Model United Nations), where high schoolers would be delegates for a particular country and argue position papers. At the conferences, I remember that I myself mentally discounted the ability of the female delegates when they went up to speak. I was willing to believe in them, but only after they really showed their stuff. I didn't have this same feeling with the guys, and I came to the conclusion that there are some areas where one gender garners more of an immediate respect than others. I decided then that I would have to come off as incredibly confident (but not bitchily so) in order to win the respect of the MUN people, as I assumed that they would have that same accidental bias. The bias made sense to me in the area of speaking - men naturally have deep, confident voices, and so you just want to believe in that voice. I don't know how to describe women's voices, but it's certainly not like that.

I think the respect bias may extend beyond debating in the tech world, however. When I look at the Twitter account for a self-professed "girl geek", I grow immediately suspicious of their geeky claims. When I see a girl go up to present on the stage, I usually assume they will talk about something less technical. Maybe this is because my suspicions are usually confirmed -- because we live in a world where we try to extend a geek label as far wide as possible, to try and sneakily get more girls "in CS." Maybe it's because girls naturally hate girls (a well documented phenomenom in women's magazines), and this is an extension of the phenomenon.

So, I'm biased, he's biased, and potentially others are as well. I don't know that we'll be able to eliminate our subconcious tendencies, but we can help people squash their own.

When you give a talk, always start off with an introduction slide that describes your background and experience. If you're an expert on the topic, admit it (humbly). If you're just learning and wanted to share your learnings, admit it.

I think part of the reason that we try to rely on other (possibly incorrect) clues to help us form opinions is that people don't give us enough information about their credentials. And I don't think that we mind if someone is or isn't technical - we just want to know, one way or the other, and not feel like we're being misled. We respect people for who they are, but we don't respect people if we suspect that they're trying to be something they're not.

Thoughts welcome, of course. :)

Why I Sent You to a Group

2009-10-13T15:59:00.000-07:00

One aspect of my role as an API support engineer is making sure that developer's questions are answered.

So, when a developer personally emails me a question, you would think that I would rush to answer it.

No. In fact, I usually ask them to post their question in the relevant group, and even if I know the answer to the question, I do not reveal it in my response.

This is because another aspect of my role is making sure that developer's questions are answered in a scalable manner.

If a developers emails me a question and I then answer it, that question and answer exist only inside our inboxes. They are absolutely undiscoverable by anyone else in the world, and basically useless to 99.9999999999999% of developers. However, if a developer posts a question in a forum and then receives an answer, that thread exists in the public group, it exists in the cached Google pages, it exists in the mail group archives - and most importantly, it exists in Google search results. That means that when another developer has the same question and search for it, they will find an answer - without even having to post their question. So, potentially 100% of developers can benefit from the question and answer. Now, *that* is scalable.

Now, a developer might think "But, I'm the only one with this question." This is nearly almost not the case, and it is not something that a developer can predict. Better safe than sorry, and share the question with the world.

Another aspect of my role is making sure that questions are answered in a timely manner.

If a developer emails me a question, and I happen to be quite busy then - with conferences, travel, launches, etc. - then I may not be able to respond for a few weeks. However, if a developer posts that question in the group, all of the group members may see it, and the chances are that atleast one of them know the answer and happen to have the time to respond. If they post in the group and don't get a response after a few days, it is fine protocol to ping the thread nicely, or hey, I don't even mind when a developer pings me personally and asks me to respond to the group thread.

So, oftentimes, when I ask a developer to post in a group, it's because I want them to get an answer faster than I can provide, and I happen to know that the Group is the best way to guarantee that.

Basically, the only times that I *happily* respond to a one-on-one email (or wave) is when the matter concerns personal account information and must be worked out on a case-by-case basis - for example, requests for higher geocoding limits, or the recent problems with some sandbox users not getting wave preview invites.

If you are a developer that I have sent to a group, please understand it is for your own good and the good of the world. Thanks for understanding!

A World of Words.. And Me

2009-10-08T05:54:00.000-07:00

Tonight, I gave a talk titled "A world of words" at Ignite Sydney, and I want to give a bit more information about why I gave that talk.

As I said at the beginning of the talk, I have always had a thing for words. When I was a wee lass, I had a favorite song called "Great Big Words" and loved to finish crossword puzzles. In high school, I realized that I needed to study words in order to do well on the SATs, and I could get away with more word geekery that way. I downloaded multiple flashcard programs on my PC, and I forced friends in my carpool to bring in words to discuss during each morning ride. Needless to say, I aced my test... and I was also no longer part of that carpool. Then, in university, I joined an honor society and suggested that we educate our peers by plastering the kiosks with "Word of the Week" posters. On each poster, I took great pleasure in coming up with a ridiculous sentence that used the word, and an overlay thorough description of its etymology. (See: poster for "diaphanous")

So, I realized I had an obsession, and I needed to make it legit. I enrolled in a linguistics minor, and I was hooked. Everything about language was fascinating - why we make the sounds we do, why our sentences can become ambiguous, even stuff like why we can say "abso-fucking-lotely" and not "ab-fucking-solutely" (seriously, that was covered in two classes). Inspired by my newfound knowledge, I applied for and was accepted into the John Hopkins Computational Linguistics summer workshop. There, I spent the summer working on a tool for visualizating the parse trees for sentences translated into multiple languages (See: screenshot).

That project got me thinking about the various ways that I could combine my computer science skills with my love for linguistics. I eventually concocted a project that would use both those, and my other minor, 3d animation, and convinced my advisors it was worthy of credit. It was entitled "A Computational Framework for Simulating Cross-Linguistic Acquisition of Spatial Prepositions", and it was basically an attempt to get a computer script to learn prepositions (above/under/on) by analyzing a 3d-scene and given sentences. And, hey, it kind of worked. (See: e-poster). I was on a roll!

So, I was at the point where I was trying to figure out what was next in life. I knew what I loved, but couldn't decide what to do with what I loved. It was suggested that I apply for a Fulbright grant - a grant that would let me do research somewhere in the world - and I thought that was a mighty fine idea. I wrote up my proposal for an app that I had always fantasized about. It was called "A World Wide Web of Comparative Linguistics", and it would let user visualize and search through etymological history on a map-based interface. (See: proposal). In my opinion, the app would bring immediate world peace. How could you possibly fight with someone after you realized how connected your words were?

Unfortunately, the Fulbright committee didn't see it that way, and I didn't get a grant. I instead went on to get a Masters degree and get hired by Google, and that's where I am today. I've been pretty busy supporting the Maps API for the past 3 years, but lately, I've started craving a bit of linguistics in my life. I started listing to word-of-the-day podcasts on my iPod during my morning commute, and it just gets my brain all tingly.

So, I put together this talk as one way of satisfying that craving (or, more likely, making it much bigger), and also to share this bit of knowledge with others. It's a nice break from my typical web talks, and I think I surprised a few folks.

You can see the talk embedded below or on slideshare, complete with captions of what I actually said.

A World of Words

View more presentations from wuzziwug.

You can also watch the recorded talk below:

For more resources on the topic, you can check out the sites that I bookmarked while researching the talk, subscribe to the podictionary podcast, or start looking up words in the online etymology dictionary.

And, of course, stay tuned to the blog to find out if I do ever create that etymology visualization app.. It would be a damn nifty thing indeed, even if it didn't bring world peace. :)

How Google Wave Could Improve Education: Group Work

2009-09-10T17:34:00.000-07:00

Last night, at the Google Wave Sydney User Group, we brainstormed a lot of different ways that Google Wave could be used in a vast spectrum of fields. A recurrent theme was education, and we touched upon various ideas, and basically just agreed that Wave (and collaborative technology, generally) can have huge implications for education. One of those ideas we discussed was group projects, and I wanted to discuss that area in more detail here.

As a teacher, you often want to encourage group projects, since they can help students learn cooperation and teamwork, and since they can often have a synergistic effect and produce amazing results. But, there's always that same concern with group projects - someone will do all the work, someone will do none, and it's impossible to know who deserves the good grade. Well, Wave could potentially solve this, both in terms of knowing who to give credit to, and encouraging a better balance of work across group members.

Here's an example proposal based on my own experience:

You're a teacher running a game projects class, and you've divided the class into project teams for the semester. The first aspect of creating a game is writing a design doc for the game (describing gameplay, objective, characters, etc), and you make that the first assignment for each team. You create a Wave for each team that has the design doc template in it (headers), and you give them a week to work on it. You recommend that they use reply blips and inline blips to divy up the work, and tell them that you will be monitoring the project and will do a review of the first draft in a week, and grading of the final a week after that.

When you review, you reply in the Wave and comment on what parts need work or clarification, and which parts look good. When it comes time for grading, you use the playback functionality to see how everyone contributed. You see who took the lead and made decisions, who wrote up large sections, who revised sections for clarity, and who just sit back and watched. Now, hopefully, since every team member knows that you can see all the edits and attribute them to each of them, they will actually feel more motivation to contribute, and you won't have many students that just do nothing. But if you do, well, you can penalize them accordingly, and perhaps next time, they will learn that their actions (or lackthereof) are being watched.

You could even automate some aspects of this with robots. There could be a robot that counts the word count of each team member, and outputs that in a stats gadget at the end. This could feel a bit too strict for the students, but it can also serve as a nice "hey, you're not quite doing as much" reminder. That robot could also just monitor progress as a whole, making sure the team stays on progress. The gadget could list stats like "5 sections completed, 5 days left until final due". Then, those per-team-member stats just become another indicator of progress on the whole, and don't feel as accusatory.

One issue I see with this proposal is the tracking of "peer waving." Some students may sincerely find it more productive to sit at one computer and write up sections together - perhaps one giving the ideas, the other putting them into words. These words would only be attributed to one student, and the idea giver could be unfairly penalized. Possible solutions for this would be to annotate the text [Peer waved w/username@bla.com] or to recommend that students alternate between accounts when doing this.

Another issue, of course, is that not all group projects are writing up a blob of text, and in fact, many of them are not. In computer science, many of them are actually writing code. You can already ask students to use SVN and monitor commits from each team member for less fine-grained monitoring, but you could potentially even have students write their code in a Wave, and use a robot to compile it out, for real-time monitoring. In other fields, many group projects involve the the creation of a physical (non-digital) object. Perhaps you could have students write a design doc for that physical object, or even use a collaborative gadget to sketch it out.

So, yes, this solution isn't perfect, and for non-text projects, involves a bit more creativity. But, I still think it's pretty damn good. If you're a teacher, try it out and report back!

The Quest for Karaoke-able Slidesets

2009-09-08T06:08:00.000-07:00

I'm a massive fan of karaoke, and I've often expressed my opinion that some songs are far more "karaoke-able" than others, and that someone/me/an entepreneur should create an app capitalizing on that. The app could let you rate the karaoke-ness of songs, upload video evidence, create karaoke playlists, and find lyrics for practicing. It'd be an awesome app to improve the karaoke experience, but somehow, people are surviving and managing to enjoy singing drunkenly without it.

Well, perhaps traditional karaoke doesn't need an app, but "Powerpoint Karaoke" definitely does. For the unfamiliar, Powerpoint Karaoke is yet another new style of presentation, and it basically involves having the speaker speak to a set of slides that he's never seen before, and that were originally delivered by someone else. It serves partially to make fun of the sometimes incomprehensible nature of slides, partially to just be damn funny as the surprised speaker deals with the surprise slides, and partially to improve the speaker's presentation skills. If you can present an arbitrary slideset and woo the audience, then you can present nearly anything.

For our most recent set of internal lightning talks, I gave speakers the option of Powerpoint Karaoke instead of their own slideset, and one brave speaker (Jez) took on the challenge. And I, being the dumb-ass who suggested a format I have never done nor seen, was tasked with picking the slideset for him to present. Yes, I could have gone the route of randomly finding a slideset on the web as soon as Jez got on the stage, but considering that this was the first and only Powerpoint Karaoke that the office would witness that day, I wanted to make sure it went well. These were the approximate requirements I had in my head:

The slideset should fit well into our lightning talk 5 minute format, with about 15-30 slides. Ideally, I could have the slides auto-advance, to challenge the speaker's reflexes further.
The slideset should have a title and picture(s) on each slide, but not much else. If there was too much text, the speaker could just read that off and know the original intention of the slide. If there wasn't a title on any slide, then the speaker would have too much freedom in what he said.
The slideset shouldn't offend anyone in terms of politics/religions/beliefs - I didn't want to pick a slideset with the clear intention to make fun of some group. It might offend, and that's too easy, anyway.

So, using Slideshare's search and browse features, my search began. I looked at the top slides in various categories for all time, I did searches for random topics, I looked for slides from speakers that I knew did the kind of slides I was looking for. After an hour of searching, I had nothing. Most slidesets were the wrong length, the wrong amount of textual content, or just plain spam (slidesets with 1 image advertising a product). I then asked the office for suggestions of topics*, and used those random suggestions to seed my searches. After another half hour, I found 2 possibilities: "How to Defend Against Zombies" and "How I learned to love ballet". I picked the second one, as it had exactly 20 slides (Ignite format!), referenced the speaker's wife (Jez's wife works in the office too), and I thought it would be more humorous if Jez could turn ballet funny than if he could turn zombie invasions funny (since, well, they already are).

How did it go? Jez took that slideset and freaking ran with it - he did more with it than I could have imagined. His best line was when he got to the slide about "Barre" (a position) and explained that was the Japanese pronunciation for "Ballet".

But, I've learned now that it is much harder to find karaoke-able slidesets than karaoke-able songs, and it makes sense when you realize that the majority of songs are there are similar length & lyrics density, whereas the slidesets in the world are a highly diverse species. So, I would like an app for finding suitable slidesets, or even better, I would like Slideshare to add the following features to their search: restrict by # of slides (a range?), restrict by text density (avg words per slide?). Then, everyone in the world can get on the Powerpoint Karaoke bandwagon, and it can be the next great (geek) thing.

*And for your amusement pleasure, here are the list of topics that my colleagues proposed. I asked for these when I was contemplating actually creating the slideset myself with random images, but realized that isn't really the point of Karaoke, and used the ideas as keywords for slideshare searches. That could become an entirely new style of presenting though, especially if someone creates an app that can generate slidesets from just the titles - complete with images, graphs, and venn diagrams, of course. :)

"Lightning bugs"
"Japanese pop culture from the 1980's"
"Sesame Street and Alcoholism"
"100 Things to do with Dwarves and Leather"
"How to prepare for a zombie invasion"
"Analytic and algebraic topology of locally Euclidean parametrization of infinitely differentiable Riemannian manifolds"
"How Google could make billions through the power of hypnosis"
"Early 20th century ballet and swimming pool repair"
"Properly Disambiguated Java Generics"
"How to bluff and give an insightful talk when you have to make it up on the spot with no prior warning"
"Latin American Hedge Funds and You"
"The Social and Economic History of the Grapefruit"
"Care and Feeding of the Dugong"
"Unicorns"
"England Won the War of Independence - a counterfactual world history"
"Keelhauling, Walking the plank, and other piratical forms of corporal punishment"
"Why Robot Ninja Monkey Zombies are AWESOME"
"A complete etymology of My Little Pony"
"Zonkies: discuss"
"The renovations that Start City *should* be making"
"A 5-minute tutorial in interpretive dance"

The Poem Store: "Write a Poem About Her Hair"

2009-06-05T21:07:00.000-07:00

During the crazy week and a half that I was back in the states (after 8 months of being in Australia), I took a break from launching products and speaking at conferences to attend the Makers Faire with my old uni buddies from Los Angeles. The Faire was awesome - arts and crafts, fire-breathing objects, corn dogs, rockets, bicycle bands, sno cones, massive mouse traps, everything you could ever want in an amusement park for geeks. One of the really random things we encountered was a guy sitting under a tree, with a sign that said "POEM STORE: Your topic, Your price." That seemed like the coolest promise ever, so my friend Diana approached him and commissioned a poem on my behalf - about my hair. After I gave him a 2-minute recent history of my hair, he quickly typed up this on an old-school typewriter...

sky blue
but nights
falling down
the plummets
spectrum doesn't
cover everything
but it does make
it darker than it
was last once weekly
dying now we survived
 our out last dead protein
             goes DEEP

..which I think is awesome, even if I don't get all of it. We chatted with him more, and found out that he had offered the same service outside Google I/O, and that "web people gobble it up." Well, fine, we do. :) His name is Zach Houston, and he's always looking for more places to show up. Shoot him an email if you've got a poem-hungry crowd at your disposal.

Ignite I/O - Growing Up Geek: My Dad, The Computer Scientist

2009-05-31T22:14:00.000-07:00

"Ignite" is a style of presentation: 5 minutes, 20 slides, 15 seconds each, auto-advance. It's probably the most challenging style of presentation out there (lightning talks are a breeze in comparison), which is why it intrigues me. I did my first Ignite in Sydney a few months ago, with a talk entitled "HTML 5 versus Flex for RIAs". It went well, as I was able to remember all of my lines, and I managed to squeeze quite a bit of content into those 5 minutes. But I discovered that the best Ignite talks there weren't the informational ones, like mine - they were the narratives ones, the ones that told stories and left the audience feeling moved in some way.

So when I was asked by Brady Forrest to give an Ignite talk at Google I/O, I decided that I would find a story to tell, and hopefully one with a geeky twist. Thinking of how much my JAOO Brisbane audience loved the slide in my App Engine talk about my dad not giving me allowance unless I'd programmed Java that week, I formulated my talk: "Growing up Geek: My Dad, The Computer Scientist". I didn't have an exact outline for the talk when I proposed it, but I figured I had enough entertaining anecdotes about life with geeky parents (my mum ultimately became a computer scientist as well) that I could fill up 20 slides.

Creating the slides took ages, since my search for authentic pictures for the slides meant digging through our old archive of 5000 digitized family photos to find evidence of our myriad PCs, and using the Wayback Machine to capture screenshots of my original websites and Perl programs — and man, nolstalgia is a bitch of a distractor. Soon, a real story began to emerge amongst the slides: the story of me wanting to do many things — including programming, my dad disapproving of these non-programming activities, and me perservering on with my renaissance approach to scholarism and finally gaining his approval. The point I want to make with the talk is this: you should always encourage your kids to explore everything that interests them. Yes, this may mean that they don't become a specialist, or that they don't become the particular profession you've set out in your heart for them — but it means that they're doing what makes them happy, and people always excel the most at what makes them happiest.

The final slides are embedded below, with my pre-scripted lines pasted in the slides (it's impossible not to script them, trust me). I've also entered the slides in a "Tell a Story" contest that Slideshare is running now, since they happen to tell a story; you can vote it up on Slideshare if you like. The video is now up on Youtube. Enjoy!

Growing up Geek: My Dad, the Computer Scientist

View more OpenOffice presentations from wuzziwug.

Google Spreadsheets + APIs = Interactive Flash Cards

2009-05-17T04:34:00.000-07:00

For about 6 months in the Mountain View Google office, I went to a once-weekly hour-long German language class. Since I didn't have much time to really do homework outside of class, I looked for excuses to use Google APIs to give me different ways of learning German. My first attempt was a gadget that combined image search with a spreadsheet-stored German vocabulary wordlist. I liked the idea of using computer-generated hints for the words and wanted to make a more general solution for any topic/language.

So, I made the interactive flash cards gadget. Each flash card has a hint and a form of guessing, with different options for hint generation and guessing strategy. The hints can come from the spreadsheet (e.g. user-entered definitions), Google translate (any supported language pair), Google image search, or Wikipedia (*currently down). The guesses can be entered in a simple text input, selected from multiple choices, or solved in a word jumble. Hopefully, these options are diverse enough for all types of learners.

Here are steps for using the gadget:

Create a new spreadsheet, put a list of words in the first column, and put hints in the second column if you'd like to use that option. My sample spreadsheet has an animals wordlist:

Click on the "Insert" menu and then select "Gadget..." This presents you with various categories of gadgets to choose from (similar to the iGoogle directory). My gadget isn't yet in the gallery, so you'll need to select "Custom" and then type in the URL to the gadget:

The gadget will appear embedded in the current worksheet, and it will prompt you to select a range of data to send to the gadget. Select whatever columns you've created (either just words, or words and hints), and you should see the Range text field update with the range. If it doesn't work, you can manually type it in. Click "Apply".

The flash cards gadget is designed to take up a bit more space, so it's best to move it into its own sheet. Click the menu in the upper left of the gadget and select "Move to own sheet".

You can now play with the different hint/guess options to find your favorite. Several combinations are shown below.

Image Search + Word Jumble

Second Column + Multiple Choice

Translation + Type-in

You can play with my sample flash cards here. One day, I hope to add the ability to track your progress in learning the flash cards content... but if you're a developer, feel free to beat me to it!

If you're a developer and want to tweak this gadget further, you can grab the code from here. It's licensed under Apache 2.0, so feel free to tweak it and use it however you'd like. (And if you've got fixes, I'm happy to patch them back in).

Creating a Wordsearch using Google Spreadsheets

2009-05-17T02:46:00.000-07:00

I'm a fan of alternative learning and testing techniques. Back when I was the teaching assistant for the "History of Video Games" class (yes, that's a real class), I gave the final exam as an illustrated crossword puzzle. It was surprisingly hard to find software for creating that crossword, so I hoped to make a Spreadsheets gadget to make it easier. Unfortunately, crossword-solving algorithms that run entirely in JavaScript are hard to find, and I gave up and went for second best: a wordsearch gadget. (A big thanks to Robert Klein for the wordsearch JavaScript library.)

Here are steps for using the gadget:

Create a new spreadsheet, and put a list of words in the first column. (Or, alternatively, use an existing spreadsheet that has a column of words you're interested in). My sample spreadsheet has a simple animals wordlist:

Click on the "Insert" menu and then select "Gadget..." This presents you with various categories of gadgets to choose from (similar to the iGoogle directory). My gadget isn't yet in the gallery, so you'll need to select "Custom" and then type in the URL to the gadget:

The gadget will appear embedded in the current worksheet, and it will prompt you to select a range of data to send to the gadget. Select all the cells that contain the desired words, and you should see the Range text field update with the range. If it doesn't work, you can always manually type it in.
You can now customize the number of rows and columns. The default is 10 by 10, but if you have more words, you likely want a larger wordsearch. Click "Apply", and see the generated output.
You have a few options for how you use the wordsearch. You can play with it immediately, inside that gadget, or you can use the option on the gadget menu to move the gadget to its own sheet and use it there. Note that each time you reload the spreadsheet, the wordsearch will be randomly generated with a new layout - so don't rely on it staying the same.

You can also publish your spreadsheet so that other people can play the wordsearch. Click "Share > Publish" and you'll see the published URL, which you can share with friends. You can also use options on the gadget menu to embed the gadget in your iGoogle page or inside a normal webpage.

You can play with my sample wordsearch here. Enjoy, and hopefully one day, I'll have a gadget that makes crosswords too.

How to Convert a Google Spreadsheet into JSON, XML, and MySQL

2009-05-17T01:33:00.000-07:00

As some people know, I have a huge fetish for Google Spreadsheets - maybe because I'm always dealing with small datasets, and Spreadsheets is perfect for tinkering with them. Often, I start with my data in Spreadsheets, and later want to move it into a different static format - like a JSON file, MySQL data, or XML file. I originally did migration by concatenating column values together (e.g. ="" & A1 & ""), but I decided to make the process easier by creating a generic converter gadget. Using my gadget, you can easily convert any spreadsheet into those formats. Note: I could get JSON and XML using the Spreadsheets data API, but then I would have to deal with alot of ATOM cruft when I'm only interested in the bare data.

Here are the steps for using the gadget:

Create a new spreadsheet, and put your data in columns. Give each column a name, and choose carefully. Since this name will be used for MySQL attribute names, JSON keys, and XML tag names, the best names are lowercase, whitespace-less, and descriptive. The image below shows a spreadsheet of geocoded pizza locations:

Click on the "Insert" menu and then select "Gadget...":

This presents you with various categories of gadgets to choose from (similar to the iGoogle directory). My gadget isn't yet in the gallery, so you'll need to select "Custom" and then type in the URL to the gadget:

The gadget will appear embedded in the current worksheet, and it will prompt you to select a range of data to send to the gadget. Select all the rows for the column with your address data, and you should see the Range text field update with the range. If it doesn't work, you can always manually type it in.

You can now select either "JSON", "XML", or "SQL" from the dropdown, click "Apply", and see the generated output. To get the output in your clipboard, just double-click inside the frame, select all and copy.

You can see the published example spreadsheet, and see the XML output of the gadget in the second sheet. I generally move gadgets to their own sheet to make my workspace cleaner.

How do you document an options Object?

2009-05-05T15:06:00.000-07:00

In JavaScript APIs and libraries, you can make a constructor or function more flexible and easy to use by having developers pass in an object of additional options.

Here's an example of a badly designed constructor that doesn't take advantage of this feature - the final 5 arguments are all optional, but yet, location must be passed in if the developer wants to specify hobbies.

EvilPerson(name:String, location?:String, age?:Number, job?:String, hobbies?:String);

When used, it's hard to understand what this constructor is doing:

var evilPerson = new EvilPerson("Taz the Haz", null, null, "Annihilator", "Blowing stuff up");

Here's an example of a well designed constructor that makes developers specify the absolute core information, and then pass everything else via an options object:

GoodPerson(name:String, options:Object);

When used, it's very obvious what options we're setting:

var goodPerson = new GoodPerson("Snuggly Muggly", {job: "Cuddler", hobbies: "Spooning"});

So, most people are in agreement that this is a good technique, but there's one problem: there's no standard on how these options objects should be documented.

In the JavaScript Maps API, we give the objects a class name, link to the class reference from the constructor, and then list the keys there. The advantage is that we can refer to these objects in the developer's guide or forum by name, the disadvantage is that we list a class in our reference that developers cannot actually instantiate, and that can be confusing.

The screenshots below are from the GMarker and GMarkerOptions reference.

In the Maps API for Flash, we turned those name objects into actual classes that developers must instantiate. This is good for documentation, but does perhaps bloat our API and make constructors more verbose.

The screenshots below are from the Marker and MarkerOptions reference.

In jQuery UI, every widget gets its own single-page documentation, with "Options" being a section along with "Events" and "Methods". There is no actual reference for the widget constructor itself, presumably because every widget's constructor takes only an options object. This likely works for jQuery UI developers as they're accustomed to this convention, but I personally found it confusing that there was no constructor reference.

The screenshots below are from the Dialog reference and options section.

In Dojo API, the reference for many of the Dijits specify that they take an Object for additional parameters, but they don't actually make it clear what can be passed into that object. My best guess is that the fields listed in the "Properties" section can all be passed in. This is probably once again a convention that seasoned Dojo developers are accustomed to, but arguably pretty confusing for a new Dojo developer.

The screenshots below are from the Dialog reference and the properties section.

In the Gears API, none of the constructors take a options argument, but there is something somewhat analagous: objects passed into event callbacks. In this case, Gears documents the object entirely inline with the reference. This technique has the advantage that everything about the function and the object are in one place - and the disadvantage that there's not a great way of referring to that specific event callback object elsewhere (besides saying "the object that the onerror function passes back").

The screenshot below is from the WorkerPool reference.

All of these styles have their pros and cons - and there's no one technique that satisfy our goals, like being easy for newbies to understand easy to refer to elsewhere in the documentation. What do you think? Have you seen a documentation that does it better, or do you think one of these techniques is clearly superior?

What is an API?

2009-04-25T21:44:00.000-07:00

A game designer asked me the other day to explain the meaning of "API" - and I thought, wow, that is a good question, considering our massive (over?)use of the term on the web. Of course, the obvious meaning is "Application Programming Interface", but that's pretty damn non-helpful, particularly for a non-programmer. So here's what I told him:

There's the traditional meaning of "API" -

Some programmer writes a library with lots of functionality in it, and exposes the functionality as different functions, so that other programmers can just call the functions.

For instance, I could write a function that goes through all the complex steps of making out:

function makeOut(passionLevel, partsOfBody) {
 for (each partOfBody in partsOfBody) {
   partOfBody.kiss(passionLevel);
   lookIntoEyes();
   sighDeeply();
 }
 moanDaintily();
 complainAboutPeopleWatching();
}

So if you want to have your code make out, then you could just call:

makeOut(10, ["neck", "ear", "mouth"]);

You don't have to worry about the "implementation details" - all that code I wrote - you just know that it works.

The "library" is the actual code, the "API" is what programmers need to know in order to use it.

So my API documentation would provide the minimal info needed to use the library, and it could look like this:

makeOut(passionLevel: Number, partsOfBody:Array)

For an example of actual API docs, Java has the online documentation for all of its common libraries here: http://java.sun.com/j2se/1.5.0/docs/api/.

And then there are "Web APIs" -

A Web API hosts all of its code on one server, and documents how other servers can call that code.

There are JavaScript Web APIs, like the Google Maps API, where the Javascript is publicly viewable but quite "obfuscated" (compressed, hard to read).

This is our actual code: http://maps.google.com/intl/en_us/mapfiles/148e/maps2.api/main.js

This is our API documentation: http://code.google.com/apis/maps/documentation/reference.html

Developers only need to know what the API looks like, they don't have to figure out what all that crazy code means.

Then there are HTTP APIs, which means that all of the code is hidden on the server, and the code is executed when a programmer hits a particular URL. Often times, these APIs will create new information on the server for a user. All of our consumer products with user data have HTTP APIs - like Google Spreadsheets, Google Calendar, Blogger, etc. A programmer can hit a particular URL with an authentication header, and either get or create more user data.

One of the most popular HTTP APIs is the Flickr API, which can be used to retrieve information, upload photos, create albums, etc. Their API is documented here: http://www.flickr.com/services/api/

You can use the API without authenticating if you just want to do a simple search:

http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=4d12a2ccfa7400584c162bfc104bf682&tags=fox

Notice the query parameters after the "?" like method, api_key, and tags. These are like the parameters to a function (like passionLevel and partsOfBody from above). You could imagine that flickr has code on their server that looks like:

function searchPhotos(api_key, tags) {
 ....
}

But once again, a developer never has to see the Flickr server code, they can just use the API and get the results they want.

Above all, an API is a promise.

It's a promise that no matter how the author changes the code (the implementation), the interface will remain the same. You can always call that makeOut function, and expect it to make out, even if it stops complaining about people watching.

Web09: Design, Code, Community.. and Maps!

2009-04-20T14:17:00.000-07:00

Earlier in the year, I was invited to speak at Webstock, an annual conference in Wellington, New Zealand. It was a fantastic conference filled with inspirational speakers from around the world who discussed the future of the web, ways in which it sucks now, what we could do to change it.

This week, I had the opportunity to speak at Web09, a similarly named conference in Auckland, New Zealand - just an hour flight north. I was a bit surprised that New Zealanders felt the need to hold 2 web conferences in a year, and wondered if this conference would be different from Webstock. Well, it was completely different - in a good way. Web09 was a cornocupia of real-world advice from both local developers - like Karl Von Randow's talk about gaming the iPhone App store, and global evangelists - like Ryan Stewart's talk about new Flex features. Some of my favorite talks were:

Dan Rubin gave us a variety of ideas for creating better designs, including adding noise to a background, using your own photographs as the focal piece of a website, and scanning in every day objects to get web textures. In trying to define good design, he referenced Don Norman as the cognitive scientist who originally articulated the problem of doors that are so un-intuitively designed that they require signs - a problem that we have in our new Google building. Norman authored The Design of Everyday Things, which I've now put on my reading list.
Paul Burnett, Adobe Flash Evangelist, showed off various new features in Flash CS4 and its much better integration with AIR (now better than Flex Builder!). I was most impressed by the fact that Flash now supports adding bones (inverse kinematics) to shapes and graphics, and being able to set weights and properties and tweak the RTS graphs for every animation. It takes me way back (2 years!) to futzing around with character animation in Maya and Max, and makes me want to get CS4 and try animating a few simple characters - zombie, whale, maybe even a streetwalker.
David Karp, creator of Tumblr, described 5 areas of community building: engagement, use, negativity, change, feedback. Karp suggested that the reason that people participate in communities is for the "promise" of something happening - like the people who upload to Youtube thinking they have a small hope that one day their video will shoot to fame and they'll be a Youtube rockstar. Karp also described how Tumblr went from 1 support email a day to hundreds, and how they dealt with it. They categorized every support email as both "type of user" plus the actual problem - with user type ranging from paying customers and new customers to evangelist users. Visualizing the requests that way enabled them to decide what features were important to growth.

I myself gave a talk called "Avoiding Red Dot Fever: Tips for Improving Usability of Maps Mashups". It was a series of tips for ways web developers could improve the maps on their sites, based on my experiences seeing many badly-designed maps over the past 2 years. The talk went over really well (so well I was asked to give it twice), and gave me an excuse to meet the web developers of many New Zealand mapping sites - Zoodle, Yellow Pages NZ, vodafoneNZ, EventFinder, etc. The slides are embedded below, and there should be a video up in a few weeks.

Overall, it was a great conference, and I hope to see both Webstock and Web09 happen next year.

Google Image Search + Color Restrict: Just look what you can find!

2009-04-09T07:00:00.001-07:00

This week, Google officially announced support for filtering by colors in Google Image search results.I don't actually know if this is actually a useful tool yet, but even if it's not - it's freaking fun. Here are some cool results from myself and the twitterverse.

You can find beautiful landscapes: sky, red

You can find your school logos: usc, red
(via @oGLOWo)

You can find a world covered in fail stickers: fail, red
(via @niick)

You can find a phrase that's lived up to its colors: state, blue
(via @ManoMarks)

And one more of those: journalism, yellow
(via @KevinMarks)

You can find two colors at once: red, black

And finally, you can find creatures you never thought existed: dolphins, pink
(via @niick)

API Design: Beautiful Interfaces

2009-04-01T21:27:00.000-07:00

This is part of a series on Web API design. The intro post is here.

When some developers think about the Google Maps API, they may envision a sea of GMarkers, GPolygons, GScaleControls, GOverviewMapControls, and the like. But really, it boils down to 2 things: GOverlay and GControl.

These two classes are interfaces in the API, and every class that is a visual item on the map extends from one of those two. Conceptually, a GOverlay is something that moves when the map moves and is somehow related to latitude/longitude coordinates, and a GControl is something that always stays in the same place, regardless of map movement. The screenshot below points to various examples in a standard maps mashup:

To add one of these to the map, a developer just calls addOverlay or addControl:

map.addControl(new GScaleControl());
map.addOverlay(new GMarker(new LatLng(37, -122));

To remove them, they call removeOverlay or removeControl.

There are some mapping APIs out there with calls like addMarker, addPolyline. This is is a bad idea for several reasons. It means you need an additional method each time you add a new visual class (bloating your API), and it likely also makes it hard for developers to extend the API. With generic methods like addOverlay or addControl, you can add a custom extension the *same way* you add a native class - so newbie developers don't have to learn a new syntax to add one to their map.

Along with using generic methods for adding stuff to the map, we can also take advantage of the interface to make our events more generic. A developer can listen to "addoverlay" or "removeoverlay" to find out when any overlay has been added to the map, and when they listen to a "click" event on the map, their callback gets passed in whatever GOverlay was clicked on. This means that whenever we add a new type of overlay to our API, the developer can continue using the same events they were before. We do often add specific events for each overlay later, but it's nice that the generic ones come for free.

And something for the advanced developers...

These interfaces make our API infinitely extensible in a standard way, and they're the reason I used the API for my personal and research projects even before working for Google. If I have a fundamental aesthetic issue with our GLargeMapControl3D, then I can simply create my own control (ExtLargeMapControl). If I want to visualize 5,000 markers, and GMarker is simply too full-featured and heavyweight for the job, then I can create my own lightweight marker (MarkerLight). If I want to visualize my points as <div>-based bar graphs instead of <img>-based markers, then I can create my own overlay (Bar).

To extend the interfaces requires defining only a few minimal methods:

GOverlay: initialize, redraw, remove

The initialize method, called when addOverlay is invoked, should create DOM objects for the overlay and append them to the desired map pane (there are several). The redraw method is called whenever the map moves, and it should re-position the overlay depending on the new latitude/longitude -> pixel mapping. The remove method, called when removeOverlay is invoked, should clean up any DOM objects created by the overlay. More info and an example is in the docs.

GControl: initialize, getDefaultPosition

The initialize method, called when addControl is invoked, should create and return the div for the control. The getDefaultPosition method should returns the recommended position for the control. There is no remove method, since the initialize method returned a <div> that the map can remove whenever removeControl is invoked. More info and an example is in the docs.

Using just these methods and some JavaScript/CSS skills, a developer can create anything their hacker heart desires. Custom controls and overlays account for 15/20 of the libraries in our official utility library, another 15 of the libraries listed in Mike William's list of 3rd party extensions, and based on my experience, many more are likely floating around in developer's code on the web.

Don't forget the actual API engineers...

Along the same lines, these interfaces also make API development easier for internal developers. If they want to add a visual class to the API, they just need to figure out whether it's a control or an overlay, define the methods, document that the new class exists, and external developers will use their existing familiarity with addControl or addOverlay to add it to their map.

It can't all be fluffy rainbows and unicorns...

We've certainly made a few mistakes along the way with the interfaces - but this post is getting long, so I'll save those for later.

To sum it all up...

The interfaces are easy for newbie developers to understand, easy for advanced developers to extend, and easy for internal engineers to implement. Beautiful.

Web API Design: The Good, The Bad, and the Ugly

2009-03-30T23:31:00.000-07:00

Two recent events have prompted me to spend a lot more time thinking about API design: 1) A series of "Good, Bad, and Ugly" talks at the Google Sydney office which examine internal architectures and coding decisions, 2) An internal reading group starting with "Beautiful Architecture", a book of essays. Though the design of internal software (largely the focus of the talks and book) is important and should be done well, it's my opinion that the design of external-facing Web APIs is even more important, and yet, a much less discussed topic.

Why? Web APIs have some unique challenges:

Flexibility: Web APIs are intended to by whatever random developer finds them useful, not by a restricted set of internal developers. And, I can tell you from experience, random developers do things that you never even realize was possible with your API - and then they beg for feature requests to make it easier for them - and you'll want to fulfill their requests because you'll think "hot damn, that was cool!" So, the easier it is to implement new and different features, the better.

Backwards-Compatibility: Web APIs have to stay around for a long, long time. Even if you threaten that you'll change your API every 2 years and you warn users 1 year ahead of time, you'll still have some developers use the old version of the API and write angry posts in your forum about their site breaking. Or, developers that have written code for client sites, moved on to bigger and better things, and left it with webmasters that have no idea how to upgrade it. Or, developers using wrapper libraries that abstract on top of the older version of the API, and have no notion of the underlying API. So, it's safe to assume that you can never really deprecate an API without breaking old sites, and you should design the API with that in mind (future-proof it).

.. and other challenges, like needing to be equally usable by both newbie and advanced developers, and needing to be a reasonable number of kilobytes (for client-side APIs).

In the land of Web APIs, the Google Maps API makes for an interesting case study. It is one of the most used Web APIs in the worlds (150,000 sites), the first interactive web mapping API, likely the first hosted JavaScript API, and it has grown from a simple API with just markers and zooming to a complex API with 90+ classes. It's also gone from version 1 to version 2, but the changes were primarily in terms of latency; the actual interface has remained largely the same. All these facts make it interesting to look at the Maps API from an architecture and design point of view, and point out the places where it went right - and where it went wrong. Of course, as an advocate of the Maps API and someone who uses it daily, I should point out that I still think we have the best Maps API in the world. But even gods can have their flaws (I hear Zeus had a weakness for mortal women).

So, in an upcoming series of blog posts, I'll single out design decisions in our API that I think were good, bad, or ugly. To start it off on a good note, I'll start with something beautiful... stay tuned!

APUGS Round-Up: Bzoo, AIR, & Eclipse

2009-03-30T04:08:00.000-07:00

Tonight, despite half of Sydney CBD being in a blackout (and zombies attacking the city), I attended the monthly APUGS (Adobe Platform Users Group Sydney) meeting. 3 developers gave talks, and I learnt a great deal of random information. I realize that all of my Flex experience currently comes from supporting the Maps API for Flash - so, if a developer hasn't asked it, I've never learnt it - and apparently, developers haven't asked me all the questions in the world yet. Here's a roundup of the topics covered:

Developer Bachir El Khoury spoke about his AS3 library for creating a client-side database with full CRUD operations, called Bzoo. It can create the database from JSON, YAML, or ArrayCollections, and optionally, it can store the database persistently using Flash Shared Objects. Shared Objects are basically super cookies for Flash that are persistent across all browser sessions on a desktop, and can take up to 100 KB per domain. Cookies can be useful in Flash apps for remembering game configurations, backing up data before a save, or user sign-in state.
Developer Andrew Muller showed off Bowernest, an AIR app he's creating for a client (BookTagger). It's a desktop app with a slick interface for managing books and other media. Andrew used the Mate (Mah-tay) RIA framework for creating the app, and the award-winning skin from ScaleNine's contest. Cleverly, the app can import files from Shelfari and LibraryThing, the two big competitors to BookTagger, so its easier for users to switch over. It then stores all the data locally in an AIR SQLite DB, and offers the user the option to export back out to the Booktagger file format. As a heavy user of web-apps, I find it a bit shocking that the data isn't constantly backed up to a BookTagger user-account, but hey, apparently some users are into the whole desktop-only app thing. When I asked Andrew about other apps out there that were desktop-only, he showed us Balsamiq Mockups, an awesome app for mocking up web prototypes in a sketchy way.
APUGS organizer Chris Velevitch showed some tips for working in Eclipse. I only work in FlexBuilder, but it was useful to see the similarities and differences to Eclipse development. Eclipse has a cool feature called local history, which lets you see every version of the files in your project - for up to "9,999 days"! Also, in both Eclipse and FlexBuilder, you can right-click on a file tab and select "New Editor" to get the same file opened in two tabs. In FlexBuilder, you can then put one tab in Design mode and the other in Source mode, and drag one so it's below the other. Highly useful.

BarCamp Canberra 2: Mapping the Fires

2009-03-27T17:34:00.000-07:00

I just spoke a few minutes ago at BarCamp Canberra 2 about our experience making a map of the Victoria BushFires. Here's a quick run-through of the presentation, with links:

We woke up, saw there were crazy fires going on, and looked at how we could help. The websites with the information were DSE (Public Lands) and CFA (Private Lands). The problem with the DSE site was the lack of an interactive map and the lack of an RSS feed. The lack of RSS feed meant that people were constantly reloading the page to see what had changed, and their server was crumbling under the load. The problem with the CFA site was the lack of a map -- and given all the number of small towns in Australia, it's very hard to visualize where the fires are happening in respect to where you or your loved. The problems with the RSS feed was that it lacked latitude/longitude coordinates, and the CFA website was struggling and producing corrupt feeds some of the time.
First we tried using Yahoo! Pipes to turn the RSS into a GeoRSS feed, but it didn't quite work correctly, and we were worried about relying on the service during an emergency.
So then I set up a database on my server, ran a script geocoding any new locations every 2 hours, output the database as an ActionScript object, copied and pasted it into my Flex app, and re-uploaded the SWF. It was ghetto and painful, but it worked.. provided I woke up every 2 hours. Sometimes, we had to manually find locations - like "DSE - 6KM ESE OF WARBURTON" - by using the distance measurer mapplet in Google Maps and eyeballing it. It sure would have been easier if CFA had done the geocoding for us!
So then we created the map. We sent the RSS feed through Google App Engine, caching it every 5 minutes to avoid hitting the CFA web server (and to ignore corrupt feeds), parsed that feed in the Flash map, and displayed the fires as markers. We later added a legend, search box, and colored/sized markers, but we basically had our map up 4 hours after we started coding. Not bad!
One important thing we did was make a gadget version of the map. This meant news agencies, blogs (like Mashable, and random concerned folks could embed the map in their sites. A lot of people discovered the map through the gadget, and the news agencies benefited since they didn't have to create their own visual to complement their articles.
The map got around 60 QPS at its peak - and App Engine handled it with no problems. It probably helped that we used our inside influence to raise all of our quotas to the absolute max (14 petabytes of bandwidth!). :)
After we had the map up, we wanted to make the geocoding less ghetto. We changed from doing the geocoding on my server to doing the geocoding on App Engine, and outputting the feed as a GeoRSS feed instead. The great thing about GeoRSS is that it's a pseudo-standard, and there are multiple websites that can parse and display them (including Google Maps). The cool thing about outputting the data in this portable format was that one concerned guy was able to import the GeoRSS into a Google My Map, plot markers where his family members were located, and figure out if they were in trouble.
At this point, we were doing good things with the CFA data, but we still had no data for the public lands. DSE was unwilling to give us structured XML data, as they had various concerns about copyrights, attribution, and data distortion. We still wanted to represent public lands data though, and that's when we discovered that NASA takes satellite imagery of South Australia every 12 hours and makes them available in various standard formats.
Using MapTiler, an open-source GUI for the command line GDAL utilities, we converted the NASA GeoTIFF into map tiles. Those map tiles can be used in most APIs - Google, Microsoft, OpenLayers, etc. We, of course, overlaid them on our Google Flash Map, and let people toggle the imagery on. NASA does an automatic analysis of the imagery to look for fires, so you could actually see red outlines around the center of big lines of smoke. Since we're still serving the imagery from 25 days ago, you can still see that on the website.
The aftermath of all of this is that we learned lessons about the issues with getting emergency data in a format that can be re-used, cached, syndicated, and visualized in useful ways. We wrote a white paper of sorts with recommendations for Emergency Data portability and we're consulting with various agencies to help them get their data up to snuff.

Ada Lovelace Tribute: A Q&A with My Mum

2009-03-24T15:15:00.001-07:00

A few months ago, I pledged to write a blog post for Ada Lovelace day. The hope is that atleast 1,000 bloggers will write about a woman in technology on today, March 24th, and that this will draw (good) attention to woman in technology. I don't necessarily know if we'll succeed in the objective, but hey, it's different and could work, so why not?

Since I don't actually know very many women in technology (I'm too distracted by all the tech boys?), I've done a Q&A with my mum, Rosemary Kennett. Mum studied Physics at Caltech, met and married my dad there (a professor! scandal!), had 3 kids, worked for NASA JPL, did physics research at SU and Cornell, taught Astronomy for a few years, and then moved on to her current job as a scientific programmer in Spectral Sciences. Here goes:

Why did you choose to study Physics?: I actually became fascinated in high school where I was taught by a teacher who had just returned from a sabbatical at Oxford and was intrigued by the new physics e.g. nuclear physics. I remember that I used to borrow her collection of popular scientific paperbooks.
What was the first line of code that you wrote?: I remember writing code to model an oscillating violin string when I took an early math course involving programming as an undergraduate (we did not have CS courses back then). Most of the early coding was in Algol 60 (which most people agree was a pretty good language but somehow it died out)
What language have you programmed the most in?: Fortran, then C/C++, then Java; (Hmm. Is Fortran kind of like 4chan? - PF)
What app are you proudest of creating?: For the general public - there's a simple Java applet that often gets referred to: Epicycle and Deferent Demo.
You taught astronomy and ran the Syracuse Astronomical Club for a few years. What's the most fascinating aspect of astronomy for you?: How much we are learning about the distant past (likewise through high energy physics experiments, which now are trying to mimic conditions soon after the start of the universe!). Also the number, variation and beauty of objects in space, especially as observed using the Great Observatories (Hubble, Chandra for X-Rays, Spitzer for IR etc)
I always thought it was pretty cool to have a mum that worked at JPL. What were you doing there (besides rocket science, of course)?: Actually the technical work of which I'm most proud was that done at JPL. One project was to check the performance of a new design of a radar instrument called a scatterometer which measures oceanic winds (strength and direction) by bouncing radar off the waves - the Bragg effect means that the radar return depends on the roughness of the waves, which is in turn influenced by the wind speed. You do this from different directions and you can tell the direction of the wind also. Anyway that style of scatterometer is now the standard, although launches of these instruments are few and far between; (That's right, my mum's invention is orbiting space above your heads right now. Boo-yah! - PF)
You have 3 kids, and two of them ended up in Computer Science. Do you credit/blame nature or nurture?: Genes!; (Hmm. I'm pretty sure it was the fact that we had a T1 line before any other kids had the internet, and that we moved to cold, miserable upstate NY and I was forced to hibernate inside our well-supplied computer room. - PF

Bonus Factoid: My mum knows all the cool kids in CS: Steven Wolfram, because he was a student working with my dad on the Mathematica forerunner, Richard Feynman, because he was a Physics professor at Caltech, and Larry Page, because he attended a Hertz event and asked her a question about her research... I'm jealous!