Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T02:27:31Z

Hriyer: /* References */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

* DRY - Donot Repeat Yourself which means that any piece of knowledge should occur once and once only.

* DIE - Duplication Is Evil which is another name for DRY principle.

* Data Duplication - Multiple instances of same data.

* Database Anomaly - Inconsistencies in database caused due to redundancy.

* Functional dependency - When an attribute X functionally determines another attribute Y, Y is said to be functionally dependent on X.

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

* Causes anomalies: It causes functional dependencies in the system. Please refer point 4 of the [[#Why Dry | previous]] section.

* Too many references to change: Please refer point 5 of the [[#Why Dry | previous]] section.

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that needs to be used while design a system. DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of cache improves the performance of the computer significantly. 
* If there is need for data redundancy. For example Source control software makes sure that if one version of file is damaged there are always previous versions to fall back on. 
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion. 

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

7. [http://en.wikipedia.org/wiki/Abstraction_principle_%28programming%29 The Abstraction Principle (Good background to DRY)]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T02:25:25Z

Hriyer: /* Some Basic Terminologies */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T02:16:09Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

* Causes anomalies: It causes functional dependencies in the system. Please refer point 4 of the [[#Why Dry | previous]] section.

* Too many references to change: Please refer point 5 of the [[#Why Dry | previous]] section.

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that needs to be used while design a system. DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of cache improves the performance of the computer significantly. 
* If there is need for data redundancy. For example Source control software makes sure that if one version of file is damaged there are always previous versions to fall back on. 
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion. 

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:35:52Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stores multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following DRY principle for code is definitely a must, but as mentioned above there can be cases where DRY can be violated for data. There can be no definite guidelines for not following this rule, but we think in the following cases violating DRY for data should be considered

* If the performance of the system is significantly improved. For example adding layers of caches improves the performance of the computer significantly.
* If there is need for redundancy. For example Source control software makes sure that even if one version of file is damaged there are always previous versions to fall back on.
* If violating DRY reduces overhead. For example making copies of global data locally reduces the overhead of adding logic for mutual exclusion.

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:34:28Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

We discussed why it is important to use DRY in the [[#Why Dry | previous]] section by discussing how it may result in clumsy code. It is a misconception that DRY is applicable to code only. It is very much applicable to data as well which we shall see in this section by analysing how it could be a harmful idea to have data duplication.
 
The following figure is a representation of how DRY is violated in a bad way by data duplication.
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]
 

Let us consider some of the many possible problems of Data Duplication
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:25:09Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

The [[#Why Dry | previous]] section has discussed
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY
[[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:24:52Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

The [[#Why Dry | previous]] section has discussed
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY
[[Image:dry.jpeg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]]

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:22:10Z

Hriyer: /* Why Data Duplication is harmful */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==

The [[#Why Dry | previous]] section has discussed
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

DRY is one of the important principle that need to be used while design a system. Following

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:19:06Z

Hriyer:

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:17:24Z

Hriyer: /* Why DRY? */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies. 
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference. 
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:16:05Z

Hriyer: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)''' [[#References | [5]]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:15:28Z

Hriyer: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

<table border="3">
<tr>
<td>
[[Image:dry.jpeg.jpg]]
</td>
</tr>
<tr>
<td>
Taken from http://tagschema.com/blogs/tagschema/
</td>
</tr>
</table>

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't have to get data
or instruction from the main memory.

'''Buffer Manager in DBMS''' is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them
for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates a copy of the source files for each project to ensure that the properly working source are
not disturbed.

'''Read-copy-update (RCU)'''[#References | [5]] is an operating system kernel technology for improving performance on computers
with more than one CPU. RCU allows you to read a shared data structure as if there were no other CPU accessing it. When you need
to update the data structure, you can update the global pointer to the data and keep the old copy until all the threads currently
executing inside the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, after
which the old copy can be deleted.

'''Global Data''' in system can be a cause of concern because multiple components of the system share the same data specially in a
multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When a new object has to be created, we clone the prototype
there by creating multiple copies of the same thing in the system.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:02:40Z

Hriyer: /* References */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

6. [http://tagschema.com/blogs/tagschema/ A review on DRY in Social Communication]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T01:00:18Z

Hriyer: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, it is some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:59:56Z

Hriyer: /* When Data Duplication wins over DRY... */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== Why Data Duplication is harmful ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Let us look into DRY

== When Data Duplication wins over DRY... ==

Data Duplication while bad as discussed in the previous section, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:53:46Z

Hriyer: /* DRY on Data */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== DRY on Data ==

Let us look into DRY

== When Data Duplication wins over DRY... ==
Data Duplication can be a big problem in many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.

'''Source Control''' software creates creates a copy of the code to each member of the team to ensure smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-
threaded application. Instead we could have multiple copies of the data accessible locally to each component.

'''Prototypes''' are another example where DRY is violated. When ever a new object has to be created then we clone the prototype
and use that object there by creating multiple copies of the same thing in the system

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:51:00Z

Hriyer: /* Why DRY? */

DRY Principle for Data 

----

== Introduction ==

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book [[#References|The Pragmatic Programmer]]. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed [http://www.artima.com/intv/dry3.html here]. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

== Some Basic Terminologies ==

== Why DRY? ==

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space. 
   An Example : 
Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of
the source code. This saves us the execution time as well as the memory.
2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy. 
   An Example : 
The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending
it.
3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation. 
   An Example : 
Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary.
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X
represents salary. It would have been a lot easier if the variable name was 'salary'.
4. It becomes very difficult to debug the code in case of anomalies.
   An Example : 
Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary
is not getting revised in peculiar cases.
5. It is always a good practice to have one reference.
   An Example : 
The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates
the salary.

== DRY on Data ==

== When Data Duplication wins over DRY... ==
Data Duplication can be a big problem is many systems. Some of the problems are listed below
* Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

* More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

'''Caches in Computers''' basically maintain a copy of data which is present in the main memory. This is good for the system on
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or
instruction.

'''Buffer Manager in DBMS''' is a intermediate layer in the DBMS which gets the DB pages from the Disk and buffer them
for upper layer components to use.

'''Source Control''' software creates creates a copy of the code each member of the teamwhen a more than one person is working a
project This ensures smother development.

'''Read-copy-update (RCU)'''[3] is an operating system kernel technology for improving performance on computers with more than one
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock.
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be
deleted.

'''Documentation''' of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every
possible place even if it means repeating the same thing.

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. [http://www.artima.com/intv/dry.html A discussion with the Authors of the Pragmatic Programmer]

3. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html A good introduction to DRY]

4. [http://stevesmithblog.com/blog/don-rsquo-t-repeat-yourself/ Importance of DRY]

5. [http://lse.sourceforge.net/locking/rcu/HOWTO/intro.html#WHATIS Read-Copy-Update]

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:31:08Z

Hriyer: /* Why DRY? */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:17:15Z

Hriyer: /* References */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:16:39Z

Hriyer: /* References */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:13:04Z

Hriyer: /* Why DRY? */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-19T00:12:06Z

Hriyer: /* Why DRY? */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:52:47Z

Hriyer: /* Introduction */

References

2009-11-18T23:50:25Z

Hriyer:

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:49:52Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:49:10Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:48:00Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:45:50Z

Hriyer: /* References */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:43:11Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:42:15Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T23:35:50Z

Hriyer: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T22:57:26Z

Hriyer:

DRY Principle for Data 

----

== Introduction ==

== Some Basic Terminologies ==

== Why DRY? ==

== DRY on Data ==

== When Data Duplication wins over DRY... ==

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T22:43:17Z

Hriyer: /* Why DRY on Data? */

DRY Principle for Data 

----

== Introduction ==

== Some Basic Terminologies ==

== Why DRY? ==

== When Data Duplication wins over DRY... ==

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T22:37:09Z

Hriyer:

DRY Principle for Data 

----

== Introduction ==

== Some Basic Terminologies ==

== Why DRY on Data? ==

== When Data Duplication wins over DRY... ==

== Guidelines on whether or not to use DRY for Data ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2009/wiki3 4 ashi4

2009-11-18T22:36:29Z

Hriyer:

DRY Principle for Data 

----

= Introduction =

= Some Basic Terminologies =

= Why DRY on Data? =

= When Data Duplication wins over DRY... =

= Guidelines on whether or not to use DRY for Data =

= Conclusion =

= References =

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-17T01:03:07Z

Hriyer: /* Example */

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify/work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

1. Allow simultaneous / parallel development of software
2. Integrate code changes from different teams / developers
3. Propagate bug fixes to future versions of the software
4. Isolate, coordinate and tidily separate work item units
5. Track and revert to older versions
6. Keep related projects in sync with one another
7. Reduce costs of late merging
8. Reduce cost of maintaining codebases

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answers. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

          Source code management techniques invariably include trade-offs. While branching early could be good, the costs for merging could add up. Trade-offs between maintaining multiple lines like development and maintenance lines can also be confusing to an extent. Optimistically thinking, maintaining a single line for both maintenance and development could be tempting. It would allow new changes / bug fixes from the maintenance team to become immediately visible in the development line thus incorporating all the bug fixes into the new development cycles. However, the cost of merging each time into the new development branch is an important criterion. What would happen if the new code being developed by the development branch is in conflict with a new bug fix? Who would re-work the code to get around the problem? Such trade-offs and many many more become important for efficient source code management.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Examples =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches. 

         The following diagram is taken from the [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/how_base_populate.htm IBM Boulder site]. It is a snapshot of the ClearCase.
[[Image:Clearcase.gif|thumb|center|550px|alt=A snapshot of IBM Rational ClearCase|A snapshot of IBM Rational ClearCase]]
 The above diagram is a snapshot view of a shared file Prog.c which is in the clearcase. The circles show the different versions of the file, i.e. the number of circles are basically the number of times the file was checked out and checked back in. The dark circle means that the file has been currently checked out by someone called "user" as shown. The file Prog.c, when checked out is copied locally in the user's machine. The changes that the user makes remains local until he checks in the file again.

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

         Another widely used tool for source code management is Subversion - an open source initiative. Subversion has superseeded CVS as the versioning control system of choice since it includes important functionality like deleting and renaming directories which were absent in CVS. The users of SVN range from those working on very small classroom projects to mammoth ones like the ones in SUN Microsystems. SVN uses a relational database, BerkleyDB as the backend and works much faster than CVS. With space for adding metadata with each file and support for "all or nothing" commits, SVN is more stable and allows for better management of the codebase.

''The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= See also =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]

= References =
1. http://www.sunsource.net/scdocs/ddCVS 
2. http://www.codewalkers.com/c/a/Server-Administration/Source-Code-Version-Control-Solutions 
3. http://en.wikipedia.org/wiki/Revision_control

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-17T01:01:11Z

Hriyer: /* Example */

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify/work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

1. Allow simultaneous / parallel development of software
2. Integrate code changes from different teams / developers
3. Propagate bug fixes to future versions of the software
4. Isolate, coordinate and tidily separate work item units
5. Track and revert to older versions
6. Keep related projects in sync with one another
7. Reduce costs of late merging
8. Reduce cost of maintaining codebases

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answers. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

          Source code management techniques invariably include trade-offs. While branching early could be good, the costs for merging could add up. Trade-offs between maintaining multiple lines like development and maintenance lines can also be confusing to an extent. Optimistically thinking, maintaining a single line for both maintenance and development could be tempting. It would allow new changes / bug fixes from the maintenance team to become immediately visible in the development line thus incorporating all the bug fixes into the new development cycles. However, the cost of merging each time into the new development branch is an important criterion. What would happen if the new code being developed by the development branch is in conflict with a new bug fix? Who would re-work the code to get around the problem? Such trade-offs and many many more become important for efficient source code management.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Example =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches. 

         The following diagram is taken from the [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/how_base_populate.htm IBM Boulder site]. It is a snapshot of the ClearCase.
[[Image:Clearcase.gif|thumb|center|550px|alt=A snapshot of IBM Rational ClearCase|A snapshot of IBM Rational ClearCase]]
 The above diagram is a snapshot view of a shared file Prog.c which is in the clearcase. The circles show the different versions of the file, i.e. the number of circles are basically the number of times the file was checked out and checked back in. The dark circle means that the file has been currently checked out by someone called "user" as shown.

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

         Another widely used tool for source code management is Subversion - an open source initiative. Subversion has superseeded CVS as the versioning control system of choice since it includes important functionality like deleting and renaming directories which were absent in CVS. The users of SVN range from those working on very small classroom projects to mammoth ones like the ones in SUN Microsystems. SVN uses a relational database, BerkleyDB as the backend and works much faster than CVS. With space for adding metadata with each file and support for "all or nothing" commits, SVN is more stable and allows for better management of the codebase.

''The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= See also =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]

= References =
1. http://www.sunsource.net/scdocs/ddCVS 
2. http://www.codewalkers.com/c/a/Server-Administration/Source-Code-Version-Control-Solutions 
3. http://en.wikipedia.org/wiki/Revision_control

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-17T01:00:25Z

Hriyer: /* Example */

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify/work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

1. Allow simultaneous / parallel development of software
2. Integrate code changes from different teams / developers
3. Propagate bug fixes to future versions of the software
4. Isolate, coordinate and tidily separate work item units
5. Track and revert to older versions
6. Keep related projects in sync with one another
7. Reduce costs of late merging
8. Reduce cost of maintaining codebases

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answers. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

          Source code management techniques invariably include trade-offs. While branching early could be good, the costs for merging could add up. Trade-offs between maintaining multiple lines like development and maintenance lines can also be confusing to an extent. Optimistically thinking, maintaining a single line for both maintenance and development could be tempting. It would allow new changes / bug fixes from the maintenance team to become immediately visible in the development line thus incorporating all the bug fixes into the new development cycles. However, the cost of merging each time into the new development branch is an important criterion. What would happen if the new code being developed by the development branch is in conflict with a new bug fix? Who would re-work the code to get around the problem? Such trade-offs and many many more become important for efficient source code management.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Example =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches. 

         The following diagram is taken from the [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/how_base_populate.htm IBM Boulder site]. It is a snapshot of the ClearCase.
[[Image:Clearcase.gif|thumb|center|550px|alt=A snapshot of IBM Rational ClearCase|A snapshot of IBM Rational ClearCase]]
 The above diagram is a snapshot view of a shared file Prog.c which is in the clearcase. The circles show the different versions of the file \, i.e. the number of circles are basically the number of times the file was checked out and checked back in. The dark circle means that the file has been currently checked out by someone called "user" as shown.

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

         Another widely used tool for source code management is Subversion - an open source initiative. Subversion has superseeded CVS as the versioning control system of choice since it includes important functionality like deleting and renaming directories which were absent in CVS. The users of SVN range from those working on very small classroom projects to mammoth ones like the ones in SUN Microsystems. SVN uses a relational database, BerkleyDB as the backend and works much faster than CVS. With space for adding metadata with each file and support for "all or nothing" commits, SVN is more stable and allows for better management of the codebase.

''The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= See also =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]

= References =
1. http://www.sunsource.net/scdocs/ddCVS 
2. http://www.codewalkers.com/c/a/Server-Administration/Source-Code-Version-Control-Solutions 
3. http://en.wikipedia.org/wiki/Revision_control

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-17T00:52:56Z

Hriyer: /* Example */

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify/work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

1. Allow simultaneous / parallel development of software
2. Integrate code changes from different teams / developers
3. Propagate bug fixes to future versions of the software
4. Isolate, coordinate and tidily separate work item units
5. Track and revert to older versions
6. Keep related projects in sync with one another
7. Reduce costs of late merging
8. Reduce cost of maintaining codebases

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answers. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

          Source code management techniques invariably include trade-offs. While branching early could be good, the costs for merging could add up. Trade-offs between maintaining multiple lines like development and maintenance lines can also be confusing to an extent. Optimistically thinking, maintaining a single line for both maintenance and development could be tempting. It would allow new changes / bug fixes from the maintenance team to become immediately visible in the development line thus incorporating all the bug fixes into the new development cycles. However, the cost of merging each time into the new development branch is an important criterion. What would happen if the new code being developed by the development branch is in conflict with a new bug fix? Who would re-work the code to get around the problem? Such trade-offs and many many more become important for efficient source code management.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Example =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches. 

         The following diagram is taken from the boulder ibm site. It is a snapshot of the ClearCase.
[[Image:Clearcase.gif|thumb|center|550px|alt=A snapshot of IBM Rational ClearCase|A snapshot of IBM Rational ClearCase]]

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

         Another widely used tool for source code management is Subversion - an open source initiative. Subversion has superseeded CVS as the versioning control system of choice since it includes important functionality like deleting and renaming directories which were absent in CVS. The users of SVN range from those working on very small classroom projects to mammoth ones like the ones in SUN Microsystems. SVN uses a relational database, BerkleyDB as the backend and works much faster than CVS. With space for adding metadata with each file and support for "all or nothing" commits, SVN is more stable and allows for better management of the codebase.

''The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= See also =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]

= References =
1. http://www.sunsource.net/scdocs/ddCVS 
2. http://www.codewalkers.com/c/a/Server-Administration/Source-Code-Version-Control-Solutions 
3. http://en.wikipedia.org/wiki/Revision_control

File:Clearcase.gif

2009-09-17T00:51:09Z

Hriyer: This diagram is taken from the IBM Boulder website.

This diagram is taken from the IBM Boulder website.

File:Config spec ux.gif

2009-09-17T00:49:26Z

Hriyer:

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-17T00:46:10Z

Hriyer: /* Example */

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify/work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

1. Allow simultaneous / parallel development of software
2. Integrate code changes from different teams / developers
3. Propagate bug fixes to future versions of the software
4. Isolate, coordinate and tidily separate work item units
5. Track and revert to older versions
6. Keep related projects in sync with one another
7. Reduce costs of late merging
8. Reduce cost of maintaining codebases

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answers. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

          Source code management techniques invariably include trade-offs. While branching early could be good, the costs for merging could add up. Trade-offs between maintaining multiple lines like development and maintenance lines can also be confusing to an extent. Optimistically thinking, maintaining a single line for both maintenance and development could be tempting. It would allow new changes / bug fixes from the maintenance team to become immediately visible in the development line thus incorporating all the bug fixes into the new development cycles. However, the cost of merging each time into the new development branch is an important criterion. What would happen if the new code being developed by the development branch is in conflict with a new bug fix? Who would re-work the code to get around the problem? Such trade-offs and many many more become important for efficient source code management.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Example =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches. 

         The following diagram is taken from the boulder ibm site. It is a snapshot of the ClearCase.

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

''Note - This section describes IBM Rational ClearCase which has an open source redbook. It has been used here as an example just to explain the points better. There are other version control tools like '''SVN (SubVersion)''' which is also widely used and well known for the powerful features that it has. The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= See also =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]

= References =
1. http://www.sunsource.net/scdocs/ddCVS 
2. http://www.codewalkers.com/c/a/Server-Administration/Source-Code-Version-Control-Solutions 
3. http://en.wikipedia.org/wiki/Revision_control

CSC/ECE 517 Fall 2009/wiki1a 4 srhi4

2009-09-12T13:33:31Z

Hriyer:

Best Practices for Source Code Management with Version Control

----

= Introduction =

         Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many developers using a codebase who have to modify / work on the same code. The problem gets more complex when there are multiple teams that want to maintain different versions of the same basic codebase to add new features or fix bugs. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor.

The below diagram gives a quick overview of a source code management system managing multiple codebases
[[Image:Version_Control.jpeg|thumb|center|550px|alt=An example of version control|An example of version control]]

=Terminology =
• Repository -   Store house for files. Usually integrated with a database 
• Trunk -  This is the location where the source code can be found. It is at the root of the tree 
• Working set -   Downloaded copy of the codebase 
• Client -   Application that connects to the repository 
• Server -  The system that hosts the repository 
• Code Check-out -  Downloading a file or a set of files from the codebase to a workspace in order to run / modify the code
 • Code Check-in -  Uploading new / modified files to a codebase from a workspace
 • Branching -  A technique used to aid the concurrent development of software. Simply put, it allows for development of code simultaneously by creating multiple paths for development.A   branch is for a single logical change in the code
 • Codeline -  A codeline is similar to a branch but can support multiple logical changes to the code. Often, branch and codeline are used interchangeably
 • Merging -  Process of integrating the changes in the code with the codeline. For example, if A branches out from a codeline, development continues on the codeline. A would then have    to merge his / her changes with the codeline to keep the versioning most recent.

= Motivation for Source code management (SCM) =

         In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

— Allow simultaneous / parallel development of software.
— Integrate code changes from different teams / developers
— Propagate bug fixes to future versions of the software
— Isolate, coordinate and tidily separate work item units
— Track and revert to older versions
— Keep related projects in sync with one another

= Efficient Source Code Management (SCM) =

         There are a lot of challenges associated with Source Code Management(SCM) and there exists no standard way for doing SCM. When do you create new branches? When do you create new codelines? Who should be responsible for the branch? When do you merge code? How do you integrate code fixes with future releases? How do you keep track of multiple releases? These are questions that have no definite answer. Each project uses a different SCM technique depending on development cycles, releases, bug fixes and size of the project.

         Fortunately, there a few common guidelines and patterns that allow for efficient management of source code. The following section describes a few common guidelines in a typical scenario

1. Have a main line from which all the code is derived
The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,      Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken      from the main line to create parallel development lines.
2. Have parallel maintenance and development lines
Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and      these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
3. Have one codeline per release
Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous      version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned
4. Create policies for each codeline
Policies for a codeline define the stability and maintainability of a source code management system. The policy for the      development line could encourage late merges while those for bug fixes encourage merging often.
5. Merge early and often
As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.      Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent      merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep      all developers in sync with the product code..
6. Do not isolate too much,
Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The      cost for merging could become high.
7. Analyse and realign
The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it      has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging      codelines must be taken appropriately to sync up versions
8. Have an owner for every codeline
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline.      The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies,      decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

         The above guidelines help in improving manageability of the source code versions. It leads to increased coordination among developers, improves traceability, isolates changes, defines definite roles and responsibilities and reduces complexity.

= Example =
         IBM Rational ClearCase is a widely used version control software with a secure version management and easy to follow interface. It follows the guidelines of the best practices for source code management with version control. It centralizes the code, making it accessible to anyone in the software development team for a particular development. The ClearCase software supports parallel development and easy merging techniques. One of the most useful features of IBM Rational ClearCase is the views. It provides two different views, SnapShot and Dynamic. SnapShot views help to create local copy of the code from the codebase while the dynamic one is used when the codebase has to be modified (during merge). This feature helps to maintain the version of the code by allowing the developer to choose the level of access required for the code.

         As discussed in the [[#Efficient Source Code Management (SCM)|previous section]], the ClearCase maintains the main branch as the baseline and when a new project has to be derived from the main branch, a sub-branch is created which uses the baseline. This sub branch is used to build the project on. Every developer who is a part of the project team and for whom the project's main branch is accessible is given a unique id. Whenever a file is checked out by a developer, his name appears on the ClearCase view. The rest of the team can always see which file is being modified / looked at by which team members. This feature sometimes helps the developer to decide whether he should access the file to modify it now or not. Also, the ClearCase maintains every version of a file. Every time a file is checked out, a copy is maintained, so that when the modified version of the file is checked in, the view still has the old version of the file as well. One of the most powerful features of this tool is that every time a project is successfully completed and needs to be released to make it accessible to the other projects (branches of the main branch), it can be merged with the main branch which makes it accessible to all the other branches.

The details of the tool can be found in the IBM publication cited in the [[#References|References]] section of this page.

''Note - This section describes IBM Rational ClearCase which has an open source redbook. It has been used here as an example just to explain the points better. There are other version control tools like '''SVN (SubVersion)''' which is also widely used and well known for the powerful features that it has. The open source document of SVN can be found in the [[#References|References]] section of this page.''

= Conclusion =
         Source Code Management or Revision Control is a way of helping the software development for faster and efficient delivery and reduce the amount of rework or manual code maintenance. In a typical development team setup, it becomes a critical tool which is used by every team member. Hence it becomes very important for the version control systems to be accurate and user friendly. Not only does it need to be simple to understand, but it also has to be reliable and transparent without any conflicts.

= References =

•  For Beginners
       [http://www.perforce.com/perforce/papers/bestpractices.html The high level overview of SCM best practices].
 •  For Advanced Readers
       An [http://hillside.net/plop/plop98/final_submissions/P37.pdf in-depth view of source code management using different patterns]. It helps in organizing related lines of development into appropriately diverging and converging streams of source code changes.
       This is the [http://www.redbooks.ibm.com/abstracts/sg246399.html?Open&S_TACT=105AGX15&S_CMP=LP product RedBook] released by IBM on IBM Rational ClearCase. It explains the different features of their Version Control tool which follow the best practices discussed in this page.
 •  For Developers
       The [https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.books.cc_build_windows.doc/cc_build.htm IBM Rational ClearCase Version Control tool document] contains tutorials and examples that are easy to follow.
       Information about SVN and its free download versions by O'Reilly media can be found [http://svnbook.red-bean.com/ here]