Christian Heilmann

Posts Tagged ‘slides’

On controversial slides, talk distribution and lack of context

Saturday, October 29th, 2011

My life lately revolves mostly about going to conferences and presenting. This gives you an interesting insight into how they are run, how other people present and what impact it has on the audiences.

I’ve done this for a while and I think I am pretty good at it. I also see other people who are incredible at it, I see a lot of potential in others and I see a lot of failed presentations.

I also see problems with the way we distribute presentation content on the web afterwards and this is what I want to discuss today.

Powerpoint hell is just not us

Presentations on web technologies (and generally covering our market) are a very strange beast. We are in a “new media” environment where we despise all the things that IT and office life was before we started linking documents with each other over the world wide web or load cool apps onto our smart devices.

A sure-fire way to fail presenting at a web-related conference is to use old school power points with headings and bullets and reading them out to the audience. Therefore we go to other extremes: the “inspiring pictures with a single word”, the “typography heaven with awesome transitions” and the “I have no slides, let’s get to live coding on the CLI or in my editor” are the most common ones.

What we lose by doing so is the context. Our presentation materials become part of the talk and not an information resource. This is good – it means you as a speaker get the attention. But it can be a problem further down the line.

Our “new media presentation style” is very different to what we did before. I use a lot of humour and comparisons with the real world in my talks. Some of my slides seem totally disconnected until I explain their angle. Aral Balkan does similar things. A lot of times he explains the usability of interfaces by showing ticket vending machines at airports. This is great. Real life frustration makes it easy to remember not to do that online.

Slides are backdrops

The gist is: our slides are not the talks, our slides aid the talks we are giving. They are a visual catalyst for the things we talk about. When you see something and you hear about it at the same time it is more likely to stick. It is as simple as that.

The dangers of re-use and distribution without context

Once the talk is over you can bet your life that the first question (unless you covered that already) is “are the slides available for download?”. And this is where it gets interesting.

For the people at the conference it makes a lot of sense to get the slides and check them later on reminding themselves of your talk. Conferences are jam-packed with talks and it is good to have a reminder to re-focus after the party. This is also a very human trait – we are hoarders and want to get our hands on everything we get offered. Free stuff never stays behind – people take it. Wether they need it or not is not the question. Better to get it in case we need it later than not have it.

I’d love to think that people download my slides and read them and all that (which is why I share them) but I am quite sure that this is very rare occasion.

It really breaks when the slides are just that – slides. The aid to support the talk that without the talk lacks a lot of context. If I look at the PDF of a talk a few weeks later and only see pretty images without remembering what they meant at that time I get confused and frustrated.

Even worse, if you distribute slides of that ilk, people will find and watch them when they haven’t seen your talk at all. And this is where it gets dangerous as people can make their own assumptions as to what you tried to achieve.

Attention getting devices can backfire

In our quest to be different to the dreaded talks we had to endure in school and office life we tend to push the boundaries of presenting.

People in web tech swear on stage, make outrageous demands in a ironic manner, and show things that are very much the direct opposite of what you expect. These are attention getting devices that – paired with a good speaker – can be very effective and also very entertaining. They can also cause controversy and misunderstanding.

The other day I had quite a back and forth with a presenter on Twitter about a slide deck he published. I’ve seen the speaker talk and respect him for what he does. I am very much sure that in the context of his talk the slide deck brought the point home and made a lot of sense.

But, as it is right now on the web without notes or any other information, a NSFW picture of an almost naked tattooed lady with taped nipples and massive breasts as your first slide is likely to cause more trouble than it is worth.

He had his reasons for using it, no doubt about that, but with the distribution being disconnected from the rest of the talk, what are the effects of this?

Why shock when you can convince or show?

There is a lot of talk about gender diversity at conferences and in IT. I am not going to poke this hornet’s nest, but I am sure that a slide like this one is a great way to keep an endless discussion with continuously mounting emotions going for months instead of concentrating on solving the issue.

Shock slides and campaigns can work. They also have been done in the past and are to me a cheap way of getting attention. Web sites like and ogrish were a very successful thing in the past and Benetton in the 80ies had massive success with their controversial campaigns in magazines. Heck, every boulevard paper has some nudity on their covers to sell issues. Page 3 girls appeal to the audience they try to reach.

So, in essence, this is an old hat. It only works when all you want is attention and your product doesn’t have much to do with the shock content. Benetton sells clothes, something very personal that people buy and own for themselves. They wanted to get their name talked about and expected people to find out about their products on their own. We can not assume people to do the same about our slides, design ideas or code tricks as they are not as excited about our them as we are.

