laurence.io

December 4, 2012 at 11:04pm
0 notes

A better way to describe RESTful architectures: Richardson Maturity Model →

November 30, 2012 at 12:01am
0 notes

Mashups: fan-fiction for music.

Do you have that friend who read Harry Potter fan fiction? Maybe you’re lucky and know someone who dips his/her quill and scratches homages to their favourite worlds?

However I ask you, why do we sneer at fan fiction but bop to the spliced beats of mashups?

A mashup is simply fan-fiction for the music world.

Fan fiction stories are written by fans that extend the world and plots of adored novels.

Entire internet communities are dedicated to sharing and indulging in these homages. They might “correct” the story line, perhaps allowing the leading man and his female companion to live happily ever after. They provide the relief that another chapter offers.

When the story ends and the book closed, are we not killing the friends we made along the literary journey? They have no more words to say, adventures to experience or love to give. Why not preserve their memory and give them a few final moments, and bask in their accomplishments by the electric shock of fan fiction.

Mashups, on the other hand, are songs blended together by the music literate who share their love of music and introduce something new made from the old to the rest of us - often to our amazement and sometimes to our horror. Like a phoenix rising from the ashes, two songs are burned (to CDs), mixed on decks, and out of the fire comes a fresh new beat.

It mixes a sense of familiarity and safety, with mystery and wonder. We explore a new aural landscape but with familiar friends and faces.

The next time you find your foot tapping along to a fresh but familiar beat - consider your literary inclined friends; or maybe revisit a long-lost character from your favourite novel.

November 27, 2012 at 2:49pm
0 notes

Restful Authentication: Tokens or Cookies

What’s the best way to authenticate clients for RESTful web services?

The clients may be AJAX (or single page web applications) running in the web browser or other machine-services.

Cookies

Cookies are easy to use for both native browser-based applications (HTML forms) as well as AJAXy applications.

A simple design might be:

  • POST /session creates an authenticated session and returns a set cookie.
  • DELETE /session/:id will logout/remove the session and cookie.

Tradeoffs

Difficult for a single-page web application to check its authenticated state without performing a request. You necessarily incur network latency at application start even if all other resources are locally cached. > 200ms may mean the difference between instant and regular web site.

This approach works well for native browser applications (HTML forms) because the login forms can be customised (as opposed to native HTTP authentication).

Cookies are easy to implement and typically supported by web application frameworks. This approach won’t add to the implementation effort.

API Tokens

An API token is a server or client generated token that is appended to each HTTP request as part of the URI (or request body).

Tradeoffs

Machine services can consume a service easier using an API token: it’s easier to append a query parameter in HTTP libraries than to setup cookie handling.

These tokens break HTTP caching because the URL changes per session.

It is not intuitive how session management would work this approach: how do you log out?

Web applications cannot have persistent sessions (between application starts) without resorting to cookies or storing the API token in HTML5 localStorage.

This approach is the same as using cookies but shifts the burden to the developer to append credentials to each request.

HTTP Authentication

HTTP Basic and Digest authentication schemes are provided for by the HTTP specification.

Problems

These solutions don’t allow the login process to be customised and provide a bad user experience for logging on (standard forms are used). Similarly, no session management options are provided and you cannot logoff.

Ideal Solution

Pick the right tool for the job. I personally use cookies as described above for most projects, but there are times when other implementations are more appropriate (when it will only be used by machine-services for example).

This is a brief (and incomplete) summary of the issue. For more information, see the plethora of questions on StackOverflow.

12:21pm
0 notes

Jeff Bezos and the Story of Amazon →

12:09pm
0 notes

Why Myers and DJs' Online Plans Won't Work →

Basically, consumers in the US have a “very strong catalogue culture" whereas customers of large retail stores like Myers and David Jones just walk in to browse.

June 18, 2012 at 1:22pm
0 notes

Perfect Dev Environment for Building Single Page Web Apps.

jQuery (+ mobile), Backbone.js, Coffeescript and HAML-Coffee.

I started building a single-page mobile web app side-project on the weekend (hopefully I’ll release it in the coming weeks). I spent a couple of hours creating the perfect development environment - its definitely share-worthy so here it is.

Node.js + Express

Node and Express provide the basic compilation architecture. connect-assets is responsible for compiling and minifying all of my client-side code. This means that I can develop and use refresh to recompile.

haml-coffee is my client-side templating language. connect-assets will compile all of the templates into .js files and then automatically include them so you don’t have to worry about dependency management. stylus is similarly used for all my stylesheet needs.

Directory Structure

Your entire client-side application lives in assets. This directory is compiled for each request (basically turned into single .js files, etc).

  • assets/js - put all of your application code here (and any other libraries that you want included and minified into your application code).
  • assets/css - stylesheets.
  • assets/templates - all of your hamlc templates go in here.

The other important file is your views/layout.jade file. This file generates the page that you will request from the browser and that will run your code. Basically you need to make sure you include your main application file and any other assets you need. For example:

