What Everyone Should Know About REST: Talk at Web Directions Code

Here are the slides:

Slides: What Everyone Should Know About REST

Sketchnotes

Thanks UX Mastery for the sketchnotes, they are awesome! (Seriously, I would be much more swayed to speak at any conference with sketchnotes because it’s a straightforward permanent memento, a better snapshot than slides or video.)

Overall, it was great to be associated with another fine Web Directions conference and the Melbourne Town Hall venue was amazing. I only regret that we were so busy scrambling on the Android app, after launching just a few days earlier, to be around the whole time. But this being my hometown — I’ll be back!

Talk Structure

I spoke at Web Directions Code on Friday, a talk on REST. I’ve been putting a lot of this into practice lately, and the talk was really an attempt to convey the main practical things every developer should know. The structure was:

  • Everyone should know about REST because it’s not just about websites anymore. Devices, whether computers, fridges, or wearable glasses – are connected, and device-to-device communication happens with web standards, i.e. HTTP. The talk covered three things about REST: Simplicity+Consistency; Security; Caching.
  • Simplicity+Consistency: Emphasising Developer Experience (#devexp) was a way to frame the general concepts, ie URLs, HTTP methods, response types.
  • Security: How the web is becoming SSL-only, and various authentication schemes. I referenced the latest Traffic and Weather, which has a good discussion on this.
  • Performance+Scalability: Mostly about caching. I’ve been musing on REST caching quite a bit for Player FM’s API (most recently thinking about a kind of reverse patch protocol, where the server can send out diffs that get cached), and explained some of the standards and tricks for squeezing efficiency out of the network.

What Wasn’t Covered

  • I didn’t go into the REST acronym or the general theory of REST as an architectural pattern arising from specific forces.
  • SSL and caching. Good Twitter conversation afterwards about this point, that you can’t cache in the middle of an SSL connection. The answer is to split the connection in the middle and run SSL on either side, with a trusted cache seeing plain-text in the middle. This is how Cloudflare works, and the CEO Matthew Prince chimed in to say it will be free soon. (At least, SSL from client to Cloudflare.) So that means the SSL-protected web could triple overnight.

Async Talk on Chrome Extensions and Chrome Web Store

I gave a talk last night at Async, a fortnightly meetup for Brighton’s ever-thriving JavaScript community, organised by the talented Prem Rose. The talk was on Chrome Extensions and the Chrome Web Store, and was a mashup of our separate GDD talks on those topics (GitHub), some live coding, and some new stuff now that the Web Store is live…though the main focus was Chrome extensions.

Slide Deck: Chrome Extensions and the Chrome Web Store

A fun part of the talk was live coding. I haven’t done it before, but I felt it went well and was definitely worthwhile. The project was an extension to show the latest blog posts on the Async website, in a toolbar button (aka browser action). Chrome extensions are a lot easier to write than most people imagine, so it was an effective demo to start with a new directory and make it happen. For the record, here’s the extension we hacked up in 15 minutes or so: async.crx. (Styling was not the main focus of this exercise :) ).

I also did something I’ve been meaning to do for a while: A Venn diagram to illustrate the relationship between extensions, packaged apps, and hosted apps:

Finally, I had a good question about detecting if you’re website is running as an installed app. I couldn’t remember the details, but they are here:

javascript
< view plain text >
  1. if (window.chrome && chrome.app && chrome.app.isInstalled)

(Updated the snippet following Johan’s suggestion in the comments.)

HTML5 in Kiev

I’ve been in Kiev, Ukraine, this week, where I was fortunate to attend several events. The developers in this country and this region are super-talented, and I’m glad I was able to meet many of them directly.

Casual Connect

As with CC Seattle, there’s a big focus on social games right now. They are not only better for distribution – the viral nature – but often more profitable due to revenue sources which have no/little relevance in a single-player context. Namely, status-improving virtual goods; status-improving level advancement by way of automating/bypassing the grind; and, controversially/riskily, improving player capabilities.

I gave the following presentation on HTML5 Gaming. Fortunately, the HTML5 Game Jam we ran a couple of weeks earlier provided great evidence that it’s here and real, and I was able to make use of that in the examples. (I also came up with the idea of an iFrame player for these slides; so you can click on some screenshots to replace them with an iFrame showing the game. This is raw and needs more work, e.g. a big play button for starters.) All this emphasises the importance of micropayments/in-app payments for the social gaming segment.

