The first thing you need to know about captions and subtitles is that captions and subtitles are different. The second thing you need to know about captions and subtitles is that you can safely ignore the differences unless you’re creating your own from scratch. I’m going to use the terms interchangeably throughout this article, which will probably drive you crazy if you happen to know and care about the difference.

Historically, captioning has been driven by the needs of deaf and hearing impaired consumers, and captioning technology has been designed around the technical quirks of broadcast television. In the United States, so-called “closed captions” are embedded into a part of the NTSC video source (“Line 21″) that is normally outside the viewing area on televisions. In Europe, they use a completely different system that is embeddable in the PAL video source. Over time, each new medium (VHS, DVD, and now online digital video) has dealt a blow to the accessibility gains of the previous medium. For example:

• PAL VHS tapes did not have enough bandwidth to store closed captions at all.
• DVDs have the technical capability, but producers often manage to screw it up anyway; e.g. DVDs of low-budget television shows are often released without the closed captions that accompanied the original broadcast.
• HDMI cables drop “Line 21″ closed captions altogether. If you play an NTSC DVD on an HDTV over HDMI, you’ll never see the closed captions, even if the DVD has them.

And accessible online video is just fucking hopeless. (And no, it won’t change unless new regulation forces it to change. When it comes to captioning, Joe Clark has been right longer than many of you have been alive.)

So even in broadcast television, captioning technology was fractured by different broadcast technologies in different countries. Digital video had the capability of unifying the technologies and learning from their mistakes. Of course, exactly the opposite happened. Early caption formats split along company lines; each major video software platform (RealPlayer, QuickTime, Windows Media, Adobe Flash) implemented captioning in their own way, with levels of adoption ranging from nil to zilch. At the same time, an entire subculture developed around “fan-subbing,” i.e. using captioning technology to provide translations of foreign language videos. For example, non-Japanese-speaking consumers wanted to watch Japanese anime films, so amateur translators stepped up to publish their own English captions that could be overlaid onto the original film. In the 1980s, fansubbers would actually take VHS tapes and overlay the English captions onto a new tape, which they would then (illegally) distribute. Nowadays, translators can simply publish their work on the Internet as a standalone file. English-speaking consumers can have their DVDs shipped directly from Japan, and they use software players that can overlay standalone English caption files while playing their Japanese-only DVDs. The legality of distributing these unofficial translations (even separately, in the form of standalone caption files) has been disputed in recent years, but the fansubbing community persists.

Technically, there is a lot of variation in captioning formats. At their core, captions are a combination of text to display, start and end times to display it, information about where to position the text on a screen, fonts, styling, alignment, and so on. Some captions roll up from the bottom of the screen, others simply appear and disappear at the appropriate time. Some caption formats mandate where each caption should be placed and how it should be styled; others merely suggest position and styling; others leave all display attributes entirely up to the player. Almost every conceivable combination of these variables has been tried. Some forms of media try multiple combinations at once. DVDs, for example, can have two entirely distinct forms of captioning — closed captioning (as used in NTSC broadcast television) embedded in the video stream, and one or more subtitle tracks. DVD subtitle tracks are used for many different things, including subtitles (just the words being spoken, in the same language as the audio), captions for the hearing impaired (which include extra notations of background noises and such), translations into other languages, and director’s commentary. Oh, and they’re stored on the DVD as images, not text, so the end user has no control over fonts or font size.

Beyond DVDs, most caption formats store the captions as text, which inevitably raises the issue of character encoding. Some caption formats explicitly specify the character encoding, others only allow UTF-8, others don’t specify any encoding at all. On the player side, most players respect the character encoding if present (but may only support specific encodings); in its absence, some players assume UTF-8, some guess the encoding, and some allow the user to override the encoding. Obviously standalone caption files can be in any format, but if you want to embed your captions as a track within a video container, your choices are limited to the caption formats that the video container supports.

And remember when I said that there were a metric fuck-ton of audio codecs? Forget that. There are an imperial fuck-ton of caption formats (i.e. multiply by 9/5 and add 32). Here is a partial list of caption formats, taken from the list of formats supported by Subtitle Workshop, which I used to caption my short-lived video podcast series:

Adobe Encore DVD, Advanced SubStation Alpha, AQTitle, Captions 32, Captions DAT, Captions DAT Text, Captions Inc., Cheetah, CPC-600, DKS Subtitle Format, DVD Junior, DVD Studio Pro, DVD Subtitle System, DVDSubtitle, FAB Subtitler, IAuthor Script, Inscriber CG, JACOSub 2.7+, Karaoke Lyrics LRC, Karaoke Lyrics VKT, KoalaPlayer, MacSUB, MicroDVD, MPlayer, MPlayer2, MPSub, OVR Script, Panimator, Philips SVCD Designer, Phoenix Japanimation Society, Pinnacle Impression, PowerDivX, PowerPixel, QuickTime Text, RealTime, SAMI Captioning, Sasami Script, SBT, Sofni, Softitler RTF, SonicDVD Creator, Sonic Scenarist, Spruce DVDMaestro, Spruce Subtitle File, Stream SubText Player, Stream SubText Script, SubCreator 1.x, SubRip, SubSonic, SubStation Alpha, SubViewer 1.0, SubViewer 2.0, TMPlayer, Turbo Titler, Ulead DVD Workshop 2.0, ViPlay Subtitle File, ZeroG.

