In celebration of taste

I’m reading a lovely little book titled Bittersweet Country, edited by Ozarkian author Ellen Gray Massey. It contains the best articles from a periodical named Bittersweet, published by Massey’s English class from the Lebanon, Missouri high school. The magazine focuses on the Ozarks, the culture and the way of life of the early Ozark settlers.

The first section of the book focused on kitchens: what appliances existed and how they were used, how food was prepared, giving recipes, and even providing diagrams of typical kitchen organization. Most had a big, rough table, usually made by hand, with benches for seats. On this, food would be placed–for eating in the next meal or to hold for the next day. It would be covered with a pretty cloth to keep the bugs off.

In those days, the settlers were frugal and nothing was every thrown away; even ash served a purpose because ash that is wet and allowed to sit and rot forms lye as a by-product. Lye was essential for both cooking and cleaning, and many homes had an ash hopper where ashes from the wood stove and fireplace would be thrown. When it rained, water would trickle through it, resulting in the lye. The cook would then combine this with water and dried corn and boil it for a time to create hominy–a fluffy, and tasty, corn dish.

(I found a recipe for homemade hominy at WikiBooks. If you’re not familiar with WikiBooks, it’s a Wikipedia-related site for …open-content textbooks anyone can edit. )

Reading about kitchens and cooking in Bittersweet reminded me to recommend an enjoyable weblog: 101 Cookbooks. The author, Heidi Swanson, features recipes from her collection of cookbooks–providing interesting background material as well as entré into a world of natural and vegetarian and vegan cooking. It’s a beautiful site, too: perfect for her topic and interests. (It’s not a site that reads well as an RSS feed, which is probably why she doesn’t provide full feeds.)

Ms. Swanson also features some rather fascinating and unusual recipes, such as today’s Lemon Verbena Drop, giving a little cocktail background as apéritif:

In the past I’ve had (a few) friends who tended to treat cocktails more like fashion accessories than beverages. They always opted for the drink that best matched their handbag or shade of lipstick. Bless them though, because they always looked cute. Or cute for a while. There is a place up the street that serves saketinis in a pretty range of sunset colors – reds, pinks, oranges. They serve them in ultra-wide, shallow martini glasses. Turn one way, and the drink in your glass slides right out the other side. It’s a given, anytime we go there someone will end up either wearing their own drink, or wearing someone else’s.

101 Cookbooks led me indirectly to the cupcake weblog, a weblog about all things cupcakes. But let’s not stop there. If you’re like me and find wedding cakes to be a true art form, then here’s a tip: use the Flickr tag wedding cake to see hundreds of photos of wedding cakes, traditional and anything but. My favorite cake so far is this rather unusual Seussian affair.


Post Serenity

I did go see Serenity tonight. The movie theater is about 1/2 mile from us, and no one was out. We had the stadium seating theater; shared with approximately 20 other people. The seats were excellent and so was the sound, but the film developed a flaw in it for the last ten minutes. Didn’t impact on the overall movie, but was unfortunate.

I won’t talk about the movie–anything one can say is a spoiler. I think it was an excellent movie, but somewhat unexpected. It was a true Firefly show, though — no disappointments for fans. I didn’t see any hull number, but I’ll take a swing and guess at the hull number and ship soon to enter Serenity trivia as noted by Commander Rogers: the NC 1701, USS Enterprise.

Diversity Technology

It starts with one

Recovered from the Wayback Machine.

David Weinberger wrote about turning down attendance at an event because the guest list ended up being all men.

When I told the organizers why I wasn’t coming, they replied that they had invited three women who turned out to be unavailable. After our conversation they have invited some more women. But, only a few because, they told me, they’re trying to keep the total number of participants down so it will be more intimate – more better bonding! I told them they could use my spot to invite another woman. Have I mentioned that this is how the old boy network is formed?

Well done David. And yes, I think it is important that you discuss it online. It lets other folks know that there are consequences for not ‘trying hard enough’ to reach diversity.

Trying to diversify these gatherings doesn’t mean a lowering of quality. It means keeping your mind open as to what makes an interesting person; being aware that each of us contributes in our own unique, and possibly, different way. It also means questioning the assumptions, and if the answers aren’t good enough, making what could be some tough decisions.

So I’ll say again: well done, David.

Connecting RDF

Put up or shut up

Recovered from the Wayback Machine.

Recently, irritated by what seems to be an endless round of pushback against RDF, I made a put up or shut up statement in a post. Well, whether my irritation is justified or not, telling people that they have to put code down in order to have an opinion was not only wrong, it’s bad technology.

In these situations, a more appropriate response is to listen to the critics, find those areas of common concern among them and address these concerns. One way to do so is change the technology; another is to provide additional documentation and clarification of either the technology or the specifications on which the technology is based. At this point, some critics may still remain adverse to the technology and have legitimate reasons for being so. We can, then, either take on another round of fix and/or document; or we can decide that the effort to meet every concern is just not an effective use of our time. This is what makes good technology.

This week, James Robertson responded to a Robert Scoble ‘deal’, where the latter said he would switch weblogging tools if the tool provided a certain kind of support for OPML. Leaving aside whether Scoble will actually change tools based on this response, Robertson had some legitimate concerns about OPML and expressed them:

Ye gods, it’s time someone came out and said something. OPML is a really, really crappy format. Really crappy. I had massive headaches implementing OPML support for import/export in BottomFeeder. Why? Because there’s no real specification […] I had to add tons of hacks to the OPML support in order to support the export formats of various tools. The problem? Everyone implemented it a little differently, because the spec is incredibly unspecific – about just about everything.

I’ve looked at the OPML specification multiple times, and frankly, I’ve never had the least interest in trying to implement anything on it–not because I can’t, but because I see no purpose in it. The specification makes no sense; it reads like a mystery novel more than a technical document. Why would anyone possibly want to implement anything so vague? Coding just to code has never seemed useful to me; coding just because it would make Big Dog happy seems even less useful.

Regardless, OPML has its fans and more power to them. But when they start talking about implementation, others are going to bring up issues with OPML–if for no other reason than they’re like me, and think that there really is a true OPML specification somewhere, and we just haven’t been able to find it in Google yet.

Scoble’s response to Robertson was, frankly, asinine; especially for someone who purports to be writing a technical weblog, and prides himself on the ‘geek’ circles he inhabits.

James, here’s the deal. I really don’t care about specs. I’m a user here. When users say they want something the correct answer isn’t to call what they are asking for “crappy” but it is to either say “here’s what you’re asking for” or it’s to say “here’s what you’re asking for and I made it even better.” Or, I guess an OK response would be “I can’t do that, sorry.”

But if you say the format is crappy that makes me wonder if you have something better up your sleeve. So, I’m gonna call you on it. Do you?

This is classic put up or shut up. Robertson wasn’t telling Scoble what to do; he was using the post as an opportunity to make a statement of interest to him, about the underlying specification. If it had been played right, the OPML folks could have had some valuable insight into concerns about the specification, as well as perceived weaknesses. But no, it became something else–a satellite discussion that revolved around a few big dogs and aside from ensuring they have their weekly quota of links, hasn’t led to any positive advancement in technology.

Of course, I’m linking to the Big Dogs myself at this time, but it’s not because of OPML, as much as it is about “put up or shut up” as a way of shutting down discussions on technology. I did so with the one post I wrote and that was wrong on my part. Wrong, wrong, wrong. No matter how I package it up, I screwed the pooch with my response.

But to return to this whole OPML discussion, it seemed to me that what is happening is that Dave Winer really doesn’t want a clear specification. If he has one, he loses some leverage. Right now, to do anything with OPML you have to go through Winer. You can implement what you think is the spec, but there’s no guarantee that it will be ‘valid’ unless you get a Winer stamp of approval. And even then, there’s no guarantee that you won’t lose that stamp of approval six months to a year down the line.

Any technology that is dependent on a specific person is bad technology. This is true whether you’re looking to use the technology or implement it.

In the meantime, several people have written about the OPML specification and this ‘put up or shut up’ doorstop that make good reading:


The reason that developer’s just can’t get their OPML to work with Dave’s application is because the specification sucks. There is simply no way for anyone to tell if the OPML file generated by their application is really compliant with what Dave’s editor implements, or only just happens to never tickle a bug or an ambinguity which wasn’t specified.

