Closer To The Ideal

I write this as a note to myself, because I want to go back and look more at these systems. I’ve spent the last year developing my own scaffolding system in PHP, and like most people working on a PHP framework, I’ve been inspired by Ruby On Rails. What programmers want, nowadays, is a system that automates a lot of the grunt work of gettting a new project started. What I didn’t realize is that many people working with Ruby On Rails have given up using the default, built-in scaffolding system and are instead using 3rd party scaffolding systems. There are a wealth of these, and some of them look quite amazing. I need to go back and these out when I have more time:

 Hobo

Streamlined

ActiveScaffold

Taylor’s career was 30 years old when “management” became a recognized profession during the 1920s. Likewise, people have been software engineers for the last 50 years, but the field has been slow to coalesce the practices and disciplines that one associates with a profession. Jeff Atwood has a nice piece on the youth of computer science. My favorite part:

As in all programming, the idea is to notice when the same solution is appearing repeatedly in different contexts and to understand the commonalities. This is admirable and valuable. The problem with the “Design Patterns” movement is the use to which the patterns are put afterward: programmers are trained to identify and apply the patterns when possible. Instead, the patterns should be used as signposts to the failures of the programming language. As in all programming, the identification of commonalities should be followed by an abstraction step in which the common parts are merged into a single solution.

Multiple implementations of the same idea are almost always a mistake in programming. The correct place to implement a common solution to a recurring design problem is in the programming language, if that is possible.

The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.

Stumbled upon this and found it interesting:

Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface.

This article is old, but the issue is still current. Way back in 2002, Drew McLellan wrote an article for A List Apart explaining how to embed Macromedia Flash movies in valid XHTML web pages (his method was called Flash Satay). This is a sticky issue, because most of the examples on the web show you techniques (for embedding Flash on a page) that are invalid. The main issue is the use of the EMBED tag, which is often still used for backwards compatibility, but which is not supported in XHTML. We’re still cleaning up our own incorrect use of the EMBED tag over at our new iHanuman site.

In 2004, Drew wrote a post on his weblog, complaining that developers still had to jump through hoops to get valid markup while delivering a smoothly functioning Flash movie to users.

The juicy part is the conversation that breaks out in the comments. John Dowdell of Macromedia asks what data would justify an investment of effort on Macromedia’s part. To which Drew responds:

Pretty much all I’ve ever heard from Macromedia on this issue is where’s the hard data? over and over again. That’s understandable. It’s an important issue, and it affects an awful lot of Macromedia customers. If Macromedia Flash were my product, earning me thousands (millions?) of dollars each year, I would be looking for answers to those questions.

But it’s not my product – it’s yours. I don’t have QA engineers, test facilities or experts in every aspect of the technology on hand. It’s not in my interest to make sure Flash can be used with liveconnect or wmode in modern web sites – only whether I can accomplish the task I need to accomplish today for the audience I’m targeting. Simply put, it’s not my problem. It’s yours. Can your product remain viable in a world where the standard mark up language excludes its use?

You guys tell me, John – have you got any hard data? I think your customers would like to see it too.

John Dowdell responded:

“But it’s not my product – it’s yours.” Actually, no… you’re attempting to describe how the various browsers invoke extensions. Going to the browser-makers’ documentation is the first step. Testing their various implementations is the next step.
…
The core, underlying problem has been that the W3C’s HTML group set their EMBED-denying spec late, a few years after the browser manufacturers and the web-development community had been using EMBED and OBJECT to invoke extensions, and the W3C never supplied a path for the real world to join their ideal world. It is a messy process to suddenly tell the real world that it is wrong.

To which Drew responds:

You mean When will it become safe to continue using Flash? ;)

I don’t believe this is purely a browser issue. Macromedia are selling a product and recommending its use on the web. Isn’t it due diligence to test it in that environment? And to keep retesting as the environment changes? There seems to be some complacency that as Flash worked fine in HTML4 pages back in 1997 it’s fine to carry on that way. I personally don’t know of any professionals build new sites using the HTML4 of 1997.

John Dowdell responds:

What you’re trying to address now is the W3C’s sudden deprecation of an existing tag. If you recommend to others that they shun EMBED, then it’s good to first test what the actual results are.

To which Drew responds:

There’s very little about the adoption of XHTML that is sudden. The recommendation itself is four years old. The fact that professional developers have already adopted XHTML means that no one is recommending EMBED be shunned. It’s been shunned. Flash is already out in the cold – we’re just looking for ways to let it back in.

Bruce Collier then sums up what is my own reaction to the debate:

I have to second Drew on this point. It’s a little surprising (and disconcerting) to hear a Macromedia employee asking the community to provide data on browser support issues, and even more surprising to think that Macromedia isn’t constantly testing these issues for themselves. “Due diligence” is a very good way to describe it.

Pointing the finger at the W3C and browser makers and saying it’s too hard isn’t really an answer either. On behalf of developers out there creating and publishing Flash content every day, please please work your butt off to improve how Flash is implemented… so we can have faith that Flash has a future on a standards-based web.

It is really worrisome that an employee at Macromedia (now Adobe) would seem so unconcerned with the issue of standards.