Tom Reestman has a nice post showing differences between the Remote application, for controlling iTunes from an iPhone, and the built-in iPod application (via John Gruber). I agree that Remote is much nicer, although it’s missing a few features. It would be nice if iTunes’ unzoomed controller could show the cover art and controls like that.
I don’t like the data detectors that Apple added to Mail in Leopard, because I never use them and they interfere with selecting text. I just figured out that you can disable them by entering defaults write com.apple.mail DisableDataDetectors YES in Terminal. Normally this type of hidden preference would be easy to look up in Google, but I only found a bunch of ideas that didn’t work, and as of this writing there are zero hits for “DisableDataDetectors”.
Update (2013-04-16): Alas, this no longer works in Mountain Lion.
If down the road it turns out Steve was lying and someone from the SEC or some lawyer in a civil suit wants to find out what was said in that conversation, they’ll have to subpoena Joe Nocera, and the New York Times will fight that request. Even if Joe Nocera wants to tell the world what Steve Jobs told him, he can’t. He made a deal. He went off the record. Even if Steve turns out to be lying, Joe Nocera is stuck.
Thus Steve Jobs gets to protect his stock price and give Wall Street the message that he wants them to hear, and should any of this turn out not to be true, well, Steve and Apple now have Joe Nocera and the legal department of the New York Times to act as their ally and firewall.
And it’s a little mind-boggling that today, nearly two weeks after MobileMe’s official opening, Apple still hasn’t solved the problem. That’s got to be a record in the short history of cloud computing.
But the real problem is how Apple is responding. For a company that’s so brilliant at marketing, it seems to have absolutely no clue about crisis management.
Update (2008-07-26): Apple’s added a status page and an RSS feed:
Steve Jobs has asked me to write a posting every other day or so to let everyone know what’s happening with MobileMe, and I’m working directly with the MobileMe group to ensure that we keep you really up to date.
And Glenn Fleishman comments on it. I agree with Fleishman: why is it written in the first person but unsigned?
Update (2008-08-04): Glenn Fleishman:
MobileMe’s launch should have been staged. First, iPhone 3G owners should have had access when signing up for new accounts. Then iPhone 3G and original iPhone owners with existing .Mac accounts or who wanted new accounts should have been given access. Then a slow transition for users who weren’t interested in the sync changes could have happened over weeks.
I’m no expert in these matters, but I’ve read enough about pipelines and caches to know that this is entirely plausible. When the code is uncluttered with detours, it goes much faster than when the end of the loop pauses to consider whether to invoke the progress function. Ironically, actually calling the function and invoking all of the Python overhead is insignificant compared to the time lost to simply deciding (in C!) whether to call it.
The results are obvious. WebKit JavaScript performance has improved steadily and significantly in just one year, with a huge jump between 1.1.4 and the new 2.0.0.
And yet his MacBook Pro (which may be running a less optimized version of Safari) is still 40 times faster. Macs are fast these days.
Update (2008-07-24) from John Gruber:
Recursion depth, in and of itself, isn’t particularly important. It’s just a particularly simple way to distinguish pre- and post-SquirrelFish versions of WebKit. And so since we now know that the iPhone isn’t yet using SquirrelFish, it means further dramatic performance improvements are on the horizon.
Craig Hockenberry describes how Apple’s tight control over what can be installed on an iPhone impedes developers’ efforts to debug and test their products. This can’t be a surprise to Apple, but it’s unclear what, if anything, they plan to do.
Update: More from Brent Simmons.
To set the record straight, I talked to Apple’s senior director of iPhone product marketing, Bob Borchers. Borchers indicated that this definitely isn’t a bug or a display defect. Yes, the display on the iPhone 3G has a warmer look—and that’s by design. The previous iPhone’s white was more of a cool blue (Borchers likened it to harsh fluorescent lighting), while this one’s is warmer and more of a sunny yellow.
I like the old color better. It’s true that it’s “more blue,” but I don’t think it really looks bluish. To my eyes, the whites look white, whereas the iPhone 3G looks like a dirty yellow. The original iPhone screen looks very good, even at low brightness levels.
AppleInsider has more photos.
Ken Case (via Lukas Mathis):
Settings which appear in the built-in Settings application can’t have any code associated with them, they can only use standard controls which store data in a few limited data types. We wanted to provide the ability to copy synchronization settings from a Mac on your local Wi-Fi network, which involves code—making it impossible to put our settings in the global Settings application.
The above point makes this moot, obviously, but in general another important factor to consider is whether the user might change a setting more than once or whether it’s really just a one-time configuration. If you’re talking about something like Mail settings, it’s pretty much fire and forget—but in OmniFocus’ case, the user might want to quickly switch between looking at all their completed items and then switch back to looking at just their available actions, and they wouldn’t want to have to relaunch OmniFocus each time they did this.
It’s not clear to me why Apple wants applications to use Settings, except that it reduces the need for a button in the application. It’s a pain to have to quit an application to change a setting, and it’s not always clear what’s a setting and what’s application data. I’ve only changed the locations in the Weather application maybe half a dozen times in the past year, yet I’m happy with them being in the application rather than in Settings.
I work solo, only moving between a desktop and a laptop, so I’m not making huge use of the distributed capability. My previous writing on Git was occasionally mildly criticised for “ignoring” that aspect of Git. I’m not ignoring it, but I lack an understanding of how it really helps me. No, what’s great about Git so far is the power of the tools for everyday operations.
One thing that’s clearly missing is any sort of backup guarantee. While you may feel more secure storing your documents on Google’s or Zoho’s or Adobe’s servers than your own, that security is not something that you’re promised. Any of the three can lose your documents or terminate your ability to get to them at any time for pretty much any reason, and you’re out of luck. So if you do put important things online—back them up somewhere else.
The unicode support in Python is generally considered to be pretty good. And in comparison to many other languages, it’s good indeed.
But compared to what is provided by the International Components for Unicode (ICU) project, there’s also a lot missing, including collation, special case conversions, regular expressions, text segmentation, and bidirectional text handling. Not to mention extensive support for locale-specific formatting of dates and numbers and time calculations with different calendars.
Gus Mueller makes fun of Adobe Reader 9. Good to know you can get the “recomposition” status down to a tenth of a percent. By the way, there’s still no universal binary.
Update (2008-07-04): Mark Pilgrim comments, and John Gruber writes:
Adobe today reminds me a bit of Apple in the mid-’90s. Tremendous engineering and design talent in the company. A loyal base of users built over 20 years. But management that just doesn’t get it at all, and seems hell-bent on running the company into the ground.
I recently installed WP Super Cache to speed up my WordPress blogs. The regular WP-Cache plug-in saves processed copies of pages, reducing the database and PHP processing overhead, but the pages are still served via PHP. WP Super Cache takes this to the next level, using mod_rewrite to send requests directly to cached HTML files:
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html -f
RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html [L]
If a page isn’t yet cached, the -f test will fail, and the request will be directed to the regular WordPress PHP script (using WP-Cache). It’s a nice system, but I hit a few snags setting it up, so I wanted to document them here.
The first problem was that the super cache was not being generated. Every request was being handled by WP-Cache. It turns out that WP Super Cache (sensibly) doesn’t add a page to the super cache unless $_GET is empty. I was using a .htaccess file from a much older version of WordPress, and it was packing the query string with elements of the path:
RewriteRule ^archives/?$ /blog/index.php?pagename=archives [QSA]
RewriteRule ^category/(.*)/(feed|rdf|rss|rss2|atom)/?$ /blog/wp-feed.php?category_name=$1&feed=$2 [QSA]
RewriteRule ^category/?(.*) /blog/index.php?category_name=$1 [QSA]
RewriteRule ^author/(.*)/(feed|rdf|rss|rss2|atom)/?$ /blog/wp-feed.php?author_name=$1&feed=$2 [QSA]
RewriteRule ^author/?(.*) /blog/index.php?author_name=$1 [QSA]
RewriteRule ^([0-9]{4})/?([0-9]{1,2})?/?([0-9]{1,2})?/?([_0-9a-z-]+)?/?([0-9]+)?/?$ /blog/index.php?year=$1&monthnum=$2&day=$3&name=$4&page=$5 [QSA]
RewriteRule ^([0-9]{4})/?([0-9]{1,2})/([0-9]{1,2})/([_0-9a-z-]+)/(feed|rdf|rss|rss2|atom)/?$ /blog/wp-feed.php?year=$1&monthnum=$2&day=$3&name=$4&feed=$5 [QSA]
RewriteRule ^([0-9]{4})/?([0-9]{1,2})/([0-9]{1,2})/([_0-9a-z-]+)/trackback/?$ /blog/wp-trackback.php?year=$1&monthnum=$2&day=$3&name=$4 [QSA]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ /blog/wp-feed.php?feed=$1 [QSA]
RewriteRule ^comments/feed/?([_0-9a-z-]+)?/?$ /blog/wp-feed.php?feed=$1&withcomments=1 [QSA]
Updating .htaccess file to let WordPress itself parse the path:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress
fixed that problem.
Now the posts were being saved to the super cache, and served from it, but the feeds were only using the regular cache. WP Super Cache is hard-coded not to cache feeds in order to avoid serving them with an incorrect content type (a.k.a. media type or MIME type). Feeds are supposed to be served as application/rss+xml or application/atom+xml, and Feed Validator will complain if they aren’t. But the super-cached files are all stored as index.html so Apache will serve them as text/html. (This isn’t a problem when using WP-Cache, because it sends the proper HTTP header depending on the type of feed being generated.)
To fix this, I modified WP Super Cache to generate local .htaccess files inside the super cache:
if (is_feed()) {
$type = get_query_var('feed');
$type = str_replace('/','',$type);
switch ($type) {
case 'atom':
$mediaType = "application/atom+xml";
break;
case 'rdf':
$mediaType = "application/rdf+xml";
break;
case 'rss':
case 'rss2':
default:
$mediaType = "application/rss+xml";
}
$htaccess = @fopen ("{$dir}.htaccess", 'w');
if ($htaccess) {
fputs($htaccess, "AddType $mediaType .html");
fclose($htaccess);
}
}
For example, the file blog/wp-content/cache/supercache/mjtsai.com/blog/feed/rss2/.htaccess changes the content type for the index.html file:
AddType application/rss+xml .html
Then I modified WP Super Cache’s wp-cache-phase2.php to remove the is_feed() check from the line:
if( !empty( $_GET ) || is_feed() || ( $super_cache_enabled == true && is_dir( substr( $supercachedir, 0, -1 ) . '.disabled' ) ) )
Now the feeds are super cached and served with the correct content types.
The July issue of ATPM is out:
Sure, it’s frustrating when you can’t figure out why a menu item is disabled. But what would be unbelievably frustrating is drowning in a sea of enabled menu items, for which the application offers no immediate usability guidance. Instead of skimming past disabled items, a user could be forced to select several, each time receiving a valuable instruction (punishment) as to why it was a worthless move.
