Over the past several weeks, I've had the obligatory parental experience of teaching a teenager to drive. This can be a nerve-wracking process as the new driver learns the mechanics of controlling the car: steering, using the pedals, shifting gears, checking rear-view mirrors, etc. But all these are relatively simple tasks that young drivers mostly master without serious problems.

The real harrowing experiences start only after new drivers have been driving for a while, when they're out on the road with other drivers. And that's where "learning to drive" truly comes into play, because it's not control of the vehicle that makes a good driver although that's certainly a prerequisite. Instead, it's the ability to anticipate the unexpected that makes a good driver--and unfortunately, that's a skill you can't teach.

You can talk about potential problems. You can describe them, and have the learner tell you what they would do in such situations. You can even practice avoidance maneuvers. But each new driver must personally experience many of the common driving hazards (and survive them) to be able to anticipate similar situations and take steps to avoid problems.

Sadly, the same rules apply to becoming a good programmer. Consider an application that stores some data in a file, retrieving it each time a user launches the application. Beginning developers, having learned the syntax to open and write data to files, simply write the few lines of code that read and store the data. If they've been programming a while, they might even write a test to make sure the code is reading and writing the data correctly. And because the code works, beginners think they're done; they've accomplished the task, met the specifications, and tested their work.

An expert programmer, faced with the same situation, knows it's not that simple. Sure, it's easy to write code to read or store some data in a file--when everything goes right. But it's not so easy to code the application to handle all the things that can go wrong, even with this simple operation. The file might not exist. The disk might be full. The file may be corrupted. The user may not have permission to access the file. The file might be in use. If the file's not local, it might not be reachable.

Granted, not all these problems are likely to happen at any given time, but developers who have delivered applications to large numbers of people know that, given enough time, all of them will happen, sooner or later.

An expert can tell a non-expert to check for such conditions, and with those specifications, the non-expert can probably code them, but only the expert anticipates them. Just like driving, what makes a good programmer is not only the ability to solve the problems that occur, but the ability to foresee (and avoid) problems that haven't occurred yet. Unfortunately, experts learn how to do that by making mistakes. It's a sad commentary on the human condition. Each generation acquires expertise primarily by repeating the mistakes of the past generations. To paraphrase Neils Bohr, "An expert is someone who has made all the possible mistakes in a very narrow field."

But when you're riding in a car with a novice driver, you'll probably appreciate P. J. Plauger's version more, "My definition of an expert in any field is a person who knows enough about what's really going on to be scared."

At the opening keynote of this week's Oracle OpenWorld Conference, Sun Chairman and Co-founder Scott McNealy called the father of Java, James Gosling, on stage to again reiterate Oracle's dedication to Java. When McNealy asked whether Oracle is good for Java, Gosling recalled the old joke about ham and eggs: The chicken is involved, but the pig is committed. In Gosling's characterization, Oracle--with its JSR leadership and Java-based product lines--is much more ham than eggs when it comes to Java.

But we know that already. The really interesting part of McNealy and Gosling's exchange came at the end, when McNealy voiced his doubts that the Moscone Center where the conference is being held was big enough to hold OpenWorld and JavaOne simultaneously. Some in the Java community have speculated that the 2009 JavaOne Conference this past June would be the last. The rumors have Oracle killing the show and holding some scaled down version of it during OpenWorld. What would that look like?

The largest convention center in downtown San Francisco has three halls, Moscone North, South, and West. Oracle needs all three, plus rooms at an off-site Hilton, to accommodate the 40,000+ attendees. Not to mention that Oracle blocks off the street between the facing Moscone North and South halls, lays carpet down on the street, and erects tents above it (129,000 square feet of tenting, that is). It's a huge production. How Oracle would host another 15,000 people (the reported attendance at JavaOne 2009) is a logistical challenge I'm glad I don't have to face.

