• Some potatoes (about 5) skinned, cubed
• Same volume as potatoes: pumpkin, cubed
• Milk, about half the volume of potatoes
• 1/8 medium onion, chopped
• 6 pieces bacon
• Sage (quite a bit)
• Brown sugar (more than you’d think)
• Parsley (quite a bit, it’s pretty but doesn’t taste like much)

Boil the potatoes + pumpkin + chopped onion in enough water to substantially cover.

Cook the bacon crispy, save the bacon grease.

Once potatoes + pumpkin + onion are mashable, drain about half the water out. Mash well.

Add: milk, sage, brown sugar, parsley, and bacon grease. Cook for a while, don’t burn the milk.

Crumble the bacon with some brown sugar for the top.

According to Google, they’re only counting “every person who searches for ‘flu’”, but what’s interesting is the that during the 2007-2008 flu seasons Google was able to accurately estimate current flu levels 1-2 weeks faster than the CDC. Today, the data is as follows:

But in counting searches, there’s a problem… not everyone wants to be counted:

A Google employee, Niniane Wang, demonstrated conclusively that a lot of the talk about "anonymized" logs is just pure B.S., and people like Greg Linden have shown that it’s possible to identify people even from aggregate data. So I think some of the Google apologists here are being a bit too partisan. But in this specific case, I think it’s perfectly legitimate (and even honorable) to mine the data in aggregate. - Joshua Allen

I wondered how data pulled out of Google’s front end (crawled web content, available to anyone) compares to what only Google can pull out of the back end (what users are search for, theoretically not available to everyone).

I wrote an Excel UDF to pull “estimated result count” from http://www.google.com/search?q= (Google’s search SOAP API is no longer supported for new users) to see how many blogs/Twitterers and other sites are saying “’I have the flu’ <State Name>” today, per capita.

A couple of the states Google sees more flu searches from came out on top:

• Ohio (1st, estimated 156000 webpages/11.5M population)
• Vermont (3rd, 21400/2.9M)
• Alabama (5th, 18900/4.6M)
• Maryland (8th, 16900/5.6M)

and the bottom:

• Kentucky (36th)
• West Virginia (38th)
• South Carolina (47th)

I’ve no conclusion here… other than Ohio really needs to drink plenty of fluids and get some rest, and something about “both ends.”

You can find out which states Google users are asking questions about the flu from at http://www.google.org/flutrends/

“Hot damn, you can drag Chrome tabs off to make new windows!”

“I thought I read Chrome’s installer forced default browser?… I installed this evening, and it left IE as default.”

“I read Chrome’s chrome falls flat on accessibility, and I’m not sure where Google apps stand on that. http://www.paciellogroup.com/b…”

“Chrome reminds me a lot of the first version of Safari… fresh and simple.”

“Another fun Chrome feature name: “Stats for nerds” (navigates to about:memory, which compares all browser processes.)”

“A Chrome gotcha: the area above tabs is narrower than most application title bars. Makes moving a window via (my) muscle memory difficult.”

“Also, it respects search provider settings set in IE. (After install it used Live Search by default, since that’s what I was using.)”

“Tried Chrome; it’s awesome. Fun feature names too: “Incognito mode”, “Basics / Minor Tweaks / Under the hood” option levels.”

2 Cups grated, drained zucchini
2 eggs, slightly beaten
1/4 Cup biscuit mix
1/3 Cup grated parmesan cheese
1/4 teaspoon black pepper
1 Tablespoon butter (optional for lower-fat)

1a) Grate zucchini and set aside to drain once it settles.

1b) Slightly beat the two eggs then add dry ingredients, folding in just enough to moisten.

2) Add drained zucchini, mix, and drop by spoonfuls to fry in butter on medium heat on a skillet. (Or without butter, on a non-stick skillet.) Fry to golden brown.

3) Serve plain (or with spaghetti sauce, but I never do that.)

This recipe originally comes from the Troy-Bilt (the garden tiller company) newsletter, and has been modified by me.

In the current implementation, favorites are interesting but terribly annoying to set when using the Zune client for playback. (It’s at least 5 clicks & two waits from a song in Zune client… (1) right-click song, (2) click More About This Album, …wait…, (3) click More At Zune.net …wait for the browser to start & load the page (may have to log into Live ID)… find the song in the list again… (4) click the song in the album (may have to scroll), (5) click Fav. (6) close the browser window or tab if you didn’t want it.)

I don’t recall if it’s even possible to favorite on the Zune device… please let me know if it’s easier than that.

