Monday, May 14, 2007

Twitter's signup page sucks.

I tried to sign up for Twitter five separate times before I succeeded. I was ready to give up after the second, but then I decided I could write about it instead.

Twice, the UI was messed up -- either a stylesheet didn't load completely, or something was positioned absolutely that should have been positioned relatively. The other three times, I got errors saying I had invalid characters in my 'screen name', even though none of the fields were called 'screen name'. I had to figure out which field it was talking about by trial and error! And it didn't tell me which characters were invalid either.

And - MOST annoying - it reset the other fields I'd entered to their defaults when it had an error, rather than remembering which timezone and screen name and so on I'd chosen! Way to remind me of the command line, guys!

Wednesday, March 14, 2007

Transcendental, not Transcendent

Today is Pi Day. 3/14 -- and it is celebrated at 1:59:24 this afternoon.

I am marking the occasion by listening to Hard'n'Phirm's song Pi on repeat.


When ink and pen in hands of men inscribe your form (bipedal P) / they draw an altar on which God has slaughtered all stability / no eyes could soak in all the places you anoint and yet to see you all at once we only need the point / flirting with infinity our geometric progeny that fit inside you oh so tight with triangles that feel so right

(many digits of pi, recited)

Your ever-constant homily says flaw is discipline / the patron saint of imperfection frees us from our sin / and if our transcendental lift shall find a final floor / then Man will know the death of God where wonder was before

Monday, March 12, 2007

Middleware and Complexity

I still have an interest in lessconfig as an idea. Sensible defaults, user-centered but system-aware design, all those things are still goals.

But now I work for a telecoms middleware company. Almost my entire working life is now taken up with...configuration. The whole reason for Sigma Systems' product's existence is configuration -- we accept orders as input, and issue network configuration commands as output. And since this is an Enterprisey kind of environment -- you don't become a successful enough telecom to warrant OSS without very very high uptime and you don't get very very high uptime without significant quantities of process -- there's lots of configuration in our application too. Configuration, metaconfiguration, metametaconfiguration -- it's easy to lose sight of what the system's actually going to be used for in the end.

And I'm not sure I can see how any of this could be simplified, in practice, without either ending up with a dangerous monoculture effect in the telecoms industry or a decrease in available services.

Some problems are just hard, I guess.

Thursday, November 30, 2006

Hiding Faults

It's a bit of a truism among software development professionals that users don't know what's hard and what's easy. Marketing people shrug and smile halfheartedly when you tell them that you've cut processor usage by 55% by designing and implementing a reentrant, optimized request-parsing module, and their eyes pop out of their heads with glee when "you can make it BLUE TOO?!?!???". Most complex systems have at least some opacity to the uninitiated; my Mechanic brother has a much more detailed idea of what A Good Car is than I do, and there aspects of structural engineering I know precisely nothing about. But at least in those two cases, and I'd argue most others as well, there's at least some way for nonexperts to judge the underlying quality of the system.

In software, that's a lot harder to do.

Most programs, especially in the Enterprise business, are heavily customized and customizable; there's no easy comparison to peers off the shelf, and nobody wants to go through two separate installation/configuration exercises just to compare performance. As a consequence, enterprise software just doesn't have the same quality pressures on it as a lot of other products do, including commercial software; after a week or so of using it, I can tell you that I like Firefox better than Internet Explorer 7 because it's faster, more reliable, and having complex pages open in one tab doesn't slow down other tabs. But how can anyone tell whether the Enterprise System they've just bought and spent a year customizing, at great expense, is really Good? We can measure Good Enough -- whether it meets business goals -- but we can't tell what the variance in quality for competitive products would have been. Is our implementation really Good, or is it Good Enough for us because our business is built to tolerate Bad? What economies are hidden from us, what effort are we wasting, because we don't know how Good our software can be?

All questions I don't have answers to. But I do know this: The difficulty we have answering those questions makes it possible for a lot of bad code, and bad coders, to survive in the marketplace.

Wednesday, September 20, 2006

What we Have and what we Are

Tim Bray writes about his discomfort at people reusing his writing and pictures, as opposed to his wholehearted acceptance of people using his code.

Personally I don't see a conflict between those two stances. It's a question of intent: code is created to be used; blogposts, and photographs, are created to be enjoyed. The "my work" vs. "me" distinction. I think it's totally reasonable to disallow commercial use of writing and music and all other performance art, because it's totally reasonable not to want other people to piggyback on your reputation.

