Archive for the ‘Mac OS X’ Category

iPhone Keychain Encryption Revealed

July 30, 2009

I just got the definitive word on the algorithm that the iPhone uses to encrypt Keychain items and it’s Triple-DES. I was flabbergasted that they didn’t go with AES since a) there’s hardware acceleration for AES-128 on the 3G and AES-256 on the 3GS; b) the Keychain APIs are wildly different from the Mac OS X ones; and c) Triple-DES has been deprecated for new secure applications for years now.

The Quest for Feed Bliss

July 18, 2009

I’ve recently switched to Google Reader for all of my feed reading needs. This is the latest iteration in a long line of trying to find the perfect feed reading experience. Here’s what “perfect” means to me in this context:

  • Readily available so that I can polish off a few items whenever I have a spare minute
  • Enables me to clear out a batch of unread items easily
  • Fast
  • Navigable by keyboard for faster reading
  • Native applications for whatever platform I’m on plus a Web application backend
  • Sync between work, home, and phone

I subscribe to 250 feeds presently so the primary consideration is staying on top of them. There is a real cognitive weight to having 1,593 unread items and I strongly dislike declaring “feed bankruptcy.” So I have spent the last few years testing different options.

For most of that time, Bloglines was my go-to solution. It was fast and fairly efficient. But I was never satisfied because it was Web-based, lacked decent keyboard navigation, and required an Internet connection to access at all. I tried Google Reader when it first came out but it left me cold. Since I spent my working life on a Windows XP machine, I resigned myself to a Web-based application.

Then I got a Mac at work and suddenly all of the great Mac OS X feed reading applications were available. I again tried all of the ones I had evaluated at home: NetNewsWire, NewsFire, Shrook, and some others that I can’t remember now. I settled on NetNewsWire because of the NewsGator syncing, the native iPhone application, and decent keyboard navigation. I still wasn’t completely happy with the set up because the NewsGator Web application is terrible: no keyboard navigation, slower than you’d think possible, and hard to mark items as read.

As I said earlier, Google Reader is my current solution and I think it’s going to stick this time. The Web application has matured substantially since I looked at it four years ago. It lacks a native Mac OS X application but I found a way around that earlier this week, which I chronicled in this Super User answer:

  1. Download Fluid.app.
  2. Save this PNG image (or this higher-resolution one) to your Desktop.
  3. Open Fluid.app and use the Google Reader URL, name, and newly-saved icon.
  4. Launch the Google Reader application from your Applications folder.
  5. Buy Byline or use the really good mobile version of Google Reader (you can save it to your Home screen to boot).

This setup is very fast, feels native (Fluid.app even displays the unread item count as a badge on the Dock icon), syncs between all environments, has great keyboard navigation, and is always available. I’ve gotten my total unread item count down to 8 and kept it in double digits for the last week, something I haven’t done since I started feed reading.

It’s refreshing to have that load off my mind.

Lessons of a First-Time WWDC Attendee

June 13, 2009

