I may have not been correct

When I said Apple should buy Sun, whether that was a good idea or not, it seems to have failed to occur. Instead, we find that Oracle have done the necessary. Well, there goes my already-outdated SUNW tag. Presumably they’ll keep Java (the licensing revenue is actually pretty good), MySQL (I’ve heard that Oracle make databases), the OS and a subset of the hardware gear. Then they’ll become the all-in-one IT industry in a box vendors that Cisco have yet to organise, with (presumably x86) servers running the Solaris-Glassfish-Oracle-Java app stack in some insanely fast fashion. I wonder how many of the recent leftfield hardware projects they’ll just jettison, and who will end up running the Santa Clara business unit…

Posted in Java, orcl, sunw, UNIX | Leave a comment

On default keychain settings

After my presentation at NSConference there was a discussion of default settings for the login keychain. I mentioned that I had previously recommended some keychain configuration changes including using a different password than your login password. Default behaviour is that any application can add a secure item to the keychain, and the app that did the adding is allowed to read and modify the entry without any user interaction. As Mike Lee added, all other apps will trigger a user dialogue when they try to do so – the user doesn’t then need to authenticate but does have to approve the action.

That almost – but not quite – solves the issue of a trojan horse attempting to access the secure password. Sure, a trojan application can’t get at it without asking the user. What about other trojan code? How about a malicious SIMBL hijack or a bundle loaded with mach_override? It should be possible to mitigate those circumstances by using custom code signing requirements, but that’s not exactly well documented, and it’s not really good usability for an app to just die on its arse because the developer doesn’t like the other software their user has.

There’s a similar, related situation – what if the app has a flawed design allowing it to retrieve a keychain item when it doesn’t need it? Sounds like something which could be hard to demonstrate and harder to use, until we remember that some applications have “the internet” as their set of input data. Using a web browser as an example, but remembering that I have no reason to believe whether Safari, Camino or any other browser is designed in such a way, imagine that the user has stored an internet password. Now all that the configuration settings on the user’s Mac can achieve is to stop other applications from accessing the item. If that browser is itself subject to a “cross-site credentials request” flaw, where an attacking site can trick the browser into believing that a login form (or perhaps an HTTP 401 response, though that would be harder) comes from a victim site, then that attacker will be able to retrieve the victim password from the keychain without setting off any alarms with the user.

If the user had, rather than accepting the default keychain settings, chosen to require a password to unlock the keychain, then the user would at least have the chance to inspect the state of the browser at the time the request is made. OK, it would be better to do the right thing without involving the user, but it is at least a better set of circumstances than the default.

Posted in conference, Keychain, security | Leave a comment

NSConference: the aftermath

So, that’s that then, the first ever NSConference is over. But what a conference! Every session was informative, edumacational and above all enjoyable, including the final session where (and I hate to crow about this) the “American” team, who had a working and well-constructed Core Data based app, were soundly thrashed by the “European” team who had a nob joke and a flashlight app. Seriously, we finally found a reason for doing an iPhone flashlight! Top banana. I met loads of cool people, got to present with some top Cocoa developers (why Scotty got me in from the second division I’ll never know, but I’m very grateful) and really did have a good time talking with everyone and learning new Cocoa skills.

It seems that my presentation and my Xcode top tip[] went down really well, so thanks to all the attendees for being a great audience, asking thoughtful and challenging questions and being really supportive. It’s been a couple of years since I’ve spoken to a sizable conference crowd, and I felt like everyone was on my side and wanted the talk – and indeed the whole conference – to be a success.

So yes, thanks to Scotty and Tim, Dave and Ben, and to all the speakers and attendees for such a fantastic conference. I’m already looking forward to next year’s conference, and slightly saddened by having to come back to the real world over the weekend. I’ll annotate my Keynote presentation and upload it when I can.

[] Xcode “Run Shell Script” build phases get stored on one line in the project.pbxproj file, with all the line breaks replaced by n. That sucks for version control because any changes by two devs result in a conflict over the whole script. So, have your build phase call an external .sh file where you really keep the shell script. Environment variables will still be available, and now you can work with SCM too :-).

Posted in cocoa, conference, iPhone, macdevnet, metadev, objc, security, xcode | Leave a comment

Controlling opportunity

In Code Complete, McConnell outlines the idea of having a change control procedure, to stop the customers from changing the requirements whenever they see fit. In fact one feature of the process is to be heavy enough to dissuade customers from registering changes.

The Rational Unified Process goes for the slightly more neutral term Change Request Management, but the documentation seems to imply the same opinion, that it is the ability to make change requests which must be limited. The issue is that many requests for change in software projects are beneficial, and accepting the change request is not symptomatic of project failure. The most straightforward example is a bug report – this is a change request (please fix this defect) which converts broken software into working software. Similarly, larger changes such as new requirements could convert a broken business case into a working business case; ultimately turning a failed project into a revenue-generator.

In my opinion the various agile methodologies don’t address this issue, either assuming that with the customer involved throughout, no large change would ever be necessary, or that the iterations are short enough for changes to be automatically catered for. I’m not convinced; perhaps after the sixth sprint of your content publishing app the customer decides to open a pet store instead.

