constructive nonconformist

"Photoshop will now exit"

I realized tonight that Photoshop 7.0.1 doesn’t run under Mac OS X 10.5 Leopard.

Officially Adobe doesn’t support Photoshop 7.0 anymore and there will be no updates for Leopard compatibility. The consensus on various forums is that there is no work-around.

Link: Photoshop 7.0 - FixYa

I upgraded to Leopard a while ago and I’m running an old version of Photoshop, so clearly I’m not a heavy user. But I was a bit dismayed — for a moment. And then I thought “Why do I need Photoshop?”

My use of Photoshop was largely oriented toward preparing images for the web. There was a time when Photoshop was the leader among a very small number of applications that could do that job well. That’s no longer the case.

I will not be going back to Tiger for the sake of any one application. I will not be buying an upgrade from Adobe. I will be freeing up some space on my hard drive. Photoshop has left the building.

Science and Technology Television for a Seven Year Old

Television shows that my seven year old son enjoys that have science and technology content:

• MythBusters
• Fetch!
• Zula Patrol
• PEEP and the Big Wide World

Internet Explorer's Maximum URL Length

Note to self: Internet Explorer has a maximum URL size limit of 2,083 characters. Passing a longer URL (like maybe a URL with a dynamically built query string) to IE 7.0 will produce a cryptic error page (even with ‘Friendly’ turned off) that says “Internet Explorer cannot display the webpage” and then misleadingly suggests that the server can not be reached. Don’t waste time troubleshooting network connections or DNS lookups. Don’t be puzzled by why the same URL works in FireFox and Safari.

Safari 3.1 Develop Menu

SimpleBits: Safari 3.1 Develop Menu

waves

the show with zefrank: waves

(Via PragDave: Don't wear the yellow trunks.)

North Pole Voyager

A wonderful 2 minute film (that happens to be an ad.)

(Via O'Reilly Radar: Advertising Homage to the DIY Spirit (Via Adverganza: JC Penney ads rock, while sales suck))

Theory P: Software Development is Probabilistic

In my head I’ve been struggling to write a blog post about how thinking of software development as a manufacturing process is wrong. The catalyst for getting some semblance of my thoughts down was reading Reg Braithwaite’s Which theory fits the evidence?

Have you seen a car ad that shows a factory floor and an efficient automated assembly line? That’s not like software development. Have you seen a car ad that shows a design studio with a clay mock-up? That’s like software development. The guy on the factory floor can easily know how long it takes to assemble an automobile. It’s much more difficult for the guy sculpting clay to predict how much work and how many revisions it will take to get to the final design.

Software development is an exploration. It’s learning about the problem domain, the customer’s needs, and how a solution can be realized with the available resources. Learning requires space and time for experimentation and failure.

Software manufacturing, at its least adorned, is a file copy operation.

It’s tempting to believe that with enough upfront planning, analysis, and specification any software project can be made predictable and problem-free. It’s a false notion. Time is always limited. Humans are fallible. Something will always be missed or misunderstood or not understood deeply enough or new information will come to light or business conditions will change. A development process must accept and adapt for unforeseen change or it’s broken.

Avoid Order Dependencies between Object Methods

My code was calling a certain method on a certain object. I was passing all the right parameters and the method was returning garbage. What the hell.

It turned out that I needed to call another method of the same object first.

An object that depends on its methods being called in a specific order is a bad idea. There's no language that I'm aware of that supports defining ordering dependencies for the methods of an object. If I make calls in the wrong order the compiler or runtime can't tell me I've made an error. I can't treat such an object as a black box. It's leaky. I'm forced to learn something about its internals. It defeats part of the point of encapsulation. Objects should be able to handle method calls in any order.

For the code I was writing I couldn't change the offending object. It's technical debt but it wasn't my call. The best I could do was add comments so the issue wouldn't be a hidden surprise for the next developer.

A minimal fix would have been to enforce the ordering constraint by having the method call fail if the prerequisite method hadn't been called. This is crude but effective.

Since this tactic implies keeping state in the object to track if the prerequisite method has been called, it might be nice to simply call the prerequisite if it hasn't been already. If the object has a method that is a prerequisite to a large number of other methods there would be this little bit of check code duplicated across all the dependent methods. That's a little ugly. And it's not DRY. (It's one of the reasons I don't like two stage construction.) So using object state as the principal means to solve the issue may not be the best solution.

A different approach might leverage the object design. Maybe these methods shouldn't all be on the same object. The 'prerequisite' method could be a factory method that returns an object that contains the other methods. If appropriate the factory could cache the last computed object.

In a well behaved object order dependencies among methods should be either designed out or encapsulated as an implementation detail.

Kathy's zones of emotion

Link: Loud Thinking: Kathy's zones of emotion.

Yes David, I miss Kathy's blogging.

A little REST and Relaxation

Roy T. Fielding on REST: A little REST and Relaxation