Ross’ PhD Blog Memex

• Currently Listening to: Neil Young — Cowgirl in the Sand

“TED” (Technology, Entertainment, Design) is a conference run each year which brings together a mix of scientists, entrepreneurs, performers and thinkers of all types who trade in the fundamental currency of ideas. They get some terrific speakers in to wax lyrical for twenty minutes or so about what’s on their mind, and for the last few years the best talks have been put online. It’s hard to choose which ones to watch, but some of the ones I found worthwhile are:

Jeff Bezos: After the gold rush, there’s innovation ahead

Bezos is the founder of Amazon and someone who knows a thing or two about fluctuations in the fortunes of the web. He begins by connecting the dramatic boom and bust of the web to the rise and fall of the American gold rush. Switching analogies, he goes on to liken the enabling effects of the introduction of the web to the introduction of electricity into people’s homes.

Dan Gilbert: Why are we happy? Why aren’t we happy?

Fascinating talk on the nature of human happiness, our “psychological immune system” and how parts of our brains have evolved to be able to simulate experience and fake happiness when required. Also discusses the pyschology of choice: how having less options will generally result in happier people.

Jeff Han: Unveiling the genius of multi-touch interface design

Before all the hoopla about the iPhone’s touch-sensitive screen, there was Jeff Han, and one of the best technology demos I’ve ever seen.

Seth Godin: Sliced bread and other marketing delights

Marketing master Seth Godin on the requirement that a product or service be not just “very good”, but remarkable to succeed, and why early adopters are the most important group to market to.

Malcolm Gladwell: What we can learn from spaghetti sauce

Writer and master of the cross-disciplinary insight, Malcolm Gladwell (of The Tipping Point fame) illustrates the fallacy of designing anything for the “average user”.

(via Aaron & Mike.)

Hello ruby in the dust
Has your band begun to rust?

• Currently Listening to: Depeche Mode — Policy of Truth

The web today is a-flutter with calls for new “standards” to fight back against the increasing problem of hostility in the world of blogging. This comes on the back of a spate of unpleasant, unprovoked attacks on various bloggers because of their politics or views on seemingly harmless topics.

Tim O’Reilly and Jimbo Wales have jointly put forward a proposal to tag websites with somewhat quaint badges, showing what level of discourse you can expect to see. This idea seems doomed to failure to me, despite the big names that are pushing it through. As they stand, the draft “Code of Conduct” has a number of problems. For example,

We do not allow anonymous comments.

We require commenters to supply a valid email address before they can post, though we allow commenters to identify themselves with an alias, rather than their real name.

Identity spoofing is ridiculously easy at the moment, so this recommendation just can’t work. At least until initiatives like “Identity 2.0” and OpenId take off.

On the badges, Jeff Jarvis writes:

[The blogosphere is not a medium.] It’s a place. And when I moved into the place that is my town, I didn’t put up a badge on my fence saying that I’d be a good neighbor (and thus anyone without that badge is, de facto, a bad neighbor). I didn’t have to pledge to act civilized. I just do.

Indeed. I posit that the big win here will come from improvements in policy enforcement, rather than up-front policy declaration. Everyone already knows they’re not supposed to act like a jackass.

The NYTimes article linked above notes

A subtext of both sets of rules is that bloggers are responsible for everything that appears on their own pages, including comments left by visitors. They say that bloggers should also have the right to delete such comments if they find them profane or abusive.

The problem here is that deleting moronic or venomous comments does nothing to stem the tide of trolling that a particular post is going to attract. It merely hides the problem under a rug for a short time, before someone, on finding their comment deleted, decides to write something even worse, perhaps in a place where the original poster doesn’t have such sweeping editorial control.

Online discussions are entropic, and it only takes one misinterpreted or snide comment to transform the complexion of a thread into a chaotic flamewar of no merit. Chaos begets chaos, and maintaining the quality and order of a discussion requires both time and vigilance.