I humbly suggest that project managers replace the word “control” in their change documentation with “opportunity” – let’s accept that we’re looking for ways to make better products, not that we need excuses never to edit existing Word files. OMG baseline be damned!

Posted in metadev | 2 Comments

On noodles

It’s usually considered a good idea to keep a blog focused on exactly one subject. Sod that for a game of soldiers! This one’s all about music.

Steph, who is a very good musician and knows what she’s talking about, wrote that there are two ways to play a harp, a “get the music right” recitation style and a “get the rhythm right and everything else follows” style more suited to improvisation, noodling or folk playing.

That’s not only true of the harp, it seems to hold for many instruments. For instance, in a moment of crazed, um, craziness this weekend I bought what’s commonly referred to as a lute. In fact, a lute with much in common with this lute. Now I’ve been playing it for all of about two hours in total since Saturday, and can barely remember what note each course plays, and do a poor rendition of about four different tunes from a book of trivially simple lute tunes. But today marked an interesting transition, as it was the first day that I could make music up on the instrument without either knowing or concentrating on what I was doing. Only a couple of things (the song “Wooden Heart” made famous by Elvis Presley, and that banging dance-floor filler “Parson’s Farewell”) but this represented the point where I could make music on the lute – a different skill than remembering where and when to stick fingers on some bits of nylon, steel and wood.

And I think that’s where the root of Steph’s distinction of playing techniques really comes from; the unprepared style relies on having some music that needs to occur, and the ability for your hands (or nose or whatever your instrument is played with) to move around in some way which causes that music to exist. Whereas the prepared style relies on having some performance in mind that must be repeated, and requires that you think about moving $appendage in such-and-such way to recreate that performance. I find the distinction in conscious application to be an important one when playing the fiddle, an instrument I’m marginally better at than the lute. If I’m reading some music, playing solo or otherwise engaged in trying to play music, then I can only play whatever notes the music contained and in a fairly uninteresting manner. It’s only if I’m able to relax and not think about the music that I can harmonise, ornament and otherwise play more interesting things than what was written on the page – even if not necessarily particularly well :-).

Posted in music | Leave a comment

Cocoa: Model, View, Chuvmey

Chuvmey is a Klingon word meaning “leftovers” – it was the only way I could think of to keep the MVC abbreviation while impressing upon you, my gentle reader, the idea that what is often considered the Controller layer actually becomes a “Stuff” layer. Before explaining this idea, I’ll point out that my thought processes were set in motion by listening to the latest Mac Developer Roundtable (iTunes link) podcast on code re-use.

My thesis is that the View layer contains Controller-ey stuff, and so does the Model layer, so the bit in between becomes full of multiple things; the traditional OpenStep-style “glue” or “shuttle” code which is what the NeXT documentation meant by Controller, dynamic aspects of the model which could be part of the Model layer, view customisation which could really be part of the View layer, and anything which either doesn’t or we don’t notice could fit elsewhere. Let me explain.

The traditional source for the MVC paradigm is Smalltalk, and indeed How to use Model-View-Controller is a somewhat legendary paper in the use of MVC in the Smalltalk environment. What we notice here is that the Controller is defined as:

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.

We can throw this view out straight away when talking about Cocoa, as keyboard and mouse events are handled by NSResponder, which is the superclass of NSView. That’s right, the Smalltalk Controller and View are really wrapped together in the AppKit, both being part of the View. Many NSView subclasses handle events in some reasonable manner, allowing delegates to decorate this at key points in the interaction; some of the handlers are fairly complex like NSText. Often those decorators are written as Controller code (though not always; the Core Animation -animator proxies are really controller decorators, but all of the custom animations are implemented in NSView subclasses). Then there’s the target-action mechanism for triggering events; those events typically exist in the Controller. But should they?

Going back to that Smalltalk paper, let’s look at the Model:

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

If the behaviour – i.e. the use cases – are implemented in the Model, well where does that leave the Controller? Incidentally, I agree with and try to use this behavior-and-data definition of the Model, unlike paradigms such as Presentation-Abstraction-Control where the Abstraction layer really only deals with entities, with the dynamic behaviour being in services encapsulated in the Control layer. All of the user interaction is in the View, and all of the user workflow is in the Model. So what’s left?

There are basically two things left for our application to do, but they’re both implementations of the same pattern – Adaptor. On the one hand, there’s preparing the Model objects to be suitable for presentation by the View. In Cocoa Bindings, Apple even use the class names – NSObjectController and so on – as a hint as to which layer this belongs in. I include in this “presentation adaptor” part of the Controller all those traditional data preparation schemes such as UITableView data sources. The other is adapting the actions etc. of the View onto the Model – i.e. isolating the Model from the AppKit, UIKit, WebObjects or whatever environment it happens to be running in. Even if you’re only writing Mac applications, that can be a useful isolation; let’s say I’m writing a Recipe application (for whatever reason – I’m not, BTW, for any managers who read this drivel). Views such as NSButton or NSTextField are suitable for any old Cocoa application, and Models such as GLRecipe are suitable for any old Recipe application. But as soon as they need to know about each other, the classes are restricted to the intersection of that set – Cocoa Recipe applications. The question of whether I write a WebObjects Recipes app in the future depends on business drivers, so I could presumably come up with some likelihood that I’m going to need to cross that bridge (actually, the bridge has been deprecated, chortle). But other environments for the Model to exist in don’t need to be new products – the unit test framework counts. And isn’t AppleScript really a View which drives the Model through some form of Adaptor? What about Automator…?

