Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Friday, May 31, 2013

An entirely unwarranted comparison between software engineering and astronomy

Back in the early days of astronomy, the problem of the stars that wander from fixed positions in the sky needed solving. Many astronomers, not the first of which was Ptolemy, proposed that these “planetai” could be modeled as following little curves—epicycles—through their larger motions. As it was found that these epicycles continued to fail, smaller and smaller iterations were added. It was not until astronomers realised that they were not at the centre of the universe that they realised this was an over-complicated and unnecessary model.

Here, in the early days of making software, the problem of the software that wanders from budget, quality and time expectations needed solving. Many programmers, not the first of which was Boehm, proposed that these “projects” could be modeled as following little curves—spirals—through their larger motions. As it was found that these spirals continued to fail, smaller and smaller iterations were added.

posted by Graham at 08:57  

Wednesday, May 29, 2013

Short Objective-C on the server update

It’s been over a year since I looked at GNUstepWeb as a server platform for Objective-C development. I’ve recently had time to dig in a bit more, send the project some patches, and get the platform to a state on the Mac where I can start developing apps. That took a while, in my defence I was writing a book that I wanted to get out while it was sitting on my mind.

My next step (pardon the pun) is to set up a deployment platform on Some UNIX™, and set up post-update deployment of the apps: I already created pre-commit and post-commit hooks for development. It seems that a lot of people come through this blog looking for ObjC server info, I thought it was about time for an update :-).

posted by Graham at 21:11  

Wednesday, May 29, 2013

On protocols that aren’t

There’s a common assumption when dealing with Objective-C protocols or Java interfaces (or abstract classes, I suppose): that you’re abstracting away the implementation of an object leaving just its interface. “Oh, don’t mind how I quack, all you need to know is that I do quack”. This assumption is unwarranted.

All protocols/interfaces actually tell you is that there is a list of messages, and you’ll be given an object that responds to those messages. Assuming that you can use it in the same way as any other object that responds to the same messages is a mistake. This is something I’ve written about before, but it’s time to give a concrete example.

I’ve been debugging some multi-threaded code recently, so I’ve been writing my own lock classes to try and inspect how the different threads interact. They implement the NSLocking protocol, as all the Foundation lock classes do:

The NSLocking protocol declares the elementary methods adopted by classes that define lock objects. A lock object is used to coordinate the actions of multiple threads of execution within a single application. By using a lock object, an application can protect critical sections of code from being executed simultaneously by separate threads, thus protecting shared data and other shared resources from corruption.

It defines two methods, -lock and -unlock. So, given I have an object that conforms to NSLocking, I can call -lock and -unlock just as I would on any other object that conforms to the protocol, right?

Wrong. With an NSRecursiveLock (which conforms to the protocol), I can call -lock multiple times in a row without calling -unlock. Given an NSLock (which also conforms to the protocol), I can’t. With NSLock I can’t call -unlock on a different thread than I called -lock; I could write a class where that is permitted.

As I argued in the above-linked post, protocols are actually a poor approximation for what we want to use them as: agreements on how to interact with an object via its messaging interface.

posted by Graham at 19:55  

Tuesday, May 28, 2013

I do the stupid so you don’t have to

So you want to use bc for some hexadecimal maths. You set the input base:


and the output base:


Oops! I just set it to output in base 22. I’d already set it to think numbers were input in hexadecimal, and that’s how it handled the “16” in my obase command. Either do this:


Or this:

posted by Graham at 14:48  

Thursday, May 23, 2013


Barely 4,000 years ago, documents were written on heavy, clay tablets. The Epic of Gilgamesh, one of the earliest known works of fiction, was written on 11 such tablets with a 12th added later. There was only one thing you could do with these tablets: read. Fast forward to the 21-st century and things are very different. The word “tablet” has taken on a new meaning, and documents can be delivered wirelessly, updated as new versions are written. They can also contain rich media and hyperlinked references to other content. And with these new capabilities come new considerations when preparing your documents—or “docs”—for your readers.

The above story seems rambling and pointless, doesn’t it? But change the timescale and the technology, and every single bloody report on mobile technology starts in exactly the same way.

posted by Graham at 08:52  

Tuesday, May 21, 2013

Shell scripts and Xcode

Back in 2009 at the first NSConf, Scotty asked some of the speakers for an Xcode Quick Tip. I’m still using mine today.

When your target needs a “Run Shell Script” build phase, don’t write the script into the box in Xcode’s build phases view. Instead, create the shell script as an external file and call that from the Xcode build phase. It’s easier to version control, and you can take advantage of the capabilities of external editors—particularly where your “shell script” is actually in Perl, Ruby or some similar language.

posted by Graham at 08:34  

Saturday, May 18, 2013

APPropriate Behaviour is complete!

APPropriate Behaviour, the book on things programmers do that aren’t programming, is now complete! The final chapter – a philosophy of software making – has been added, concluding the book.

Just because it’s complete, doesn’t mean it’s finished: as my understanding of what we do develops I’ll probably want to correct things, or add new anecdotes or ideas. Readers of the book automatically get free updates whenever I create them in the future, so I hope that this is a book that grows with us.

As ever, the introduction to the book has instructions on joining the book’s Glassboard to discuss the content or omissions from the content. I look forward to reading what you have to say about the book in the Glassboard.