In the interest of contributing to the wealth of tips on WWDC, I’d like to share what I learned this week about the event itself—I can’t talk about the session material since it’s under a non-disclosure agreement.

  1. Don’t lose your badge. I didn’t, thankfully, but the attachment of the badge to the lanyard is very precarious. Everything—everything—revolves around that badge and there’s security everywhere. They will balk if they can’t see the full badge.
  2. There is no Apple-provided dinner except for the Bash. From the original Web site, it seemed like Apple would provide dinner daily, but that was emphatically not the case. The Bash food, incidentally, was excellent. I was stuffed from the sushi, hot dogs, pizza, Chinese, pasta, cookies, and quiescent confections.
  3. You can leave on Friday. I booked my return flight for Saturday morning thinking that sessions would run as normal on Friday and I didn’t want to rush around dealing with luggage and transportation to the airport. Turns out, the last session ended a little past 2 o’clock and they have a luggage holding station at Moscone West. I could have easily left that day. There’s a lot to see in San Francisco, of course, but I was ready to go home.
  4. Don’t miss Stump the Experts. I didn’t learn anything at all from the session but it was hilarious. This was the 20th Stump the Experts event and it made me feel nostalgic even though this was my first time attending.
  5. The labs run concurrently with the sessions. There were many great sessions that conflicted with one another, but most of the good labs also conflicted with those great sessions. The best bet, I found, was to skip a Q&A here and there to make use of the session interstitials. Even still, I missed several opportunities. If the videos came out in a timely manner, I’d say to only go to the sessions for the Q&A (or to ask your Qs at) and focus on the labs. You can watch the video at your leisure but you’re never going to get that kind of face time with an Apple engineer otherwise.
  6. The WiFi access was excellent. I consistently got five bars throughout Moscone West during the entire conference. I also was able to connect via VPN at will. I’m not sure why the online accounts I read had WiFi trouble in the past, but Apple appears to have gotten its act together.
  7. Complaining about the lines is an effective icebreaker. WWDC, for me, was a series of lines: lines for the sessions, lines for the labs, lines for the urinals, lines for the sinks, lines for the food. Witty observations about this led to many interesting conversations with line neighbors. Not that you need an icebreaker: I never had any trouble striking up a conversation with anyone and the bonhomie was palpable throughout.
  8. Use the elevator. There’s an elevator near the stairs that was almost never being used. If you’re on the third floor after a Presidio session and you want to go to a lab, your best bet is to skip the line for the escalators entirely and go straight for the elevators. I generally rode it alone; I have no idea why so few people took it.
  9. Plan on getting in line for the Keynote by 8 o’clock. I waited until 9 AM to mosey down to Moscone and the line had already wrapped around nearly back to the main entrance off Howard. By 9:45, we had barely moved. I ended up getting seated in the overflow room, which had quite a nice view of the Keynote, about 10:20 AM and missed the hardware announcements entirely.
  10. The Interface Design consultation is by appointment and they fill up quickly. I was planning on having an Apple engineer give my iPhone application a once-over, but I didn’t realize you had to reserve a spot so they were gone by the time I got down there. If I were doing it again, I would make this action my top priority.

Was WWDC worth it? Big time. It was hard being away from my family—video conferencing via iChat helped considerably—but I learned so much and got direct answers to my questions that I can recommend it without reservation. Plus, I got a developer’s preview of Snow Leopard that is wonderful. iPhone OS 3.0 and Snow Leopard are going to be great, people. Make sure you upgrade when they become available.

Redmond, Start Your Pricing Guns

June 11, 2009

One of the most exciting aspects of the WWDC keynote announcements was the pricing of Snow Leopard at $29 and a five-pack family pricing of $49. I’ve purchased every version of Mac OS X for $129 since the original 10.0 (except 10.1 obviously), only occasionally catching a break due to buying new Macintoshes.

Every version was worth it, mind you, but it still felt like an ongoing cost of owning a Mac. (I must here disclaim any sense of entitlement: I know that previous versions of Mac OS X continue to work after the new ones come out and I have taken that route for non-essential computers. This feeling arose from my inner cheapskate more than any sense of deserving something for nothing.) Every new version required a careful calculation of benefits and review of features for ancillary machines.

But I don’t have to think twice at a $29 (or $49) price point. On this point, David Pogue has it right. But his reasons for the pricing barely scratch the surface. I paraphrase his four listed reasons as follows:

  1. This release doesn’t have enough features to justify $129.
  2. They want to get this out to a lot of people.
  3. They want to embarrass Microsoft with this ridiculous value of the release.
  4. The lower the price, the likelihood that people won’t even blink at upgrading.

There’s a lot more to it than that, though. 10.6 requires an Intel machine. If you’ve got an Intel machine already, it’s likely that you’ve running 10.5 and that you’d gladly pay $29 to recover 6 GB of space much less for a slew of new features. If you’re running Tiger on an Intel machine, you have to shell out $169 for the Mac OS X Box Set. And if you’re not using an Intel machine, you cannot upgrade to 10.6 (and presumably any future releases either). So this release cycle effectively communicates to those still on Tiger or the PowerPC platform that their days of being supported by Apple are nearly over.

