New Technique for Tracking Gestures

An interesting new technique is being explored for tracking gestures. This technique is of special interest to me because, at one time, I worked with SONAR in the Navy. At the time I worked with SONAR, it never occurred to me that the techniques I was using, would also have so many civilian applications. However, things like Doppler effect have had a huge affect on sciences such as predicting the weather. Now there is a new use of the Doppler effect in sensing gestures. When someone moves their hand in a specific way, a system can sense the hand movement and use it to perform a task. Right now the technique is more of an experiment than something that’s useful. The current technology can sense five gestures, but the inventor says that it will eventually be able to sense up to ten gestures. Personally, I think the technology will become refined enough to do a lot more.

My interest in this technology is as a means of providing one more form of accessibility aid for those who need it. Using the Doppler effect in this way has the advantage of making it possible to sense gestures in any light and under most conditions. In other words, even though the range of gestures is limited, once refined, the technology should prove extremely reliable. If you have some special need, reliability is always a primary concern. You need to know that the technology you’re using is always going to work as expected, even if that technology is a little less flexible than you’d like it to be. Someone who has some type of movement or speech need could use hand gestures to better communicate with the computer.

More importantly, for me, seeing this technology coming out tells me that science fiction often becomes science fact. Cinematic presentations such as TekWar have emphasized the use of hand gestures for years now. I remember being quite engrossed in the four made-for-television movies when they came out. One of the technologies that grabbed my attention was how people were manipulating computer input in a 3D space using gestures. This sort of technology seemed like complete fantasy at the time, but now it seems a lot closer to reality.

One of the questions that has occupied my mind for years is whether the mouse and keyboard will eventually go away. Voice technology gets close, but not close enough. I certainly couldn’t use something like Dragon Naturally Speaking to write my books, but some people do use it to create less technical documents. (In fact, I’ve reviewed this product several times—the last time on DevSource, but the article is no longer available.) Human speech is so complex that we really do need something to augment technologies used to understand it. Perhaps gesture technologies will fulfill this role.

How do you see the future of computing? Will gesture technology, coupled with some for of spoken input, eventually replace the keyboard and mouse? How do you think this technology will serve as an accessibility aid? Let me know at John@JohnMuellerBooks.com.

 

Updating Application Code

At some point, every application requires update. It’s impossible to write the perfect application that never requires one. Something will happen to cause an issue that requires attention. If you happen to work at the same place for a long time, you may be the one to update your own code, but in reality, that rarely happens. It’s far more likely that you’re going to inherit code written by someone else. That’s why I wrote “How to Inherit Somebody Else’s Code” for Software Quality Connection (SQC). The article was posted yesterday and provides you with some interesting ways to make your application update easier.

My basic motivation in writing the article for SQC was to provide some insights into a process that most developers abhor. Code written by someone else often appears poorly written because the updater would have used a different technique. Any comments will appear nonsensical or useless because it’s hard to understand the thought process the other developer used to create the code. The problem is one of communication. You may not have any contact with the developer who wrote the application, so the only information you have is the documentation and code that the developer left behind. There is no one there to answer your questions, making delving into the code frustrating.

Updating another developer’s code need not be a painful experience. In many cases, once you understand the application, it does appear well (or at least adequately) written and the comments begin to make sense. My article helps you get to that point faster. Rather than waste time thinking about how much of an idiot your predecessor is, you can spend more time getting the update done early and then knocking off the weekend. In many respects, updating other developer’s code is a good experience—it exposes you to new coding techniques and helps you see things in ways that you might not have thought about on your own.

Of course, I’m always looking for ways to make my writing better. If you have any insights you’d like to share or have some ideas for content you’d like to see, leave a comment here or contact me at John@JohnMuellerBooks.com. You can also leave comments on SQC and I’ll be sure to see them.

 

Understanding the LINQ Question