The question we should ask ourselves is what we achieve with this. You get attention quick and you probably get talked about a lot. What people talk about though is that there was “some guy on some conference showing a naked lady (run over puppy, open wound, vomiting child, whatever…)” and not what you wanted to bring across in your presentation.

Using shock slides is the equivalent of kicking someone in the shins and then asking for the way to the station. Yes, you have their undivided attention, but you are not likely to get out of them what you wanted.

By all means, if you want to keep using them – do so. But be aware that when you fail to provide context you will not get your message across. If you use nudity or sexist material you will also contribute to an already existing problem.

If you publish things you are as responsible for their content than when you are on stage presenting them.

Saying that “nobody complained” is not an excuse for offensive material. Not all people who are offended say so and confront you. Actually most are intimidated and will not say anything but tell others how they felt and what your behaviour did to them instead. This is how discrimination and bullying works – you shock and intimidate by coming from a position of power. And you being on stage is a position of power that can be used to inspire others or for personal satisfaction.

So, to me at least, we should stop using any shocking materials in our slides as an attention getter. We are better than that. Our messages should be the “a-hah!” moment, not the packaging they come in.

The best of all worlds

As to the overall distribution of our talks, I think it is time to reconsider our ways.

If our slides are only a backdrop to our talk and we don’t even have notes or a transcript, let’s not give them out. Let’s wait for the video to come out and distribute them together with the video – even if it means that people have to wait. In essence this is a good test to see if people really care about them or if they just want them right on the spot for hoarding purposes.

If you want to release them immediately, try to give them more context. Have notes on your PDF or presentation document. I tend to record the audio of my talk while I give it and publish it along the slides. I always want to sync the slides with the audio but it is a lot of work so most of the time I forget about it so I am not sure just how effective this is. If you use keynote you could do that automatically as it records a movie of your slides if you ask it to. In any case, I can point out what was said and debunk accusations that way.

I also started to go the other way around. I wrote my Fronteers 2011 talk as an article, then split it up into paragraphs and created a slide for each. That way I could publish it as a blog post that makes sense and with accompanying slides.

The new HTML slide format I use based on DZSlides allows me to have the talk as a searchable, printable page with support for old browsers and as a slide format at the same time. I am cleaning this up and adding some new features to release soon.

Let’s be professionals

In essence, it boils down to one thing: if you want to be inspiring and an educator, don’t leave things online that lack context or cause controversy. It confuses people, causes misinterpretation and helps neither you nor the people you try to reach. This is about the people you talk to – not about you.

Comments? Questions?

Discuss this on Facebook or Google Plus

Why I don’t write my slides in HTML

Tuesday, November 2nd, 2010

At the Fronttrends2010 conference Tantek Çelik spent the last few minutes of his HTML5 talk praising HTML as a great format for presentations and urged people for the good of the open web to use HTML slide systems instead of Flash or PDF. Other presenters right now write awesome CSS3 driven slide shows and build their own scripts to show their presentation. I could, but I don’t – and here’s why.

Presentations are not web documents

I am all for the open web (heck, I just took a job evangelising it) but I don’t write my slides in HTML and I really don’t consider it a good format for something like a presentation. Here are my reasons:

  • A presentation is not what you see on the screen – many speakers have notes that are shown in presenter view in Keynote or Powerpoint and not shown to the audience but on a different screen. There are probably ways to do that with CSS and media queries but I have yet to find a slide system using web standards that supports this requirement. If you just read your slides you might as well not be on stage.
  • Adding images should also allow you to edit them – I find myself dragging photos into Keynote and cropping and resizing them all the time. This can be done with CSS and JavaScript but I have yet to see a slide system have that functionality.
  • Presentations need to scale to different resolutions – I’ve encountered anything from 800×600 to 1280×1024. A slide package resizes my fonts and keeps them the way I intended them to – HTML doesn’t do that yet. Again, I am sure with SVG, Canvas and clever trickery this can be easily done but please tell me about a system that considered that.
  • Presentations need to be a single, printable file – presentations get mailed around and printed out for people who like to edit or read on paper. Using a PDF I can do that. Printing out is needed for example when you have a conference with sign translation. As sign translators do not translate word by word but sentences by meaning it is important that they know what is coming. Unless HTML slide systems also support good print styles this is not really possible
  • HTML slides can’t be embedded and resized – using Slideshare people can embed my slides in their blog posts or articles and people can watch them in context. You can put HTML slides in an iframe but they wouldn’t resize but instead get massive scrollbars
  • Slides might need to be synced with audio to make sense – I normally record my talks in addition to offering the Slideshare embed. I also used to do slidecasts, but the editor on Slideshare is not good enough yet. This is something we could write for HTML slides – a syncing tool with audio that automatically moves ahead in the deck.
  • Slides need to work offline – many a conference doesn’t have working wireless and people want to read the slides on the train. If you use third party fonts or images hosted elsewhere or you link to live demos this is very frustrating. You can use offline storage for that though.
  • Slides should work without your computer and your browser – many hand-rolled slide decks expect the presenters settings, operating system or nightly build of a certain browser and are not written with progressive enhancement as they are for personal use. When people try to watch them on their own computer and cannot see the effects or demos explained this actually is bad advertising for open web technologies.
  • A slide deck has a fixed layout and fonts – and differences in browser rendering or elastic design effects are not welcome in a slide deck – so why choose a technology that excels in this?

