Antivirus and Application Compilation

Sometimes applications don’t get along, especially when one application is designed to create new content at a low level and the other is designed to prevent low level access to a system. Such is the case with compilers and antivirus applications in some cases. I haven’t been able to reproduce this behavior myself, but enough readers have told me about it that I feel I really do need to address it in a post. There are situations where you’re working with source code from one of my books, compile it, and then have your antivirus application complain that the code is infected with something (even though you know it isn’t). Sometimes the antivirus program will go so far as to simply delete the application you just compiled (or place it in a virus vault).

The solution to the problem can take a number of forms. If your antivirus application provides some means of creating exceptions for specific applications, the easiest way to overcome the problem is to create such an exception. You’ll need to read the documentation for your antivirus application to determine whether such a feature exists.

In some cases, the compiler or its associated Integrated Development Environment (IDE) simply don’t follow all the rules required to work safely in protected directories, such as the C:\Program Files directory on a Windows system. This particular issue has caused readers enough woe that my newer books suggest installing the compiler and its IDE in a directory the reader owns. For example, I now ask readers to install Code::Blocks in the C:\CodeBlocks directory on Windows systems because installing it elsewhere has caused some people problems.

Unfortunately, creating exceptions and installing the application in a friendly directory only go so far in fixing the problem. A few antivirus applications are so intent on protecting you from yourself that nothing you do will prevent the behavior. When this happens, you still have a few options. The easiest solution is to turn the antivirus program off just long enough to compile and test the application. Of course, this is also the most dangerous solution because it could leave your system open to attack.

A safer, albeit less palatable solution, is to try a different IDE and compiler. Antivirus programs seem a little picky about which applications they view as a threat. Code::Blocks may cause the antivirus program to react, but Eclipse or Visual Studio might not. Unfortunately, using this solution means that steps in the book may not work precisely as written.

For some developers, the only logical solution is to get a different antivirus application. I’ve personally had really good success with AVG Antivirus. However, you might find that this product doesn’t work for you for whatever reason. Perhaps it interacts badly with some other application on your system or simply doesn’t offer all the features you want.

My goal is to ensure you can use the examples in my books without jumping through a lot of hoops. When you encounter problems that are beyond my control, such as an ornery antivirus application, I’ll still try to offer some suggestions. In this case, the solution truly is out of my control but you can try the techniques offered in this post. Let me know if you find other solutions to the problem at John@JohnMuellerBooks.com.

 

Thinking of All the Possibilities in Software Design

A number of books on my shelf, some of which I’ve written, broach the topic of divergent thinking. Unfortunately, many developers (and many more managers) don’t really grasp the ideas behind divergent thinking. Simply put, divergent thinking starts with a single premise and views as many permutations of that premise as possible. Most developers don’t take the time to use divergent thinking as part of the development process because they don’t see a use for it. In fact, most books fall short of even discussing the potential for divergent thinking, much less naming it as a specific element of application design. I’ve explored the topic before and a reader recently reminded me of an article I wrote on the topic entitled, Divergent Versus Convergent Thinking: Which Is Better for Software Design?.

The process that most developers rely upon is convergent thinking, which is where you convert general goals and needs into specific solutions that appear within a single application. The difference between the two modes of thinking is that divergent thinking begins with a single specific premise, while convergent thinking begins with a number of general premises. More specifically, divergent thinking is the process you use to consider all of the possibilities before you use convergent thinking to create specific solutions to those possibilities.

There is an actual cycle between divergent and convergent thinking. You use divergent thinking when you start a project to ensure you discover as many possibly ways to address user requirements as possible. Once you have a number of possibilities, you use convergent thinking to consider the solutions for those possibilities in the form of a design. The process will point out those possibilities that will work and those that don’t. Maintaining a middle ground between extremes of divergent and convergent thinking will help create unique solutions, yet keep the project on track and maintain project team integrity. Managing the cycle is the job of the person in charge of the project, who is often the CIO, but could be some other management position. So, the manager has to be knowledgeable about software design in order for the process to work as anticipated.

One of the reasons that many applications fail today is the lack of divergent thinking as part of the software design process. We’re all too busy thinking about solutions, rather than possibilities. Yet, the creative mind and the creative process is based on divergent thinking. The reason we’re getting the same solutions rehashed in a million different ways (resulting in a lack of interest in new solutions) is the lack of divergent thinking in the development process.

