Saturday, June 6th 2009
http://daringfireball.net/2009/06/palm_saturday
The iPhone was introduced at Macworld Expo on 9 January 2007. On that day, Palm Inc. was screwed.
Sunday, May 31st 2009
http://www.whereiwrite.org/
Photos of science fiction authors and their creative spaces.
Friday, May 29th 2009
BoyGeniusReport and Engadget (sourcing Pre Central) are both reporting that:
the Pre will, in fact have IMAP IDLE (AKA Push) Gmail capabilities,
Let’s get one thing straight: IDLE is not Push
IMAP has been around for awhile, and so has the IDLE extension. This allows you to login to your IMAP account and remained logged in while idling, and notifications of new mail are sent to the client. Note that this does not push the mail out itself, just the header, with message marked as new so the client can then download the mail when initiated by the user. I use IMAP with IDLE support on my mail server, and it is fantastic, yes, but it’s not “Push” mail. What Apple and the entire rest of the world mean when they say Push mail is that the entire message is delivered to the client instantly after the server receives it. Push requires more bandwidth, a bit more CPU usage, but most importantly a protocol that is not IMAP.
In my research there are only a small number of ways to achieve Push mail. Microsoft Exchange does it, and while I don’t know what Yahoo Mail is doing or what Apple is using for MobileMe Push, it’s more akin to what Exchange is doing at the protocol level and definitely not IMAP IDLE. There is also some Java based Push mail server implementation available from Sun, but as far as I know it is not open source, or even free of charge. To my best knowledge there is currently no open standard for pushing mail. Believe me, I’d love it if there was and I would be the first person installing “GNU FreePush” or somesuch on my personal Linux mail server if anything existed. But for now, IMAP IDLE is poor man’s Push until there is such a standard. In my crazy imagination, Apple is currently using a homebrew Push protocol and server and they’ll release the source along with Snow Leopard Server.
Friday, May 29th 2009
Rejecting all of them, consistently, would in fact be no good at all. The feeling of being part of the monolith — of being the monolith — really only surges when I use my position to act capriciously.
To act fairly would be to follow the rules. To act capriciously is to be the rules.
Damn, I love John Gruber.
Wednesday, May 20th 2009
I had thought that Apple’s three-pronged, open answer to Exchange was going to be IMAP+CalDAV+LDAP, but today I learned about [v]CardDAV. It’s an IETF draft spec that combines WebDAV and ACLs to create a vCard server, much in the way they are combined to create CalDAV. Major contributions to the RFC come from Apple, but as yet there’s not really any implementation available yet.
Apple is openly advertising CardDAV server on their Snow Leopard Server info page, so the commitment is real. But it remains to be seen if it will be implemented in the same open source, friendly way as Apple’s CalendarServer.
Great news, especially since LDAP sucks for shared address books.
Wednesday, May 20th 2009
http://www.demon.cx/icaldavmerge/
Thoughtful script from JJ Spreij to get a list of CalendarServer users and generate single, monolithic webcal feeds for the user’s entire calendar. Mine’s at webcal://calendar.airwaterunix.org
Sunday, May 17th 2009
http://www.time.com/time/specials/packages/completelist/0,29569,1898610,00.html
1. Vista
7. Zune
Ouch.
But the list is suspect, because 5 is YouTube, which aside from the user comments I don’t think anyone could argue is a failure.
Sunday, May 17th 2009
http://news.cnet.com/8301-13846_3-10242526-62.html
“I’m a guy who doesn’t see anything good having come from the Internet…(The Internet) created this notion that anyone can have whatever they want at any given time. It’s as if the stores on Madison Avenue were open 24 hours a day. They feel entitled. They say, ‘Give it to me now,’ and if you don’t give it to them for free, they’ll steal it.”
Sunday, May 17th 2009
http://furbo.org/2009/04/30/matt-gallagher-deserves-a-medal/
There are some people who think that settings should only be in the Settings app. There are others that think they should only be within the application. I can honestly see how both groups are right, but what both sides fail to realize is that it’s often a matter of context.
If you’re working on a simple application with simple needs, relying on the infrastructure provided by the SDK is fine. You may have some additional support load for users who have problems finding your settings, but that’s a reasonable tradeoff for saving development time. Sophia Teutschler’s Groceries app is a fine example of where the built-in settings shine: I turned off the Marker Felt font several months ago, and I haven’t touched it since.
In the case of Twitterrific, there were three main reasons why we built the settings into the application:
We could not split the settings between two locations. From a user’s point-of-view, it’s incredibly confusing to have an application’s configuration in two places. This would have happened if we had put the account settings in the application and everything else in the Settings app.
Some of the settings are things that people will change on a fairly frequent basis. For example, the dark theme works best at night, while a light theme is better during the day. Leaving the app to make these types of adjustments is inconvenient.
The Settings app can’t handle preferences that are “dynamic.” An example is a vibration setting for the notification: there’s no way to make this appear on an iPhone but not on an iPod touch.
As we start to see more complex applications appearing on the App Store, I think there will be a lot of other developers coming to grips with settings in their applications