Using My Coding Books Effectively

A lot of people ask me how to use my books to learn a coding technique quickly.  I recently wrote two articles for New Relic that help explain the techniques for choosing a technical book and the best way to get precisely the book you want. These articles are important to you, the reader, because I want to be sure that you’ll always like the books you purchase, no matter who wrote them. More importantly, these articles help you get a good start with my coding books because you start with a book that contains something you really do need.

Of course, there is more to the process than simply getting the right book. When you already have some experience with the language and techniques for using it, you can simply look up the appropriate example in the book and use it as a learning aid. However, the vast majority of the people asking this question have absolutely no experience with the language or the techniques for using it. Some people have never written an application or worked with code at all. In this case, there really aren’t any shortcuts. Learning something really does mean spending the time to take the small steps required to obtain the skills required. Someday, there may be a technology that will simply pour the knowledge into your head, but that technology doesn’t exist today.

Even reading a book cover-to-cover won’t help you succeed. My own personal experiences tell me that I need to use multiple strategies to ensure I actually understand a new programming technique and I’ve been doing this for a long time (well over 30 years). Just reading my books won’t make you a coder, you must work harder than that. Here is a quick overview of some techniques that I use when I need to discover a new way of working with code or to learn an entirely new technology (the articles will provide you with more detail):

  • Read the text carefully.
  • Work through the examples in the book.
  • Download the code examples and run them in the IDE.
  • Write the code examples by hand and execute them.
  • Work through the examples line-by-line using the debugger (see Debugging as An Educational Tool).
  • Talk to the author of the book about specific examples.
  • Modify the examples to obtain different effects or to expand them in specific ways.
  • Use the coding technique in an existing application.
  • Talk to other developers about the coding technique.
  • Research different versions of the coding technique online.
  • View a video of someone using the technique to perform specific tasks.

There are other methods you can use to work with my books, but this list represents the most common techniques I use. Yes, it’s a relatively long list and they all require some amount of effort on my part to perform. It isn’t possible to learn a new technique without putting in the time required to learn it. In a day of instant gratification, knowledge still requires time to obtain. The wisdom to use the knowledge appropriately, takes even longer. I truly wish there were an easier way to help you get the knowledge needed, but there simply isn’t.

Of course, I’m always here to help you with my books. When you have a book-specific question, I want to hear about it because I want you to have the best possible experience using my books. In addition, unless you tell me that something isn’t working for you, I’ll never know and I won’t be able to discuss solutions for the issue as part of blog post or e-mail resolution.

What methods do you use to make the knowledge you obtain from books work better? The question of how people learn takes up a considerable part of my time, so this is an important question for my future books and making them better. Let me know your thoughts about the question at John@JohnMuellerBooks.com. The same e-mail address also works for your book-specific questions.

 

API Security and the Developer

As our world becomes ever more interconnected, developers rely more and more on code and data sources outside of the environment in which the application runs. Using external code and data sources has a considerable number of advantages, not the least of which is keeping application development on schedule and within budget. However, working with APIs, whether local or on someone else’s system, means performing additional levels of testing. It isn’t enough to know that the application works as planned when used in the way you originally envisioned it being used. That’s why I wrote API Security Testing: Think Like a Bad Guy. This article helps you understand the sorts of attacks you might encounter when working with a third party API or allowing others to use your API.

Knowing the sources and types of potential threats can help you create better debugging processes for your organization. In reality, most security breaches today point to a lack of proper testing and an inability to debug applications because the inner workings of that application are poorly understood by those who maintain them. Blaming the user for interacting with an application incorrectly, hackers for exploiting API weaknesses, or third parties for improperly testing their APIs are simply excuses. Unfortunately, no one is interested in hearing excuses when an application opens a door to user data of various types.

It was serendipity that I was asked to review the recent Snapchat debacle and write an article about it. My editorial appears as Security Lessons Courtesy of Snapchat. The problems with Snapchat are significant and they could have been avoided with proper testing procedures, QA, and debugging techniques.This vendor is doing precisely all the wrong things—I truly couldn’t have asked for a better example to illustrate the issues that can occur when APIs aren’t tested correctly and fully. The results of the security breach are truly devastating from a certain perspective. As far as I know, no one had their identity stolen, but many people have lost their dignity and privacy as a result of the security breach. Certainly, someone will try to extort money from those who have been compromised. After all, you really don’t want your significant other, your boss, or your associates to see that inappropriate picture.