The biggest concern game developers have with HTML5 is graphics capability. Handling a hundred avatars real-time on the screen at once, that kind of thing. I hope to work with a few of them to get some useful data and feedback for the browsers.

HTML5 Game slides

SPA Hacks: Hacks Emerging From the World of Single-Page Web Apps

This is a permalink for my JSConf.US talk. Full slides are online here:

THE LOST HACKS: Ridiculous browser tricks from the world of single-page Applications

The talk will overview TiddlyWiki and Single-Page Apps, and then cover eight specific hacks:

  • File access without browser extensions
  • Javascript-HTML chameleon files
  • SVG-VML chameleon files
  • Inline SVG
  • iFrame squriting
  • Script islands
  • Embedded images
  • Fragment IDs

I’ll be posting a link to the slideshow notes from here. I’m pleased to say the nascent TiddlySlidy app has been a pleasure to dogfood it in.

[Image credits]

What’s New in On-Demand Javascript? ScaleCamp Presentation

These are the slides from my ScaleCamp presentation, covering various techniques for various styles of On-Demand Javascript, including Script Islands, “async” and “defer” attributes, and library support.

One of the interesting things at ScaleCamp is that many of the folks there are dealing with third-party advertisers and analytics providers. This leads to very different on-demand Javascript drivers from those of us mostly dealing with enterprise web apps. If you’re a small fish in a big pond, you’re pretty much held hostage to the script tags of leading advertisers and trusted analytics companies in your industry; if they serve the script slowly, it blocks your page from loading and therefore messes with user experience. That’s why some of these new techniques are so critical, notably the dynamic async script tag technique the Google Analytics came out with at a very timely moment, just a couple of days before this presentation.

Design Pattern: Script Islands

“Script Island” is what I’m calling a design pattern I alluded to here. The pattern is to embed Javascript in your HTML like so:

  1. <script id="greeting" type="x-deferred-script">
  2.   alert("this is my script - it's eval'd on demand");
  3. </script>

When the page loads, the browser should say “I don’t know what ‘x-deferred-script’ is, and therefore ignore the concents of the script tag. You eval it manually later on, using something like eval($("script#greeting").html()); This is similar to Google’s trick of embedding Javascript in comments, but has the additional benefit of keeping Javascript where it should be, in a script tag. This way, it plays nicer with code editors (e.g. Vim happily handles syntax highlighting) and analytical tools. (Technically, those tools should probably do the same as browsers and not treat anything inside a script tag as Javascript, but fortunately for us, they do.)

Script Islands are useful in the following situations:

  • With a complex web app – lots of Javascript – where you want it to load quickly and without lots of processing or round-tripping back to the server. Sometimes, it’s a better user experience to load the lot in one go, show something, and eval() the rest of the Javascript once the basic app is running (perhaps in anticipation of a separate “page” or another part of the application). This is a special case of Predictive Fetch; it makes sense Google would use (a variant of) Script Island for the mobile edition of GMail, where round trips to and from the server are expensive.
  • With a single-page application (SPA) like TiddlyWiki, where all the code is inside the HTML file. Each of the script islands is a separate module, and a microkernel is responsible for loading the scripts according to different rules. For example, the scripts might contain “depends” attributes to declare they depend on other scripts, so the microkernel sequences the script loading. Or another scenario might be that the user has some control over which scripts get loaded; instead of deleting the other scripts from the file, you keep them around in case the user wants to repackage the SPA, with a different set of scripts.

BTW I originally used <script src=""> to trick the browser into not evaluating the script tag’s innerHTML. Thanks to Jeremy for coming up with the more elegant alternative of a type=x-tiddler (which I stated above in the more generic form type=x-deferred-script).

FossBazaar at Open World Forum (OWF), Paris, Oct-2009

Quick notes from today’s FOSSBazaar event at Open World Forum in Paris. Usual caveats on typos etc as I was writing these notes live.

Martin Michlmayr overviews FOSSBazaar

IMG_0069 (by mahemoff)

