Singlecell, the Angry amoeba weblog

What does HTML5 mean for viral video?

2010-01-15T00:00:00+00:00

Okay, so I’m basing my optimism for HTML5 video on a hypothetical future where Internet Explorer vanishes from the earth, and even in the browsers that do support it, codec support is inconsistent, but in my opinion those differences will become meaningless very rapidly because there is only one truly dominant browser engine in the mobile space, and it’s Webkit. And mobile is where HTML5 video will truly shine, because you don’t get Flash video on the iPhone and you do get Webkit. I wish it were more complicated, I really do. If it were more complicated I could make some extra money as a consultant.

I digress. Or rather, because the digression occurs so early, I fail to begin. So let us begin.

Where does the value in viral video come from?

Why are agencies able to charge gigantic sums for the privilege of having their brand associated with a video of fifteen hundred people being a bloody nuisance at King’s Cross station? Firstly, it builds intangible value. Exercising control over any large brand has traditionally been an epic, thankless task, so the concept of simply producing something amusing and using people’s newfound capacity for mass sharing as a delivery and targeting strategy was a bit of a sensation.

Secondly, an embedded flash video naturally must come with a user interface, which means interactivity. And where you have interactivity you can generate clicks that lead directly to your product. The value comes from not just embedding the video, but embedding the video player with all its little hidden engagement-measuring technology and up-front calls to action. In most commercial video environments, the content itself is just a tiny part of what gets delivered to the user’s browser.

HTML5 video is referenced assets, not embedded behavior

Now. HTML5’s new <video /> tag lets us deliver the content - the video file itself - but it does not let us deliver all the other bits and bobs that make web video so valuable. Video rendered with the <video /> tag will have no interactive elements such as advertising or social features, nor will it have the ability to share an embed code for itself. These features must now be delegated to the HTML and Javascript around the video player rather than being encapsulated within it.

This behavior makes sense, given the semantics of HTML - much like the <img /> tag, the <video /> tag is a dumb reference to an external asset, and the browser is free to ignore it, use the alternate text, or render it depending on the situation and its capabilities.

What’s missing from the HTML5 picture?

The point I’m trying to demonstrate here is that the <video /> tag is just a small part of the puzzle for video on a post-flash web. As a video publisher, I want to be able to deliver a player - not just a video file - to users, and make it easy for them to share that experience with others.

“But Dan,” I hear you cry, “you can just build a player out of markup and javascript!” And indeed you can. Youtube already have an excellent duplicate of their flash player built in HTML5, after all. But let’s look at the problems of sharing such a player.

First, you’re going to try having users copy and paste the gigantic wedge of markup and javascript that make up your player. This will fail for a few reasons - most notably, you can’t release patches for the player once it’s been embedded, and you must implement permanent URLs for your video assets.

Then you’re going to refactor the bloody thing to something like this:

<script type="text/javascript" src="http://mysite.com/player.js?replace=thevideotag" />
	<video src="http://assets.mysite.com/some-overdone-meme-lol.mp4" id="thevideotag" />

Which is cool, because if the Javascript fails then you still have the video tag to fall back on. However this will also fail, because you can’t share <script /> tags on forums or social networks for security reasons. And that pesky asset URL problem is still there.

“Eureka!” You will think next, “I will serve the player remotely from my application as an HTML5 document unto itself!” And that is a good suggestion. However, the only way to embed such an application is by using an <iframe />, and that is, to be blunt, fucking disgusting. You can’t use iframes on most forums or social networks, and they have absolutely monstrous security problems. They also have very poor semantic value for the use to which we want them put.

HTML5 is supposed to be an application markup language. It’s not just for documents anymore. The standard is absolutely lousy with interesting interactivity (such as OS-native drag and drop), but it contains no firm way for applications to be nested or otherwise made modular.

For this, I have a suggestion. I would like to see the following work in HTML5:

<embed type="text/html" width="800" height="450" src="http://mysite.com/player.html?video_id=FOO" />

No, you haven’t gone mad. That is an <embed /> tag. Yes, they’re disgusting. But they also match the semantic we want - we want an embedded application which just happens to have been written as an HTML5 document. We want the security domain inherent to embed tags, which allows the host document to remain opaque to the client document at the host browser’s discretion. This is the semantic I would like to see for embedded applications in HTML5.

Update: When publishing this post, and thoroughly buggering up my code sample escapes, I noticed that the above embed code actually renders in webkit! No Firefox support though, alas.

Developers and the Kübler-Ross model

2009-09-30T00:00:00+00:00

