Getting the Fastest Question Response

I always want to be sure that you get fast, courteous responses to your book-specific questions. Even though I don’t check my e-mail every day, I do check it most days of the week, so that’s the fastest way to contact me regarding issues that you have with my books. Of course, you can make the response even faster by doing a few simple things when sending your email:

  • Be sure to include the name of the book and the book edition in the message subject line.
  • Tell me which page, figure, or listing number to look at in the book.
  • Document the steps you took.
  • Provide me with the exact error message you’re seeing.
  • Tell me about your platform (operating system, the version of any software you’re using, and so on).

If you provide these basic pieces of information, I can usually answer your questions much faster—often without asking for additional information. E-mail communication can be difficult at times because it lacks that in person body language element and you can’t show me what you’re seeing on your machine. Remote diagnostics are harder than you might think.

It’s also important that you understand that I focus on book-specific questions. I’ve discussed this issue before in Sending Comments on My Books and Sending Comments and Asking Questions. The bottom line is that I want you to be happy with your book experience, but I also don’t have time to provide free consulting. Please let me know if you have any questions or concerns about contacting me at John@JohnMuellerBooks.com.

 

Sending Comments and Asking Questions

Anyone who reads my blog for very long understands that supporting my books is a big deal for me. I actively work with my readers because I realize that you have the choice of using books written by other authors. Let’s just say that my support system is one of the reasons you really do want to buy my books. My blog not only answers common questions you have, but also adds examples and other information to the information you already receive through my books, so make sure you keep you eyes peeled for additional information here as well.

The last time I discussed this topic was in 2011 in my Contact Me, Please! post. The same things apply now as they did then. I’ll answer your book-specific questions as soon as I possibly can and in as much detail as I can. However, I won’t write your school term paper for you, accept a marriage proposal, or provide free consulting (amongst other things readers have asked me to do in the past). If you’re having problems with an example or can’t find the book’s source code, please be sure to ask because I want your experience with my books to be nothing less than phenomenal.

I also encourage you to be a beta reader. You can see the posts I’ve made for several recent books. The biggest reason for me to ask readers to participate in the book building process is to ensure you get the book you want. I also want to avoid Errors in Writing. As far as I know, I’m the only technical author on the planet that invites reader comment during the writing process, but I truly feel your input is essential, so I request it in every way I can. As I get new book contracts, you’ll continue to see requests for beta readers posted on my blog.

You can always contact me at John@JohnMuellerBooks.com with any comments and questions you have. This includes both books and blog posts. Let me know about any concerns you might have and I’ll do my best to solve them. In the meantime, happy reading !

 

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.

 

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.

 

Sending Comments on My Books

I regularly receive a stack of e-mail about my books. Readers question everything and it makes me happy to see that they’re reviewing my books so closely. It means that I’m accomplishing my principle goal, helping you understand computers in every possible way so that you can be more productive and accomplish tasks with less effort. When I make something easier for someone and they tell me about it, the grin extends from one side of my face to another. It really makes my day.

Some readers are still asking me if it’s OK to send me comments. I definitely want to see any constructive comment that you have. Anything that helps me understand your needs better or corrects errors in my writing makes it possible for me to write better books. As I mentioned in my Contact Me, Please!, I really do want to hear from you. The main element that I need to obtain a usable comment is that it’s constructive. A comment that says, “This book really stinks!” doesn’t tell me anything. Here are some of the things you can do to create a constructive comment:

 

  • What book are you reading?
  • Which page contains the error?
  • What do you view as an error on that page?
  • How would you fix the error?
  • What sort of system are you running?
  • Are you using the correct version of the software (the same version that appears in the book)?
  • When did you encounter the problem?


The more information you provide, the easier it is for me to understand the issue and provide you with feedback. In many cases, I’ll upload the fix to my blog so that everyone can benefit from the response (so be sure you keep an eye on my blog for new entries). I work hard to ensure that my books are as error free as possible, but everyone makes mistakes. Also remember that sometimes mitigating factors, such as differences in software versions or anticipated hardware, make it appear that there is an error in the book when you’re really looking at a different in environment. Help me provide you with better books—send me comments!

There are a few things that I won’t do for you. I won’t help you pass an exam at school. Your learning experience is important to me, which means that I want you to continue your education by working through the instruction on your own. I also don’t provide free consulting. This means I won’t check the code that you created on your own for errors. I’ll help you with any book-specific question, but I draw the line at that point. Let me know if you have any input or insights on my books 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.

 

Contact Me, Please!

I ran across an online review of one of my books the other day. The author was mainly complimentary, but said he couldn’t contact me using e-mail and found that he felt alone in using my book. He obviously had unsolved questions and felt that he had been left alone to solve them by himself. Of all of the complaints I receive about my books, not being able to contact me for help is the one that hurts worst.

