Senseless Figures in Front of a Mirror

My observations of some individuals in the world of software modelling and, previously, in the misnamed “academic” sector, remind me of a story by Carlos Castaneda in his book, “The Active Side of Infinity”. Castanada’s friend recommends that he visits a prostitute called Madame Ludmilla. Castanada relates that Madame Ludmilla’s speciality is dancing in front of a mirror, where she twirls round and round to a “haunting melody”:

She dropped her red robe, kicked off her slippers, and opened the double doors of two armoires standing side by side against the wall. Attached to the inside of each door was a full-length mirror. “And now the music, my boy” Madame Ludmilla said, then cranked a Victrola that appeared to be in mint condition, shiny, like new. She put on a record. The music was a haunting melody that reminded me of a circus march.

“And now my show” she said, and began to twirl around to the accompaniment of the haunting melody…

“And now, figures in front of a mirror!” Madame Ludmilla announced while the music continued.

“Leg, leg, leg!” she said, kicking one leg up in the air, and then the other, in time with the music. She had her right hand on top of her head, like a little girl who is not sure that she can perform the movements.

“Turn, turn, turn!” she said, turning like a top.

“Butt, butt, butt!” she said then, showing me her bare behind like a cancan dancer.

She repeated the sequence over and over until the music began to fade when the Victrola’s spring wound down. I had the feeling that Madame Ludmilla was twirling away into the distance, becoming smaller and smaller as the music faded.

Castaneda relates this story to his teacher, the shaman and sorcerer, Don Juan, who remarks that this story must be included in Castanada’s collection of stories, because “it touches every one of us human beings.” Don Juan explains:

“You see, like Madame Ludmilla, every one of us, young and old alike, is making figures in front of a mirror in one way or another. Tally what you know about people. Think of any human being on this earth, and you will know, without the shadow of a doubt, that no matter who they are, or what they think of themselves, or what they do, the result of their actions is always the same: senseless figures in front of a mirror.”

And that’s exactly what I see in both the “academic” world and the world of software modelling – senseless figures in front of a mirror.

Software Craftsmanship

I was beginning to wonder if anyone cared about quality over price in anything any more. We see it everywhere – macdonalds, supermarkets. and in software. it seems like a race to the bottom in the X factor generation.

Another term is artisan. As used by Beedocs

I like that term but was disappointed in the reaction it got here:

Don’t be a Coder, Engineer, or Developer: be a Software Artisan!

As the guitarist Robert Fripp says in one of the Guitar Craft aphorisms, “how we hold the pick is how we organise our lives”.

And then I discovered Software Craftsmanship by Sandro Mancuso.

Software Craftsmanship

…we can say that Software Craftsmanship is a better metaphor for software development than software engineering. Software Craftsmanship sees software as a craft and compares software developers to medieval blacksmiths.

Mancuso’s personal definition of “Software Craftsmanship”:

Software craftsmanship is a long journey to mastery. It’s a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques, and constantly bettering themselves. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.

And, for me, the key phrase:

[to] delight customers helping them achieve whatever they want to achieve

These are important qualities to have in our lives and in our code. To paraphrase Fripp – “how we write our code is how we organise our lives”.

Developers are taking the matter into their own hands and are trying to change how the industry sees software development. They are doing that not just by proposing new and revolutionary processes but also by showing their customers that they care about what they do. Developers are showing their customers they want to work together with them in order to produce great and long-lived software, helping them to achieve whatever they want to achieve.

(Emphasis mine)

Perhaps if more software “engineers” played a musical instrument, painted, or were artists they might like the term “artisan” or “craftsman”.

And I particularly loathe the term “Software Engineer”. I am not an engineer. Isambard Kingdom Brunel was an engineer. I would rather be called a “hacker” than an “engineer”. (Actually, my chosen term is “code punk”).

Asynchronous Unit Testing in Xcode 6

