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.
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 are easy to use for both native browser-based applications (HTML forms) as well as AJAXy applications.
A simple design might be:
POST /sessioncreates an authenticated session and returns a set cookie.
DELETE /session/:idwill 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.
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.
This is a brief (and incomplete) summary of the issue. For more information, see the plethora of questions on StackOverflow.
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.
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.
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/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
!= 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
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
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:
To use the app simply run
node server.js and navigate to
That’s the workflow - it’s amazing quick to build and experiment with and let’s you nicely build single-page web apps.
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:
- Open Java Preferences (search for it using Spotlight by pressing Apple-Space and typing it in).
- Check the ‘Enable applet plug-in and Web Start applications’
- Restart Safari.
You’re Auskey will now work again.
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.
Really interesting slide set on managing state on the JVM and the different problems we try and solve with shared state.
A Better Website Editing Workflow: Word to Markdown
For the SULS website, most people prefer to submit content in Word format (
doc). This presents a slight problem since the website uses Markdown for content.
- manually convert the word files to markdown (extremely tedious and spirit crushing);
- teach everyone how to use markdown;
- 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
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.