Sunday, April 14, 2013

Flamethrower Shooting Gallery gets 2013 Grant from Burning Man

I am thrilled to report that the Flamethrower Shooting Gallery™ will be returning to Burning Man this year thanks to a wonderful grant from the Burning Man organization.

The Flamethrower Shooting Gallery is an interactive, fully participatory installation embodying the spirit of American freedom, spectacle, and friendly competition. It was created in 2007 and first appeared to the public in 2008. It is a big thrill to bring it back again in 2013.

If you are interested in being part of the Crew this year please check out our Participation Page at

Technorati Tags: ,

Saturday, October 13, 2012

Testing Private Methods with Kiwi

I recently had a good reason to test a private method in an Objective-C class (a delegate method that is only called by a 3rd party framework) and a good reason to keep the method private (only the object for which I am providing a delegate should be calling me.)

It turns out that it is easy to test private methods and properties using Kiwi: You use a category in the Spec class to do this.

I learned this in Daniel Steinberg's book "Test Driving iOS Development with Kiwi"

Technorati Tags: , , , ,

Wednesday, October 06, 2010

Just Kids: A story of two young people becoming Artists

Patti Smith's recent book "Just Kids" is a wonderfully told story of two young people (Smith and Robert Mapplethorpe) pursuing their dreams and becoming Artists. The story is told in Smith's customary tender fierceness - qualities which we can absorb and future in ourselves as we read along. I highly recommend this book to anyone interested in artistic processes.

Just Kids on Amazon

Technorati Tags: ,

Saturday, March 06, 2010

RPC - How can you be two places at once when you're not anywhere at all?

Recently I've been looking into using either XML-RPC or JSON-RPC to communicate between a Cocoa client and a PHP back-end.

I came across Samuel Sutch's Objective-C implementation of JSON-RPC and saw what to me is a curious pattern: methods with no name that take any object (id) as an argument and return an object of indeterminate type (id)

- (id):(id)arg {
  // do stuff

While this is legal in Objective-C it sure is difficult for me to follow. That said, I'm not an expert in ObjC so I consider this a learning opportunity.

I suspect that the reasoning behind this has something to do with the fact that the author is implementing a version of the "Deferred" pattern. Still, it seems like code that is very hard to maintain. I'm hoping to get in touch with the author and learn more. At a minimum I hope to become better educated.

Technorati Tags: , , ,

Thursday, July 23, 2009

Apple Professional Apps Documentation Goes on the Web

Saturday, July 18, 2009

Josh Keppel reviews some Oakland California Burning Man cultural spin-offs

Flamethrower SHooting Gallery crew member Josh Keppel is also a writer for NBC Bay Area - a San Francisco Bay Area local news and events web site. Josh recently wrote a review of some Oakland-based hot-cultire events. Have a look.

Saturday, February 28, 2009

Why Technical Debt Should Be More Visible

Recently my colleague Jeffrey Thalhammer of Imaginative Software sent me a pointer to Steve McConnell's article on Technical Debt:

Instead of sending Jeff an email with all my notes, I'm sending him a pointer to this posting.

Overall I thought the article plus the comments were very good. The comments and back-and-forth really add  a lot of value the the article and I suggest anyone reading the article make their way all the way through the comments.

I think we should write a version of this aimed entirely at non-technical people.

McConnell does acknowledge that estimating the "interest payments" is very difficult. One of the (maybe not so obvious?) reasons is that involves calculating the expected lifetime of the system, because as the article says:
When a system is retired, all of the system's technical debt is retired with it. Once a system has been taken out of production, there's no difference between a "clean and correct" solution and a "quick and dirty" solution.
So having a realistic estimate of the expected lifetime of the system make a huge difference it the expected cost of the debt.

I also like the attention that the article and comments gave to the issue of why different people may have different attitudes towards technical debt. For example, the article says:
The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred.
and commenter Robin Barooah said:
This might further explain why business people are prepared to accept technical debt - they aren't the ones who are going to have to pay it off.  The developers suffer real consequences because they aren't learning or growing by having to rework code that they knew was being done to substandard quality in the first place.
I think Barooah's comment is spot-on and indicates an often unarticulated and under appreciated difference between financial and technical debt.

The article summarizes some of this by saying that:
The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it.
I would amend that to say "so some people have" cf. Barooah's comment above, but I basically agree: making the "technical debt" more visible is fundamental to improving how it is handled. That means means finding ways to make it visible to people with different perspectives: Finding indicators that are equally meaningful to both business and technical staff would be a big help.

Technorati Tags: , , ,