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."

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.

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 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.

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.

In a recent speech, VMWare CEO Paul Maritz raised the rising virtualization rhetoric to a ludicrous level. Among his statements was this gem:

"By and large, people are no longer writing traditional Windows applications," said Maritz. "People are increasingly looking at different ways of writing and provisioning applications."

This statement should both surprise and disappoint DevX's huge developer audience—and not just those writing applications for Windows. Maritz went on to say that "we are going to see the traditional operating system, in fact, deconstructed and made more customized and relevant to the particular application framework."

While there's no doubt that other application types running on other OSs are more common than they once were, the statement that "people are no longer writing traditional Windows applications" simply indicates how far out of touch Maritz is with the mainstream efforts of working developers.

The truth is that more Windows applications are being written than ever before: Office automation programs, web applications, games, database applications, communication, embedded, robotics, and mobile applications, and yes—standard desktop/laptop business applications. In any case, Windows has already been "deconstructed" in the process of expanding Windows programming into other devices. Again, it's not just Windows; there are also more desktop, mobile, and web applications being written for other OSs, most of which were adapted from existing OSs specifically for those types of devices.

Virtualization definitely has an important and a growing place in the IT stack—but that place is supplemental to existing OSs, not a substitute for them.

Cloud computing has been getting an increasing amount of press recently, because it offers attractive solutions to a number of business problems. Cloud computing translates to "hosted applications;" a hosting company lets you build and deploy applications on its servers, delivers those applications through users' browsers, and generally promises near-24x7 uptime and unlimited scalability. To businesses, that translates to hard dollars: servers the company won't have to buy and maintain, databases for which the company won't have to buy licenses, free storage, backup, and disaster-recovery services—all of which mean IT personnel that the company doesn't have to hire and pay salaries and health care for.

Most hosting companies offer infrastructure for development as well. Common types of applications can be developed more quickly, deployed more easily, and scale immediately. That's an attractive proposition; however, there are downsides.

The first problem? Despite the promises availability  has been less than stellar. Many of the major hosting companies have had outages recently, including Google's Gmail, Amazon's S3, and salesforce.com. Web site outages aren't usually terribly important to businesses, because most sites don't host applications that the business depends on. But when businesses begin to host mission-critical applications in the cloud, such as email, customer/sales data, and financial services, they need and expect near-perfect service levels.

Second, because hosting companies own the hardware, it's unclear how difficult or expensive it might be to retrieve the data generated by all these cloud-computing applications. But in today's world, these applications and data are essential to the business. What happens if a service outage can't be fixed quickly? What happens if the hosting company goes out of business altogether? What recourse does a business have if a hosting company fails to back up their data and loses it? Hosting companies essentially hold businesses hostage to their own data.

Third, so far, each system is unique—there's little to no ability to move applications from one hosting company to another without rewriting and retesting the application. Sure, businesses could write applications that copy the data to internal servers—but that puts them back in the position of maintaining their own servers, losing one of the major advantages that cloud computing offers.

Finally, there's a question about what the hosting companies could do with the data that gets collected on their servers. Obviously, they have access to that data, and obviously, they must be allowed to have some level of interaction with it: encrypting and decrypting it, backing it up, copying it to improve throughput, moving it between servers, etc. This raises questions about exactly what rights the hosting company has. If a hosting company employee looks at your data, what's the penalty? What if a hosting company decides to sell one company's data to a competing company? What if they outsource the data-hosting portion of the business? What if the hosting company decides to mine the data for email addresses and user interests? Whose data is it, anyhow?

Unfortunately, the real-life answers to these questions have been disappointing. So far, court decisions about who "owns" stored electronic data have trended firmly in favor of the owner of the hardware on which that data is stored, or the business that generated the data, regardless of who generated it. For example, many employees have discovered (to their surprise) that anything they write or any data they generate using a company computer (such as email, documents, or Internet access logs) belongs to their employer, and that the employer is perfectly within its rights to analyze that data or use it however they see fit. One recent UK court case found that an employee who simply uploaded his Outlook contacts list to LinkedIn did so illegally, because—even though the employee insisted he had built that contact list personally—it belonged to the employer.

All in all, it's no surprise that a recent survey of top CIOs by Goldman Sachs & Co. found cloud computing was the last item on their priority lists. One analyst posited that the reason cloud computing placed so low is because "They [hosted services] require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding." But it's rather obvious from the simple advantages stated at the beginning of this blog that gauging the benefits of cloud computing does not, in fact, require much technical understanding. It's far more likely that executives and managers are avoiding cloud computing because they do understand the implications, and are simply making logical decisions to protect their business data.

 