Presentations are more than a document on the web and unless I can do the things above as effectively and easily in HTML as I can do them in Keynote, I won’t switch.

Arguments for HTML slide decks

The main argument – beyond “doing the right thing for the web” that Tantek mentioned was that your slides as a PDF or Flash movie just can’t be found on the web. This is not true – Google happily indexes PDF and Flash and furthermore Slideshare creates a transcript of your slides as an ordered list for SEO reasons.

The other argument which is more to the point is that HTML documents are easy to edit, re-use and update. Collaborating on a slide deck in Keynote and Powerpoint can lead to annoying inconsistencies across operating systems and software versions.

My hybrid approach

Personally, I use a hybrid approach to the issue. I write my presentation as notes and then create a slide deck from those. I explained the lot (and the above arguments against HTML slides) in the presentations chapter of the Developer Evangelism handbook:

When I write a new slide deck I start with a text editor. I write the story of my presentation and I follow the same rules as for writing online articles. That way I make sure of a few things:

  • I know the content and the extent of what I want to cover – which also allows me to keep to the time limit when presenting.
  • I have the information in a highly portable format for people to read afterwards – by converting it to HTML later on or blogging these notes.
  • I already know all the links that I want to show and can create easy-to-find versions of them – for example by bookmarking them in Delicious.
  • I don’t get carried away with visuals and effects – which is a big danger when you play with good presentation software.

Yes, this is duplicating work, but I think it is worth it – after all Slideshare is a community for slide decks – you already have a captive audience rather than hoping Googlebot comes around and considers you better than another resource on the same subject.

Frontloaded and zipped up – the Full Frontal 2009 keynote

Saturday, November 21st, 2009

Here are the slides, the audio recording and my notes for the keynote of the full frontal conference held yesterday in Brighton, England. It was a blast, thank you Remy and Julie!

Slides on Slideshare

Audio recording

You can get the recording of the talk over at – recorded on my macbook, so there are some volume fluctuations.

Talk description

The following was the description of the talk introducing the ideas to the attendees of full frontal.

Frontloaded and zipped up – do loose types sink ships?

JavaScript had a bumpy ride up to now, from its origins as a CGI-replacement, initiator of countless popups and annoying effects over the renaissance as Ajax enabler up to becoming wrapped up in libraries to work around the hell that is browser differences. With the ubiquity of JavaScript comes a new challenge. How do we keep JavaScript safe when browsers don’t really distinguish between different sources and give them all the same rights? Why do we still judge the usefulness of JavaScript by how badly browsers speak it? Learn about some environments you can use JavaScript in securely and marvel at the magic and annoyances that are technologies that try to put a lock on the issue of JavaScript security.

A quick trip down memory lane.

When I first encountered JavaScript it was mainly used to do simple calculators, window manipulation and simple form validation. The main interface used was the browser object model with window being the main object and form and element being the collections to manipulate. You added content either by changing the value of a form field or by using document.write() with the latter being different from browser to browser. The other thing you had was the images array and this is what we used extensively to create rollovers.

Event handling was done with on{event} inline handlers and the body always had an onload handler on it.

Bring on the bling!

That however did not stop us from already abusing JavaScript to create pointless bells and whistles. Status bar tickers, title changing scripts and moving popup windows were the first to annoy the end user and they were just the start.

More bling.