A few readers have written to ask me about the question I keep discussing when talking about LINQ. I use the idea of a question in both LINQ for Dummies and Start Here! Learn Microsoft Visual C# 2010 Programming to describe the concept behind LINQ. In fact, if you have problems understanding this concept, you’re not alone. Many people have trouble understanding just how it is that declarative languages such as LINQ and SQL perform their job. The idea that you can describe what you want and let the computer decide how to do it is foreign to many people because most people rely on procedures to understand many issues. LINQ and SQL don’t offer procedures. At the root of the problem is the word “how.” We want to know how things work and how to do things.

Imagine for a moment that someone tells you to go to 123 Anywhere Street and pick up a widget for them from the grocery store. They don’t tell you how to get to 123 Anywhere Street or anything else about the request—they simply assume that you’ll figure it out on your own. Most people would eventually get a map, work out a route, and get to 123 Anywhere Street. Once there, they’d go to the grocery store and ask for a widget from the owner. This sequence of events is akin to what is happening with both LINQ and SQL. You tell the computer to get the widget from the grocery store at 123 Anywhere Street. The “how” is unimportant and you truly don’t care how the computer accomplishes the task.

So, where does the question part of this discussion come into play? Developers want data to manipulate within their applications, not widgets. When a developer requests data from the computer using a language such a LINQ, the developer does so in the form of a question or a query. In fact, declarative languages often use the word query as part of their nomenclature: Language INtegrated Query (LINQ) and Structured Query Language (SQL). These languages specialize in asking questions and telling the computer to use any means necessary to answer them. The developer doesn’t care how the language does its work—all the developer cares about is the data.

Declarative languages free the developer from having to think about how to perform tasks. A developer can spend more time thinking about data manipulations and less time thinking about the mechanics of language. This means that the developer can become a lot more productive and write applications significantly faster. The use of declarative languages also makes application development easier. A less skilled developer can write a more complex application.

Don’t get the idea that LINQ is a wimpy language that limits what you can do in the interest of simplicity. In fact, LINQ users can create extremely complex scenarios that would require considerable time to figure out without LINQ. For example, I wrote an article about using LINQ Extensions some type past. You’ll want to review this article if you need to see one of the more technical ways to use LINQ (and even this article doesn’t discuss the topic in depth). While you’re at it, check my other articles on using LINQ Expression Trees and using LINQ with Resource Description Framework (RDF) files.

The bottom line is that LINQ is about queries, or questions. You ask the computer to supply data based on some criteria. The computer decides how best to obtain the data for you, so you can concentrate on issues that the computer can’t decide, such as data manipulation and presentation. If you have additional questions about why someone would use LINQ or why I explain LINQ as answering questions, please let me know at John@JohnMuellerBooks.com.

 

Watching a Directory for Changes

A lot of my books have examples that require reliable access to one or more files on the hard drive. For example, the example showing how to load an XML file from disk on page 472 of C# Design and Development requires that the file is present—you can’t load a file that doesn’t exist. In fact, the need to know that a file is present is an overwhelming requirement in most of my books. For the most part, I can rely on the File.Exists() method to ensure that the file is there. If it isn’t, then I provide code to:

  • Rebuild the file
  • Use a backup file
  • Ask the user to supply the file
  • Create a new file from scratch.


I’m sure there must be other techniques in some of my books to handle the missing file, but the point is that when a file is missing, you have to deal with it in some way or the application will crash. A reader recently asked about an alternative to dealing with the missing filepreventing the user from deleting it in the first place (or at least logging the deletion). Sure, the user could attempt to delete the file, but a Windows service would sit in the background and place the file in a safe location for later retrieval. The suggestion has merit. It avoids the whole process of figuring out what to do now that the user has made life difficult.

I’ve written about working with Windows services in the past. In fact, it’s relatively easy to create a Windows service using Visual Studio. You can read about the process in my article entitled, “Writing a Managed Windows Service with C#.” However, that article doesn’t discuss how to monitor a directory so that you can detect a deletion and log the deletion as a minimum. So, that’s what I’ll discuss in the remainder of this post.

The FileSystemWatcher class provides the means to monitor file system changes and react to them. The concept is relatively simple. You create code that monitors the directories used by your application for changes. When a change occurs, you do something about it. I’ve created a very simple example to demonstrate the basics of what you need to do. Before you do anything else, add a reference to System.IO to your application.