So, my guess is in the current implementation favorites are likely things users want to show to others on thier card, badly enough that they will go through the effort I described to do so, but that favorites are abandoned after some time by N% of users. (When they realize there is no benefit, and that effort is high, and they churn.) And I bet some users only have 1 or 2 favorites from accidental clicks in the Zune card.

The upside is that perhaps if setting favorites has a “cost”, they really are more meaningful than actual plays, for those users who go through the effort to set them regularly & lovingly. So then, perhaps they have value in matching like-users up. Limiting the # of favorites (as is already being done) has this effect too, although it kind of pissed me off when I discovered I’d clicked so many times, all except 5 (clicks) x 8 (favorites max) for naught. Now I’m likely to not be a customer of the Favorites feature anymore, and if you add a match-up feature, it won’t do me much good. See churn.

In summary, please just make it usable ((1) right-click the song, (2) click Make Favorite), tell your customers up-front what benefits, and downsides, it has

It’s just for fun… show your friends what your 8 favorite songs are! Maybe we’ll add a match-up feature later!

and see what happens.

Cordially (like the Cherry),

Wade

Unfortunately there a couple usability problems with the Atom feeds:

1. According to feedvalidator.org, the Atom namespace qualifier used on the <feed> element will cause interoperability problems. It’s perfectly valid XML and Atom 1.0 but some consumption code, including some I saw written at work the other day, is looking for <feed>, not <a:feed>. I suspect this is what throws off FriendFeed’s blog importer, as well as the importers for Yahoo Pipes and Microsoft Popfly.
2. <entry><link> has an empty href attribute. Hey Zune team, remember that social I mentioned earlier? If you don’t link to it, customers ain’t joinin’ it.
3. <entry><updated> is the feed-generated date/time, not the date/time the track was added to the playlist. Time is an important dimension! (*waded favorites a curmudgeonly song at 3:54PM.)

So I thought, hey, let me try a little Yahoo Pipe grease:

1. Fix the interoperability problems by sourcing the Atom feed in Pipes as raw XML, then spitting certain elements back out as RSS.
2. Use the Zune Social XML namespace track information to make a useful <item><link> to get users to http://social.zune.net album info.
3. Nothing much to be done about the date problem that I could see… that’s for the Zune folks to fix.

The result is at http://pipes.yahoo.com/waded/zunefavorites. The RSS rendering, with parameters in bold, is at  http://pipes.yahoo.com/pipes/pipe.run?_id=4va_WrpV3RG7AfwEiXrL0A&_render=rss&mid=98772405-3286-4e64-b78b-f7512f3804fe&playlist=BuiltIn-FavoriteTracks

“My spoon’s too big… my spoon’s TOO BIG!”

Wouldn’t it be nice if the room we call the “lounge” wasn’t dominated by a computer desk and a rolling office chair? Here’s an idea:

Get rid of the computer desk & chair.

Put a nice colorful rug down.

On top of that, a small table & L-shaped couch, with an option to sit almost upright with back support on one leg of the L, and the option to lie down on the other leg

The tabletop should rotate to serve either leg of the couch.

Put the Apple LCD & keyboard & mouse on the tabletop; the monitor will lean back on its legs to serve all form factors of users.

Hide the computer box somewhere, perhaps behind the couch.

#1: Added an Atom <link>. RSS is dead. (Well maybe that’s a bit extreme, but providing only an RSS <link> is lame.)

#2: Removed any RSS badging/links. The fine art of “wasting time looking for a syndication badge when there’s plenty of other stuff on the WWW to look at” is dying. It’s not as usable or quick as letting a computer figure it out.

#3: Removed the search box, and related WordPress search cruft. Search on low-traffic personal blogs is definitely dead.

#4: Now displaying a bit more older content on the homepage.

#5: Fixed validation bugs (a <div> in a place it can’t be, a missing alt attribute on an <img>, and a Flickr URL with unencoded ampersands.)

#6: Changed styles and text a bit.

New research suggests that heavy coffee drinkers are less likely to die of heart disease, such as heart attacks, strokes, and arrhythmia. Edidemiologists from the Autonomous University of Madrid analyzed data from more than 120,000 men and women. According to their study, women who drank four or five cups of brew a day were 34 percent less likely to die form heart disease. Men who drank more than five cups a day were 44 percent less likely to succumb to heart disease…

(I cut it BoingBoing off here just for fun.)

That’s cool. So I’ll just keep on doing what I’m doing.

Now, I heard the same this morning on the radio, although the radio folks said decaf coffee has the same effect. Lies.

If we keep playing the telephone game long enough, we’ll be drinking coffee from the Annals of Monkey. Oh wait, some people actually do that one.

In summary, coffee is great, reblogging is annoying, and people on the radio just talk about whatever in the morning and I wish they would shut their yappers and play some music.