5 Great Feeds For Software Craftsmen

Today I was looking through my RSS reader of choice, Google Reader, and looking at the software development articles that I have starred. It occurred to me that you might benefit from knowing whose feed I am following. Here are my top five:

1. Uncle Bob's Blatherings
   

   This is a category on the Object Mentor Blog dedicated to Robert Martin's writing. It is one of my favorite for both practical coding advice as well as thoughts on methodologies and mentoring programmers.

   
   


2. PragDave
   

   Dave Thomas's Pragmatic Programmer Blog is full of small tidbits of useful insight on coding and also some pointers to the books his company puts out.

   
   


3. Martin Fowler's Bliki
   

   As Martin describes it, this is A cross between a blog and wiki of his partly-formed ideas on software development. This is chock full of industry news and his thoughts on different methodologies

   
   


4. Google Code Blog
   

   If you do any kind of web development, this Google blog is full of information on free APIs and techniques which will improve your skillset.

   
   


5. Joel On Software
   

   This is Joel Spolsky's site where he promotes his consultancy and views on running a software consultancy. I threw this one out there as a site to consider reading even if you don't necessarily agree with his approach. Sometimes being able to rationally debate an idea about software craftsmanship is extremely valuable.

   
   

Whose feed are you reading?

Oldies But Goodies

If you are a new reader of this blog, then you may enjoy some of the most popular posts from the archives:

• Rails Session Management


• Rails Session Management Howto: Part I


• DB Table Naming Convention


• 5 Great Code Refactorings


• Don't Release on Friday

Any future topics you would like to see covered?

Software Craftsmanship Group

Just wanted to point out a Google group that has gotten really active over the last few months. It is called Software Craftsmanship and as of right now is at 585 members. I believe it was originally started by a group from 8th Light who meet monthly in the Chicago area.

The group has pages on a Software Craftsmanship Manifesto and Charter. Give it a look and let me know what you think.

DB Table Naming Convention

It can be common for developers to be involved in the creation and design of databases for an application they are developing. Since most developers aren't trained as Database Administrators, it is important that they develop some sound approaches to writing SQL and Data Definition Language (DDL). I've previously reviewed Database in Depth: Relational Theory for Practitioners by C. J. Date in the post, Book Review: Database in Depth. I highly recommend getting it as a guide to best practices for any relational database work.

Singular or Plural

One of the choices that invariable occurs is what to use for table names. Sometimes the particular RDMS may restrict the choices, but often this is pretty wide open. What I'm interested in is the small decision of whether to use the singular or plural form of a noun for the name. A common example is the table where user data is held. Should the table be named user or users?

My Choice

I am not sure there is a standard answer. This has been discussed before (for example, see Database table naming conventions), but I haven't seen anyone justify why it is better to make the choice for theoretical reasons. Some frameworks or DDL tools will make the choice for you as I discuss below for Ruby on Rails. My own choice has been to use the singular name. I think this leads to improved code quality because:

1. It leads to consistency in Foreign key names (order.user_ID references user.ID).
2. It makes ORM a 1:1 match (the user object reflects a row in the user table).
3. It avoids some of the annoyance of the English language pluralization rules (see Rails below).
   
4. Then there are small things like ordering of tables. For example, user, users, userOrder, and user_line_order may not sort in the most effective way.
5. I believe it is the simplest design that works. Using the plural form makes me think there is a singular table from which the plural form is distinguished. Would that be a table which is guaranteed to only have a single row?
   

Rails makes a poor choice?

So what happens when you use the command script/generator scaffold user in a Rails project. Rails generates a DB migration for creating a users table. There are ways to control the model names and DB migration, but it is interesting that the developers of Rails decided to make the default choice of using plural table names. (See Agile Web Development with Rails for example syntax on how to not use defaults).

But what about that tricky English language? Well script/generate scaffold person produces people. Pretty cool. And woman produces women. But then goose becomes gooses. Woops! Now you may have no need for a goose object in your application, but I am sure there are other examples like this. Alas, this appears to be a bug in the Rails framework, but just think how easy it is for you to bump into this yourself when trying to remember the plural form of the object you are working with. In addition, these names show up in the URL for Rails routing. Thus they become public. I rather see geese in applications I work on.

I realize there are pros and cons to the choice of using singular or plural names. In terms of producing quality code, what do you use and why?

5 Code Refactoring New Year Resolutions

Since I have been posting some of my favorite refactorings (5 Great Code Refactorings) and re-reading Refactoring by Martin Fowler lately, I thought I would discuss five refactorings that I wish I used more and make them my Software Craftsmanship resolutions for 2009.

1. Move Method

While I use this refactoring on a regular basis, I'd like to use it more in a specific case. Specifically I want to move more behavior into my data classes so that they don't just contain simple get and set methods and private fields. It may even be possible to make the get and set methods private at some point.

By using this refactoring in the specific case of data classes, I believe that the my classes will have improved cohesion in the OOD sense.

2. Replace Magic Number with Symbolic Constant