Which of these formats are important? The answer will depend on whom you ask, and more specifically, how you’re planning to distribute your video. This series is primarily focused on videos delivered as files to be played on PCs or other computing devices, so my choices here will reflect that. These are some of the most well-supported caption formats:

• SubRip
• SubStation Alpha
• MPEG-4 Timed Text
• SAMI
• SMIL

SubRip

SubRip is the AVI of caption formats, in the sense that its basic functionality is supported everywhere but various people have tried to extend it in mostly incompatible ways and the result is a huge mess. As a standalone file, SubRip captions are most commonly seen with a .srt extension. SubRip is a text-based format which can include font, size, and position information, as well as a limited set of HTML formatting tags, although most of these features are poorly supported. Its “official” specification is a doom9 forum post from 2004. Most players assume that .srt files are encoded in Windows-1252 (what Windows programs frequently call “ANSI”), although some can detect and switch to UTF-8 encoding automatically.

Because .srt files are so often published separately from the video files they describe, the most common use case is to put your .srt file in the same directory as your video file and give them the same name (up to the file extensions). But it is also possible to embed SubRip captions directly into AVI files with AVI-Mux GUI, into MKV files with mkvmerge, and into MP4 files with MP4Box.

You can play SubRip captions in Windows Media Player or other DirectShow-based video players after installing VSFilter; in QuickTime after installing Perian; on Linux, both mplayer and VLC support it natively.

SubStation Alpha

SubStation Alpha and its successor, Advanced SubStation Alpha, are the preferred caption formats of the fansubbing community. As standalone files, they are commonly seen with .ssa or .ass extensions. They have a spec longer than three paragraphs. They are actually miniature scripting languages. A .ass file contains a series of commands to control position, scrolling, animation, font, size, scaling, letter spacing, borders, text outline, text shadow, alignment, and so on; and a series of time-coded events for displaying text given the current styling parameters. It has support for multiple character encodings.

The playing requirements for SubStation Alpha captions are almost identical to SubRip. The same plugins are required for Windows and Mac OS X. On Linux, mplayer prides itself on having the most complete SSA/ASS implementation.

MPEG-4 Timed Text

a.k.a. “MPEG-4 Part 17,” a.k.a. ISO 14496-17, MPEG-4 Timed Text (hereafter “MP4TT”) is the one and only caption format for the MP4 container. It is not a file format; it is only defined in terms of a track within an MP4 container. As such, it can not be embedded in any other video container, and it can not exist as a separate file. (Note: the last sentence was a lie; the MPEG-4 Timed Text format is really the 3GPP Timed Text format, and it can very much be embedded in a 3GPP container. What I meant to say is that the format can not be embedded in any of the other popular video container formats like AVI, MKV, or OGG. I could go on about the subtle differences between MPEG-4 Timed Text in an MP4 container and 3GPP Timed Text in a 3GPP container, but it would just make you cry, and besides, technical accuracy is for pussies.)

MP4TT defines detailed information on text positioning, fonts, styles, scrolling, and text justification. These details are encoded into the track at authoring time, and can not be changed by the end user’s video player. The most readable description of its features is actually the documentation for GPAC, an open source implementation of much of the MPEG-4 specification (including MP4TT). Since MP4TT doesn’t define a text-based serialization, GPAC invented one for their own use; since their format is designed to capture all the possible information in an MP4TT track, it turns out to be an easy way to read about all of MP4TT’s features.

MP4Box, part of the GPAC project, can take an .srt file and convert it into a MPEG-4 Timed Text track and embed it in an existing MP4 file. It can also reverse the process — extract a Timed Text track from an MP4 file and output a .srt file.

On Mac OS X, QuickTime supports MP4TT tracks within an MP4 container, but only if you rename the file from .mp4 to .3gp or .m4v. I shit you not. (On the plus side, changing the file extension will allow you to sync compatible video to an iPod or iPhone, which will actually display the captions. Still not kidding.) On Windows, any DirectShow-based video player (such as Windows Media Player or Media Player Classic) supports MP4TT tracks once you install Haali Media Splitter. On Linux, VLC has supported MP4TT tracks for several years.

SAMI

SAMI was Microsoft’s first attempt to create a captioning format for PC video files (as opposed to broadcast television or DVDs). As such, it is natively supported by Microsoft video players, including Windows Media Player, without the need for third-party plugins. It has a specification on MSDN. It is a text-based format that supports a large subset of HTML formatting tags. SAMI captions are almost always embedded in an ASF container, along with Windows Media video and Windows Media audio.

Don’t use SAMI for new projects; it has been superceded by SMIL. For historical purposes, you may enjoy reading about creating SAMI captions and embedding them in an ASF container, as long as you promise to never, ever try it at home.

SMIL

SMIL (Synchronized Multimedia Integration Language) is not actually a captioning format. It is “an XML-based language that allows authors to write interactive multimedia presentations.” It also happens to have a timing and synchronization module that can, in theory, be used to display text on a series of moving pictures. That is to say, if you think of SMIL as a way to provide captions for a video, you’re doing it wrong. You need to invert your thinking — your video and your captions are each merely components of a SMIL presentation. SMIL captions are not embedded into a video container; the video and its captions are referenced from a SMIL document.

SMIL is a W3C standard; the most recent revision, SMIL 3.0, was just published in December 2008. If you printed out the SMIL 3.0 specification on US-Letter-sized paper, it would weigh in at 395 pages. So don’t do that.

QuickTime supports a subset of SMIL 1.0. WebAIM provides a nice tutorial on using SMIL to add captions to a QuickTime movie.

