I have a confession to make.

You know that really popular design patterns book that most software developers (especially in the Java world) claim to have read? You know the one I’m talking about. The one written by the “Gang of Four”. The one you were supposed to have read during your junior or senior year of college. Yeah, this one.

I’ve never read it.

Sure, I’ve owned it. I have even thumbed through it a few times. But I’ve never sat down with any real intention of absorbing the information within its covers. The problem for me personally was that when I first opened Design Patterns I was just starting my software development career. I was too young and hadn’t seen enough code to really comprehend the authors’ message or understand the need for such a book.

A few years have passed since then and while it’s still early in my career I now have a much better idea of how to develop software and have a much better understanding of Object Oriented Design. Even though I spend a significant amount of my free time developing my skills and reading about software development I have yet to read the seminal Design Patterns book.

Design patterns have left a bad taste in my mouth. Over the years they have been abused and misunderstood. They seem to have become caught up in the all too familiar silver bullet buzzword vernacular of the IT industry (SOA anyone?). So I simply avoided them. Unless I was about to interview for a new job, design patterns never so much as crossed my mind. Repeat after me: Singleton, Factory, MVC. You’re hired!

But things have changed. Over the past year and a half or so I’ve really started to focus on my career as a software developer. I’ve learned new operating systems and languages, created this blog, and started attending local developer meetings on a regular basis. While I still have my favorite technologies and interests, I’ve been doing a much better job of keeping an open mind about trying out new development tools and methodologies.

Enter Russ Olsen. In addition to being a great developer and all around good guy, Russ is someone who I had the honor of working with at the beginning of my career. He was very much a mentor and I credit him with teaching me many of the applied fundamentals of software development. So what does Russ have to do with design patterns? Well it just so happens that a few years after I left the company where Russ and I worked together he wrote a book called Design Patterns in Ruby. Because of my respect for Russ and my fondness of Ruby I decided I’d give the book a shot. While I was certainly expecting to learn some new things, I was surprised (although I shouldn’t have been) by how much great information I was able to extract from this book.

In their most minimal form, design patterns are simply reusable solutions that have been created to solve common coding problems. While this may seem intuitive, it was actually somewhat of a revelation to me – a person who has ignored the direct usage of design patterns for all these years. I see now that given an appropriate situation design patterns can be used to create consistent, maintainable code. The important thing to remember is that each pattern has a specific use and should only be used when applicable.

Although the title of the book is Design Patterns in Ruby, a majority of the principles and patterns apply to many other object oriented languages as well. In fact, while I was reading Russ’s book I was in the middle of working on a small Java project. This project had to keep track of rapid state changes on a particular website. I needed to keep track of a countdown timer, a list of participants, and an aggregate score. Each of these pieces of information was updated independently, but I needed to make decisions in my code based on the combination of this information at any given time. After reading the chapter on the Observer pattern, I realized it would be the perfect fit. Prior to using the pattern my code was a huge pile of tangled spaghetti. Afterwards, it was clean and easy to read.

I really liked the way the chapters were organized in Design Patterns in Ruby. Russ started each chapter by posing a common programming problem. Then he would explain how a specific design pattern could be used to solve that problem. As the chapter progressed Russ would work through the problem using examples that were very easy to understand. Each chapter ended with real world examples of the patterns as they have been implemented in the Ruby core libraries or various open source projects. I found the real world code samples to be especially useful as compliments to the examples given in the book.

Not only did I enjoy reading this book because it was written by Russ, but I genuinely feel like it has helped to make me a better programmer. In addition, it has helped increase my Ruby specific programming skills. Learning to program in Ruby is easy, but learning to program the “Ruby Way” is a much greater challenge. Ruby is full of powerful idioms that are not necessarily obvious without a deep examination of the language. Russ’s book helps enlighten would be Ruby programmers to many of Ruby’s powerful language features.

For example, compare an implementation of the Proxy pattern written in Java and Ruby:

Java Version

MathService.java

public interface MathService {
    public void add(int x, int y);
    public void subtract(int x, int y);
}

MathServiceImpl.java