While the recommended purchase price of APPropriate Behaviour is $20, the minimum price now that it’s complete is just $10. Looking at the prices paid by the 107 readers who bought it while it was still being written, $10 is below the median price (so most people chose to pay more than $10) and the modal price (so the most common price chosen by readers was higher than $10).

A little about writing the book: I had created the outline of the book last Summer, while thinking about the things I believed should’ve been mentioned in Code Complete but were missing. I finally decided that it actually deserved to be written toward the end of the year, and used National Novel Writing Month as an excuse to start on the draft. A sizeable portion of the draft typescript was created in that month; enough to upload to LeanPub and start getting feedback on from early readers. I really appreciate the help and input those early readers, along with other people I’ve talked to the material about, have given both in preparing APPropriate Behaviour and in understanding my career and our industry.

Over the next few months, I tidied up that first draft, added new chapters, and extended the existing material. The end result – the 11th release including that first draft – is 141 pages of reflection over the decade in which I’ve been paid to make software: not a long time, but still nearly 15% of the sector’s total lifespan. I invite you to grab a copy from LeanPub and share in my reflections on that decade, and consider what should happen in the next.

posted by Graham at 12:30  

Friday, May 17, 2013

When single responsibility isn’t possible

This posted was motivated by Rob Rix’s bug report on NSObject, “Split NSObject protocol into logical sub-protocols”. He notes that NSObject provides multiple responsibilities[*]: hashing, equality checking, sending messages, introspecting and so on.

What that bug report didn’t look at was the rest of NSObject‘s functionality that isn’t in the NSObject protocol. The class itself defines method signature lookups, message forwarding and archiving features. Yet more features are added via categories: scripting support (Mac only), Key-Value Coding and Key-Value Observing are all added in this way.

I wondered whether this many responsibilities in the root class were common, and decided to look at other object libraries. Pretty much all Objective-C object libraries work this way: the Object class from ObjPak, NeXTSTEP and ICPak101 (no link, sadly) all have similarly rambling collections of functionality.

[*] By extension, all subclasses of NSObject and NSProxy (which _also_ conforms to the NSObject protocol) do, too.

Another environment I’ve worked a lot in is Java. The interface for java.lang.Object is mercifully brief: it borrows NSObject‘s ridiculous implementation of a copy method that doesn’t work by default. It actually has most of the same responsibilities, though notably not introspection nor message-sending: the run-time type checking in Java is separated into the java.lang.reflect package. Interestingly it also adds a notification-based system for concurrency to the root class’s feature set.

C#’s System.Object is similar to Java’s, though without the concurrency thing. Unlike the Java/Foundation root classes, its copy operation (MemberwiseClone()) actually works, creating a shallow copy of the target object.

Things get a bit different when looking at Ruby’s system. The Object class exposes all sorts of functionality: in addition to introspection, it offers the kind of modifications to classes that ObjC programmers would do with runtime functions. It offers methods for “freezing” objects (marking them read-only), “tainting” them (marking them as containing potentially-dangerous data), “untrusting” them (which stops them working on objects that are trusted) and then all the things you might find on NSObject. But there’s a wrinkle. Object isn’t really a root class: it’s just the conventional root for Ruby classes. It is itself a subclass of BasicObject, and this is about the simplest root class of any of the systems looked at so far. It can do equality comparison, message forwarding (which Objective-C supports via the runtime, and NSObject has API for) and the ability to run blocks of code within the context of the receiving object.

C++ provides the least behaviour to its classes: simple constructors that are referenced but not defined can be generated.

It’s useful to realise that even supposedly simple rules like “single responsibility principle” are situated in the context of the software system. Programmers will expect an object with a “single” responsibility to additionally adopt all the responsibilities of the base class, which in something like Foundation can be numerous.

posted by Graham at 10:18  

Tuesday, May 14, 2013

More security processes go wrong

I just signed a piece of card so that I could take a picture of it, clean it up and attach it to a document, pretending that I’d printed the document out, signed it, and scanned it back in. I do that about once a year (it was more frequent when I ran my own business, but then I only signed the piece of card once).

Just a little reminder: it’s not having my signature that should be valued, it’s having seen me perform the act of signing. Signatures can easily be duplicated. If you’ve decided that I’m me, and you’ve seen me put my signature to a document, from that moment on you can know that I signed that document. If you didn’t see it, but got a validated statement from a known notary that they saw it, then fair enough. If you didn’t see it, and a notary didn’t see it, then all you know is that you have a sheet of paper containing some words and my signature. This should tell you nothing about how the two came into proximity.

posted by Graham at 17:45  

Tuesday, May 14, 2013

Could effortless lecturers make everything seem too easy?

From the British Psychological Society blog: Engaging lecturers can breed overconfidence.

The students who’d seen the smooth lecturer thought they would do much better than did the students who saw the awkward lecturer, consistent with the idea that a fluent speaker breeds confidence. In fact, both groups of students fared equally well in the test. In the case of the students in the fluent lecturer condition, this wasn’t as good as they’d predicted. Their greater confidence was misplaced.

I’m speaking at a couple of conferences later this year (iOSDev UK in Aberystwyth in September and NSScotland in Edinburgh in October), and will endeavour to be exactly as exciting as the material deserves: a capability to which my track record can attest.

posted by Graham at 12:38  
Next Page »

Powered by WordPress