I also use this on a regular basis when I am coding. For example, I might use the literal 1024 several times within a class. I usually will replace it with a constant that explains what it is so I only need to change it in one place. This is fine. However, I resolve to replace some magic numbers with a constant even if they are only used a single time. The reason for this is that by naming the constant appropriately, I can achieve improved readability for my code.


3. Encapsulate Collection

This is a refactoring that I have never used and resolve to try this year. The idea is to refactor a class containing a method that returns a modifiable collection into a class with a method that returns a read-only collection and has add and remove methods for the collection.


In Java, this is done by using the Collections interface methods unmodifiableList(), unmodifiableSet(), etc.

This produces proper encapsulation and leaves the responsibility for manipulating the values of the collection up to the class which owns the collection. Thus the coupling is now similar to that of a data class with get and set on non-collection objects.


4. Introduce Null Object

This is one of my favorite refactorings. I saw it presented at a user's group meeting many years ago in a discussion of the null object pattern. The basic idea is to replace repeated checks for a null value with a null object.

Normally you test if an object is not null and then call a method on the object. Instead of doing that you can create a null object and then call the method and get the appropriate behavior. The refactoring involves creating a null object (a subclass of the same type as the non-null object) which contains the methods needed to produce the same behavior in your code as would be done when the test of the null value for the object is true.

I infrequently use this refactoring and resolve to use it much more this year. One of the biggest motivations is when looping through objects for display purposes. I can eliminate all those tests for null values that just lead to displaying blanks.


5. Replace Nested Conditional with Guard Clauses

I'll give a very simple example of this here:

if (i==1) {
result=odd1;
} else if (i==2) {
result=odd2;
} else if (i==3) {
result=odd3;
} else {
result=normal;
}
return result

can be refactored to

if (i==1) return odd1;
if (i==2) return odd2;
if (i==3) return odd3;
return normal;


The above method reflects the unusual case where i equals 1,2, or 3. It "guards" against them. This refactoring provides more clarity within the code and I resolve to use it more in 2009.

If you have any questions about how to perform the above refactorings, I encourage you to leave them in your comments here and also I highly recommend picking up a copy of Refactoring.

I believe that each of these resolutions will contribute to better code quality based on Why Refactor. What are your New Year's coding resolutions?

5 Great Code Refactorings

Refactoring is the process of changing software such that it does not alter the functional behavior of the code while improving the internal structure. The first key point is that code which is already written is being improved. The second key point is that the behavior of the software is not being altered. This is not a process for fixing bugs. I've previously discussed motivations for refactoring in Why Refactor.

Below are 5 refactorings that I frequently use in practice:

1. Extract Method

   One of the most common refactorings I use. It involves taking a section of code and putting it into a method whose name explains the purpose of the method. This has two advantages for me. First, it breaks up longer methods into shorter, clearer methods to read. Second, it is useful for applying the DRY principle when you have the same code repeatedly in a class or multiple classes. You may need to determine how to make code sections look exactly alike so that this can be done. For example, passing in nulls to the method in certain classes, but not in others. I believe this is an example of Parameterize Method

2. Rename Method

   This is the process of changing a method name such that the name is more informative by clearly showing the purpose of the method. I often perform this refactoring when introducing another new method to the same class which is similarly named.

3. Move Method

   Another common refactoring for me. I use this when I want better cohesion in my classes. This leads to simpler designs and better understanding of the responsibilities.

4. Introduce Parameter Object

   I introduce a new data object (with getters and setters) when I have a group of parameters that are related and frequently accessed together. This then may lead to use of Move Method if there is also associated behavior with these parameters.

5. Introduce Explaining Variable

   This is one that I wish I used more often. I think the best examples I have seen are to introduce a boolean for a complex expression in an if statement. By using a name that adds clarity, reading the if statement can be improved substantially. For super complex conditional logic expressions you can reuse this repeatedly to simplify the code. It can really make code maintenance much simpler in the future.
   

Agile methodologies make refactoring an enjoyable process. With the principles of test-first design and simple design, refactoring becomes a complementary exercise. It makes it easier to keep the design simple and the unit tests provide the confidence needed to make frequent changes to the code during refactoring sessions. Perform your favorite refactoring and run the tests to be sure no functional behavior was broken.

What are your favorite refactorings? For more insight into refactoring, I highly recommend Refactoring: Improving the Design of Existing Code by Martin Fowler.

Rails Session Management Howto, Part IV

In Rails Session Management Howto, Part III of this series, I described memory based session storage approaches. The mem_cache_store approach provides fast access to the session data and unparalleled scaling, but doesn't provide rock solid reliability (because it is ultimately a cache). It also maybe overkill for a lot of applications. In this post, I will discuss the final approach which is database based sessions.

There are a couple of options. The first is to use DRb storage. With the drb_store, the session data is marshaled to a DRb server. The DRb server is accessible from multiple servers so you can scale out to many servers for your application. And it is also reliable. DRb stands for distributed Ruby and more information about DRb and DRb server is available in Intro to DRb. Performance is reported to be very solid with DRb based session storage.