public class MathServiceImpl implements MathService {
    public void add(int x, int y) {
        System.out.println("Result ("+x+ " + "+y+"): " + (x + y));
    }

    public void subtract(int x, int y) {
        System.out.println("Result ("+x+ " - "+y+"): " + (x - y));
    }
}

MathServiceProxy.java

public class MathServiceProxy implements MathService {
    private MathService delegate;

    public MathServiceProxy(MathService ms){
        this.delegate = ms;
    }

    public void add(int x, int y) {
        System.out.println("Call made to the add method");
        delegate.add(x, y);
    }

    public void subtract(int x, int y) {
        System.out.println("Call made to the subtract method");
        delegate.subtract(x, y);
    }
}

MathServiceDriver.java

public class MathServiceDriver {
    public static void main(String[] args) {
        MathService ms = new MathServiceProxy(new MathServiceImpl());
        ms.add(1, 2);
        ms.subtract(4, 3);
    }
}

Ruby Version

math_service.rb

class MathService
  def add(x, y)
    puts "Result (#{x} + #{y}): #{x + y}"
  end

  def subtract(x, y)
    puts "Result (#{x} - #{y}): #{x - y}"
  end
end

class MathServiceProxy
  def initialize(math_service)
    @delegate = math_service
  end

  def method_missing(name, *args)
    puts "Call made to the #{name} method"
    @delegate.send(name, *args)
  end
end

ms = MathServiceProxy.new(MathService.new)
ms.add(1,2)
ms.subtract(4,3)

Result of Running Either Program

Call made to the add method
Result (1 + 2): 3
Call made to the subtract method
Result (4 - 3): 1

In this example we use the Proxy pattern to print out a message before each method call. If we decided to add any methods to our MathService interface we would need to update our MathServiceImpl and MathServiceProxy Java classes as well. However, by using Ruby’s built in method_missing method we have the ability to wrap each MathService method call dynamically without having to write a new method in our MathServiceProxy class. Ruby removes the tedium of implementing the Proxy pattern.

This is just one small example of the flexibility and power provided by the Ruby language. Before reading Russ’s book I didn’t necessarily “get” many of Ruby’s idioms. Reading Design Patterns in Ruby has certainly helped solidify my understanding and is great for programmers who would like to take their Ruby skills to the next level.

Code Samples

All code samples from this blog entry can be downloaded from GitHub by clicking here

In order to stay up to speed in an industry that changes by the day developers must constantly be learning and acquiring new skills. As technology fads come and go it is important for developers to isolate and keep pace with the technologies that are in high demand. Because technologies change so rapidly it is important that we are able to learn as quickly and efficiently as possible. While there is certainly no shortage of information available on the latest technologies, making sense of this information, figuring out what is important, and putting this information to use can be a very challenging task. Therefore it is important that developers learn how to learn.

I recently finished the book Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt, co-author of the seminal book The Pragmatic Programmer. In this book Hunt discusses how people (specifically software developers) learn and offers tips on how we can set out to learn more effectively. Here are some useful tips I stumbled upon while reading Pragmatic Thinking and Learning:

SQ3R

It is unfortunate that the most common way that many people attempt to teach themselves new skills is by reading. A lot of people tend to learn better through experimentation and observation, but in many cases these are not practical first steps to take when starting out with a given subject. On the other hand, reading is an important skill and reading material is abundant so it’s important that we are able to get the most out of the things we read.

The main reason reading is not a great way to learn is because it is often viewed as a passive activity. As Hunt describes in his book however humans don’t do a great job of simply ingesting material. Instead, Hunt suggests that we turn reading into a more active endeavor and describes using a technique called SQ3R. SQ3R is a simple strategy that can be used to actively engage yourself in whatever it is you are reading. The SQ3R process is as follows:

There is plenty of information available on SQ3R on the web and of course there are many other techniques that can be used as well. What is important however is that instead of passively trying to absorb what we read we are deliberate in the way we go about consuming information.

Mind Maps

Generating ideas, especially on structured topics can oftentimes be a challenge. Traditional brainstorming techniques such as creating outlines are a great start, but are often limited by their structure and by the restriction of simply using words to express ideas. An alternative approach which Hunt presents in this book is to create a Mind Map.

