97 Things Every Programmer Should Know

The 97 series now consists of the following titles:

• 97 Things Every Software Architect Should Know
• 97 Things Every Programmer Should Know
• 97 Things Every Project Manager Should Know

The architect book was very good. The programming topics were also good but I found more value within the architecture discussions. I definitely want to get my hands on the project management book soon. I have a feeling that one will be a bit more humorous.

My Favorite Things Programmers Should Know:

• The Professional Programmer by Uncle Bob
  • Favorite Quote:
    "Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right".
    
    
  • Key Message:
    This post was unquestionably at the top of the my list. The entire message is about personal responsibility. This one's a wall hanger. Print it out, frame it, and hang it up! This post reminded me of the talk I heard Dave Thomas give many years ago at No Fluff Just Stuff.
  
  
  
  
• Don't Rely on "Magic Happens Here" by Alan Griffiths
  • Favorite Quote:
    "You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't."
    
    
  • Key Message:
    Can you fulfill the roles of every individual on your last project? Image how valuable you'd be if you could. Again, the more knowledge you have, the more efficient you and your project will be.



• Hard Work Does not Pay off by Olve Maudal
  • Favorite Quote:
    "programming and software development as a whole involve a continuous learning process."
    
    
  • Key Message:
    Continuous learning is the key point within this post. Combined with the right tools and knowledge you will see greater efficiency gains on your projects. The real challenge is allocating time to focus on your continuous learning efforts.



• First Write, Second Copy, third Refactor by Mario Fusco
  
  • Favorite Quote:
    "So the first time you are implementing something new, write it in the most readable, plain, and effective way. It is definitely too early to put the general part of your algorithm in an abstract class and move its specialization to the concrete one or to employ any other generalization pattern".
    
    "The second time you face a problem that resembles the one you solved before, the temptation to refactor that first implementation in order to accommodate both these needs is even stronger. But it may still be too early. It may be a better idea to resist that temptation and do the quickest, safest, and easiest thing it comes you in mind: Copy your first implementation".
    
    "When you need that solution for the third time, even if to satisfy a slightly different requirement, the time is right to put your brain to work and look for a general solution that elegantly solves all your three problems. Now you are using that algorithm in three different places and for three different purposes, so you can easily isolate its core and make it usable for all three cases".
    
    
  • Key Message:
    The Rule of Three also applies for reuseability. For example, in order for a solution to be classified as a design pattern the rule of three must apply. If you can successfully apply the same pattern across three separate systems you have a design pattern. Furthermore, this rule also applies to API design. If your API can successfully be consumed by three separate clients, you have a very concrete and proven design. Applying the Rule of Three for shared services or libraries is also valuable.
  
  

YUI to the rescue

Are you still rolling your own HTML user interface components? If you are, take a look at what YUI has to offer. The advantages of leveraging YUI's standard components are abundant.

YUI Advantages:

• Saves cost on development effort. The suite of controls are already developed and tested. This allows your team to work on more valuable tasks.
• Excellent performance. YUI has adopted many of the great performance improvement practices that were identified in Best Practices for Speeding Up Your Web Site. Several of the performance improvements include:
  • Minified JavaScript and CSS files. This will improve page load performance with smaller files to download.
  • Aggregated or rolled-up JavaScript and CSS files. This will improve page load performance with fewer HTTP requests.
  • Yahoo will host the files on their own Content Delivery Network. In addition, Yahoo will compress and cache all of their controls for even greater performance. They also manage versioning.
• Components are supported across all A-Grade browsers
• Helps non-UI experts design beautiful user interfaces. Yahoo provides the design and CSS layout for all of their components.
• 508 compliant. All components are screen reader accessible.
• All components already have extensive documentation with many examples.
• Reusable. You can apply the YUI controls everywhere because they are not proprietary.
• Technology agnostic. These controls can be applied across all Web environments regardless of technology (Java, .NET, Rails, etc.).
• Support many features that allow you to change behavior without customizing the code.
• Thier code is clean. I validated their JavaScript with JSLint and few errors were reported. I also validated their CSS files and no major issues existed either.