With browsers starting to allow you to manipulate more of the document (via document.all and document.layers) and new and bespoke CSS extensions we had even more options to do very annoying and pointless things. Animated menus, rainbow cycling scrollbars, the floating (and flickering) Geocities logo, mousetrails and other abominations were built to bling up our sites and subsequently the audience got sick of JavaScript and discarded it as a toy.

Ajax for the win!

This all changed when Ajax came around and there was no way not to have some way or another you load content on demand using XMLhttpRequest – if you wanted to have a cool web site that is. And of course people used it wrongly.

Security scares.

As people used JavaScript to load information that should not be visible to the world and it is easy to intercept and see everything that happens in a browser in JavaScript we have more and more security scares coming up.

Is JavaScript a security problem?

This bears the question if JavaScript in itself is a security problem and if we should discard it at all.

Security flaws start at the backend but JavaScript gets the blame.

Last week I came across an interesting survey by the security company Cenzic – get the PDF here. They looked at the state of the web and the main security problems in the first two quarters of 2009. The survey showed that the browser was responsible for only 8% of the overall security issues.

One thing that is interesting is that most security flaws start with a problem on the backend but get blamed on JavaScript. XSS is a backend problem, but it becomes a problem as JavaScript is designed to give scripts too many rights.

JavaScript implementation vs. JavaScript

The problem is not JavaScript itself – well, not exclusively – it is mostly the implementation of it in browsers. And funnily enough this is how we measure the quality of the language. It is like judging the quality of a book by its movie.

Browsers don’t care where JavaScript comes from.

To a browser, every JavaScript has the same rights to the content of the page and other things JavaScript can reach – and that includes cookies. When I can steal your cookies I can steal your users’ identities and this is a big security issue.

Browsers are full of security holes.

The other issue is that browsers are full of security faults. This can be interesting as people complain about IE6 and its flaws, but the survey actually ranked Firefox and Safari as the most vulnerable browsers. The reasons are plugins in the case of Firefox and – in Safari’s case – the iPhone. Interesting targets are always successful platforms.

Plugins have and still are a main source for security issues. Especially in the case of IE Flash and PDF display was always a problem. The reason is simple – plugins extend the reach of the browser into the file system and that is an interesting attack vector. So if you offer PDF documents and you want to keep your system secure it might be a good idea to loop them through a script that sets a header that forces user download – this also allows you to add statistics to the PDF downloads.

So we can’t use JavaScript, right?

Which brings a lot of people not to trust JavaScript at all and see it as the source of all evil. Plugins like NoScript are all the rage and the security-conscious are happy to call JavaScript the source of all evil.

It is about spreading the joy of JavaScript.

JavaScript is an amazingly useful part of the interfaces we give our end users. Totally turning it off or not using it means we give up on a lot of things that our users should get and expect from an interface in 2009. I like that I can write a message while an attachment uploads in the background.

Learning JavaScript

The first thing to remember is that this is not 1997. We don’t have to learn JavaScript by looking at other people’s source code. Opera’s web standards curriculum and The Yahoo video theatre are great resources to take your first steps into the JavaScript world.

What to use JavaScript for

The main thing is to remember what we should use JavaScript for:

  • slicker interfaces (autocomplete, asynchronous uploading)
  • warning users about flawed entries (password strength for example)
  • extending the interface options of HTML to become an application language (sliders, maps, comboboxes…)
  • Any visual effect that cannot be done safely with CSS (animation, menus…)

CSS has come a long way but unless you can control the animation and be sure it works cross-browser it is not a replacement. Menu systems using CSS only are a gimmick as they cannot be made keyboard accessible.

What not to use JavaScript for

  • Sensitive information (credit card numbers, any real user data)
  • Cookie handling containing session data
  • Trying to protect content (right-click scripts, email obfuscation)
  • Replacing your server / saving on server traffic without a fallback

What if you need more?

All this becomes an issue when you get into developing large web products where you push the envelope of what can be done with the web and the technologies right now. The new Yahoo homepage is one of these examples – in it we wanted to allow third party developers to build own applications and run them safely inside ours without endangering the privacy of our users.

You can limit yourself

One thing you can do is to limit yourself to the “safe” parts of a language. Douglas Crockford’s AdSafe takes this approach and is meant as a guideline for ad providers.

You can pre-process JavaScript

The other option is to enforce the limitation of the language by pre-processing JavaScript and converting it to a safer subset. The main tool for this nowadays is Caja which has been invented by Google and now made workable by Google and Yahoo for the Open Social platform. Caja converts JavaScript to a safe subset – either on the client or on the server.

Things Caja doesn’t allow you to do

