- Three separate stylesheets. Three: one for IE, one for Navigator 5 and up, and one for the rest - plus the browser detection code is crude.
- Those image links are killing me. They're ugly, they're unnecessary, the rollovers don't even line up properly. Worse, they're backed up by some horrendous-looking JavaScript that could be rewritten in about five lines even without pulling in anything like jQuery.
- Searching the site for CSS turns up...no results. How do you write about website usability without once mentioning CSS!? Simple: throw in a bunch of process jargon. And you wonder why these government websites never finish their usability reviews...
- That aside, finding anything on this site is a bit of a chore. Either I go with Search and receive what I'll refer to as "context-free results", or I poke through their gangly tab-list-hyperlink structure. Wait, never mind - this makes everything so much clearer, right?
February 26, 2009
In Soviet Russia, Website Uses You!
I could go on for days about how government websites are hopelessly mired in a funk of ancient design practices and proprietary databases - or I could just point you here, where the U.S. Department of Health & Human Services has kindly made my point for me. Among the snafus:
And...
...we're back to relative sanity here at Quizzical Quincunx, now that the new CSS has been plugged in. With that out of the way, I might delve into the widget content itself (free time pending, as always!)
Note to Blogger: editing HTML directly through your editor is a terrible experience. So terrible, in fact, that I resorted to saving a local copy and vim-Firebug double-teaming it. Make it easier to quickly see the results of my changes and start supporting things like, you know, the tab key. Ugh.
Note to everyone else (yes, all three of you): comments? thoughts? gripes? minor sticking points? Feedback is always appreciated.
Note to Blogger: editing HTML directly through your editor is a terrible experience. So terrible, in fact, that I resorted to saving a local copy and vim-Firebug double-teaming it. Make it easier to quickly see the results of my changes and start supporting things like, you know, the tab key. Ugh.
Note to everyone else (yes, all three of you): comments? thoughts? gripes? minor sticking points? Feedback is always appreciated.
February 24, 2009
Hooray for Experimentation!
I'll be gutting and tweaking my Blogger theme over the next few days. In the meantime, if you should have the misfortune to happen upon my humble ramblings and irreversibly sear your eyes in the process, well - you have been warned.
February 23, 2009
On the Bright Side...
...my camera and associated USB cable are finally in the same location, which means I can start annotating my posts with random images like this:
Pay attention to what the Fuel Gauge says!
It was the best of luck, it was the worst of luck: today, en route to salsa lessons (nothing better than dancing away the Ottawa winter blues!), I ran out of gas halfway up a hill on King Edward - almost directly across from a gas station. I was operating under the (evidently false) assumption that the angry blinking indicator really meant that I had about 30 km of good driving left before my ride puttered out on me.
Which brings me to ask - we have indicators that display external temperature, speed, and cumulative distance. We have GPS systems and radar warning systems and anti-lock brakes. Why not tell me exactly how many liters of gas are sitting in my tank? After all, if we want to encourage those hypermiling gas-sipping compulsive optimizers, we should give them all the relevant data.
Which brings me to ask - we have indicators that display external temperature, speed, and cumulative distance. We have GPS systems and radar warning systems and anti-lock brakes. Why not tell me exactly how many liters of gas are sitting in my tank? After all, if we want to encourage those hypermiling gas-sipping compulsive optimizers, we should give them all the relevant data.
February 12, 2009
ICANN't
Here's a question: in the age of crowdsourcing, social networking, and distributed peer-to-peer filesharing, why do we have to pay a centralized body $2500 for the right to directly register a domain name? Small wonder that some disagree. Part of the issue is DNS itself - to translate that nice, human-readable URL into an IP address like 64.58.66.214, your computer has to ask a translator. To find the right translator, it asks a global directory.
If you have any background in security whatsoever, digital or otherwise, you're probably asking yourself - isn't that a really dumb idea? Sure. Let's ignore that, however, and envision instead the following scenario:
A person, who we'll call X, decides one night to nmap -sP 0.0.0.0/0 | grep "appears to be up". X then scrapes DNS and WHOIS info for each responding host using nslookup and whois into a massive database. Since X is a computer programmer par excellence with access to infinite upload bandwidth, they write their own server capable of answering all DNS queries worldwide.
Obviously, there are some minor wrinkles - like the intractability of crawling the IPv6 address space, or the impossibility of X being able to serve the immense global DNS lookup demand, or the infeasibility of expecting your average (read: clueless) computer user to change their DNS lookup settings. The above scheme is clearly suboptimal, though; the scraping part is embarrassingly parallel, and X could easily publish the data publicly - as a torrent, say, or as multiple smaller chunks.
Of course, this opens up a whole new can of worms: as a decentralized DNS provider, I could direct every lookup to my website or add entries for my competitors pointing to, er, less reputable content. Nevertheless, the idea is at least plausible; with a reliable trust model and just enough regulation of domain markets to shut out serial cybersquatters, it might even be workable.
If you have any background in security whatsoever, digital or otherwise, you're probably asking yourself - isn't that a really dumb idea? Sure. Let's ignore that, however, and envision instead the following scenario:
A person, who we'll call X, decides one night to nmap -sP 0.0.0.0/0 | grep "appears to be up". X then scrapes DNS and WHOIS info for each responding host using nslookup and whois into a massive database. Since X is a computer programmer par excellence with access to infinite upload bandwidth, they write their own server capable of answering all DNS queries worldwide.
Obviously, there are some minor wrinkles - like the intractability of crawling the IPv6 address space, or the impossibility of X being able to serve the immense global DNS lookup demand, or the infeasibility of expecting your average (read: clueless) computer user to change their DNS lookup settings. The above scheme is clearly suboptimal, though; the scraping part is embarrassingly parallel, and X could easily publish the data publicly - as a torrent, say, or as multiple smaller chunks.
Of course, this opens up a whole new can of worms: as a decentralized DNS provider, I could direct every lookup to my website or add entries for my competitors pointing to, er, less reputable content. Nevertheless, the idea is at least plausible; with a reliable trust model and just enough regulation of domain markets to shut out serial cybersquatters, it might even be workable.
February 11, 2009
NaNoWriMo 2008
Last term, I had the immense pleasure of participating in NaNoWriMo - that hallowed annual event wherein would-be writers consent to a month of grueling lexical vomitus in exchange for, well, nothing (unless you count pride and a sense of accomplishment as material.)
My tool of choice? Google Docs. Despite some slowdown on the sluggish university lab terminals - especially towards the end of the month - the experience was relatively smooth. The greatest benefit, however, was being able to easily share it with friends and have them track the development of the story. Try doing that with MS Word. Anyways, here it is.
My tool of choice? Google Docs. Despite some slowdown on the sluggish university lab terminals - especially towards the end of the month - the experience was relatively smooth. The greatest benefit, however, was being able to easily share it with friends and have them track the development of the story. Try doing that with MS Word. Anyways, here it is.
February 8, 2009
Dimwitted Reactionary Measures
Just read some snippets from Cory Doctorow's 2004 talk at Microsoft Research about the absolute mindboggling brain-deadness of DRM schemes - it's a shame they ignored the lesson. Anyways, the talk is well worth a read, even if it is outdated by online standards.
February 3, 2009
Monkeying Around
I finally got in touch with PKCC, Ottawa's local parkour community. One of their members is trying to get a weekly group conditioning session going, which is definitely A Good Thing; the harsh and prolonged Ottawa winter puts a damper on most regular outdoor activity, save perhaps for the occasional bit of vigorous snow-trudging.
On my goals list for this term: do 5 muscle-ups in a row. My training has been less than dedicated over the last couple of years, and this seems like a good benchmark to start with.
That said, I'm slightly disappointed to find that PKCC is nowhere near as active or cohesive as the group in Toronto. I'm hoping that the Ottawa scene will pick up again once this frigid pallor lifts. Until then, I've got some serious conditioning to do.
On my goals list for this term: do 5 muscle-ups in a row. My training has been less than dedicated over the last couple of years, and this seems like a good benchmark to start with.
That said, I'm slightly disappointed to find that PKCC is nowhere near as active or cohesive as the group in Toronto. I'm hoping that the Ottawa scene will pick up again once this frigid pallor lifts. Until then, I've got some serious conditioning to do.
February 2, 2009
Doesn't Help, Statistically
Bruce Schneier often finds occasion to rail against what he refers to as "security theater" - and what better example thereof than that most venerated of public institutions, the Department of Homeland Security? Happy reading.
(As an aside, I'm still waiting for the day when some enterprising terrorist decides to make explosive clothing, thus resulting in a general ban on clothes in airports. (Not really, of course - but it makes for a darkly comical thought experiment!))
(Update: I can't believe I'm linking to MSN Video, but...watch L'Aeroport.)
(As an aside, I'm still waiting for the day when some enterprising terrorist decides to make explosive clothing, thus resulting in a general ban on clothes in airports. (Not really, of course - but it makes for a darkly comical thought experiment!))
(Update: I can't believe I'm linking to MSN Video, but...watch L'Aeroport.)
February 1, 2009
So You Think You Can Sort
Selection sort. Insertion sort. Quicksort. Mergesort. All are standard fare in your average basic-level CS class; the first two are inefficient but conceptually simple, whereas the last two are decent general sorting algorithms. This is all good and well, but no one uses them for performance-critical applications:
As a simple example, suppose you have a billion integers to sort, but you know that each one is between 1 and 100. With that restriction alone, you can easily sort them in O(n) time. Other examples:
A while ago, I wrote a DHTML table sorter (for fun, naturally!) For reference, here's a standard quicksort implementation. Ignoring the horrendous colour scheme for a moment, why is the first one so much faster? Simple - it avoids swapping DOM elements. (There's a reason it's called permutation quicksort!)
Fine. So we can guarantee O(n) swaps in exchange for linear memory overhead. How do you limit comparisons? Remember that second point - notice patterns.
- Often, a sort is not required; what you really want in most large-scale cases are the top k results for some relatively small k.
- Real-world data has patterns that general algorithms like your standard library quicksort fail to exploit.
- Comparisons and swaps aren't always cheap.
As a simple example, suppose you have a billion integers to sort, but you know that each one is between 1 and 100. With that restriction alone, you can easily sort them in O(n) time. Other examples:
- The data are k-sorted (i.e. A[i] >= A[i-k].)
- The data aren't quite sorted, but they are unique; furthermore, abs(A[i] - A[i-1]) < k.
A while ago, I wrote a DHTML table sorter (for fun, naturally!) For reference, here's a standard quicksort implementation. Ignoring the horrendous colour scheme for a moment, why is the first one so much faster? Simple - it avoids swapping DOM elements. (There's a reason it's called permutation quicksort!)
Fine. So we can guarantee O(n) swaps in exchange for linear memory overhead. How do you limit comparisons? Remember that second point - notice patterns.
Subscribe to:
Posts (Atom)