Blogging Roller has an excellent take:

I think Scoble and Winer are right, it’s about the users. When you create a data format or netwok protocol specification, your users are the developers who have to implement the spec. In the case of blog tech specs, the users think the specs suck.

Roger Benningfield had two posts about the discussion: one on implementing OPML in JournURL and one responding to Dave Winer’s OPML guideline. Scoble, if you’re linking those who have met your demands, you need to link Roger’s post and weblogging tool, too.

Elliot Back takes a closer look at OPML from an XML implementation point of view.

In response to ‘put up or shut up’, James Kew wrote:

Like James, I’m not convinced that OPML is the magic bullet that Robert wants it to be. But I do firmly believe that shouting down critics with “do better or shut up!” is unhelpful, unproductive, and just plain rude: macho posturing at its worst.


Speaking of which, why are people so insistent on having the attitude that you can’t criticize something unless you can do better? Knowing that something won’t work is more valuable than coming up with the idea that doesn’t work – they’ve already done more than the person that came up with the original idea just by showing why it won’t work. Besides which, there’s a different set of skills required to do something than there is to evaluate it. How many wine drinkers know how to make a better wine than the one their drinking? How many have actually done it? Would you suggest they just drink whatever wine is put in front of them because they can’t do better themselves?

A succinct Fanklinmint:

Scoble, that’s not very nice.

Rogers Cadenhead seems particular y put off by my and Jason Levine’s criticism in Scoble’s comments. (Levine not, I am assuming, being the same Jason who specifically told me to shut up in said comments.)

Let’s just accept as a given that you’re right (especially Shelley Powers and Jason Levine). OPML is utter crap. We could do so much better.

You could do so much better.

Create a better, better-specified format for the tasks supported by OPML. If the format’s as bad as you say, you shouldn’t have any trouble at all topping it.

But if you don’t have the time or the need to do that, then please have the decency to turn your critical gaze away from OPML. This format needs an RSS-style flamewar like the Gulf Coast needs tropical storms.

Jason responded with:

You should know better than to say something as meaningless as “if you can’t create something better, then don’t comment on the issue.” It’s a straw-man argument, created to be a distraction; of course reviewers don’t have to be implementors, they just have to know how to review — critically, with reason and logic, and with an understanding of the space in which their reviews exist. In this case, both Shelley and myself have been at this long enough to know how dangerous having crappy specs is — if any interest is generated in them, apps pop up that end up unable to generate compatible files, unable to interchange data, and leading to an enormous mess for the very users who helped popularize the features that the spec advertised. It’s no good for anyone at all. But the fact that I don’t have the time or energy to create a new spec is all you see, and the point you attack, leaving untouched the fact that OPML is still a terrible spec; if people want it to actually work, then what’s the harm in Dave (or anyone!) actually putting it together into a spec that’s usable by implementors?

I was going to respond in some depth until I read Jason’s comments; then I basically just wrote “ditto”.

(Speaking of RSS: I’ve played around with implementing applications that produce and consume RSS 2.0, RSS 1.0, and Atom. Of course, the RSS 1.0 is pretty easy for me as I have an API that can speak the model so I ‘cheat’ and use it rather than parse out the markup. But I found the Atom specification harder to implement out of the box than RSS 2.0. Why is that? Because the Atom specification is so precise that I can’t just slop anything in. RSS 2.0 is much easier to hack, but I’m left wondering how many tools support multiple enclosures and how many tools do not. I avoided the dilemma by going with RSS 1.1. )

I don’t want to channel Mark Pilgrim and spend a lot of my time pointing out the obvious–other than, if you haven’t been out to Mark Pilgrim’s site, Dive Into Mark, he’s got an interesting Red Cross donation page. He also has a t-shirt for sale I wouldn’t mind adding to my collection; to wear during those times when I waste my time commenting in Scoble’s ‘mudpit’.

(Mudpit. Now that’s a way to set the tone of discussions. Taking a page from Pilgrim’s biblical approach, you reap what you sow, Scoble. )

And since I have no interest in ‘putting up’ code for OPML (how many monkeys typing on a TiBook randomly can…), I guess I’ll have to shut up–Burningbird style.

picture showing kitten running in terror with words to the effect that God kills kittens when you use OPML