In fact, I’d go so far as to say that most developers have never even heard of divergent thinking (and never heard convergent thinking called by that name). With this in mind, I’ve decided to provide some resources you can use to learn more about divergent thinking and possibly add it to your application design process.

 

These are just four of several hundred articles I located on divergent thinking online. I chose these particular four articles because they represent a range of ideas that most developers will find helpful, especially the idea of not applying stereotypical processes when trying to use divergent thinking. Stereotypes tend to block creative flow, which is partly what divergent thinking is all about.

The bottom line is that until divergent thinking is made part of the software design process, we’ll continue to suffer through rehashed versions of the current solutions. What is your view of divergent thinking? Do you see it as a useful tool or something best avoided? Let me know your thoughts at John@JohnMuellerBooks.com.

 

Finding the Source Code for Microsoft ADO.NET Entity Framework Step by Step

Sometimes a bit of information isn’t known by an author at the time of writing, so the book will contain placeholder text to remind everyone to add the information later. Normally, the process works great and the replacement is made without problem. I was recently informed of a problem in Microsoft ADO.NET Entity Framework Step by Step. It turns out that there is placeholder text in some places that reads, “Provide URL Here.” I added the placeholder because I didn’t know where the publisher would store the book’s source code at the time of writing. Of course, the placeholder is hardly helpful to anyone who really would like to find the book’s source.

If you encounter such a placeholder in this book, please go to the O’Reilly download site at http://aka.ms/ADONETEFSbS/files or http://examples.oreilly.com/9780735664166-files/ to obtain the files. I really do consider it important that you download the book’s source code and use it as you work through the text. This particular book has a lot of complex examples that will be tough to get right if you type them in by hand. A single typo can make the examples completely unusable, or at least cause damage to your sample database.

In addition to reading about potential problems and obtaining useful bits of additional information by reading my blog, make sure you also check the book’s errata page at http://www.oreilly.com/catalog/errata.csp?isbn=0790145339164 (see my Errors in Writing post as well). This page provides you with succinct summaries of potential problems and the fixes I suggest for them. Always feel free to write me about my books as well at John@JohnMuellerBooks.com. It’s important to me that you always have a great experience when using my books.

 

In Praise of Dual Monitors

A lot of people have claimed that the desktop system is dead—that people are only interested in using tablets and smartphones for computing. In fact, there is concern that the desktop might become a thing of the past. It’s true that my own efforts, such as HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, have started to focus on mobile development. However, I plan to continue using my desktop system when working because it’s a lot more practical and saves me considerable time. One such time saver is the use of dual monitors.

Yes, I know that some developers use more than just two monitors, but I find that two monitors work just fine. The first monitor is my work monitor—the monitor I use for actually typing code. The second monitor is my view monitor. When I run the application, the output appears on the second monitor so that I can see the result of changes I’ve made. Using two monitors lets me easily correlate the change in code to the changes in application design. Otherwise, I’d be wasting time switching between the application output and my IDE.

I also use two monitors when writing my books. The work monitor contains my word processor, while my view monitor contains the application I’m writing about. This is possibly one time when a third monitor could be helpful—one to hold the word processor, one to hold the IDE, and one to view the application output. However, in this case, a third monitor could actually slow things down because the time spent viewing the output of an example is small when compared to creating a production application.

The concept of separating work from the source of information used to perform the work isn’t new. People have used the idea for thousands of years, in fact. For example, when people employed typewriters to output printed text, the typist employed a special stand to hold the manuscript being typed. The idea of having a view of your work and then another surface to actually work on is used quite often throughout history because it’s a convenient way to perform tasks quickly. By employing dual monitors, I commonly get between a 15 percent to 33 percent increase in output, simply because I can see my work and its associated view at the same time.

Working with dual monitors not only saves time, but can also reduce errors. By typing as I view the output of applications, I can more reliably relate the text of labels and other information the application provides. The same holds true when viewing information sources found in other locations. Seeing the information as I type it is always less likely to produce errors.

Don’t get the idea that I support using dual monitors in every situation. Many consumer-oriented computer uses are served just fine with a single monitor. For example, there isn’t a good reason to use two monitors when viewing e-mail in many cases—at least, not at the consumer level (you could make a case for using dual monitors when working with e-mails and a calendar to manage tasks, for example). Dual monitors commonly see use in the business environment because people aren’t necessarily creating their own information source—the information comes from a variety of sources that the user must view in order to use reliably.

Do you see yourself using dual monitors? If you use such a setup now, how do you employ it? Let me know at John@JohnMuellerBooks.com.

 

Choosing Variable Names

It often surprises me that developers seem to choose completely useless variable names like MyVariable when creating an application. Although MyVariable could be an interesting variable name for an example in a book, it never has a place in any sort of production code. Even then, I try to create book examples with meaningful variable names, especially when getting past the initial “Hello World” example. Variable names are important because they tell others:

 

  • What sort of information the variable stores
  • When the variable is commonly used
  • Where the variable is used
  • How to use the variable correctly
  • Why the variable is important


In some cases, the variable name could even indicate who created the variable; although, this sort of information is extremely rare. If you never thought a variable name should contain all that information, then perhaps you haven’t been choosing the best variable names for your application.

Even with these restrictions in place, choosing a variable name can be uncommonly hard if you want to maximize the name’s value to both yourself and other developers. Some organizations make the selection process easier by following certain conventions. For example, a form of Hungarian Notation, where certain type prefixes, suffixes, and other naming conventions are used, is a common way to reduce the complexity of creating a variable name. In fact, Hungarian Notation (or some form of it) is often used to name objects, methods, functions, classes, and other programming elements as well. For example, NamArCustomers could be an array of customer names (Nam for names, Ar for array). The use of these two prefixes would make it instantly apparent when the variable is being used incorrectly, such as assigning a list of numbers to the array. The point is that an organizational variable naming policy can reduce complexity, make the names easy to read for anyone, and reduces the time the developer spends choosing a name.

 

Before I get a ton of e-mail on the topic, yes, I know that many people view Hungarian notation as the worst possible way to name variables. They point out that it only really works with statically typed languages and that it doesn’t work at all for languages such as JavaScript. All that I’m really pointing out is that some sort of naming convention is helpful—whether you use something specific like Hungarian Notation is up to you.


Any variable name you create should convey the meaning of that variable to anyone. If you aren’t using some sort of pattern or policy to name the variables, then create a convention that helps you create the names in a consistent manner and document it. When you create a variable name, you need to consider these kinds of questions:

 

  1. What information does the variable contain (such as a list of names)?
  2. How is the variable used (such as locally or globally, or to contain coordinates, or a special kind of object)?
  3. When appropriate, what kind of information does the variable contain (such as a string or the coordinate of a pixel on screen)?
  4. Is the variable used for a special task (such as data conversion)?
  5. What case should prefixes, suffixes, and other naming elements appear in when a language is case sensitive?

The point is that you need to choose variable names with care so that you know what they mean later. Carefully chosen variable names make it possible for you to read your code with greater ease and locate bugs a lot faster. They also make it easier for others to understand your code and for you to remember what the code does months after you’ve written it. However, most important of all, useful variable names help you see immediately that a variable is being using the wrong way, such as assigning the length of a name string to a coordinate position on screen (even though both variables are integer values). Let me know your thoughts about variable naming at John@JohnMuellerBooks.com.

 

Verifying Your Hand Typed Code

I maintain statistics for each of my books that are based on reviews and reader e-mails (so those e-mails you send really are important). These statistics help me write better books in the future and also help me determine the sorts of topics I need to address in my blog. It turns out that one of the most commonly asked questions is why a reader’s hand typed code doesn’t work. Some readers simply ask the question without giving me any details at all, which makes the question impossible to answer. In some cases, the reader sends the hand typed code, expecting that I’ll take time to troubleshoot it. However, this isn’t a realistic request because it defeats the very purpose behind typing the code by hand. If I take the time to diagnose the problems in the code you typed, I’ll be the one to learn an interesting lesson, not you. If you learn better by doing—that is, by typing the code by hand and then running it, then you need to be the one to troubleshoot any problems with the resulting code.

My advice to readers is to use the downloadable source code when working through the book text. If you want to type the code by hand after that as part of your learning experience, at least you’ll know that the example works on your system and you’ll also understand how the example works well enough to troubleshoot any errors in your own code. However, you need to be the one to diagnose the errors. If nothing else, perform a character-by-character comparison of your code to the example code that you downloaded from the publisher’s site. Often, a reader will write back after I suggest this approach and mention that they had no idea that a particular special symbol or method of formatting content was important. These are the sorts of lessons that this kind of exercise provide.

Now, it has happened that the downloadable source code doesn’t always work on a particular user’s system. When the error is in the code or something I can determine about the coding environment, you can be certain that I’ll post information about it on my blog. This should be the first place you look for such information. Simply click on the book title in question under the Technical category. You’ll find a list of posts for that book. Always feel free to contact me about a book-specific question. I want to be sure you have a good learning experience.

There are some situations where a reader tries to run application code that won’t work on a particular system. My books provide information on the kind of system you should use, but I can’t always determine exceptions to the rule in advance. When I post system requirements, your system must meet those requirements because the examples are guaranteed to fail on lesser systems. If you encounter a situation where the downloadable code won’t run on your system, but none of the fixes I post for that code work and your system does meet the requirements, then please feel free to contact me. There are times where an example simply won’t run because you can’t use the required software or the system won’t support it for whatever reason.

The point of this post is that you need to work with the downloadable source code whenever possible. The downloadable source code has been tested by a number of people, usually on a range of systems, to ensure it will work on your system too. I understand that typing the code by hand is an important and viable way to learn, but you should reserve this method as the second learning tier—used after you have tried the downloadable source code. Please let me know if you have any questions or concerns at John@JohnMuellerBooks.com.

 

Book Reviews – Doing Your Part

Readers contact me quite a lot about my books. On an average day, I receive around 65 reader e-mails about a wide range of book-related topics. Many of them are complimentary about my books and it’s hard to put down in words just how much I appreciate the positive feedback. Often, I’m humbled to think that people would take time to write.

There is another part to reader participation in books, however, and it doesn’t have anything to do with me—it has to do with other readers. When you read one of my books and find the information useful, it’s helpful to write a review about it so that others can know what to expect. I want to be sure that every reader who purchases one of my books is happy with that purchase and gets the most possible out of the book. The wording that the publisher’s marketing staff and I use to describe a book represents our viewpoint of that book and not necessarily the viewpoint of the reader. The only way that other readers will know how a book presents information from the reader perspective is for other readers to write reviews.

A good review will tell what you liked about the book—how it met your needs, what it provides in the way of usable content, and whether you liked intangibles, such as the author’s writing style. The review should also present any negatives. For example, the book may not have provided detailed enough procedures for you to actually accomplish a task. (Obviously, I want to know about the flaws, too, so that I can correct them in the next edition of the book and also discuss them on my blog.) Many reviewing venues, such as the one found on Amazon, also ask you to provide a rating for the book. You should rate the book based on your experience with other books and on how this particular book met your needs in learning a new topic. The kind of review to avoid writing is a rant or one that isn’t actually based on reading the whole book. As always, I’m here (at John@JohnMuellerBooks.com) to answer any questions you have and many of your questions have appeared as blog posts when the situation warrants.

So, just where do you make these reviews? The publishers sometimes provide a venue for expressing your opinion and you can certainly go to the publisher site to create such a review. I personally prefer to upload my reviews to Amazon because it’s a location that many people frequent to find out more about books. With that in mind, here are the URLs for many of my books. You can go to the site, click Write a Customer Review (near the bottom of the page), and then provide your viewpoint about the book.

 

Thank you in advance for taking the time and effort required to write a review. I know it’s time consuming, but it’s an important task that only you can perform.

 

Database Creation Differences Amongst Language Versions

The issues that come with working with non-English language versions of Visual Studio are becoming more apparent as readers write to me about them. Here is the essential problem that you need to consider when reading this post. I strongly endorse use of the downloadable source when working with one of my books. Using the downloadable source means that you don’t have to worry about problems with internationalization or with typos for that matter. All you need to do is load the example into your copy of Visual Studio and follow along as you read the book.

However, many people learn by doing and that’s when problems come into play. If you recreate the examples from scratch, you could encounter problems that have nothing to do with your programming skills or your ability to follow directions. In this case, the problem isn’t the fault of the reader, but of Visual Studio. Databases are created differently by the Entity Framework designer when working with various language versions.

