Purple Question

I just finished Purple Cow. In the book, Seth Godin asks one very intelligent question a number of different ways.

What are you doing to create a remarkable experience for the person who will consume your product?

The foundation Godin uses to answer this question is a mixture of anecdotal evidence and rational thought. The choice of case studies and source material makes the answers compelling narratively but prone to criticism from a scientific standpoint, similar to the work of Malcolm Gladwell. I do feel, however, that the question is an interesting litmus test for the work that I do as an application developer. It works in interviews, in code reviews, in strategy meetings, everywhere. It's rare that a single question can cut to the chase like that and cross domains with ease. Pretty awesome.

Coders in Transit

Cover of Coders at Work

Yesterday I was in transit for twelve hours door to door. While I wasn't sleeping or on conference calls regarding secure video for the web, I read three chapters of Coders at Work.

There is a fascinating and nuanced history to the development of software engineering and it's a shame that so little of the field is dedicated to capturing it in a permanent form. It's fortunate that Peter Seibel had the foresight to interview the people directly involved in the making of that history and disseminate their thoughts to the rest of us.

Read it. It's awesome.

You put your disease in me. It helps me. It makes me strong.

Image via Wikipedia

I've heard several people talk about test infection over the past two years. I am going on the record right now. I don't think that having tests means that the code base itself is good. I do wish, however, that there were tests for the code base that I am troubleshooting right now.

I understand that there were operational concerns with providing the ability for full testing. I understand that I bowed to those concerns. I now wish that I hadn't. It forces development into a reactive rather than a proactive stance when it comes to addressing live errors. And that just sucks. Code needs innoculation against the dangers of the wild. Hasn't Dorothy Vallens taught me anything? Argh.

Linking it all together

Part of my day was spent researching web services for semantic data extraction from text, including Zemanta, a service designed to improve the quality of blog content by making it easy to add links, images, and tags to posts.

The service provides a REST API, browser plug-ins, and server side plug-ins for major CMS systems (think Drupal). I am using the Firefox plugin right now. So if you see a bunch of ultra-linked blog posts with pretty pictures and egregious tagging, well, you know who to come after.

Loving the Clouds

The grayness of the day has kept me indoors, researching cloud computing providers for my side projects. Operations engineering has never been one of my strong suits, or one of my weak suits, or for that matter anything that I would want to put on my body ever, so deploying web applications on the cloud is a clear plus for me.

After judging the lay of the land, I settled on Aptana Cloud (the one with the Joyent Accelerator under the hood) as my provider. I found Amazon's EC2 unappealing as I would have to configure my image from scratch, and Google's AppEngine would force me to build my applications on top of an incredibly proprietary stack.

Aptana's solution is both easier to configure than the Amazon solution and based on an open source stack, unlike Google's solution. All I have to do is push the application from the Eclipse based IDE that I already develop in for personal projects and everything "just" works.

I even get source control and staging sites. Between this and Basecamp I don't think there's anything that can stop a web entrepreneur with a great idea .

Give me chains, or give me death!

On my current project the component developers are moving towards constructor-based dependency injection. But here's the thing. I think that constructor-based injection looks ugly. There. I said it. I understand why it's there but it's ugly and verbose and I think that we might be using it as a workaround for more serious problems within our software architecture instead of using it for its intended purpose.

How many objects do you inject into a business object's constructor before that creates a code smell of its own? And what are the types of things that should be injected into a business object? I'm not entirely comfortable injecting business objects that our teams wrote into other business objects that our team wrote when we wrote both and we're not crossing an architectural layer. I may be wrong, but it just feels awkward.

It seems like maybe in our quest to create independent assemblies we forgot that it is possible to create logical dependency chains between assemblies and now we may be using constructor based dependency injection to work around our egregious independence.

Browser === Arby's

A MIX09 presentation by Nate Koehchley has brought to mind the muddle that is front end engineering. Where server side programmers are surgeons performing in an operating room, client side programmers are first responders. Nothing is sterile and we're trying to stop the bleeding in the middle of an Arby's. At times it's an exercise in futility that I have grown to love. Honestly. I love the cornucopia of specifications and the strange interpretations of those specifications and even the bugs in the strange interpretations of those specifications.

In a related note, I have also been reading The Forever War. Dexter Filkins reminisces that it was difficult to return from Iraq because the conflict became a part of him. Holding on to whatever tatters of the situation he could gave him purpose. I don't want to directly compare client side programming to the middle east conflict, of course, but I have formed a strong bond with what was formerly "the most hostile programming environment ever devised", and while I wouldn't say no to a kinder and gentler way to write software on the web, I would miss the constant challenge.

Sometimes Arby's is just an exciting place to be.

Public schooled

Returning to the world of statically typed languages, I am reminded of how weak the public access specifier is from an architectural perspective. Private is fine. Internal is fine. But public is a nightmare. Public in what context, or rather, public to what other assemblies?

Assemblies and their connectivity is a topic that I studied in graduate school but haven't thought of in a while. Like any important topic, however, it's coming up again. In any software project of reasonable size, there are certain assemblies that should not reference any part of one another in order to ensure the manageability of the system as a whole.

Such references will not cause compile time errors because they do not cause a conflict in the traditional sense of the word. The result is an architectural conflict rather than a computation conflict. And I know of no mechanisms that have filtered down from the research community to make such references rain warnings down upon anyone who would try to make them.

Gar.