Friday, July 21, 2006

Scott Adams' Cynicism Koan

Today's Dilbert is better than any I've seen in a long time.

Monday, July 17, 2006

Why is Unix not good enough for Enterprisenessosity?

Sounds snarky, I know. But I actually do want to ask the question.

It seems to me that one of the things that defines Enterprise code (besides abysmal performance, ridiculous user and administrator interfaces, feature bloat, and resistance to change, haha I can't not say it, my fingers wouldn't let me) is that Not Invented Here Syndrome is very strong. WS-Security exists because WS-People don't think HTTPS is secure enough, even though it's good enough for WS-Designers to do their internet banking with. WS-Transfer exists because WS-Designers forgot the WS-Standards are realized as SOAP over HTTP. Lots of products use databases when as Mr Bray so rightly puts it ext3 or ReiserFS or UFS or ZFS would do just fine.

So what is it about Unix that the Enterprise doesn't like? It seems like most are happy with its ability to act as infrastructure, in the sense that it can run a JVM and/or a .Net CLR, but don't want to use any of the higher-level services like secure, distributed filesystems it provides. Is it a familiarity thing? Are people coming out of Enterprise Architecture School -- whatever that means -- just not familiar with the capabilities of the world's best server OS? Are we just paying lip service to reusability, writing our 'general' components, all the while not acknowledging that the most general component of all has already built this stuff, and it's been in production for twenty years?

Sunday, July 16, 2006

Sixty-five trillion reasons...

...not to hold debt in US T-Bills denominated in US dollars. (Thanks for the correction, Atlas.)

Kotlikoff holds forth on the structure of the US economy.

Tuesday, July 04, 2006

Independence Day

230 years ago today, a nation founded itself. Whatever one thinks of its current (or past) leadership, its mores, its methods and its concerns, it has done a great deal for the world over that time.

Happy Independence Day, United States of America.

What We Really Know

What you truly own is what you can carry in one hand, running flat out, firing an automatic rifle over your shoulder.  Facetiousness aside, there's a point there.  Ownership, as a concept, is pretty contentious when/if the rubber meets the road. 

So that's what you own; what about what you truly know?  What you can remember, running flat out, firing an automatic rifle over your shoulder?  In that case, I know the feeling of fear, my name, my desire to live, my face in the mirror, and not a lot else besides a whole lot of song lyrics (what, you mean they don't pop into your head all the damn time too?).  But I know a lot of other things right now, sitting on a city bus typing this out on my way to the office.  I know I look like a huge nerd with his laptop out on a city bus, for one thing.  And I know I dislike commuting.

I think it's mostly about context.  Psychology's known about the effects of context on memory for a long time, but it's not something that we think about in everyday life.  One of the sideline expository devices in Charlie Stross's Accelerando is a pair of glasses the main character wears, glasses that feed him context about everything he pays attention to.  It's like an implant without the actual hardware; when he loses them, he loses so much of his memory that a lot of his identity goes away too. (sideline question:  how is what you know different from who you are?)  We're not to that point yet -- at least I'm not -- but we're getting there; I often find myself answering questions with the help of the internet when the I'm near a device that can access it, I don't even try to remember meetings anymore, and it's been a long time since I sent a letter through the real mail.  It wasn't until I spent a few days without network access getting my laptop up and running on Solaris (I've switched back to exclusively running Windows now, with Solaris and so on in VMWare, so that's no longer an issue) that I realized the extent to which I rely on my network connection to feel at home on my computer. Even if the job I was trying to do didn't require any network interfaces other than loopback (there's no place like!), not having access to the web made everything harder.

Ultimately I 'm not sure the distinction between "what you know" and "what you really know" is important.  After all, the context required for any given set of memories is usually present when you need them (what reason would you have for trying to recall something out-of-context?), and the mind is a flexible thing.

Thursday, June 22, 2006

Frameworks versus Libraries

Benji Smith, who is famous for why he hates frameworks, has very good points.

(Go read that.  it's important, and it'll make you a better person.)

