stevedoria.net

The Linux User’s Manual page states, “The iostat command is used for monitoring system input/output device loading by observing the time the devices are active in relation to their average transfer rates.” The page continues, “The iostat command generates reports that can be used to change system configuration to better blaance the input/output load between physical disks.”

Today, I caught myself doing this:

bool f()
{
  bool r;
  if( x == y )
  {
    r = true;
  }
  else
  {
    r = false;
  }

  return r;
}

When I really should have written:

bool f()
{
  return x == y;
}

In the actual code I that I was writing, x and y were functions or fields that used multiple member access operators. I do not remember why I wrapped this boolean expression into a function, but when I caught myself doing the former, it was like smelling a strong stench.

Everyday is an opportunity to learn something new. Today, I learned how to set the tab width for vi (set tabstop=2) while trying to format the picture for this blog entry, for example. Daily learning is a form of personal refinement. Accumulated knowledge allows people to do things better.

If the lesson relates to development, then that piece of incremental personal development can be used to enhance software development.

Here are snippets of code that I have written and currently maintain:

The functionality of both versions are essentially identical. I wrote the version on the left side approximately two years ago. The one on the right side is the current and evolving version.

Changing the function’s accessibility is a significant evolution of the code. Straying from the simple public/private access control dichotomy, I employ protected accessibility to allow child classes to reuse this code. It is currently labeled final, because I do not want child classes to be able to override this function at this time. I may remove this restriction, if I later feel that there is a need. This follows the computing adages of minimizing interfaces, minimizing code duplication, and employing code reuse. Restrictions on a module’s interface can be relaxed. Restrictions cannot, however, be increased due to possible dependencies. Code may have been implemented to depend on a module’s interface, and to restrict accessibility to a function of the module, for example, would require code to be reworked. The cost of reworking the code that depends on the relaxed interface to use a more restrictive one grows significantly along with the amount of dependent code.

Supporting two versions of a particular class encouraged my use of inheritance here. Two files were used to provide a debug and a production version of the class. Modifying code that is common to both versions required that code be copied from one file to the other. The duplication of code is a “smell,” as Fowler puts it, that indicates the code can be better organized. Instead of replacing the debug and production versions of the files containing a class as I did earlier, which is a potentially dangerous practice, I use inheritance to localize duplicate code into the parent class and employ a factory method (not shown) that returns a debug or production instance of the class. If dependents on this class use the factory method to create an object, they do not have to be aware of which child class an object is. This assumes that the dependent code is written to depend on the interface that is defined by the factory method’s return type, which is usually a parent class. Since an object of the parent class can be substituted with objects of child classes, the factory method can return an instance of the child class while advertising the parent class as its return type to dependent code, and the dependent code will act on the object just the same.

The use of accessors to fetch the field values of a class instance is another significant change in the code. Although this does not serve more than little protection from unintentional instance variable modification (the instance variables could still be accessed directly in the member function), it may be useful if lazy evaluation is employed. So, the use of accessor functions is a good practice. A little indirection seems to always be good.

I also introduced a dependency into the function’s implementation. Rather than use a heretodoc string to represent an XML document, I depend on a class that speaks XML.

My code and designs have certainly improved over the years. To help reinforce and develop of my skills, I continually employ good programming and software engineering practices on the projects that involve me. I also analyze my approach and think about alternatives or ways that it can be made better.

I just finished rereading Design Patterns: Elements of Reusable Object-Oriented Software. As a little experiment, I will explore how far I can get with the book’s fundamental design patterns with Python, an object-oriented scripting language that I am trying to pick up.

One of the first design patterns I came across even before reading DP is the Singleton pattern. The basic Singleton pattern creates a single instance for an entire system to use. A system task scheduler or print spool are examples of singletons.

The source code of my implementation of the Singleton pattern in Python is presented here:

# Singleton class definition
class MySingleton ( object ):
  __instance = None	

  def __new__( cname ):
    if not cname.__instance:
      cname.__instance =
        super( MySingleton, cname ).__new__( cname )
    return cname.__instance

  def setX( self, x ):
      self.x = x

  def getX( self ):
      return self.x

# Singleton client code
a = MySingleton()
b = MySingleton()

print a
print b

a.setX("hello")
print b.getX()

The output from the Python interpreter is:

<__main__.MySingleton object at 0xb7ebb24c>
<__main__.MySingleton object at 0xb7ebb24c>
hello

Printing the objects shows that the objects are located at the same address and are the same type. Furthermore, invoking operations that modify the instance that is attached to “a” affects the one that is attached to “b.” Changes to “a” are reflected in “b.” In other words, the instance of MySingleton that is referenced by “a” and “b” are the same. This demonstrates the Singleton pattern in Python.

“You dropped a hundred and fifty grand on a fucking education you could’ve got for a dollar fifty in late charges at the public library.” –Will, Good Will Hunting

My experience in college can be summed up as an ongoing lesson on learning. College was an opportunity to learn how to learn. I am employing tactics, which I used to succeed at a university, to pick up the knowledge that I need to perform tasks and prepare for future accomplishments.

There have been many books that I have read since I left college. Some books that I believe have improved my code and overall software architecture are Object-Oriented Analysis and Design with Applications by Booch et al. and the gang of four’s Design Patterns: Elements of Reusable Object-Oriented Software. These books are not specific to a particular programming environment, but can be applied to many kinds of projects.

As an example of a book that is less theoretical and more applicable, C.J. Date’s An Introduction to Database Systems comes to mind. I have read several books on team and project management, too. I also picked up books that I wanted to read while I was at college, namely, Richard Stevens’ Unix Network Programming. I have also read books on notations like the UML, but I feel the same about reading such books as I did in college. I am still somewhat discouraged from reading about notations that I perceive as more transient than a given widely accepted, general programming language.

Not all books that I have read are technical. I have read books that talk about personal finance and planning, such as Peter Lynch’s Beating the Street and One Up on Wall Street, David and Tom Gardner’s The Motley Fools Rule Breakers Rule Makers and The Motley Fool Investment Guide, along with Robert Kiyosaki’s Rich Dad, Poor Dad.

My reading queue currently includes a math book on game theory, Luce and Raiffa’s Games and Decisions, and one on legal matters with regard to software. I did not care much for reading while I was in school, so I am pretty impressed with the amount of reading that I have done lately. There are still many books on topics that I would like to study and other books that are listed in the syllabuses of graduate level university courses that make up my reading list.