The need to test APIs carefully, fully, and without preconceived notions of how the user will interact with the API is essential. Until APIs become more secure and developers begin to take security seriously, you can expect a continuous stream of security breaches to appear in both the trade press and national media. The disturbing trend is that vendors now tend to blame users, but this really is a dead end. The best advice I can provide to software developers is to assume the user will always attempt to use your application incorrectly, no matter how much training the user receives.

Of course, it isn’t just APIs that require vigorous testing, but applications as a whole. However, errors in APIs tend to be worse because a single API can see use in a number of applications. So, a single error in the API is spread far wider than a similar error in an application. Let me know your thoughts on API security testing at John@JohnMuellerBooks.com.

Entering Data in a Code::Blocks Window

Sometimes it isn’t very obvious how to enter data into a Code::Blocks window. One of the windows that seems to be causing problems for a number of readers is the Watches window. You open this window by choosing Debug | Debugging Windows | Watches. The purpose of this window is to let you view the content of variables in your application, which is an essential part of the debugging process. In order to view the variable (or other expression) content, you must enter it in the Watches window. Book III of C++ All-In-One Desk Reference For Dummies tells you all about debugging.

One technique for entering the variable is to select it in the editing window and the drag it to the Watches window. The variable will appear in the Watches window along with its value. However, this approach only works for variables and expressions that actually appear in your code. You might want to enter some other expression (or manually enter the variable, rather than drag and drop it). The Watches window consists of rows and columns as shown here.

WatchEntry01

The name of the variable or the expression you want to view appears in the first column. To enter a new value into the Watches window, click directly in the first empty left column cell. The row will turn blue and you’ll see a red insertion point appear in the cell as shown in the screenshot. Now you can type the variable name or expression you want to work with and press Enter. Let’s say your variable is named i. It might look like this:

WatchEntry02

Notice that the row is now white because it isn’t selected. However, you can see the name of the variable, i, it’s value 1983844706, and it’s type int. The row is in red because the value of i has just changed (unchanged values appear in black so you can see them easier). As you debug your application, you can now watch the value of i for changes.

Sometimes it isn’t obvious how to enter information into Code::Blocks (or any other application for that matter). When that happens, the focus turns to the application, rather than the work you need to do, and the experience becomes frustrating. Let me know about your book-related Code::Blocks questions at John@JohnMuellerBooks.com and I’ll do my best to answer them. Because I don’t have a direct connection to the vendor, my ability to answer other sorts of questions is limited.

 

Pausing the C++ Example Output

A number of readers have written to ask about running the example code in C++ All-In-One Desk Reference For Dummies. The book shows that the examples pause so you can see the output, yet a few people experience problems getting the example to pause as shown in the book. Let’s take the first book example. When you run the example, you should see a command window similar to the one shown here open.

ExamplePause01

This is how the command window looks in Windows, but if you use some other operating system, you should see something similar. Notice that the output is paused. Pressing any key will cause the window to disappear and the example to end. The purpose of pausing the output is so that you can see the result.

There are two common reasons that people aren’t seeing the output pause. The most common reason is that the example is run in debug mode. Make sure you click Run or choose Build | Run to execute the example. If you click Debug/Continue or choose Debug | Start/Continue instead, the example will execute without pausing and you won’t see the output. Of course, you can always set a breakpoint to get the example to pause, but most people simply want to see the example output which means running the example, rather than debugging the example.

A less common cause is that the project environment is configured incorrectly. Normally the Code::Blocks environment automatically pauses when you run the example. However, it’s possible to set Code::Blocks not to pause. Some readers inadvertently change this setting while exploring the environment. In order to check this setting, choose Project | Properties to display the Project Targets/Options dialog box. Select the Build Targets tab and you see the dialog box shown here.

ExamplePause02

Notice the Pause When Execution Ends option. If this option is cleared, the example won’t pause when you run it. Make sure this option is checked and click OK. The projects that come with the downloadable code all have this setting set up correctly.

Of course, there could always be other reasons why the examples aren’t pausing. Please let me know if you have any problems setting the example output. It’s essential that you be able to see the example output as you follow along in the book to understand how C++ works. Send your queries about this (or any other book-specific) topic to John@JohnMuellerBooks.com. I always want to ensure you have the best possible experience when using my books.

 

Debugging As an Educational Tool