The Kübler-Ross model is a classic pattern that defines how people deal with great loss or catastrophe. It’s the five-stage grief model so beloved by TV scriptwriters - an array of shows have made use of the model, most notably this brilliant episode of The Simpsons in which Homer learns of his own impending demise:

Hibbert: There are five stages. First is denial.
Homer: No way, because I'm not dying.
Hibbert: Next comes anger.
Homer: Why you little...
Hibbert: After that comes fear.
Homer: What's after fear? What's after fear?
Hibbert: Bargaining.
Homer: Doc, you've got to get me out of this. I'll make it worth your while.
Hibbert: And finally, comes acceptance.
Homer: Well, we've all got to go sometime.
Hibbert: Mr. Simpson, your progress is remarkable!

It only occurred to me recently that the same model applies to a developer being told that his work has a bug. Not just a simple display bug, but one of those really nasty voodoo buggers that defy all attempts at rational explanation and turn debugging into a two-day stretch of swearing, shouting, and occult sacrifices. Observe:

Denial

Nah, that works just fine. Must be a freak happenstance, or the user’s machine is knackered.

Anger

Why do people bring me all these problems? Give the users better training!

Bargaining

Maybe we can just fix it in the next version, so I can get on with my life?

Depression

This problem will never go away. It’s going to actually haunt me until I die. I am Moby Dick to this bug’s Ahab.

Acceptance

If I fix this, I can have my life back.

Charging for the last inch

2009-06-18T00:00:00+00:00

When apple announced the iPhone OS’ new capability to provide a tethered cellular data connection to your laptop, the masses rejoiced. When some carriers announced hefty additional charges for the privilege of using your ‘unlimited’ data plan on a larger screen that you already own, the masses wept. It was as if a great many voices cried out and then were suddenly compelled to create a new trending topic on Twitter.

The problem, it seems, is that O2 promise to give you unlimited¹ use of your iPhone’s data connection, on condition that you do not take them up on the offer². The deal as they see it is that you can consume a reasonable amount of data on your iPhone itself, but if you want to view that data on a big screen - say, a laptop you already own - it’ll cost you another £13 per month for the privilege. For those playing along at home, that’s the same price as a standard O2 USB modem plan, only they don’t give you the modem.

Therein lies the obvious question. Why does it cost more to download a reasonable amount of data to my laptop than to my telephone, especially when the difference between the two is rapidly thinning?

For those who feel that being charged £13/mo to deliver data over the final inch between your phone and your laptop is an insulting proposition, you know have another option. One brave soul has created a small web application that provides tethering configuration for almost any carrier, enabling iPhone tethering without forcing you to buy a costly data plan in addition to the one already included your standard iPhone contract.

For those who choose this path, there are a few immediately obvious ways to profile a user’s connection to determine whether or not they’re tethering, so be mindful:

If your user agent string is anything other than Mobile Safari, then you’re tethering.
If you’re loading Flash movies, then you’re tethering.
If you’re loading Java applets, then you’re tethering.

Whether or not the operators will act on this finding is unknown.

Disclosure: I already hold a data contract with O2 and don’t plan on getting rid of it, as I find the USB modem very useful.

Footnotes:

May in fact be strictly limited
The use of terminology like “unlimited within fair use” is a long-standing tradition among mobile operators, who have no problem using double, triple or even quintuple negatives if it’ll shift more phones.

The Internet Mapping Project

2009-05-05T00:00:00+00:00

Kevin Kelly, of Wired fame, has launched a lovely collaborative project to map the Internet, sensibly named The Internet Mapping Project.

The goal is for individuals to try and map the hairy N-dimensional structure of the Internet into a two-dimensional representation that matches their own interpretation of it, but the interesting twist is that contributors are expected to place their ‘home’ on the map. The split in designs is interesting - some contributors have drawn the internet from a position of consumption, placing their home at the center of a network of services, while others have drawn their maps from a position of oversight, trying to make sense of the many brands and roles that dominate our lives online.

I decided to try my hand at contributing myself, so I spent an hour this morning with a biro trying to make sense of the thing. I wanted to illustrate the difference and interdependence between things online that are predetermined, and things online that just happen. It also amused me to depict ‘the bubble’ as a self-contained structure that is completely insulated from outside realities, and in which you are unable to survive past thirty.

What I ended up with is basically a water cycle diagram from year 10 geography class, except I didn’t colour it in.

which means I would, under the reign of my former teacher, have lost marks for failing to add artistic flair to what is intended to be a scientific topic.

Design competitions are PR you don't need.