To ensure the security of our applications, Caja stops you from using some things you might have gotten accustomed to using in the last few years.

Caja and HTML

Here are the things you cannot use in HTML:

  • name attributes
  • custom attributes
  • custom tags
  • unclosed tags
  • embed
  • iframe
  • link rel=”...”
  • javascript:void(0)
  • radio buttons in IE
  • relative URLs

Caja and JavaScript

Things you need to keep out of your JavaScript:

  • eval()
  • new Function()
  • strings as event handlers (node.onclick = ‘...’;)
  • names ending with double / triple underscores
  • with function (with (obj) { ... })
  • implicit global variables (specify var variable)
  • calling a method as a function
  • document.write
  • window.event
  • ajax requests returning JS

Caja and CSS

And last but not least things deemed dangerous in CSS are:

  • star hacks
  • underscore hacks
  • IE conditionals
  • Insert-after clear fix
  • expression()
  • *@import

Caja ready code examples

You can find a good collection of Caja ready code examples in the Yahoo Application Platform documentation.

Caja problems and making it easier

Whilst Caja is a great idea to ensure the security of widgets it is not without its problems. If you chose client-side conversion it means a massive dent in the performance of your application and even with server-side conversion it becomes harder to build new systems. For starters, Caja-converted code is very hard to read and therefore debug and in many cases it means that as a developer you need to change your ways.

Libraries and Caja compliance

Much like we fix browsers, we can also use libraries to make our Caja-compliant development easier. The first library to be fully Caja compliant is the Yahoo User Interface library and other libraries like jQuery have also shown interest in compliance.

Abstracting the issue with an own language – YML

The other way to make it easier to write secure code is to abstract most of th changes to our normal development ways out into an own markup language. Facebook had done this and in Yahoo’s case there is the Yahoo Markup language or short YML. Using this language in a widget for the Yahoo homepage you can do Ajax requests and dig into the Yahoo social graph without having to write any JavaScript or server-side code.

Extending browsers

Another interesting way to make JavaScript development more interesting is to think about browser extensions. This starts with GreaseMonkey which allows Firefox users to extend any web site out there with new functionality using a few lines of Dom Scripting – a great way for example to do quick prototyping. Google Gears, Yahoo Browser Plus and and Mozilla Jetpack kick this idea up a notch and give you new APIs to extend the reach of the browser into local storage, allow for database access in JavaScript and give you worker threads to do heavy computations without slowing down the main interface. These extensions give browsers the power we would love to have to be able to deliver real applications inside browsers.

Moving out of the browser

The other thing you can do with JavaScript these days is to move outside the browser and take your HTML, CSS and JavaScript solutions to other platforms.

Widget frameworks

Widget frameworks have been around for a while with Konfabulator and Apple Dashboard widgets leading the way. Opera also allows you to run small applications outside the confines of a browser window. The interesting thing about widgets is that they always looked much prettier than most web solutions – mainly because PNG support was a given and not something you had to hack for MSIE.

W3C widgets

W3C widgets are a standard that allows you to zip up an HTML document with CSS, JavaScript and images and run it as a self-contained widget. Peter-Paul Koch has written a great introduction to W3C widgets and several mobile phone providers (first and foremost Vodafone) offer a way to run these widgets on handsets without the need to learn any mobile OS language or tools.

Adobe Air

Adobe Air has made it possible for web developers to write full-blown installable applications that run across several operating systems and have access to databases and the file system. Probably the most successful apps are Twitter clients and music apps like Spotify.

Command line JavaScript – Rhino

If you don’t like all the fancy visual stuff and you want to use JavaScript to do some heavy data conversion you can use JavaScript on the command line using Rhino which is a Java implementation of JavaScript. The really cool thing about writing JavaScript for the command line is that it supports all the features of the language and you are not at the mercy of a browser to do it right.

Turning JavaScript Mashups into web services.

One rather new opportunity for developers is that you can use YQL or Yahoo Query Language to easily mash-up and filter data from several data sources on the web. YQL allows you to:

  • mashup data with a SQL-style syntax
  • filter down to the absolutely necessary data
  • return as XML, JSON, JSON-P and JSON-P-X
  • use Yahoo as a high-speed proxy to retrieve data from various sources.
  • use Yahoo as a rate limiting and caching proxy when providing data.

Retrieving data from an HTML document and choosing the right output format

Using YQL it is dead easy for example to retrieve the headlines from an HTML document with the following statement.

select * from html where url=”” and xpath=”//h3”