One of the questions I get asked quite often is how I learn new programming techniques. After all, I work with a broad range of languages and IDEs in my pursuit of new programming environments. Let’s face it—I like to play with code. For me, it’s not really a job to write application code. I like to see how different things work and what’s possible with a given language. In order to accomplish my goals, however, I need to learn techniques quickly. The debugger is my secret to learning how to code quickly and easily. In fact, I’ve written an article on the topic, “Improve Your Coding Skill by Listening to the Debugger.” You also see this technique emphasized in a number of my books, especially LINQ for Dummies and Start Here! Learn Microsoft Visual C# 2010 Programming.

The main reason that I use the debugger as an educational tool is that I can see the code in action. It’s possible to see how the code actually works, rather than envision what the code is supposed to do. The difference is important. For me, seeing the code actually work demonstrates that the theory behind the code is sound. Many theories sound good until you actually try to use them—using the debugger proves the theory as you work through the code.

From a personal perspective, the biggest hindrance that I face in using the debugger as an educational tool is the lack of good comments. In fact, comments are such a problem that I write about them in Creating Useful Comments. When the code lacks comments, I need to look up the calls myself and then determine how the developer is using them. It’s time consuming and a somewhat painful way to learn at times because I can see the code work, but I don’t know how it works or why the developer chose a particular approach. Even worse is when the code contains misleading comments. Worse still are comments that are outright incorrect because they reflect a previous state of the code or the developer didn’t actually understand why a technique works (the sheer dumb luck approach to coding).

Make sure you check out my article on the topic and get back to me about it. I’d like to hear your views on using the debugger as an educational aid. For that matter, I’d like to hear your viewpoint on debuggers as a class of application. Do you feel they need work or are debuggers as useful as they need to be? You may even feel that debuggers have become encumbered by way too many features. Whatever your viewpoint, let me know at John@JohnMuellerBooks.com.

 

Methods of Learning

More than a few readers write me about the best way to learn. Many of them are asking about the best way to learn how to become a programmer—a topic I discuss in my Becoming a Programmer post. However, more and more often, readers are asking me about learning in general. The fact is that I can point you to different techniques for learning, but I can’t determine what will work best for you. You’re the only person who can make that determination and you won’t know until you try a number of techniques. In a society ever more devoted to success at all costs, learning requires that you fail in order to make gains. When you fail, you learn what doesn’t work and possibly why it doesn’t work. So, trying various techniques is the only way to discover what works best for you and that process involves some level of failure.

I imagine that my answer frustrates a lot of people because they don’t want to fail at something, so they ask what works best for me. Mind you, what works for me probably won’t work for you. I personally learn best by working through examples written by other people. When it comes to programming, I rely on application examples written by other developers and scrutinize them intensely using the debugger so that I can see precisely how they work. Then I create applications of my own that use those techniques to ensure I actually do understand how things work. Likewise, I use examples from other woodworkers, gardeners, or other professionals as a basis for my own hands on learning experiences. In addition to these hands on techniques, I also read a large number of books and articles every year. Often, all I really need to learn a new technique, is a good explanation of it. I read books and magazines in every area that interests me—everything from application development and computer hardware to new gardening techniques and animal husbandry. In some cases, I also attend lectures and seminars to augment my learning, but given that lectures and seminars tend to be expensive, I focus on my primary means of learning new things whenever possible.

Don’t limit yourself to what I use though. There are many other ways of learning that are just as viable and just as important. The only requirements of learning is comprehension (the ability to understand what you’ve learned) and retention (the ability to remember what you have learned). How you achieve your goal is up to you. Here are a few other methods you might consider trying in addition to those that I commonly use.

 

  • Instructor Led Training: There is a good reason that children go to school. An instructor (teacher) can answer questions about a particular skill immediately and fully. The interactive communication that occurs helps the student learn faster and with fewer problems.
  • Tutorials: A tutorial is essentially a set of precisely written procedures meant to guide the student along a particular learning path. It’s a combination of reading and doing that helps someone develop a skill quickly.
  • Interactive Media: This is a newer form of the tutorial that relies on sight and sound to convey meaning. Interactive media includes animations and graphics that help a viewer visualize the content better. Hands on exercises included with the interactive media help the student know when a particular training goal is achieved.
  • Observation: The subtle art of observation isn’t mentioned very often anymore—probably because people are too busy or impatient to use it. I know that I’ve learned more than one new task though simply by watching someone else do it. Observing someone means watching and thinking about what they’re doing. You don’t necessarily ask any questions (and may annoy the person you’re observing when you do).
  • Experimentation: Of all of the methods used to learn, this method provides the highest gains when successful, but also incurs the greatest amount of failure. It’s a matter of asking a question, deciding on how best to answer that question, and then creating an environment in which to determine the answer. In order to ensure that the question is answered correctly, you often have to repeat the experiment a number of times in various environments. Experimenters often discover new knowledge or rediscover lost knowledge, but at the cost of failing a lot.
  • Cooperation: A cooperative learning environment is one in which two peers have part of an answer and choose to share their part with someone who has another part of the answer. The exchange benefits both parties because both now have two parts of the answer. Of course, a cooperative learning environment requires trust on the part of both people.
  • Dissection: When I was younger, I couldn’t be bothered to keep anything in one piece. I dissected everything in an attempt to discover how it worked. Often, that meant not putting the item back together because the dissection process is destructive. Even so, you’d be amazed at how many things you can learn by dissecting an object to see how it’s put together.