A Mind Map is a free form diagram that focuses on a central idea and illustrates the relationships among topics associated with that idea. The advantage of using a Mind Map is that you are not limited to simply using words. You can sketch pictures, draw lines between ideas, and use color to group similar thoughts.

As an example, I decided to create a Mind Map for a presentation I will be giving in a few weeks on VirtualBox. To be fair this might not have been the greatest example of the power of using a Mind Map because I have already done quite a bit of research on the topic, but it was a good place for me to get started with Mind Maps and definitely helped me solidify some ideas for my presentation. Here’s what I came up with (click to enlarge):

One thing I found interesting while creating this Mind Map was that I actually needed to create multiple drafts. My first draft of this very same image was pretty scatter-brained. But that is the point of creating a Mind Map. It helps you take the ideas from your head and organize them into a tangible format that can then be translated into actual work (i.e. a presentation, an essay, code, etc.).

Harvesting Techniques

Have you ever struggled with a tough coding problem? Do you think as hard as you can about the problem, but are still unable come up with the answer? Then has the solution ever popped in your head upon waking the next day? Did the answer you were looking for suddenly appear during your daily commute when you were least expecting it? This happens all the time and the reason it occurs is because in many case we already know the answers to our problems.

Our brains have an amazing capacity for storing and retrieving all sorts of relevant (and irrelevant) information. As an oversimplification we can think of our brains as being split into two distinct hemispheres. The left hemisphere (L-mode) is analytic, logical, temporal, linear, and rational. It is responsible for processing words and symbols. The right hemisphere (R-mode) is more spatial and is good at processing patterns and relationships. The right side of our brain is intuitive and makes decisions based on hunches, feelings, and images.

As developers we tend to heavily favor using the left side of our brain to solve problems in our daily work, but in order to learn and work as efficiently as possible we must use both sides of our brain. It is very difficult to force R-mode thinking, but you can help coax R-mode ideas out of your brain by using what Hunt calls harvesting techniques. Harvesting techniques are ways to relax your brain’s L-mode processing in order to allow your R-mode thoughts to surface. Here are a few examples of harvesting techniques:

Free Form Journaling – Writing is a great way to relax your mind and allow your R-mode thoughts and ideas to escape your brain and present themselves onto paper. When ideas pop into your head, write them down, and then elaborate on those ideas. Simple brainstorming on paper can give you the opportunity to clarify your thoughts.

Walking – Sometimes the best way to come up with ideas is to simply step away from your desk, relax your mind, and go for a walk. While you’re walking though, try not to think about anything, especially the problem you are trying to solve. The goal is to silence your L-mode and give your R-mode the chance to do some work.

Image Streaming – This is the process of deliberately observing images in your mind and paying close attention to them. First, pose a problem to yourself or ask yourself a question. Then shut your eyes and relax. As images start to cross your mind describe them out loud. Try to describe as many details as you can using all five senses. This type of thinking can help you discover fresh insights to the problem or question you presented yourself.

At first some of these ideas may seem a bit silly, but keep and open mind and give them a chance. You may be pleasantly surprised with the results.

Conclusion

Pragmatic Thinking and Learning is very accessible and easy to read. Hunt writes the book using simple terms and concepts and illustrates his points with many examples. I’ve really only begun to scratch the surface of the material covered with this blog entry. Hunt goes into much further detail in his book and offers many additional techniques to help developers discover how they can best approach learning a new subject.

The book describes many different aspects of human physiology and psychology to explain why certain techniques work and others do not. While Hunt does not claim to be an expert in either of these fields he cites a multitude of references and clearly shows that he has put in the thorough research required to write such a book. Overall this book was a pleasure to read and I would certainly recommend it to anyone interested in improving their ability to learn.

Author: Neal Ford
Rating: 3.5/5

As a developer I am constantly seeking ways in which I can improve my ability to quickly generate high quality code so I was excited to pick up Neal Ford’s latest book, The Productive Programmer. This book offers advice on how to accelerate the production and quality of code by exploring many tools and practices that developers can use on a daily basis. In the book, Ford introduces several productivity patterns that can be used immediately, but more importantly he defines a nomenclature that allows developers to construct additional productivity patterns on their own.