Now that you have the required reference, let’s create a FileSystemWatcher. The first task is to initialize the object. I’ve created a simple button named btnStart to perform this task. The following code is a good starting place.

private void btnStart_Click(object sender, EventArgs e)
{
   if (btnStart.Text == "&Start")
   {
      // Keep an eye on C:\Temp.
      FSW = new FileSystemWatcher(@"C:\Temp");
 
      // Change the button text.
      btnStart.Text = "&Stop";
   }
   else
   {
      // Delete the existing FileSystemWatcher.
      FSW = null;
 
      // Change the button.
      btnStart.Text = "&Start";
   }
}

Unfortunately, this code won’t do much. Sure, it creates or destroys the FileSystemWatcher as needed, but it doesn’t really handle anything. To perform this next step, you need to create an event handler in the first part of the if statement. Since this reader is interested in deletions, you create a Deleted event handler by typing FSW.Deleted +=. When you type the =, the IDE automatically starts helping you create the required code. Press Tab to create the required FileSystemEventHandler object and then press Tab again to create the event handler, which is FSW_Deleted() in this case. Just to make things easy, the example displays a message box whenever the user deletes anything from C:\Temp. To make things symmetrical, you also have to remove the event handler in the second part of the if statement. The full code for this example then is:

// Create the FileSystemWatcher.
FileSystemWatcher FSW;
 
private void btnStart_Click(object sender, EventArgs e)
{
   if (btnStart.Text == "&Start")
   {
      // Keep an eye on C:\Temp.
      FSW = new FileSystemWatcher(@"C:\Temp");
 
      // Make sure that the FileSystemWatcher has events enabled.
      FSW.EnableRaisingEvents = true;
 
      // Change the button text.
      btnStart.Text = "&Stop";
 
      // Create a deleted event handler.
      FSW.Deleted += new FileSystemEventHandler(FSW_Deleted);
   }
   else
   {
      // Remove the event handler.
      FSW.Deleted -= FSW_Deleted;
 
      // Delete the existing FileSystemWatcher.
      FSW = null;
 
      // Change the button.
      btnStart.Text = "&Start";
   }
}
 
void FSW_Deleted(object sender, FileSystemEventArgs e)
{
   // Display a message box.
   MessageBox.Show("The user deleted: " + e.Name);
}

 

When you click Start, the application will monitor C:\Temp for any deleted files. Make sure that you set EnableRaisingEvents to true or the FileSystemWatcher won’t raise any events. When a deletion occurs, you see a message box telling you which file has been deleted. This solution is incomplete at the moment, but I plan to revisit it in the future. In the meantime, you have a tool now for knowing when a deletion has occurred that will affect the stability of your application so you can do something about it before the application crashes. Let me know if you have any questions at John@JohnMuellerBooks.com.

An Update About Mono

I’m not one to get stuck on a particular form of a technologyit’s best to use the solution that works, rather than make a favored solution try to fit. Many .NET developers miss opportunities to move their solutions to other platforms or use them in places that normally don’t work well with the .NET Framework by leaving out Mono, the .NET Framework alternative. Most people associate Mono with the Macintosh or Linux, but there is also a Windows form of Mono. When Windows Server 2008 Server Core came out without the .NET Framework, I immediately wrote an article about it entitled, “Mixing Server Core with .NET Applications.” In fact, I’ve promoted Mono to frustrated administrators in my book, “Administering Windows Server 2008 Server Core.” Before Microsoft finally came out with a .NET Framework solution, you could use Mono to do things like run ASP.NET applications on Windows Server 2008 Server Core and my book told you how to do it in Chapter 24.

So, I was more than a little disturbed when I heard that the Mono crew had been laid off by Novell. Fortunately, I discovered later that the layoffs are just a prelude to having Mono supported by a new company named Xamarin. To read more about this company, check out Miguel de Icaza’s blog entry, “Announcing Xamarin.” Not only will the new company continue supporting the open source versions of both Mono and Moonlight (the Silverlight alternative), but it’ll create new commercial products for both Android and iOS. In short, this development is actually good because the new company will focus on this incredibly useful technology.

