Steven Levy (via Jason Kottke):
The data people generate when they search—what results they click on, what words they replace in the query when they’re unsatisfied, how their queries match with their physical locations—turns out to be an invaluable resource in discovering new signals and improving the relevance of results.
But, still, in the end, the new version of the system was less code than the Core Data version. That will not be the case for most apps. I took it as further indication that this was the right move for this particular app.
I’ve run into these issues as well. I don’t think they’re that uncommon, unfortunately. One thing that Simmons didn’t mention is that all of these examples could be handled well in a future version of Core Data. That is, they’re not fundamentally incompatible with its design. (In fact, I think his #4 was addressed in Mac OS X 10.5, and 10.6 added some more database-type features.) Of course, this doesn’t help him now, but if you can possibly live with Core Data you probably shouldn’t bet against it. It will get better with time.
Update: Jonathan Rentzsch explains how this worked with Enterprise Objects Framework and how it might work with a future Core Data.
I learned that I much preferred pagination to scrolling—even tilt scrolling—and that pagination is part of what makes the Kindle reading experience so great. So I spent a long time experimenting with different methods to bring pagination to the iPhone, and I finally found a solution that, while simplistic, allows any mix of pagination and scrolling in the dynamic Web content that Instapaper is ideal for reading. I now prefer pagination to tilt scrolling. You can toggle between them with the Pagination switch in the Settings screen.
Also, an in-app browser replaces the graphical mode.
Hg Init, from Joel Spolsky, looks like a nice Mercurial and DVCS tutorial. (I’m still happy with Git, though.)
So what I see as hypocritical about Apple’s decision here is not about the fact that you can access the same sort of content via MobileSafari, but rather about the exceptions granted to Sports Illustrated, etc. I see why: Sports Illustrated, Victoria’s Secret, and Playboy are not just strong brands but also quality brands. But who’s to say some new brand couldn’t be just as good? The best apps in all sorts of categories across the board in the App Store are frequently from new companies, building new brands. It’s no more fair for the “hot chicks in bikinis” category to be occupied solely by existing major brands like Sports Illustrated/Victoria’s Secret/Playboy than it would be if the, say, photo manipulation category were occupied solely by Adobe and Corel, or if games were only allowed from companies like EA.
António Martins & João Reis (via Jonathan Rentzsch):
We’ve decided, therefore, to write this open letter exposing what we consider a misjudgment and huge discrimination, specially if you compare it with current Apple iTunes Store contents like L World, Californication, Sex and the City, Bikini Blast, Top 100 Models or Good Luck Chuck.
The handling of multiple changes is astonishingly good. Let’s say you crop photo_01 in the desktop library, and adjust exposure on photo_02 in the mobile library. Then let’s say in that mobile library, you add metadata to the same photo_01 file that was cropped in the desktop library. When you merge the libraries, everything is synced correctly—the desktop-cropped photo_01 will gain the metadata added to the same photo_01 in the mobile library; the exposure adjustment on photo_02 will be applied.
Unsure of its ability to successfully roll it out as an independent product, Google must have then decided to force feed Buzz through its Gmail user base of 175 million. Google executives likely reckoned that in a single day Buzz would garner more users than Twitter has been able to in two years after all that celebrity publicity. That really is why Gmail users woke up one day to find their private account details exposed to the public, unannounced and unprepared, because without such default exposure Google executives likely didn’t believe they could deliver a critical user base for Buzz. That’s not “improper testing,” it’s a platform strategy.
Every divisor has a magic number, and most have more than one! A magic number for d is nothing more than a precomputed quotient: a power of 2 divided by d and then rounded up. At runtime, we do the same thing, except backwards: multiply by this magic number and then divide by the power of 2, rounding down. The tricky part is finding a power big enough that the “rounding up” part doesn’t hurt anything. If we are lucky, a multiple of d will happen to be only slightly larger than a power of 2, so rounding up doesn’t change much and our magic number will fit in 32 bits. If we are unlucky, well, we can always fall back to a 33 bit number, which is almost as efficient.
On the whole, I’m very happy with the new features and interface improvements in Aperture 3. Many of the changes have been discussed elsewhere, however I wanted to mention a few points that I haven’t seen covered:
I’ve been putting off keywording people in my photos because I assumed that face detection was on the way. Now that it’s here, I’m not sure how much I’m going to use it.
In one of my projects, the faces were totally messed up. Aperture detected “faces” in solid-color areas near the corners of the photos, completely ignoring the prominent people in the middle of the frame. I manually added some faces, drawing rectangles and naming them, but Aperture forgot this as soon as I clicked on another photo in the browser. The only way I could get faces to work with this project was to delete the versions and re-import the masters. Luckily, these versions did not yet have any keywords or adjustments because they would have been discarded.
In my other projects, at least the dozen or so that I’ve gone through since upgrading, the face detection seems to be working properly, pretty much like in iPhoto.
There was some confusion when multiple people had the same first name, or the same first and last name with different middle initials. Also, the Address Book integration didn’t quite work the way I expected. Now that I see how it works, I think it’s adequate, but I would rather that Aperture not get cute and try to abbreviate to ambiguous first names.
The “Unnamed Faces” strip doesn’t seem to offer a way to zoom out or jump to the original photo. As a result, there are some faces that I can’t identify because I can’t see enough context. I don’t want to click Skip, because then how do I get back that list of untagged faces? But if I don’t click Skip, it seems the strip will be forever filled with those same unnameable faces.
Aperture uses a sensible storage model (which I first saw in Mail and copied for EagleFiler) where an “index” database is used for speed but the data and metadata are stored in flat files and XML. If the database is deleted or damaged (or not backed up), the data and metadata remain intact, and the database can be reconstructed from the other files.
Unfortunately, this does not seem to be true for faces. It looks as though Aperture stores the face information in the Faces.db SQLite database but that it does not save it in the XML files along with the other metadata. (It does export faces as keywords in the JPEG files, but that’s not particularly helpful when reconstructing a library.) This makes me wary of spending lots of time tagging faces and possibly losing that work if there’s ever a problem with my Faces.db.
I’m considering using the face detection to aid in assigning keywords. However, there doesn’t seem to be an easy way to generate and assign keywords from faces (other than exporting) or to assign faces from keywords (if I were reconstructing a library where the face information had been backed up in that way). It’s a shame because, although Aperture has good support for keywords, the faces feature is better suited for tagging people (though, alas, faces don’t show up in the various metadata displays).
Aperture 1 and 2 used Core Data, but Aperture 3 seems to have dropped it in favor of using SQLite directly. As a user, this doesn’t particularly matter to me, but as a developer making heavy use of Core Data I wonder about the reasons for the change. It’s curious that Mail, iTunes, iPhoto, and Aperture are highly visible “database” applications, none of which use Core Data. Does Apple think that Core Data is the wrong kind of technology for these applications? Or are there limitations/flaws that make the dog food unpalatable? My hunch is that for what Mail needs to do it’s more efficient to use SQLite directly. However, Aperture seems like exactly the kind of application that Core Data was intended for.
The folder structure inside the library package has been improved so that Time Machine backups should be much more efficient, especially if you rearrange your projects and folders. The thumbnails are now excluded from Time Machine backups, as is the BigBlobs.apdb. Other large database files are included, however: Faces.db, History.apdb, ImageProxies.apdb, Library.apdb, and Properties.apdb. My guess is that, except for Faces.db, these could all be reconstructed, so I’m excluding them from my CrashPlan backups.
Even after face detection completed (and I rebooted), Aperture 3 seems slower and more RAM-hungry than ever. I’m using a 2009 MacBook Pro, maxed out with 4 GB of RAM, and my library has about 34,000 versions. Aperture 2 was sluggish at times but bearable. Aperture 3 often locks up itself—and the rest of my Mac—for seconds or minutes. I’m going to see whether DiskWarrior helps.
MoneyWell 1.5 is a nice update to the financial application that I’ve switched to from QuickBooks. I couldn’t be happier. Previous versions weren’t difficult to use, but 1.5 cleans up a bunch of interface issues that had been slightly bothering me, and it feels much smoother now. Although it’s marketed for budgeting and cash flow, MoneyWell works well as a simple tool for reconciling accounts and keeping track of categories for tax reporting. Unlike QuickBooks, it does not support invoicing, so I’m using Billable for that.
As you can see, the server doesn’t have to do that much. It stores some small bits of data with timestamps. I don’t think it needs any cron jobs (at least not conceptually) — it just responds to requests. It doesn’t even have any idea what this data is about.
You can think of the log file as a queue or message stream that’s being collaboratively read and written by all of the clients. This sounds like something you’d need a fancy web-app to manage, but it turns out that all it takes is a typical HTTP 1.1 server and a trivial server-side script.
It’d be nice to have an alternative to Google Reader.
Given the crappy copy and links in the message, after a quick scan, it’s not difficult to miss a key line or two and be left thinking you can hit reply and continue the conversation. After all, they originally asked me to e-mail them, they just replied to my mail, they ask me to “write back”, speak in the first person and they sign with a staff member’s name. I typed “Hi Scott, there must be some confusion. There is no another e-mail add—” before I noticed the “cannot accept incoming e-mail” line.
At this time, I suspect the closed nature of the App Store is not as worrying as it should be because it only concerns our smart phones. We can still develop anything we want for Macs, the “real” machines. However, what if the iPad starts to replace the Mac to such a degree that it no longer becomes profitable to write apps for the Mac? It seems that to be a Cocoa developer will eventually mean to have one’s business chained to the App Store. To be chained to the App Store means Apple makes the final decision on whether your apps can be sold the way you like them, or at all.
Webdesigner Depot (via Cathy Shive):
On February 10th, 2010, Photoshop turns twenty. To mark this anniversary, we’ve come up with an article that takes you through the evolution of Photoshop from its modest beginnings as a bundled program sold with scanners to its current version.
For each version and major feature listed, we couldn’t help but think “did Photoshop ever exist without that feature?”.
The February issue of ATPM is out:
