To be honest, this is my first workshop of this sort and I'm a little nervous. While I've been blogging for a year and a half, I only took it seriously as part of a New Years resolution. I've been lucky enough to be in the presence of blogging giants who've been very encouraging and inspirational. I take pride in maintaining a consistent readership and having had some great discussions. I was initially reluctant to blog about food and tech, but when I get a comment like:

I am a programmer and enter to your site to read about zend… and finish commenting on the cuisine.
Delicious . I see there any patterns? (thanks Valugi!)

I realize that developers like to eat food too.

I've also managed to start a small business that's been accredited and has produced web video for all the major festivals in Montreal. We were even the Montreal Jazz Festival's official podcaster when people didn't know what that was!

Like a film critic who may know nothing about making movies, I've been around the web long enough to know what works and what doesn't, and if you can stand my voice and my french grammar slips, I invite you to come!

We must face the fact that we are on the brink of times when man may be able to magnify his intellectual and inventive capability, just as in the nineteenth century he used machines to magnify his physical capacity. Again, as then, our innocence is lost. And again, of course, the innocence, once lost, cannot be regained. The loss demands attention, not denial.
–Christopher Alexander

This week, Ian Christian’s entitled “Should you learn a framework?” ended up on PHPDeveloper. The article is excellent, however it seems like such a non-issue in other web development circles. Would a Python developer write an application without Plone or some equivalent? What about Ruby developers?

The Java and .NET communities have moved far past such questions. Not only have frameworks been design requirement, they’ve also affected where businesses position their software development. For example, a .NET shop might specialize in traditional ASP.NET, CastleProject’s full stack, the “Guidance Packages” from the Patterns & Practices group or the upcoming Microsoft MVC framework. Within Microsoft itself, you can still pick a framework geared towards the kind of development is required.

All frameworks encourage thinking of subsystems and the development of patterns. Christopher Alexander, the building architect who inadvertently gave birth to object-oriented programming, would be proud to see people using object-orientation to solve the ever increasing complexities of software development.

Will it be possible then, for people to say stonily, that poems are not real, and that patterns are nothing but images: when in fact, the world of images controls the world of matter.
–Christopher Alexander

Writing code without a framework is like building a building without specifications for the height of baseboards and door handles and then asking the architect to design a custom tubing, air conditioning, fire and burglary standards. While Alexander was talking about patterns in visual language, I think the same can be said about software development.

Patterns exist in software and every time we write from scratch, we lose the opportunity of refining an existing pattern. Accepting that software patterns exist "demands attention, not denial."

This is something that I've encountered from many professionals in my field. Often times it stems from a lack of understanding the difference between web development and web design. If anything I would argue that web development presents as many, if not more challenges to developers.

Following Best Practices

If I was a mechanical engineer, or better yet, a building architect, I could easily rattle off a list of "best practices" that are industry standard. Not following these standards would leave me jobless with no one willing to hire me. As software engineers, specifically web developers, best practices are just beginning to emerge as a business requirement.

As a freelancer, I often find myself estimating and reviewing deliverables with clients. I could imagine this being much easier if there wasn't a user interface. Traditional C++ / Java development usually involves writing servers, daemons, processes and drivers. When you're coding any of the aforementioned list, your client won't be eager to peek over your shoulder and see the color of that x86 sound card driver, or whether that enterprise service bus has the latest javascript calendar picker.

Because the resulting deliverables in a non-web application are inherantly foreign to the business, it's easier to factor in time for documentation, code reviews, versioning, testing and business analysis. The end product resembles a cake that rises rather than a bunch of really cool lego bricks that fall into place in front of your eyes.

As a web developer, factoring in the time to document, review and analyze a business model before even writing a line of code could leave the job in the hands of someone less inclined to what are considered best practices. I won't dive into Seperation of Concerns, layered development, Don't Repeat Yourself and other mantra's since they apply across the board.

Which side are you on?

Web applications, by there very nature all generate HTML, CSS and Javascript. The backend language is very different from the resulting code. Writing code for the desktop means that the compiled result is the culmination of both a client and (optionally) a server. The underlying implication is that memory and state need only be managed in one place. With the web, client-side behaviour and server-side behaviour are each treated differently, with varying levels of discoverability, security and overall weight.

How big is your pipe?

Web applications also need to deal with Caching and Bandwidth. I've had the pleasure and challenge of working with an excellent web designer who would pick one javascript framework over another if it meant he could push an extra 10kb of graphical data. Only a small subset of desktop applications even attempt to deal with bandwidth, caching, and queueing.

Sorry, I only speak english and french

Whether you're using Interface Builder, Visual Studio or some Java UI modeller, you have the luxury of being abstracted away from dealing with the visual components of an application that will sit on the desktop. This means you can stick to your desktop language of choice. A web developer needs to be comfortable dropping into a myriad of languages. Even if you're working in ASP.NET, a public website should be standards compliant (or have a good reason not to be). In order to be competitive, eventually components that are specific to a web application will need to be developed.

Visual designers for HTML and CSS don't cut it. Especially when an application is attempting to mimic a desktop experience with a lot of AJAX interactions. These can't be written without a solid understanding of HTML and CSS. Lastly, the syntactic model that a web developer starts with in a mock-up could lend to browser incompatibilities, SEO optimization issues, deficiencies for screen-reading devices, lack of portability to mobile devices or even multi-lingual requirements that could occur in the future.