Further reading

• Multimedia Accessibility (Joe Clark)
• Web Captioning Overview (WebAIM)
• Subtitle formats explained (AfterDawn)
• How to play subtitles (OpenSubtitles)
• Subtitle (captioning)
• Closed captioning
• MP4 FAQ (doom9)
• Adding/editing captions on YouTube videos

The most important consideration in video encoding is choosing a video codec. A future article will talk about how to pick the one that’s right for you, but for now I just want to introduce the concept and describe the playing field. (This information is likely to go out of date quickly; future readers, be aware that this was written in December 2008.)

When you talk about “watching a video,” you’re probably talking about a combination of one video stream, one audio stream, and possibly some subtitles or captions. But you probably don’t have two different files; you just have “the video.” Maybe it’s an AVI file, or an MP4 file. These are just container formats, like a ZIP file that contains multiple kinds of files within it. The container format defines how to store the video and audio streams in a single file (and subtitles too, if any).

When you “watch a video,” your video player is doing several things at once:

1. Interpreting the container format to find out which video and audio tracks are available, and how they are stored within the file so that it can find the data it needs to decode next
2. Decoding the video stream and displaying a series of images on the screen
3. Decoding the audio stream and sending the sound to your speakers
4. Possibly decoding the subtitle stream as well, and showing and hiding phrases at the appropriate times while playing the video

A video codec is an algorithm by which a video stream is encoded, i.e. it specifies how to do #2 above. Your video player decodes the video stream according to the video codec, then displays a series of images, or “frames,” on the screen. Most modern video codecs use all sorts of tricks to minimize the amount of information required to display one frame after the next. For example, instead of storing each individual frame (like a screenshot), they will only store the differences between frames. Most videos don’t actually change all that much from one frame to the next, so this allows for high compression rates, which results in smaller file sizes. (There are many, many other complicated tricks too, which I’ll dive into in a future article.)

There are lossy and lossless video codecs; today’s article will only deal with lossy codecs. A lossy video codec means that information is being irretrievably lost during encoding. Like copying an audio cassette tape, you’re losing information about the source video, and degrading the quality, every time you encode. Instead of the “hiss” of an audio cassette, a re-re-re-encoded video may look blocky, especially during scenes with a lot of motion. (Actually, this can happen even if you encode straight from the original source, if you choose a poor video codec or pass it the wrong set of parameters.) On the bright side, lossy video codecs can offer amazing compression rates, and many offer ways to “cheat” and smooth over that blockiness during playback, to make the loss less noticeable to the human eye.

There are tons of video codecs. Today I’ll discuss five modern lossy video codecs: MPEG-4 ASP, H.264, VC-1, Theora, and Dirac.

MPEG-4 ASP

a.k.a. “MPEG-4 Advanced Simple Profile.” MPEG-4 ASP was developed by the MPEG group and standardized in 2001. You may have heard of DivX, Xvid, or 3ivx; these are all competing implementations of the MPEG-4 ASP standard. Xvid is open source; DivX and 3ivx are closed source. The company behind DivX has had some mainstream success in branding “DivX” as synonymous with “MPEG-4 ASP.” For example, this “DivX-certified” DVD player can actually play most MPEG-4 ASP videos in an AVI container, even if they were created with a competing encoder. (To confuse things even further, the company behind DivX has now created their own container format.)

MPEG-4 ASP is patent-encumbered; licensing is brokered through the MPEG LA group. MPEG-4 ASP video can be embedded in most popular container formats, including AVI, MP4, and MKV.

H.264

a.k.a. “MPEG-4 part 10,” a.k.a. “MPEG-4 AVC,” a.k.a. “MPEG-4 Advanced Video Coding.” H.264 was also developed by the MPEG group and standardized in 2003. It aims to provide a single codec for low-bandwidth, low-CPU devices (cell phones); high-bandwidth, high-CPU devices (modern desktop computers); and everything in between. To accomplish this, the H.264 standard is split into “profiles,” which each define a set of optional features that trade complexity for file size. Higher profiles use more optional features, offer better visual quality at smaller file sizes, take longer to encode, and require more CPU power to decode in real-time.

To give you a rough idea of the range of profiles, Apple’s iPhone supports Baseline profile, the AppleTV set-top box supports Baseline and Main profiles, and Adobe Flash on a desktop PC supports Baseline, Main, and High profiles. YouTube (owned by Google, my employer) now uses H.264 to encode high-definition videos, playable through Adobe Flash; YouTube also provides H.264-encoded video to mobile devices, including Apple’s iPhone and phones running Google’s Android mobile operating system. Also, H.264 is one of the video codecs mandated by the Blu-Ray specification; Blu-Ray discs that use it generally use the High profile.

Most non-PC devices that play H.264 video (including iPhones and standalone Blu-Ray players) actually do the decoding on a dedicated chip, since their main CPUs are nowhere near powerful enough to decode the video in real-time. Recent high-end desktop graphics cards also support decoding H.264 in hardware. There are a number of competing H.264 encoders, including the open source x264 library. The H.264 standard is patent-encumbered; licensing is brokered through the MPEG LA group. H.264 video can be embedded in most popular container formats, including MP4 (used primarily by Apple’s iTunes Store) and MKV (used primarily by video pirates).

VC-1

VC-1 evolved from Microsoft’s WMV9 codec and was standardized in 2006. It is primarily used and promoted by Microsoft for high-definition video, although, like H.264, it has a range of profiles to trade complexity for file size. Also like H.264, it is mandated by the Blu-Ray specification, and all Blu-Ray players are required to be able to decode it. The VC-1 codec is patent-encumbered, with licensing brokered through the MPEG LA group.

Wikipedia has a brief technical comparison of VC-1 and H.264; Microsoft has their own comparison; Multimedia.cx has a pretty Venn diagram outlining the similarities and differences. Multimedia.cx also discusses the technical features of VC-1. I also found this history of VC-1 and H.264 to be interesting (as well as this rebuttal).

VC-1 is designed to be container-independent, although it is most often embedded in an ASF container. An open source decoder for VC-1 video was a 2006 Google Summer of Code project, and the resulting code was added to the multi-faceted ffmpeg library.

Theora

Theora evolved from the VP3 codec and has subsequently been developed by the Xiph.org Foundation. Theora is a royalty-free codec and is not encumbered by any known patents other than the original VP3 patents, which have been irrevocably licensed royalty-free. Although the standard has been “frozen” since 2004, the Theora project (which includes an open source reference encoder and decoder) only hit 1.0 in November 2008.

Theora video can be embedded in any container format, although it is most often seen in an Ogg container. All major Linux distributions support Theora out-of-the-box, and Mozilla Firefox 3.1 will include native support for Theora video in an Ogg container. And by “native”, I mean “available on all platforms without platform-specific plugins.” You can also play Theora video on Windows or on Mac OS X after installing Xiph.org’s open source decoder software.

The reference encoder included in Theora 1.0 is widely criticized for being slow and poor quality, but Theora 1.1 will include a new encoder that takes better advantage of Theora’s features, while staying backward-compatible with current decoders. (Info: 1, 2, 3, 4, 5, source code.)

Dirac

Dirac was developed by the BBC to provide a royalty-free alternative to H.264 and VC-1 that the BBC could use to stream high-definition television content in Great Britain. Like H.264, Dirac aims to provide a single codec for the full spectrum of very low- and very high-bandwidth streaming. Dirac is not encumbered by any known patents, and there are two open source implementations, dirac-research (the BBC’s reference implementation) and Schroedinger (optimized for speed).

The Dirac standard was only finalized in 2008, so there is very little mainstream use yet, although the BBC did use it internally during the 2008 Olympics. Dirac-encoded video tracks can be embedded in several popular container formats, including MP4, Ogg, MKV, and AVI. VLC 0.9.2 (released in September 2008) can play Dirac-encoded video within an Ogg or MP4 container.

And on and on…
Of course, this is only scratching the surface of all the available video codecs. Video encoding goes way back, but my focus in this series is on the present and near-future, not the past. If you like, you can read about MPEG-2 (used in DVDs), MPEG-1 (used in Video CDs), older versions of Microsoft’s WMV family, Sorenson, Indeo, and Cinepak.

The timing of this is quite intriguing following the recent hacking attack, supposedly orchestrated by the Chinese authorities, on Google, Yahoo, Adobe and some 20 other major international corporations; whilst there is also the ongoing concern from many quarters about Google is too dominant in many aspects of our online lives.

But less of the cynicism, the five principles are:

• Use information to provide our users with valuable products and services.
  Focus on providing the best user experience is the first tenet of Google’s philosophy. When users share information with us, it allows us to build services and products that are valuable to them. We believe that focusing on the user fosters both the products and privacy-enhancing features that have fueled innovation and built a loyal audience of users online.
• Develop products that reflect strong privacy standards and practices.
  Our ambition is to be at the leading edge of technology, including the development of tools that help users manage their personal information in a simple, accessible manner without detracting from a valuable user experience. We comply with privacy laws, and additionally work internally and with regulators and industry partners to develop and implement strong privacy standards.
• Make the collection of personal information transparent.
  We strive to show users the information used to customize our services. Where appropriate, we aim to be transparent about the information we have about individual users and how we use that information to deliver our services.
• Give users meaningful choices to protect their privacy.
  People have different privacy concerns and needs. To best serve the full range of our users, Google strives to offer them meaningful and fine-grained choices over the use of their personal information. We believe personal information should not be held hostage and we are committed to building products that let users export their personal information to other services. We don’t sell users’ personal information.
• Be a responsible steward of the information we hold.
  We recognize our responsibility to protect the data that users entrust to us. We take security issues seriously and work together with a large community of users, developers and external security experts to make the Internet safer and more secure.

Whether these principles can be fully adhered to by Google is an important question, but they do serve to calm the fears of many about what they’ll do with our data. If nothing else, they do serve to highlight the need for data privacy to be taken seriously by anyone considering building web applications.

If you’re interested in more of Google’s privacy stances, they’ve got an entire portal dedicated to them.

The sections we’re really interested in are 3.1.1 and 3.1.2. These are detailed below.

Regarding production software on a per-CPU and Virtual Machine (VM) basis:

3.1.1 Adobe grants Licensee a license to install and use the Software as Production Software on a per-CPU basis as provided in a separate writing. The total number of CPUs of all of the Computers on which the Software operates may not exceed the total number of CPUs separately licensed. For purposes of this License Metric, (a) all CPUs on a Computer on which the Software is installed shall be deemed to operate the Software unless Licensee configures that Computer (using a reliable and verifiable means of hardware or software partitioning) such that the total number of CPUs that actually operate the Software is less than the total number on that Computer, and (b) a CPU shall mean a single, physical chip with the capability of housing multiple processor cores. If Licensee purchases a 2-CPU Production Software license, then each CPU to which it applies such license must reside in the same Computer. In the event that Licensee desires to apply 2-CPU Production Software licenses to Virtual Machines, then (c) for the Standard version of the Software, the number of 2-CPU licenses required shall be the greater of (i) the number of available physical CPUs for all instances of the Software divided by two (any fractions shall be rounded up for purposes of this provision), or (ii) the total number of Virtual Machines on all Computers on which the Software is installed, and (d) for the Enterprise version of the Software, the number of 2-CPU licenses required shall be the number of physical CPUs on which the Software operates divided by two (any fractions shall be rounded up for purposes of this provision).

The key information here is:

• The Standard license is charged per 2-CPU or per-VM, which ever is greater.
• The Enterprise license is charged per 2-CPU.

But what does this actually mean for Joe Bloggs? Fortunately the guys at Adobe, via Twitter, were on hand to help.

Here is a little table that should whet your appetite:

Regarding production software on a cloud network:

3.1.2 Adobe grants Licensee a license to install and use the Software as Production Software on a Cloud Network on a per-instance basis as provided in a separate writing. The total number of instances that may run on a Cloud Network may not exceed the total number of instances separately licensed. Licensee must purchase and apply 1 instance license to each use of the Standard version of the Software. Licensee may apply 10 instances for each license purchased of the Enterprise version of the Software.

The key information here is:

• The Standard license supports cloud computing, but for each instance, 1 license must be applied.
• The Enterprise license supports up to 10 cloud instances, e.g. on Amazon EC3, Azure, Joyent, Rackspace Cloud etc.

In essence, if you’re going to run a [decent] virtual machine environment, or indeed a cloud environment, it would be far more cost efficient to run ColdFusion Enterprise, since it is costed by the number of virtual machines or increments of 10 cloud instances.

You can download the original Adobe ColdFusion 9 EULA (PDF 400K) from the Adobe website.

Schwartz starts by defining a test case. This is in essence a question; How can I future-proof my career? Once you know the question, you can then set about identifying key influences on your question–e.g. technological change–scenarios that may bring about the change–e.g. new competing technologies, lack of technological development in your sector, or the collapse of a key stakeholder–and finally, future implications.

Here is what Schwartz says in more detail:

1. List driving forces

What variables, trends and events will affect your mission? The first step is to list them. Next, divide them into uncertainties (such as economic, political and social conditions) and relative certainties (such as global population growth and climate change). Finally, rank the items according to their importance, from most to least significant. The result: a catalogue of factors that will determine the future of your area.

If I take web development as an example:

• Pace of technological change.
• Number of companies using the chosen technology.
• Number of people available in the industry (permanent and contract).
• State of the [digital] economy.
• Competing technologies, e.g. Ruby on Rails vs ColdFusion, AJAX vs Flash, offline vs online, desktop vs mobile.
• Support of the community, e.g. open-source software, tutorials and application servers.
• Support of key stakeholders, e.g. Adobe’s support of Flash, Flex and ColdFusion.

2. Make a scenario grid

Now it’s time to map out possible futures. The two most important uncertainties from the top of your list form the axes of the grid, with each of the quatdrants representing a potential future. Some may be more likely than others–and some may seem downright improbable–but they all depict the interplay of key forces. Thus, they’re within the range of possibility and deserve attention. They help you prepare for a range of possibilities and bolster core actions with those related to the future you deem most likely.

3. Imagine the possible futures

Sketched as a grid, these 4 possible scenarios are so abstract that it would be hard to recognise them if they merged. Make them more concrete by fleshing them out into imaginery, but plausible, news stories of the forces at play.

To continue the web development example:

• Global financial crisis prevents companies investing in technology. They cannot raise the adequate funding to push through key development projects, even if it means increasing efficiencies within the company.
• Adobe drops support for ColdFusion causing turmoil in the community. Railo picks up a lot of business, but can’t scale to fill the demand. Far-sighted companies migrate to other suitable platforms.
• Ruby on Rails booms under the paradigms: Convention over Configuration and Don’t Repeat Yourself, eating into ColdFusion’s key mantra: Rapid Application Development.
• Key advances in technology on the desktop and mobile continue at pace. Micro-payments allow people to create relatively cheap applications that appeal to a mass audience. Development frameworks allow developers to transfer their skills between technologies without the need for significant retraining.

4. Brainstorm implications and actions

Now it’s time to develop strategies for coping with each of the four possible futures you’ve imagined. Start by listing all the implications of each of the scenarios and then come up with actions that would enable you to prosper under any of the new conditions. Some actions would apply to almost any scenario: these should form the basis of your plan, since they help you to prepare for a range of possibilities. Bolster these core actions with those related to the future you deem most likely.

Examples of possible implications:

• Scarce funding.
• Limited demand for new technologies.
• Few companies to work for.
• Few new projects to work on.
• Increased competition for places.
• Increased demand for people with key skills, e.g. mobile.

and possible actions:

• Concentrate on existing technologies.
• Develop and exit strategy, e.g. cross-train into a new technology.
• Cultivate your network, make new contacts at major development houses.
• Polish skills in areas of uncertainty.
• Start your own cutting-edge business.

5. Track the indicators

