Kindle-d But Not Available

The New Yorker is now available in Kindle form. I subscribe to The New Yorker and have access to it in a browser, but the Kindle subscription is not linked to my physical subscription and their customer service says “Nope, can’t link ’em.” (Heck, I’d probably _trade_ my physical subscription for the Kindle version — aside from the very occasional photo-essay, the New Yorker is text and cartoons, which is perfect for the Kindle.)

The other day I bought a (dead-tree) technical book on Amazon. As part of the checkout process, I was offered a $5 “upgrade” to read it online. “Yeah, okay,” I thought. Again, what I was given was a browser-based viewer. The book is _available_ on the Kindle for $29. So I wasted my $5 and will never use that option again. But had they offered me a $5 (or even $10) “physical book + Kindle” bundle, I’d do it every time.

Dow 7000: What’s the P:E?

Does anyone know what the combined earnings of the DJIA 30 is? I still have a couple decades before retirement; if the P:E ratio is getting back to normal, I might start buying because (a) it’ll either come back or (b) it won’t, in which case “investment strategies” aren’t going to help one way or the other.

From Theory to iPhone, Part 2: Separation of Concerns

 Part 1

Model-Editor / Domain-View : On This We Can Agree

For 20 years now, it’s been widely agreed that one of the best ideas for writing a maintainable system is to separate the domain stuff from the interface stuff. This makes especially good sense in a world where you want to make your software available on multiple devices (say, a desktop and a smartphone).

In the world of Smalltalk, the domain stuff was called the Model and the interface stuff was called the Editor. The idea was that you had a single Model and you had one or more Editors for manipulating it. In the Windows world, years later, there was a similar model called “Document-View,” and, indeed, it’s an essentially universal concept when working with GUIs.

From Editor To View-Controller: The Gathering Storm Clouds

Smalltalk went a step further. “Interface stuff” consists of input and output, which are really quite different beasts. So Smalltalk split the Editor concern into two parts: the View concerned with how things are … let’s say … drawn on the screen and the Controller, which is concerned about how … let’s say … mouse clicks and keyboard strokes are interpreted as commands to the domain-stuff and screen-stuff.

This leads to the classic Model-View-Controller (MVC) communication model:


The View requests data from the Model (“What is the city name?” “What is the postal code?”) and outputs it. The Controller routes mouse clicks and keyboard strokes to either the Model (“calculate shipping costs”) or to the View (“Scroll to the next page”). When the Model changes, either in response to a command sent to it view the Controller or by, say, a timer going off, it sends out a notification to any objects that have registered interest in hearing about it.

This model is simple enough, but it does contain some structural assumptions that are not logically demanded by the idea of separating the concerns of Model, View, and Controller. The most obvious is the notification model. Instead of having a Observer pattern, objects interested in the Model could be independent actors that just poll the Model regularly. That’d work: it’s actually closer to the structure of the Web (think about an RSS feed – the server does not maintain a list of subscribers, the subscribers just hit it every once in awhile saying “Anything new?”).

Another assumption (one directly relevant to OS X / iPhone programming) is that the Model maintains the list of its Observers. Another option is a separate notification “hub” that maintains the lists of “objects publishing updates” and “objects subscribing.” (This is how I think one “should” do it in Cocoa.)

Finally, this tidy little diagram begs the question of organizing complete screens. I’ve heard people adamant that one should create an MVC triad for each interface element. They say a BarChart View reflects a NumericRange Model and has Keyboard and Mouse Controllers and that these elements ought to be gathered together into larger units (panels and forms). Each component completely encapsulates its own responsibilities. This is a structure that fits well with most interface painting tools. I argue that such a structure is not MVC at all, but is Presentation-Abstraction-Control. (And I argue that most people get PAC wrong and that this is a cause of much suffering in the world. But that’s a post for another day.)

In my opinion, one ought to think of MVC triads in the coarsest granularity that maintains coherence. Sure, if you’re designing a framework, you have fine-grained MVC triads. But if you’re developing an application, your MVC triads ought to be quite coarse – that if you have a domain / Model object of type, say, Address, you ought to be thinking along the lines of an AddressController and an AddressView (or, in many cases, multiple View-Controllers that view and control the same domain object in different contexts – for instance, a read-only view that occurs after shipping occurs).

Warning: This description of mine does not describe any MVC framework – it’s a discussion of the MVC pattern. Modern MVC frameworks implement things based on an underlying platform and implementation language. I think it’s valid for Rails, ASP.NET MVC, and Cocoa to call themselves MVC frameworks, but even if you scratch under their surfaces, you won’t (quite) see the diagram I’ve presented here. Indeed, that’s the major reason I’m writing this series of posts.

From Theory to iPhone, Part 1: Everyone’s Got An Opinion

This is not a tutorial. This is me talking to myself. Much of what I say about iPhone development will be wrong.