link(rel='stylesheet', href='/stylesheets/style.css')
link(rel='stylesheet', href='http://code.jquery.com/mobile/1.1.0/jquery.mobile-1.1.0.min.css')
script(src='https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js')
script(src='http://code.jquery.com/mobile/1.1.0/jquery.mobile-1.1.0.min.js')

!= js("underscore")
!= js("backbone")
!= js("swipe")

!= css("style")

!= js("app")

The difference between script(src='https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js') and != js("underscore") is that the former is loaded from an external site, while the latter is included as part of my application and will eventually be minified into just a single app.js.

Including Other Files

This workflow uses snockets (node version of sprockets) to manage dependencies. Including another file is as simple as putting a comment at the beginning of the file:

#= require ../models

Similarly, you can require a whole directory (including sub-directories) of files by using require_tree as such:

#= require_tree ../templates

Configuration

Important tidbits for configuration - you need to add these lines to your app.coffee file to get it to work properly.

hamlc = require("haml-coffee")
assets = require("connect-assets")

app.register '.hamlc', hamlc
assets.jsCompilers.hamlc =
  match: /\.js$/
  compileSync: (sourcePath, source) ->
     assetName = path.basename(sourcePath, '.hamlc')
     compiled = hamlc.template(source, assetName)
     compiled

app.use assets()

In order to use a Coffeescript app.coffee file - you should also create a server.js which is what you’ll actually run with the following in it:

require("coffee-script");
require("./app.coffee");

Fin.

To use the app simply run node server.js and navigate to localhost:3000.

That’s the workflow - it’s amazing quick to build and experiment with and let’s you nicely build single-page web apps.

A special thanks to @vrouesnel (blog) for hooking me up with this environment.

April 27, 2012 at 9:14am
0 notes

Using an Auskey on Mac OS X Lion

If you’re using an Auskey and you upgraded to OS X Lion you may find that you can no longer login to the ATO Business Portal.

The fix is very simple:

  1. Open Java Preferences (search for it using Spotlight by pressing Apple-Space and typing it in).
  2. Check the ‘Enable applet plug-in and Web Start applications’
  3. Restart Safari.

You’re Auskey will now work again.

8:49am
0 notes

Keeping Today Clean

Never have a list of things you have to get done ‘today’ that lasts longer than ‘today’.

I use Things to store and plan tasks that I need to get done. When I first started using it, I would stack up my ‘Today’ list with aspirations - things which I thought I might be able to get done today. Then I would come back the next day. And they would still be there. And then the next, and there would even be a couple more items which I need to get done.

It’s pretty disheartening to look at a long list of tasks you should be doing every morning. It hurts even more when its not really stuff you really care about.

The list of stuff you need to get done today should not be aspirational.

By having a long list of tasks I’ll never get around to doing, it reduces the value of the list: I never get around to doing half of the stuff and it doesn’t seem to matter (because you’ll always get the important stuff done regardless). It also disincentivises me from checking it - why face this giant list that makes you feel bad?

I realized that I had to take control and stop using my task manager as an aspiration planner. Every morning I now compose a couple of ‘must complete’ items into my Today list. When those are done, I can tackle others from the ‘Next’ list. No more big hairy scary lists.

April 22, 2012 at 8:48am
0 notes

Different Reasons for Concurrency and Solutions on the JVM →

Really interesting slide set on managing state on the JVM and the different problems we try and solve with shared state.

April 21, 2012 at 8:08am
0 notes

A Better Website Editing Workflow: Word to Markdown

For the SULS website, most people prefer to submit content in Word format (docx or doc). This presents a slight problem since the website uses Markdown for content.

The solutions:

  1. manually convert the word files to markdown (extremely tedious and spirit crushing);
  2. teach everyone how to use markdown;
  3. automatically convert the word files to markdown.

The second option seems reasonable, until attempted in practice. Markdown is an extremely simple format - and most people seem to get it really quickly. The problem is that the workflows for producing it are terrible. If people don’t use a dedicated editor on Mac, they tend to use TextEdit which spits out RTF files which have to be manually converted regardless. While software like Mou exists which is fantastic, not everyone has the latest version of OS X (which is required by Mou) or even runs Mac. On Windows, the WYSIWYG editor situation is pretty horrific as well.

Most of the Word content is actually pretty trivial (no complex formatting) - therefore automated conversion actually has a chance of working well. So, how do we do it? David on StackOverflow helpfully provides a solution:

textutil -convert html file.doc | pandoc -f html -t markdown -o file.md file.html

This actually works surprisingly well - however it does have some minor issues converting links and other things. It does reduce a lot of the legwork out of manually converting a lot of the content.

The main shortcoming seems to be with textutil's conversion of doc to html. This could perhaps be remedied using Google Docs. One potential solution is to pull down all the website content dynamically from Google Docs as html at compile time and then convert it to md. This could provide a nice and seamless editing workflow.