My main concern for the new company is that they won’t have the funding to do everything they envision doing, but that remains to be seen. Reading Mary Jo Foley’s article gives me hope that they’ll succeed. What are your thoughts about Mono? Is it a technology that you’ve used or at least are willing to try? Let me know at John@JohnMuellerBooks.com.

 

Getting the Right Visual Studio Add-In

Give me the right tool and I can use it to create just about anything in code! It’s a bold statement and I’m sure that I’d have little trouble finding a lot of other developers who believe precisely the same thing. Unfortunately, finding the right tool is akin to finding a needle in a haystack (feel free to substitute any other worn cliche you can think about). How does someone quantify the usability of a tool or decide whether to even download it in the first place. I recently wrote an article for Software Quality Connection entitled, “Techniques for Finding Useful IDE Add-ins” that answers that question. The article proposes some techniques you can use to make the process of finding just the right add-in easier.

Of course, my great add-on is a piece of junk for you. Our needs, goals, programming skills, and programming tasks differ. So, what I’d like to know is how you look for add-ins and how you use them to create better applications. It’s nice to get another perspective on a given topic. Over the years I’ve talked with hundreds (perhaps thousands) of readers about the tools they use because the right tool in the right hands can do amazing things. Most of my books contain a healthy number of links to various tools and I often employ add-ins in my books to make tasks easier. Let me know about your favorite add-in and tell me why you think it’s so great at John@JohnMuellerBooks.com. (Please, no vendor e-mails. I already know your tool is great; I really want to hear from people in the trenches on this topic.)

Part of my reason for asking this sort of information is to improve the quality of my books and articles. Quality is extremely important to me. In fact, it’s the reason I created the beta reader program. A beta reader reviews my manuscript as I write it. You can find out more about the beta reader program in my Errors in Writing post. If you want to become a beta reader, just write me at John@JohnMuellerBooks.com for additional details. In the meantime, try out some new add-ins and have a bit of fun .

Inheriting Someone Else’s Code

In my book, “C# Design and Development,” I propose a lot of management techniques that could apply to any language. In fact, I’ve used the techniques in this book successfully for years with Visual Basic, C#, IronPython, C++, and PHP, among many others. The idea behind the concepts in this book is to create code that performs well from the outset and is easy to maintain when changes are required. In today’s environment, you can count on changes at some point. There are many reasons to expect changes:

 

  • The business is bought by someone else and the code must be integrated into a new system.
  • A change in some other component necessitates a change in the application (such as the changes in Vista and Windows 7 security).
  • The business has grown and now needs new features to support its customers.
  • Modifications in the law mean changes to the way the application interacts with data.
  • Technology changes in such a way that the application no longer works properly.

In fact, the reasons for change are endless. I could probably continue writing reasons for change for hours and not cover even a small number of them. The point is that applications will change at some pointit’s simply a matter of time.

If you’ve written code for any time at all, you know that feeling in the pit of your stomach when you discover the perfectly lucid comments you wrote at the time you created the application are no long lucid now. Worse still, the documentation you put together doesn’t tell you what you did and why. Still, after a few hours of looking at your comments and documentation, you can usually begin to fit the pieces together of an application you created because you can recreate the thought patterns you had when you designed and wrote it in the first place.

However, what happens when you’re part of a team or you’re working on an application that someone else designed? Now there isn’t any way to “get back into the groove” of what you did in the past. The thought processes are foreign, so the comments and documentation have to be as comprehensive as possible. Even with great comments and documentation, it’s going to take a while to get up and running with the code.

The longer it takes you to recreate the ideas that went into creating the code, the longer the project update languishes and the more extreme management’s position becomes. The only thing that management knows is that your application (the one you inherited from someone else) is costing the business money. Not only is there a cost associated with the update, but the delay costs the organization money too. Users who have to fight with an outdated application are always unhappy and aren’t productive. So, what techniques can you use to become productive as quickly as possible? That’s what I’d like to know as well. Obviously, reading the documentation and comments are two pieces to the puzzle, but what other techniques do you use?