I want you to be able to contact me. In fact, I check several times a day, five days a week (Monday through Friday) for reader e-mail and try my best to provide same day support. The only exception is when I’m out of the office on vacation (I’m striving to provide an automated message to let you know when I expect to return to answer your question). Even then, the first day back from vacation is spent answering reader e-mail. Your comments, questions, and general observations are incredibly important to me. Just in case you haven’t seen it in the book, my e-mail address is:

John@JohnMuellerBooks.com

If you purchase one of my books, you’ll see my e-mail address in at least two places: About the Author and the last chapter of the book as a bare minimum. I try to make it a point to mention my e-mail address five or six times in the book. In at least some cases, you’ll also find my e-mail address on the back cover.

Despite my best efforts, you may find it hard to reach me. If you can’t reach me for whatever reason, contact the publisher. Every publisher I work with has a Web site with a contact page. Normally, the publisher supports a forum in addition to an e-mail address (plus other contact methods that vary by publisher). If you contact the publisher, you can be sure that the publisher will contact me. The publisher knows it’s in its best interest to send any reader queries my way as quickly as possible.

At this point in time, I want to wipe out the “I couldn’t contact the author” complaint from the face of the earth. If you have anything to say about one of my books, don’t be afraid to contact me and say whatever is on your mind. You may be surprised to find that I care deeply about your needs and want to be sure you get the best possible use from my books.

That said, there are some people who try to take advantage of me. I won’t provide free consulting and no, I really am not a marriage prospect (I’ve been happily married for 31 years now). I truly don’t have time to debug your personal project, no matter how much it might interest me (and believe me, you readers have come up with some truly amazing projects over the years). However, if you have any question about my book, the source code, additional materials, or anything of that sort, please contact me, rather than assume I won’t treat you right.

Now, here’s an opportunity to tell me how to improve my books. If there is some other place that you’d like to see my e-mail address, tell me about it. I truly want to hear from you. Let me know where it would help to see my e-mail address so that you can contact me about my books whenever you want. I’ll be waiting to hear from you at John@JohnMuellerBooks.com.

 

Using CodeBlocks 10.05 – Part 6

This post is a continuation of the series that began with Using CodeBlocks 10.05 – Part 1. The purpose is to help people use CodeBlocks 10.05 with C++ All-In-One Desk Reference For Dummies, which is currently written to rely on CodeBlocks 8.02 (which is actually the previous edition, despite the odd numbering disparity). You can find a complete list of these posts in the C++ All-in-One for Dummies category archive. This post starts with a review of the updates for the source code found in Book IV Chapter 5.

There is a section entitled, “Templatizing a Function” that begins on page 528. You can see the code for this example in \Author\BookIV\Chapter05\FunctionOverloadingAndTemplates. The initial example is designed to fail, as explained on page 531. You’ll see the same error message and recommendations for both versions of CodeBlocks. In order to see this example work, you must comment out the line that reads:

cout << AbsoluteValue(10.5) << endl;

by highlighting the line of code and pressing Ctrl+Shift+C or by choosing Edit > Comment. Of course, you can simply add the comment manually by typing // at the beginning of the line. You must also comment these two functions out:

int AbsoluteValue(int x)
{
    if (x >= 0)
        return x;
    else
        return -x;
}
 
float AbsoluteValue(float x)
{
    if (x >= 0)
        return x;
    else
        return -x;
}

After you comment these lines out, you can uncomment the templated version of the function:

template <typename T> T AbsoluteValue(T x)
{
    if (x >= 0)
        return x;
    else
        return -x;
}

by highlighting the required lines of code and pressing Ctrl+Shift+X or choosing Edit > Uncomment. In addition, you must uncomment these lines of code to exercise the template:

cout << AbsoluteValue<int>(10) << endl;
cout << AbsoluteValue<float>(10.5) << endl;

At this point, the example will compile and run as expected. You’ll receive the same results in both CodeBlocks 8.02 and 10.05. Because so many people have complained about this particular example, I plan to provide two completely different source code files for the next edition of the book (so it won’t be necessary to comment/uncomment anything). Even so, the lines you must uncomment are clearly marked in the current source code file. The example found in the \Author\BookIV\Chapter05\ImFree folder requires similar commenting and uncommenting to see the full potential of the example, but this example doesn’t produce an error at the outset. The other examples in this chapter should work precisely as expected.

On to Book IV Chapter 6 (the last chapter in this mini-book). On page 555 you see Listing 6-8, which contains the code for \Author\BookIV\Chapter06\Sets2. This example won’t currently compile properly and you’ll find the explanation on page 557. In order to run, you must add another library, algorithm, to the group so that the list of includes looks like this:

#include <iostream>
#include <set>
#include <algorithm>

All of the other examples in this chapter run in CodeBlocks 10.05 without a problem on my system (let me know if you experience any problems on your system). In the next post I’ll start
with Book V Chapter 1. In the meantime, let me know if you have any
questions about the CodeBlocks 10.05 updates for this book at John@JohnMuellerBooks.com.