We miss her a lot.
]]>Although I listen to a lot of music when I'm alone, we don't listen to much in the family spaces around the house. The kids both have stereos on their rooms, but they don't listen to the radio on their own. Yet they are constantly exposed to musical and cultural references in the films and TV they watch, and the games they play. I always find it fun to see how they react when I connect something they've just heard or seen to the "original" from twenty years ago (which itself generally has roots in a still earlier era).
In this case, their interest turned into dance. While they were still getting clean and ready for bed, I burned a selection of 80s hits onto CDs for them. The playlist opens with Axel F, of course, but there's some Michael Jackson on there, a bit of ABC, a bit of Human League, a bit of Boomtown Rats. They eagerly stuck the discs into their players, and just minutes later Alex was breakdancing to Axel F, and Fiona had put together a short ballet to the sounds of "Girls Just Wanna Have Fun." I was completely enchanted.
Music is so important to me that I'm always delighted whenever they take any kind of interest in it. I need to work on getting more of it into their lives.
]]>
We miss her a lot.
]]>Additionally, whenever you're dealing with a company that handles anything of value to you (with banks it's money, with Facebook and Google it's personal data), you have to weigh up the trust you have to place in them against the benefit you expect to receive. Google passes that test for me (for now), but I don't trust Facebook not to try and screw me over.
What happens when you try to leave Facebook is emblematic of this. Here's the page you get when you try to disable your account:
Asking me to confirm that I want to deactivate my account is appropriate. Using my social connections in a clear attempt to trigger an emotional response that will keep me on the service is absolutely not.
"Your 32 friends will no longer be able to keep in touch with you" is nonsense. I assume that since they know how to use a web browser, they're reasonably familiar with a computer, and probably have an email account they can use to reach me.
Below that, they display a random selection of my Facebook contacts with above each one the text "XXX will miss you". Not only are these statements factually incorrect — they won't miss me because I never used Facebook to communicate with them in the first place — but Facebook is almost literally putting words in the mouths of these people. Facebook has not asked them if they will miss me; it is using them as sock puppets to push its own message, which is "don't go." By using the emotional "miss you" phrase, Facebook is using its knowledge of my social connections to make me feel bad about leaving.
They are abusing my social graph for their own ends. It's manipulative, unethical, and downright slimy.
Furthermore, if they are using my contacts to try to make me stay, it follows that if my friends have tried to leave Facebook, then Facebook may have used me, or at least my photo, to try to make them stay — something that I myself would absolutely not do.
Goodbye, Facebook. Martin will not miss you.
]]>It's magical thinking: If we defend against what the terrorists did last time, we'll somehow defend against what they do next time. Of course this doesn't work. We take away guns and bombs, so the terrorists use box cutters. We take away box cutters and corkscrews, and the terrorists hide explosives in their shoes. We screen shoes, they use liquids. We limit liquids, they sew PETN into their underwear. We implement full-body scanners, and they're going to do something else. This is a stupid game; we should stop playing it.
What’s most striking about the government’s response to this unsuccessful bombing attempt is the complete lack of any rational relationship between the actions that have been taken and are being proposed, any analysis of which of these and similar tactics did or did not contribute to the success or failure of the Christmas Day attack on Northwest Airlines flight 253, and any likelihood that they would make future attempts at terrorism less likely to succeed.
No, what bothers me is the fact that distorting public policy, removing individual liberties, and instituting a culture of irrationality and fear is exactly what the terrorists wanted in the first place.
Our job is to think critically and rationally, and to ignore the cacophony of other interests trying to use terrorism to advance political careers or increase a television show's viewership.
So what can I personally do to refuse to be terrorized? Unfortunately, airlines and airports have a monopoly on air travel, and national governments have a monopoly on border control, so I can't refuse to play the security game whenever I go abroad. I would if I could, because personally I feel more at risk from the security measures than I do from terrorist action. The risk of being subject of an attempted terrorist attack (much less a sucessful one) is, after all, less than being struck by lightning.
For one thing, I can help point out when people take the right approach. For example, The Register:
First: It is completely impossible to prevent terrorists from attacking airliners.
Second: This does not matter. There is no need for greater efforts on security.
Third: A terrorist set fire to his own trousers, suffering eyewateringly painful burns to what Australian cricket commentators sometimes refer to as the "groinal area", and nobody seems to be laughing. What's wrong with us?
I can also call bullshit on articles like this one on Travolution in which a tiny, poorly worded sidebar poll on a travel industry blog gets blown up to represent that a majority of all travellers are in favour of body scanners that would not have flagged the completely pants bomber in the first place.
But ranting about this stuff on my blog reminds me of the depressing inevitability of the war in Iraq in late 2002 and early 2003. No matter how much we, the people, protested — and the lead-up to the war we saw the biggest anti-war protests in history — our governments still went blithely ahead. I may have high hopes for the decade ahead, but an end to the ridiculous security theatre that plagues us is beyond even my wildest dreams.
]]>The problem is to do with Safari 4's "Top Sites" feature, which shows you a pretty grid of thumbnails for the sites you visit most regularly (or that you have pinned in place). The interesting thing is that these thumbnails are live (ish) previews of what those pages currently look like. If you don't happen to have a Top Sites page open in a tab, and if Safari considers that the current thumbnail is sufficiently out of date, it will automatically go and retrieve the latest version.
This can cause headaches for site owners, because in order to show the actual state of the page, Safari relies on full page requests: it downloads all the HTML, CSS, images, and JavaScript for the page, and then displays everything exactly as if the user were viewing the page in a standard tab. Adverts are rendered, page tracking scripts are executed, and to the server it looks just like a regular page hit. This can lead to the site recording unnecessary actions, and your site analytics being all messed up.
At Skyscanner, for example, we noticed this because Google Analytics was showing an unusually high number of Safari users (8.5%) with an abnormally high bounce rate (the proportion of sessions where users view a single page, then walk away with no further interaction): Safari 4 users were twice as likely to bounce as other browsers. Useless sessions generated by Top Sites were the problem.
As Jeremy noted, the user agent that Safari 4 reports for a Top Sites request is exactly the same as for a normal page request. Fortunately, there is a way to distinguish the two types of request: in the current version of Safari 4 (4.0.4) the Top Sites request for the base page (but not its JS/CSS/image resources) carries an additional HTTP header, namely "X-Purpose: preview".
An easy way to verify this is to use an HTTP debugging proxy like Fiddler or Charles to watch what happens when Top Sites makes a request — see the screen grabs below:
If your pages are dynamically generated, you can adjust your server-side code to examine the HTTP headers of the incoming request, and take appropriate action if this is a "preview" request. Here's some sample PHP code:
<?php
if ($_SERVER["HTTP_X_PURPOSE"] == "preview") {
echo "preview";
} else {
echo "normal";
}
?>
("X-Purpose" is not a standard HTTP header, and you won't find "HTTP_X_PURPOSE" in the PHP documentation. It's the CGI specification that specifies how HTTP headers should be handled: they should be made into an environment variable with an "HTTP_" prefix followed by the header name, with dashes replaced by underscores. Hence, the value of the "X-Purpose" header is placed in the "HTTP_X_PURPOSE" environment variable, and retrieved as $_SERVER["HTTP_X_PURPOSE"].)
If all you're looking to do it fix your site stats in Google Analytics, then you should just make sure that you don't write out the GA tracking code for preview requests. If you are concerned about excessive load on your servers, unwanted user actions, or spurious advert impressions, you can take more aggressive action, perhaps by rendering a lightweight version of the page. An extreme possibility I considered was generating a completely different version of the page, specifically designed to look good in the thumbnail format of the Top Sites preview page:
However, doing this runs counter to the notion that these thumbnails represent previews, and I don't know how your users would react. More importantly, Google might consider this cloaking, and come round your house in the middle of the night with a baseball bat. Just because it's possible, doesn't mean it's a good idea...
]]>I have read the first three series several times before already, and they are always fresh, and always fun. For a change, I read the Vorkosigan books in chronological order (although I started with Shards of Honor, rather than Falling Free), and in rapid succession. The early Miles books (The Warrior's Apprentice and The Vor Game are still my favourites, and it turns out that Diplomatic Immunity isn't as bad as I remembered it.
The Julian May books were less of a pleasure. If it weren't for the "I've got this far so might as well keep going" sunk-costs argument, I would (should) have stopped about fifty pages into The Golden Torc. I remember waiting eagerly for the publication of Diamond Mask and Magnificat in the mid-90s, but now I just find the characters overly self-absorbed and melodramatic; I don't think I'll be re-reading them again.
Staying with Lois McMaster Bujold, 2009 saw the publication of the fourth and final book in her Sharing Knife series. I bought the first book, Beguilement when it was released in 2006, but didn't read it at the time. I knew it was only the first part of a single big story, and having been burned by Peter F. Hamilton's Pandora's Star the previous year, I didn't want to start on the tale, only to have to wait three years to get to its end. But when the fourth part, Horizon was published in February, I grabbed it and started from the beginning.
The Sharing Knife is a fantasy romance -- not a combination that normally leaps off the shelves at me. But I trust Bujold to write characters I care about and a story that interests me regardless of my genre prejudices, and that is exactly what she has done here. The world she has created has more of an American frontier feel to it rather than a pseudo-medieval European vibe: prairies and riverside trading towns rather than dark forests and castles. Lakewalkers patrol the land on the lookout for malices, creatures that rise from the earth and feed on the life energy of everything nearby, and are capable of devastating entire towns. The malices are an ancient menace, but thanks to Lakewalker efforts over the centuries, a rare one now. So rare that many farmers don't even believe in them any more, which causes tension when Lakewalkers come to town and require their aid. Because of the apparent safety, and the particular magical means by which Lakewalkers fight the malices, farmers have grown likely to fear and mistrust them, and call them witches, rather than heed their warnings.
The main characters are Fawn, a young farmer woman who has run away from home, and Dag, a grizzled Lakewalker veteran. They fall in love despite the large cultural gap that separates them. The books follow them as, outcast from their families and communities, they try find a place for themselves in the world, and to somehow reconcile these two parallel but highly interdependent societies.
Oh, and fight evil! The book covers may look all sweet and pastoral, but the plot is driven forward by the ongoing and very real threat of the malices. While I wouldn't characterize the books as adventure stories, there is no lack of action. Bujold strikes a masterful balance between the clash-of-cultures love story and edge-of-your-seat thrills, and I can highly recommend the whole series.
(Just make sure you read the first two books, Beguilement and Legacy together, because it is really one book split in two -- even the covers are two halves of a single piece. Three and four make up "part two", but they are a looser pairing.)
Throughout November and December I also caught up on Steven Brust's Vlad Taltos series (including an advance copy of Iorich thanks to Patrick at Tor). I know that I had read Jhereg before, and I'm pretty sure that parts of Yendi were familiar; what I can't figure out is why the hell I would have read the first two books, but not gone on to devour the rest of the series, because it's awesome. They are (for the most part) hard-boiled fantasy detective novels, not dissimilar in tone to some of my favourite contemporary detective series (Spenser, Elvis Cole, Myron Bolitar, et al.) The "detective" may be a witchcraft-using assassin, and his sidekick a miniature dragon (jhereg) on his shoulder, but the mean streets of the city are still mean, and when tough talk fails, knocking a few heads together often shakes loose the information required.
That only really describes the surface appearance of this series, though; the underlying world is rich and complex, full of Gods, Great Weapons, ancient sorcery, discrimination, social unrest, and peasant revolutions. Another thing that appeals to me about the books is that they are short, in the 200–300 page range. Steven Brust says what he wants to say, and then moves on. I like that. (Unfortunately his writing style in the other Dragaeran books has the opposite effect on me. I haven't been able to get past the first few pages of The Phoenix Guards.)
Finally, some non-fiction. I have been interested in non-verbal communication since I picked up a copy of Allan Pease's Body Language in the mid-eighties. In fact, this is one of the reasons I dislike working remotely. Phone calls strip out all the visual cues I use to pick up on the mood of the office, and to gauge unvoiced concerns in a meeting.
Joe Navarro is a former FBI agent with a background in interrogation and deception detection, and What Every Body Is Saying pays a lot of attention to reading the signals people emit during conversation. Navarro emphasizes that this is not about being able to tell whether someone is lying or telling the truth (although that does make for good TV), but rather about learning whether someone is confident or holding back, relaxed or stressed. When you understand that, you can try to guide the conversation to figure out why they are feeling that way.
Interestingly, this has significant use in usability testing. One of the tenets of usability testing is that you pay attention to what people do, rather than what they say. People are often reluctant to criticize, preferring instead to tell white lies about things they dislike. By studying their posture, gestures, and expressions during a test, and in post-test conversations, you can gain a much better understanding of their emotional state, and where problems lie.
This is definitely one of my top picks of the year. It's very clearly written, and sprinkled with good illustrations, and not only does it make an excellent introduction to the subject of non-verbal testing, but it also rewards repeated reading and bite-sized dippings-into. Very excellent.
]]>No fit of pique for me, actually. More like a gradual aha, with a slight wince and sigh at the end. I’ve spent the past year or so reading and writing and doing my level best to chip away at 40 years of belief in the logical fallacy that one’s identity meaning – self-worth, self-image, whatever you want to call it – can accurately be measured in the thoughts of others. Much as you and I may enjoy being encouraged through recognition and praise and dislike being saddened by rejection or indifference (god knows we’re taught to right from the outset by caregivers: good boy, pretty picture, heckuva job Brownie), deriving personal value from these transactions in the absence of a well-formed internal frame of reference through which you can decide on your own what does and doesn’t work, and subsequently accept the opinions of others as feedback, is just plain faulty thinking, of the sort that makes otherwise capable, centred people all loopy and weird.
I never used Favrd; I haven't spent a lot of time thinking about the rights and wrongs of shutting it down so abruptly. What I have spent a lot of time thinking about is my own sense of self and self-worth. I intend to spend more time on this in 2010.
]]>Yeah, I miss those days too. Twitter (which I will use as shorthand for any short messaging service) makes it very easy to post a quick thought, a status update, or a link to something interesting. Much of blogging used to be like that, but the blog postings used to be longer, with more context. I rarely posted one-line blog entries or simple links, because I felt that a blog entry should have some kind of story — a thread, a narrative — to guide the reader to a particular conclusion or insight. This classical "essay" model of blogging has problems, though:
Over the last year, I have heard many people say that they blog much less now that Twitter is around. By providing an outlet for people to express themselves quickly and efficiently (albeit in 140-character chunks), it bleeds off a certain amount of creative pressure that would otherwise have led to more and longer blog postings.
I don't want to make this a lament on the "death of blogging", because blogging emphatically isn't dead; otherwise, where would we all find the cool links to tweet about? In fact, good blog articles benefit from Twitter, because it provides a fast and social notification medium in parallel to the existing mechanisms of RSS feeds and reblogging.
Furthermore, "The Tweet" is as much a new form of writing as blogging was, with its own grammar and conventions. In his article "How the Web and the Weblog have changed Writing", Philip Greenspun talks about how blogs have given a natural home to ideas that don't need to be padded out to a whole book or a full-length magazine article; Twitter is just the next logical step.
The web has given us an unprecedented range of tools with which to express ourselves. It is up to us to learn to use these tools, and to understand when it is appropriate to use each one.
]]>Source code is for humans, live code is for machines.
I first heard Christian Heilmann state this rule at @Media Ajax 2007 as "production code is for humans, live code is for machines" but I prefer the term "source code" to "production code". The rule was important and prescient then; now I consider it the absolute foundation of any significant web application.
Rule 1 comes into play as soon as you have a project that involves any of the following:
In olden days (say, 2006), the JavaScript code for many web applications consisted of a single file. Comments were few and far between, and variable names were kept short because we wanted the code to be as small as possible. But this strategy does not scale. As projects get more complex, a single file filled with non-descriprive functions and one-letter variable names quickly becomes unreadable. In modern web application development there are two weapons we can use to tackle this problem: concatenation and minification.
Concatenation is the process of taking multiple JavaScript files, and combining them into a single file. Minification is the process of transforming a JavaScript source file to make it smaller. Early JavaScript minifiers just removed comments and unnecessary whitespace, but modern minifiers (YUI compressor, Dojo Shrinksafe, Google Closure Compiler) can also perform more aggresive optimizations, such as shortening variable names and removing unneeded code.
Basically, the JavaScript source code that developers write is no longer the JavaScript code that end users receive, and can see when they view the components for the page. The first benefit of this is performance: concatenating files reduces the number of HTTP requests web app requires, and minification reduces the download size (and can also reduce parsing time on the client). The second benefit comes in the form of better source code clarity, which is good for development and maintenance:
A further consequence of this is that when you are writing JavaScript code, you now have to keep three audiences in mind:
Personally, I am most familiar with the YUI compressor. If you choose to use it, then Nicholas Zakas' slide deck on structuring your code for optimal optimization is required reading. In addition to helping the YUI compressor make your code even smaller, many of these tips make for tidier, more comprehensible code; and because they encourage the use of local instead of global variables, they can even make your code run faster too. Here are some of the main points:
var keyword and one return statement per function.eval, with, or JScript conditional comments.Where exactly you apply the concatenation and minification is up to you, and will depend on how your deployment pipeline is set up. You can do it as part of your build process, or you can do it at runtime — provided you have some form of caching enabled so that you don't repeat the process for every request.
*Finally, I should note that the process of concatenation and minification is not the single most effective strategy in reducing the download size of your JavaScript components; that honour goes to gzipping, so I suppose that enabling gzip compression on your web application should, in the programming tradition of zero-based lists, be considered as "Rule 0". But when it comes to maintaining a complex application, and delivering a compact download package, this is the way to go.
]]>Just to be clear, MT5 should work fine with Safari. Actually, the UI designer mainly uses Safari to develop MT5.
On the other hand, supported platform is defined by the platform which QA team conducts their test. It is now
* Mozilla Firefox 3.5 or higher
* Internet Explorer 6.0 or higher
He slightly elaborates on this on the MTOS-dev mailing list, also on 9th December:
That's the difference between "Supported" and "Should work fine". I'm sorry that the System Requirements page on MT.org is not precise on that part. We will fix it.
The System Requirements page for MT was last updated on 10th December. The "Web Browser" section currently reads:
As Movable Type is a modern web application which uses Javascript and AJAX extensively, it requires a modern web browser. We strongly recommend the latest version of the following browsers. Browsers are free and easy to upgrade!
The Movable Type is tested and supported on the following browsers:
- Mozilla Firefox 3.5 or higher
- Internet Explorer 6.0 or higher (We STRONGLY recommend the latest version).
Movable Type should work fine with other modern browsers, but is not tested with these browsers:
- Safari 3 or higher
- Opera
- Chrome
- etc.
As a web developer, I completely understand the difference between "supported" and "should work". Yahoo's Graded Browser Support policy, with its definitions of A, C, and X-grade browsers codifies this concept neatly. With limited development and testing resources it is impossible to fully support every browser.
But for a company like Six Apart to restrict their list to IE6+ and Firefox 3.5+ is mind-boggling. First of all, there is a huge contradiction between the two platforms they do support: IE6 is eight years old, used by a small and rapidly declining percentage of users, and is widely known as the least capable browser platform still in common use today; Firefox 3.5 is one of the most advanced browsers currently available, but it was released a mere six months ago. Secondly: no Safari. Safari is the browser of choice for the vast majority of Mac users, and enjoys significant use on Windows, too.
The only thing I can think of when I look at that list is: enterprise. Movable Type has now completely abandoned its former user base of hobbyists, bloggers, and geeks, and wants to concentrate on selling into the corporate market. The vocal minority of people who will be pissed off by the absence of official Safari support &mdash the trendsetters, the evangelists, the plugin developers, the tutorial writers — are not the people 6A is interested in reaching any more. To be honest, most of them left for Wordpress, Drupal, or ExpressionEngine a long time ago. For several years now, Movable Type has been lacking in product momentum, community, and cool factor, but damn it, it's a great product with a fantastic feature set, and it's an awesomely stable platform on which to build a site.
But if MT is abandoning me (I'm writing this in Chrome — not Safari, but part of the Webkit family), I don't think I can continue to recommend it any more, and this makes me very sad.
]]>
Fronteers is the Dutch organization for Front-end web developers. Since 2007 it has run regular meetings for members and non-members, and it also runs an annual conference that attracts speakers and delegates from all over the world. For some reason I didn't blog about the 2008 conference, but here's my report of the 2009 conference that took place at Felix Meritis in Amsterdam last week. It was a single-track conference with remarkably few beards present — I'd estimate that fewer than 10% of the men were sporting facial hair (even including soul patches), an extremely low figure for the tech industry.
The speaker photos in this blog post were made by Marien Van Os (marvos on flickr), used under a Creative Commons license. (And also by permission -- because it's polite to ask.) Please go and have a look at his photos on 1pictureaday.com, because they're amazing.
Molly opened the conference with an overview of where "The Mobile Web" stands today, and what we can (and should) be doing to work with it. Her view is that the most practical strategy at the moment is to create a single site for both the mobile and desktop web ("desktop web" being the term that many of the speakers used to distinguish the "traditional" mode of accessing the web with a PC and a browser), but optimize the experience for the device. This means using things like server-side UA detection, CSS media types, capability detection, and CSS3 media queries to determine what the user is browsing with, and adjust the display accordingly. This certainly fits with existing best practices for accessibility, which emphasize progressive enhancement over graceful degradation; progressive enhancement for mobile devices can be treated as another branch of the same tree.
Peter-Paul has recently been doing research into mobile browsers, and has published a ton of useful and interesting information on his site Quirksmode.org. Here he talked about the mobile browser landscape, highlighting the fact that — at present — you have almost no hope of building a site that will render the same on all devices.
He then went on to discuss W3C Widgets, which is a specification to allow you to package up a single page of HTML, along with CSS and JavaScript, and deploy it as a single package to a widget-capable device. The device typically uses a separate runtime to display the widget outside of a browser context, which makes it seem much more like an application than a web page. The technology to run these widgets exists already on S60 phones, and in Opera Mobile, but it is unlikely that the iPhone will (ever) implement it, which is a significant downside for developers who would like to target a uniform platform.
Chris is always an entertaining speaker. He is passionate about the web, software development, and the technologies we have available to us today. Although the topics he covered in the first half of this presentation were fun and inspiring (don't hang on to knowledge beyond its use-by date; share your skills; use a JavaScript library), it was the second half where he talked about YQL that really set the audience alight.
In case you haven't come across it before, YQL is a service from Yahoo! that allows you to run SQL-like statements on the web. Not as in, "here's a web-based interface to a back-end SQL database", but as in, "select * from flickr.photos.search where text="Cat" limit 10" to get a list of cat pictures from Flickr as XML, or as JSON with a callback (JSONP) so that you can get the results directly from client code, with no server-side proxy needed.
(Pause for awesome.)
YQL has been publicly available for about a year now, and has been getting steadily more powerful and useful. Not only can you query Yahoo's own services, but community tables allows anyone to create a table definition for any arbitrary web service. You can use XPath queries to select data from the HTML of an arbitrary web page. It is cool, useful, and above all stable. It is built on top of Yahoo Pipes, and apparently powers many of Yahoo's own new services now. According to Chris, "if YQL goes down, Yahoo goes down."
If you haven't tried it yet, just fire up the developer console and experiment with some of the sample queries. You don't even need a developer key to get started, and run YQL queries from your own applications.
Martin spoke about the processes and techniques they use at Mirabeau for organizing their front-end code to help with things like client hand-overs, version control, and build processes. Everything he talked about was good practice, but none of it was new to me; and the case study he showed wasn't what I would consider "complex."
Stephen discussed the three competing layout modules currently under consideration for CSS3: CSS3-grid, CSS3-layout, and CSS3-flexbox. All three of these proposals allow you to specify a layout for your elements in CSS independent of the element source order -- which means no more tedious mucking around with floats and negative margins to implement grid-based page designs.
Unfortunately, the only native browser implementation that exists right now is CSS-flexbox in Firefox. There is a jQuery plugin that implements the CSS3-layout functionality, which is interesting. Stephen seemed to favour this proposal, and I like it, too. Your CSS effectively contains an ascii art representation of what the layout will look like. It's a very visual representation, and is easy to explain and understand. Combined with CSS3 media queries (different than CSS2 media types), CSS3 layout will completely change how we provide support for multiple resolutions, media, and devices in our sites.
When you talk about JavaScript testing, what you usually mean is testing whether a piece of JavaScript works correctly on a page in a web browser. Does panel A expand when you click button B, for example. You are testing DOM interactions -- with all the cross-browser fun that brings -- as much as the actual algorithms.
John noted that there are many JavaScript frameworks available for running unit tests on client-side code: QUnit, JSUnit, YUITest, etc. He demonstrated that writing such a framework is not even all that hard. What is hard is scaling this kind of testing. When you have half a dozen major browsers to support, each with potentially dozens of variations, how do you effectively manage your test suite?
John has recently been working on TestSwarm, a distributed continuous integration JavaScript testing solution. You point a set of clients at a central server, and the server distributes tests for the client to run. At the moment, TestSwarm.com exists to support testing for some of the most popular JavaScript libraries (jQuery, YUI, Dojo, et al.), but you can download the code to run your own server and set up your own swarm of clients to for your own projects.
Steve Souders literally wrote the book on web site performance. (And its sequel, too.) He created YSlow, Hammerhead, SpriteMe, and writes extensively about performance on his blog. Front-end performance is a subject very close to my heart, and I was very excited that he was speaking at Fronteers this year.
The theme of his talk was Fast By Default. There is a lot of research and information available that shows how much the perceived speed of a web site depends on front-end performance, and how much of an impact this speed (or lack of it) has on the bottom line for a business. So why don't more businesses spend more time on it? Because it's actually still quite hard.
Steve highlighted several tools that can help with this, though. Aptimize Website Accelerator, for example, is a drop-in software solution that automatically applies optimizations like rolling up multiple JS and CSS files to reduce HTTP requests, minifying and gzipping JS and CSS resources, and spriting of CSS background images. WebPageTest.org, a web version of the AOL PageTest tool, gives extensive performance statistics and optimization tips for any page you choose to submit. ShowSlow.com uses showslow to collect and chart YSlow performance statistics over time, so you can see trends for your pages. SpriteMe, Steve's own tool, analyzes a web page and gives you ready-made CSS sprites and sample CSS code to optimize your background images.
He also talked about progressive rendering, the techniques available for parallel downloading of script resources, and recent innovations in this area, such as reducing startup latency by putting script inside comments so that it the code isn't parsed as soon as it is downloaded. Instead, you wait until the code is needed, remove the comment markers (/* */) and eval the whole block.
Douglas Crockford really knows how to weave a good narrative. He leads you through important and complex material with the grace of a great storyteller -- his presentations often feel like documentary films. In this one, he talked about Ajax security.
The core of the security problem with "Ajax" (using that as a convenient shorthand for third-party script inclusion) is that third-party scripts have the same rights on a page as scripts from the host site. Third-party script can take over the page, and there is no way for the user to know that what they see is not part of the application. If the script is malicious by default, we call this a XSS (cross-site scripting) attack. But even well-intentioned inclusions can turn sour, as the New York Times found back in September. Basically, as soon as you include third-party script, you give up control of your page. Douglas put it succinctly as follows:
A mashup is a self-inflicted XSS attack. (Advertising is a mashup.)
(Digression: Adverts are the bane of my life. If you want to include banner ads on your site, an ad network will typically give you a piece of JavaScript to insert on your page wherever you want the ad to appear. This JavaScript will typically be some of the most hideously tortuous code you have ever seen. It will reveal a positively Lovecraftian chain of document.write() calls, eval() statements, and nonsensical browser hacks that eventually result in a 2MB Flash file being pulled over a 28.8kbps network connection from somewhere in Kazakhstan. Advert code is the closest thing modern science has to the Berryman Logical Imaging Technique. I hear that the CIA used to teach terrorist suspects JavaScript just so they could expose them to advert code, and break their wills.)
However, it turns out that by adopting an object-capabilities model, third party scripts can be secured. I didn't understand object capabilities the first time I came across them (at @media Ajax in 2007), but this presentation made the principles clear. Douglas's ADSafe defines a safe subset of JavaScript, and an API with which the code can get access to the DOM. The JSLint tool has an ADSafe mode that allows you to statically check a JS file and prove that it conforms.
What we need now is for advert publishers to start publishing adverts for the modern web:
document.write() calls, so that we we can avoid the performance penalties of inline code (and the hacks we sometimes use to get around them anyway)
Unfortunately, site owners are not in a position of power here. The advert publishers have code that "works": so long as you stick to their guidelines, it loads in virtually any browser with JS enabled -- at the expense of performance. They don't own the sites on which the ads appear, so they are not the target of security vulnerabilities. As Douglas put it towards the end of the presentation:
The advertising problem is serious. The publishers must go as one to the advertising industry and demand basic standards of ad quality.
Afterwards, I was chatting with Martin Reurings and Sam Foster about this. One of the options we discussed was creating some kind of action group like the Web Standards Project (WaSP) to fight for sanity and standards in web adverts. (Might this even be grounds for another WaSP task force?) This has been going round in my head ever since, and I want to write more about it soon. If you have an interest in this subject, please leave a comment below.
Pete spoke about some of the features available in IE8 that were not there in previous versions, such as mutable DOM properties, native JSON, and the selectors API. Not all strictly HTML5 features, but hey. He also highlighted the SuperPreview tool (part of the Expression Web suite) that allows you to preview web pages side-by side in various browsers, e.g. Firefox and IE8. It also has the IE6 rendering engine built in to it, so you can even use it to test IE6, IE7, and IE8 on the same machine, without resorting to unsupported hacks. This is very cool, and there is even a free version available (SuperPreview for IE), which is limited to comparing pages in the different versions of IE, but which is still very useful for doing compatibility work.
Native web fonts are big right now. With the release of Firefox 3.5 earlier in 2009, we have reached a critical mass of browsers that support embedding of fonts with @font-face. Okay, so you have to have the font in several different formats (TTF, EOT, SVG) for it to render in all of the supportable browsers, but at least it's possible. Well, technically, at least. There's still that whole licensing issue.
Jonathan has done a lot of research into web fonts recently, and in this presentation he took us through all the available options, from text replacement techniques (sIFR and Cufón), right up to WOFF support in Firefox 3.6. There are many different things to consider to get @font-face fonts to work correctly (and legally) on as many browsers as possible, but the results are lovely. Give it another year or so, and we'll be wondering how we ever built sites without them.
Xopus make a WYSIWIG XML editor for the web. It's a big application -- more than 120,000 lines of code in about 1,150 files -- and Robbert talked about some of the challenges they have in getting it to perform well. For a user, the responsiveness of the application while typing is crucial: the browser cannot be allowed to freeze up while it is processing keystrokes, and the user must not have to pause typing just to let the browser catch up with what they have done. Xopus therefore makes extensive use of event handling queues, and chunked processing with setTimeout() calls to keep everything running smoothly.
Thomas Fuchs is the author of the script.aculo.us UI framework. However, for small projects sometimes a library like that can be overkill. So Thomas has developed Émile, a tiny and utterly beautiful library that provides basic but useful animation effects: colour transitions, movement, and easing. And when I say tiny, I really mean tiny. It fits into 50 lines of JavaScript code, and minified and gzipped weighs in at less than 1K.
Because it is so small, Thomas was able to guide us through it line-by line in less than an hour. He clearly explained all the principles behind the effects that the library provides, and showed precisely how to implement them all. At each step he showed the problems that could arise, and what he did in code to circumvent them. The Emile library is a delightful piece of tight, elegant code; the presentation itself was a masterpiece of education.
CSS is a funny old thing. I'm starting to think that of the three pillars of modern front-end web development (semantic HTML, unobtrusive JavaScript, and CSS), CSS is actually the hardest to do well.
There are many CSS frameworks available that assist in setting up things like grids and typography, and many of these advocate some kind of "modular" approach, though what exactly "modular" means can vary. But all of these approaches are very hard to scale once you get up to sites (or applications) with tens, hundreds, or even thousands of different pages, layouts, or widgets. Knowing how to create cool new CSS3 gradients, rounded corners, and transitions is one thing; making that CSS re-usable, efficient, and maintainable and for a large-scale site is a whole different ball game.
Nicole Sullivan reckons that modular CSS -- in this context, taking "modular" to mean CSS specific to a visible block of content on a page -- is fundamentally a mistake. I have often used exactly such a modular approach specifically to isolate modules from each other: if you want to change the styling of one module, you don't run the risk of screwing up something else. As Nicole points out, however, this approach results in your CSS expanding linearly with the number and complexity of your modules, and does not allow for effective re-use of code, or good design consistency.
Object-oriented CSS is an approach that Nicole has been writing about for some time now. It's a pattern for designing re-usable content modules by making better use of the CSS cascade. It's the cascade, in conjunction with carefully structured HTML, that allows us to use object-oriented techniques like inheritance encapsulation for styling our HTML. To be honest, when I first started reading about OOCSS earlier this year I was skeptical, but I have gradually been coming round to it, and am starting to appreciate its subtlety and usefulness now. I'm not sure if it is the ultimate answer to creating effective CSS, but it is definitely an important piece of the puzzle.
Poor Ben was really sick with the flu, and should have been in bed rather than on stage. But he made it all the way through to the end nonetheless, and they closed the conference with one of their classic inspirational rallies, guaranteed to leave you with a smile on your face and a spring in your step.
They talked about all the things that excite them about the future of the web, such as canvas, GPU acceleration, and web workers, which will allow us to build applications that previously would only have been possible as platform native apps. "Mobile" featured heavily, of course, as it did throughout the conference. They are firmly convinced that the future lies with "devices" -- not just mobile phones, but anything outside the traditional PC form factor. And I'm pretty sure they're right.
The biggest challenge ahead is going to be keeping "the web" as a flourishing common platform, and not allowing the device space to splinter into incompatible proprietary walled gardens. This isn't a far-future challenge, either -- it's happening right now.
Fronteers 2009 was a fantastic conference. The quality of speakers and presentations was great, and the spectrum of technologies they covered was just right. There were plenty of opportunities for chat and networking, and even the lunchtime food was pretty good. (Long queues, but that's only to be expected.) My thanks to all the organizers and volunteers who made it happen: great work, guys. I'll definitely be there again next year.
]]>The Tester is always right. I will listen to the Tester. I will not ignore the Tester's bug reports. The Tester is god. And, if this ever happens again, the Tester will personally rip your lungs out.
This comes courtesy of Abi, who subverted the Babylon 5 mantra for the purposes of educating inexperienced developers.
I was somewhat miffed when I discovered that Neko Case was playing Amsterdam in February this year by checking her web site a few days after the intended gig, and finding that she had had to cancel it because of an illness. On the one hand, I had missed seeing her; but on the other hand I would have missed seeing her anyway. Hmm.
Fortunately, her autumn tour brought her back to the Netherlands, where she played Paradiso on Saturday 19th September. Abi and I managed to wangle babysitting for the evening, so we could both go. It was a lovely Saturday, and we cycled in to town and had a burger at Burgermeester before the gig. We had a delightful evening, but as concerts go it wasn't that great.
Although Neko was in fine voice, she looked tired and unhappy. Kelly Hogan, the second vocalist in the band, did all the talking between songs, occasionally throwing a line to Neko only to be rebuffed with a shrug. It was only towards the end of the set, when the end was in sight, that she even cracked a smile and started to engage a little with the audience. I know that she had had to cancel at least one gig earlier this tour because of illness (Edinburgh), so it's possible she still wasn't feeling right. However, the overall vibe I got from the stage was aloof and reluctant, which was disappointing.
Having said that, the actual performance was good. Neko's voice is one of the modern wonders of the world, and Kelly Hogan's provides a great accompaniment. The band was clearly comfortable playing together, and Jon Rauhause, hunched in intense concentration over his banjo and steel guitar, was a special treat.
They played through most of the new album Middle Cyclone and a helping of favourites from earlier albums. "Maybe Sparrow" was a definite crowd-pleaser early on, but the songs from Blacklisted were the ones I liked best, with "I Wish I Was The Moon" in the middle of the set being my personal highlight. It seemed to me that "The Train From Kansas City" right at the very end was where the band really seemed to shake loose and enjoy themselves the most. It's just a pity that they didn't light up earlier on.
Encore:
MC = Middle Cyclone, FCBTF = Fox Confessor Brings The Flood, BL = Blacklisted, TTHS = The Tigers Have Spoken
]]>