Finally, if 10.6 is truly laying the groundwork for future plans, then Apple has an interest in having as many developers making use of its new technologies as possible. But historically developers will not migrate to these new systems until a critical mass of users have made the move: supporting two disparate versions of a feature is expensive for small developers and they won’t do it unless there’s a absolutely compelling reason. Pricing 10.6 at this level will induce a substantial number of consumers to upgrade. On the iPhone, I can imagine that 3.0-only applications will come about soon because the upgrade friction is minimal there.

With a solid base of applications using 10.6 features, Apple can sell future hardware in a way that Microsoft-based vendors cannot. With the gigahertz arms race faded, hardware vendors are competing on multiple cores, multiple CPUs, and RAM. But consumers quickly discover that all of this extra hardware encounters diminishing returns on the software that they use—either the software can’t make use of memory above 4GB or these extra cores are mostly idle. 10.6’s promise is that it makes using these hardware features seamless to the developer through mechanisms like Grand Central Dispatch, OpenCL, and completing the transition to 64-bit.

These strike me as more substantive reasons for the pricing than Pogue’s facile ones. I believe 10.7 will resume the $129 price cycle as people catch up to the Intel/Leopard transition and Apple wants the third-party applications to be there waiting to sell the hardware’s value.

Bravo, David Friedman!

August 13, 2008

Today, a co-worker and I, both fans of the iPhone, were discussing how to do text selection and cut/paste operations. I’ll confess that I didn’t have much of anything to add to the conversation beyond being a good listener and carefully considering his ideas.

He had a pretty decent notion of using one finger as an anchor position while the other could drag around to set the other anchor. With our hands, you could cover the screen completely and even handle scrolling through longer documents. We weren’t really sure how to implement the cut/copy/paste side of the equation, but we guessed that an alert panel with applicable buttons would suffice.

After seeing David Friedman’s tweet about his take on the subject, I knew that he had nailed it perfectly. His solution is captivating in its simplicity and obviousness. If any Apple iPhone engineers are reading this and haven’t read his entry, get out of here right now. Also, hey, good job on the iPhone—can you pull some strings and get me in the beta program?

The iPhone as trackpad is just genius, sheer amazing genius.

Go Go Daddy Dashboard!

June 10, 2008

Screenshot of the widget

I just deployed my latest effort: the Official GoDaddy.com Domain Search Dashboard Widget. I know, it’s not a terribly catchy name but it’s quite descriptive. It’s a Dashboard widget for Mac OS X that enables you to check domain name availability. It’s certainly a variation on a common theme but what can I say? Domain registration is bread and butter.

This widget was a little different than the other ones I’ve done, however. It’s got all the visual flair attendant with Mac OS X, to be sure. The animation took forever to get just right and smooth. It also had to have an update mechanism since it doesn’t reside anywhere that we can control. The update process is fairly simple but so is the app itself.

It consumed a lot more time than you’d expect, but I enjoyed it. Well, except for some of the fighting with Dashcode. Oh and that issue I had all yesterday with the little loading spinner: that drove me nuts trying to pin down the cause. (Incidentally, in the open method of the XmlHttpRequest object, if you specify false for the asynchronous parameter, it will not run any code that updates the widget until the response comes back. But only in the Dashboard version of WebKit. Safari works just fine. It was a pain to track down.)

[The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy Software, Inc.]

Let’s See the Polished Draft Now

June 10, 2008

After reading Andy Ihnatko’s tweet about Apple’s announced solution to the lack of background processing on the iPhone, I realized that I had been taken in by Steve Job’s famous RDF. It sounded good to me while I was listening to it—I mean, except for the September release. But I didn’t think much about how little the single-source notifications addressed the problem it ostensibly solved until I read Hank Williams’ excellent analysis.

Basically, the single-source notification is good for handling incoming alerts that need to be displayed to the user in any application but doesn’t address the other two compelling cases for background processing: a) notifications like an alarm clock or countdown timer and b) broadcast messaging for status updates or location notification. Updating a badge with a new count of incoming messages is nice but it really limits the sort of application possible using the new features and API.

Can you imagine the extra work a developer of a countdown timer app would have to do to tell the user that the timer has reached zero? When the countdown timer app is exited due to a call or another reason and the timer hadn’t elapsed, he would have to send a final message out to his server on the Internet indicating the remaining time and the iPhone in use. Then the server would notify Apple when the timer elapsed and Apple would alert the user. But the application would spawn this process even if the user intended to quit the timer app or even if there was two seconds left. Further, it seems like Apple’s server would queue update requests so it’s entirely possible that the user would be alerted long after the timer had actually elapsed.

For status broadcasting, there’s just not going to be a way to handle it in the single-source scenario as it appears to be a one-way process. Sites like Brightkite or Fire Eagle couldn’t get the particular iPhone to respond to a pull request because I’m sure that Apple would not allow a notification to quit the running application to open a different one. That would make for a jarring user experience and I just don’t see Apple going that route.

Obviously, details about this September service are sketchy at this point so all of these considerations could prove moot when it is released. But Apple had better address them because no countdown timer app maker would provide a server to accommodate Apple’s unwillingness to allow background processing and location-based social networking seems to be a compelling use of the new GPS capability.

Dashboard Widget moveTo

June 7, 2008

If you find yourself whipping up a widget in Dashcode and circumstances have moved that widget (during the running and testing) off the screen so that you’ve essentially lost it, you’ll try everything to get it back. window.moveTo doesn’t work. There is no widget.moveTo. And manually setting window.screenTop to 0 has no effect. So you google and google and google, but there’s seemingly no query that you can construct to get an answer. I guess you’re never going to see your little widget again.

But don’t despair, friend! Just use the undocumented method widget.resizeAndMoveTo(x, y, width, height) in your show method and you’ll have your widget right where you want it, safe and sound.

What to Expect That I’m Expecting

June 5, 2008

This iPhone-related patent application just surfaced today. Combined with the rumor that Apple will unveil the iPhone App Store at the Worldwide Developer’s Conference starting on Monday, it offers some tantalizing insights into what we might expect from the normally secretive company.

Here’s two excerpts from the patent application:

The device supports a variety of applications, such as one or more of the following: a telephone application, a video conferencing application, an e-mail application, an instant messaging application, a blogging application, a photo management application, a digital camera application, a digital video camera application, a web browsing application, a digital music player application, and/or a digital video player application.

And also:

The wireless communication may use any of a plurality of communications standards, protocols and technologies, including but not limited to … voice over Internet Protocol (VoIP), Wi-MAX, … instant messaging (e.g., extensible messaging and presence protocol (XMPP), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), and/or Instant Messaging and Presence Service (IMPS)), and/or Short Message Service (SMS)), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document.

Video conferencing? IM? Blogging? Digital video camera? SIP/VoIP? XMPP? These are all technologies that aren’t in the current iPhone. So the question here is whether this is a carte blanche, catch-all sort of patent application or a revelation of Apple’s upcoming intentions.

I am very conflicted about this report. On the one hand, having these applications built by the mothership means that they’ll be more widely used and available. For applications like instant messaging and video conferencing, ubiquity makes them useful. On the other hand, by including them for free Apple would short-circuit developers interested in selling such applications at a time when there are exactly zero sanctioned, third-party applications. This, of course, is nothing new for Apple.

It’s within their rights to offer whatever software they want on whatever platform they create. But if they’re looking to grow their third-party application catalog (and make money off the App Store), they’d do well to emulate the Facebook platform or even their own operating system. Competition with their constellation of developers has a chilling effect and should only be engaged in rarely.

[UPDATE (6/9/2008): Apple appears to not be competing with iPhone developers. From the keynote, it looks like they’re just adding features to their existing stable of apps and leaving IM et al. to third parties. I think it’s the right decision.]

Full to the Brim

January 11, 2008

I put 4 GB of RAM in my MacBook and 2 GB of RAM in my iMac. I don’t know why I hesitated for so long in spending the $150! Everything is so zippy and I can have many, many applications open at the same time without worry. Now I just need to sell back all these 512 MB RAM cards I seem to have accumulated over the years…