I raise havoc, like giving Mobb Deep a booster chair

‘Cutting the mustard’ is the term the BBC News web developers use for what in other circles is called ‘feature detection’: Programmatically checking whether a given feature is available in the user’s browser.

The technique can be summarised succinctly as:

if (feature in element) {}

Where feature is the feature to check for (like ‘querySelector’) and element is the element you will be accessing said feature on (often window or document, though it can be any DOM element).

This is a crucial component of progressive enhancement, adding features to users whose browsers can support them, in a layered manner where said features are considered additions.

The problem I have encountered is of a philosophical nature: What features should one cut the mustard for?

If we take BBC’s opening statement (‘The browser is a hostile development environment’) to its extreme conclusion, a browser could theoretically support no JavaScript APIs. Thus, to cut the mustard, one would have to feature detect everything.

Now, this is probably overkill. Aside from the obvious fact that if the browser doesn’t support the controls if and in feature detection isn’t even possible, there are softer features to check for that are probably overkill. Object.prototype.hasOwnProperty() has been part of JavaScript since the beginning, and is implemented in all browsers known to MDN, so it can probably be assumed to be present.

But this still leaves the question: What features should one cut the mustard for? If we can assume some features are present, but not others, how do we determine which ones to check for? The only good rule of thumb I can think of is consulting implementation tables such as the ones on MDN and Can I use…, and drawing the line somewhere. And although better than outright user agent detection, it veers too close for my liking.

This might be me being too idealistic, but I am still unsure of the right approach.

Over the last month or so, I’ve begun learning Clojure. I don’t do much blogging, let alone technical, but I realise I’ve actually had this blog for so long that my first impressions of Python (the language I spend most of my day job writing in), are documented.

I read through Kyle Kingsbury’s Clojure from the ground up series, and found it an easy learning process. Although I consider myself somewhat of a polyglot, I realised that I hadn’t actually learned any new programming languages in almost ten years, aside from various JavaScript type annotation supersets. (I’ve tried learning Haskell, but have been largely unsuccessful.)

All in all, I like it. I like its functional paradigm, making functions pure by default, but not having to ask permission to get side-effects (which is the feeling I get a bit with Haskell). Leiningen is a great tool to get up and running, and it takes care of a lot of the minutae, like installing dependencies and running tests. I really like being able to name functions almost anything, including non-ASCII characters and characters normally reserved (so now I can use possessive in a function name).

One thing I find about that I really dislike is the abbreviations. Now, this might simply be because it’s the first language I’ve picked up in a while, and I simply haven’t paid attention to it in other languages, but the incessant abbreviating every conceivable name drives me up the wall. Why in the world does it have to be conj and assoc, what’s wrong with conjoin and associate‽ The fact that abbreviations are applied so randomly proved a stumbling block for me, which I feel it really shouldn’t have to be. This is my first foray into Lisp, so I don’t know how much (if any) is simply convention, but space-saving concerns one might have had in the 50s can surely be ignored today. I get more riled up than I justifiably should be, but it irks me. (And again, I realise this might simply just be my internalisation of some abbreviations: I have no problem with str, concat and def.)

I find the destructuring syntax in a lot of cases to be greatly confusing and emanating magic. I have come to terms with let taking a vector of alternating key value pairs, but the sprinkling of keywords to imbue bindings with special properties means I’m still at a copy & paste–stage for some use cases. I’m not very far into macros yet (I have yet to write my first one), but from what I can sense, it leads to a lot of poorly designed APIs. But it might just take some getting used to. (I thought the self argument for Python methods was stupid at first, and now I don’t think about it.)

I also really miss Python’s named, any-order parameters. I realise something similar can be achieved in Clojure using keys destructuring, but that can’t be combined with arity overloading, which I also really like. (Yes, this might be a case of wanting to have a cake and eating it too.)

The lack of a good date and time library is also unfortunate (at least for the apps I tend to do). I’ve been using clj-time, which seems to be a pretty thin wrapper around Joda Time, and while it does its job, it has some odd shortcomings, the primary being its incapability of representing date-less times. I’ve resorted to vectors of hours, minutes, etc., but when you’re used to Python’s datetime library, specifically datetime.time in this instance, you find yourself wanting.

I have found one library that I really like, though: Enlive. It’s an unconventional templating library, in that it doesn’t make a DSL for templating (or, indeed, give access to the whole language, as in PHP), letting the templates instead be pure HTML, and doing the transformations in Clojure. It took me a little while to get the hang of doing things such as loops, but I think it makes for a clean separation of concerns, and I’ll definitely investigate the concept in Python. (There is a Python port, although it doesn’t seem to get much attention these days.)