So let me finish by re-capping on what I think the Controller layer is. It’s definitely an adaptor between Views and Models. But depending on who you ask and what software you’re looking at, it could also be a decorator for some custom view behaviour, and maybe a service for managing the dynamic state of some model entities. To what extent that matters depends on whether it gets in the way of effectively writing the software you need to write.

Posted in cocoa, metadev, ooa/d, smalltalk | 4 Comments

When techs collide

If you’ve ever seen the film Ghostbusters, you’ll know that each of the proton packs was, on its own, very powerful and capable of performing its function. Combine two, by crossing the streams, and rather than something twice as powerful you have a potentially Zuul-beating, potentially universe-destroying chaotic mess on your hands.

Such a combination I found today, when I mixed a little bit of Distributed Objects with a soupçon of Cocoa Bindings to create, um, Distributed Bindings (calling it Cocoa Objects would just be rude).

It’s actually just as simple as you think it will be, so there’s no point in any sample code. You can basically use the answer to the FAQ question on DO. Once you’ve got the proxy object in the client, use it as the observable controller in -bind:toObject:withKeyPath:options:. And that’s it!

Well, not quite it. You’ll notice that things are a wee bit crashy, which is why this is somewhat like crossing the streams. Both Bindings and DO use the Proxy pattern to achieve their magic, but because the two systems have no special knowledge of each other the proxy connections are not kept in sync. If your server object mutates after the DO connection disappears, then it tries to send a KVO notification to an object that’s no longer there…boom. Having a client-server system where the client can crash the server is of, well, dubious utility. There are some things that you could do to mitigate this, for instance looking for NSConnectionDidDieNotification (in the server) or opening a heartbeat RPC for the client to “check in” with the server. These fixes will work perfectly, if the vended object is updated predictably enough that you can reliably take care of broken connections between KVO notifications. Without that you’re SoL, as the server won’t reliably get a DO exception – more often than not it’ll segfault. But while this may be unstable, it still is damned cool.

Posted in cocoa, objc | Leave a comment

A lack of CocoaHeads

Apologies to anyone sat in the Glue Pot wondering where the nerds are. Due to a general feeling of bitter colditude we’ve postponed for a couple of weeks. But never fear, Scotty shall still wax forth on SearchKit on the 16th of the month.

Posted in whatevs | Leave a comment

Most favouritest and least favourite Macs

The current meme seems to be, given the 25th anniversary of the launch of the Mac (and I’m not going to let it slip by that it’s the 20th anniversary of the NEXTSTEP 1.0 launch this year, either) to write an opinion on the best and worst Macs we’ve ever used. So here’s mine.

Obviously my Mac use comes as a result of Mac OS X, so neither of my choices are particularly old machines. My favourite is a definite thing, and it’s the first Mac I ever bought myself – a PowerMac G4 Sawtooth. I didn’t own it from new; I bought it from a contractor who was writing a WebObjects app for us when I worked at the University. It was a “G4 Server” according to the sticker, which really just meant that it came with a SCSI adaptor fitted standard, and the pièce de resistance: Mac OS X Server 1.2 installed :-). The 1.x series of MOSES (Mac OS Enterprise Server) was a release of Rhapsody, a straight port of OPENSTEP to the PowerPC with a couple of changes. Most noticable were the configuration of startup items, the platinum UI and some changes to the Workspace to make it a little more similar to the Mac OS Finder. The 450MHz G4 I had was blazingly fast in this OS, and none too shabby when it came to more modern OS X too. When I finally sold it on it was running 10.4.

My least favourite is less clear-cut, I have a choice of two. But I think I’m going to give it to the Beige G3 Power Mac I borrowed long-term, I think from the University, when I was a student. This was really a slightly updated Power Mac 8600 with a faster CPU in, but the CPU’s capabilities were significantly limited by the architecture (50MHz bus, 5MBPS SCSI) which really belonged to the older 603-alike processors. I seem to remember it having some weird amount of memory, like 208MB, because I’d scrounged different chips from different places, but even with that much RAM it couldn’t do more than crawl in OS X 10.0-10.2. As with the G4 I installed Server 1.2, but many of the Java components really were staggeringly slow on this system.

Posted in whatevs | 1 Comment

Quote of the year (so far)

From David Thornley via StackOverflow:

“Best practices” is the most impressive way to spell “mediocrity” I’ve ever seen.

I couldn’t agree more. Oh, wait, I could. thud There it goes.

Posted in Business, metadev, mythicalmanmonth, rant | 1 Comment