His points about the problems with abstraction in frameworks are good, and well taken.  (at least, they're well taken by me.  It seems like the Java EE folks and the WS-* folks have a lot to learn from him.)  But a couple of posts down in that thread he comes back with some more ideas, one of which is one I really wish I'd thought of first:  the difference betwen a framework and a collection of libraries.  The difference is this:  your code encloses its libraries, but is enclosed by its framework.  This has a couple of consequences that are good for framework vendors, but bad for developers:

1. frameworks are mutually exclusive.  If you're using Java, you're by definition not using .Net; if you're using Struts, you're not using JSF; if you're using Google Web Toolkit, you're not using Atlas; if you're using GTK, you're not using QT.

2. frameworks impose lockin.  In order to stop using a framework, you have to get your code out of it, a process that may or may not be possible and certainly won't be easy.  In order to stop using a library, you have to take the library out of your code.  Depending on how heavily you're using it, that might be hard too; but in its hardest case, you still don't have to "get your code out of" a library. 

The difference is crucial.  The barriers to exit are much, much lower with libraries than with frameworks.  Developers of libraries have to be a lot more humble than developers of frameworks do; we talk about "J2EE applications", but not about "cURL applications" or "pango applications".  Given the choice between a framework and a library with equivalent functionality and ease of use, I'll take the library every time.

Of course, libraries and frameworks still have a lot of similarities.  They're both bits of helper code that purport to do something complex or common well, so you don't have to hand code boring or tricky things.  They're programs like everything else, with a tradeoff between features and complexity.  They have their bugs, and their idiocies.  And there are certainly times when it makes sense to use a framework; Ruby on Rails or PHP or JSP or ASP is better than coding servlets or CGI programs, for the majority of the things I want to expose on the web.  But when you evaluate some helper code, be aware of the difference between a framework and a library.  And when you're *writing* helper code, for gods' sake please write a library.  Frameworks are much harder to get right.

Friday, June 02, 2006

The Wisdom of Crowds

Tim Bray on Tantek Celik on Scott Reynen on the topic of innovation, using a turn of phrase Bill Joy invented:  "Innovation happens elsewhere".  I take Tantek's (and Bill's) point:  there's more brainpower on the internet that there is in your walled garden, sure.  And the 'net will do as the 'net wills, that's for sure.  If you're trying to do something that the 'net can do, you're better off letting the 'net do it.  (Things the 'net can do:  make a half-decent operating system for operating system nerds, generate impenetrably abstruse discusison on every topic known to humankind, expose failures of thought quickly, etc etc.)

But there are things the 'net can't do.  And, contrary to the opinions of the 'net, not all of those things are uninteresting by virtue of the fact that the 'net can't do them.  One of them is good usability, for example.  The 'net's greatest downfall is its greatest virtue:  anyone can participate.  Sure, bad decisions get questioned, but so do good ones.  The 'net builds consensus, and relies on the assumption that what "everybody knows" is what's right.  And for most things, it is.

But not for everything.

Anything that's counterintuitive, the 'net's going to get wrong most of the time.  Anything that's profoundly multidisciplinary, the 'net's going to get wrong most of the time (because the experts in the individual fields will drag the project their way, at the expense of the others).  I'm sure there are other examples.

I think we haven't got the balance right between hierarchical, corporate, power-concentrating decision making and the wisdom of crowds here at Sun.  We're still too focused on the hierarchy; we don't do enough out in the open where people who care can keep us in check.  But it's possible to go too far the other way, too, and get mired in endless debates about what the right thing to do is.  What we need, of course, is the Platonic benevolent-dictator philosopher-king; someone everyone trusts, who takes good advice and ignores bad advice, who listens when it's appropriate and rules by fiat when it's not.  (and while I'm making wishes, I'd like a pony.)

Wednesday, May 24, 2006

Will Stallman ever stop tilting at windmills?

yes, yes, I realize that RMS is much more interested in software being Free than he is it being Useful.  That's a valid ideology, and he pursues it relentlessly -- but it's fundamentally irrelevant to the industry as a whole.

Why?  Because people don't care whether the software they use is free.  People can't even be bothered to care about their own personal freedoms -- witness the Patriot Act and the general lack of uproar over the NSA's domestic spying!  Given the choice between software that works, but is proprietary and software that is Free, but hard to use (and therefore doesn't work), they'll choose the former every time.  Perhaps, if two products were identical in their use and one was Free and the other wasn't, they'd choose the Free one if they knew there was a difference.  But usefulness trumps license every single time for most people, and RMS' assumption that it doesn't hurts him, and his crusade, every time he opens his mouth in public.