This list is incredibly short. Over the years I’ve seen people learn an amazing array of knowledge using all sorts of techniques that boggle the mind. In every case, the successful learner has experimented with various techniques until he or she finds the techniques that work best. These techniques won’t work best for someone else, but they work best for you. I encourage you to fail in order to learn. Don’t be afraid of trying something and then discovering it doesn’t work because that’s the only real way to learn anything. Let me know about your favorite learning technique at John@JohnMuellerBooks.com.

 

Are Enforced Updates a Good Idea?

I currently have a system running Windows 98 in my home because there are some older games and other applications that I still enjoy using on that platform. The system isn’t connected to the Internet or any other machine because I consider the system a security hazard. I’ve set this system up for the sheer pleasure of seeing some of my old applications come to life again and to make use of some older hardware that still works just fine. The system has our movie database on it and a few other non-business items. However, the fact remains that this system would be unsafe to use to browse the Internet. It would probably be infected to the point of being unusable in a matter of hours (if it lasted that long).

Generally, when it comes to my Internet-connected systems, I use the latest software available to keep my systems secure. The software isn’t allowed to languish until it reaches an unprotected state either. I test every available update on one machine. If it works and I don’t see any major problems, I deploy it to all of the other systems I own on the same day. One of the major ways to keep your systems safe is to ensure you’re running the latest version of the software—the one with all of the latest bug fixes.

For most developers, debugging is an ongoing process. Although it seems is if it would be possible to squash every bug in the application after one carefully conducted review, the reality is that most applications are complex enough that even a team of developers can’t find every bug in multiple reviews, much less one. It also doesn’t help that many companies rush products to market long before they’re ready because they need to generate money from that product in order to remain solvent. So, from a certain perspective, we’re all beta testers and those bug updates are a requirement if we want to keep our systems running properly in the hostile environment of the Internet.

Unfortunately, not everyone is as conscientious as I am and some people are downright suspicious of updates. So, I can understand
Microsoft’s perspective about employing forced updates of some of their
products when those products are attached to an unfriendly Internet.
Just in case you haven’t heard it, Microsoft is going to start automatically updating Internet Explorer users. However, Microsoft is hardly the first one to the party with enforced updates. A lot of other vendors use this tactic as well. Many products today include a forced update feature. Most allow the user to opt out of the forced update, but the default setup relies on forced updates to keep less skilled user’s machines updated.

There are many advantages to using forced updates. The most important is that using forced updates keeps everyone on the Internet safer. The fewer machines that nefarious individuals can exploit, the better. Forced updates also reduce vendor support calls and could therefore help keep software costs lower. Using forced updates can also improve the user experience and make users more productive. For all these reasons, and more, I see forced updates as a big win for the less experienced user, especially the home user who is currently susceptible to every sort of virus and intrusion out there.

However, there is a down side to using forced updates. All users find them intrusive. Even if the update is silent, it uses resources during the update process. As a result, the user’s system suddenly slows down, which could actually cause some number of support calls when the update process is a resource hog. Forced updates are also a cause for concern in corporate environments where running untested software can cause a host of interoperability problems with custom software. Expert users also find forced updates a problem because the update can (and usually will) cause problems with the user’s custom configuration.

I’d also like to see forced updates provide a wait feature. Some users will apply unauthorized fixes to repair a bug until an update comes out. These unauthorized fixes tend to cause problems with the update. Giving the user a chance to remove the unauthorized fix before the update occurs will keep the update from actually trashing the user’s system. Personally, I never use these unauthorized fixes simply because they do have such a huge potential for causing more problems than they fix. However, some users don’t have the option to wait for the update to come out and must rely on an unauthorized fix.