A German reader was kind enough to send me some screenshots of a particular issue that I don’t discuss in the book because I was unaware of it when I wrote it (and a lack of international beta readers kept me from learning about it until now). If you look at the Entity SQL example that begins in the “Creating a basic query using Entity SQL” section of Chapter 4 (page 86), you see that the code interacts with the Customers table. You create this table earlier in the book and it should appear as Customers in SQL Server Management Studio. However, it doesn’t appear under that name if you’re working with the German version of Visual Studio. The IDE appends the word Satz (set) to the table name as shown here (all screenshots are courtesy of my German reader):

TableCreation01

Consequently, when you try to create the code shown on page 87, it doesn’t work. It would work if the table had the right name or if the code used the right name, but the two are out of sync. In order to make this example work, you must change the example code as shown here:

TableCreation02

Of course, making the code change (circled in red) does solve the problem, but it’s not something the developer should have to deal with. In addition, consider how things will work if you’re interacting with a number of team members in different countries—all of whom are using their own language versions of Visual Studio. The resulting chaos must be impressive indeed.

The true source of the problem is the Entity Framework Designer. When you initially create your design, the name of the entity might be Customers, but the Properties window will automatically add Satz to the name for you as shown here:

TableCreation03

To make the book examples work as they appear in the book, you need to ensure that the entity names match those in the book. In this case, all you need to do is remove the Satz part of the name.

Unfortunately, these sorts of problems will continue to crop up with various languages. I’d like to hear about them because knowing what could happen will help me write better books in the future and to provide updates to you here. I really appreciate all of the help my German reader provided in this case. Contact me with any other language-specific glitches you find at John@JohnMuellerBooks.com.

 

DateTimePicker Control Data Type Mismatch Problem

A reader recently made me aware of a problem with the Get User Favorites example in Chapter 2 that could cause a lot of problems depending on which language you use when working with Visual Studio 2012. This issue does affect some of the examples in Microsoft ADO.NET Entity Framework Step by Step so it’s really important you know about it.

Look at the model on page 30 of the book (the “Creating the model” section of Chapter 2). The Birthday field is defined as type DateTime. When you finish creating the model, you right click the resulting entity and choose Generate Database from Model to create a database from it. The “Working with the mapping details” section of Chapter 1 (page 19) tells you how to use the Generate Database Wizard to create the database. The Birthday field in the database will appear as a datetime type when you complete the wizard, which is precisely what you should get.

At this point, you begin creating the example form to test the database (the “Creating the test application” section on page 36). The example uses a DateTimePicker control for the Birthday field by default. You don’t add it, the IDE adds it for you because it sees that Birthday is a datetime data type. The example will compile just fine and you’ll be able to start it up as normal.

However, there is a problem that occurs when working with certain languages when you start the “Running the basic query” section that starts on page 39. The DateTimePicker control appears to send a datetime2 data type back to SQL Server when you change the birthday information. You’ll receive an exception that says the data types don’t match, which they don’t. There are several fixes for this problem. For example, you could coerce the output of the DateTimePicker control to output a datetime data type instead of a datetime2 data type. However, the easiest fix is to simply change the data type of the Birthday field in the database from datetime to datetime2. After you make this change, the example will work as it should. You only need to make this change when you see the data type mismatch exception. I haven’t been able to verify as of yet which languages are affected and would love to hear from my international readers about the issue.

As far as the book is concerned, this problem is quite fixable using the manual edit (although, manually editing the database shouldn’t be something you should have to do). However, it does bring up the question of how teams working across international boundaries will interact with each other if they can’t depend on the controls acting in a particular way every time they’re used. This is a problem that you need to be aware of when working with larger, international, teams. Let me know if you have any questions or concerns about the book example at John@JohnMuellerBooks.com. You’ll have to contact Microsoft about potential fixes to the DateTimePicker control since I have no control over it.

 

Extra File in Entity Framework Book Downloadable Source

At least one reader has noted that there is an extra file in the Databases.zip file which is part of the downloadable source for Microsoft ADO.NET Entity Framework Step by Step. The Rewards2 RowVersion.mdf file isn’t used by any of the examples in the book. This was a test file that I used for experimentation purposes and you can safely delete it or simply ignore it. You certainly don’t need to install it in SQL Server. I had actually forgotten about that file and uploaded it with the rest of the downloadable source. I’m sorry about any confusion that the extra file has caused. Please let me know if you have any questions about it at John@JohnMuellerBooks.com.