I'm not one of those people for whom the task of composition is a somewhat mechanical extension of increasingly detailed outlines. Nonetheless, research consumes between 80-90% of the time I spend on a technical article (note I said time and not effort -- subjectively, writing text is two or three times harder than writing C++. You can satisfy a compiler.)

In this case, research will consist of:

1. Integrating CodeAnalyst and Eclipse
2. Profiling a simple application
3. Implementing an image-processing application
4. Profiling it to discover a performance problem
5. Investigating that problem with CodeAnalyst
6. Ameliorating it
7. Evaluating the performance "win"
8. If not "big enough" go to 3 

In this case, my target sample application has two algorithms that I think will be difficult:

1. Seam-discovery (CPU intensive)
2. Seam-removal (Memory-manipulation intensive)

With seam-discovery, I know that even if I implement a known-good algorithm (such as graph-cuts), I am guaranteed to peg the CPUs. My big gamble professionally is that I'm a good enough programmer to find a Step 6 "win" that I can pull off in a reasonable amount of time. A safer bet would be to choose an algorithm that would have performance problems if intentionally implemented in a naive manner (for instance, a filter that just iterated across rows and columns and, at each pixel, retrieved the neighboring pixels and averaged them. Pretty easy to tune that up!)

Now, a confession. By the time you read this, I've been somewhere not-Hawai'i for a week or so. I'll carry print outs of this paper on content-aware image resizing and this paper on graph-cuts and study them on the plane tomorrow. I'll have my laptop with me and may noodle around with source code, but it's far more likely that I'll be working with pen and paper to see if I can "get" the algorithm intuitively. Other than that, I'm going to do my darnedest not to spend too much time thinking about computers.

Coming September 19th or thereabouts: Part 4, Research Gets Underway...

Probably the biggest difference between academic and commercial writing is this: academic writing is almost always concerned with algorithms and process, commercial writing is almost always driven by a specific set of technologies. In this case, I'm being paid by AMD to explain integration of CodeAnalyst and Eclipse CDT. So that dictates that I'll be using C++, which leads to a couple questions:

• Linux or Windows?
• What C++?

The Linux or Windows question is fairly easy for me to answer: I boot into Windows and run Linux in Virtual Machines. For an article on a profiler, the VM is a complication -- CodeAnalyst works within a VM, of course, but since I expect this article to get down to the hardware, I don't want any confusion about how toasty-warm my code is making my Opterons. So I'll be experiencing the code in Windows.

