A better way to describe RESTful architectures: Richardson Maturity Model
[video]
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 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.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.
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).
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 Basic and Digest authentication schemes are provided for by the HTTP specification.
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.
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.
Jeff Bezos and the Story of Amazon
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.
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 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.
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.
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
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");
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.
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:
You’re Auskey will now work again.
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.
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.
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:
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.