A few years ago I saw an interesting approach by Sam Ruby, very nicely illustrated through an anecdote here by Mark Pilgrim. The theory:

In social sciences, there’s a theory called the “broken window” theory. It states that a little ongoing maintanence — like fixing windows as soon as they get broken — can have dramatic effects. It also states that the smallest sign of destruction, if left untended, tends to bring about more destruction. Even in a “good” neighborhood, where normally people wouldn’t dream of being randomly destructive.

This is powerful thinking, and the most effective way to deal with the problem that I have seen. Passages in comments are selectively marked as “flamebait” by the site’s owner, which then appear as text with a strike-through to anyone reading the comments. This allows a site owner to Bowdlerise a comment in line with their site’s own (stated or no) comments policy, and leaves a tangible signifier to anyone else thinking of commenting that there is a single voice patrolling the comments and keeping order.

• Currently Listening to: Bernard Fanning — Songbird

So Christmas arrived, and I managed to secure a Nintendo Wii (thanks Nikky). I’ve been a crazy Nintendo fan ever since that fateful day I got my first NES back in about 1989. I shamelessly wear geeky Mario-emblazoned t-shirts and have engaged in countless fruitless “which console is better” debates with friends and enemies. Shigeru Miyamoto is an idol of mine. And every new Nintendo console has been a special occasion.

Mark receives the thrashing of a lifetime!

Wii Sports is the very definition of a “killer app.” On the surface so simple, but containing surprising levels of depth and nuance. Once a friend has hit their first home run or cross-court volley, they’re hooked, and in most cases, go home wanting one. A number of times now a friend has taken a break from flailing their arms around to remark, wide eyed, things like “It’s amazingly accurate”, and “The speaker in the controller is a really good idea!”. Yes. I know.

While chasing my dog around today I was marvelling at her natural instincts to want to run around the whole time. It’s a game for her, and probably her favourite thing to do apart from tearing the house to shreds. The developing problem we’ve got as a species is that we got too goddamned good at building things that are even funner than basic locomotion. The Wii is a very smart move back in the opposite direction.

• Currently Listening to: Tom Roger — Timelock

Time management is becoming an increasing concern around the office, with a number of us turning to David Allen’s highly addictive Getting Things Done methodology. Some basic, seemingly-obvious productivity tips I have picked up over the last few weeks:

• Don’t sit beside Mark.
• One of the fundamental tenets of GTD is to get everything out of your head and onto a todo-list. For me, that todo list needs to be web-accessible so that entries can be added from wherever you are. I use Basecamp, which is almost exactly what I need. Though I’m sure when I’m procrastinating about something or other in the future I will decide to write my own, better version .
• Rationalise the mailing lists you’re subscribed to. Some of the ones I’m on (like our internal SRG-members list) need to be always-on, but others, like the list for Gallery developers, is now delivered to me at the end of the day as a digest of the day’s discussions. This has saved me a lot of time.
• Clear your inbox. I’m a big fan of Merlin Mann’s “Inbox Zero” series (and basically his whole site). It warrants re-reading again and again. Using the two-minute rule and systematically whittling your concerns down mail by mail is highly rewarding, and spares you from having to keep your mail client open all day.

• In terms of email management, I’ve found that a lot of the habits I’d gotten into actually resulted in me spending more time hopelessly wrangling messages. For instance, there is little point in creating a folder for mail from a certain person, or filtering based on words in the subject. I’ve noticed some people in the labs with gigantic hierarchies of nested folders. The time it takes to decide on these partitions, set up filters or manually place mails into these folders, and then maintain that arrangement over time where requirements and priorities are constantly in flux is frightening.

  With the search capabilities of modern email clients, these filtering steps become redundant, as email is much easier to find again by simply dumping them all into a single place and then performing a keyword search on a large folder. There are loads of strategies you could try, but right now I’m trying to minimise the amount of folders I use. The only mail I keep in my inbox are those that I need to reply to, or the ones I’m waiting for a reply on.