Last year I described a method to implement asynchronous unit testing in Xcode 5.

Let’s remind ourselves of the problem with asynchronous unit testing. Many APIs on the iOS platform themselves are asynchronous. They have use callback invocations to signal when they’re completed, and these may run in different queues. They may make network requests or write to the local file system. These can be time-consuming tasks that need to run in the background. This creates a problem because tests themselves run synchronously. So our tests need to wait until they are notified of when the running task has completed.

I proposed a method that entailed setting a boolean flag in the unit test and looping in a while() loop until the flag was set to false, allowing the test to complete properly. This method worked most of the time but I have never been happy with it, regarding it as a bit of a kludge. In that blog post I concluded:

I still have my reservations about this technique, and I’m still looking for the perfect solution for asynchronous unit testing in Xcode. You would think that Apple might have provided a solution in XCTest, perhaps similar to the implementation in GHUnit.

Here’s what the Objective-C version of a bare bones example asynchronous unit test in Xcode 5 using the old method looks like:

In fact, because I was re-using the same pattern in many of my tests, I converted parts of it to a Macro that had to be included in each header file. Also, I noted that under some conditions the test didn’t complete properly.

Well, the good news is that, less than a year later, Apple have delivered a means to implement asynchronous unit tests in an intelligent and offcially supported way. Furthermore, not only have they given us a new version of Xcode 6 (still in beta at the time of writing) with this new unit testing framework, but they have also delivered a brand new programming language, Swift. I’ve spent some time over the last few weeks converting a hefty chunk of Objective-C code to Swift, and in converting my Unit Tests to the XCTest framework I implemented Apple’s new methods for asynchronous unit testing. From now on, all of my iOS coding is going to be done in Swift, so the examples below will be in Swift, too.

So, how does it work? In Xcode 6 Apple have added some extensions to the XCTestCase class, and I’m going to focus on two of them:

There’s also a new class, XCTestExpectation which has one method:

Basically, you declare an “expectation” in your unit test, and loop in a wait loop waiting for the expectation to be fulfilled in your code. It’s the same pattern as before, but with more options. Here’s the old Objective-C code converted to Swift using the new framework:

In line 6 we instantiate a new instance of XCTestExpectation, named readyExpectation. We give it a simple description for convenience, “ready”. This will be displayed in the test log to help diagnose failures. It is also possible to set more than one expectation as a condition. Then in line 9 we make the call to the code that needs to be tested. In the completion handler, after making our tests, we call the method fulfill() on the expectation. This is equivalent to setting the flag to false in our earlier Objective-C implementation.

The last block of clode starting at line 18 runs the run loop while handling events until all expectations are fulfilled or the timeout is reached. I set the timeout to 5 seconds to be on the safe side.

And that’s about it. There’s more you can do with the new additions to the unit test framework, such as key-value observing, and performance metrics, but the above should be sufficient to get going. Finally, we have a proper framework for Asynchronous Unit Testing in Xcode!

Eclipse and Asynchronous Unit Testing

I’ve been retro-fitting hundreds of JUnit tests to Archi‘s code base. It’s a Zen meditation, as the process of devising the unit tests ensures that I re-engage with the code, clean things up, refactor here and there, and finally understand what that nifty algorithm does that I wrote 3 years ago. Like children not eating their greens, no-one wants to write unit tests. But it’s a valuable thing to do and rewarding, especially when you see the green bar in Eclipse:


Perhaps the process of testing and being rewarded by the green bar is an example of “gamification”? Maybe, but I’m not interested in vacuous neologisms, I’d rather just get stuff done.

Some tests that I wrote were failing. The code that these tests was calling depended on events occurring in the UI of the application, such as an editor window opening. The tests were finishing before the editor window opened. Not sure what to do about this I went for a jog to have a think. And then I remembered that I already had the answer in one of my own posts, Xcode and Asynchronous Unit Testing. This has turned out to be quite a popular post in the Xcode and Objective-C community, solving a common problem. So I wondered if Eclipse would be happy with a similar pattern. I’m never sure what’s going to happen when I start playing with threads and dispatch queues.