2009-03-27T00:00:00+00:00

A little exposition

Earlier this week, the folks over at Carsonified managed to stir up a bit of an unintentional fuss when they started a design competition on their blog. The resulting flame war waged over the issue of what constitutes “spec work” vs. what constitutes a “PR opportunity”, and managed to completely avoid mentioning what I think is the real problem with “opportunities” of this type in the year 2009.

Hold up, Ebenezer. What's wrong with entering a design competition?

Absolutely nothing. Let’s get this straight. You’re a creative person, for whom work well done is its own reward. It would be fun to enter a competition, even when there will probably be no material reward for doing so. It’s more productive than garden-variety procrastination, right? But I shall try to put this kindly, as I do not wish to cause unintentional offense: If you think that the most efficient way to promote yourself is to design something for somebody else’s brand, then you need your head examining.

More specifically, if you think that the best place to publish that work is on a slide, in a room containing a finite number of people, during a break when nothing of interest is happening on the stage and everybody is clustered around laptops enjoying the conference’s corridor track, then be serious. What do you think the conversion rate from peer/competitor to paying customer will be in this case?

Holy crap, people. It's 2009.

I don’t care if you’re a coder, a UX specialist, a semantics geek, a DBA, an artworker or an illustrator. You should not be waiting on ideas from competitions or design briefs. If you sit doing nothing until a brief lands on your desk, you’re a vending machine with lungs.

At Videojuicer we have a hiring policy for developers - personally-motivated work inspired by the need to solve a pre-existing problem, even a minor one, will always trump equivalent commercially-briefed experience when it comes to choosing candidates. We weight our decisions in this manner because we want people who identify problems and then go on to give a crap about solving them. We do not want people who sit helplessly on their hands until the problem is broken down for them.

Competitions create an illusory line between the judging and the judged. In reality, that line vanished the day universities started running ethernet to the dorm room. Indeed, the development community today is democratised to the point of closely emulating the scientific community’s approach to peer publishing and review, and those practices are not lagging far behind (if at all) in the design best practices, accessibility and user experience domains.

The Internet worked. Value by affiliation is dead. We should be conceiving, creating and deploying ideas as rapidly as possible, selecting the ones that work for progression and speaking about the successes and the failures at geek meetups, conferences and in writing as much as possible.

Sure, throw out a competition entry or two. But do it for fun. Don’t be fooled into thinking it’s the best way to market your skills. You do not have to pander to anybody. Your work can stand on its own. Get on with your life, create the things you want to create and use those things to achieve your goals.

Introducing the new Angry amoeba

2009-03-21T00:00:00+00:00

Over the last couple of days, we pushed out several long-overdue updates to the Angry amoeba site - and I thought it’d be fun to go into a little detail about the design and process behind the new version. I wanted the new site to meet several key business objectives:

Refresh the Angry amoeba brand.
Drive attention to both our commercial and our open source projects.
Decrease homepage bounce rate.
Increase conversion rate from main site to our satellite product sites.

And several key nerd objectives:

Blog like a hacker using Jekyll (inspired by TPW and New Bamboo).
Site source should be available on Github.
Blog posts should be licensed with machine-readable CC Attribution licenses, site copy should be under traditional Copyright.

To start, I made some customisations to Jekyll to get everything working just as desired. Mainly, I wanted the ability to fold blog posts, and I wanted to be able to handle that elegantly while authoring. I settled on a fairly simple solution, which is to fold posts around <hr /> tags.

Prior to this relaunch, the vast majority of our traffic was organic - that is, occurring naturally through search. Those visitors were arriving at the old site, reading old blog content, and then falling through our fingers. Any successful redesign will expose these users to more recent content through a related posts element, or other means of content suggestion.

The numbers for the first 48 hours seem positive, although I’ll wait for the initial ooh-look-a-relaunched-site spike to calm down before doing any serious analysis of the design’s success:

Bounce rate from homepage down 50% - 30% of homepage visits converted into blog visits
Twitter and Github engagement noticeably increased
Bounce rate within the blog is noticeably decreased

I also have some advice to offer when migrating to a new site, particularly if your URL structure is changing and you do not wish to lose your hard-earned Google placement.

In order to preserve our existing inbound links, our web server was configured to redirect the most freqently-hit URLs from the old site to their new equivalents. The redirect is done with a HTTP 301 Moved Permanently status, which serves to inform search spiders that the new URLs are formal replacements for the old ones, allowing us to preserve age and placement for our most popular articles. This may seem basic, but you’d be surprised at how easy it is to lose sight of these steps in the rush of deploying a new site or app.