Procurement – might like to avoid, but they have a really important role to play. With open source, it’s easy to ignore procurement – why go through procurement when you can download it! Great, that saved me several weeks of work, I can go home now :). But then you ship the code a few months later with GPL.

Make FOSS “business as usual” – how acquired, chosen, used, supported, updated, project tracked, licensed, mature.

FOSSBazaar to help people manage these issues. Good to have members outside of the US (Europe and maybe some now joining from Asia) as issues are different; this is the first FOSSBazaar meeting here.

FOSSBazaar for experienced users – working together to define standards and best practices

FOSSBazaar for inexperienced users – learning about open source issues, reducing the fear

Discuss, resolve, and document the “hard” issues related to adopting FOSS in the enterprise.

Question – why is HP spending money supporting the community? Martin explains HP has some experience dealing with compliance issues. Want to share experiences, e.g. we explained how we explored Palamida; other companies might do the same with Black Duck. It’s been a really good experience, talking to people who we might otherwise have not talked to.

Open Source Compliance – View of Validos. Martin von Willebreand (lawyer basedin Finland).

IMG_0070 (by mahemoff)

Vaidos has DB of 130+ packages validated.

“Shall we use this package or not?” Validos adds legal validation

Shows DB report showing licenses being used in a package.

Talking about typical guidelines, e.g. distributing the licenses with the code. Putting license on your website isn’t really redistributing it.

Showing how they prepared a document for republication. It’s big, it’s scary, and it’s very likely necessary for legal purposes. [Kind of sad that open source gets this complex - makes me feel like just releasing all my code as public domain; losing attribution would be a shame, but the real downside would be the risk of liability if there's no warranty. It also makes me think that licenses should be embracing the web more, instead of forcing all this stuff to be repackaged - cut-and-pasting a URL would be a good start to what is a long path.]

Martin comments FOSSBazaar has been thinking about standardising some of this license declaration stuff; and there was a parallel effort recently which he’s hoping to work with.

IP Tracking Methodology at INRIA

IMG_0074 (by mahemoff)

On the forge: 1600 projects; 400 open source.

Done various tracking and would be good to compare methodologies, work together on tools.

Discussion session – Working on a Creative Commons contract to establish relationship with contractors, ensuring they use open source the right way.

TiddlyGuv Tool (the bit with me in it)

Steve Barnes motivated the tool from his perspective as a governance administrator. I then gave a demo and explanation.

IMG_0081 (by mahemoff)

Feedback:

  • Possible to get metadata e.g. to get XML feed. [Yes. Showed the bags/tiddlers model in the browser and how you can easily get a list of JSON or txt. Made the mistake of not demoing xml, which would have taken all of 5 seconds. Take off the pro-json blinkers next time!)

  • Can I see which packages (components) are using a paricular license?

  • What does a software policy look like? Do we need them at all. [Steve explained we probably wouldn't want to have a blanket policy like "don't use GPL", though others could; the tool lets you declare whatever policy you like.]

  • It should be more about training than official policies. [I explained TiddlyGuv is intended to be a tool for developers and governance authorities to work together, share information, leave comments, etc.; not a rigid policing-the-masses weapon]

FOSSology

IMG_0089 (by mahemoff)

Disclaimer that you need more than just tools and need other tools too.

Looks at every single file in a package – fuzzy match against a library of >400 known license.

Walks through demo. Can try online.

Many new features – email notifications, new licenses, tutorial section, cleanups.

Plans – new license analyser (based on phrases); concept of license categorisastion (e.g. “good license”/”commercial license”)

Question regarding international labour organisation – what happens if a child developed code and contributed it? Do they have the legal authority to donate the code etc. Is there a child labour question? Martin notes international treaties as a similar issue – notes you’re not allowed to distribute code from one country to another; how do you accept contributions across that boundary. It’s a potential FUD issue people can use against open source in government.

Community Management and Project Governance: A checklist with an attitude Charles-H Schultz

IMG_0094 (by mahemoff)

Good “HowTo”/tutorial presentation of governance on a particular projct.

Not just about making code available. but make it easy to find – e.g. when it’s on sourceforge, but not linked easily from project page.

You never manage your community; so “community management” doesn’t exist. - fair, transparent rules and governance - soft power - trust employees like you trust other contributors