It has become a truism that the platform library, not the programming language, has become the large barrier to learning. As a guy with a background in “everything but the Mac” (well, I learned Smalltalk on a Mac FX – does that count? And I had a NeXT pizzabox, but I never did any serious development on it), the barrier to iPhone development involves:

  • Objective C
  • XCode
  • Cocoa
  • iPhone Licensing / Provisioning Hurdles

My initial expectation was that Objective C was going to be the big problem. Objective C was a fascinating hybrid language back in the late 80s which combines approaches from C and Smalltalk – every C program is a valid Objective C program. (I really doubt that every valid Smalltalk program is also valid, but given Smalltalk’s famously compact grammar, who knows?)

Objective C was a success both in its time as an important part of the dialog about shifting towards object-orientation and, to this day, as the main programming language for the second-most-popular OS. But, let’s face it, it’s kind of an odd bird in today’s ecosystem. The combination of pointers and explicit memory management with Smalltalk-style messages and syntax is guaranteed to cause some mental context thrashing (I was looking at a simple piece of code yesterday and caught myself in a loop: “Right-associative? Left-associative? Right-associative? Left-Associative?…”). Heck, Brad Cox doesn’t much code in Objective C anymore!

But after a short time with my books (Cocoa(R) Programming for Mac(R) OS X (3rd Edition) by Hillegass, The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK (Developer’s Library) by Sadun, and Step into Xcode: Mac OS X Development by Anderson), it became clear that not only did I have to add a new challenge to my list:

  • Interface Builder

But that the real challenge would be understanding Cocoa and its design idioms.

APIs, Frameworks, and Opinions

At the lower-levels of an Operating System API, you can typically solve a problem in any number of ways: you have a potful of function calls and a whole bunch of resources that can be combined in whatever way you desire. You want to use a technique for inter-process communication that was obsolete a decade ago and is kept for legacy purposes? Go for it! You want to store the results of a calculation by encoding them in filenames? Awesome!

At the other extreme, frameworks such as Ruby on Rails boast of being “opinionated.” How do you structure your source code? Like this. Do you use unit-testing? Damn right: that goes over here. Storage structure, naming conventions, etc. – there’s a good argument to be made that “convention over configuration” saves a lot of time.

One of the big advantages of a baked-in “opinion” is that one can write tools based on the opinion. While it’s possible to write, say, a screen painter that works with any kind of layout management, generally speaking, tools can generate better code when there are fewer options.

Cocoa is less opinionated than Ruby on Rails but more than, say, .NET. More accurately, it appears to me that XCode and Interface Builder are quite opinionated, and if you forego the convention, you’re likely to lose out on some very powerful tooling (particularly in Interface Builder). Wow is a fantastic resource, which lists the specific projects in the economic stimulus, broken down to the county and city level, and sortable by price, number of jobs estimated, or votes (from the public) as to whether or not it’s truly critical.

This is just fantastic; I hope that it is actually read by politicians.

Update: Fixed link.

Fireable Offense?

Woman calls a customer service department, complains about something, has the situation explained to her.

She goes on a consumer advocate Website and describes the situation, saying that she had spoken to someone who was “moderately intelligent.”

Customer service rep sees this post, takes offense. He uses his customer service email account to send an email with the content “moderately intelligent…?” to her.

She goes on the Website and characterizes this email as outlandish, offensive, etc.

The customer service rep gets fired. I dunno’. On the one hand, the rep’s response was clearly ill-advised, but on the other hand, aren’t we supposed to be breaking free of old conceptions of the appropriate tone between a company and its clients? If a rep responded, not with a boilerplate “We apologize for any inconvenience…” but with a “You know, that really hurt because I was distracted that day because I’d been up all night hand-feeding some kittens…” then this might have been some example of a company “speaking with a human voice.” Is it really a fireable offense to take offense at being insulted (not that characterizing someone as “moderately intelligent” is extreme behavior) and to let the person know that you object? 

What do you think?

Update: Chuck Todd has a blog entry complaining about the tight reins he’s experiencing as a member of the White House press corps. The most common response of commenters is “quit whining.” But I read it and see “These are the conditions I work in. They’re frustrating and don’t serve anyone’s interests.” It’s the same kind of thing — a personal tone, but isn’t that what everyone’s supposed to be doing nowadays?

Kindle Monospaced Font Not “Picked Up” By My Existing Books

I checked every programming book I have on my Kindle: Hillegass’s Cocoa Programming, Odersky et al.’s Programming in Scala, and a couple Pragmatic Programmer books — none “trigger” the monospaced font now supported by the Kindle. I suppose the “good” news is that there are not many programming books for the Kindle yet, so the amount of unsupported content is low.

Now that a monospaced font is available and Amazon is going to make Kindle material open on a variety of platforms (i.e., the iPhone), one hopes that the tech publishers will make the extra effort to support the Kindle / Mobi format. Both O’Reilly & Associates and Pragmatic Programmers have an eBook infrastructure and high-quality texts. It is just a matter of whether they can be convinced that the incremental cost of supporting the Kindle format is worthwhile.