You may have also noticed that Chirrup, our Twitter commenting system, has been replaced on our blog with Disqus, a more conventional solution for blog comments. This is because I have concluded that as it stands, Chirrup doesn’t quite work as a standalone comment system, and that it needs re-examining in the light of Twitter’s OAuth support becoming available.

The site also has a public bugtracker available on Tails. If you spot any problems, dropping a ticket there is the best way to let me know about them.

The Hacker's Amendment

2009-02-17T00:00:00+00:00

Artraze, a commenter on Slashdot, discussing the possibility of sinister DRM in Windows 7

Congress shall pass no law limiting the rights of persons to manipulate, operate, or otherwise utilize as they see fit any of their possessions or effects, nor the sale or trade of tools to be used for such purposes.

What can I say, apart from a strong, resounding yes?

The API antipattern, Twitter, and the Fail Whale's new clothes

2008-11-28T00:00:00+00:00

Not enough developers get angry when they encounter the password antipattern. You’ll know it when you see it because you’ll see site A asking you for your login credentials for site B in order to enable cool feature C. That cool feature C is usually a mechanic for spamming site A’s users into signing up for site B notwithstanding, this pattern smells worse than week-old crab left wrapped up in some wet newspaper atop a radiator.

Yes. This pattern is terrible for security because the least secure part of any system is inevitably the fallible bipedal meat-creature who uses that system, and a culture that encourages meat-beings to hand over login credentials to any form that winks and offers to buy us a drink will only further damage our already poor intertube survival instincts. Not only is this insecure, but a complete replacement of the concept of authentication by a dangerously brittle system of electronic hearsay.

When you say auth, do you mean authentication or authorisation?

Let’s go back to basics for a second. What does “authentication” mean? A brief fumble with google’s define function yields the following:

[Authentication is] The process of identifying an individual or data. In security systems, authentication is distinct from authorization. Authentication merely confirms that the identification of the individual or data is accurate.

And quite right, too. When your small personal army of Twitter client apps* are out there, running in the cloud, firing periodic requests off to Twitter, they’re authenticating as yourself. Twitter has no way to discern whether those requests come from you, or any one of the many agents you authorise to access your account. Put the other way, all agents accessing your account have the full power of the account owner, including the ability to change your password and lock you out of your account. Let’s not even get into the miniature localised apocalypse you’ll trigger whenever you change your password yourself.

Nowhere else, in any sphere of security, is this considered acceptable. Take as an example the entourage who orbit closely around a given celebrity (that’s you, you lucky thing). Your entourage look after you, they have access to your stuff, but they don’t carry your passport and driver’s license. They carry their own identification which institutions accept as authorisation to access your stuff. That’s the right way to do it. Your fabulous slick-haired fashion consultant - his name is Quantum, by the way, not that you care - authenticates as himself when he calls up the designers, but the designers know that he is authorised to buy clothes for you, because you’re too busy recording a voiceover for a rigidly formulaic CG animal cuddlefest about a penguin called Zappy who gets lost in New York with the baby of a wealthy but comedically inept couple.

Anyway. The point is that the various software agents you give access to your account should have their own credentials with which they can access your account. The service they’re working with should recognise those credentials as having access to your account. An agent should never be able to change your password or perform other tasks that are reserved for you and you alone. You should be able to revoke those credentials if you lose trust in one of your agents. You should be able to grant time-limited or once-only to agents you’re just trying out.

There’s one site in particular who already have this solved. It’s Flickr. They nailed it pretty much from the get-go. Just look at the documentation for authenticating with them. It’s beautiful, and the fact that no major independent player has been visibly inspired by it is, frankly, shocking.

The vast majority of Twitter’s traffic is via their API. And they’re still running on basic HTTP authentication, the way neanderthals authenticated with their social microstatus aggregators. It’s time for them to do better, like we all know they can.

*For Twitter, being particularly complicit in this problem, shall have the pleasure of being my whipping boy for the purposes of this article.

Addendum: And see below. Twitter comments - I loved the idea of them. But people need to enter their password in order to comment. Twitter’s bizarrely primitive approach to authentication is a massive barrier to innovation in this way.

An introduction to merb-auth and the wonderful secrets contained within

2008-11-22T00:00:00+00:00

The point of a framework is to help automate common work, right? So why is building your application’s authentication system so repetetive? The Merb framework does a lot of useful things and, thankfully, finally includes core patterns and support for user authentication within the framework. It’s called merb-auth, it just moved into town, and it is already beating up other frameworks and stealing their lunch money. And dating your daughter.