I’m currently putting an article together that discusses this topic in detail and I’d like to hear about your techniques. If you’ve ever been frustrated by someone else’s code, write me at John@JohnMuellerBooks.com. I’ll let you know when the article is published on Software Quality Connection

 

Working with Low Level Code

Working with low level code is becoming less necessary as Microsoft continues to improve the .NET Framework, but you sometimes still need to resort to direct Win32 API access using P/Invoke.  My book, “.NET Framework Solutions: In Search of the Lost Win32 API,” is a great place to learn about P/Invoke and the significant number of ways you can use it to access Windows features that Microsoft hasn’t made available in the .NET Framework yet.  For example, you’ll find a thorough discussion of the Windows messaging system in Chapter 4.  However, the discussion is a bit lengthy because there is so much you can do with the Windows messaging system.

One of the questions I get asked quite often is whether there is a quick start sort of guide I can recommend for working with the Windows messaging system.  With that in mind, I wrote a series of four DevSource articles some time ago.  Here’s the complete article list:


These four articles provide quite a bit of information about Windows messages that you might not know from a .NET perspective.  Using these techniques can save you considerable time, especially when you need to interact with other applications.  In fact, the final article reveals secrets you can use to interact with applications when you don’t have the source code; a significant problem for most developers.  So, how do you use P/Invoke?  Have you had to resort to P/Invoke to work with Windows 7 features that haven’t been added to the .NET Framework yet?  Let me know at John@JohnMuellerBooks.com.

 

Moving from 32-bits to 64-bits

64-bit processors have been around for a long time now. Unlike the move to 32-bit processors, the move to 64-bit processors has been sluggish. In fact, if the move goes any slower, we’ll still be using 32-bit processors ten years (or more) from now. The main reason that the move to 64-bit processors has been so incredibly slow is that users are basically happy with their 32-bit setups. There isn’t any compelling application that makes the move to a 64-bit environment necessary, or even desirable. So, we still have 32-bit Windows XP enjoying a huge market share. It wasn’t until October 2010 that its market share finally fell below 60 percent.

However, the environment is beginning to change for a number of reasons. For one thing, Windows XP is becoming less secure as Microsoft starts to view it as an old OS past its prime. Yes, you still get security updates for Windows XP, but it’s only a matter of time before those updates become ineffective; the platform is simply becoming outdated and hard to maintain.

Anyone who has worked with Vista knows that the platform has problems. In fact, I tried my best not to work with it unless absolutely necessary. Windows 7 is a different story. I’ve been using it now for quite a few months without any problems at all. In fact, except for a few problem applications, I don’t even notice the Windows 7 differences any longer; it has become part of the background for me, as it has become part of the background for many people.

Windows 7 works best as a 64-bit operating system. I tried it as a 32-bit operating system and found that it lacked pep. A memory upgrade and moving to Windows 7 64-bit have made all the difference in the world. I now consider Windows 7 a true upgrade to Windows XP and hope that people begin moving to it en masse soon.

Microsoft has also made the move to 64-bits in some of the server products it offers. For example, Microsoft Exchange comes only as a 64-bit product now, as does SharePoint. Consequently, many organizations are beginning the arduous upgrade to 64-bit operating systems on their servers.

Using a 64-bit setup does have significant advantages. Of course, there is the availability of additional memory to consider. It’s also possible to perform certain code optimizations on a 64-bit system that you can’t achieve using 32-bits. Of course, if you want to obtain the full benefits of a 64-bit platform, you need 64-bit applications. Some developers are worried about the consequences of this move and for good reason. Making the move to the 64-bit environment is fraught with unexpected pitfalls. My latest article, “10 Biggest Issues for Developers Migrating 32-bit Applications to 64-bits”, explains some of the most common problems that developers encounter when moving their applications to the 64-bit environment. Give it a read and let me know what you think at John@JohnMuellerBooks.com.