January 2009 Archives

For authors, it's a sad fact that when it comes to popularity, not all articles are created equal; some prove to be more popular than others. The truth is that no matter how well you select topics, or how well you write, you won't be able to hit a home run every time. Nonetheless, if you're already writing programming articles (or you're thinking about writing them), the tips listed here are proven to help vault articles from the ho-hum heap to the top of the most-viewed lists.

1. Choose a Pithy Topic. Picking a pithy topic is tough, because many interesting topics aren't concise at all; they're long and complex. Sometimes you can create nicely self-contained individual articles that work in concert as a longer topic, but usually not. You may need to write a series or a book instead. Either pick something else or break the topic up into pithy chunks.

The next few tips can help you meet the requirement of tip #1:

2. Augment Existing Documentation. Some of the most consistently popular articles are essentially augmented documentation. There's nothing wrong with that, because technical documentation is often produced hurriedly, is incomplete, isn't written by developers, or lacks pertinent examples. In nearly every case, documentation (or the lack thereof) provides a rich vein of topics for authors to mine.
3. Compare Things. Another often-popular tack is to write a comparison between two or more popular items. These could be languages, language versions, APIs, databases, operating systems, frameworks, programming methodologies, patterns—in the rapidly-changing developer world, there are innumerable opportunities here. Pick two or more technologies that developers use, and write the article that best helps developers transition or choose them.
4. Make a List. You may think it's tired, but the "10 for/about " type articles tend to do well. (If this blog post does well, I'll consider it validation of this point; if it doesn't, maybe I'll reduce this to "Nine Tips…."). Editors and publishers love these articles because readers like them. I suspect readers like them because any article that contains a number of things increases the probability that at least one will contain needed or at least interesting material, but maybe people just like lists. At any rate…

After you have a solid topic, and you're ready to start writing, keep these points in mind:

5. Ignore History. Yes, I know you think everyone needs to understand the background history for your particular subject before they get to the meat, but the fact is, they rarely do. Your readers no more want to ponder your historical comments than you wanted your father to explain the history of math when you were learning algebra in high school. Here's an inside tip from reader behavior analysis: Most readers never get past the first page. So, if you don't answer their question or grab their interest immediately, it doesn't matter how on-target the rest of your article is; they won't see it. Link to the history, get to the meat.
6. Eschew "HelloWorld" Examples. Just because you've seen a thousand "HelloWorld" code examples in articles and books that you've read doesn't mean they're good! They're not. No one likes them. They're all but completely useless for learning anything about programming. They're not entertaining either. It's perfectly possible to write clear and straightforward examples that both teach and aren't boring.
7. Illustrate Your Points. Developers like code, sure, but you can save them time and effort by including illustrations and screenshots, too. That's because many of them may not run your fascinating sample code, but if they're reading your article, they're probably interested in the results. Show the input or output whenever it matters.
8. Show the Interesting Code. Many technical authors seem to think that providing a brief explanation and following that up with reams of example code (or worse, just showing the code without the explanation) will spur their readers to study the code to gain enlightenment. I assure you that's not true. The best articles explain the topic, show only code fragments, and then explain or show (or both) what that code does, how it fits in with the surrounding code or overall topic, when you should use it, when you should not use it, and only then—and only if it's truly useful—do they refer you to longer chunks of code. Instead, put only the interesting code in your article, and provide the rest as a runnable, complete-project download.
9. Make the Complex Simple. Avoid the urge to tell people how complicated your subject is. They know it's complicated, or they probably wouldn't be reading your article. Instead, think of ways to make your complicated subject seem simpler.

And perhaps the most important point of all is:

10. Be Brief. The most consistently popular technical articles give readers just what they need—and no more.

Finally, it's true that some articles are popular despite having few or none of the characteristics listed here—but that's not something you can control. Trying to write one of those articles is much like drawing to an inside straight; you'll lose most of the time. Concentrate on the basics, write a lot of articles, and some of them will be winners.

Happy writing.