The main value of the scenarios is that they sensitise you to the way the future is unfolding. Over time, the world is likely to gravitate toward one of your four quadrants. The trick is to recognise the shif in progress. As you monitor the news, look for signals that a particular possibility is becoming a concrete reality. Keep a file of news relevant to your scenarios, jotting down a quick note, along with the date, whenever you come across a significant story. Evaluate these developments on a quarterly basis so you can track the trends. Keep adjusting your action strategy to anticipate the future as it emerges.

Of course it is possible that none of your four quadrants becomes true. If this is so, you will need to go back and re-evaluate your scenario grid. Keeping a critical eye on your grid and apace of industry developments, you can be assured that the future will not change so quickly that you’ll miss an opportunity.

• Don’t reinvent the wheel unless you really have to. Borrow code and ideas from elsewhere whenever it makes sense. The web community it great at sharing, just look at the various JavaScript libraries, the huge quantities of APIs or indeed the major players’ developer areas: Google Code, Yahoo! Developer Network, Mozilla Developer Center, Adobe Developer Connection and Dev Opera to name five I regularly refer to.
• Things should be as simple as possible, but no simpler (Einstein). This idea is really born out of and emphasised by 37Signals’ Getting Real book. Commonly, 90% of people using an application only use 10% of it’s functionality. The key therefore is to find what people use most often and only build that functionality. If there is a requirement to add more, then sobeit. This can also apply to the code-level, the essence here being a balance between over- and under-engineering something.
• Do one thing well (The UNIX philosophy). It is better to do one thing well, than several second-rate. This could be at the code level — think encapsulation, coupling and cohesion — or indeed at the application level — you’re never going to beat Microsoft Word, but Google and Zoho have developed compelling alternatives, but with far less features.
• Don’t fret too much about performance — understand how to write efficient code and plan to optimise later if or when needed.
• Don’t try for perfection because good enough is often just that. This of course is a matter for conjecture. If I were working on a personal project, I may be more stringent on perfection than say, for a client’s application. This doesn’t mean to say the client’s application would be any worse, but rather it is a question of dotting-the-is and crossing-the-ts. It also depends on your perspective and what gains can be made by aiming for perfection.
• (Hence) it’s okay to cut corners sometimes, only if you can do it right later. I rarely adhere to this! It makes sense to do it right the first time, since bodge-jobs often come back to haunt you and result in double the effort!
• Don’t fight it; go with the flow. This is somewhat clichéd, but the essence behind this is try to avoid getting stressed out. This isn’t always easy to achieve, but taking a step back from a situation and avoiding politics is important.

I often strive for perfection, which isn’t an entirely clever pursuit since it is almost impossible to achieve. However, in a realm of imperfection, the principles above have helped me to achieve a modicum of decent code throughout the years. They may also resonate and provide inspiration for you.

Adobe is now offering developers subscribed to the Adobe Enterprise Developer Program access to their own virtual instance of LiveCycle ES through LiveCycle ES Developer Express. LiveCycle ES Developer Express provides a pre-configured, virtualized installation of LiveCycle ES Solution Components in a self-contained development environment. LiveCycle ES Developer Express is hosted on the Amazon Elastic Compute Cloud (Amazon EC2). AEDP members can test, build, store and develop their applications in a cloud-base environment where all LiveCycle ES applications are pre-configured and running. The Adobe Enterprise Developer Program will offer a minimum of 10 hours of runtime per month, with additional hours to be available separately.

What is cloud computing and why is it important?

The term cloud computing, as used by some commentators, refers to the use of scalable, real-time, Internet-based information technology services and resources. This somewhat nebulous concept incorporates software as a service (SaaS), utility computing, Web 2.0 and other recent technology trends. The common theme stresses reliance on the Internet for satisfying the computing needs of users, without them needing knowledge of, expertise with, or control over the technology infrastructure that supports them. An often-quoted example is Google Apps, which provides common business applications online that are accessed from a web browser, while the software and data are stored on Google servers.

The cloud element of cloud computing derives from a metaphor used for the Internet, from the way it is often depicted in computer network diagrams, and is an abstraction for the complex infrastructure it conceals.

How do Adobe and Amazon fit into the equation?

Adobe and Amazon have similar goals. They both want to gain more share of the enterprise market. Amazon needs to convince the enterprise that its version of the cloud is capable of supporting the demands of enterprise applications. On the other hand Adobe wants to convince the developers who already use AWS that LiveCycle is the platform of choice for the enterprise.

What is Adobe LiveCycle?

Adobe’s LiveCycle Enterprise Suite is a J2EE-based server software product used to build applications that automate a broad range of business processes for enterprises and government agencies.

LiveCycle combines technologies for data capture, information assurance, document output, content services, and process management to deliver solutions such as account opening, services and benefits enrollment, correspondence management, request for proposal processes, and other manual based workflows.

What are Amazon Webservices?

Since early 2006, Amazon Web Services (AWS) has provided companies of all sizes with an infrastructure web services platform in the cloud. With AWS you can requisition compute power, storage, and other services–gaining access to a suite of elastic IT infrastructure services as your business demands them. With AWS you have the flexibility to choose whichever development platform or programming model makes the most sense for the problems you’re trying to solve. You pay only for what you use, with no up-front expenses or long-term commitments, making AWS a cost-effective way to deliver applications to customers and clients.

How do they fit together?

Essentially, Adobe has put a Red Hat JBoss J2EE stack on AWS and deployed LiveCycle on the stack. Adobe state that this platform is purely for prototyping, developing and testing applications, rather than production environments, but that is likely to change.

The future