The Productive Programmer is broken up into two parts:

Part I. Mechanics

This section discusses tips, tricks, and tools that developers can use while physically engaged in the act of writing code. This section is laid out in a recipe style format and is the part of the book which I found to be the most useful.

Ford breaks Part 1 down into four chapters which he calls the “Principles of Programmer Productivity”. These principles are:

Acceleration

This chapter discusses tips developers can use to speed up their development efforts. Ford lists many tips on using launchers, clipboards, and keyboard shortcuts for a variety of popular development tools and operating systems.

Focus

Ford uses this chapter to introduce guidelines on how to limit distractions, context switching, and pesky officemates so that developers can stay in the zone and focus on what’s really important – their work!

Automation

Common tasks that are repeated over and over again can kill a developer’s productivity. This chapter lists strategies for automating such tasks to help save precious time throughout the workday.

Canocality (i.e. D.R.Y)

In this chapter Ford discusses the importance of version control, continuous build machines, and syncing development tools. This helps to ensure the entire development team is on the same playing field so that precious time is not lost in dealing with inconsistencies between individual developer environments.

Part II. Practice

In Part 2, Ford takes aim at practices that developers can use to improve the quality of their code. By using the techniques and philosophies discussed in this section, Ford illustrates how code can be broken down into small, readable pieces that are easy to maintain. Practices covered include Test Driven Development, Static Analysis, and Meta-Programming. Also discussed are a few development philosophies that can guide developers when making decisions about how they should go about writing their code. These philosophies include: YAGNI (You Ain’t Gonna Need It), SLAP (Single Level of Abstraction Principle), and my favorite – Questioning Authority, an excerpt:

The point is that just because things have always been done a certain way does not mean that we should blindly accept the status quo in favor of doing things that might actually make more sense or improve our code.

Thoughts

The Productive Programmer was an enjoyable read. At 200 pages the book reads very quickly – perhaps a bit too quickly in fact. My one criticism of the book is that it would have helped to have some additional examples to solidify some of the concepts in the second part of the book (I would guess that is probably my one criticism of most books). I did pick up a lot of small tips however and have been using them in my day to day work. I’ve noticed some small speed and productivity improvements so in my opinion this book was totally worth the Amazon sticker price.

Author: Dan Cederholm
Rating: 4/5

When I first started toying around with computers in the mid-90s one of my favorite things to do was create websites using free services like Geocities and Tripod. Back then I was guilty of all the deadly web design sins: table based layouts, pointless animated GIFs, heinous font and background color choices, and of course using the dreaded “Under Construction” page. Today I’m a little smarter about my design choices and feel that while web design as a whole isn’t quite where it needs to be, it is getting much better and there’s no doubt it’s because of books like Bulletproof Web Design by Dan Cederholm.

The book centers around designing sites to be accessible and flexible. A lot of the focus is on font sizing which on the surface may seem trivial, but because of differences among browsers, font size actually ends up having some important implications on accessibility. One of the most commonly used browsers (Internet Explorer 6) limits a user’s ability to increase or decrease a site’s font size if the designer of that site specifies the font size using strict pixel values. This creates a lot of problems for users with poor vision. Additionally, table based layouts are also targeted by the author for their excessive markup and rigid design constraints. In Bulletproof Web Design, Cederholm explains in detail some of the techniques designers can use to avoid these and other common design pitfalls.

Other topics included in the book that I found particularly useful were designing using floats, degrading pages nicely when CSS is not available, and a discussion on fluid vs elastic layouts.

While the book does not offer any revolutionary information, the concepts it does present on quality web design are organized in an efficient and easy to read manner. The book is filled with code examples and color pictures making it a quick and easy read. I’d definitely recommend the book to anyone starting out on a new web project or anyone looking for a refresher on best practices in web design.

A bit of a disclaimer: I just launched this blog recently and I know that I’m being a bit of a hypocrite by not following some of the basic web design principles found in the book being reviewed. I’m currently using a simple Wordpress theme built by Bob that gets the job done for now, but I’m looking forward to applying a lot of the principles from the book as I create my own custom theme for this site.