Here’s my solution, an abstract Java class called “AsyncTestRunner”.

This class implements Runnable which has one method, run(). This run() method will be called by the current Display instance asynchronously in this line:

Meanwhile the read and dispatch process will go off and do its thing in the event loop:

This ensures that UI tasks can be completed.

Here’s an example of how we use it:

Here, we create a new anonymous instance of AsyncTestRunner and implement run() with the testing code and then call its start() method. Be sure to call super() in the run method to invoke stop() which sets a boolean flag to false which breaks the event loop in the start() method.

The class may seem verbose with its stop() method, you could simply directly set the waiting flag to false, but I wrote it like this so it can be sub-classed and to make it obvious what’s going on. I also like the idea of a run() method consisting of one stop() method.

Very Zen.

So far it works in both Eclipse 3.8.2 and Eclipse 4.4. I may find a gotcha further down the line, and I may refine the class in the future, but so far it’s looking good. If it can be improved I’d be glad to hear about it.

Draw a line in the sand

I’m reading the book “Rework” by Jason Fried and David Heinemeier Hansson. It’s the right book for me to read right now. I’ve been thinking that as David is to Goliath, so is Archi to other tools. And here’s a quote from the book that resonates with that thought:

As you get going, keep in mind why you’re doing what you’re doing. Great businesses have a point of view, not just a product or service. You have to believe in something. You need to have a backbone. You need to know what you’re willing to fight for. And then you need to show the world.

A strong stand is how you attract superfans. They point to you and defend you. And they spread the word further, wider, and more passionately than any advertising could.

Strong opinions aren’t free. You’ll turn some people off. They’ll accuse you of being arrogant and aloof. That’s life. For everyone who loves you, there will be others who hate you. If no one’s upset by what you’re saying, you’re probably not pushing hard enough. (And you’re probably boring, too.)

Lots of people hate us because our products do less than the competition’s. They’re insulted when we refuse to include their pet feature. But we’re just as proud of what our products don’t do as we are of what they do.

We design them to be simple because we believe most software is too complex: too many features, too many buttons, too much confusion. So we build software that’s the opposite of that. If what we make isn’t right for everyone, that’s OK. We’re willing to lose some customers if it means that others love our products intensely. That’s our line in the sand.

Sand Line

But, of course, lines can always be re-drawn. Boundaries are constantly shifting depending on demand and opportunities. Perhaps, too, the wind will blow away the line in the sand and a new one drawn?

Zombie Organisations

Max Keiser rails against “zombie” banks, and rightly so as the economy suffers from the life-draining consequences of these wretched institutions. A zombie bank is a bank that that has an economic net worth of zero, or less than zero, but continues to operate as a result of government backings or bailouts.

But what about zombie organisations?

A zombie organisation is an organisation that also has a net worth of zero, or less than zero, since it has had all of its life-blood drained out of it and yet somehow, inexplicably, continues to walk the earth. Or, more accurately, the life-blood has left it – the good people of the organisation, the creative and honest people, have long since left to go onto better things, no longer able to endure the lack of management, and the incompetence and solipsism of the zombie organisation’s funeral directors. However, unlike the zombie banks, the zombie organisation is not being bailed out and instead has lost its source of funding, its fiscal blood supply, and yet stumbles on relentlessly, zombie-like, pursuing its mindless course.

I don’t know which is the saddest, the zombie bank or the zombie organisation. At least you can understand how the zombie bank continues in its unfortunate existence, pumped with the blood of tax-payers’ money. But how do you explain the continued existence of the zombie organisation, deprived of the blood of funding, unwanted even by its own host organisation, circling itself in its own uselessness and redundancy? Just how do you put the zombie organisation out of its misery?