YQL is a web service in itself and you can retrieve the data returned from this request in different formats.

  • XML returns the data as an XML file which is not that useful in a JavaScript environment.
  • JSON is natively supported and therefore much easier to parse.
  • JSON-P wraps the returned JSON object in a JavaScript function call and thereby makes it very easy to use in a script node (either hardcoded or created on the fly).
  • JSON-P-X wraps the returned JSON object in a JavaScript function call and returns the XML content (in this case the scraped HTML) as a string. This makes it very easy to use innerHTML to render the data in a browser without having to loop through the JSON object and re-assemble the string.

Retrieving photos for a certain geographical location

As a demo, try this out. In order to retrieve photos for a certain geographical location you can use the geo and Flickr APIs in a single YQL statement:

select farm,id,secret,owner.realname,server,title,urls.url.content
from where photo_id in(
select id from where woe_id in(
select woeid from geo.places where text=”london”


Try it out in your browser to see the resulting data.

Using a few lines of DOM scripting you can turn this into a nice web site showing these photos.

Moving JavaScript solutions into YQL to turn them into web services

The problem with the solution above is that you make yourself dependent on JavaScript to show these photos. If you want to still use JavaScript but allow users without it to see these photos you can use a YQL open table with embedded JavaScript to do the conversion. YQL uses Rhino to run and execute your JavaScript server-side and returns you the content you created inside an XML or JSON file. As JavaScript is executed on the server, you have full E4X support to make the use of XML painless and you can use advanced JavaScript like for each:

var amt = amount || 10;
var query = ‘select farm,id,secret,owner.realname,server,title,’+
‘urls.url.content from where ‘+
‘photo_id in (select id from‘+
amount + ‘) where ‘;
query += ‘woe_id in (select woeid from geo.places where text=”’ +
location+’”) and ‘;

query += ’ text=”’ + text + ‘” and license=4)’
var x = y.query(query);
var out =

This, embedded in an open table means you can retrieve photos from Flickr as a UL now using the following YQL statement:

select * from flickr.photolist where text=”me” and location=”uk” and amount=20

You can then display the photos returned with PHP:

$url = ‘;%20select%20*%20from%20flickr%20where%20text=%22me%22%20and%20location=%22uk%22%20and%20amount=20&format=xml&diagnostics=false’;
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETRNTRANSFER, 1);
$output = curl_exec($ch);
$output = preg_replace(‘/.*
      $output = preg_replace(‘/
$output = preg_replace(‘//’,’‘,$output);
$output = preg_replace(‘//’,’‘,$output);
echo $output;

Or with a very simple JavaScript, thanks to the JSON-P-X output format:

Another example – scraping HTML from web pages that need POST data

Another powerful example of what you can do with JavaScript when you embed it into a YQL table is the following:

Christian Heilmann
HTML pages that need post data
select * from {table} where
and postdata=”foo=foo&bar=bar” and xpath=”//p”]]>

As explained in detail in this blog post this JavaScript extends the HTML scraping option of YQL to allow for POST data to be sent to a document before retrieving the HTML:

select * from htmlpost where
and postdata=”foo=foo&bar=bar” and xpath=”//p”

Notice that YQL execute gives you full REST and HTTP support and has the xpath conversion built-in as a on own function.

oAuth in JavaScript – the netflix example

Another interesting example is the open table provided by Netflix, which shows you how you can use oAuth in JavaScript:

// Include the OAuth libraries from

// Collect all the parameters
var encodedurl = request.url;
var accessor = { consumerSecret: cks, tokenSecret: “”};
var message = { action: encodedurl, method: “GET”, parameters: [[“oauth_consumer_key”,ck],[“oauth_version”,”1.0”]]};

// Sign the request
OAuth.SignatureMethod.sign(message, accessor);

try {
// get the content from service along with the OAuth header, and return the result back out
response.object = request.contentType(‘application/xml’).header(“Authorization”, OAuth.getAuthorizationHeader(“”, message.parameters)).get().response;
} catch(err) {
response.object = {‘result’:’failure’, ‘error’: err};

Liberating our JavaScript

As you can see switching environments liberates our JavaScript solutions and gives us much tighter security. So open your minds and don’t judge JavaScript by its implementation. Instead have fun with it and use it wisely. With great power comes great responsibility.

An explanation for all conference organizers who need slides upfront

Tuesday, November 25th, 2008

Calvin and Hobbes Cartoon - Inspiration needs the right mood - Last Minute Panic

Found via the fabulous Searchable Calvin and Hobbes Archive