This morning, iTunes started hanging at “Syncing Bookmarks” when syncing my iPhone. Several tries yielded the same results, even when I left it syncing for over an hour. A quick Google search led me to this iPhone Atlas page which said you could fix the problem by deleting ~/Library/Application Support/iSync and ~/Library/Application Support/SyncServices but warned that you may end up with duplicate data.
Instead of deleting them, I just moved them to my Desktop so I could restore them if necessary, then tried to sync again. That fixed the problem and I didn’t notice any duplicates either on my computer or the phone. After the successful sync I checked ~/Library/Application Support again and noticed that iSync had been recreated, but SyncServices was not. So I dropped my original SyncServices back in and everything still works fine.
To summarize, it seems that the problem can be solved by deleting ~/Library/Application Support/iSync, then letting the iTunes sync recreate it.
I’m sure this has been brought up many times before, but I can’t for the life of me figure out why the iPhone webapps directory (which is bookmarked by default on all iPhones) isn’t an iPhone optimized page. Not only is it non-optimized, it’s more difficult to navigate than most. Apple is (or was) encouraging developers to iPhone optimize apps, so it just seems obvious that they would do the same for their own.
On that topic, the iPhone 2.0 API and the new App Store have kind of overshadowed the web app directory. As a new iPhone owner, I just checked it out for the first time. It contains some good stuff; you may want to check it out if you haven’t already. Just remember to do it on your desktop.
There’s a short interview with Alex Payne, one of the Twitter developers over at radicalbehavior.com. He’s a Ruby / RoR developer (and big fan), but points out how it falls short for high traffic applications.
A few interesting quotes:
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.
It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow.
All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.
Ruby is a great language, but this is just further proof that you need to take a close look at your requirements up front, then pick the best (not necessarily the coolest) tool for the job at hand.