You should use merb-auth because:

It provides a clean, easily-extendable structure for authentication.
It’s part of the official framework, so it’s far less likely to break between versions.
It’s just plain damned sensible when you weigh up what it automates for you.

So let’s build a quick merb app to test it with:

merb-gen app merb-auth-playground
cd merb-auth-playground
merb-gen resource secret
merb-gen resource user

Starting at the beginning: merb-auth-core

# Add this to config/dependencies.rb if not already present
dependency "merb-auth-core"

What happened? Nothing you can see just yet. This is because, as with all merb components that offer a “core” package, the core contains only structure upon which to hang your own code. merb-auth-core doesn’t care about or do anything to your app. It just provides some hooks for you to start using. What merb-auth-core actually gives us is:

Nifty support for storing authentication details in the user’s session:

# In any of your controllers
if session.user
    "You're logged in as user ID #{session.user.id}"
else
    "You're logged out, so you don't get an ID. You don't deserve one."
end

Support for strategies. Strategies are ways to authenticate a user. A username and password sent from a form is one strategy. OpenID is another, OAuth yet another. You can register your own strategies with merb-auth, and activate them when you want them used. When merb-auth tries to authenticate the user, it will call a method named run! on each strategy in turn until one returns a user or it runs out of strategies. If a user is returned, then the authentication is successful. If not, then the authentication was unsuccessful and an exception will be raised.

Strategies look like this:

# This is an example strategy
class Merb::Authentication
  module Strategies
      class MyCustomStrategy

        def run!
          do_something_that_returns_either_a_user_or_nil_or_false
        end 

        def strategy_error_message
          "AND THEN THERE WAS FAIL"
        end

      end
  end
end

You can register and activate them like this:

# In config/init.rb:
Merb::Bootloader.after_app_loads do
    Merb::Authentication.register :custom_strategy, Merb.root / "path/to/your/strategy.rb"
  Merb::Authentication.activate! :custom_strategy
end

An ensure_authenticated method we can use in our controllers.

class Secrets < Merb::Controller
    before :ensure_authenticated

    def index
        "lol, juicy secrets"
    end     
end

There’s also one very important thing that merb-auth does not give you. Merb-auth is Bring Your Own Model code, which means you’re expected to write your own user model. If your user class is called User, which it probably is, then merb-auth will find it just fine with zero configuration. If your user class is called something else, then you’re a masochist, and you should add this to your init.rb:

# config/init.rb:
Merb::BootLoader.after_app_loads do
  Merb::Authentication.user_class = MyCustomUserClass



end

Going deeper: merb-auth-more

Adding merb-auth-core to our app got us all this sweet structure and architecture for free - we can trade authentication strategies with other developers, pretty much any merb developer we hire can understand our authentication system and we still get to define business logic ourselves. But what if we want to use merb-auth-core to do something totally basic that every developer has to build at least over 9000 times in their lifetime, like basic password auth? Enter merb-auth-more. Merb-auth-more doesn’t contain any new architecture over and above merb-auth-core, but it what it does include is a package of ready-made auth strategies that work wonderfully right out the box. Let’s use merb-auth-more to add simple login form support to our application:

# Add this to config/dependencies.rb if not already present
dependency "merb-auth-more"

And if we didn’t already, let’s craft a really simple user model including merb-auth-more’s salted, hashed password module.

merb-gen resource user

# In app/models/user.rb
require 'merb-auth-more/mixins/salted_user'
class User
    include DataMapper::Resource
    include Merb::Authentication::Mixins::SaltedUser

    property :id, Serial
    property :email, String, :format=>:email_address
    property :login, String, :nullable=>false

    # You do not have to define password or password_confirmation attributes - the SaltedUser mixin does this for you.
    # You do not have to define the ::authenticate! method - SaltedUser does this for you.      

end

If you don’t want to use :login and :password as the params for logging in, or you want users to login using another property, you can easily customise this behaviour with this code:

# config/init.rb:
Merb::BootLoader.after_app_loads do
  Merb::Plugins.config[:"merb-auth"][:login_param] = :email
    Merb::Plugins.config[:"merb-auth"][:password_param] = :secret_squirrel_decoder_ring
end

Woot! Full authentication from controller to model is ours to use, enjoy and love, with little to no maintenance or hassle. But we don’t have any views set up to allow users to log in, which is somewhat problematic. But don’t panic, honey. Merb’s got your back.

Hot damn: merb-auth-slice-password

