Re: Core Data using only one object
Re: Core Data using only one object
- Subject: Re: Core Data using only one object
- From: Steve Weller <email@hidden>
- Date: Tue, 24 Apr 2007 21:54:20 -0700
John, Roland, Corey, Steve, others - can you please provide
examples of where you feel the Core Data documentation is talking
over the heads of developers, especially in the "Core Data
Programming Guide" and "Core Data Basics" books?
The Apple documentation takes care of two groups well: ignorant
novices and ignorant experts.
The first group neither knows what to do nor what to do it with. They
can neither think in three dimensions nor wield a chisel. They have a
long road to being a sculptor. They don't even know anatomy. So toy
examples and simple code are just the ticket.
The second group knows what to do, but not how to achieve it with the
tools supplied. A chain saw? But how does that... ah we work with
*ice*. So much faster than a chisel! They already think in three
dimensions and having struggled with bad tools, understand why these
tools are so good and know how and where to apply them. Core Data and
its documentation are great for these people.
The third group (of which I am a member) is the knowledgeable
novices. We have done lots of great things but with different tools.
We know a lot, but just not about Cocoa. We are painters of horses,
not sculptors of people. We know anatomy, but of the wrong animal.
Give us a chisel and we'll hack away at the canvas. Tell us to paint
in three dimensions and we (or at least the Brits among us) will look
at you sideways and raise one eyebrow in a quizzical way.
This is the group that needs the help. We need to be able to learn
(but not necessarily actually be taught!) what tools are applicable
to what problems and why. This will involve unlearning as well as
learning, or else we'll just take anything you give us and poke it at
the canvas like we do with paints and brushes. In some cases we'll
have to learn shapes and shadow and color all over again.
And this is a most difficult task. Since we have a very wide range of
previous experiences, we approach problems and apply solutions in
widely differing ways. First you have to catch us before we leap to a
conclusion, then you have to convince us that the weird way is worth
the effort, and then concrete the experience by showing us where it
leads to.
Writing an Aperture plug-in, some 2000 lines of code in all, has been
a very interesting experience, particularly with respect to bindings.
I used bindings as I went along here and there to save code, and was
comfortable with that. But my understanding of the value of bindings
really came about quite recently through my *not* using bindings.
There are many places that I could have and should have used bindings
but did not. Faced now with the problems of not using bindings in a
growing application (all the extra code and debugging I now find
myself contemplating), it dawned on me what problems bindings were
designed to solve, and how all the features fit together with MVC to
make a valuable whole. I now understand why I need to know anatomy,
even though I am never going to be a doctor. The next app I write
will be a binding-fest from the start.
I will probably try to blog what I have learned about learning about
bindings, but realize that it will be difficult to do for a general
audience. I have to do the catch, convince, and concrete steps
without the benefit of puzzled looks and glazed over eyes.
So the purpose of the missing documentation should be to accelerate
the process of revelation for knowledgeable novices. To do this you
will first have to understand how this audience understands and
misunderstands using the material and experience they currently have,
and then segment and formulate ways to channel that time investment
into a valuable learning experience. All the knowledgeable novices
will get there in the end, but that is too much code to write. We're
looking to short-circuit the experience of writing ten apps so that
our first or second app will be that much easier to create and support.
--
Bagelturf Blog http://homepage.mac.com/bagelturf/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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