• In a similar vein, I’ve been realising more and more that GMail is remarkably well designed, once you understand how best to use the “archive” button — which unfortunately seems to have passed a lot of people by. Once you’re finished with a mail that doesn’t require any action on your part, just hit “archive” and you don’t have to think about it again unless you need it in future, by which time it’s nestled safely in your “All Mail” view. You can get similar archiving functionality in Thunderbird with an extension.

• Currently Listening to: The Strokes — Trying Your Luck

So, I got my first paper finished and submitted in time to a workshop at AVI 2006 entitled “Context in Advanced Interfaces.” Worked all the way up to 15 minutes before the deadline (which I’m told is “decent buffer”). An arduous but rewarding experience, and I couldn’t have done it without the help of our terrific support structures in the SRG, namely our academics and postdocs. As Lorcan put it so nicely, “Welcome to the anti-rat race dude.”

Update 2006/04/08: Got ‘er in.

• Currently Listening to: Metallica — Orion

So we’ve been thrashing out some ideas for our Distributed Systems practical, which is insanely tight on time.

The challenge is to build a distributed file system across the computers in the fourth year lab. The primary goal is robustness, but we’re also striving to make it as fast as possible. It’ll be tested by adding some text files to the system on some computer, allowing them to disseminate for a while, and then stressing the system through a combination of Steve flooding it with traffic and Paddy fervidly unplugging random machines from the network. We will presumably be assessed on the availability of the original files once the dust settles.

Here are my own, possibly naïve plans for how this is going to go down. These ideas are a distillation of some heated exchanges we had on Monday. They’re subject to change as I become privy to new information, man.

* The first task is to discover the other machines on the network. It has been suggested that Apple’s Bonjour networking system is ideal for dealing with “dynamic node membership”. Each machine will cultivate a peer list, and add or delete machines as they join, or are forcefully extricated, from the network.

* Each file will have to be broken up into chunks. The spec says they have to be split into 1KB chunks. Each of these will need to be packaged as an object, and be tagged with relevant metadata so we can tell which file it was originally part of. We then serialise the object for transfer, and deserialise when it’s received. This adds a considerable amount of overhead to the system, but it’s necessary as far as I can see. Some of the metadata properties each fragment needs are the source file’s original filename¹ and the part of the file it corresponds to (more on this in a moment).

* Each file is first slurped into a ByteArray. This means we can send various slices of the file to other machines on the network. Each slice (being the packaged 1KB chunks) will also have to store which part of the file they contain, which is simply their index into the file ByteArray. When reassembling the file, we first build up an empty ByteArray of the same size. We then send a call out to the other machines on the network, and they send back the fragments of the file we want. The full array is then folded back into a usable file.

* Each computer on the network will need to build up and maintain a listing of all the files — and fragments of files — that it currently stores (and yes, this means the hard drives on all the computers will fill up inexorably; this is the price we pay for true robustness). Each file is to be addressable by filename and by the hash of its contents. For this we need a HashMap with two keys for every value. The value they both point to is of course a key into another Map somewhere else, to avoid dangerous duplication.

* This index table will also store a record of the original file size and hash value of the full files². It does not need to store any reference to the data stored on any of the other computers.

* When a search request for a file (by filename or hash value) is received, the machine running our system (the “local machine”) first searches its own index to see if it has the file on its own hard drive, or has replicated parts of the file itself. If the full file hasn’t been found, it searches over k nearest neighbouring machines from its peer list, which are hopefully ordered by their ping.

* Yes, this may mean having to search every machine on the network in pursuit of a single missing kilobyte of the file. Creating a partly-centralised system like distributed hash tables has too many problems of their own. Primary among them being the fact that the hash table itself needs to be distributed and replicated, which is the problem we’re trying to solve in the first place. We still need to look a little deeper into this aspect.

* The key to this all working is that when we replicate a file, or part of a file, to another machine, we also send its corresponding record in the index table. This means that any computer that has part of a file also has a record of that in an easily-searchable format. So, when the search request propagates out to one of these remote nodes, it can very quickly ascertain whether it has part of the requested file or not, and return yay or nay.

* This discussion doesn’t attempt to guess at the “magic number” of nodes we should replicate file fragments to at a time. Logic would dictate that we should try to have every fragment of every file residing on at least three computers at a time if robustness is going to be maintained. There is likely some number to be deduced, based on the number of nodes in the network, the amount of files and amount of free space available, but we’re unlikely to work this out without first implementing the system.

1. Instead of storing the filename as text, it would be a nice optimisation to store a reference to the file’s record in the index table instead. ↩
2. This can be easily extended so that the index table holds additional metadata about each file, like singer and album details for music files. These would then also be made searchable. ↩

Update 2006/05/18: We successfully completed the assignment. Here’s my writeup comparing and contrasting current peer-to-peer systems.

Peer-to-Peer Systems Individual Research Report prepared for completion of Comp 4.14: Distributed Systems

• Currently Listening to: Modest Mouse — Float On

This paper describes visualising the process of looking after a medical patient, using multiple, simultaneous, tightly-coupled views.