But when writing about Eclipse, surely I should imagine that my target audience is not strictly Windows-based. So it seems logical to set up a compiler-chain based on GNU C++: I know that will be portable. (Note: I'll probably cross-compile with at least Microsoft C++ and compare the experience. That might give me enough information for, if not an article, at least a column.)

Since the article is supposed to emphasize multicore/multichip development and in C++, it's a no-brainer that I'll be using OpenMP.

My next thought is unit-testing. For one thing, I just don't develop anything without unit-testing anymore. For another, repeatability is critical to the article. For a third, I expect to hit some hard problems along the way and unit-testing is the best way to maintain momentum in the face of brain-twisters. I have not compared C++ unit-testing frameworks, but Boost has a test component, and while there may well be better, I know that Boost won't be poor.

Version control is not the same issue in an article that it is in professional development, but you can never over-estimate the benefit of a backup: I'll be using Subversion against a local server.

Since I know that I'll be doing image-processing, I'd just as well use a library or two to handle file-loading and basic pixel manipulation. If I were building an application, I'd definitely tend towards GTK+. However, I want to keep things as simple as possible around the algorithm(s) that I'll be developing, so I'm going to see how far I can get with this project, CImg, which seems nice and minimal.

So my initial tool list is:

• CodeAnalyst : Profiler
• Eclipse CDT : IDE
• GCC : Compiler-chain
• OpenMP : Shared-memory parallel programming
• Boost.Test : Unit-testing
• Subversion : VCS
• CImg : Image-processing library

If I need or change libraries, I'll make mention of it in forthcoming posts.

Next: Part 3, Research Begins...

I thought I'd try blogging the development of a technical article; it might prove interesting to, I dunno', 3 people in the world.

I've been contracted to write a 2,500-words-plus-listings article on using AMD's CodeAnalyst profiler with Eclipse, especially relating to multithreaded / multicore development. So that's a pretty beefy article, about twice the length of a typical technical article in a print magazine. CodeAnalyst works with native code, so my sample program(s) pretty much have to be written in C++ -- anything else would limit the audience.

AMD targets an experienced audience, so the educational goals for the article are "The reader will be able to..."

• ... enable and gather data using CodeAnalyst from within Eclipse CDT
• ... navigate within the main profiles provided
• ... recognize the profile most clearly associated with their performance limits
• ... determine the source-code lines associated with a performance issue
• ... after making code changes, compare the performance of subsequent runs"

Which is a heck of a lot of ground to cover. So the end result will be something like an advanced tutorial that you might get towards the end of a piece of documentation.

My professional goals are to deliver a technically sound article that satisfies my client's goals within a profitable range of hours. I can control that primarily by manipulating my sample program(s); the amount of time I need to research the actual use of Eclipse or CodeAnalyst is minimal, since I know both products. The research aspect of the article -- always the most time-consuming in a technical article -- will be the development of sample program(s) that:

• have a performance-limit that can be ameliorated,
• are comprehensible, and
• can be distributed (this limits my use of libraries)

My personal goals are to make sample programs that are interesting in and of themselves. This is a weakness on my part, but what can you do? In this particular case, I hope to implement some significant part of the algorithms used for content-aware image resizing. I have no intention, or interest, in recreating the GUI shown in the video. I have neither the time nor, quite honestly, the mindset -- once I see the algorithm work, I can guarantee you that my interest in this will virtually disappear. That's one reason why I'm not rich.

Next up: Part 2, Gathering Tools

Please, feel free to laugh at this column describing how I was completely pwned by hackers trading the German dub of 'Norbit'...

"But this isn’t a silver bullet!" Fabian insisted. "It's a djinni-bearing magic lamp! Not just one thing—you get three things!"

...My April 1st column for SD Times is now online...

However, the real-world development of software product lines is hampered by the real-world limitations of maintaining a stable center as the product-line offerings spin off in a widening gyre...

Going Over the Software Product Line is the title of my latest SD Times column.

My latest in SD Times is up, in which I decide to stop being polite about WS-*.

At the risk of sounding immodest, I think we SD Times columnists have been hitting on all cylinders for the past few issues. The latest issue includes Allen Holub on FitNesse testing, Andrew Binstock on free books for programmers, and some crap from me on XNA and non-professional programming (written before I'd gotten hands on XNA. Scratch the part about network programming.)

My latest SD Times column argues that it's time to retire Mort, Elvis, and Einstein.

I just got off the phone with David Intersimone. My recent SD Times column on “DevCo,” (the codename for the spin-off of Borland’s languages and database teams) ruffled some feathers, particularly when I described the Delphi language as “well past its peak, and with its Pascal roots … on the wrong side of trends in syntax.”

To address that line specifically, David I said that was “like saying that BASIC died in 1968….Languages don’t die unless [language designers] stop innovating in them.” Which is true. But I wasn’t speaking of missing features, I was speaking primarily about the trend away from structural explicitness and secondarily about the prevalence of C-language syntax.  Is Delphi something that a lot of people are intrigued by? Not if this treemap of sales of books about programming languages (taken from Tim O’Reilly) reflects broad trends (and I think it does). Perhaps I’m holding Borland / DevCo to too high a standard, but I think it speaks poorly to the language that there are more people reading about Vbscript than Delphi (I take the response as given that: “they don’t read books because they’re too busy making money.” Sure.)

I highly doubt that the addition of features such as generics, closures, or even LINQ to Delphi will be sufficient to cause a resurgence in popularity (although they’ll undoubtedly be welcomed by existing users). A resurgence in the popularity of LISP or Smalltalk is unlikely but to my mind either is more likely than a resurgence in popularity of Delphi. I just don’t see this decade’s market embracing the explicitness of Pascal-like language design. It’s possible to imagine, though, a language that was backwards-compatible with today’s Delphi but which supported looser styles of creating program entities (just as VB’s “option explicit” essentially supports two different philosophical approaches). Such a language is what I meant by a “Delphi-in-name-only.”

We talked briefly about the Classhelper technology, which is exactly the sort of thing that I see as being important to future growth.

The growth of Delphi aside, David I shared several interesting points about the spin-off that may provide some food for thought:

“DevCo” consists of the development tools, the database technologies, and some “legacy products.” Obviously Delphi, JBuilder, and C++Builder, but also Interbase, JDataStore, Kylix, Turbo Assembler, and some others.

They have a .NET embeddable SQL database they’ve shown but not announced as a product.

“DevCo” has licenses for a number of Borland products (Together, RequisitePro, etc.) so that they can continue to sell the IDE in an integrated manner.

“Borland Developer Studio” has been the internal name for that which is installed by the DVD. In some places, they’ve marketed this as BDS, in other places as Delphi. This was the source of a little confusion on my part in the article, as I thought “Delphi” had become the overarching brand. One way or the other, the name for “DevCo”s products has not been determined and may even be determined by a contest among users! (Cute.)

David I says that Borland has a vested interest in the success of DevCo, as failure of DevCo would reflect poorly on Borland.

The leadership team of DevCo includes: Nigel Brown, Michael Swindell, Steve Todd, Alan Bauer, Ben Netick, and David I plus an internal Board of Directors.

They have 3-year roadmaps for Delphi, JBuilder, and Interbase.

Sarbanes-Oxley has lots of implications for software and other high-tech companies. It may be that under SOX you cannot add features in an update. (If this is the case, wow.)

The size of DevCo will be ~250-300 at the start.

DevCo will be headquartered in Scotts Valley. Borland will be HQ’ed in Cupertino. “That’s the plan” (but investors / buyers might overrule).

Delphi: generics coming, eventually will support LINQ.

David I doesn’t like referring to VCL as cross-platform. Likes to say “leveraging skills across implementations…...NET is not a platform, it’s a layer on top of Win32.”

In response to question about VCL on the Mac: “We’re looking into that.” Not on the roadmap. Time will tell; first and foremost is supporting existing customers. With bootcamp, will people develop in Windows on Mac hardware? Wondered David I.

“Wouldn’t be surprised” if DevCo eventually supported more languages than are currently supported. (Didn’t bite hard on my “Turbo Ruby” enthusiasms.) Mentioned

Interbuilder, a before-its-time JavaScript & Data tool. “Some of that DNA is still in DevCo.”

Sees a “healthy market” for “the JBuilder experience,” no matter on what technology that experience is built (originally, JBuilder was built on Delphi, then on Primetime, and in the future, on Eclipse).

We talked a little bit about the tension between spending resources on languages / IDEs and on databases. Traditionally, this has been a problem for Borland. David I is more on the languages side and didn’t really have an opinion on whether the world was looking for a new dBase / Paradox.

Finally, we heartily agreed that “developers matter” and that there were golden opportunities for bold companies producing great development tools.

My two latest articles on Tablet PC programming are up on DevX:

The first details the development of Arcs of Fire and the Mobile PC Game SDK.

The second discusses the brand-new smart client sample application for Mobile PC development.

My Hexodoku Programming Contest is live: the challenge is to generate 16 x 16 Sudoku grids. If multiple entries can consistently beat 1 second, the winner will be the program with best Big O behavior as the order of the grid scales (4^4, 5^4, 6^4, etc.). The prize is this year's Jolt Awards Finalists in the "General Books" category:

My latest column for SD Times discusses Windows Live.

My latest article on DevX implements a packet filter and custom selection tool using the Tablet PC RealTime Stylus APIs.

My latest article for DevX shows how to add ink annotations to photos, both on the image itself and within the EXIF metadata headers.