YUI Disadvantages:

• Some controls are not bullet proof. For example, there is a sorting issue with their datatable control if you embed the component within a table. However, this is not an issue if you are working in a CSS based design.
• They do not have everything but the list is extensive.

Recommendations:

• Try to avoid customizations. Customizing the code will make it difficult to migrate to newer versions in the future.

Preventing Buffer Overflow Attacks

Is your website resilient enough to withstand a buffer overflow attack? A buffer overflow attack is actually one of the simpler attacks a malicious user may attempt. Imagine the following scenario. You have a public facing web page that allows unauthorized users to submit data. A malicious user probes your site to see if you have exposed this vulnerability. If your site is at risk, it may only take minutes for the user to bring your site down if they employ a botnet attack.

The Attack

• The simplest attack method is for malicious users to throw overloading (2GB - 8GB) amounts of data in a text field in hopes of crashing the server due to out of memory errors.

The Prevention

• Bounds checking on the server-side is the most effective solution for preventing buffer overflows. For example, if you are using Spring's annotation-based validation this is all you would need:
  

  
  /**
   *
   * Spring's annotation reference documentation
   * Configuration setup example
   */
  public class Student {
   
   @NotBlank
   @Length(max = 50) 
   private String firstName;
   
   @Length(min = 1, max = 50) 
   private String lastName;
   
  }
  

  
  
  HTML's maxlength attribute is NOT sufficient:

  <input type="text" name="firstName" maxlength="50" />

  This is not secure because there are tools that will enable users to bypass this HTML tier of validation. You must perform max length validation on the server-side as in the example above.
• Leverage the bulkhead stability pattern to decouple your authenticated business critical applications from your publicly exposed (more vulnerable) applications. The goal of this pattern is to preserve the stability for a particular group of customers. Most software attacks are targeted at publicly available web sites. You should leverage this pattern if you want to help preserve the stability of your authenticated users during an attack on your publicly available sites.
• Prefer to keep public data out of session. This simple solution will help preserve memory if a user attempts a buffer overflow attack.

JavaScript Singletons

JavaScript singletons are relatively simple to create. With two additional characters you can define your object as a singleton. I'll show how this is accomplished in a moment. In my prior JavaScript post I talked about why the module pattern was preferred for creating objects. Those objects were prototype-based and multiple instances were allowed. The following examples illustrate the preferred way to create singletons with the Module pattern. This should be your preferred creational pattern for creating JavaScript singletons.

Singleton Pattern Example #1:

/*
 * Singleton counter example.
 */
var mySingletonCounter = function() {
 
   /* private, static variables */
   var count = 0;

   return {
      /* public methods */
      increment: function (inc) {
           alert('Adding ' + inc + ' to count.');
           count += inc;
      },
 
      getCount: function() {
           alert('The current count is ' + count);
           return count;
      }
   };
}(); // <- These two parentheses define the object as a singleton.  It assigns the result of invoking this function to mySingletonCounter.

To exercise the singleton, the button below will execute the following code:

mySingletonCounter.increment(2); mySingletonCounter.getCount();

Run Singleton Counter

Singleton Pattern Example #2:

/*
 * Singleton data access example.
 */
var mySingletonData = function() {
 
   /* private, static variables */
   var data = {
       1: "Harry Potter and the Philosopher's Stone",
       2: "Harry Potter and the Chamber of Secrets",
       3: "Harry Potter and the Prisoner of Azkaban"
   };

   return {
      /* public methods */
      getData: function() {
           return data;
      }
   };
}();

Reference the singleton object in the following manner:

mySingletonData.getData()[2];

Run Singleton Data

Advantages:

• It is extremely simple to declare a JavaScript object as a singleton. More dynamic languages are focusing on simplicity. For example, Groovy has recently provided the @Singleton transformation to simplify Singleton creation.
• Improved run-time performance vs the prototype-based creational pattern.
• You still leverage all the advantages that the module pattern provides.