There probably wouldn't be much overlap in attendees who go to both shows either. Fundamentally, the conferences speak to different audiences: OpenWorld is an enterprise IT show for executives, while JavaOne is a developer show for Java programmers. Just observing the unwritten dress code at each one makes the difference obvious.  Casual attire at OpenWorld is khakis and a button-down shirt with your company's logo embroidered on the breast pocket. That same outfit at JavaOne would be formal (What's with the khakis?).

Beyond the issues of sufficient space and differing styles is that of content. OpenWorld actually already offers content for Java developers. Oracle Develop is OpenWorld's three-day program dedicated to developer topics, and it held a number Sun-hosted sessions that were JavaOne-esque, including overviews and updates of JPA 2.0, EJB 3.1, Java SE, Java EE 6 and GlassFish, JavaServer Faces 2.0, and JavaFX. However, Sun is hosting only 10 out of a total of 217 Oracle Develop sessions--a fraction of the content JavaOne offers. Oracle would need to scale the number of sessions up significantly and find the room to host them.

Where Oracle Develop takes place also speaks volumes about the focus of OpenWorld. To get to Oracle Develop from the main show, you have to walk to a hotel about 10-15 minutes away. Shuffling off to the Hilton felt a little like being invited to a fancy dinner party and then been relegated to a wobbly ironing board in the den for your meal while the "grown-ups" (the IT executives) eat at the dining room table.

For Java developers, that feeling of being second-class citizens would be an unavoidable consequence if the shows merged. As the steward of Java, Sun constantly interacts with the Java community to help shape and plan JavaOne. During Goslings conversation with McNealy at the opening keynote, he confessed that Oracle was "a little unprepared for the volume of the Java community." Sun's developer programs, according to Gosling, are much larger in terms of downloads and interactions than those Oracle currently offers.

The developers who are downloading bits from the many java.sun.com projects, reading Sun distinguished engineer blogs, reporting bugs, and otherwise getting involved in the development of the Java platform make for an enthusiastic audience when Sun puts on a show just for them. (You won't hear the Brazilian contingent whoop and holler every time their country's mentioned here at OpenWorld, but you can count on it at JavaOne--and more than one keynote presenter has when his presentation starts to lose some steam.)

A backlash from developers who fear being marginalized in a merged OpenWorld/JavaOne likely won't be enough to save JavaOne if Oracle decides to end it; OpenWorld has swolled other conferences (PeopleSoft Connect and BEAWorld are just two). However, the audiences for the other shows it consumed have been more aligned with the IT executives who attend OpenWorld. With the logistical challenges and divergent audience, OpenWorld might choke if it tries to swallow JavaOne.

If you're going to host a tech conference in the middle of a global recession, O'Reilly's Open Source Convention (OSCON) wouldn't be a bad choice. What does a bear market mean to an open source project that thrives on programmers who code passionately—for coding's sake, not for the almighty dollar? And haven't cost savings always been the great promise of open source software for buyers? I'm oversimplifying things, but economic concerns did become a theme at this year's OSCON where one huge organization, the U.S. government—tasked with leading an economic recovery here in the States—took center stage.

Founder and CEO Tim O'Reilly and Clay Johnson, Director of Sunlight Labs, both gave presentations centered on the emerging U.S. initiatives to establish an open government platform. One of the first projects in that effort is Data.gov, whose stated mission is "to improve access to federal data and expand creative use of those data beyond the walls of government." To put the site in a developer's context, O'Reilly described Data.gov as an attempt by the government to put together an SDK for all their APIs. If successful, civic-minded developers will be able to build an ecosystem around the platform.

Johnson knows first hand what type of innovation can grow out of this type of accessibility. Sunlight Labs is an agency that actively works on finding useful applications for the government data and creating tools that will enable users to apply them.

Both men stressed that this "government as a platform" idea won't reach its full potential until the federal procurement process (i.e., the required procedures for a government agency to acquire goods and services) is streamlined. The process is currently so complex that Johnson couldn't fit a chart of it on a single slide. What he did manage to capture looked like a Gantt chart wrapped in an object diagram inside an org chart (Take a look).

When a bid actually meets all the process requirements, the results can be very lucrative for the bidder and exorbitant for the government, like the $9 million contract awarded for the construction of the web site Recovery.gov (according to Johnson).

Open source developers (Drupal, anyone?) don't need to be civic-minded to be interested in a share of payouts like that. But they'll have to wait for a more accessible procurement model.

Some other notes from OSCON '09...
Open Source as the 'Exit Strategy' for Government Projects
An interesting idea for overcoming the procurement problem came from the audience. As the keynote speakers were taking questions, a man (I didn't catch his name) argued that a retirement strategy for government software projects is fundamental, and that open source licenses were a good match for that strategy. As I understood his point, if the government were to employ open source software, it could simply abandon (or retire) projects when they stopped being useful. With the vast sums the government invests in those projects today (see the Recovery.gov contract above), just retiring them isn't economically viable.

The Open Source Project as a Boys Clubs
If you're a male developer who wants to know what it's like to be a woman on an open source project, go get a pedicure. That was the proposition Kirrily Robert made in her "Standing Out in a Crowd" presentation. One of a small minority of women who work on open source projects, Robert argued that no matter how welcoming the nail salon staff and clientele may be, a man probably would feel somewhat out of place there.

Such is the experience of female coders, who can face everything from openly displayed pornography to sexist jokes to outright harassment—along with the burden of representation. According to the feedback Robert has received from the mostly female development communities at Dreamwidth and Archive of Our Own, women contributors felt that their contributions to projects weren't valued and that their skills were relegated to ancillary duties like documentation.

If you're a woman who's involved in open source, I'd be interested in your comments.

Microsoft Keynote Topic an Odd Choice
After Microsoft made perhaps the biggest open source news of the week by releasing 20,000 lines of Linux code under the GPLv2 license, I was surprised the company didn't use its allotted presentation time to take a victory lap in front of an audience of open source developers. Instead, VP of External Research Tony Hey spoke about Redmond's open tools and services initiatives in academic research. The work Microsoft is doing in this area is certainly important and interesting, but why ignore the 800-pound penguin in the room?

Most Entertaining Presentation of the Show
Hands down, Simon Wardley's hilarious and informative talk on cloud computing was the highlight of the show for me. Not only did he send up the numerous definitions of the term (he found 67 on Google, some self-serving, many confused), but he put the technology in a historical context that you won’t find in vendor releases about supposed cloud computing products. Best of all, he saved the pitch for Ubuntu Enterprise Cloud until the end. Well done, Simon.

Interesting Out-of-context Quotes
"Federation is, maybe, the new open source."
– Tim O'Reilly discussing the possibility of federating the disparate data services that millions of web users access everyday

"I should be able to knock you over with a feather right now."
– Google's Chris DiBona during his presentation of Google Code Search crawl data, referring to a slide that showed GPLv3 penetration at nearly 46% this year

Recently, I learned a valuable lesson in modern programming efficiency: Problem-solving abilities often take a backseat to information retrieval and analysis. I was working on an application that saved images extracted from Word 2007's OOXML file format, and received an application error:

System.Runtime.InteropServices.ExternalException was unhandled

Message="A generic error occurred in GDI+."

Source="System.Drawing"

ErrorCode=-2147467259

 

In OOXML, various "parts" of the document are stored in DocumentPart containers. The various parts have relationships, each with its own ID. The project code had obtained the appropriate DocumentPart containing the image from the document, using the relationship ID associated with that image. It then retrieved the image from the DocumentPart, using the Image.FromStream method, and stored the resulting Image for later use. The code that caused the error was a simple Image.Save command that attempted to save the image in a specified folder.

The error message was no help: What does "A generic error occurred in GDI+" mean, anyhow? Time to review the stack trace:

 

StackTrace:

   at System.Drawing.Image.Save(String filename, ImageCodecInfo encoder, 

      EncoderParameters encoderParams)

   at System.Drawing.Image.Save(String filename, ImageFormat format)

   at System.Drawing.Image.Save(String filename)

   at TestOpenXMLSDK2.Form1.btnSaveImages_Click(

      Object sender, EventArgs e)

   at System.Windows.Forms.Control.OnClick(EventArgs e)

   at System.Windows.Forms.Button.OnClick(EventArgs e)

 

Nothing jumps out from that. I had a valid image; the filename was valid; the destination folder existed and contained no existing image with the same filename; the folder wasn't read-only; I had full permissions on the folder; and there was plenty of room on the disk. Even worse, the code had been running for several days with no problems.

In earlier years, I would have been stuck, but modern programming is fundamentally different. Rather than laboriously solving problems, often by trial-and-error, you can usually solve problems by a simple search. The key to solving this one was the line ErrorCode=-2147467259. Pasting that into Google turned up a discussion that referenced this Microsoft Support page. The information there says basically that if you create a Bitmap from a stream (which I had), that stream must remain open for the lifetime of the Bitmap, because:

"GDI+, and therefore the System.Drawing namespace, may defer the decoding of raw image bits until the bits are required by the image. Additionally, even after the image has been decoded, GDI+ may determine that it is more efficient to discard the memory for a large Bitmap and to re-decode later. Therefore, GDI+ must have access to the source bits for the image for the life of the Bitmap or the Image object."

I didn't want to recode the project to keep the stream open, but the page also provided a workaround: You can make a copy of the original bitmap, which removes the requirement to access the source. It provided these instructions:

1.     Construct the original Bitmap from the stream, from the memory, or from the file.

2.     Create a new Bitmap of the same size, with a pixel format of more than 8 bits-per-pixel (BPP).

3.     Use the Graphics.FromImage() method to obtain a Graphics object for the second Bitmap.

4.     Use Graphics.DrawImage() to draw the first Bitmap onto the second Bitmap.

5.     Use Graphics.Dispose() to dispose of the Graphics.

6.     Use Bitmap.Dispose() to dispose of the first Bitmap.

 

It took only a few minutes to add that code, and the project was back on track. But the real point is that the resources available on the web to modern programmers often makes programming much more of an exercise in good search techniques than an exercise in good logic and debugging techniques.

Of course, all this could have been avoided if the Image class had a way to ensure that the source bits would be available even if the originating stream were closed. And it would have been far less irritating if the error message had said "Unable to save because the source stream or file for this image is no longer available." But that's another topic.

The new Sun boss put the OpenOffice and JavaFX groups on notice during the JavaOne opening keynote today: Produce some JavaFX libraries for the OpenOffice suite and do it quickly. Larry Ellison, head of the soon-to-be Oracle/Sun Java giant, said: "I've been meeting with different groups inside of Sun, and one of the things we're looking forward to is seeing libraries come out of the OpenOffice group that are JavaFX-based."

He offered spreadsheet and word-processing programs as the types of JavaFX application he expects. (Never mind that OpenOffice already has a spreadsheet program called Calc and a word processor called Writer.)

The two-hour keynote closed with a symbolic passing of the torch from the old “Chairman of JavaOne,” former Sun CEO Scott McNealy, to the new one, Oracle CEO Ellison. With so much speculation about how the acquisition will shake out for Java, both men had to address the topic for the largely developer audience. But their exchange was carefully worded because the acquisition has not yet been finalized.

As expected, Ellison reiterated Oracle's commitment to Java (Oracle’s entire middleware stack is 100-percent Java) and twice pledged to expand its investment in Java, which drew applause both times. But his most pointed remarks were the challenge to the OpenOffice and JavaFX groups and later wondering out loud why Sun/Oracle couldn’t produce mobile devices like netbooks or Google and T-Mobile's G1 phone, all based on the JavaFX platform.

In a setting where Ellison had to be particularly mindful of his words, choosing to declare these challenges publicly provided some insight into where Oracle will place its focus for Sun Java.

For you JavaFX devotees, hearing Ellison put the platform front and center has to be encouraging. At one point, he said: "We're very committed to seeing JavaFX exploited throughout Oracle and throughout Sun."

 

When Oracle bought Sun, it got Java. If you make your living in Java development, that statement can make you cringe, smile, or shrug—depending on how well you think Sun has handled owning Java, and whether you think Oracle will do better or worse. You might even believe that the Java platform is too entrenched for this deal to have any real impact.

For its part, Oracle announced the acquisition with praise for Java ("the most important software Oracle has ever acquired") and a commitment to keep it vibrant ("continued innovation and investment in Java technology for the benefit of customers and the Java community"). And you don't have to take Oracle's word for it; the company's software products ran on the Java platform long before it decided to buy Sun.

So what's really going to change for the Java developer? Following the money may provide an answer. The Java platform has spawned countless development projects over the years with Sun providing the care and feeding—read: cash and staff—for hundreds of them. Sun spends billions of dollars in R&D every year, much of it going to Java-based innovation. (Java itself came out of the Green Project at Sun back in 1990.) The problem for Sun seems to be turning innovation into profits; being bought by Oracle may mean the end of R&D without ROI.

Oracle expects Sun to contribute over $1.5 billion to its operating profit in the first year, according to Oracle President Safra Catz. To fulfill that mandate, Oracle may start pulling staff and funding from Sun Java projects that don't immediately contribute to the bottom line or at least show promise of contributing in the near future.

Instead of worrying about Java itself, the types of questions Java developers really need to ponder are: What's the return on investment for JavaFX? Is it possible to monetize Project Looking Glass? What would the migration from Project GlassFish to Oracle WebLogic Server be like? And so on and so on for all those cool, interesting projects that aren't paying their own way. Soon, it may be the communities—alone—who keep them going.

Now—are you cringing, smiling, or shrugging?

As job losses in the U.S. mount, under pressure not only from the current economic downturn/depression, but also from foreign competition, de-unionization, outsourcing, offshoring, and imported labor (both legal and illegal), it's increasingly difficult to advise people on a "safe" career field. But there are a few bright spots—for the gifted, at any rate.

Most recently, I've been advising dentistry as the smart career choice. You can't offshore dentists (yet), or import enough dentists to meet the demand. People need the service, they're willing to pay for it, and the salary's pretty good. The work's not terribly unpleasant, and you can pretty much live wherever you like. It is hard to get into dental school, though.

But a few days ago, I saw an article about a new Japanese-made "runway robot." My first thought was "There go the modeling jobs!" (I hadn't seen a picture yet.) My second thought was "Here's a second profession that I would recommend to young people: robotics."

While runway models don't have to worry about being displaced by this first awkward runway robot, it's increasingly obvious that robotics is the wave of the future. Robots are cheaper, faster, stronger, less fragile, more flexible, more accurate, and easier to train and upgrade than humans. As if that weren't enough, each generation of robots is "born" knowing everything the previous generation "learned"—robots simply skip the long maturation and learning period that humans must go through. Moreover, the duration of robot generations is much shorter than human generations, so they evolve faster.

Given these advantages, intelligent machines are slowly—but inevitably—taking over the tasks that humans have traditionally performed. And I'm not just talking about service jobs, factory jobs, or dangerous or physically demanding jobs; robots will get those first, but they won't stop there. I'm talking about high-skill, training-intensive jobs—professions such as surgical assistant (and surgeon), mechanic, airplane pilot, stockbroker, lawyer, musician, and actor.

Even dentistry will eventually succumb to the advances in robotics.

People just entering the robotics field are getting started at the beginning of a big expansionary period, much like the expansions of electricity, physics, chemistry, computer technology, transportation, and biotechnology during the last century. If history is any guide, that expansion will probably last long enough for a decent career.

Publishers take heed: If you don't have the content, the readers won't come.

 

As a publisher of developer-related content, I spend a significant amount of time researching technical topics, and I also spend time evaluating how others reach the content we publish. It turns out that an overwhelming percentage of our audience reaches our content via search.

 

Not by browsing to a site directly and seeing what's new.  

 

Not by clicking links in newsletters.

 

Not by clicking links on other sites.

 

Not by clicking links in RSS feeds.

 

Through search.

 

Because this is DevX, you can be pretty sure that the searchers who land here are developers looking for specific pertinent developer-related content—in other words, they use search the same way and for the same reasons I do: It's the fastest way to find what you need.

 

But for publishers what this means is that the old adage "Content is King" is more relevant today than ever. It also means that branding is becoming increasingly irrelevant. For example, despite the presence of search boxes on most modern sites, people rarely use them; unless they know the information they need was published on a particular site, they gravitate toward one of the major search engines instead. That's because it's usually a waste of time to search a specific site when you're interested in information rather than presentation; the information might be anywhere on the web, and you're far more likely to find it quickly by searching the entire web rather than a single site. I do browse—but only when I'm not looking for something specific. 

 

Reaching content through search also means that site organization isn't particularly important. I rarely care, notice, or even see whether publishers arrange their material by language, technology, publish date, author, or whatever other categories they might think readers want. Browsing is slow and inefficient. Searching is fast and—with the right search string—produces near-instant results.

 

However, while organization isn't usually pertinent, presentation is. Because the goal is to find and absorb material as fast as possible, I tend to avoid sites that hinder my searching by being unusually slow, prefaced with popup ads, or that use any other marketing technique that's intended to get my attention, but usually just results in my looking elsewhere. Again, content is king. If the only site with the information I want has irritating marketing, I might suffer through it to get to the content. However, if there are multiple sites with the information, I'll find one that's less intrusive. With the size of the web today, most information appears in multiple locations, so I rarely have to endure in-your-face marketing or poor presentation. The result is that I don't much care where the information is, just that I find it.

 

The cold hard fact is that for the past few years, I've rarely even given the URL in search engine hits more than a cursory glance—I'm interested only in the content. Sure, for technical content the combination of the search hit text and the URL usually tells you whether you're about to view a blog or a tech site, but frankly, I rarely care. If a link looks like it has the content I'm after, and it's not on my list of sites with poor presentation or bad marketing, I'll hit it, regardless of the branding.

 

I suspect I'm not alone. 

 

For those of you who didn't attend Scott Ambler and Terry Quatrani's keynote "Software Development Strategies, Philosophies, and Techniques: Traditional vs. Agile" at this week's SD West conference, let me give you the gist of the first half:

• Advocates of traditional software development approaches, such as waterfall and V-Model, are myopic bureaucrats who worship detailed specifications and denigrate the code necessary to build those specs.
• Agile development practitioners, on the other hand, are logical pragmatists whose only goal is to build what the customer wants.

In a parody of the Apple television ads where a hapless businessman personifies a PC and a know-it-all hipster portrays a Mac, Ambler and Quatrani debated the relative merits of traditional and Agile development models. Ambler, the practice leader for Agile Development at IBM, played his Bizarro doppelganger: a staunch traditional model supporter (the PC). IBM Rational Evangelist Quatrani portrayed an Agile proponent (the Mac). The results were much like the TV ads: the brain-dead PC always played the fool.

Watching Ambler mock the traditional approach was good for a few laughs. He sarcastically advocated detailed specifications with complicated models that an architect could throw over the wall to the "programming monkeys," who he joked are good only for writing code exactly to spec and documenting every detail as they go. All the while, Quatrani countered with Agile's iterative, test-driven process, where stakeholders are involved and the spec evolves as the team targets working code for each iteration.

In the second half of their talk, Ambler and Quatrani traded comedy for statistics, presenting some data to validate their pro-Agile satire. Based on surveys of Dr. Dobb's Journal readers (i.e., developers), the data compared the project success rates and effectiveness of the Agile and traditional development paradigms.

Considering the source—people who may have an axe to grind against a model that elevates the architect specialization while relegating developers to "programming monkey" status—I took the survey results with a grain of salt, but they still revealed some interesting tidbits. For example, the vast majority of modeling is performed by sketching on a white board or paper rather than by using software-based modeling tools. Also, while Agile came out ahead in most categories (surprise, surprise), the traditional model had a higher success rate in distributed development. Ambler admitted that Agile teams don't know how to do distributed Agile yet, and claimed the available tools aren't helping them.

The traditional-versus-Agile debate is nothing new, of course. Six years ago, an editorial by the DevX editor-in-chief at the time titled "Are You Passing the Requirements Buck?" prompted vehement rebuttals from a DevX author and even Scott Ambler himself. Since then, DevX has published editorials on the thorny developers-vs.-architects issue, from the polemical (David Talbot's "To Software Architects: Serve End Users, Not Your Egos," December 2004) to the conciliatory (Andy Schneider's "Bridging the Divide Between Developers and Architects," July 2006).

I sat in on Ambler and Quatrani's keynote to get a sense of whether cooler, more pragmatic heads had prevailed. I ended up more entertained than informed, and left with the impression that the debate remains as religious as ever.

I recently read the book, “33 Million People in the Room” by Juliette Powell. The subtitle inspired me to get rich quick: “How to Create, Influence, and Run a Successful Business with Social Networking.” Sounds good, huh? I read this 154-page book, with wide margins and large type, in about two hours. I probably would have read it quicker if I didn’t stop to reply to email.

The book provides several case studies of those who used social network sites to increase sales, boost awareness, and to become micro-celebrities. As a developer, it should inspire you to create the next great application, and then promote it shamelessly on Facebook, Twitter, MySpace, Orkut, hi5, and a few others. If you’ve never joined a social networking site, and you have no idea how they work, this book might serve as a good starting point.

The basic premise of the book, just like any other book directed to entrepreneurs, is to come up with a business idea that you’re genuinely interested in, put your own unique spin on it, and then market it and sell it. Simple, isn’t it? Why don’t we all do it? Because like all get-rich-quick schemes, it’s not that easy, but here are some quick pointers to get you started:

• Place yourself in the center of your network to gain the most amount of information. The more information you have, the better decisions you can make.
• Get out there as much as you can. Attend meetings and conferences, while you’re there, take photos of yourself with influential people. Later, upload the photos and tag yourself.
• If content is King, then distribution is Queen. Learn how business development works and how to market your application; doing this provides aces in the hole.
• The book recommends providing free favors to people who can pay you back twice as much later.

This last point flies directly in the face of everything I’ve ever learned. If you give your applications away for free, then people will expect free applications in the future. The only time I see giving away something for free as a good thing, is if you’re giving away an iPhone application with embedded advertising. In that case, you’ll probably make a lot of money; especially if your free app shows up on social networking sites.

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.

Game developers take note: the future of video games is all about casual, social games that women and grandparents like to play; think Facebook and the Wii. Hardcore games like Grand Theft Auto will still have a place in the industry; they will just move into a dark corner. So said Bernie Stolar, aka the “King of Content,” during a Keynote interview at a Microsoft-hosted event in Mt. View, CA last week during which a who’s who of the industry discussed the future of video game development.

Why should you believe Stolar? Because his impact in the video game industry is deep and far-reaching. His credentials include former Game Evangelist at Google, former CEO at Mattel Interactive, former President and COO of SEGA, and EVP at Sony for the launch of the Playstation. During the Keynote interview (with some big names—Activision/Blizzard, THQ, and Electronic Arts—in attendance), Bernie carved the headstone for the anticipated death of the hardcore game and couldn’t say enough about the future of casual gaming.

To secure a place in the future of game development, you need to make the games fun and ignore gender and age limitations. Social gaming has broadened the demographics away from the 18 to 35-year-old male. Game demographics are now 50 percent women in their late 30’s and 40’s and that does not include grandparents and grandchildren who are playing video games. This new game demographic are playing games on Facebook and bowling on the Wii (Reuters is reporting that 800,000 Wii’s were sold over the Thanksgiving weekend).

Facebook is now a viable gaming platform, as are all social networks. If a developer creates a multi-player (MP) Facebook game that connects to the iPhone, that game is almost guaranteed success. Take golf as an example of an iPhone/Facebook/MP game. For the game to work, players use the accelerometer on their iPhones to swing their clubs, they see their actions through Facebook, and they compete against other players online. Mobile games are going multi-player as well; if you develop it, they will come.

If developing mobile games isn’t your forte, then the future for you most likely includes Massive Multiplayer Online Games (MMOG), social communities, and cloud computing. In terms of developing games for the cloud, you need to remove the computing from the client and put it on the server, which allows for a much larger-scale community, easier updates, and simplified creation of new environments. Cloud gaming reduces retail and packaging costs, increases the life span of a game through easy updates, and allows for micro transactions.

Anne-Marie Roussel, Microsoft's Director of Strategic and Emerging Business, presented MS’s vision for the future of video games during the conference. Roussel mentioned that the third version of XNA is now available to the community and is geared towards developing games with a social community. She expressed the need to democratize video game development and the importance of nurturing a creative community. Microsoft boasts 12 million subscribers to its Xbox Live services, which they will continue to grow (think of Xbox Live growing from one station to a multitude of stations; just like how TV channels evolved).

Video gaming is a $30-37 billion business, and it’s not going away anytime soon. In the future, more and more independent game startups are likely to emerge, which is a great way for the big publishers to find new talent.

Developers, it’s time to get your social game on.

Social networking is about to take a new turn in the coming months. Yahoo! is in the process of releasing its Open Strategy with the goal of connecting more people in more ways than ever before.

There are more social networking sites on the web than any one person could use or keep up with. There’s Facebook, MySpace, Twitter, not to mention Netflix, eBay, or other sites like Digg, StumbleUpon, or Reddit, and that doesn’t even cover the various mail and address book services like Gmail, MSN, and Yahoo.

On the surface, Facebook and eBay do not appear to have anything in common, but they do: they both involve social activity on the web. But there’s nothing linking them together. If you want to tell your wife you outbid the competition for a brand new football-shaped lamp for the bedroom, you can’t tell her through eBay, you have to switch to your email and copy and paste links. Or let’s say you read about a movie you think your mom might enjoy. You can’t contact her directly through Netflix to make your recommendation. Once again, you have to open your email account.

Yahoo wants to change all that through a revolutionary transformation by breaking down barriers and unifying the web. Speaking of unification, did you realize that Yahoo sits on Google’s OpenSocial board, and they meet once a week?

Yahoo! is rolling out a platform approach for the web that combines online activities through a unified identity, connects users, and provides activity updates—all through an access layer—regardless of whether you and your friends are on Yahoo or not.

For this to work, the following must happen:

1. Developers like you need to create the applications.
2. Yahoo and the third-party sites need to approve the applications.
3. Users need to find and use the applications.
4. Most importantly, the users' friends must reciprocate.

To help developers meet the first requirement, Yahoo released YQL (Yahoo Query Language), which is basically the same as SQL except that it is extended to model and fit web services. This week, Yahoo is revealing more about the developer side of this social transformation.

Users already meet the third and fourth requirements all the time. For example, would you be on Facebook if your friends weren’t there? Would you have an e-mail program if you had no one to send e-mail to? So why wouldn't Yahoo's platform work?

For a glimpse of what is to come, download and install Instant Messenger Beta 9. This latest version has a bunch of new options. For example, if you use Blogger or Facebook, you can add a PingBox, which allows you to support an IM application. The thing works great. I installed it on a personal blog of mine this morning, asked a friend to test it, and the next thing I knew, he added it to his blog.

I could go on and on about this, but I’ll let Cody Simms’, Senior Director, Product Management for the Yahoo Open Strategy, blog do all the talking. There’s a presentation there to help developers get to work.