Tuesday, October 25, 2011
(via John Gruber
A photo comparison from all iPhone version cameras (first generation iPhone, iPhone 3G, iPhone 3GS, iPhone 4, the new iPhone 4S), a point-and-shoot camera, the Canon S95 ($500), and a professional dSLR, the Canon 5DMKII ($4000+) in two situations: 1. A macro setting to test detail and quality of the cameras; 2. A backlit skyline shot.
My main camera has been a Canon PowerShot S90. It’s been encouraging to see that in some cases, particularly those where HDR is beneficial, the iPhone 4S takes better photos. It’s also frustrating, because now I have to think about which to use.
Update (2011-11-07): The low-light follow-up.
October has been a sad month for developers: Steve Jobs, Dennis Ritchie (co-creator of C), and now the creator of Lisp. This xkcd seems apt.
As the inventor of Lisp, the world’s second-oldest programming language, and coiner of the phrase “artificial intelligence”, it’s fair to say that (aside from Turing) there’s nobody whose contributions to computer science have had a bigger impact on my life.
Paul Graham (in 2008):
In 1958 these ideas were anything but obvious. In 1958 there seem to have been two ways of thinking about programming. Some people thought of it as math, and proved things about Turing Machines. Others thought of it as a way to get things done, and designed languages all too influenced by the technology of the day. McCarthy alone bridged the gap. He designed a language that was math. But designed is not really the word; discovered is more like it.
I wish every product had a spokesperson and ego behind it like the Kindle and iPad do. Take Flickr for example. It’s way ahead of all the other Internet photo apps. But its egos, Stewart and Caterina, left years ago. Since then it’s drifted on with a little of the momentum they left with it. And even so, it’s way ahead of all the other photo apps, as a platform. And that’s proving to be really important.
But Google Reader has just changed, and some syncing RSS readers will lose some features, and I take that as a reminder that it could change in a way that breaks syncing, and Google would not have broken any official APIs.
I’m not an RSS reader developer any more. But if I were, I’d start looking for an alternative syncing system right now.
I wish that NetNewsWire hadn’t switched to using Google Reader for syncing in the first place. The Google syncing of the read and flagged status was unreliable for me. Plus, it seemed to delay receiving new items (compared with downloading the feeds directly), and I would sometimes completely lose unread content if the author later deleted or revised the item. Plus, I’d prefer to put this data on another server, rather than entrusting it to Google.
Update (2011-10-25): Of course, that’s not as easy as it sounds.
Today I broke down and just wrote a little NSView subclass that draws an example of all compositing operations. Feel free to download this image and print it out or whatever for future reference.
Friday, October 21, 2011
Version 1 adds support for apps that can only read or write to a single folder in your Dropbox. You can rename or move this App Folder wherever you want in your Dropbox, and the app will keep working normally.
Developers can now build search and sharing right into their apps. Version 1 also exposes the full power of the Dropbox revision system. This includes undeleting files, reverting files to past versions, and not overwriting changes when two people update a file at the same time.
Sounds good. It’ll be interesting to see how Dropbox and iCloud evolve. Right now, it seems to me that the main weakness of Dropbox is that there’s no API call to get the sync status of a file or folder.
Wednesday, October 19, 2011
Tower, my primary Git client, now has views for file history and blame. I’m not really a fan of the popovers, though. Next up, I’d like to see searching of file contents.
How could big tech companies offer cloud services to hundreds of millions of people without better guarding their data against catastrophic loss? On Google’s side, one explanation involved complexities of the law. My wife and I might think that Google had a “duty” to be able to find her messages after some hacker had erased them. But according to Google’s legal department, its higher and more stringent duty is to ensure that messages are erased, if whoever is in charge of an account wants them gone.
If you don’t back up your own files, the cloud is probably safer storage than your hard drive. But if you do, Apple and Google’s cloud technologies take away your control without really offering the kind of professional management that you might expect. When Fallows’ wife tried to restore the six years of e-mail that the hacker had deleted, Google’s automated systems only found four month’s worth and e-mailed to say, “We unfortunately will not be able to respond to any further emails on this case.”
It remains to be seen how iCloud will handle this sort of situation, but at first glance it seems to abstract away from files even more. Mail and iCal maintain local caches that theoretically could be re-imported if you had your own backups of them. But there’s no folder on your hard drive that corresponds to the current contents of your Photo Stream, and the only thing you can do from the Web interface is to completely erase it. (If you regularly import the Photo Stream into Aperture or iPhoto, you could back up those applications’ files.) iWork documents currently don’t sync down to your Mac at all. The general iCloud document approach seems to be to make it appear as though there are no files.
Not having files makes some things easier on the surface, so long as everything is working perfectly. But the lack of tools to do the sorts of things that we do with files creates other problems. If something gets messed up in your cloud, you can’t just go in and fix it. And good luck getting someone at Google to help you.
Dropbox, on the other hand, seems to have hit a sort of pragmatic sweet spot. It’s less ambitious, in a way, but it doesn’t take away your favorite tools. My Mac always has a full copy of everything, in a normal folder that I can back up, search, re-arrange, etc. Multiple iPhone text editors can share the same folder with BBEdit. Nothing is locked away in a silo, only accessible through a specialized client application. Everything is viewable and editable from the Web site.
iCloud offers some syncing services for Core Data, which Dropbox cannot match (without a lot of custom work). But for regular documents, compared with Dropbox, it does not seem to offer me any benefits as a user. The details are hidden, At Ease–style. I suppose to Apple that’s a feature, but I hope that the applications I use will continue to support more open approaches such as Dropbox.
Update (2011-10-25): Ted Landau on Losing iWork documents in iCloud.
Researchers at Georgia Tech and MIT have developed a proof of concept to demonstrate that it is possible to record a computer user’s keystrokes using an iPhone 4’s accelerometer. The researchers developed a method to accurately translate the vibrations from typing on a keyboard picked up by the device’s accelerometer when placed on a desk near a PC.
As the loop executes, the “if” becomes like a giant if/elif/elif ladder: each time around the loop adds another test of the condition, but only if all previous tests were false. The “else” clause caps it all off, just as it would in an explicit if/elif/else structure. And it works just like the explicit structure: if all of the conditions are false, then the “else” clause is run.
Even though I understand the problem this is trying to solve, I have never found it intuitive. I still have to think when reading or writing one of these loops. It just doesn’t seem worth it for such a small gain.
Jim Rhoades (via Erik Barzeski) lists some spacing, punctuation, and capitalization voice commands that Siri recognizes. I’ve yet to figure out how to escape these, when I want the literal word. Maybe it will improve with practice, but my early impression is that dictation is not very useful for entering notes. Between mistaken homophones and regular mistakes and the times when it does nothing at all, it’s less frustrating to just type. It’s potentially more useful when you really want to avoid typing, e.g. while driving, although it’s not accurate enough that I feel like I could avoid looking at the screen to check that it got something close to right.
Monday, October 17, 2011
Joseph Linaschke reports that photo edits made on the iPhone are non-destructive. The photo imports into Aperture as the original image, with the edits translated to Aperture adjustments. This is awesome. I’ve found, though, that Aperture often doesn’t update its Photo Stream unless I turn it off and then on again in the preferences.
Sunday, October 16, 2011
Brendan Gregg and Joyent:
Applications can become slow or unresponsive while waiting for CPU work, memory requests or disk I/O to complete. Standard performance analysis tools like Activity Monitor and top(1) (and any third-party tools based on the same foundation) can’t tell you some key information about activity on your system, such as how much CPU consumption is caused by short-lived processes, or which processes are causing disk I/O. DTrace, however, can see (just about) everything.
Thursday, October 13, 2011
There’s no longer anywhere to store files that don’t need to be backed up (or can’t be, by the new policy) but shouldn’t be randomly deleted. This is problematic for lots of apps[…]
It’s hard to believe that there was a time when any of these weren’t conventional wisdom, but there was such a time. Unix combines more obvious-in-retrospect engineering design choices than anything else I’ve seen or am likely to see in my lifetime.
Not to take anything away from Ritchie, but Unix got so much right and was so successful that it created a bit of a monoculture, with even some of the bad ideas becoming conventional wisdom.
Herb Sutter (via John Gruber):
Bjarne Stroustrup made an eloquent point about the importance of Ritchie’s contributions to our field: “They said it couldn’t be done, and he did it.”
Update (2011-10-16): More from Lambda.
If you type with your thumbs while holding an iPad in both hands, or if you want take the new Show/Hide keyboard button out for a spin, check out the new Split Keyboard feature. To begin parting the Red Sea, drag using your thumbs outward from the middle of the keyboard to split the sections. To put the keyboard together again, put a thumb on each section and push them together.
This is one of the best features in iOS 5, but I don’t understand why there’s a preference and you have to specifically split the keyboard with a gesture. What would be the benefit in switching off the preference?
In Mail on the iPad, in portrait view, swipe left to right with two fingers to display the mailbox list, which slides as a panel from the side of the screen.
I don’t know why the list doesn’t appear as a popover, as it used to — perhaps Mail will become the iTunes of the iPad: the place where Apple experiments with interface.
It’s be nice to see some guidelines and consistency, but I like the sliding panel. Popovers seem better suited to tools and inspectors than to navigation.
Business Week’s profile of Scott Forstall (via John Gruber):
Before the introduction of the iPhone, Forstall supported Jobs’s view that Apple didn’t need to create an ecosystem of third-party developers. Back then they figured the device would stand out for combining a phone with an iPod plus a superfast browser. For the most popular activities—watching YouTube videos, for example—Forstall’s team would simply partner with market leaders such as Google (GOOG) to create apps built specifically for the iPhone.
I’ve long assumed that Apple always intended to create an iPhone SDK, but that they didn’t talk about it in 2007 because it wasn’t ready yet. The line about changing their mind and opening it up due to feedback from customers and developers was just rhetoric. Supporting this theory is that Apple emphasized to developers that it was built on Cocoa and other frameworks that they were familiar with. And, secondly, that it was blindingly obvious even then that iPhone OS would be a great app platform and that this would benefit Apple. But what if that really wasn’t the plan?
My real worry is that programs like those will stop being made. My secondary worry is that more and more features of the OS will require being a signed application by Apple. i.e. only work from the MAS. Consider iCloud. It’s completely understandable why Apple may wish to have applications go through the approval process to use iCloud. (Apple apparently hasn’t decided on policy here yet – at least not in any official statement) Suddenly that means that no application can send arbitrary Applescript and access iCloud. I think it is safe to say that more and more features may start requiring the limits that the app store imposes.
John Gruber also notes the uncertainty:
My gut feeling/semi-informed hunch is that yes, it will be restricted to App Store apps, so that Apple can approve all iCloud storage use cases in advance, and easily pull the plug on any app that proves to be abusive in the wild. Put another way, my bet is that if your app isn’t signed by Apple, it won’t be able to write to an iCloud container.
iCloud and the application sandbox were probably the two biggest Mac announcements at WWDC in June. Now they’re deployed on customers’ Macs, and Apple still hasn’t clarified the policies for using them.
Wednesday, October 12, 2011
The best sign I can think of regarding Siri’s practical utility: after a week of using this test iPhone 4S, yesterday, while using my regular iPhone 4, without thinking I held down the home button to create a new reminder for myself, and when the old Voice Control interface appeared, my mind went blank for a few seconds while I pondered what went wrong. I missed Siri already.
Siri demos well, but these things never seem to live up to expectations. It’s encouraging that reviewers seem to be finding it useful in the real world.
The number one thing I’d want to do with Siri is create new tasks in OmniFocus. So far it only works with the built-in Apple apps, though.
And, more broadly, it’s heavily tied into the OS. On the Mac, there have been various third-party dictation and voice control products that could pretty much do what they wanted. They went way beyond the OS’s built-in speech recognition features. On iOS, only Apple is allowed to try to make something with the scope of Siri. So you’ve got to hope that Apple has the best voice recognition engine, the best AI, and a plan for future improvement and extensibility. You can’t replace or adjust any of these components except by switching to different hardware and a different OS. Of course, it looks like Apple is currently in the lead, so to most this will not seem like a pressing concern.
That one last thing that Google doesn’t do well is Platforms. We don’t understand platforms. We don’t ”get” platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.
Update (2011-10-21): Yegge’s follow-up (via Hacker News).
Monday, October 10, 2011
Wednesday, October 5, 2011
BBEdit 10.1 is a terrific update, just a few months after BBEdit 10. The “Open File by Name” command has at last gotten a major improvement: it shows the list of matching files as you type. (There’s also some cleverness as to what you can type; see the release notes.) I’ve used similar features in Emacs, TextMate, and Xcode, and it’s hard to overstate how useful this is. I had been using LaunchBar with sub-searches for particular folders to quickly open files in BBEdit. Now I can simply use BBEdit projects.
Additionally: Unix filter scripts now operate on stdin rather than on a temporary file passed as an argument, and the new markup pop-over operates much more smoothly.
Tuesday, October 4, 2011
Monday, October 3, 2011
Growl 1.3 is now available, exclusively from the Mac App Store. I like the new history feature, and I’m happy to send the developers the $2. The Mac App Store necessitated the switch from a preference pane to an application, which is fine, but it also requires a compulsory menu bar icon. I’d prefer to avoid that clutter. The installation process was glitchy, even though I’d manually deleted the old version of Growl before purchasing. The App Store application kept telling me that Growl was installing, though it wasn’t, and it either didn’t appear in the Purchased list at all or did appear but with a titleless button. I kept quitting App Store, going back to the Growl page, and re-buying, and eventually it did install the application.
Sunday, October 2, 2011
It took me a few weeks to realize something: the whole point of sandboxing is to isolate all of the processes running in your system, and prevent any one of them from interacting in any way with any other process. Annnnd… controlling all of the apps and functions on your Mac is the whole point of Mac OS X’s automation features.
Can AppleScript and Automator have any future on an operating system where every app is surrounded by an impenetrable steel shell of distrust?
That question is seeming more and more rhetorical.
Recently I had an idea for a tool that would make my life much easier and it required some scripting of the Preview app. In all my years of avid scripting, I’ve never done anything with that app before and so it came as a surprise when I tried to open its dictionary with the AppleScript editor and I discovered that it had none.
This has long struck me as a strange omission. Preview could be an example of how great Mac OS X scripting is, but it doesn’t even support the most basic AppleScript features that are built into the Cocoa frameworks. (There’s a way to enable the default window and document scripting support, if you don’t mind replacing Apple’s code signature with yours.) The excellent PDFpen is scriptable, but Preview does lots more than handle PDFs.
Not only does this approach risk turning the Mac App Store into a wasteland of arcade games and one-trick-pony apps, it risks dumbing down the Mac app ecosystem as a whole. While developers can always opt out of the Mac App Store, they’re reluctant to do so. Not only are they afraid that Apple will one day make new Macs unable to run apps that don’t come from the App Store, but they realize that if their competitors are in the Mac App Store, they risk losing sales. It’s generally too expensive to develop two separate versions of an app, so the net result of tighter App Store restrictions could be that Mac apps everywhere—on and off the store—will actually become less powerful.
Not widely discussed so far is the huge gulf between the theory of the sandbox and the reality. It would be great to be able to buy a utility like SuperDuper from the Mac App Store, but we all understand why that doesn’t fit Apple’s rules. Yet there is also a large class of applications that are well-behaved and could fit in with the idea of what the sandbox is trying to accomplish, but that fall victim to bugs and limitations of the current sandbox implementation. Apple has in recent history done a good job of dogfooding and providing for gradual transitions. The app sandbox is a notable exception. Not only is it not ready for prime time, but the mechanics of the transition remain a secret. We’re now less than a month from November. Many developers have in good faith tried to adopt sandboxing, filed bugs, and there has been virtually no response.
It’s not even a question of opting out. What happens if an application that’s already in the Mac App Store can’t be sandboxed? People have already bought it, and they expect fixes and updates. Apple changed the rules, but developers will get the fallout.