Tapirtype Blog

I’ve become convinced that those flashy blinking ads are designed to drive page hits. How? I just found myself reloading the New York Times web page five times in a row in the hope that I’d get an ad that wouldn’t compel me to hold my hand over the screen so I could read the actual content without being distracted.

(And yes, I know there’s software to fix that.)

So we all know that the 24 hour limit sucks. That (along with the fact that you can only get HD content if you have an Apple TV, what could otherwise be the killer feature for me) certainly prevents me from me from even considering it as an option beyond something to keep in the back of my head for last resort instant gratification.

Netflix, by contrast is of course quite happy to let you keep DVDs for as long as you like. As a subscription outfit, they just make more and more money off of you. But plenty of people would certainly prefer to pay per rental and herein lies the problem as renting on a long enough time frame becomes indistinguishable from buying.

The solution: Instead of putting an arbitrary cutoff time after hitting play, there should be a virtual check back in. You’d a allowed to have, say, 10 movies checked out at a time, paying for the rental when you download them and keeping them as long as you like, but you wouldn’t be allowed to download the 11th until you “check in” one of the 10, rendering it unplayable. Certainly this would introduce some more security holes and would set an upper limit on how many movies you could take with you on a trip if you don’t want to access the internet from the road, but it would prevent wholesale abuse. On the whole I think it would work much better for most people.

Duh!

Or well, you’d think it would be “duh.”

I’m not big on ultra portables. I use a mid sized MacBook Pro 15” (named Mallory by the way) because I like to have (and well, can afford) one machine that I largely take from desk to desk going from work to home to wherever else I need to be. I’m a large enough guy that carting Mallory back and forth from work isn’t ever much of a problem, and making her smaller, even much smaller isn’t going to magically solve the ergonomics of using her away from a desk.

So I’ve watched the complaints that Apple doesn’t offer a decent ultra-portable form the sidelines as a somewhat disinterested observer. Ok, I get that for people with desktop machines who use their portables as portables instead of “transplantable” computers might like something super small to take to the coffee shop or the plane or class or meetings or wherever it is that they go when not sitting at their desktop.

So Apple comes out with just such a machine and all those same people, the people who derided the 17” and so clearly don’t subscribe to the “transplantable” computer idea, complain that there are not enough ways to tether it down? Honestly? You really want lots of ports so you can park this super, super thin computer on a desk with wires sticking out of every end so you won’t notice how thin it is because you can’t pick it up without unplugging a bunch of things anyway? You’re really concerned that you need to install software on it with the help of a larger computer? Do you really do much installing of software on the road? If you, like me, aren’t willing to sacrifice much in the way of power for size then, news flash, you don’t actually want an ultra portable. You want a general purpose portable, and congratulations, Apple already sells those in a variety of size-power-price points.

Update: Many people are further making the comparison to the Cube. I think that’s deeply flawed as while both machines made compromises on price in order to achieve small size and exciting form factor, many people appreciate those things in a desktop, but few really benefit from them. Anyone who uses a laptop will benefit in very concrete ways from the lightness and thinness of the Air… even if many don’t feel the trade off is worth it. I strongly doubt that anyone out there would find themselves buying a computer they otherwise wouldn’t because they could fit it on a smaller desktop. There are definitely people out there who would choose to bring a computer with them at the weight and thinness of the Air that would decide not to bring one at all otherwise.

I don’t think most ducks migrate, but this mallard has just about finished migrating tapirtype over to the new Joyent shared accelerator “Myrtle”.

Just a couple more things to test (this post included) and I’m going to declare it done and switch the DNS over.

While checking out the new iPods at the Apple Store, I discovered a big defect in the new iPod’s marquee feature: cover flow. On the first several iPods I picked up, scrolling through cover flow would cause the audio to distort and stutter unbearably. Not just a little or just when the song hadn’t had a chance to cache and not just when scrolling all the way from one end to the other. I was just about ready to give the feature up for useless when I picked up another iPod, one attached to one of the iMacs on the other side of the room and there was no trace of the problem. A quick google search pulled up some other reports of the problem, so it wasn’t just something wrong with the iPods in that store, and frankly I was a little surprised not to find more reports given the severity of the problem.

