Over the course of the year, in browser tabs, bookmarks, and del.icio.us, I’ve built up a huge list of things that I felt I should write about, at least at the time I saw them. Well, dammit, I’m not gonna let 2007 end without at least making a try. Here goes. Categorized, even.
XML · Jelliffe on the awfulness of XML Schemas.
CMSMCQ has a klog. Which is to say, C. Michael Sperberg-McQueen has a blog that he calls a “klog” for reasons described here. Michael and I wrote the XML 1.0 specification; he’s smart and writes well.
The eleven-act OOXML high opera trundles on.
Ruby and Rails · Ola Bini on JtestR; code in Java, test in Ruby. Sounds like a step forward.
Reg Braithwaite on why Ruby needs to be self-extending. Not the first time this point has been made.
Oh, and Ruby 1.9 is out.
I’ve written before about Rails and ETags and how they’re important and
Rails probably can’t Solve The Whole Problem, but could do better, and while I
haven’t gone deep (because I’m not actually running any Rails at the
moment) it
seems that Assaf Arkin’s
if_modified
probably does do better. If so, it’s important
Dave Thomas: Pipelines Using Fibers in Ruby 1.9. Oh my goodness gracious.
Programming · A nice commencement address by Bruce Eckel.
You’d think that regular expression processing would be a closed book after all these years. You’d be wrong.
_why, in This Hack Was Not Properly Planned, says “You could blame Stallman, but I just don’t think that gives entropy enough credit.” and a whole lot of other wise and surprising things too.
The Web · Ka-Ping Yee explains Why PHP should never be taught. Ouf. And then follows up with with Why PHP should never be taught, Part II.
I contributed to the Architecture of the World Wide Web document, and mostly I’m proud of that work. On the other hand, it may be true that, as Noah Mendelson suggests, its advice that data formats version themselves is, well, wrong. I spent some years of my life helping design The Atom Syndication Format, which emphatically does not do versioning, and I agree with that decision. Hmmm.
There’s this guy named Bob Aman whom I’ve only met once, but I’m a fan. He’s maniacally determined that Ruby shall have the world’s best URI-handling library, so he’s building it, and it’s called adressable, which is a good name. I was sitting on the floor talking to the RSpec guys at the last RubyConf and Bob plunked himself down and started wondering out loud about the best way to manage his many thousands of test cases. Someone who’ll write thousands of test-cases for URI wrangling is totally OK by me.
From gloriajw at devchix, RESTful Thoughts on a Web 2.0 Python Project. Mmm, very very tasty, one of the better why-REST statements ever.
Things Open · GlassFish, the Open-Source instantiation of the Sun Java Application Server, has gone from boring and corporate to kind of interesting. As witness its showing up in Debian, with the Maven dependency amputated. Gotta like that. As far as I know, Sun didn’t even know this was happening. Gotta like that.
There’s an internal Sun mailing list I’m on that’s concerned with government technology policy, and I keep seeing stories go by about governments liking Open Source and Open Data Formats, often confusing the two laughably, but still, it’s a real trend. One particularly tasty example is Arve Bersvendsen’s Norway mandates open formats.
Hardware · I exist at the airy, arm-waving level of the Web Tier. Descend twenty-three levels of indirection and you end up with silicon and the people who build it. There’s some serious churn happening in that world.
User Interfaces · The famous Tog explains in parts 1, 2, and 3, why the mouse is always faster than the keyboard. He’s wrong. Why is left as an exercise for the reader.
Contributions
· Technology (90 fragments)
· · Coding (98 more)
· · Open Source (82 more)
· · Ruby (93 more)
· · Web (396 more)
· · XML (136 more)
Comment feed for ongoing:
From: Bob Aman (Dec 31 2007, at 22:26)
In the interests of modesty, it's only 446 test cases. Still, that works out to roughly a 3:1 lines-of-tests to lines-of-code ratio, with 100% code coverage and lots of "heckling". Even so, despite all the testing stuff, I recently managed to find two significant bugs in one of the URI template methods that should have been obvious. (The method gave an incorrect return value for URI templates that contained no variables.) While I do claim that Addressable is the best URI wrangler available for Ruby, it is, by no means, the holy grail of anything.
[link]
From: daveadams (Dec 31 2007, at 23:28)
I've seen the Tog articles pointed to in various other places recently. Besides being reprints from 89 and 92, I can't tell when they were reprinted or what their intent is.
They're clearly written in a world where DOS is king, multitasking is a fantasy, and the WIMP UI (and even the use of personal computers in general) is still just an experiment. The argument doesn't exist in the same world we do.
The mouse is a critical part of personal computer interfaces today, and certainly no longer needs justification. Tog's argument seems to assume a perpetually naive user constantly learning new applications and a keyboard interface that maps keystrokes one-to-one with mouse-possible actions. Mainly all the comments seem to want there to be a one-size-fits-all answer to the question, but I'm guessing Tog didn't have to research the question of what the faster way to input text was.
The bits about perception versus reality are interesting. I think Tog misses a possible reason his subjects preferred using the keyboard for his stopwatch-timed replacement tasks: the mouse feels clumsy and inexact for selecting single characters. Even if it's faster, user frustration comes into play, not just perception of duration.
[link]
From: Justin Mason (Jan 01 2008, at 04:03)
hi Tim --
regarding that regexp link, there's a thread on PerlMonks well worth reading for follow-ups, including commentary from Jeffrey 'Mastering Regular Expressions' Friedl and perl's demerphq -- http://perlmonks.org/?node_id=597262 .
[link]
From: Kevin Scaldeferri (Jan 01 2008, at 20:40)
It seems to me that the flaw in Tog's argument is summarized in these sentences: "it takes just as long to decide upon a command key as it does to access the mouse. The difference is that the command-key decision is a high-level cognitive function of which there is no long-term memory generated."
Observing a skilled Emacs or vi user should put this assertion to rest. I no more think "what is the keystroke to delete this line?" than I would think "what is the keystroke to insert the letter 'a'?". To the point, there actually _is_ a long-term memory generated of these high-level cognitive functions. Reasonably sophisticated editing sequences flow from my fingers with essentially the same ease as typing words and sentences.
This example may not be universal. There may be applications which do not lend themselves to the same muscle memory that text editing does. But, there are certainly counter-examples to the general assertion that Tog makes, and this is clearly one of them.
[link]
From: Kendall Helmstetter Gelner (Jan 03 2008, at 20:36)
Let's say for the sake of argument that the study quoted by Tog is generally correct, and that even though using keyboard shortcuts feels faster, that mouse operation is actually faster.
Then I say - so what? Why should I do something over and over again that *is* faster if it *feels* slower? All you will do is give the impression to the user that it's harder and slower to do those operations than it might have been. And at the end of the day when you add up all those fragments of time you save you might have saved a whole ten seconds of time but feel drug out because you were "fighting" with the computer all day at a pace that to you, felt needlessly sluggish.
I just don't understand why the clock is the winner in the final choice of what UI system is actually best, when the "U" stands for User.
[link]
From: Hal (Jan 04 2008, at 10:38)
In a 2005 article in Intl J of Human-Computer Interaction (18(2), 133-144), Lane and colleagues report an objective study of this: "Six participants performed common commands using menu selection, icon toolbars, and keyboard shortcuts. The keyboard shortcuts were, as expected, the most efficient." The time differences were substantial (mouse often took twice as long). Moreover, it seems that Lane "stopped the clock" when the command was issued, so they didn't include in their estimate of the time-cost of mouse usage the time it takes to get your mouse back to where you are working. So, they probably substantially underestimated the advantage of shortcuts. The methods in the Lane study look reasonable to me. I am guessing that maybe Tog may have been focusing on very unrepresentative special cases or extremely low levels of familiarity with the shortcuts.
[link]
From: Niyaz PK (Jan 13 2008, at 20:55)
OMG, I just posted an article on the same theme (mouse vs keyboard).
http://www.diovo.com/?p=40
I think the problem is not whether the mouse is faster or whether it is the keyboard….
The issue that must be tackled is to how to make changes to both the devices to help us to be more productive.
[link]