Wednesday, May 10, 2006


You're writing a program.  It could be a library for your own personal use, or it could be a webapp for your friends, or it could be your paycheque for the month to do this kinda thing.  Stop for a second and think about how much effort it takes to go from a zipfile on the disk (or however you're delivering it) to using it normally, and how much effort it takes to use it for its intended purpose.

Is it effortless?'s not, is it?

That's a bad sign.

The reason it's a bad sign is that as soon as your program requires *any* effort to use, you reduce its reach.  Every step that can be messed up will be messed up by some group of people -- and most of them will throw up their hands and quit when they do mess it up.  The people who don't quit when the going gets tough are either forced by circumstance to use your program, or take some kind of perverse joy in the self-flagellation that's usually involved in installing and using non-effortless software.  Don't give up hope, though.  There are a few ways to Effortless from where you are.

Check your interfaces
Think HARD about your user interface.  (This means you too, library writers.)  What clutter can you remove so that there's less setup, less configuration, less data entry, fewer clicks?  How could you change names, or shift workflow, so that things that are Bad are harder to do?  How many knobs and frobs and bells and whistles are there that you could really remove, or at least give a default for and hide the customization and the choice from people who don't care?

Check your installation
You'll have to spend a disproportionate amount of time on the initial setup stuff, on making installation a breeze.  Your average user will spend a lot more time using your program than they will getting it working in the first place, but when they're installing it that's all they've seen of your baby and if you don't get that part right, they'll never see the rest.  You don't get a second chance to make a first impression.

Check your documentation
Nobody's going to read it, yeah, we all know.  That's not why you're checking it, though.  You're checking it because everything you felt the need to document, you thought was tricky enough that it needed explaining.  Is there something you could change about the interfaces to reduce the need for the documentation?  ...Since nobody's going to be reading it, after all.  Maybe you could put (pretty and unobtrusive, please!) tooltips on things so that people don't have to go looking for documentation. 

Check your ego
Some people say the best interface is no interface at all.  When something Just Happens and the user doesn't really know why, but they're happy it did -- that's a happy user, that's a user you're not getting in the way of, that's a masterfully Effortless program.  But all that means that the bulk of your work is going to go unnoticed by most of your users, most of the time.  And that's OK.  In fact, that's great.  You can do it -- but that means that you have to stay out of the user's way, even if what you're doing is Really Cool (tm) under the hood.