It puzzled me for a while. At first I figured that identical seeming iPods were getting different components. Then I figured it out: The ones by the computers were restarting when they got plugged and re-plugged. Sure enough, I picked up the first iPod again, stuttery as ever. A quick restart, holding down the center and menu buttons, and it was perfectly smooth. Mystery and, as far as I’m concerned, problem solved. Hopefully a future software update will prevent it from happening at all.

Unfortunately this doesn’t change that, while cool, cover flow is of limited utility to begin with, especially so on a mobile device device with a large collection that can only be browsed in one long list. What’s especially unfortunate is that on the go playlist creation doesn’t seem to work with cover flow and that’s where I could most see using it: brainstorming about what I want to listen to next.

I’ve been thinking more about Apple’s new iPods and my reaction to them. I think the basic force behind my disappointed reaction was that, for the first time ever, it wasn’t entirely clear to me which iPod I would buy if I could. In fact, I think it is noteworthy that prominently displayed on Apple’s webiste is a feature entitled “Which iPod are you?”. Apple tends to strive for simple product lineups these days, balancing the need to make as much cool stuff available as possible with the fear of diluting their product image with a flood of sub-par options. Furthermore there is some tendency, I think, to feel that if a customer has to think too hard about which option is the best for them, they might think themselves right out of the purchase altogether, feeling that none of the options is optimal. Apple would much rather have you salivating over the one perfect product.

Apple is in a funny product transition with its iPods, based in part on the iPhone and in part on the increasing capacity of flash based players, and that has, unfortunately, left them caught making their customers choose between sub-par options whose flaws wouldn’t even be evident if the other product wasn’t available for comparison.

Ok, I think I have the caching thing figured out. Seems that Smarty (which handles the dynamic publishing—and caching—for Movable Type) defaults to a one hour cache timeout. What Smarty does is write the time-stamp in a header on the cached file along with an expire time-stamp computed by adding an interval determined by the smarty variable $cache_lifetime which defaults to 3600 seconds (or one hour). When retrieving a page, smarty compares the expire time with the time the cached file was built and retrieves the cached file only when the cache has not yet expired.

Why it does this is another matter. One hour seems either far too long or far too short for the life of a cache. It especially makes no sense in the context of Movable Type which seems to clear the cache whenever there is a change to the database, such as saving an entry—whether or not the entry is published—or making a comment (although, not, for some reason, when comments are deleted). Incidentally, I haven’t yet figured out how Movable Type achieves this. I can’t seem to find where in the code it flushes the cache or checks the modification date on the database, however I have empirically determined that this is the behavior.

This caching behavior especially makes no sense for me, since this blog changes, at most, daily. Fortunately, the default cache lifetime can be changed by editing the smarty.class.php file (found at mt/php/extlib/smarty/libs/). At the top of the file, which defines the smarty class, a bunch of default values for variables are set, some of which are overridden by Movable Type when it creates an instance of the smarty object and uses it to display dynamic content, notably the $caching variable which defaults to 0 (off) is flipped on later if you have enabled caching enabled via publishing preferences.

Setting $cache_lifetime = -1 results in a cache that never expires until the Movable Type database is changed, the setting that makes sense (to me, anyway) assuming that the only way the content displayed for a given page will change is if a change is made through Movable Type. This does bring up an important caveat however (although one I haven’t verified), which is that if you have dynamic content on a page that changes based on input other than the Movable Type database, it may not work, or may take some extra effort to ensure that it works.

I was hoping to get an excuse to upgrade my 20GB 2G iPod today. At first my heart sunk when I saw the iPod Classic announcement, thinking they had decided not to release the expected touch screen iPod. Then I hit reload, and it was there… Except it kind of wasn’t. The iPod Touch has everything I could possibly want in an iPod, except it only has up to 16GB of storage. That’s less than my 5 year old iPod which cannot, as of earlier this year, hold my entire music library—the main reason I’m looking for an upgrade. I just can’t see a downgrade in storage. Sure, I don’t need to take all of my music everywhere, but once I cross that bridge, I suddenly have to start making decisions about which music I am going to take. And now instead of just plugging it in and it’s done, I have to think about it. I have to make decisions, and I have to keep things organized. And that’s just less fun than the original wonder I had in being able to carry all my music with me anywhere without thinking about it.

