Posted by marshall
Sun, 24 May 2009 20:58:00 GMT
Initially, I didn't believe that the new hourglass marshmallows in Lucky Charms would actually make it possible to control time. Day after day, I ate a bowl of the cereal, hoping to suddenly find myself able to change the course of history without having to invent my own flux capacitor or fly through a black hole, yet nothing happened.
But today was different. Today I was wearing my three-wolf moon shirt, and as I poured some Tuscan Whole Milk (1 gallon, 128 fl oz) over the cereal, I suddenly found myself able to travel through time to whenever I wanted. So I went back to yesterday and got a free taco.
Posted in Gallimaufry | 1 comment | no trackbacks
Posted by marshall
Thu, 08 Jan 2009 07:43:00 GMT
When I bought my iPhone 3G last summer, I decided to simply set it up as a brand-new device, rather than attempt to upgrade my original iPhone to the 2.0 firmware and then restore to the new one. I didn't really need the call logs, I had used Syphone to save my SMS logs as PDF files, and everything else was synchronized. Or so I thought.
I forgot about Notes. Notes don't sync.
When the iPhone was first introduced, it suddenly made sense why Apple was adding the Notes feature to Mail in Leopard: it needed to be able to sync with the iPhone. When the iPhone was released and Notes didn't sync up at all, I found it somewhat inconvenient, but knew that in just a few months Leopard would be released and all would be well. But then Leopard was released, and still there was no synchronization. It's now been over a year, with a brand-new iPhone OS 2.0 platform with multiple updates, a brand-new iTunes, and several updates to Leopard, but still, no synchronization of Notes. It really is puzzling.
At any rate, there I was with my new iPhone 3G, and I'd already handed down my previous iPhone, and I suddenly realized that my notes were all missing. At the time, I simply wrote them off as gone and moved on. But recently I wanted some information that I remembered storing in Notes on the iPhone, and realized that I still had the backup sitting around from the old device. I just needed to find a way to extract the Notes database and convert its contents into a readable format.
Now, there are existing tools floating around that can extract databases from iPhone backups, but my quick search didn't turn up anything that specifically located the Notes database and converted it to individual files like I wanted. Perhaps there is such a thing somewhere, but I was somewhat inclined to just write it myself anyway, simply for the fun of learning a little more about iPhone internals and solving my own problem. It turned out to be fairly easy to do using the stock Ruby installation in Leopard, which already includes the RubyCocoa and SQLite libraries needed to read the backup files.
So here it is, in case anyone else finds such a thing useful: iPhone Notes Extractor.
Posted in Computing, Smartphones | no comments | no trackbacks
Posted by marshall
Thu, 20 Nov 2008 18:37:00 GMT
From Macworld's review of the BlackBerry Storm 9500:
And while we're on the subject of welcome features that users are clamoring for, let's not overlook (cue fanfare) cut-and-paste. BlackBerry has shown Apple how it's done, by using the same multi-touch technology used in the iPhone 3G. Here's how it works: you put one finger at the start of what you want to copy, and one finger at the end to highlight text; then press the Menu button to select 'cut' or 'copy'...RIM's solution doesn't work well enough for us because it is fiddly beyond belief ("using this would drive you mad," said one of our testers).
I can't tell if the phrase, "BlackBerry has shown Apple how it's done", is sarcasm or not. It seems to be written in complete seriousness, yet I can't see how it could be. It is this kind of thing that demonstrates precisely why Apple has not yet implemented copy and paste in the iPhone. It's not that they don't know what it is, or don't recognize the need for it. It's that, if they're going to implement it, they need a good implementation to begin with, and they haven't got one worked out yet. All the BlackBerry has done is provide a reference implementation of how not to do it...and there are plenty of those already.
Posted in Smartphones | no comments | no trackbacks
Posted by marshall
Mon, 17 Nov 2008 04:06:00 GMT
When I first heard, several months ago, that iPhone OS 2.0 supported hardware-accelerated 3D CSS transforms in WebKit, my first thought was, "CoverFlow could be implemented in Safari with this!" In fact, I fully expected such an implementation to arrive within weeks. Well, months went by, and no one actually wrote such a thing that I could find, so a couple of weeks ago I decided that I ought to.
Last weekend I actually sat down to write it, but first made one more cursory check to see if I'd missed anything. It turned out that, in the previous week, Charles Ying had posted his own work on implementing CoverFlow using 3D CSS transforms, and had even set up a CSS-VFX project on Google Code for continuing work on it.
The CSS-VFX example demonstrates touch events, canvas (for reflections), CSS animation, and rotating images in 3D space, using sample images from Flickr. It's well worth looking at if you're doing any work on iPhone-optimized web sites. And although 3D transforms are currently only available on iPhone OS, they will no doubt make it to WebKit on other platforms in the future, and perhaps even on other browser engines if the extensions make it into an official CSS spec someday.
It's also worth noting that the WebKit team has already implemented a -webkit-box-reflect style in the nightlies, though it hasn't yet made it to iPhone OS. When it does, the canvas code won't even be necessary; the iPhone will be able to do hardware-accelerated reflections in CSS.
Posted in Computing, Smartphones | no comments | no trackbacks
Posted by marshall
Tue, 17 Jun 2008 00:43:00 GMT
I'm back from WWDC, and it was a great week. The sessions were interesting, I had lots of good discussions with friends, and as usual, a bit of sightseeing was worked in as well. The conference itself was far better than last year's blend of dropped Leopard features and the "sweet" "Web 2.0" "app" "solution" for the iPhone. This year, we got solid information on the real iPhone SDK, Snow Leopard, and even some improvements for web apps.
For once the early buzz was fairly accurate, so my predictions for what was likely to appear turned out to be reasonably accurate as well. The things I thought would happen did, and the things I didn't expect (but nonetheless hoped for) were nowhere to be seen. And while there were a few small surprises, there weren't any really big shockers.
That being said, here are the results, broken down in the same way the predictions were...
Read more...
Posted in Musings, Computing, Smartphones | no comments | no trackbacks
Posted by marshall
Sun, 08 Jun 2008 05:41:00 GMT
There is almost always a surprise at Macworld and WWDC keynotes, and no one really knows going in just what's going to happen. There's no real point in trying to figure out ahead of time what sessions to attend at WWDC; the keynote frequently changes everything.
John Siracusa has been making bingo cards for the past couple of years, containing predictions what may or may not appear at the keynote. I never really played along, but I do have my own expections of what will happen. I'm usually wrong -- most spectacularly at Macworld 2007 (my list was similar to Gruber's) -- but even then it's fun to look back later and compare what I predicted with what actually happened.
So here they are, broken down by how confident I'm feeling.
Read more...
Posted in Musings, Computing, Smartphones | no comments | no trackbacks
Posted by marshall
Thu, 05 Jun 2008 22:48:00 GMT
TUAW is saying that WWDC next week will bring a build of Mac OS X 10.6, which "will not include any new significant features from 10.5; instead, Apple is focusing solely on 'stability and security.'"
Daring Fireball notes that the name for this release is rumored to be "Snow Leopard", and follows up with this comment:
"If you’ve ever wished that Apple would spend more time focusing on making existing parts of the OS work better rather than adding new features, this is going to be the release for you."
Count me in among those who have wished for something like this.
Read more...
Posted in Musings, Computing, Smartphones | no comments | no trackbacks
Posted by marshall
Sun, 25 May 2008 03:54:00 GMT
A few days ago, John Gruber posted a Perl script that he uses for converting text to title case on the excellent Daring Fireball site. Shortly thereafter, Dan Benjamin of RailsMachine voiced my immediate thought: "We need this rewritten in Ruby."
Ruby includes a capitalize method for String objects, but it simply uppercases the first letter and then downcases everything else -- not helpful at all. Rails adds a titleize method that gets a bit closer, but it's one of the "non-clever" functions that Gruber mentions: it doesn't downcase small words like "of", it incorrectly handles words with embedded caps (e.g. "iTunes"), and it mangles contractions and possessives (e.g. "can't", "AT&T's"). Gruber's script, by contrast, works correctly with almost any input.
Knowing that Ruby's text processing features are largely influenced by Perl, and seeing that the script in question wasn't actually that long, I figured I'd give it a try. It turned out to be quite a straightforward port; the biggest hurdle was learning enough Perl to determine what the script was doing (it's one of those languages that I was intending to learn for a long time, but I lost the will once I came across Ruby). And once I'd gotten that far, it wasn't too difficult to work out a JavaScript version as well. Gruber very helpfully provided a list of edge cases for testing, so it was easy to tell when the new code was working properly.
With the Ruby and JavaScript versions finished, I probably should have stopped. But it was turning out to be a fun exercise, and I thought to myself, "what if I needed this in an iPhone app someday?" Well, that's more of a challenge. Gruber's script does all its work with regular expressions, and Cocoa does not have built-in regular expression support. Various people have come up with extensions to support them, such as RegexKit, but those require additional libraries, and I kind of wanted to keep it self-contained. Plus I figured it would be more of an interesting problem to solve with just the built-in objects, since I'd already done two versions that depended on regular expressions.
The result is an Objective-C category (VCTitleCase) that extends all NSString objects with a titlecaseString method to complement the existing lowercaseString and uppercaseString methods. It's implemented using NSScanner, and because it already has to parse out each word, it does almost everything in one pass rather than doing multiple find-and-replace steps.
All three versions are available on the Title Case Ports page.
Footnote: Of course, I was just one of many to respond to Benjamin's request: he later posted a list of 11 responses, with more in the comments. A couple of them took the next step and extended the Ruby String class to support title-casing. Unfortunately, quite a few seem to have missed the point -- or at least they didn't take the time to understand the problem. Many didn't properly handle contractions, small words at the end, or the special cases that Gruber's script took care of, such as "Q&A". It's particularly disappointing given that 1) the original script wasn't that long, 2) Gruber spelled out exactly what "clever" things he was trying to accomplish, and 3) a set of edge cases was provided for testing.
Posted in Computing | 1 comment | no trackbacks
Posted by marshall
Mon, 14 Apr 2008 19:49:00 GMT
They discontinued the Grilled Fiesta Burrito. It was perhaps the best burrito ever made (at least from a fast-food place), and now it's gone. The rest of the burritos at El Pollo Loco are lousy...nowhere near the same league.
It just depresses me to go there now. I've started steering people toward other options when they suggest it. Even thinking about it makes me sad.
I suppose I should have seen it coming. It seems that if I'm a fan of something, it's doomed to be removed from the menu. The Queso Live at On The Border. The Monte Cocoa and Strawberry Limone at Olive Garden. The Chocolate Espresso Crème Brûlée at El Torito Grill. All gone.
It's perhaps worse with the Grilled Fiesta Burrito, because El Pollo Loco was one of the southern California establishments I missed greatly after we moved to Idaho, solely because of that item. To finally come back to SoCal and find it missing was heartbreaking, in a things-that-shouldn't-bother-you-because-they're-so-trivial-yet-they-do-anyway kind of way.
Goodbye, El Pollo Loco. You tossed aside the Grilled Fiesta Burrito as though it were a bag of moldy tangerines, and I'm not your best friend anymore. So there.
Now I'm just waiting for Carl's Jr. to discontinue the Western Bacon Cheeseburger. (Although on a happy note, it seems that Hardee's will finally be getting all of the Carl's Jr. menu items this summer, so I can finally respect its use of the happy star logo.)
Posted in Gallimaufry | 1 comment | no trackbacks
Posted by marshall
Thu, 03 Apr 2008 20:54:00 GMT
Yesterday I had the misfortune of having to install Adobe Creative Suite 3 (Super Duper Web Ultimate Premium Extreme Edition...or something like that). It's not that I didn't want the products; it's that Adobe has crafted perhaps the worst out-of-the-box experience I have dealt with.
I was going to write up a whole article detailing its failures, but it turns out that Adobe is inflicting the same horrible system upon users of Photoshop Elements as well, and Jens Alfke has posted an excellent write-up of it here:
It doesn't cover some of the further annoyances, like how Adobe Help Viewer gets installed in /Applications even if you tell it to install somewhere else, and how multiple folders get created inside /Applications/Utilities even though you told it to install somewhere else, and how every single application in CS3 is put into a separate folder full of files like "JSBridge.bundle" and "libjflashgen.jnilib" (including apps you didn't know you were installing and couldn't turn off)...but some of those may be CS3-specific, I'm not sure.
From the comments on that page, it appears that the installer is the product of Blue Flavor, whose PR page for the installer goes on about how the installer is web standards compliant and AJAX-enabled.
What the...?!
It's a freaking installer! We're not talking about the latest Web 2.0 my-second-social-face app here. We're talking about a way of distributing software that already has a standard framework with a standard user experience on both Mac OS X and Windows.
And this is what happens whenever developers try to take shortcuts when creating cross-platform applications: their product sucks on all platforms. It's generally worse for the Mac, whose users have higher expectations, but it's bad for both.
This is why one of the best things I've heard recently is that Adobe's going to have to rewrite Photoshop CS5 in Cocoa to get 64-bit support. By dropping 64-bit support for Carbon, Apple has forced Adobe to finally update Photoshop to a modern codebase, instead of maintaining the lousy OS9-based UI it's been limping along with for years.
This wouldn't necessarily give me as much hope (if anyone can screw up a Cocoa-based UI, it'll be Adobe) if I didn't keep hearing positive things about Lightroom. It's Cocoa-based, and apparently it feels much more at home on Mac OS X than other Adobe products -- right down to the installer. I'm at least encouraged by the feature tour on Adobe's site: the dialogs actually use Aqua group boxes (the sunken style introduced in Panther), which, when compared with CS3, is a major accomplishment for Adobe. Hopefully the improved quality of Lightroom will become the norm rather than the exception.
(And no, I'm not saying that Carbon cannot be used to produce great apps. It's just that virtually all of the apps that I've used that feel out-of-place on Mac OS X are from developers who are depending on Carbon to keep around old UI code written for a completely different operating system. The developers who really "get" Mac OS X are all using Cocoa. Plus Cocoa provides a base set of "free" functionality that, because it takes extra work, rarely shows up in Carbon apps.)
Posted in Computing | no comments | no trackbacks