[Editor's Note:  This started out as a response to Mr Governor's article on smalltalk.  My point there was that while effortlessness is indeed bourne out of practice, the amount of practice necessary can be influenced by the program's design.  To extend the butcher analogy, even a master butcher needs more practice with a tricky, soft, easy-to-dull knife than a comfortable, hardened-steel one.]

Tuesday, April 25, 2006

Protective Colouration, Trademark violation, and NEC

Slashdot has an article today on how a group of people -- pirates, in some sense of the word -- have cloaked themselves in the coloration and name of the Japanese electronics corporation NEC and, essentially, established themselves as a rogue division.  It's like the relationship between the Monarch and Viceroy butterflies (note, even the names imply the relationship!).

Monarch caterpillars feed almost exclusively on milkweed, which is more than mildly toxic and correspondingly foul-smelling and -tasting to mammals and birds.  The toxin stays in the insect during its transition from caterpillar to butterfly, so Monarch butterflies taste *terrible*.  They adopt a protective colouration that's a bit counterintutive as a result -- they're orange and black, with somewhat stripy patterns.  Google's image search will give you a really good idea.

Viceroy butterflies are a different species altogether, with a much wider diet.  They eat some milkweed too, but not nearly as much as Monarchs do -- so they don't taste particularly bad, as insects go. However, their colouration is very similar to a Monarch's. They piggyback on the reputation that Monarchs establish, and are predated less as a consequence.

If you've read the Slashdot article, you know where I'm going here.

The term we use to describe what Viceroys do when companies do it is "trademark violation".  Of a particularly egregious sort, because it applies both up and down the supply chain.  It's piracy, but it's a twisted kind - misrepresenting your goods to consumers is one thing, but misrepresenting your business to your suppliers requires even more cojones.  I can't help but think that we'll see more of this, though, and that biological metaphors will take us further and further toward the realization of a true business ecosystems.  Here's a prediction for you: the other component required of the global market to create a true business ecosystem is autonomous corporations.  Give it 10 years.

Friday, April 21, 2006

Charlie Stross goes deep, hoping to catch his own Hail Mary

In his latest post, Charlie Stross (who is one of my favourite Science Fiction Writers) sounds off on his craft in a deeply technical way.  The second last paragraph in the post contains this gem of writerly jargon, fit for publication in almost any lit-crit journal:
It's not so much about metafiction as about metainformation for the fiction at the centre of the narrative process. [italics his.]

Tuesday, April 18, 2006

It's going to end up custom anyway

The Anti-WS-DeathStar* movement's been pretty active lately, at least in the corner of the blogosphere I read.  Although I really do agree with them -- I think time spent on WS-* would be better spent elsewhere -- it was only this morning that I think I finally nailed down why.  Being as deeply ensconced in an architecture-oriented environment as I am, I can certainly see why WS-* exists, and I think that there's nothing malicious about WS-Consortium's attempt to WS-Standardize the world.  The problem is that it's all founded on the assumption that all the WS-Work will lead to WS-Specifications that are complete enough that different implementations will be interoperable. 

And I think that's just not the case.

Every implementation of a specification has different characteristics.  Even when two implementations conform exactly, there are differences -- perhaps in memory usage, perhaps in run time, perhaps in the relative efficiency of two (or more) operations.  And that's assuming that the spec is unambiguous (or that the implementations interpreted ambiguity in the spec in exactly the same way), which they often aren't.  So ultimately, there has to be some change, or some custom code, to connect two implementations of a spec.

So why not make it as simple as possible to make those changes?  The more statements a spec has, the more places there could be error either in specification or in interpretation.  Conversely, the simpler a spec is, the easier it is to implement correctly.  I'd rather have many small specifications to implement than a single large one -- after all, they're all going to end up custom anyway.

Thursday, April 06, 2006

lessconfig is another word for friendliness

Jaime wants to know "why lessconfig?".

1) Because I'm not special.  (the defaults should work for me until I have a reason to change them.)

2) Because I don't want to need to know how my software works in order to use it.  (I already know you're smart, I downloaded your program; you don't need to show me how smart you are by showing me how hard it is to get the app working.)

3) Because configuration is neither user- nor developer-friendly.  (Everything I can touch is something I can break.)

The first reason is the sensible-defaults argument.  I think we're all in agreement about that.

The second reason is a little harder for developers (myself included!) to grok because we like it when our work is appreciated, and because showing off comes naturally.  "This was hard to write, it should be hard to understand" is the ha-ha-only-serious expression I'm fighting here; we need, as developers, to learn to take pride in Just Works even if it means that our effort is misunderestimated by nontechnical people.

The third reason is the kicker, though.  The Mac users out there already understand this, and have for a long time.  The more configuration your app has, the smarter your users have to be.  Being smart is hard, but that doesn't make it a virtue.  Being smart is a (sometimes necessary) evil.  Anything that

forces me to think -- as a developer or as a user -- when I could just

be getting on with my day is Bad.  The more things I have to pay attention to, the more mistakes I will make when I don't.  And "just do your job!" is a wonderfully pragmatic thing to say, but given the choice between a package/patch management system that lets me hit one button and trust my machine is updated and safe and one that requires me to care about, and spend time on, each individual patch and I know which one I'll choose.

Thursday, March 30, 2006

Less Config: notes towards a nonmanifesto

Coté replied to my comment.  The more I think about it, the more I think there's room here for a position statement -- if not a manifesto -- on the subject of configuration and configurability.


Configuration is what you have to do to get the thing you have to work the way you want.  Examples:  telling your newly installed Unix box what its hostname is and where its name servers are.  Setting HTTP proxies for your browser.  Entering account information into your mail client.  Adusting the seat and mirrors in your rental car.  Configuration takes a system from a state where it's less usable to a state where it's more usable.  (Sometimes, the difference is between unusable and usable period.)

A rant

Before we get any further, a rant:  I hate configuration.  Every time I have to distract myself from my actual goal for the day to twiddle a setting so things work, a little piece of me dies.  Every time I have to think about my tools rather than thinking about the problem I'm trying to use them to solve, I get peeved.  When I finally get everything working, there is a sense of triumph -- but it's bittersweet, since it came as a result of things Not Just Working.  I want things to Just Work.  I hate it when things get in my way, and I hate it even more when it's for no good reason.