So, what is your opinion about forced updates?  Are they a good idea? Generally, I see them as a win for novice and home users, but less helpful to corporate and expert users. Let me know your opinion at John@JohnMuellerBooks.com.

 

Creating Useful Comments

A major problem with most applications today is that they lack useful comments. It’s impossible for anyone to truly understand how an application works unless the developer provides comments at the time the code is written. In fact, this issue extends to the developer. A month after someone writes an application, it’s possible to forget the important details about it. In fact, for some of us, the interval between writing and forgetting is even shorter. Writing good comments is a main topic in C# Design and Development as part of Chapter 13, but I make the topic part of every application development book I write. Despite my best efforts and those of many other authors, many online examples lack any comments whatsoever, making them nearly useless to anyone who lacks time to run the application through a debugger to discover how it works.

Good application code comments help developers of all stripes in a number of ways. As a minimum, the comments you provide as part of your application code provides these benefits.

 

  • Debugging: It’s easier to debug an application that has good comments because the comments help the person performing the debugging understand how the developer envisioned the application working.
  • Updating: Anyone who has tried to update an application that lacks comments knows the pain of trying to figure out the best way to do it. Often, an update introduces new bugs because the person performing the update doesn’t understand how to interact with the original code.
  • Documentation: Modern IDEs often provide a means of automatically generating application documentation based on the developer comments. Good comments significantly reduce the work required to create documentation and sometimes eliminate it altogether.
  • Technique Description: You get a brainstorm in the middle of the night and try it in your code the next day. It works! Comments help you preserve the brainstorm that you won’t get back later no matter how hard you try. The technique you use today could also solve problems in future applications, but the technique may become unavailable unless you document it.
  • Problem Resolution: Code often takes a circuitous route to accomplish a task because the direct path will result in failure. Unless you document your reasons for using a less direct route, an update could cause problems by removing the safeguards you’ve provided.
  • Performance Tuning: Good comments help anyone tuning the application understand where performance changes could end up causing the application to run more slowly or not at all. A lot of performance improvements end up hurting the user, the data, or the application because the person tuning the application didn’t have proper comments for making the adjustments.


I had previously mentioned the need for good comments. Some developers write comments that are nearly useless. Although it’s hard to encapsulate the substance of a good comment, developers who answer these sorts of questions are well on their way to writing good comments.

 

  • Who is affected by the code?
  • What is the code supposed to do?
  • When is the code supposed to perform this task?
  • Where does the code obtain resources needed to perform the task?
  • Why did the developer use a particular technique to write the code?
  • How does the code accomplish the task without causing problems with other applications or system resources?


There are many other questions you could ask yourself, but these six questions are a good start. You won’t answer every question for every last piece of code in the application because sometimes a question isn’t pertinent. As you work through your code and gain experience, start writing down questions you find yourself asking. Good answers to aggravating questions produce superior comments. Whenever you pull your hair out trying to figure out someone’s code, especially your own, remember that a comment could have saved you time, frustration, and effort. What is your take on comments? Let me know at John@JohnMuellerBooks.com.

 

Debugging a CodeBlocks Application with Command Line Arguments

Most application environments provide a means of setting command line arguments and CodeBlocks is no exception. The example shown in Listing 4-12 on page 107 of C++ All-In-One Desk Reference For Dummies requires that you set command line arguments in order to see anything but the barest output from the debugger. This post discusses the requirements for setting command line arguments for debugging purposes.

Let’s begin with the example without any configuration. Every application has one command line argument—the path and application executable name. So, when you run the example shown in Listing 4-12 you’ll see the path and executable name as a minimum, as shown here.

CommandLineArguments01

If you run this example, you may see a different path, but the command line executable should be the same. The point is that you see at least one argument as output. However, most people will want to test their applications using more than one argument. In order to do this, you must pass command line arguments to the application. The following steps tell how to perform this task.

 

  1. Choose Project | Set Program’s Arguments. You’ll see the Select Target dialog box shown here.
    CommandLineArguments02
  2. Select Debug as the target, as shown in the figure.
  3. Type the arguments you want to use, such as Hello Goodbye, in the Program Arguments field and click OK. The IDE is now set to provide command line arguments to the application when you’re using the specified target, which is Debug in this case.

To see how this works, set a breakpoint at the line that reads (you’ll find a discussion of how to set breakpoints on page 375 of the book):

for (int index=0; index < argc; index++)