Perhaps the maturity in Java / C++ development encourages more specialization, whereas a web developer needs to not only know how to code, but also needs to have a very broad skillset ranging from architecture and data modelling to design and user-interface conventions.

"Adobe TV is the online video source for anyone with wants to see how Adobe tools are being used to create stunning work," ... "It brings together experts from Adobe and the creative community to inspire and teach how to get the most from the software that is empowering the delivery of high-impact print, online, video and mobile communications. It's also the perfect showcase for Adobe's broadcast video technologies in action."

With a press snippet like that, I was really looking forward to a hands on glimpse into what professionals do with the Adobe product suite and how they create great looking professional content.

Personally, I think the most compelling piece of content on Adobe TV is an interview with Steve Krug (author of the usability book "Don't Make Me Think!"). However even in this interview with a leader in web usability, this piece of content is prefaced by what feels like an endless bumper at the beginning. While the content is great, this "interview" is composed of two questions! Regardless, it's still worth hearing this man speak his mind about usability and making its need apparent within a corporation.

Dennis Redeke does a great job with his beginner classes, while the green screen at the beginning doesn't have the same production value of Greg Rewis' videos, the content is targeted at beginners, it's clear and he doesn't try and burden the viewer with information that is irrelevant. Furthermore, in his opening remarks for video two in his series, tell that he's already adjusting his programming to match the pace of his viewers.

The actual site is well designed and I think it shows how great Flex can be at delivering a great user experience with content streaming from a web services (judging by how all videos are organized associatively and by their relative popularity, date of publish etc..). The video streams beautifully and one can't help but browse through the modest content library.

However, where the site falls short is in dealing with the three headed monster that Adobe's trying to push with Adobe TV. Namely:

1. "to see how Adobe tools are being used to create stunning work,"

2. to bring " together experts from Adobe and the creative community to inspire and teach how to get the most from the software"

3. and as the "perfect showcase for Adobe's broadcast video technologies in action."

Teaching people (1) how to use adobe products is very different from showcasing creative experts (2). Furthermore, this is all very different from showcasing Adobe technologies specifically. What ends up happening is that videos tend to fall into one of two camps, however they become very technology-specific. What adds to the ambiguity are the "Buy", "Try" and "Learn More" buttons next to every video. These buttons aren't about supporting the content creators, but rather, are links to purchasing adobe products. In short, I kept wondering if I was supposed to be learning, if I was supposed to be entertained or if I was watching an advertisement.

The immediate comparison that comes to mind is Apple's "Get a Mac" ads (which are labelled as such) versus their tutorials on the product websites and their carefully produced vignettes done on the "Aperture in Action" section where different professionals are interviewed about their artwork, and how Apple products are implicitly referred to. Apple nails this by providing distinct content sections for each video - we know we're watching an ad, we know we're meant to learn something, we know were gaining a glimpse into a photographers workflow.

While I see a lot of noble efforts by people like Denis Redeke and Donald Booth, the videos produced by Greg Rewis, a product evangelist who joined adobe when they were acquired by Macromedia, leaves me wondering who he's trying to evangelize. His videos fired my interest since they sounded like screencasts, and an opportunity to see the professionals at Adobe doing screencasts would be a great learning opportunity for yours truly.

What really soured the video was his opinions about cell phones and how they characterized a certain cultural demographic that he's generalized as the only demographic doing CSS or is able to afford and use Adobe products:

"How many of you have a cell phone? Everybody, stupid question"

"I mean, everybody's got a cell phone right? Have you surfed the web on it?"

"Cell phones today have browsers!"

He then goes on to characterize the W3C as "guys in the Himelayas", essentially dodging the corporate backing of the standards body, to which Adobe sits on. Such a reference to the W3C might be appropriate when you've worked as a web developer for over a decade, however by including such a comment in a video entitled "Introduction to CSS", you've simply built camps around web standards instead of providing a beginner with the knowledge to make sound web production decisions.

The video gets worse when you suffer through him sticking his fingers in his ears yelling "la la la la" as a way of depicting the authors of early websites who denied the use of CSS, as though it was mere ignorance that drove people away from adopting table layouts. He goes on to aggrandize the problems table layouts faced and their impact on early web development.

While these comments alone wouldn't bother me, what does is the tone. When I hear Gregg Rewis ask for a raise of hands from his audience in an attempt at breaking the fourth wall, I ask myself what was left behind when Brecht engaged his audience so emphatically, and controversially as a mid-20th century playwright and where Greg Rewis went wrong.

If Adobe wants to make content that's educational around their product suite, it's entirely unnecessary to hear a product evangelist mock Photoshop over Fireworks (or vice versa), which he does towards the end of the video about workflow. I would think that with such tools being over a decade old, we could transcend the pissing contest and focus on getting our respective jobs done, quickly and effectively and do away with the politics surrounding our tools. When I compare this video with Donald Booth's, who takes us into his world of photographing a building next to his office for several months, you realize the diverse culture inside of Adobe. I can't help but share in Booth's love of capturing an evolving construction site, and while he isn't a product evangelist like Greg Rewis, his description of how he uses Adobe After Effects to make time laps footage feels like a natural extension of his artistic process. The tools Booth is using transcend their corporate backing and appear to simply be a part of his language as a content producer.

I hope that Adobe TV matures into something that feels less like product rhetoric and captures some of the beautiful by-products of such a powerful suite of tools. Personally, I'm looking forward to the day I see an interview with Veerle.

Thanks to Ray for the feedback and editing.