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)?

Related Posts

• Rails Session Management Howto, Part II
• Rails Session Management Howto, Part I
• Rails Session Management
• Accidental Perceived Functionality

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.

Related Posts

• Rails Session Management Howto, Part III
• Rails Session Management Howto, Part I
• Rails Session Management
• Accidental Perceived Functionality

Sessions can contain any objects which can be marshaled (think serialization if you are used to other languages). Rails provides numerous ways to persist the session objects. The default in Rails 2.0 is to send it via a cookie to the client. Because the session is hash-like, multiple objects may be stored in the session. The size limit of cookie based session objects is 4K total.

Because the data in the session is passed with every http request from the client to the server, this can cause an increase in bandwidth usage compared to alternative approaches (discussed in the next posts). Also, even though the cookie contents are signed, they are unencrypted by default. So no secure data should be stored in the session when using the cookie_store.

If your session data is very small and the data is not sensitive, then using the cookie_store can be very effective. However, for many web applications this is not the case and fortunately Rails provides some effective solutions.

You can change the session defaults in your controllers by overriding them with the session declaration in a controller.

Related Posts

• Rails Session Management Howto, Part III
• Rails Session Management Howto, Part II
• Rails Session Management
• Accidental Perceived Functionality

Regardless of the cause, the net result is guaranteed to be user complaints about an issue with functionality (ordering of the resultset in the UI) which was never intended to be a function of the application. This is what I term accidental perceived functionality (no doubt, somebody has a better name). Please post other examples of this (so we can all learn) in the comments.

Tips to avoid this situation:

1. Hire a good business analyst to capture all requirements (including eliminating possible points of confusion). This won’t necessary avoid the problem, but will increase the odds.
2. Make it a habit to always include an ORDER BY clause in all SELECT statements.
3. During table definitions always provide a column that allows ordering of results in accordance with the desired functionality (capture by requirements)
4. Thoroughly unit test the results sets (including order) of your DAOs.

Related Posts

• Rails Session Management Howto, Part III
• Rails Session Management Howto, Part II
• Rails Session Management Howto, Part I
• Book Review: The Pragmatic Programmer

Today I am continuing a series of posts in which I will be reviewing some of the books which are related to the development of quality software. They may be specific to a certain technology or a software development methodology.

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas is aimed at developers who want to write software systems that are easy to design, build, test and extend. Andy and Dave have revealed some of the basic practices that they follow during the full software lifecycle as well as project management and career development. I am an enthusiastic fan of their work and believe this book should be read by every developer early on in their career.

This book is also one of the easiest books I have ever read. The chapters are concise nuggets of information and I found myself flying through them and then stopping to reflect on what I had just read. Even though the chapters are grouped, each chapter is mostly independent of the others and it makes it easy to stop/start without having to recall the details of the previous chapters. So, the book is one that you can pickup months or years later and go right to a chapter that you want to reread without needing to read the whole book again. In that sense, it is almost a reference book.

Good-Enough Software

Of the many gems in the book, one of them is “Good-Enough Software”, which is about creating software that users qualify as being good enough. This approach can be capture by empowering users to be a part of the process and to shift quality into requirements specs. In the Agile world this is related to producing the simple design over the complex one with the caveat that the design must work.

DRY Principle

Another great idea is the DRY (Don’t Repeat Yourself) principle. The idea is to eliminate any duplication of functionality and define a single authoritative location for it. This creates consistency, simplicity and reduces many maintenance headaches. Not only is this important in a single software system, but with the invention of Service Oriented Archictectures (SOA), you can apply it across systems.

Broken Windows Theory

One further nugget is the idea that leaving “broken windows” (bad code) unrepaired in a system will eventually compound and pretty soon you will have a whole system (building) full of broken windows and a team that doesn’t mind throwing stones occasionally. The idea is to take the time to repair your code as soon as you see an issue so that the software doesn’t deteriorate.

Consider this to be a must have for your collection and get a copy of The Pragmatic Programmer: From Journeyman to Master today.

Related Posts

• Rails Session Management Howto, Part III
• Rails Session Management Howto, Part II
• Rails Session Management Howto, Part I
• Accidental Perceived Functionality

• Are you interested in working with some of the best Agile developers in the DC area?
• Do you want to learn from top Software Craftsmen as they concentrate on code quality and delivery of working software?
• Do you possess J2E skills?
• Do you like to share knowledge?
• Are you comfortable putting the success of the team ahead of yourself?
• Do you like daily interaction with the end users of the software you are developing?

If so, please contact me via my contact page ASAP.

Related Posts

• No Related Posts

• pragdave Dave Thomas of The Pragmatic Programmer
• bryanl Brian Liles discusses Ruby, Macs and web technology
• unclebobmartin Robert Martin discusses programming approaches and techniques
• WardCunningham discusses Agile, Patterns, etc.
• packetlife  Jeremy Stretch talks networking
• martinfowler discusses software developement methodologies
• KentBeck discusses programming and methodologies
• aglover Andrew Glover discusses development and testing
• RonJeffries discusses Extreme Programming

A longer list is available at http://twitter.com/dcpatton/techies.

Are there others in the software craftsmanship area you follow?

Related Posts

• Book Review: Database In Depth
• 5 More Code Refactorings
• My Associates Store – Books
• Book Review: Software Craftsmanship

Today I am continuing a series of posts in which I will be reviewing some of the books which are related to the development of quality software. They may be specific to a certain technology or a software development methodology.

I’ve chosen to continue this series with Database in Depth: Relational Theory for Practitioners (amazon affiliate link) by C. J. Date. The target audience of this book is experienced database practitioners, not novices. If you’ve been involved with writing lots of SQL and DDL, then I believe the book is aimed at you. It explains the basic principles of relational theory in depth. The book is completely independent of any particular products and the SQL standard. One of the fascinating aspects of the book is the revelation of how few (if any) commercial database products truly implement the relational theory.

The author C. J. Date, worked closely with the E.F. Codd (inventor of the relational model), strongly influenced the development of database technology, and is considered to be a master in the field. For such an theoretical book, I found his writing style to be very lucid.

Theory discussed includes relations, types, tuples, relational variables, relational algebra and database design theory. One of the most applicable sections is the discussion of normalization. Another principle that I have taken to heart is the prohibitions of nulls. What is a method of implementing this principle? Well here is one. First suppose you have the following situation:

To avoid the NULL in the table, you can design the schema to be like the following:

Table 1:

Table 2:

By breaking up the original table into two tables we have avoided the use of NULLS. Complimenting this approach to database design is the use of OUTER JOINs in SQL.

If you want to become a better developer, I recommend reading Database in Depth: Relational Theory for Practitioners (amazon affiliate link).

Related Posts

• My Associates Store – Books
• Accidental Perceived Functionality
• Book Review: The Pragmatic Programmer
• Twitter Users To Follow

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?

Related Posts

• Book Review: Software Craftsmanship
• Rails Session Management Howto, Part III
• Rails Session Management Howto, Part II
• Rails Session Management Howto, Part I

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 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.

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 refactorings will contribute to better code quality based on Why Refactor. What are your favorite refactorings?

Related Posts

• 5 Great Code Refactorings
• Book Review: Software Craftsmanship
• Why Refactor?
• Rails Session Management Howto, Part III