The Problem

And that's the meat of my position:  There's at least 3 kinds of configuration.  (I'm open to suggestions on what the others are.)  There's the configuration that's necessary for identity and security -- there's no way Thunderbird or Gaim can know how to act on my behalf if I don't tell them who I am.  There's the configuration that results from there being more than one good way to do something -- situations where your user community is split about what the best way is.  And there's configuration that results from developers being unwilling to make decisions about what the best way is.

The first kind is a necessary evil.  Security and usability are almost always diametrically opposed, since after all the whole point of security, and its siamese twin authentication, is preventing people from doing things.  Don't get me wrong, though; it is an evil.  That's why people who know how to do it set up certs so they don't have to type their passwords in to start ssh sessions, and the rest of us security-ignorant masses set our mail clients and IM clients and browsers to remember our passwords.  I'm just checking my bank balance, get out of my way with this password crap!

The second kind is debatable.  Sometimes it's ok; most designed things should afford some sort of personalization, since human beings aren't all the same.  It doesn't affect the function of my computer, but the ability to make my taskbar and window borders silver instead of blue makes me happy.  However, sometimes it's not:
Windows and OSX let you move the taskbar/dock around, with the end result that on some people's computers, that basic piece of UI infrastructure is not where I expect it to be.  Which means that it might as well not be there at all.  And don't even get me started on the ridiculous state of affairs in GNOME and KDE.

The third kind is inexcusable.  Luckily, it's mostly avoidable -- in desktop software.  But for some reason, Enterprise Software has all sorts of bells and whistles and knobs and frobs and controls that you have to set just exactly right or nothing works, and the factory defaults are useful to nobody.  Sometimes it goes away as products mature, if the development staff gets -- and uses -- advice from the field about what the correct ways to set things up are.  Sometimes it doesn't, and the company makes its money in two phasees: first it sells you its unusably complex software, then it sells you person-years of consulting time from one of the twelve people on the planet who understand the software well enough to configure it properly.  In fact, I'd go so far as to say that's one of the defining (mis)features of Enterprise software, much to all our detriment.  For some reason, large customers feel better about their purchase when it's difficult to implement.

The Solution

It doesn't have to be that way.   Unix is finally escaping its high-configuration heritage with Linux distributions like Gentoo and Ubuntu that don't require 40 hours of grovelling around in config files and newsgroups to get sound and accelerated video working; Windows and OSX are now easy enough that most people can do their day-to-day jobs without ever having to care about the operating system they're running on.  Google and the rest of the Web 2.0 scene understand, almost at a subconscious level, that things that Just Work are better, even if they have a more limited feature set to start with.  Sun's learning this too; we're trying, with things like the Network Auto-Magic project in the approachability community of OpenSolaris and some upcoming services from my group (among many other things!).  But we're nowhere near there yet.  Luckily for us, neither is our competition -- but that just means we have a chance to get a real leg up.

Friday, March 24, 2006

What We Really Own

In his most recent blogpost, Raymond Chen thirdhands an expression I now fourthhand to you:
you don't really own anything you can't carry at a dead run while firing an AK-47 over your shoulder.
Ha ha, we think; how glib.  But what about data?  One thing you can carry at a dead run while firing an AK-47 over your shoulder is passwords, and the mobile phone in your pocket -- you know, the one with more compute power and local storage than the entire WORLD 35 years ago -- probably doesn't slow you down that much.  Not to mention the fact that, as long as the war you're in the middle of isn't global, you probably have some safe (virtual) place to store a bunch more bits.  Greg Papadopoulos, in a spiel I attended, made the analogy between data storage and money storage.  Nowadays, it's totally obvious that the safest place for your retirement nest egg is a bank and not your mattress.  But not only was that not always the case in the past, but it took people's perception a bit of time to catch up to the reality that yes, banks are safer.  Not always more convenient, but safer.  And the money's no less yours for you not having actual specie in your posession.

And the same thing goes for data, we just don't all know it yet.

Monday, March 20, 2006


Of course, the first entry of every blog should be the test entry that determines whether the blog is working as it should.  Heaven forfend this one be an exception.