Fireworks
4th July Fireworks: 2.5s f/8.0 ISO100 80mm, Canon 30D, Canon 70-200 f/2.8L IS
I have a small selection of fireworks photos in my Canon 30D gallery now. My style is to use a long lens and record the detail of the display rather than try to capture the whole thing. I used ISO 100, f/8 for all of them, varying the exposure time according to how much movement I wanted. I used a tripod of course, one of the few occasions that I do, and turned IS and AF off. JPEGging them for upload loses a lot of the detail, and that's unfortunate because they are very sharp.
Apple To Buy Tesla Motors
You heard it here first. Apple will buy Tesla Motors. Yes, it's a crazy idea, but actually not so far off as you might think.
Apple has the cash. They also have the design and operations know-how. God knows they have the marketing acumen. An electric car is a pile of electronics and they have many engineers. The car industry, at least in this country, is out of touch with its customers, so ripe for the Apple touch. It's high-profile, begging to be integrated with practically everything, and all very glossy. Start high-end, move down-market, and create a whole new class of vehicle.
Can Steve and Jonathon resist? It would certainly be an amazing third act for Steve Jobs.
What You Paid For vs. What You Got
100 products: what you paid for on the left vs. what you got on the right. See the English write-up at Fantasticus, or go to Pundo3000, the original German site.
James Dempsey and the Breakpoints
Illicit footage from WWDC on YouTube: James Dempsey and the Breakpoints singing Release Me, I Love View, and Designated Initializer.
It's probably the best-kept secret of WWDC: all the sessions are set to song. I hope someone posts Bertrand Serlet's crooning.
Back From WWDC 2008
I'm back from WWDC 2008 and catching up with real life. It was fun, busy, tiring, informative, interesting, and packed with people engrossed in their laptops. I met a whole bunch of people who I knew online, as well as seeing many of the regulars from Cocoaheads. I've posted 94 photos at SmugMug, several of which are posted here.
Keynote
The keynote is of course very popular. I arrived two hours before the start and was about halfway back on the right. Here is the view I had of the procedings:
Seeing the real thing was great, but unless you have a good seat there is much real but not very much thing. Lots of excitement, but I was more interested in the state of the union talks that occurred later in the day.
Al Gore was at the keynote, and I snapped a photo of him in his way down on the escalator:
Room and Board
I kept the cost down by not staying in San Francisco and spending >$250 a night. Instead I commuted from the south bay, which, while inexpensive at $10.50 for a round-trip BART ticket, took out four hours from each day, much of which came at the expense of sleep. Finding parking at Fremont BART can be hard if you don't get there before 7am, so that pretty much controlled my timetable. By Thursday I was way too tired and went home early, so missing the bash.The food was pretty decent, especially considering that there were more than 5000 people there. Pre-packaged cold lunches were served at midday, and there were things to nibble on several evenings. Breakfast materials (doughnuts, bagels, etc) were there at 8am. The afternoons saw snacks and fruit arrive. Coffee and tea was available much of the time. I brought extra food and ate it all.
Sessions and Labs
The sessions themselves were very well done. The sound systems were excellent, so I could sit anywhere and hear perfectly well. Many of the seats had power strips attached to the legs so I could juice up my MacBook while I listened. The speakers, typically engineers and others working directly with the technologies, spoke and presented well. The product evangelists and other engineers were on hand for the Q and As that followed each session.I didn't get a great deal out of the labs, but that was mainly because I didn't have specific questions or problems, and had no app to show. The User Interface lab was completely sold out. The people in the labs rotate each day, so I only found out too late that I had missed the experts for a certain subject in the Graphics and Imaging lab and those that were there could not help me. So it pays to ask exactly what their schedule is day to day.
Cocoaheads
Tuesday night was Cocoaheads in the Apple store and it was packed:
There were a selection of indy Mac developers present talking about their companies and applications. Scott Stevenson has more information on his blog. Unfortunately there were no recordings made.
Infrastructure
Wireless networking was everywhere and hard ethernet ports were in several areas. On only a couple of occasions could I not get a signal. The infrastructure could sustain an awful lot of traffic: the only time I had to wait for anything was when I needed a 1.6GB installer and found that almost everybody at my table was downloading it at the same time.
Everything Else
There were non-Cocoa happenings too. Juggling took place on level two most days:
and there were many informal groups getting together and chatting.
The Apple Design Awards went quickly as they had a lot to cram in: Mac and iPhone this year. The little cubes light up when you touch the top, as you can see in this photo:
It was a pretty good place for photography, but only if you like taking photos of geeks with laptops and have the equipment to contend with low light and busy backgrounds.
Light levels and color vary enormously. I lugged a backpack with 20 lbs of computer and camera gear with me all week and got some pretty good photos. However I was constantly changing lenses. My favorite lens was the 85mm f/1.8 (about 135mm equivalent). I can see why people with full-frame cameras rave about the 135mm f/2L: it's a very useful length and aperture. The only lens I took but didn't use was the 50mm f/1.8. I used the 17-55 f/2.8 instead. A longer focal length would have been useful at times, but probably not worth the weight.
Next Year
Will I be back in 2009? Probably yes. It's expensive (especially since I'm self-employed) and a lot of work, but it's definitely part of being serious about development with Cocoa and Objective-C. I've come back with all sorts of ideas and a head full of knowledge that I would not have had otherwise.Photo Gear For WWDC
Stripey Hat: 1/160s f/9.0 ISO200 120mm, Canon 30D, Canon 70-200 f/2.8L IS
I'm treating WWDC as a photography opportunity as well as a Cocoa opportunity. I'll be taking a collection of my own lenses, plus two that were leant to me for the week. I don't have a flash (except the one built into the Canon 30D), so I'll be challenged by low light.
The 80mm f/1.8 is equivalent to about 135mm, good for across the room shots of people, and the longest lens I am planning in taking. The 24mm f/1.4L is equivalent to about 38mm and will be good close up. Neither of these have image stabilization, so although they will give me low-light capability, it will be blurry if I can't hold the camera still enough. That's why the 17-55 f2.8 IS may be there as well: it's the widest and has IS. I'll also carry the 50mm f/1.8. It's plastic, very small, light, and inexpensive.
Since I'm commuting each day, I'll be able to switch equipment often, ditching the things I find myself not using. It's possible I'll lug the very heavy 70-200 f/2.8L IS around, but I'll need a very good reason. Other than camera and lenses I'll take nothing special. Maybe a tiny tripod, but otherwise just things like spare cards and a spare battery, download cable and a card reader. I'll be processing the images on my Macbook using Aperture and uploading to SmugMug when I get a chance.
WWDC Now Warming Up
No Doubt Who Is Here: 1/2000s f/5.0 ISO200 24mm -0.3ev, Canon 30D, Canon 24mm f/1.4L
No word on whether there will be any sort of Aperture meet-up so far. There's plenty going an already actually. I planned my sessions the other day and it is packed with good stuff.
Blue and Purple: 1/250s f/5.6 ISO200 24mm -0.3ev, Canon 30D, Canon 24mm f/1.4L
See You At WWDC
I'll be there with my camera gear, including two lenses that were loaned to me by a friend, so there should be plenty of photos that week. Check my WWDC 2008 gallery for updates.
Predictions? A tough call as always. I have an almost 100% record of being wrong, but here goes:
1. 3G not only in the new iPhone, but in all new laptops from here on
2. A switch to LLVM as a base for all code compilation
3. A paid software update service for developers -- just like Software Update, but with more bells and whistles
4. A new .Mac offering scalable back-end services to iPhone developers
Übermind Releases iPhoto Plug-ins
Übermind has released three iPhoto plug-ins to complement their Aperture plug-ins: ÜberUpload for iPhoto, iPhoto to Picasa Web Albums, and iPhoto to Archive. They are offering a promotional price until the end of June.
Ballistic Jaw Propulsion Of Trap-Jaw Ants
This has to be one of the oddest (and strangely mesmerizing) things on the net: ants flying through the air in extreme slow motion propelled by the rapid closing of their jaws. All set to a very peculiar sound track. The ant at the top of the image above is cart-wheeling its way over the other two.
Cocoaheads Video Now Available Via Torrent
Scott Stevenson (above) has posted videos from the May CocoaHeads. They're available via a torrent as well. The main topic was a rapid introduction to Cocoa.
CocoaHeads Silicon Valley continues to draw good attendance. I'm sure that the WWDC meeting will be packed just like it was last year.
Aperture 2.1: Less Adjusting To Do
Life At Number 4: 1/200s f/8.0 ISO400 17mm -0.3ev, Canon 30D, Canon EFS 17-55 f/2.8
Having used it for a while, I'm finding that Aperture 2.1 gives me consistently better images than 1.5. I notice it because in most cases I am unable to improve them: it does a better job first time and there is simply less to do, or even attempt to do. This is good. I'd rather not spend much time tweaking.
The Ongoing Debate Over Apple's Developer Documentation
Today I threw my assessment into the ring with all the others. See below:
The documentation debate is actually several orthogonal debates that regularly get intermingled:
* What should the purpose of the documentation be?
* How should it achieve those goals?
* Who should be responsible for it?
The answers to these questions used to be easy because of the scale of the problem: small. As Apple grows, as its software base grows, as its customer base grows, and as its developer community grows, so does the diversity of all of those and difficulties and vocal minorities with those difficulties appear.
An area where Apple has proved itself to be a master in its *products* is that of managing expectations. Only by managing expectations is it possible to consistently satisfy and delight customers. But we're not debating products here, we're debating *developer documentation* and that's not a product. Or maybe it is? I argue that it is not because if it were then Apple would be managing it like one and is clearly not. If it were, then the three questions above would have answers and we would all know and understand them. It is notable that for the iPhone SDK announcement there was a live public demo of Apple's developer tools -- a milestone event -- so maybe the path to the productization of the documentation is coming.
To add fuel to the multiple fires here:
Erik Buck wrote:
Many of those with difficulties know and understand this. It's the best thing since sliced bread and they want to learn, badly. They quickly find that the Cocoa way is not the same as the Java or C way, and while there are a small number who will simply complain that it is unfamiliar and do nothing about it, the majority just see it as another thing they need to grok. Programmers have one thing in common: they want to be productive. Those learning ObjC/Cocoa are doing it because they want to be productive and they believe that mastery will make them greatly productive."Cocoa is the most consistent, elegant, and productive software development technology I have ever used, and I have used a lot. Cocoa uses key metaphors and design patterns ubiquitously. If the programmer is either unaware of the metaphors or does not see their utility, it will be difficult to use Cocoa. If a programmer fails to grasp a particular pattern, the whole framework may be incomprehensible because the pattern is most likely used throughout."
But the documentation actually *defines* them very well. What the documentation does not do is to justify the existence of these things, explain the problems that they solve, put them into context, relate them to the user's situation, reassure the reader how much they need to know right now to get to the next step, etc. It does all of these things *in places* and to different degrees, but not consistently and not enough. The environment is hostile to learning."The attributes of Cocoa that make it so consistent and elegant are exactly the same attributes that I think newbies are complaining about. The newbie complains that the reference documentation mentions delegates or tags or data sources or the responder chain or key value coding or bindings or targets or actions etc. without defining them".
And this is precisely why there used to be sections in computer manuals on mouse usage, hierarchical file systems, etc., all unfamiliar concepts to many of the users. But there are *no such sections* in Apple's docs. Should there be?"This is exactly like a newbie complaining that clicking and dragging and selecting and double clicking are used throughout a GUI but not explained in the documentation for every application. Once the GUI metaphors are internalized, it is unnecessary at best and annoying at worst to keep encountering mouse based selection explained in every user's guide. The consistent application of the metaphors makes the GUI easy to use. The consistent use of metaphors makes Cocoa easy to program. BUT YOU MUST UNDERSTAND THE METAPHORS FIRST in both cases."
No really, I can't find them. Here I am in Xcode's docs and I'm typing in Concepts, Conceptual into the search box, and any way I try it I don't find any conceptual docs except Core Foundation Design Concepts (now three years old). And if I go to the developer site and find my way to http://developer.apple.com/documentation/Cocoa/, there is nothing labeled "conceptual". Let's try the pop-up on that page: Jump To: No concepts.
But the idea of conceptual documents *really is* there. The document Introduction to Cocoa Bindings Programming Topics has the following path: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html. It's in the *Conceptual* folder so I know that conceptual documents exist here as a concept at least. Now show me all the conceptual docs in one place so I can learn the concepts!
Now *I* know that the Guides fill a conceptual role, and Getting Started With Cocoa tells me to go see the Guides for conceptual information. But when I actually go there practically salivating with anticipation, it's organized by *Topic*, not by Concept. Show me the concepts!
Let's try a global text search at the developer site: 8600 documents show up, and I meet Core Foundation documents before I meet Cocoa. "Cocoa Concepts" does somewhat better with 1500 documents, but still. Where do I start? How about Core Data, that shows up near the front and sounds pretty conceptual....
Am I looking in the wrong place? For the wrong thing? How would I ever know if I'm starting out?
Perception is everything. If the newbie perceives that it's all screwed up then it *really is*. It doesn't matter if *you* learned Cocoa from reading the backs of cereal boxes. *You* are not the typical Cocoa learner. And this is key and why the docs need fixing: Almost nobody here is a typical Cocoa learner, because at least 90% of the typical Cocoa learners have not yet even arrived in Cocoaland.
On May 18, 2008, at 4:33 AM, Julius Guzy wrote:
Here is an example of the difficulty. Go to the Cocoa section of the Core Reference Library. Click on Fundamentals (Essential information for developers using Objective-C) and select Memory Management Programming Guide. I'm playing the part of a good newbie here -- clicking on everything that claims it is fundamental, essential, and core to the whole thing. By being here I am told that memory management is fundamental, essential, and core, and the document reinforces that. The first thing it says is:"The very good , interesting and informative debate in this list concerning the accessibility of the programming environment to new users has it seems to me incresingly polarised between those who think the documentation more or less adequate and those like me who for whatever reason, have great difficulties making use of the facilities."
"Memory management, especially as it concerns Objective-C programs, is an important subject. Some of the more common problems encountered by novice application developers derive from poor memory management. Cocoa provides mechanisms and a policy to assist you in the proper creation, retention, and disposal of objects."
Wonderful! I am in the right place. The docs are doing their job. But in the second section I find that:
"Cocoa does not use garbage collection. You must do your own memory management through reference counting."
Really? I'm sure that garbage collection was in here somewhere, that was one of the reasons I wanted to learn Cocoa all of a sudden. And then later on, there is a whole section on Core Foundation memory management, talk of retain cycles, NIB files, data sources, weak references, and the like. Whaaaaaaa?? If this is the fundamental stuff, what do the tricky bits look like?
The individual developer documents are of very high quality, and this particular document is no exception. It is well-structured, complete, consistent, has many references to other documents, stresses the importance of important things, shows simple examples, describes common errors, has good readable English, etc. Some of the developer docs I have read are truly exceptional, describing very difficult material very precisely and very clearly, so it's not a lack of writing skill or the ability to explain complex things.
So what is wrong?
1. This document that I believe to be fundamental, essential, core, and important *does not stand on its own* and so robs me of understanding.
2. It is at least five times too long and contains material that while fundamental, is not fundamental to *my learning as a newbie*.
3. It has not been designed as a learning tool. If it had then it would be goal-oriented and as a learner I would be able to measure achievement by reaching that goal. I would then have confidence that my task was complete and would tackle the next fundamental item.
4. It has not met my expectations
The last point is the most important one. For whatever reason I expected to be able to learn from the documentation and it was only when I tried to do that and failed were my expectations dashed. *As a product* the documentation fails for this one fundamental reason. If I were here because I had somehow missed the huge Learn Cocoa Here banner on the developer site and clicked in the wrong place, then it would be my fault (or I had continued past the banner that told me not to learn here). But there is no such banner and no such material, and so I have every reason to believe that I can learn here.
While the documents themselves are very good, I believe that the architectural problem is that the *documentation* is not. That is, as a body of work, it is on the verge of no longer meeting the needs of developers. That's because the nature of developers themselves has changed, and the current documentation organization does not scale. Apple's own product success (iPhone!) and ease of use sets a very high expectation bar for new developers too.
It is also worth noting that many (most?) younger developers expect (demand?) an agile approach to learning new languages, environments, and concepts. Maybe Cocoa is not like that and can never be like that, but this is the expectation that Apple faces. A Google search for "agile cocoa" yields no Agile books (but at least does lead to Fraser Speirs).
"I think this debate relates to the same concerns and battles we had, and in many cases are still having about computer usability, namely the effective design of human-computer interfaces, aka HCI.
It's a scaling problem. That fundamental memory management document above covers a lot of ground out of necessity (in order to be complete in the face of scaling) but in doing so covers too much ground (in the face of scaling of readership and hence the diversity of reader backgrounds).It is ironic that we are having this debate within an Apple programmer's mailing list. Apple has been celebrated for the usability of its machines and long may it continue to be so. However, Apple has been less celebrated for the humanity of its programming interface having, in my experience of Macs from the Lisa onwards, seemingly taken the attitude that its programmers were hobbyists, geeks essentially, who because of their enthusiasm would successfully negociate their way into the machine's innards. That said, the 9 tomes of "Inside the Macintosh" documentation of the programmer's workshop were pretty good once you got into them but there was a lot less to get into then than there is today"
"This question of volume of documentation and system size and complexity is significant to our debate. It is pertinent to quote what one of the great programming pioneers, Dijkstra said about PL/1: That it " must be like flying a plane with 7,000 buttons, switches, and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language - our basic tool, mind you! - already escapes our intellectual control". ("Humble Programmer", see Prgramming Methodology 1978).
It's not the programming interface that has difficulty. It really is extremely good and very well thought out. Every time I do something the "right" way I end up with less code and understand a little more of how smart the people were who created all this in the first place.Well I think that the sheer size and complexity of Cocoa et al comes close to being an aeroplane cockpit and one which we are largely expected to learn to use from engineering manuals essentially concerned with listing the identity, composition and location of components,(not to mention the various incarnations of Xcode and Interface Builder). I am not saying that tremendous pains have not been taken to create a robust coherent system nor to document it. There have. Also there are many who have succeeded in mastering the system. Some will have done so through having grown up with it from early days, others will have had the fortune to attend (expensive) traning courses, and others still will have done so through dint of talent, perspicacity and hours of hard work. So mastery is possible. But I am not stupid nor a shirker nor a complete novice and I expect that the same can be said for most people who have had and are continuing to have horrendous dificulties in getting to use the system. It is clear that the programing interface to the Mac has serious usability issues."
It just doesn't look so good to those who don't understand why it is like it is. There are some similar arguments to this one about the interface to Blender, the 3D modeling and animation application. It's hell to start with (three button mouse? you must be kidding...), but much later you realize why it all makes sense because the enormous complexity you would otherwise face at that later point is so much more manageable than with other apps. Experienced Blender users are amazingly productive *and* they can keep up with the rapid scaling of the platform because of its conceptual underpinnings. The Blender docs are another matter though...
Exactly. Conceptually, saving triggers the connection and makes the magic happen. But how is that concept learned? Where is the metaphor? Why is saving even needed?"I cannot help touting one recent example. To specify the outlets etc between a class definition and Interface Builder on Leopard we are told to type the name of the class into a field and that thereafter IB will make the appropriate links with Xcode. It took me ten minutes of doing it this way and that before I realised that IB would only make the connections AFTER one had typed in the class name AND saved IB! We know from HCI research that it is little things like this which most frequently cause users to give up and never touch the equipment again."
Perception is everything!"Now, of course, as programmers we are well used to wasting hours hacking through the underbrush to discover that to switch on the machine we need to hold down Alt-Escape with the right hand whilst depressing a button round the back of the machine with the left. (That was how in the 70s one turned on some of the PCs at Leicester Poly!). But what a waste of time and effort and how demoralising and off-putting to anyone but the most obstinate programmer. I deferred having a go at Cocoa for about three or four years because I knew it would be a struggle and these last five months or is it six have been horrorshow.Let me state two principal facts.
1. Designing good user interfaces is hard.
2. Designing good user interfaces is expensive.
It is hard because every human being is an individual,
because there is seemingly a lot to learn
and because there are limits to the complexity we can handle.
It is expensive because the design of good HCI is primarily an empirical activity centered on user testing"
We have right here the results of some user testing and yet those results are not being accepted as valid. Why is that?
Let's look at the issues again, partition them the way I think they should be, and throw in some answers:"The question is then whether we and possibly apple should do anything about it"
* What should the purpose of the documentation be?
To hook beginners, to teach learners, and to support experts. These three different goals require mutually exclusive techniques and tools, but currently there appears to only be one big classroom and one textbook at Cocoa School.
* How should it achieve those goals?
Reward beginners with their concrete understanding; reward learners with their concrete code; reward experts with their concrete profit.
* Who should be responsible for it?
Ultimately it must be Apple because they control the code. They don't have to write the material themselves, but they must find a way make it possible for the material to exist and be found. There is no "Apple Press". There is little to no investment in a writing community that could fill in the gaps. There is no structure into which additional material can fit in a rational fashion, although there is all sorts of material out there that we stumble across.
Jason Stephenson wrote:
"I also don't find any great difficulty in using Apple's documentation. The conceptual documents cover the concepts, and the reference documentation serves as a reference. No, I don't think you should learn to use Cocoa just from the conceptual documents, but I'm sure it is possible.
Agreed. So what about third party books? Surely everyone is expected to go buy a book and use that. Well, not everyone does these days, since the web has taken over much of the world's publishing. But let's give the developer docs a chance and see what is recommended. Go to Getting Started With Cocoa at http://developer.apple.com/referencelibrary/GettingStarted/GS_Cocoa/ and look at Start Here. There surely cannot possibly be a better place to start! There are two book links:The simple fact of the matter is that documentation, just like a GUI, cannot be all things to all people. Programmers and those interested in programming are a particularly eclectic bunch. We each come at Cocoa for the first time with different experience, different reference points, and different expectations. One set of documentation cannot be expected to handle all of the possible permutations of programmer knowledge and experience. For this reason, other books exist written by third parties to cover those gaps or target different audiences."
http://www.oreilly.com/catalog/9780596003012/ leads me to a book published five years ago.
http://www.oreilly.com/catalog/9780596002350/ leads me to another book published five years ago.
And the other books on the page are of the same vintage.
You see the disconnect -- we all know that this is not how the great Cocoa books are found, yet here it is in the docs. Apple's documentation is not integrating well with other resources, and worse, maintenance appears to be falling behind somewhat. This is not a tenable position. Just as a city gets run down area by area, not noticed or lived in by those who could foster change, documentation, especially documentation on this scale fails in the same way with the new users in the slums.
Why this situation?
Jason Stephenson also wrote:
But since Apple is the de facto owner of Objective-C and the actual owner of Cocoa, there is no alternative!"In summary, I think it is a problem of all programming documentation and programming interface regardless of the platform or language, and I don't really see a way for a single vendor to resolve the issue, not do I think they really should"
The allocated resources at Apple are just not sufficient for the current task. It's not that the problems are not known or fretted about, it's a matter of priority. We and everyone else can debate and complain as much as we like, but no lasting changes will occur until this particular user interface is viewed on a par with the consumer user interface and dealt the resources commensurate with its importance.
Silicon Valley Cocoaheads April Meeting Now Available On Video
Two videos and slides of the April Cocoaheads meeting is now available online. For details, see Scott Stevenson's blog entry. There's a total of some 750MB of material.
It featured Scott (seen above) on user interface design, and Joar (below) digging into the debugger.
I'm in the audience asking intelligent questions.
More Learning Than I Can Shake A Stick At
Out of the Tunnel: 1/30s f/6.3 ISO400 17mm -0.3ev, Canon 30D, Canon 17-55 f/2.8 IS
I've been a bad blogger -- not blogging. It has something to do with working harder, commuting further, and earning less, but it's also also tied up with my head being in continual input mode right now.
My temporary spot tech writing has morphed a little and I have another writing client for whom I'm doing a developer guide for cell phone middleware, so I seem to have become a technical writer without really meaning to (talking to others, this is how it apparently happens). Not only that, I'm hiring and managing other tech writers. Plus I continue to plug away at my Cocoa application in my "spare" time.
Let's see, I'm learning:
- Ruby
- Rails
- XML
- XForms
- XPath
- How to hire and manage tech writers, set up a tech pubs department, etc.
- How enormous chips are designed
- Big chunks of Cocoa
- Object-oriented programming
- The practical application of MVC
- PDF document structure
- The math of Bezier curves