An interesting split is becoming obvious in computing today; older people (among them those who were instrumental in empowering computing and the modern web), are increasingly worried about privacy, while younger people (those who've been exposed both to the weband on it—for most of their lives) seem to be far less interested in privacy issues, tending to view the web as a vehicle for social interaction, even if that social interaction involves losing control of their personal privacy altogether.

This emerging difference becomes glaringly clear in the brief comments in this TechnologyReview.com article. For example, Mena Trott, president and cofounder of Six Apart in San Francisco, says: "With the popularity of blogging and online video and photo sharing, we already know that people want to publish significant portions of their lives online. In 10 years, I can easily see someone putting 75 percent of their day online. But it won't all be public."

In contrast, Bjarne Stroustrup, Professor at Texas A&M University and designer of the C++ programming language, says that within five or ten years we can expect "The total end of privacy. Governments, politicians, criminals, and friends will trawl through years of accumulated data (ours and what others collected) with unbelievably sophisticated tools. Obscurity and time passed will no longer be covers."

Even Richard Stallman, the foremost advocate of open source, isn't really interested in open-sourcing people's private data, saying: "I see a danger in the Web today: doing your computing on servers running software you can't change or study, and entrusting your data to U.S. companies required to give it to Big Brother without even a search warrant. Don't risk this practice!"

The problem, as I suspect many older people see it, is that collusion between businesses (those license agreements that give businesses the right to have "associated businesses" access your data) and between businesses and government effectively makes a lie out of assurances such as Trott's that "it won't be all public." The opposite of public is "private," but what is private when ISPs and governments can search through every request, every post, every email, every IM transmission, and every digital phone conversation you have? Is it private just because your neighbors and friends can't see it? Ben Franklin wrote: "Three may keep a secret, if two are dead." That statement's just as true today as it was when Franklin wrote it. Do you really trust people with your private information? If so, why? People with access to secrets not only tend to misuse them, but also share them with others. Even at the business level, recent research suggests that a large number of those with access (network administrators) look at information they're not supposed to be viewing.

It's bad enough when you first truly understand that your recent data is not private. But now, imagine a world in which every faux pas you've ever committed can be discovered, resurrected and perhaps used against you.

Remember when you once posted those pictures of you at that graduation party in Maui? Now you're applying for a job at a company owned by a conservative Christian business network. Too bad. Rejected.

Remember that IM conversation you and your buddy had one evening about your career choices, where you said you never wanted to get put into the position of having to fire large numbers of employees? Now you're up for a promotion, but you have to be willing to wield the corporate axe. Oops, guess you won't get it.

The plain and simple fact is that there is no real privacy in digital data. There never was any complete and total privacy, of course, but there was a strong probability of privacy, because private data was difficult to access and search. Most paper-based data was filed in a single location, and access was typically restricted to people with good reasons to look. Even published information reached only subscribers, or those willing to spend the time manually scanning library copies. Moreover, much private data simply disappeared after a period of time. Records of childhood legal infractions were sealed. Financial records were destroyed after seven years. People threw away letters when you were no longer a part of their lives. And some communications were too difficult to monitor. Phone calls from public telephones were essentially anonymous. Conversations with a journalist were once considered unassailably private. None of that is true any longer—Stroustrup is correct in saying that obscurity and time passed will no longer be covers. The things you say, the places you go, the items you buy, the food you eat, the pages you visit—these combine to create an electronic trail that employers, governments, businesses, or any sufficiently interested and well-financed person can use to discover things about you that you might not want known.

When confronted with this fact, the enemies of privacy typically argue that there's no reason to hide anything you've done unless you've done something wrong that others should know about; that hiding information is tantamount to lying, and that in this age of terrorism, everyone has a right to know everything about you, particularly your government. That argument should sound familiar to those who remember the 1950's witchhunts.

But being able to outlast every tiny personal truth gives you the ability to become the person you'd like to be, rather than the person you were in the past. Americans have long believed in (or at least given lip service to) second chances. We love hearing about the gang member who gets his GED in prison, and goes on to become a successful business executive. We love stories about the prostitute with a heart of gold who marries the millionaire.

Conversely, the inability to obscure every tiny personal fact can make you now and forever the least appealing person you've ever been. The one who gave into temptation, who stole, lied, cheated—who failed in some way, perhaps even in a way that, at the time, wasn't considered a failure. For example, you might have voted for the "wrong" person for President, and mentioned it to your mother in an email, or written it proudly on your FaceBook page. A partisan administration might hold that against you.

On the other hand, perhaps most humans can see beyond the peccadilloes of people's pasts—particularly when their own mistakes are equally open to scrutiny. Perhaps the stigma of indiscretions currently held private will disappear, when it's no longer possible to hide them. Perhaps the total honesty engendered by "life searching" will create better, or at least more tolerant people. (I'm skeptical myself, but one can always hope.)

So is this generational divide in the approach to privacy due to accumulated wisdom, or is it due to aging pessimism? What do you think?

From a developer's perspective, Tech Ed 2008, which attracted over 6000 developers to Orlando, doesn't offer much that's completely "new;" however, it does offer a great deal of value for developers who need to find out about existing technologies. If there's a single overview word that one might use to describe the thrust of the conference, it's "unification." Microsoft is unifying the developer view into its existing technologies.

For example, starting with the small and moving toward the large, the .NET Compact Framework, the .NET Embedded Framework, Silverlight, Office, Visual Studio, SharePoint, BizTalk, and SQL Server all leverage developers' knowledge of the .NET framework and its supported languages in very much the same way; after becoming familiar with the framework and one language, you can build on that knowledge to write applications intended to run embedded in other devices, to run on mobile devices, to deliver rich content through a browser, integrate with Office applications, run as standalone desktop or Internet-connected applications, or run custom code inside SQL Server—all without having to learn a completely new environment or language. Unification is the theme not just with developers, but with architects, development managers, designers, testers, and maintenance; the newest and upcoming toolsets cover the entire application lifecycle.

One of the most exciting additions to this lineup is Silverlight—no, not the 1.0 version; the new 2.0 (still beta, but soon to be released with a Go-Live license) version. Silverlight puts Microsoft's WPF technology—specifically XAML—front and center in the development world.  The new version not only improves rich media (video/audio) delivery, but moves beyond JavaScript, letting developers write Silverlight code in familiar .NET languages such as C# and VB—and some newer ones, such as IronPython and IronRuby. If you haven't started exploring WPF, I highly recommend it.

Bill Gates, giving what may be his last keynote for Microsoft (he's stepping down at the end of June to concentrate on his work with the Bill and Melinda Gates Foundation) mentioned two other noteworthy topics. First, SQL Server 2008 (soon to be available as RC 0) adds the ability to store geographic location points (geopoints) as a native type. In a brief demonstration, he showed how a user could identify a point, and an application could request additional points of interest within a circle with a defined radius from that point. While perhaps not groundbreaking, adding location data as a base type both simplifies developing location-aware applications, and elevates them to mainstream status. 

Other enhancements to SQL Server 2008 include support for external blob storage in the file system, on local NTFS-formatted drives. Storing blobs externally gives SQL the ability to manage files and large binary data blobs in an intuitive way, letting developers treat them as standard file streams, while still taking advantage of SQL Server's transaction, rollback, and backup features. This also helps to avoid the performance penalty associated with storing large blobs internally.

Finally, SQL Server 2008 adds support for hierarchical data (tree structures). While it's been quite possible to handle such data before, T-SQL itself provided no assistance. Because tree-structured and hierarchical data has become ever more common, that's a welcome addition.

Another welcome technology, although still under development, is enhanced modeling in Team Studio.Brian Harry, a Technical Fellow in Microsoft's Developer Division, demonstrated how code submitted to a project repository containing a model of the application can be tested at check-in to ensure that the code contains no dependencies that would break the model. As applications have become ever more complex, improved modeling support helps to unify the original architect's vision of not only the application but the application code itself. The modeling support will ship as part of "Oslo," Microsoft's code name for its upcoming model-driven and service-enabled application toolset(Oslo is MS's vision, but what, exactly, is it? What kind of app? EG). Brian said developers could expect a CTP of Oslo at Microsoft's PDC conference in October.

Being in the front row for perhaps Bill's last keynote reminded me how long I've been working in this industry; I remember when IBM chose the relatively unknown company Microsoft as the supplier of its PC operating system—DOS. Bill's departure comes at a time when development is undergoing a major shift, where instead of having to learn new languages or new hardware platforms to gain new capabilities, developers can concentrate on gaining deep knowledge of their core focus areas, relying on tool improvements to give them access to new capabilities and new devices, while still using their existing tools. We all owe Bill a debt of gratitude. Sure, he was lucky to be in the right place at the right time, but he also helped create our industry and make developers a driving force in the modern world. Thanks, Bill. Good luck in your new endeavors. You'll be missed.

Business computing today works largely on a flawed vision of reality. For example, consider an inventory-management application. The system holds a list of items in a database, such that:

• When items arrive at the store, the item counts are incremented with the number of items that get stocked.
• When an item gets sold, the system decrements the count for that item.
• When an item count falls to a specific pre-set level, the system marks that item for ordering, or possibly even orders more stock automatically.

But the system doesn't really know how many items the store has. It can't, because the items themselves have no connection to the computer. For example, the system can't—by itself—account for misplaced items or stolen items. The system is forced to rely on a human to give it that type of information.

All that's going to change, because one of the next big advances in computing is location-based computing, which uses one or more methods to let the computer know and track the exact location of objects or people.

Location-based computing, so far, has been primarily concerned with GPS information: geographic locations—positions—of roads, buildings, trucks, and, in some cases, people. Trucking companies, for example can attach a GPS system to their trucks, which can then wirelessly send their location back to company headquarters every second or so, letting the company track the actual position of the truck. If it stops, the company will know. If it gets lost, the company will know. If the driver speeds, or drives too slowly, or takes a detour to visit his family, the company will know.

Similar applications let you track individuals via their GPS-enabled cell phones, or indeed, any cell phone, because software can triangulate the position of a cell phone by the relative speed with which it responds to various cell phone tower signals. That's how the 911 emergency service can locate a cell phone caller.

GPS tracking is fine for large objects that move large distances outdoors, but it's not cheap. A GPS receiver is relatively large, and it's not well-suited for tracking objects that are indoors, where they don't have clear access to satellite signals or objects that move only small distances, such as items in a store, books in a library, or children in a school. Another technology, called Radio Frequency Identification (RFID), is better suited for tracking small objects. Several years ago, Walmart, in a rare lucid action that might actually benefit employees, customers, and the corporation, announced it would require all its Sam's Club suppliers to tag shipping pallets with RFID tags by 2010. At that time, RFID technology was in its infancy, tags were battery-powered, relatively large, and expensive.

Tagging pallets to trackmerchandise uses RFID at the macro level, but still doesn't help computers track individual objects—the goods after they're removed from the pallet. But we're about to see an explosion in location-based computing at the micro level. Newer generations of RFID tags are far smaller, have (mostly) dropped the battery and draw power from the tag reader's electrical signal, can hold more data, and are more reliable. You can easily buy tags today that are about the size of a grain of rice—but much smaller tags are in development; some are the size of a dust particle, almost invisible to the naked eye. 
RFID tags do cost money, but the price is coming down rapidly. Costs vary depending on the type of tag (powered or unpowered), how close a reader must be to read the tag, the amount of information the tag will hold, the tag's frequency, the tag's size, and of course, volume. Common unpowered tags currently cost between 7 and 15 cents per tag. They're already being used on some big-ticket items, particularly those that are small and easy to misplace or steal. Readers cost money as well, running from $100 to $750 or so, with the average reader probably running around $300. At these prices, the tags obviously aren't ready to be used to track inexpensive items. However, they're already reaching the price point where they're useful for tracking more expensive items, where keeping the item's location in sync with software is critical.

If you're already working with location-based computing technologies, let me know. If you're not, but you have ideas about how you plan to use location-based computing in your business or your applications, let me know that as well.

 

Here's the average developer's newest dilemma: Intel and other CPU manufacturers have moved full steam ahead into creating multi-core chips to speed up computing. These chips increase processing speed not by improving the speed of a single CPU as has traditionally been the case when new chips debuted in the past, but by adding additional CPUs. These new chips contain two, four, or (soon) eight CPUs. The idea is that developers can (potentially) double, quadruple, or octuple the speed of their applications by writing code that can split operations across all the available CPUs. That's great--in theory. In practice, however, it turns out that few developers are comfortable writing and debugging even multi-threaded code running on a single CPU, much less writing and debugging code intended to run in parallel on separate CPUs. Moreover, the languages most working developers use don't yet contain constructs that allow them to target multiple CPUs, nor are the debuggers all multi-CPU aware or capable. Nonetheless, hardware manufacturers are already touting the speed increases businesses should expect from their software when it's running on the new chips. And no doubt, managers will soon be asking why their new dual-CPU hardware is no faster when running their existing applications than their old hardware was.

As usual, the hardware cart has been put before the software horse. Sure, the C and C++ guys can find some first-generation tools for writing multi-core code. But for business software, the miracles won't start appearing until developers get multi-core tools that work with their common standard languages.