The second option is to utilize the built in Active Record capability of rails. I like the active_record_store because it is easy to configure and immediately provides scalability and reliability to session data storage. Performance is largely dependent on the database server infrastructure, which is a well know field and has many different optimization possibilities. Rails provides a simple way to configure the sessions by running rake db:sessions:create. Then you can just run the migration to create the table via rake db:migrate.

As pointed out by the authors of Agile Web Development with Rails, the proper choice of session storage is uniquely application and environment driven. There is an older study, by Scott Barron comparing the performance of some of these approaches. Although the results might have changed slightly, the considerations and insights are still probably very valid.

I personally use the active_record_store as my default approach. It requires no special outside expertise to implement and for most applications it is scalable and reliable. What do you use?

Rails Session Management Howto, Part III

In Rails Session Management Howto, Part II, I discussed using the PStore approach for session data storage. The p_store based sessions utilize the local OS file system. In this post, I will present memory based storage approaches for session management in Rails.

The first approach is to use memory_store based sessions. With MemoryStore the session objects are kept in the applications memory with no serialization necessary. While this approach will make it extremely fast for an application to move objects in and out of a session store, it is not a reliable method because the memory where the session data is stored is only available to a single server. Thus it also does not scale well since it requires sticky sessions.

The second approach utilizes memcached, a high-performance, distributed memory object caching system. Memcached is used by some of the largest websites in the world and is certainly a very solid approach for session storage. The mem_cache_store based sessions meet the criteria of scalability (just add more servers) but this approach is still not reliable. Because it is a cache you still need to use some form of reliable storage for your session data, such as a database store. But if you need super fast reads of the session data across multiple servers, then memcached is really the best performing approach. You can find some discussion of that approach discussed in Sessions. Several memcached Ruby clients are available including RMemCache.

For more discussion of these memory based sessions and their configuration, I recommend you pickup a copy of the excellent reference Agile Web Development with Rails. Are you using a memory based session approach? How do you scale and protect against server crashes (or maintenance)?

Book Review: Software Craftsmanship

Software Craftsmanship: The New Imperative by Pete McBreen is the best book I have ever read about software development. It is written for programmers who want to produce the highest quality code and project managers who want to work with and nurture those type of programmers. Pete emphasizes that software is best developed by small teams and developers can reach the top of their craft via the mentoring that occurs among the apprentices, journeymen, and experienced craftsmen in these teams. I am a enthusiastic supporter of the approach explained by Pete and believe all software developers and project managers should read this book repeatedly.

Some of the topics covered include:

• Understanding customer requirements
• Identifying when a project may go off track
• Selecting software craftsmen for a particular project
• Designing goals for application development
• Managing software craftsmen

The most important aspect of the book is the questioning of the popular Software Engineering approach to development and how Software Craftsmanship differs. It all boils down to valuing the people over process.

This book appeals to me so strongly because it reflects the reality of my own experience. The highest quality software (maintainable, bug free, simple design, and providing the most value to the user) I have seen developed has always been done by small teams with strong craftsmen leadership. I think Pete also does a good job of emphasizing how important it is to create the proper environment for fostering the craft of software development.

Do you have a copy of Software Craftsmanship: The New Imperative? If so, what is your favorite piece of sage advice from it?

Rails Session Management Howto, Part II

In Rails Session Management Howto Part I, I introduced the concepts of managing http sessions with Rails and explored the first approach, cookie based sessions. A couple of the limits were the size of the data that can be stored in the session and the lack of encryption as the data is transferred from browser to server. The next approach is to store session data in a flat file on the server in what is known as the PStore format. This format stores the serialized (marshaled) form of the session data on the file system. The location and name (actually just the prefix for the name) of the file can be configured in the environment.rb file. Refer to Agile Web Development with Rails by Dave Thomas for details on the syntax and configuration.

The benefits of using the p_store based sessions are that the data is securely kept on the server and never crosses the network between the browser and server. This provides security and also reduces bandwidth usage. The size limit of the session data is also greatly increased (limited by your system IO).

What happens when scaling the number of servers? Clearly each server can not have an individual PStore unless one is using "sticky" sessions and are willing to have users lose their session data when a server fails. This is not an optimal situation for scalable, reliable, load-balanced systems. When there is more than one server, then it is necessary to have the PStore file available to all servers because subsequent http requests may be directed to a different server each time. One way to do this is to place the PStore file on a network mounted storage system.

Thus with a p_store based session there is increased data security and reduced bandwidth usage vs a cookie based session. However, there is also now some challenging server configuration choices and network file storage. Thus it is a IO limited solution which requires a lot of optimization and monitoring. For some applications this might not be a problem and should be tested. In an application with many simultaneous sessions the number of PStore files can grow very large.

I'll also briefly mention that there is a file_store option for sessions in Rails which also uses flat files, but it is rarely used because the session data must be strings.

Is anyone using p_store based sessions in their applications? Is it scalable? Is it reliable when servers failover?

In the next part of this series I will examine some memory based sessions.