Conducting an interview via email can be very convenient. I can formulate my questions exactly the way I mean them (avoiding my propensity for rambling), and the interviewee has the time to compose thoughtful answers that address my specific questions (avoiding his/her propensity for rambling). Plus, I get the complete Q&A returned to me in "cut-and-pasteable" text: No tedious trawling through my digital recording to transcribe quotable answers or deciphering my hastily-written scrawl while trying to write as fast as the interviewee talked.

Like most modern conveniences though, email interviews have their downside too. Not only do they forfeit control over when I will receive answers to my questions, but more importantly, they take away an essential interviewer's tool: the immediate follow-up question. Such was the case with this blog: An email Q&A with two members of the JavaFX team, JavaFX Chief Architect John Burkey and Senior Director of JavaFX Marketing Param Singh. The interview covers a variety of topics related to the recent JavaFX 1.0 release.

The interview wasn't completed as close to the actual release date (early December 2008) as I would've liked—the holidays not withstanding—and a couple of the responses beg for follow-up questions. But that's the price of convenience. I'll let you be the judge:

Sun's Zero-Sum Java Development:

DevX: With many Java developers clamoring for language features such as properties, closures, and data binding in Java 7 (not all of which will be included in that release) and fearing that Java is falling behind C# in terms of features, some view any development effort dedicated to JavaFX as resources diverted from core Java language development. How does the JavaFX team respond?

JavaFX Team: JavaFX is a series of technological initiatives, some of which just couldn't [be] done on top of the existing Java frameworks. Specifically, the industry is moving towards animation, visual tools, and scripting, all around a core of a scene graph. People are excited when we talk about these things, from traditional Swing developers, to visual designers who have never considered working in Java.

JRE and Applet User Interaction:

DevX: How does/will the JavaFX user experience (e.g., security dialogs, JWS downloading JNLP files, etc.) compete with that of Flash?

JavaFX Team: JavaFX is powered by Java, and hence leverages the underlying features and functionality of Java. For instance, JavaFX uses the robust and proven security model of Java. Consequently, JavaFX uses industry best practices for security for items such as cross-domain access and access to system resources.

DevX: If JavaFX is currently run as an applet in the browser, is there any way for a web developer to use JavaFX without placing applets on his or her web site?

JavaFX Team: No. Applets are just the standard container for doing JavaFX, managing the lifecycle of the JavaFX objects within the browser. However, we do have some nice features here, including bi-directional interaction with JavaScript, allowing very nice communication with the rest of the web site.

JavaFX Mobile:

DevX: Which mobile device manufacturers are the JavaFX team working with? If you can't divulge that, which mobile platforms will developers be able to use JavaFX with starting in spring '09 (announced release date for JavaFX runtime for mobile devices)?

JavaFX Team: Sun works with most of the major telecommunications carriers, operators, and OEMs with Java ME. Sun is working closely with these partners to bring JavaFX Mobile to market.

Sun will announce key partners around Mobile World Congress and will continue to roll out partners at other key events.

DevX: How soon do you plan to support JavaFX on Android?

JavaFX Team: Sun is committed to delivering JavaFX Mobile runtime on a wide range of platforms (device/OS combinations) that our partners demand. Sun has demonstrated the potential to deliver JavaFX Mobile on Android at JavaOne 2008.

DevX: How will the JavaFX team address the issue of provisioning JavaFX applications to mobile devices?

JavaFX Team: [Through] a standard set of tools to allow developers to deploy to mobile devices, as well as emulate those devices on Desktop. Over the next few releases, expect these tools to get better and better.

DevX: What portions (if any) of JavaFX will be left out of JavaFX on mobile platforms?

JavaFX Team: You won't be able to call the Desktop profile, which includes Swing-based API's on Mobile, and in fact, we encourage you do stick to our "Common" architecture, which is a focused set of API's enabling next-generation media and graphics, as well as effects and timeline-based animations.

Language Interaction and Web Service Support:

DevX: Besides Java, which other programming languages (or scripting languages) does JavaFX interact with and at what level?

JavaFX Team: There is a bi-directional JavaScript bridge, which allows deep access to our JavaFX API, or DOM. In addition, JavaFX is built on top of Java, and calls into any Java API in Java SE just as a Java applet would.

DevX: With JavaFX 1.0's added web service support (calling RESTful web services and making asynchronous HTTP requests that return XML or JSON), is this how Sun recommends JavaFX clients communicate with server-side applications? Are there plans for additional web service support capabilities in the future?

JavaFX Team: We fully support RESTful web services and the web standards, but will continue bringing more capabilities to the platform. There are several things in play, enabling easier tie-in with more sophisticated web services.

Open Source Roadmap and JavaFX Gadgets:

DevX: What's open source today? What will be in the future? What (if anything) never will be open source?
 
JavaFX Team: Sun is committed to open source. Key parts of the JavaFX platform are in open source, including the JavaFX compiler.

DevX: Do you intend to release a set of JavaFX-based gadgets any time soon, or do you plan to leave it up to the community to develop them?

JavaFX Team: Yes, in addition to the great work already occurring in the community, we have a standard set of gadgets coming in the next several releases.

"Not Invented Here" Questions:

DevX: Instead of JavaFX Script, why not just adopt Groovy, which already had all the necessary language constructs and was quite mature?
 
JavaFX Team: JavaFX Script is designed specifically for doing visual scenes, and because it is a statically compiled language on top of a world-class virtual machine, it is quite a bit faster than Groovy, as well as being more expressive for visual scene construction.

DevX: What features in JavaFX couldn't have been implemented directly to the Java language with some minor enhancements, such as Properties (with data binding) or the {} construct (like in Groovy) to cut down on the verbosity of the code?

JavaFX Team: JavaFX script is a scripting language, and as such is built for fast declarative style coding, and takes as its precedents several scripting languages. The entire look of the language would be different if it were a Java derivative. Both Java and JavaFX script are important languages.

Editor's Note: Thanks to DevX authors Edmon Begoli, Jacek Furmankiewicz, Anghel Leonard, and Jim White for contributing questions for this interview.

I've read a lot recently about the economy, including a number of prognostications about how the downturn will affect IT. But most predictions ignore some basic IT facts. A downturn in the general economy may foreshadow a downturn in hardware and commercial software sales, but it probably heralds a relative increase in IT expenditure. That's because one of the primary ways companies can save money these days is by automating tasks that have traditionally been performed by humans.

The tasks themselves still have to get done, even during an economic downturn. Salaries are the largest single expense for most businesses. Therefore, companies turn first to downsizing their workforce to save money during lean times. But that leaves more work to be shared among the remaining employees, which results in two perhaps non-intuitive IT-related outcomes:

1. Remaining employees now spend more time on any given task than they had previously (when the task was divided among more employees), so automating those tasks increases in value, because automation frees up employees for other, less-easily automated tasks.
2. Because automated tasks require less human time and attention, automation increases productivity and improves opportunities for further downsizing.

Both these outcomes increase in importance as employees' workload increases and as the economy gets worse, putting pressure on companies to reduce their workforce even further. Putting it plainly, the value of automation increases as the number of available employees diminishes.

Not all businesses realize this; many still consider expenditures on new development as an expense rather than an investment. The reasoning goes that "Salaries are a fixed expense: we have to pay all our employees anyhow, so automating their tasks doesn't save us any money." But the cold hard accounting fact is that automating even one hour of each of your employees' time per week frees employees for other work (improving productivity), reduces the total number of employees you need to perform the remaining work, and can result in substantial savings over a very short period.

That's not necessarily good for the humans whose tasks get automated—either those laid off, or those still employed—after all, "productivity improvement" generally means either extra work for employees or job losses—but automation is, for better or worse, the future of most tasks that humans are capable of doing. Even though the ongoing need for automation will not prevent all IT layoffs (many IT tasks are themselves automatable), developers should fare better than most.