Deploying LiveCycle on AWS has wider implications, not only for Adobe products. By setting up a J2EE stack on AWS it makes it possible to deploy any Java-based application; yes that does mean one developed in Adobe’s ColdFusion or indeed its chief rival, Railo.

Take this scenario. A company I once worked for had what can be described as a business directory built upon a licensed, yet bastardised, version of a popular ColdFusion-based CMS. It didn’t work that well! The decision was made to redevelop the application in Java. It took two years to reach the same level of functionality! What happened next? Ruby-on-Rails is what! The rest is history and beyond the topic of this post.

So, in effect, the application almost went full-circle in its development paradigm — both ColdFusion and Ruby-on-Rails can be considered Rapid Application Development environments, Java, certainly not. Why did the decision makers not stick with ColdFusion and put time aside to actually build it properly in the first place? To put it simply, they lost faith in ColdFusion; it was largely mis-understood.

The weakness of every programming language does not lie with the language itself per se — albeit it can have an important influencing factor — but rather with the ability, or indeed inability, of the developer to leverage the language in the most efficient and optimal way.

ColdFusion, like every other programming language has had and I’m sure still does have its fair share of poor developers; those people simply working with it as a means-to-an-end, rather than those passionate about the language, those people programming without understanding the fundamentals of programming or the implications of their poorly written code. This is apparent from .NET to Java, ColdFusion to Ruby, JavaScript to ActionScript.

Let’s not dilly-dally, bicker or insult one another about which is best, which one is dying and which one is not worth the computer it is compiled on. What is important is to understand the merits of each language and decide which one best suits the application, not only in technical terms, but also in terms of time-to-market, cost of development, availability of a skilled workforce etc.

ColdFusion, whether rightly or wrongly in some people’s opinion, can sit proudly amongst its peers and provide a truly compelling alternative.

Here’s how (in no particular order):

1. Low Total Cost of Ownership – frequently, ColdFusion is described as expensive, it simply isn’t especially if you consider the natively supported functions. But to put it bluntly, if your company cannot afford the cost of ColdFusion standard, or indeed ColdFusion hosting, you have bigger things to worry about regarding the profitability of the company; you won’t be able to afford much of anything! The problem becomes not the product. ColdFusion applications are quicker to develop and developers are vastly cheaper to employ than their peers in Java or Ruby, just look at ITJobsWatch for examples.
2. Rapid Application Development – ColdFusion vastly simplifies tasks. What would take other languages numerous lines of code to produce is efficiently encapsulated either in a tag or function or as a setting in the administrator. This is a simplistic yet indicative example: where else can you connected to a database simply with one line of code or indeed simply by name? ColdFusion changed the idea of specifying development time in terms of months and years to weeks and months or small features a matter of hours and days. Simplicity is not the mother or all evil. To be pragmatic, simplification reduces costs.
3. Rich Internet Applications – ColdFusion may or may not have pioneered the RIA paradigm, but it has played a significant supporting role to Flash and now Flex. ColdFusion natively supports Flash remoting, providing the all important data access tier.
4. Platform Maturity – ColdFusion 8 is built upon the latest version of Java (1.6). Along with internal improvements to the ColdFusion application, this has afforded ColdFusion unprecedented speed improvements and stability.
5. Language Maturity – with each major release of ColdFusion comes many language enhancements added to the core. This means that previous addons, for example image manipulation, which came at a premium are now standard. Adobe and other companies that produce CFML engines are now participating in a CFML advisory committee, which aims to set standards for the core language. This is not only a sign of maturity but a letter of intent by the industry that will mean your application will work on any engine, assuming no proprietary functionality is used.
6. The Ultimate Middleware – ColdFusion sits comfortably between any backend and front end system. Be it interfacing with a host of databases, Java, .NET, COM, Corba or connecting to classic HTML or rich Flash, Flex and AJAX frontends with little or no configuration.
7. Feature Rich – what other web technology natively supports PDF generation, charting, enterprise-level search, AJAX, image manipulation, Atom and RSS creation, Zip and JAR file manipulation, a server monitor, Flex integration, encryption libraries, all important database connectors, webservice creation, XML manipulation, inbuilt reporting application (similar to Crystal Reports), email, FTP to name but a few? I hazard a guess at none, unless you’re happy to pay a premium.
8. Platform Independent – since ColdFusion 6, when Macromedia redeveloped the entire application in Java, ColdFusion has been platform independent. You can install it on practically any machine.
9. OpenSource Alternatives – BlueDragon and Railo are both significant alternatives to Adobe ColdFusion and both have opensource alternatives, the latter of the two having recently joined the JBoss community. Adobe are also considering providing a free edition to academic institutions.
10. The Future – many commentators have mentioned Hibernate as a significant addition to the next release of ColdFusion, version 9. But having seen the prerelease notes, that is not all that will be added. Alas I’m under NDA, but rest assured, there is going to be a significant intake of breath when developers get hold of the next release. ColdFusion 8 was firmly geared towards middle management with fuzzy additions, ColdFusion 9 is set to re-address the balance with compelling language and functionality enhancements.

ColdFusion evangelism needs to step up a gear! Adobe certainly doesn’t afford much marketing budget to the product, prefering The Community do the hard work. It is not always easy convincing the decision makers that ColdFusion is a good product of choice, without Adobe’s unnerving support, but we have to work hard, break down those barriers, encroach on events outside the comfortable sphere of the ColdFusion world and demonstrate ColdFusion’s match-winning ability.

ColdFusion isn’t dying, it’s simply niche. Every niche has its place.