All in all, I’m really excited about Clojure. For web development it lacks some of the maturity and cohesiveness that I’m used to with Django, but as a language it has a lot of interesting concepts and libraries.

Aaron Gustafson (via Jeremy Keith):

The square brackets (“[]”) at the end of the name are the magic bit that allows the values of each chosen “reservation_requested_device” checkbox to be submitted as the value of “reservation_requested_device”.

This is not, strictly speaking, true. It is not incorrect either, and if you use PHP, you’ll need it.

That was a mouthful, but the underlying truth is this: You don’t need square brackets at the end of a checkbox’ name attribute to send multiple values to the server. However, in order for the server to understand that there is (or might be) multiple values, PHP has chosen a convention of ending the name with square brackets (which aligns with its syntax for pushing an element to an array). It is possible others have mimicked this behaviour (I know jQuery does it for sending arrays as XMLHttpRequests from the client), but there is no necessity for it.

I have wrapped up a tiny example to showcase that this is not necessary. My example is implemented in the Python web framework Django.

A query string can contain any key multiple times, and it is up to the server to interpret the result. For instance, Django has chosen for its QueryDict that you can access any value from the standard Python get method to get a single value, or you can access the getlist method to get a list of values (it is possible for the resulting list to only contain one item, or indeed none for an unknown key).

The use of square brackets might indeed be very logical (to signify the expectation of multiple values), but Jeremy noted that he, wasn’t sure whether that was just a PHP thing, and I wanted to confirm that’s indeed the case.

John Gruber outlines his wishes for Twitter’s new longer tweet format:

This sounds like what I’ve been hoping they’d do: treat longer-than-140-character posts as an attachment type, like quoted tweets, images, etc.

An idea for a service I’ve been idly considering for some time: Capture part of a page, and if requested with an Accept header that prefers images over HTML, show the text as an image.

Sort of like a mix of Mozilla’s PageShot (but instead do it for excerpts) and OneShot and similar apps for text-fragments-as-screenshots.

This would be ideal for Twitter clients, although I’m not sure whether (any) Twitter clients actually explicitly prefer images over HTML. Considering how most of them embed images inline, I think they should, though.

Apple, Caterpillar, Chevron, Coach, Flour, Gap, Pantry, Staples, Target, Visa.

Context: The Message posted a list of start-up companies whose names are existing English words.

Way back in November (I realise this puts my comment in the category of insanely untimely responses, but so be it) Ruben Verborgh wrote an article called The lie of the API, which I got to via Jeremy Keith.

Let me, before I lay out my disagreement, start by saying that I agree with the basic gist of both their arguments: There is little reason why an HTML representation of a piece of content is freely available, but a JSON (or XML or YAML) representation requires an OAuthenticated API.

Although Keith disagrees that content negotiation is the way forward, his waryness seems to be of a nature that could be URL hacked away — instead of using actual content negotiation (Accept: application/json), one could simply append .json to the end of the URL, or other similar measure. It may not be the absolute cleanest, most native HTTP implementation, but I’m sure Verborgh and Keith could both live with this.

This doesn’t pave over the reliability of the API though, which I’ll argue is an, albeit maybe not explicitly communicated, major reason why sites choose to offer their data via an actual API.

The thing is, when you visit an HTML page, you do not need to know anything about the structure of the data. The browser and the developer have an agreement that HTML structured in a certain way, with CSS and JavaScript structured in their certain ways, will be displayed in a certain way (save of course for browser-inconsistencies, but that’s the general idea). That is why an HTML page can be viewed, and made sense of, by a human being, whereas a JSON representation for the far majority of people will make essentially no sense.

When you make a JSON representation of some data, the structure will not be self-explanatory, and you will be forced to choose a structure for the data. Unless you’re dealing with Platonic ideals (and are very good at achieving those ideals on the first try) this structure is bound to change. You might add a field, remove a field, or change the semantics of a field.

If you do this with an HTML document, you can go about the change any way you like – so long as the new structure of the data still conforms to the browser’s expectation of how an HTML page should be structured, you’ll still have something usable. If you do this with JSON – assuming the JSON representation is only read by a machine, which will almost always be the case – the consumer will quite possibly break, unless you’ve changed the consumer accordingly, or notified them in advance if they’re an external entity. This last case is where the (versioned) API comes into play: If one can make changes that don’t break existing implementations, by somehow working a versioning scheme into the API, that’s a bonus. HTTP Accept will not let you do this.