@inproceedings{1019226,
 author = {Wolfgang Aigner and Silvia Miksch},
 title = {Supporting Protocol-Based Care in Medicine
   via Multiple Coordinated Views},
 booktitle = {CMV '04: Proceedings of the Second International
   Conference on Coordinated \& Multiple Views in Exploratory
   Visualization (CMV'04)},
 year = {2004},
 isbn = {0-7695-2179-7},
 pages = {118--129},
 doi = {http://dx.doi.org/10.1109/CMV.2004.19},
 publisher = {IEEE Computer Society},
 address = {Washington, DC, USA},
}

Though the middle sections of this paper do not have much specifically to do with my own field of visualisation, they do contain a lot of good passages on visualisation techniques. Visualising time-orientated data is particularly interesting. They refer to the somewhat misleadingly named “fisheye view”, in which the focused element is enlarged and centred, and all other elements are distorted by shrinking and moving them outwards, which is a nice way to better make use of display space.

There is also a good introduction to using multiple simultaneous views, each focusing on different aspects of the data. They go about this by splitting the display area into a Logical View and a Temporal View. This approach could also be used to visualise sensor data — in effect explicitly denoting the scientific and information visualisation aspects.

There is also a section on setting up a user study to ascertain the needs, general practices and expectations of seasoned medical professionals. This is relevant as I may well have to set up some testing time with domain experts to test if our new visualisation environment is indeed more useful for collaboration than the way things are currently done.

The characteristics that the doctors and other staff identified as being important in such a system were non-surprising: intuitive interactions, a clean interface and flexibility were all mentioned. Designing for domain experts also raises a new point: the system will have to include a means for data input, which is a part of the UI that I hadn’t given much thought before.

• Currently Listening to: The Strokes — What Ever Happened?

After an interesting meeting today, we’ve each chosen a website to extract data from, to be fed into construct as RDF. The idea of standardising on Python for all of the newly created sensors was brought up, which is good as I’ve already started working on my Python scraper.

Hidden Data

I didn’t mention this in the meeting, but some very useful data, like currency conversion rates, are generally not shown on public-facing websites. To get at them requires a form submission, and then scraping the resulting HTML page. Things I learned during my fourth year project may be able to help here, since one of the sites I tested on was this currency conversion page.

Access to a feed of realtime data costs $540 a year. With my project, for the cost of a HTTP GET request, you could have up to the minute data on any currency available in their system. This was made possible by a very useful Perl module called HTML::Form, which allowed me to simulate form submits, and thus retrieve the HTTP response page. Something similar is bound to exist for Python.

Working with Trees

There are two main approaches to screen-scraping: using heavy, regular expression-laden parsing for certain patterns of text in a string, or constructing a treelike representation of a page in memory, and then traversing this tree looking for certain elements. My favoured method is the latter, since it is generally more robust to small cosmetic changes to the underlying HTML page. Scraper rewrites are still required for when a page is reorganised, but this happens less frequently than a site having a few colours changed around.

Beautiful Soup is a very useful package for Python, which will robustly convert even an invalid HTML page into a tree, and then provides you the methods required to traverse the tree. This way, scrapers can be bashed out pretty quickly. Here’s some code to set it up; after this’ll come the page-specific code that extracts the relevant table rows or whatever is required.

import urllib, sys, re, BeautifulSoup

def get_page(url):
    """Fetches an arbitrary page from the web and prints it."""
    try:
        location = urllib.urlopen(url)
    except IOError, (errno, strerror):
        sys.exit("I/O error(%s): %s" % (errno, strerror))
    content = location.read()

    # Clear out all troublesome whitespace
    content = content.replace("\n", "")
    content = content.replace("\r", "")
    content = content.replace("\t", "")
    content = content.replace("> ", ">")
    content = content.replace("  ", " ")

    location.close()
    return content

def generate_tree(page):
    """Converts a string of HTML into a document tree."""
    return BeautifulSoup.BeautifulSoup(page)

Once you have this set up, fetching a certain element on a page becomes as easy as writing:

print generate_tree(get_page('http://www.imdb.com/')).first('table')

Polling Period

We discussed how often the sensors/scrapers should fetch their target webpage to re-parse it. Polling a page too often is likely to get your IP address blocked. Personally I don’t think this is as big a problem as was made out. Most RSS readers are designed to poll a feed once every 30 minutes to an hour. This is a reasonable period. Bar a few examples (stock quotes specifically), very few sites that we’re monitoring will be updating more frequently than that. In fact, the period could likely be increased. It would be relatively simple to set up a cron job to run each of the sensors in order every 30 minutes.

This approach could then be extended. RSS readers are/should be designed to honour various HTTP headers so that they don’t continually re-fetch the same feed over and over again if it’s not changing. All HTML files are sent with those same headers, so we could have conditions set up that the sensors will first do a HEAD request, and if we get a 304 response or if the Last Modified headers are within the last update cycle, we defer the update until the next cycle.

Ideally, the polling would be adaptive, so we have a single script that takes as input the derived update frequency of each page, and writes a new cron file with modified periodicity for each site. Thus, pages like the Dublin Bus timetables, which I’m working on, will be re-parsed very infrequently, since the site is rarely updated. Conversely, sites that serve constantly-updated information, like stock quotes and currency conversion rates, will be fetched much more often (but never more than a lower bound, like every 10 minutes).

I’ve begun learning some Python, primarily because Mark found an open source 3D graphics package called Blender, which uses packages written in Python.

So far, it looks like it’s similar in many ways to Perl, which is good because I already have plenty of experience with Perl, having used it for my final year project. Also, Lorcan is talking about doing some screen-scraping on major websites to glean data like movie showtimes and current stock prices, to be fed into Construct as contextual data.

I’ve done some screen-scraping in Perl before, but I’m guessing most of the others won’t want to code their screen-scrapers in Perl too. This will lead to serious code maintainability problems, which will invariably happen since every time the source website is updated you may have to recode some or all of your corresponding screen-scraper. Such is the life we’ve chosen. It would be best if we didn’t have to have designated caretakers for each module, so standardising on one language for them all would be nice. And I know which way the tide is turning (Joe characterised Perl with “I don’t like any language where my cat can walk across the keyboard and it will still compile” — touché).

Update: I’ve done some work on a scraper in Python.

• Currently Listening to: Ampop - My Delusions

After my initial foray into predicting the future was met with puzzlement, I’ve been thinking back over the idea of, as Aaron put it, “marrying the Scientific Visualisation with the Information Visualisation”. This seemed like the logical way to go, but right now it doesn’t look like what’s actually required or even desired for this project. Nonetheless, I want to write down the reasons I originally started thinking along this track.

Spatial Representation

First of all, because an autonomic system is made up of a large and fluctuating number of sensors and actuators, it made sense to have some form of spatial representation of where the sensors are located. This allows such actions as the person watching the visualisation saying “show me activity for the sensors at the rear of the car”, or for those clustered in the engine, for example. This would surely be a useful UI for interacting with the simulation.

Sensor Grouping

Beyond these ‘logical groupings’, they could also simply drag a box around the sensors they were interested in, and use the usual Shift-click/Ctrl-click interaction to add or remove sensors from their selection, and then generate the visualisation from this selection. Splitting the sensors driving the visualisation into groups like this would simplify the task of focusing on certain parts of the simulation, or moving parts of it onto other display devices (particularly low-power devices, with not enough processing power to generate the entire visualisation).

Using a 3D Camera

When sensors fail, as they are wont to do, the camera in the 3D environment can be positioned to show the location of the failure. This would allow the user to select nearby sensors and get realtime data from just those sensors surrounding the problematic one.

At this early stage in my PhD, it would be instructive to look ahead and take a wild, naïve guess as to what kind of deliverable simulation I may end up producing at the end. If only to look back and laugh later on.

First of all; the challenge, as I understand it at this time:

To model an autonomic system, specifically one inside an automotive machine, most likely a car. A modern car will have a wide array of sensors and actuators, and the system designer needs to be able to see how they are performing, in real time.

At the moment I’m envisioning a car, modelled in 3D, driving out onto a classic Tufte-ian grid.

A car that I’ll never be able to model.

The best guess at the moment on what kind of 3D I’m going to use would be some modification of the “Source” engine, which powered Half Life 2. The SDK comes with the game and I’ve played around with it. It’s very powerful.

Once the car comes to a stop, the outer paneling flies off, exposing a simplified version of the car’s innards. Thus begins the simulation, with (hopefully live) data being fed into the system and the display showing various activities on the screen.

Statistics like network activity and CPU usage will be on-screen at all times, in the form of pie-graphs and “sparklines” to show trends over time. Atomic events such as sensors being activated and sensors failing will be shown as alerts, possibly through a picture-in-picture system that shows a zoomed-in version of the full model at the point where the incident occurred. Clicking on this PiP box will then focus the main view on this area, through a camera movement. This device was used in the household simulation game, “The Sims”, to announce events like burglaries and housefires.

So, that’s what I’ve got so far. Of course, I’m leaving out all the bits about multiple displays and pulling elements from the main screen down onto a PDA or something crazy. It’s early days yet though, so this could still go in any direction.

While looking into the possibilities of the Source SDK, specifically the FacePoser program, I had an idea that may or may not be useful. The SDK contains an assortment of tools for creating realistic human characters; characters that look, move and emote like real people. This goes as far as a very impressive facial expression modeller.

The characters that are created for games like Half Life 2 are very convincing. So, my idea was to create a human character (dressed in a lab coat and carrying a clipboard), who would stand beside the model of whatever autonomic system I was simulating. As the simulation wears on, the character will speak, and emote, various feedback cues to the user, like flailing his arms around when sensors fail. What more intuitive form of feedback than one which everyone is most used to having to interpret?

The trick, of course, is to not let this become a more technologically advanced version of Clippy. The character, who could be thought of as an avatar for the autonomic system’s general health, would generally stay in the background. Much of the feedback he provides could even be picked up subconciously, as he walks around the car performing ‘checks’; all the while providing subtle auditory hints and contorting his face to show his level of contentment.

Of course, there are some faces that no amount of technology could ever emulate.