I don’t know. Maybe my experiments with downsizing my library to fit on my current iPod will convince me that 16GB is enough. Or maybe in 6 months there will be a 32 or 64GB version, or eventually I might get an iPhone and a touch screen iPod will seem less exciting, leading me to an eventual iPod Classic upgrade. But in any case, I won’t be throwing any money Apple’s way just right now, and I was kind of hoping to be pushed over the edge into doing that today.

Update: Seems about the least I can get my catalogue down to without having to make any really difficult choices is 15GB, which probably wouldn’t fit onto a 16GB iPod Touch given the formatting and OS overhead. My next iPod must have at least 30GB.

As I mentioned previously, I recently switched a good portion of Tapirtype Blog—everything other than the front page index and the entries themselves—to dynamic publishing. I’ve been collecting my impressions, although I’m generally waiting for the upcoming move on to Solaris at TextDrive, my hosting provider for any final judgments about performance.

I like the idea of it, but I’m still not sure on all the details of the execution. This is partly because Movable Type uses Smarty for it’s template system, so in order to understand what’s going on, I have to understand both what Movable Type is doing and what Smarty is doing. Note, this isn’t a criticism, I think Smarty is perfect for the job, and I’m glad they didn’t try to reinvent the wheel, making their own php template compiler. The biggest concern when switching to dynamic publishing is that the efficiency equation shifts. During static publishing, it makes sense to make trade offs that make build time just slightly longer for the sake of convenience, simplicity, or feature-fullness. Using dynamic publishing, however, this could lead to intolerable page load times, so caching becomes very important in order to make only the first load any slower.

Smarty has two levels of caching. First it complies the templates into php files on the first request. In theory this should eliminate any disadvantage of a template based system as compared to Wordpress style php “templates”. Second, as pages are requested the output is stored in a cache folder, so the second request for a given page should be able to simply echo that cache file with no computation necessary. Actually there’s a third level of caching, though I’m not sure whether it is a Smarty or a Movable Type feature, which is that the blog will instruct the web browser that the page has not changed since the last request, allowing the browser to fetch it from it’s own cache.

But the difficulty with caching is that any caching system is only as good as it’s ability to tell when it needs to recompute the content. Preferably, the system would be smart enough to understand which pieces of the content have updated and which are still the same, but at the bluntest it must flush the entire cache every time any change is made. And here’s where things have been falling down for me. In a given session, I can sit at the blog, load a bunch of pages, and see that after the first load, the loads get much quicker. However, inevitably, the next day, with no changes made the the blog, I’d find the caches recomputing. With no changes published to the blog, I can’t see why this would be the case. The only thing I could think of was the fact that several trackback requests had come in and were marked as junk, resulting in no changes to the published blog. It would be quite silly if that was causing the cache to reset, but just to test, I’ve disabled trackbacks now. As much as I like the idea of trackbacks, they’ve never really worked out, anyway, and since adding a captcha to anonymous comments, they are my only current source of spam (although none ever get published due to the insistence that the trackback request come from the same IP address to which it points).

In the wake of the current spat between NBC and Apple over the price and DRM applied to TV content sold on iTunes, many people have been considering the status quo of TV distribution and pricing. Fake Steve, through his usual hyperbole probably comes closest to the truth by asking, essentially, why we need the networks at all. Don’t they exist simply to agrigate content produced by production companies in order to pipe it over the airwaves to consumers? Why should we need them at all when the content producers could sell directly through iTunes or any other internet distributer? What are they there for other than to take a cut of the profits?

Leaving aside the fact that—for now—vastly more people watch plain old, live, non-time-shifted network TV than any kind of content on the internet, you could come up with a few reasons for networks to keep on existing: