Re: More sandblasting (oops, I mean sandboxing die die die)
Re: More sandblasting (oops, I mean sandboxing die die die)
- Subject: Re: More sandblasting (oops, I mean sandboxing die die die)
- From: Alex Zavatone <email@hidden>
- Date: Mon, 03 Sep 2012 19:30:30 -0400
On Sep 3, 2012, at 6:57 PM, Roland King wrote:
> These exact points are explained at the start of the 2012 WWDC sand boxing video, which also introduces some of the terminology and thinking behind the design. I found that video well worth 45 or so minutes of my life. Won't help with the sand boxing bugs but it did give me a better idea of how the Apple engineers think about sandboxing and some terms to search the docs for.
The fact that we have to wait 'til a bunch of the creators get together and make a video to explain a fundamental process shows a huge gap in the system.
Take this example from the WWDC 2011 video "1-16 Session 319 - Effective Debugging with Xcode 4".
At 15 minutes, 20 seconds in, the speaker mentions that the first thing people ask is "how do I show the console in a separate window". First of all, no developer should ever have to ask this question. How to do this should be painfully obvious.
Besides watching this video, there is no way someone is going to find out how to open a full window console, which should be one of the simplest tasks to the developer, and one easily assignable to a shortcut key.
At too many important parts in the getting running and developing process are Apple's processes rather broken.
Getting up and running with certs and keys should be handled by an assistant AS SOON AS someone opens Xcode, if everything is not in place. There should be checks to make sure that everything is in place before moving to the next step.
And having to find a video that tells you the process on how to open a window that is only the console and then go through all those steps (which still to not result in a menu item that you can use to open a full window console) is just insane in a modern development tool.
There are easy to identify areas that must be improved. It seems to make painfully obvious sense the most sense to work on these areas first if Apple's goal is to make us more productive.
FYI, I never had to go through as many hoops to get Xcode to work normally in xCode 3.1.3.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden