This flaw should never have crept into the code base; it’s an elementary SQL injection attack. And once in the code base, it should have been caught by review. But it didn’t get caught, and the WordPress team sat on the fix for nearly a month before advising people to upgrade; during just over two of those weeks an exploit was widely disseminated.
If I had one wish going forward into next year, it’s this: Please, Apple, document and support the iPhoto plugin API. It’s been stable for about as long as it has existed—FlickrExport actually works back to iPhoto 2—so it’s not as if it’s experimental or unproven code that might have to be incompatibly re-implemented in the future. There’s a market for third-party plugins out there, Apple, please put it on a formal footing so that we can confidently rely on that API.
Because this year’s WWDC was largely a repeat of last year, I spent more time in the introductory AppleScript, Automator and Cocoa Scripting sessions than I normally would. I left these sessions with the impression that developing a scripting interface was a difficult and error prone exercise. The Q&A questions at the end of these sessions confirmed for me that the audience was not clear on how to proceed. Everything that was said in these presentations was technically accurate, but I came away uninspired.
Unlike with a user interface, it can be hard to fix a scripting interface because you have to worry about breaking existing scripts.
The Guardian interviews SQLite’s creator:
In a world of people obsessed by turning the tiniest idea into something profitable, Dr Richard Hipp’s best-known software stands out for two reasons—he actively disclaims copyright in it; and at a time when multi-megabyte installations are booming, he has a self-imposed limit on the size of his product: 250KB. And he’s stuck to both aims. “I think we’ve got 15 kilobytes of spare space,” he says of the headroom left in the code.
Maybe a year and a half ago (not coincidentally around the time I started working for Google, which gave me more time for work on Python than I had had in a long time) I decided it was time to start designing and planning Python 3000 for real. Together with the Python developer and user community I came up with a Plan. We created a new series of PEPs (Python Enhancement Proposals) whose numbers started with 3000. There was a PEP 3000 already, maintained by others in the community, which was mostly a laundry list of ideas that had been brought up as suitable for implementation in Python 3000. This was renamed to PEP 3100; PEP 3000 became the document describing the philosophy and schedule of the project.
Lots of good stuff, and the schedule seems realistic.
OmniFocus uses compressed XML transaction files to store its data, with a SQL cache for efficient access. (Each time you update the application, we rebuild the SQL cache to ensure that it’s consistent with the latest schema.)
This clever design lets OmniFocus store its data in a text-based format while also providing good performance and mitigating the rigidity of SQL storage for an evolving application. I’m currently trying out OmniFocus as a replacement for OmniOutliner Pro for managing my software projects. Despite the fact that I’m not into GTD, OmniFocus seems to be a good fit. It automates much of the work that I did manually in OmniOutliner, moving items around to view them in different ways. It supports multiple windows and hoisting, and the filtering options are much better suited to my purposes than OmniOutliner’s. Most importantly, OmniFocus doesn’t do too much. It’s nothing like OmniPlan, which goes way behind my needs. It’s more like a version of OmniOutliner that’s optimized for tasks.
Update (2013-08-13): In an old blog post, Tim Wood describes this in more detail.
The MBA folks I’ve met who are interested in the tech sector tend to fit into two groups — those that think feature checklists are the be-all and end-all and those that think you need to truly understand what the customers want. Furthermore, party membership doesn’t seem particularly driven by level of technical skill. Some tech-savvy MBAs want solutions with every bell and whistle while others believe that their level of tech-savviness takes them outside of the main market segment.
Walt Mossberg: So the two of you have certainly–you’re involved every day with the Internet, you have Internet products, you have a whole slew of stuff on the Internet, you have iTunes and “.Mac” and all of that, but on another level, you’re the guys who represent the rich client, the personal computer, the, you know, big operating system and all that. And there is a certain school of thought–and I’m sure it’s shared by some people in the room–that this is all migrating to the cloud and you’ll need a fairly light piece of hardware that won’t have to have all that investment, all the kind of stuff you guys have done throughout your careers.
Steve Jobs: I’ll give you a concrete example. I love Google Maps, use it on my computer, you know, in a browser. But when we were doing the iPhone, we thought, wouldn’t it be great to have maps on the iPhone? And so we called up Google and they’d done a few client apps in Java on some phones and they had an API that we worked with them a little on. And we ended up writing a client app for those APIs. They would provide the back-end service. And the app we were able to write, since we’re pretty reasonable at writing apps, blows away any Google Maps client. Just blows it away. Same set of data coming off the server, but the experience you have using it is unbelievable. It’s way better than the computer. And just in a completely different league than what they’d put on phones before.
And, you know, that client is the result of a lot of technology on the client, that client application. So when we show it to them, they’re just blown away by how good it is. And you can’t do that stuff in a browser.
I do have one last thing.…What about developers? [applause]…We've come up with a very sweet solution.…We've got an innovative new way to create applications for mobile devices. Really innovative.…The full Safari engine is inside of iPhone. It gives us tremendous capability.…You can write amazing Web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services.
In Leopard, take this a giant leap forward with 64-bit Carbon and Cocoa, all the way to your applications. You can have fully native 64-bit UI Carbon or Cocoa applications.
First implemented at the UNIX level in Tiger, Leopard brings complete 64-bit support to all of Mac OS X’s application frameworks. Using either the Carbon or Cocoa frameworks, you can create applications that can address extremely large data sets, up to 128TB using the current Intel-based CPUs.
In addition to the POSIX and math libraries supported in Tiger, Leopard enables developers to build complete 64-bit applications using the Cocoa, Quartz, OpenGL, and X11 GUI frameworks. You can even use 64-bit Java on capable Intel processors.
The omission is not an accident. All of my applications are Cocoa, but they use bits of Carbon to do things that aren’t possible with pure Cocoa.
The advantage of Microsoft’s method is that it works better for on-screen reading. Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that’s comfortable to read is more important than the typeface designer’s idea of how light or dark an entire block of text should feel. Indeed Microsoft actually designed font faces for on-screen reading, like Georgia and Verdana, around the pixel boundaries; these are beautiful on screen but don’t have much character in print.
The transparent menu bar is insane. If you had asked me a couple years ago whether this or the gratuitous Dock reflections were Leopard or Vista features, I would have guessed Vista.
Not that there’s anything wrong with Cover Flow (though I won’t use it myself), but it’s not what the Finder needed. The Finder isn’t fixed; it looks to me like a minor update, though opinions differ. That said, the new Finder’s appearance is much better than brushed metal, and Quick Look (the framework more than its use in the Finder) is a great enhancement that’s long overdue.
I’m not at all surprised that there’s no iPhone SDK. I think that Apple has always planned to eventually open up development of real iPhone applications, but it was unrealistic to expect this right away. And it’s in everyone’s interest for them to take their time and get it right. It’s unfortunate, however, that Steve Jobs has been so deceptive on this point. The Apple Product Cycle is familiar enough by now that I don’t think anyone really believes what Jobs says. And, more importantly, it’s insulting to portray some browser hooks as an SDK for writing true iPhone applications. The iPhone Web applications aren’t even at the level of Dashboard widgets, and Apple certainly isn’t using them to write the iPhone’s Finder. I’d have been happier if Jobs had simply said that having a real Web browser means access to real Web applications.
Safari 3 is very nice, but unfortunately the beta requires an installer, completely replaces Safari 2, and even requires a reboot. For shame!
Safari for Windows, apparently the highlight of the keynote, is interesting in that it doesn’t use Windows controls. It even renders fonts the OS X way. Lots of low-level Mac frameworks are built-in, and even the RSS support was completely rewritten to be portable. I don’t expect Safari on Windows to win many converts, but it should help make more Web sites compatible with Safari on Macs and iPhones.
As expected, Apple isn’t competing with Parallels and VMware, but they are making Boot Camp switching a little less painful. Keeping in mind the Apple Product Cycle, I expect this to change in 10.6 or 10.7.
Overall, it was a disappointing keynote. I didn’t expect the top secret features to materialize, but it’s still a let-down after Job’s hype last year and all of Apple’s Microsoft bashing since then. And there was no new hardware. (So much for Apple moving that from the summer Macworld to WWDC.) I hope no one took Fake Steve’s advice to buy AAPL, because right now it’s down since that time, closing down 3.45% for the day while Creative was up 3.91% (though it’s still way down from its pre-iPod heyday).
Like the keynote, I think Leopard looks underwhelming for end users. However, as a developer I’m very excited about it. There are numerous under-the-hood changes that will make for better applications that run faster and that can be developed more quickly. Developers will get hammered with this message throughout the conference, but thanks to the keynote it isn’t what most people will be discussing.
Third-party opportunity: write a little utility that changes the top of an image file so that when it’s used as a desktop picture in Leopard the menu bar doesn’t look transparent.
I’m a Cocoa programmer, so I use Xcode all the time. Sometimes I wonder if I don’t really like it, or if it’s just like that I don’t like IDEs. Programmers are intelligent people and sophisticated computers users, so you’d think that they would be more productive and happier with a literate interface instead of all this heavyweight point-and-click madness. You’d think they would demand it.
I don’t like working in Xcode, either, and yet there’s no doubt that Xcode 2.4 is much better than previous versions of Xcode, Project Builder, and ProjectBuilder. And, from what I can remember, I mostly like it better than CodeWarrior, Visual Studio, Symantec, and THINK C.
I don’t really know what to “demand” to make Xcode better. It just doesn’t feel right, and I think Brent is correct that the problem is that it isn’t linguistic enough. So I’ve opted out of it. Rather than use Xcode as an IDE, I use it as a build engine, controlled via make from either BBEdit or Terminal. When I need a debugger, I tend to just fire up gdb by itself. What I’d like from Xcode is more hooks so that external editors can leverage its symbol index and display build errors.
NetNewsWire 3 is out! I’m really looking forward to the performance enhancements. I like the feed cover art and the ability to hide read items.
Update: I was skeptical about the new tabs, but it turns out that I really like them. I miss the old toolbar buttons, though.
I’ve been critical of Apple’s advertising in the past, but I agree with John Gruber that the iPhone ads are very good. There’s so much information in them that people like me will want to pause to look at the details of the interface, yet the overall impression is of a product with a clean interface that’s effortless to use.
Best of all, the experience isn’t just short on screen taps, it’s high on obviousness. It seems obvious that anyone who can use an iPod or a PC ought to be able to figure out on their own how to use iPhone. The fundamental trick to learn is the magic home button.
After a successful fund-raising two-years ago, Seth Dillingham is again looking for software developers to donate their wares to be auctioned off for cancer research and treatment. I’m happy to contribute my three applications to the auction, and I thank Seth for doing the work to make this happen.
The June issue of ATPM is out:
The just-announced Pixelmator is a new image editor that leverages Core Image and various other Mac OS X technologies (via John Gruber). I’m not crazy about the HUD-heavy interface, but on the other hand GraphicConverter’s dialog boxes look ancient and Photoshop Elements has an increasingly Windowsy interface with frustrating window management. I’ve been using GraphicConverter for the last few weeks and, once I got my mind out of Photoshop mode, it was pleasant to use. I’d forgotten about this gem for too long. I have no idea whether Pixelmator will tempt me, but what’s clear is that unless Adobe updates Photoshop Elements to make it universal they will have lost me as a customer. I only do occasional graphics work, so there’s no way that I’d pay $550 to update to Photoshop CS3 when its only advantage for me compared to Elements is not being really slow.
Frankly, they look really great up front, and there’s nothing wrong with the idea. I completely agree that checked exceptions are a wonderful feature. It’s just that particular implementations can be problematic. By implementing checked exceptions the way it’s done in Java, for example, I think you just take one set of problems and trade them for another set of problems. In the end it’s not clear to me that you actually make life any easier. You just make it different.