Merb-slices are awesome. They’re little apps designed to run inside your main apps - they can have their own controllers, models, helpers and views, which your main application can override on a file-by-file basis. They’re plugins on steroids - essentially the best way to refactor and share complex behaviour from one merb app to another. Merb-auth-slice-password is a merb slice built on top of merb-auth-core and -more which uses merb-auth-more’s auth strategies to provide a simple login/logout mechanism for your app. Let’s get it running:

# Add this to config/dependencies.rb if not already present
dependency "merb-auth-slice-password"

# In your config/router.rb
# This will 'mount' the slice within your app's URL structure. 
# The :path_prefix option tells the router not to mount the slice at a subfolder like /merb-auth-slice-password/login.
# below: Merb::Router.prepare do
add_slice(:MerbAuthSlicePassword, :path_prefix => nil)
# above: end

rake slices:merb-auth-slice-password:install
rake db:automigrate

Let’s try booting up the app! Use the merb command to fire it up and check it out in a web browser. Hit http://localhost:4000 and you should see the merb welcome screen:

However, hit the protected controller we made at http://localhost:4000/secrets and hot diggity damn, free login functionality!

Now the login you have here follows a pattern called exceptional authentication. Merb-auth considers you being logged out (when you need to be logged in) to be an exception, just like NotFound or any other exception. So instead of needing to bounce users to Sessions#new when the user visits a protected URL, we raise an exception and display the login page right there. A single specific URL with a :return_to param is still used to start the session as merb URLs can perform differently depending on the request method used, and we most likely want to render the GET version of the URL upon successful login.

Let’s finish you up by making some changes to the somewhat simplistic login form provided by slice-password. Because we’re dealing with a slice here, we can easily provide new templates for the slice. Check out the directory structure of your project - since you installed that slice, you’ve got a slices folder in the root. Within it, a folder for each of your slices, gloriously arranged for your inspection. Each folder empty, awaiting your instructions. With any slice, you can override views on a per-file basis. Unfortunately due to this bug in Merb 1.0, we have to go about this in a slightly askew fashion for slice-password. In terminal:

rake slices:merb-auth-slice-password:freeze

This will copy the slice files into your slices folder for you to tweak. I’m also going to force the slice files to render inside my main application’s layout:

#in config/init.rb
Merb::Slices::config[:merb_auth_slice_password][:layout] = :application

I’ll restart the slice to see what happened:

Awesome.

How to get Quicksilver's radial menus to play nice with your mouse

2008-11-17T00:00:00+00:00

You may have seen Quicksilver’s Radial Constellation menus, which are freaking awesome. Behold:

Wouldn’t it be great if you could get them to pop up when you click on items with a particular mouse button or modifier key? Hell yeah it would. And as it turns out, Quicksilver already contains all the science you need to do it. To get started:

Open Quicksilver’s preference pane and tick ‘Enable advanced features.’ Allow Quicksilver to shout at you for a moment. Agree when it asks to restart itself.
Re-open the preference pane and click ‘Plug-ins’ in the toolbar. Search for three addons: Constallation Menus, Mouse Triggers and User Interface Access. Install them.
Click the ‘Catalog’ toolbar item and select ‘Quicksilver’ from the source list on the left. Tick ‘Proxy Objects’ on the right if it isn’t already ticked. Restart Quicksilver again.
Open the preference pane for the third and final time and select ‘Triggers’. Click the + sign at the bottom of the window and select ‘Mouse’.
Double-click the item and make a selection like this:
Pick which mouse button and modifiers you want to trigger the menu:
Enjoy.

In which we enjoy catharsis by joining the Merb vs. Rails drama

2008-11-16T00:00:00+00:00

Summarising this post from Merbist, in which the current bun fight between Rails and Merb camps is documented in detail:

Rails is enormous and comes as a package. Although it is theoretically possible to run Rails without some of the bajillion modules it loads at boot, it involves freezing your Rails version, removing a bunch of includes, staying clear of any dependent methods and, oh yeah, never being able to easily upgrade to newer Rails versions again. Ever.

Merb is smaller, although younger (Rails used to be smallish too), but it has a modular design which allows you to actively decide the size of the included framework. Smaller projects can use only the core controller stack, while larger projects can introduce Merb’s ORM, view and many helper modules on a selective basis as they are needed. Merb is also faster in most cases (YMMV) and in my own personal experience has a far lower rate of WTFs/minute when reading through both core source and addon source, thanks to Merb’s plugin API.