For representations that are only intended to be used internally, a changing, non-versioned JSON one may suffice; if one has control of the entire stack, one doesn’t need to maintain backwards compatibility to the same degree. But those sorts of APIs wouldn’t be subject to OAuth restrictions anyway.

I agree that an OAuth token shouldn’t be necessary to get a JSON representation of one’s Twitter stream, when an HTML representation is freely available – but I do think that the nature of intended-for-machines representations are so substantially different from intended-for-humans representations that some sort of agreement (and documentation) is required. If you can find an existing format that fits (Accept: application/atom+xml for a Twitter stream), by all means use it, but that’s also locking yourself into a model that may not fit your data exactly as you’d like it to – and unlike HTML, you have no way of telling the consumer what to do with your seemingly arbitrarily structured data, the way you do with CSS.

Insofar as it’s possible, you should make representations of your data that fit the user agent’s Accept header; but if you don’t commit to the structure you choose, it will be unreliable and essentially unusable for machines parsing it.

This is by no means a review. For that I refer you to Macworld, Ars Technica or iMore. These are the observations I made. I notice small things, and generally ignore big things. Mind you, my favourite part of iOS 5 was the addition of the en-dash in the keyboard. So, here they are:

• They put in a ‘kr’ button in the Danish numbers keyboard. It inserts the letters k and r, which for most people would probably be easier to just type. (Same amount of clicks and they’re closer to each other)

• The maps are certainly prettier than Google’s. As for the use of them, I must admit I never used maps all that much, but from my limited use of them, there seems to be almost no knowledge of Odense, where I live. (Transit missing is OK for me personally, because I never used the ones in the old Maps.)

• No password required for app updates is great, and it’s mind baffling it’s taken so long for it to appear. Now we just need same behaviour for free apps (though I see more potential problems with that.)

• Do not disturb is a great concept, somewhat lacking implementation. The ability to set up schedules would be great. (I have very different times for when I want to receive notifications on weekdays and weekends.)

This post will talk about my iPhone, iPad, and Macbook specifically, but I am sure that the lessons here are applicable to comparable non-Apple manufactured devices.

The topic is of locking. On the iPhone and the iPad it is done by tapping the small lock-button on the top of the device. (Or, on the iPad, if it has a Smart Cover, by folding the smart cover over.) On the Macbook it is done by closing the lid.

All of these devices, however, have an additional lock mechanism, an automatic one: if the device hasn’t been used for a period of time, it will simply lock itself, thus saving battery by turning off the screen.

So all devices have a manual and an automatic way of locking down. Yet, despite these being conceptually quite different – one active, the other distinctly inactive – they are treated the same when devices wake up.

Whether I lock my iPhone or let it go to sleep, I have to enter the lock-code when I want it to wake up again. Yes, the lock-code can be disabled, or I can set a delay before the device will require the code, but it still applies to both methods of going to sleep.

The thing is, I see these two sleeping methods coming from very different places: when I press the lock button on the iOS device, or when I close the lid on my Macbook, I make a very conscious (and active) choice of not wanting to use the device for the foreseeable future; when I let the device lock up by itself by not inputting into it, I might have forgotten about it, or I might be occupied for a longer time than I had expected with something. I might even just be paying attention to something, waiting to interact with the device for just a short while. (Specific use case illustrating this: When I was at university, I attended quite a lot of lectures where I kept either WriteRoom on the Macbook open, or Plaintext on the iPad. Sometimes the lecturer will take her time to get to the point, or simply not make a point for a while, which means I don’t do anything when the device, but I still want to be able to write something when an idea comes to mind.)

The current situation has me reaching for tools such as the very useful Caffeine to prevent my Macbook from going to sleep. (I don’t believe a similar tool would be possible on iOS.) This introduces another problem: I often forget to turn it off afterwards, which means that if I leave my machine, it won’t turn off the screen, thus wasting power.

I really think all devices could benefit from a realisation of the fact that these are different things, occur for different reasons, and should be handled differently. I even think the change could be made very simply, by adding an unobtrusive checkbox asking whether the passcode should only apply on non-auto-lock (or active lock, or whatever one might choose to call it). On iOS it would most likely require a merger of the Auto-Lock and Passcode Lock panes, but I can’t see any reason for them not being in the same one already.

Nelly.com tilbyder mig at jeg kan købe noget tøj fra [[1 DKK]] om måneden. Det ville være en afbetalingsordning der ville tage 62 år og lidt til. Jeg overvejer det.