With no pundit reputation to screw up, I stand here unashamed and ready to be proven wrong. Here are my predictions for what the mythical Apple tablet computer will be all about.

It will be called the ‘iSlate’

Cool name. NYTimes editor Bill Keller called it a version of that name (”the new Apple slate”) at one point awhile back, and it just fits nicely. Also Apple owns islate.com.

There will be an awesome accessory

The iPhone comes with an accessory that manages to actually up the cool factor — its headphones. The iSlate will have one if its own: a sleek cradle that will fulfill the functionalities of a stand (allowing the iSlate to sit upright for easy seated viewing), and a charging station, using magnetic induction as its power delivery mechanism, and enabling Apple’s designers to avoid placing a power port on the device itself. I’m also predicting as part of this that it will support over-the-air sync only.

Part of the pitch will be for use as an accessory

Not a big part, mind you, but I think there will be significant emphasis on using this as a secondary input device for an existing computer — as a drawing tablet or a multi-function “hotkeys” device or something. This could just be wishful thinking on my part, but I just can’t get past the idea that Apple wants people to view this as a computing device whose primary attraction is that it lends itself to a paradigm-shifting generality of use. That means fulfilling the roles of computer, television, magazine, and yeah, Wacom tablet.

More importantly will be the idea that the iSlate fits into your life in a certain way — as your “on-the-go” device; even more so than the iPhone, this is the thing you take to meetings, take on short trips, etc. Auto-syncing important documents and whatnot over the air will be a big deal.

It will run something beefier than iPhone OS

Maybe not full-on OS X, but I agree with John Gruber that they’re not going to just spooge the iPhone OS onto the device:

in the same way that it made no sense for Apple to design the iPhone OS to run Mac software, it makes little sense for a device with a 7-inch (let alone larger) display to run software designed for a 3.5-inch display.

I also don’t think that the file system will be completely hidden away a la the iPhone and that the only way you’ll be able to interact with the device is through apps. If this is to try and be a general-purpose computing device, there has to be some kind of file system access, even if it’s severely limited. Another piece of evidence for it being something somewhere between iPhone OS and full-on OS X is the WWAN (as in 3G) network information reporting in Snow Leopard.

OK — that seems like prognostication enough for now. Can’t wait for January 26th/27th.

I like this Macalope column from Macworld, reminding us all how wrong all the pundits were in advance of the iPhone (and quite a bit of the dumb stuff that’s been said lately about the rumored Apple tablet). The best part though is his insight that the reason Apple has succeeded with the iPod and iPhone is because those two technologies each had a killer differentiating feature that made them able to disrupt an existing market.

if and when it appears, will have some differentiator that makes it a compelling purchase. The iPod replaced your CD collection, the Apple TV would like to replace your DVD collection (but you won’t buy one), and the iPhone, obviously, replaced your cell phone. The tablet (insert caveat about its existential dilemma) will turn another industry on its head. The problem with the JooJoo is that it has no hook, no ecosystem. It doesn’t act as a compelling replacement for anything you have.

One thing that I’m hoping for (but that I think there’s very little possibility of due to the likelihood that they’re going to base it on iPhone OS) is some kind of personal diagramming application. I’d love to be able to add some programmatic heft behind the diagrams I draw of data models, applications, etc. I’d love to be able to put data behind some stuff, or draw things that can go right into a program like OmniGraffle

If my own little personal BS grammar of pseudo UML could get programmed out pop-n-fresh automatically into some ActiveRecord models right after I drew it freehand, I’d be one step closer to some right-brain techie Nirvana.

There are more black people than white people on Twitter, and this is only recently becoming obvious to people because of new Twitter stuff like Trending Topics:

But seriously—talk about being in a bubble!—demographically, there is a greater proportion of black people than white people among the Internet-using population on Twitter: according to Pew, 26% of African-Americans online use Twitter; only 19% of white Internet people use Twitter. So really the question is: why does Twitter get so white and boring during the day? Don’t white people do anything at work?

So many data at play in this that I don’t want to say anything, but this is really interesting for what it says about Twitter’s power as a general communication medium with high availability outside the socioeconoomic ranks of affluent suburban office workers.

Short answer: OpenURI doesn’t support the “feed://” pseudo protocol and if you try it with a hash of header options it gives you the same error as if, like some dumb muppet, you hadn’t required the library in the first place. In other words, it falls through to Kernel#open and leaves you scratching your head.

Long answer: Read on, code fiends. Read on.