Merb has taken functional cues from Rails’ brilliant RESTful resource handling and multi-format controller actions, and Rails is taking some architectural cues from Merb’s super-fast controller stack and non-blocking file uploads.

I have problems with Rails’ lack of modular containment and high-maintenance hackability, but I also see why there’s room for an end-to-end framework in the marketplace. I have problems with DHH’s decision to solicit help from a community he had no intention of listening to, but I also appreciate that strength of ideology is what made Rails take off in the first place.

I just wish Rails didn’t so finely straddle the line between being “opinionated” and being an irresponsible douche.

In the end, we’re all trying to solve the same problems. So find the tools you like, help them grow, and have fun hacking. And for science’s sake, don’t be a douche.

Create with Context on How people really use the iPhone

2008-11-13T00:00:00+00:00

The guys and girls over at Create with Context have created a very interesting document detailing the results of their independent user testing of the iPhone, and in a stroke of sheer brilliance they’ve made it available to all of us.

Their look into usability of the in-built iPhone apps turns up some interesting points about Apple’s iconography. Many users note confusion around the purpose of some icons, most notably between search and zoom. It seems that some users expect magnifying glass icons to either increase the current zoom level, or to reset the zoom level to a full-page view. This is unfortunate, because the magnifying glass is, on the desktop, the canonical icon for search - so I’m curious to see if these results are specific to user interfaces that are so centered around zoom and pan, or if we’ve been missing problems with desktop iconography all along. It’s also possible that the relatively cramped conditions on the iPhone’s screen give little opportunity to space controls out and give them distinct context.

Most useful for my fellow Cocoa Touch developers is the section on App Store experiences, which gives insight into app pricing, which App Store listings and the impact of positive/negative reviews on the download page.

It’s a highly recommended download and I’d like to thank Create with Context for making it available to all of us.

Barclays online banking uses sketchy external stats provider, is only as secure as a sketchy external stats provider.

2008-08-28T00:00:00+00:00

Basic software security, lesson #1: You are only as secure as the weakest point in your system.

It’s a valuable lesson. Earlier this year Barclays made a big show of security, even going so far as to mail two-factor authentication devices to their customers in an attempt to prevent online banking fraud. That’s a big investment.

Unfortunately for Barclays, it doesn’t matter, and their money was wasted. Because if you want to compromise the computers of Barclays account holders, there’s no need to circumvent the giant, thoroughly-audited security schemes that are almost certainly in place. Nope, you just need to compromise their analytics provider.

That’s right, every page load from your “private”, “secure” banking pages is also communicating directly with Webtrends’ servers. And worse, Webtrends get to run code within the page, putting you totally at their mercy. If an angry Webtrends employee wants to harvest your banking data, he needs only change that javascript without alerting Barclays first. If you google “webtrendslive”, by the way, you’ll notice that malware reports actually outrank the actual product site. It’s a nice touch.

Anyway. Looks fine, right? They’re just including a local script from the /f directory. No. The script they’re pulling from a local file is in fact writing a new script tag to the document, which will load a script from an external server. Take a look:

// THIS IS ALL INNOCENT ENOUGH
var gDomain="statse.webtrendslive.com";
var gDcsId="REDACTED";
var gFpc="WT_FPC";
var gConvert=true;
var gFpcDom=".barclays.co.uk";

// WELL, IT'S ONLY BANKING INNIT. THE SECURITY MODEL ONLY
// PREVENTS YOU FROM DOING THIS SO YOU DON'T LOSE YOUR
// MYSPACE PASSWORD.

if ((typeof(gConvert)!="undefined")&&gConvert&&(document.cookie.indexOf(gFpc+"=")==-1)&&(document.cookie.indexOf("WTLOPTOUT=")==-1)){
 document.write("<SCR"+"IPT TYPE='text/javascript' SRC='"+"http"+(window.location.protocol.indexOf('https:')==0?'s':'')+"://"+gDomain+"/"+gDcsId+"/wtid.js"+"'><\/SCR"+"IPT>");
}

Why does it have to do this, you ask? Because the browser security model specifically prevents you from making off-site requests in this way to protect the user from, oh, script injection vulnerabilities and having their details pinched by dastardly or inept external script providers. But this is only banking, right? S’probably fine to just ignore the reasons not to do it and go ahead with it. It’s not like you can assess your stats by analyzing your own logs or anything.

Basic software security, lesson #1: You are only as secure as the weakest point in your system.

It’s a valuable lesson.

Testing for desirable errors in Ruby

2008-07-04T00:00:00+00:00