UPDATE: If you would like to view the ensuing debate regarding ColdFusion prompted by Aral Balkan, feel free to do so. This post should serve as a positive reminder of ColdFusion’s virtues, alongside the need for a balanced and polite debate.

Eclipse started out as a Java IDE and has continually grown from there. Plugins now include, amongst a plethora of others, the venerable Aptana, CFEclipse, SQL Explorer, Subclipse and, more recently, the Adobe-developed Flex Builder and ColdFusion-equivalent codenamed Bolt.

Apache Ant is a software tool for automating software build processes. It is implemented using the Java language, requires the Java platform, and was originally developed to automate the build of Java projects. However, since Ant was created as a simple, platform-independent tool, it can really be used to automate the build of anything you choose.

Ant uses XML to describe the build process and its dependencies, using a file commonly called build.xml. Using this file, Ant makes it trivial to integrate unit testing frameworks with the build process and has made it easy for web developers to adopt test-driven development, and even Extreme Programming.

Fortunately for us, if you download and run Eclipse, you already have Ant installed and so do not have any complex configuration to concern yourself with; well, at least initially.

Setting Up Eclipse

For the most part, Eclipse has all you need to get up and running with Ant pre-installed. However, most projects will include a release target which uses FTP to upload the files to a live server. The FTP ant task requires some extra libraries (.jar files):

commons-net-*.jar
jakarta-oro-*.jar

(The library files can be downloaded from here).

Copy the files into the ant lib folder of your Eclipse install. The folder is commonly located here:

C:\Program Files\Eclipse\plugins\org.apache.ant_*\lib

(The asterix * refers to the Ant version).

Next, go to Window > Preferences and select Ant > Runtime. In the Classpath tab, select Ant Home Entries, click Add External JARs… and select the 2 files you copied to the ant lib folder.

A Typical Ant Project Setup

A project with ant build scripts should have the following within the repository:

• build.xml (the actual ant build script)
• build.properties.template (a template for individual build.properties files)
• an optional top level lib folder (containing jar files for external ant tasks)

Examples of the build.xml and build.properties.template files can be downloaded from here.

Create Your Own build.properties File

Make a copy of the build.properties.template file (name it build.properties) and set the values to fit your local setup (in most cases, the only property you may want to change is deploy.dir.local which is the path to the site on your local machine).

This file should never be committed to the repository (the repository should be set to ignore it anyway).

Basic Build Tasks

The build file should have a deploy.local task. This task builds the project and copies it to your local webserver (the path to the web server folder will be defined in the build.properties file).

Most projects should also have a deploy.dev task to copy the latest work to the dev server so that other people can view it.

Setting Up an Automatic Build

To make things easy, you can set deploy.local to run every time you save a file. This is called an automatic build.

The process for setting up automatic build is quite convoluted. I’m not sure why but this is the best way I’ve found to make it work.

Step 1: Add the build file to your ant view

Click the add button and select the build.xml file from the project. You can also drag the build.xml file onto the ant view (To add the ant view to your perpective, go to Window > Show View > Other…)

Step 2: Run as Ant Build

In your ant view, right click the newly added build file and select Run As > Ant Build… In the dialog window, select the ‘Hide internal targets not selected for execution’ option in the Targets tab. You can rename the builder in the box at the top of the window if you wish (I usually remove the trailing ‘build.xml’. Click Apply and Close.

Step 3: Setup automatic build

Right click on the project, select Properties, then Builders. Click Import. Before closing the screen, highlight the imported build and select edit. Go to the Targets tab select clean for ‘After a clean’ and deploy.local for ‘Auto build’. Apply the changes and close.

Step 4: Enable Auto Build

Go to Project > Build Automatically

Acknowledgment: Thanks should go to Martin Laine for his help and guidance which resulted in this article.

For the seasoned Flex developer, we’ve been accustomed to using the Flex Component Explorer as a reference. However, this is set to change with a great new application called Tour de Flex.

Tour de Flex is a desktop application, built using AIR, with the goal of providing a way to explore Flex’s capabilities and resources, including the core Flex components, Adobe AIR and data integration.

Created by James Ward, Greg Wilson and Christophe Coenraets, Tour de Flex has three main purposes: provide non-Flex developers with an overview of what is possible; provide seasoned Flex developers with a visual reference tool; and finally, provide commercial and non-commercial Flex developers a platform to showcase their skills.

Probably the greatest feature of this application is the integration of a variety of third-party components, effects and skins. The application contains examples from the following and we are told that this list will be regularly updated when new content becomes available:

• Acrobat.com Share
• Amazon
• AOL Instant Messenger
• Cocomo
• Ebay
• Flickr
• Google Language
• Intuit Quickbase
• Last.fm
• Photoshop.com
• Salesforce.com
• Scribd
• Smugmug
• Twitter
• Yahoo Weather

Below is a selection of screenshots from the application:

(Click on the images to see a larger view)

Included with the Tour de Flex project is an Eclipse plugin, built by Holly Schinsky, that provides a search interface to the 200+ examples available in the main Tour de Flex application. The plugin allows you to search by component name, tag or author and double-click any item in the results to immediately see the component in Tour de Flex.

To install the plugin, add the following URL to your Eclipse software update sites:

http://tourdeflex.adobe.com/eclipse.

Once installed, a new Tour de Flex view is available to add. The plugin has been tested with Eclipse 3.4 and with Flex Builder 3.x.

The official Tour de Flex page and install can be found on the Flex.org website.