You also want to create a watch that shows the command line arguments in action. In this case, you want to see the particular argument that the application is processing. Use these steps to set the watch.

 

  1. Choose Debug | Edit Watches. You’ll see the Edit Debugger Watches dialog box shown here.
    CommandLineArguments03
  2. Click Add. You’ll see the Add Watch dialog box shown here.
    CommandLineArguments04
  3. Type argv[index] and click OK. You’ll see the new watch added to the Edit Debugger Watches dialog box.
  4. Click OK. The new watch is ready for use.

You’re ready to test out the new setup. Choose Debug | Start or press F8. The debugger will start. If you don’t see the Watches window, choose Debug | Debugging Windows | Watches. Click Next Line and you’ll see the first command line argument as shown here.

CommandLineArguments05

Notice that the value of index is in red because it has changed to 0. In this case, argc contains 3 arguments (including the first one that you’re seeing now) and that argument is in argv, which is pointed to at the memory address shown. The argument at that first index value is the path and command line executable name, just as expected.

Click Next Line twice. Now you’ll see the second argument, as shown here.

CommandLineArguments06

If you followed the instructions earlier, you should be seeing Hello as the second argument as well. Click Run and you’ll see the output shown here.

CommandLineArguments07

Testing for command line arguments in a CodeBlocks application consists of telling the IDE what to pass in the Select Target dialog box and then setting the correct watches so that you can see how the command line arguments work. Let me know if you have any questions about this process at John@JohnMuellerBooks.com.

 

The Release of Start Here! Learn Microsoft Visual C# 2010 Programming

It’s always exciting to see a new book released. I had previously told you about my new book, “Start Here! Learn Microsoft Visual C# 2010 Programming” in my post entitled, “New Book Announcement: Start Here! Learn Microsoft Visual C# 2010 Programming.” That post provides some basic information about the book, including a list of the chapters and what you should expect as content. Today this book is finally in print, so you can see it for yourself. Interestingly enough, I’ve already received a few queries about this book. I’ll answer the most commonly asked question in this post, which is what prompted me to write it.

Every time I receive an e-mail, see a review of one of my books online, or obtain information about a book in some other way, I try to see if I can use the feedback to improve later editions or to write a better book. In fact, I maintain statistics about each of my books because I really value your input and want to make the best use of it. The statistics I obtain from all of these forms of input help me understand how you use books better.

One of the comments I receive fairly often is that most books feel like college courses. They’re highly structured and seem most interested in teaching how to write applications using a stilted, old fashioned approach that doesn’t fit the reader’s needs very well. At least one reader has associated this approach with learning how to play piano using textbooks—you spend hours performing boring exercises to learn how to play something relatively simple. In the reader’s words, “Such an approach sucks every bit of joy out of the process of learning to play piano.” Yes, many people do learn to play piano using textbooks, but others learn to “play by ear” (simply by doing it without learning any basics first). These readers wonder why computer books can’t be written in a way that let’s you learn how to program using the “play by ear” approach.

I agree that not everyone learns in the same way. All other things being equal, one person may require a completely different book from someone else in order to get anything out of it because the two people learn differently. So, even if I wrote the most error free and comprehensive book ever written about C# application development, some people would love it and others would hate it simply because of the approach I took. Trying to solve this problem of writing a book that uses the “play by ear” approach has proven difficult.

To solve this problem, I needed to come up with a technique that would allow the reader to write code and then “hear” what the code does by running it. However, simply seeing the output isn’t sufficient in this case. In order to understand the code, the reader has to trace through itessentially “hearing” the individual tasks performed by each line of code. I tried a tracing technique for the first time in LINQ for Dummies and received quite a few positive responses about it. Now, LINQ for Dummies does use the college approach for the most part, but some sections use this new “play by ear” approach and it seems to work well for readers who require that approach.

It was with great excitement then, that I took on a book that would approach C# development from a completely different perspective after Russell Jones asked me about it. Start Here! Learn Microsoft Visual C# 2010 Programming is the result of my efforts. This book uses the tracing technique I started to develop in LINQ for Dummies extensively. Instead of spending hours learning about basic programming constructs and then writing tiny programs to put the theory into practice, you begin writing code immediately.

The main plus I see in using this approach is that nearly anyone should be able to learn to write useful (but basic) applications in a fraction of the time normally required and without devoting nearly as much time to the activity. The learning process should also be significantly less boring because you’re always doing something that has real world results. Of course, I’m extremely interested in seeing how this approach works for you, the reader. The only way I’ll get that information is if you write me at John@JohnMuellerBooks.com and tell me what you think of the book.