Sometimes, you want your code to fail. You want to make sure that in the event of a failure, an exception is generated - the equivalent of a controlled explosion. Something you can design contingencies around. Until now I’ve been a little frustrated with testing these eventualities, so I decided to hack up a quick custom assertion for your Test::Unit suites (although it should translate pretty effortlessly to RSpec or any other test framework):

# In test_helper.rb:
def assert_error_raised(errorklass=StandardError, &amp;block)
     raised = false
     begin
       block.call 
     rescue errorklass 
       raised = true
     end
     # You will see this message if an error was not raised.
     # If an error was raised which was not of the type you specified, then the test trace
     # will be allowed to display the error as normal and the test will fail with an E.
     assert raised, "Expected error #{errorklass.to_s} to be raised but error never encountered."
end

# In your application code, let's say some_model.rb:
def do_something_with(array)
       unless array.is_a?(Array)
              raise ArgumentError, "Argument of type #{array.class.to_s} given to SomeModel#do_something when argument must be of type Array"
       end
       continue_doing_something
end

# In your test suite:
def test_error_generated_with_bad_argument_to_do_something_with
       @some_model = SomeModel.new
       # This test will pass
       assert_error_raised(ArgumentError) do
              @some_model.do_something_with "i'm not an array"
       end
       # This test will fail and dump the error via your test console's usual channel
       assert_error_raised(RuntimeError) do
              @some_model.do_something_with "neither am i"
       end
end

Chirrup 0.81 released

2008-07-03T00:00:00+00:00

Hi there, sorry I haven’t written in a while. It’s this damned work business. Some actual content is promised soon.

Anyhow - A rather nasty text-escaping bug popped up in Chirrup, so I’ve issued a patch in version 0.81 which is available for download now.

The problem: Badly-formatted tweets containing certain special characters caused Chirrup’s JSON to fail parsing and the Chirrup UI to not display.

The fix: Improved sanitisation routine for tweet data being sent over JSON.

Happy Tweeting.

How to force Git to ignore files

2008-05-24T00:00:00+00:00

Just documenting this one for later, really. If you’re setting up a git repository and you need to ignore certain types of file - logs, or python bytecode (not that I’m dealing with those two problems at this exact moment or anything), the procedure is quite simple:


# Get to the hidden .git directory within your project.
cd /path/to/your/project
cd .git/info
# in .git/info is a file named "exclude". Open it in whatever you like. Here we'll open it with Textmate.
mate exclude

The file’s contents are, by default, commented out. To add your own ignore rules, just add each rule on a new line. Here’s a simple example from a Python project which prevents bytecode and Textmate project files from being committed:


*.pyc
*.tmproj

In a Rails project, you’d likely want a set of rules like the following completely untested fragment:


log
*.log
*.pid
tmp

Chirrup launched for public use

2008-05-20T00:00:00+00:00

Well, that’s another silly little side-project in the can. If you’d like to have Twitter comments on your blog, wiki, website, or basically anything with a URL, head on over to chirrup.angryamoeba.co.uk and download Chirrup to get started!

Thanks to the Videojuicer dev team for helping with testing - Ted Han, John Carlin, Alex Nichol and Adam Livesley. And thanks to Adam for turning Chirrup into a wordpress plugin - this functionality is included in the main download package .

Thanks for bearing with us over the testing period, and have fun with Chirrup!

Chirrup - Twitter comments for your blog!

2008-05-13T00:00:00+00:00

UPDATE: Chirrup is now available to the public. Visit chirrup.angryamoeba.co.uk to get your copy.

You might’ve noticed some new features here at Singlecell - we’ve been working on a library called Chirrup, which allows you to include comments from Twitter in your pages.

The idea behind Chirrup is to provide a more natural relationship between dialogue happening on individual pages and dialogue happening in public on applications such as Twitter. People are discussing content in comment sections, and then duplicating the discussion on Twitter - so why not marry the two up?

When you post a comment to a page via Chirrup, your comment is sent as an @reply to the blog’s owner, and contains both the URL and your comment. This means that your comments are completely legible to the rest of Twitter, and contain no unnecessary data.

Chirrup’s server-side component then slurps up the blog owner’s @replies and sorts through them for Chirrup responses. It supports compression and decompression of tinyurl’s, so comments sent with all major Twitter clients can be recognised by Chirrup’s parser.

Chirrup will enjoy a short testing period on this page while I snarf down huge piles of my own dog food, and will then be released under a Creative Commons license.

In the meantime, if you find a bug in Chirrup’s behaviour, I’d be obliged if you’d post it to the Chirrup bugtracker on Tails.