Tonight I decided to earn some HusbandPoints™ by helping my wife get a large number of tagged photos off Picasa for a project that she’s working on. Downloading them by hand would’ve been a pain in the ass timewise and also would’ve been a big pain opportunity-cost wise as well, since she would’ve had to take time out from the main body of the project (a homemade cookbook for a friend’s wedding) to do a dumb photo-by-photo clickfest through the entire large Picasa album she’d assembled with her friends. Plus it gave me a reason to mess around w/ the Google APIs some — knowledge that would almost certainly come in handy later.

Now, the easiest way to go about scripting this w/ Ruby involves using open-uri to pass in the authorization token from Google into every request, per their ClientLogin authentication method. You do that with a piece of code like this:

Here we’re getting the content from Google (which will come as an Atom feed, as all of their various pieces of content do) and then parsing the result with Hpricot. We pass the http_header Hash to OpenURI’s open method to specify a set of HTTP header variables. This is supposed to be easy, but tonight it wasn’t, and my wife was treated to the inelegant sounds of me cursing at my laptop screen for 10 or 15 minutes until I figured out what the problem was.

‘feed://’ don’t go ’round here

The problem turmed out to be the “feed://” pseudo protocol. Safari likes it (because it fancies itself a feed reader), and decided to make the RSS link provided by Google for the tag set my wife wanted to download into a “feed://” URL. Of course, there’s no such protocol, and “feed://” itself is a pretty lame. People have been bitching about its lameness for a long, long time. It’s almost as lame as me not catching it.

But the lamest thing of all (which was causing the cursing) is how OpenURI handles this:

This is the same thing you get when you try to use open on a URL with a hash of header arguments and you’ve forgotten to require the OpenURI library in the first place.

The problem here seems to be with this part:

It’s not calling the part you might think — the piece where it asks if the name can be converted to a string and if it conforms to a loose URI regex pattern. It’s instead calling it with the original, version of open, the one that the Kernel class provides so you can easily open files and URLs (but without all the tasty options given you by OpenURI). This error gets thrown by Kernel when you try to use open outside the context of OpenURI (as this guy points out).

Since we can tell that a URL that starts with “feed://” should pass the first of the two tests in the “elsif” clause (the regex pattern), that means that it’s not passing some part of the the URI.parse test. Here’s what that URI.parse method looks like:

No great clues there. But if you run through the code in the OpenURI#open method’s elsif clause, it turns out that if you parse the offending “feed://”-based URI, you don’t get a “URI::HTTP” object. You get a “URI::Generic” object, which doesn’t respond to open. Obviously, the library doesn’t support this kind of URL, and if it weren’t overriding a Kernel method, it’d probably say so, but it can’t make assumptions about what you’re trying to do with open, so it instead falls through to the call to the overridden Kernel#open and you get the same error you’d get if you never used “require ‘open-uri’” in the first place.

Lesson learned, boys and girls — pseudo protocols aren’t supported by much at all other than self-important feed reading software.

Thanks to the Gimite Google Spreadsheet library for inspiration on the auth code

I’ve only played with Google’s new Fast Flip newsreading feature for a few minutes, but I’ve already got one major problem with it: it’s hard to scan headlines. When you think about it, that’s something that reading a paper newspaper still lets you do — you open up a double-sided broadsheet and you’re scanning over probably 5 or 6 stories on the inside, depending on the number of advertisements. If you scan down the front page or the main page of a section, you can see the headlines for 8-10 stories. With Fast Flip, the “scanning” view is a bunch of screen caps of the articles you’re about to look at, with the headline in small print underneath. Scanning this list of screen caps isn’t that informative because the shrunken headlines are hard to read.

Contrast this with the front page of Google News or something like Techmeme or memeorandum and you’ll see what I mean.

Now I get that Fast Flip is designed for you to click into one of the streams of articles and then use the left/right arrows to page through it, but this causes me to “zoom in” conceptually and doesn’t really let me stand back and see all the headlines from a distance. So I can have the experience of “flipping” from page to page and not knowing in advance anything about what I’m going to see next (other than some basics of subject matter), or I can scan small headlines all at once. Doesn’t feel like the greatest compromise in the world.

For me, I’m still deciding if I like this or not. I’m a big fan of graphic design and I like that Fast Flip offers an opportunity for that to shine through earlier in the reading process than it can on something like Google News or Techmeme, but I’m not sure if that outweighs the benefit of being able to move fast through a large number of headlines.