Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-27T01:53:41Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the [http://en.wikipedia.org/wiki/Extreme_programming_practices extreme programming (XP) twelve core practices]. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently.

=== Best Definition ===
[http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

=== Good Example ===
A development team utilizes a source repository where all modified code is checked in as modules are written. On check-in, an automated build process executes and then notifies the team of the status of the build by email.

=== Bad Example ===
In my opinion, if you follow all the essential concepts of continuous integration as outlined above, you should not have a bad example. Even if one person is doing all the development, by checking in the code often and running automated builds against that code, problems and errors will surface quickly. Problems will arise when you have a rogue programmer who does not follow the integration rules or if you omit any of the essential concepts.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-27T01:50:41Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the [http://en.wikipedia.org/wiki/Extreme_programming_practices extreme programming (XP) twelve core practices]. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently.

=== Best Definition ===
[http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

=== Good Example ===
A development team utilizes a source repository where all modified code is checked in as modules are written. On check-in, an automated build process executes and then notifies the team of the status of the build by email.

=== Bad Example ===
In my opinion, if you follow all the essential concepts of continuous integration as outlined above, you should not have a bad example. Even if one person is doing all the development, by checking in the code often and running automated builds against that code, problems and errors will surface quickly.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-27T01:43:42Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the [http://en.wikipedia.org/wiki/Extreme_programming_practices extreme programming (XP) twelve core practices]. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently.

=== Best Definition ===
[http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-27T01:41:42Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently.

=== Best Definition ===
[http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T03:09:58Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T03:05:40Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the software development life cycle. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T03:03:35Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the software development life cycle. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T03:02:12Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Popular vs. Cumbersome ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Popular Vs. Cumbersome ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the software development life cycle. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

[[Image:CIDiagram.jpg]]

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T02:50:50Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Popular vs. Cumbersome ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.[[#References|14]]

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

=== Popular vs. Cumbersome ===
Continuous integration is most popular in the Agile and XP methodologies.

=== Good Example ===

=== Bad Example ===

[[Image:CIDiagram.jpg]]
= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

File:CIDiagram.jpg

2010-11-18T02:49:36Z

Srstarr: CI Diagram

CI Diagram

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T02:14:52Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition ===
When we talk about ownership, we are generally talking about the following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership. 

=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. 

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out. 

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. 

=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles. 

=== Popular vs. Cumbersome ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

==== Not Always the Most Efficient ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

==== Conflicts with Other Programming Practice Guidelines ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts. 

=== Good CCO Example===
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

=== Bad CCO Example===
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential concepts to Implement ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T01:44:17Z

Srstarr:

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change<\u> (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefits of Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temporarily is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacles between. To complete certain function system wide, you have to consult each of these development groups or individuals one by one. This slows down the development. 

=== Essential concepts to put CCO in practice===
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in code changes. 

*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the sub system. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practice which is coincidentally lying within these other principles. 

=== Where it is popular and where it is cumbersome ===
==== Limitation in programming for the large ====
In the real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company doing outsourcing or global development, almost no way to do pair programming and even simple oral report for code change will be possible[[#References|9]]. 

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practice is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practice considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

===The good CCO example===
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

===The bad CCO example===
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

=== Essential concepts to Put into Practice ===
CI requires the following concepts to implement:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of CI ===
There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|12, 13]]

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T00:50:24Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefits of Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temporarily is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacles between. To complete certain function system wide, you have to consult each of these development groups or individuals one by one. This slows down the development. 

=== Essential concepts to put CCO in practice===
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the sub system. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practice which is coincidentally lying within these other principles. 

=== Where it is popular and where it is cumbersome ===
==== Limitation in programming for the large ====
In the real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or global development, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practice is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practice considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

===The good CCO example===
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

===The bad CCO example===
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

CI requires the following:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of CI ===
There are many benefits to using continuous integration.

More to come...

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T00:49:39Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefits of Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temporarily is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacles between. To complete certain function system wide, you have to consult each of these development groups or individuals one by one. This slows down the development. 

=== Essential concepts to put CCO in practice===
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the sub system. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practice which is coincidentally lying within these other principles. 

=== Where it is popular and where it is cumbersome ===
==== Limitation in programming for the large ====
In the real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or global development, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practice is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practice considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

===The good CCO example===
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

===The bad CCO example===
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

== Continuous Integration ==
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

CI requires the following:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

== Benefits of CI ==
There are many benefits to using continuous integration.

More to come...

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-18T00:49:04Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefits of Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temporarily is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacles between. To complete certain function system wide, you have to consult each of these development groups or individuals one by one. This slows down the development. 

=== Essential concepts to put CCO in practice===
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the sub system. The knowledge of the code is truly shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practice principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practice which is coincidentally lying within these other principles. 

=== Where it is popular and where it is cumbersome ===
==== Limitation in programming for the large ====
In the real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or global development, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practice is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practice considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

===The good CCO example===
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

===The bad CCO example===
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

= Continuous Integration =
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

CI requires the following:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

== Benefits of CI ==
There are many benefits to using continuous integration.

More to come...

= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-17T04:13:51Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefit from Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temparury is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacle between. To complete certain function system wide, you have to concult each of these develop groups or individuals one by one. This slows down the development. 

== Essential concepts to put CCO in practice==
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practised that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effecitive CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this senario, each person has the experience of every part of the sub system. The knowledge of the code is truely shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practise principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practise which is coincidently lying within these other principles. 

== Where it is popular and where it is cumbersome ==
==== Limitation in programming for the large ====
In real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or gloable developing, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practise is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practise considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practise and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

==The good CCO example==
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

==The bad CCO example==
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

= Continuous Integration =
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|13]]

CI requires the following:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of CI ===
There are many benefits to using continuous integration.

More to come...

= Reference =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-17T04:12:21Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefit from Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temparury is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacle between. To complete certain function system wide, you have to concult each of these develop groups or individuals one by one. This slows down the development. 

== Essential concepts to put CCO in practice==
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practised that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effecitive CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this senario, each person has the experience of every part of the sub system. The knowledge of the code is truely shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practise principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practise which is coincidently lying within these other principles. 

== Where it is popular and where it is cumbersome ==
==== Limitation in programming for the large ====
In real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or gloable developing, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practise is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practise considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practise and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

==The good CCO example==
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

==The bad CCO example==
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

= Continuous Integration =
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|12, 13]]

CI requires the following:[[#References|12, 13]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of CI ===
There are many benefits to using continuous integration.

More to come...

= Reference =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-17T04:11:21Z

Srstarr:

(THIS PARAGRAPH IS ONLY FOR OUR USE. WILL BE DELETED BEFORE SUBMISSION.)
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

==Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|1]].

=== Best Definition===
When we talk about ownership, we are generally talking about following 5 factors [[#References|2]]
*Direct benefit from increases in value or generated income 
*Pride in appearance, achievement, and improvement 
*Responsibility for problems, flaws, or routine maintenance 
*Commitment to long-term involvement 
*Potential for successful resale (reuse) 
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|3]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership. 

===Benefit from Collective Code ownership ===
The most feasible benefit of collective code ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|4]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temparury is 100%. The truck factor is 0.5 if there are 2 person working on the same project. 

Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out. 

Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|3]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacle between. To complete certain function system wide, you have to concult each of these develop groups or individuals one by one. This slows down the development. 

== Essential concepts to put CCO in practice==
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practised that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effecitive CCO, pair programming and complete unit test before check in code changes. 

*Pair programming is essential for code knowledge sharing in XP. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this senario, each person has the experience of every part of the sub system. The knowledge of the code is truely shared by all the team members. [[#References|5, 6]] 

*Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|1, 3, 7]] 

As mentioned in many articles, except the two mention above, other practise principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browing tools to check old methods)[[#References|3, 8]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practise which is coincidently lying within these other principles. 

== Where it is popular and where it is cumbersome ==
==== Limitation in programming for the large ====
In real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or gloable developing, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|9]]. 

Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|2]] 

====Not always the most efficient ====
After all, XP practise is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. 

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|2, 10]] 

====Conflicts with other programming practice guide ====
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practise considered in OOP, as for a well designed system, one needs no knowledge of other part of code. 

This is the outcome of the root debate between agile practise and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part. 

==The good CCO example==
A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|6]] 

==The bad CCO example==
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|11]] 

= Continuous Integration =
Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. [http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|9, 10]]

CI requires the following:
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

=== Benefits of CI ===
There are many benefits to using continuous integration.

More to come...

= Reference =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://industrialxp.org/collectiveOwnership.html Collective Ownership, industrial XP]
#[http://jamesshore.com/Agile-Book/collective_code_ownership.html The Art of Agile Development: Collective Code Ownership]
#[http://www.xpexchange.net/english/intro/collectiveCodeOwnership.html Collective Code Ownership, XPexchange.net]
#[http://www.markhneedham.com/blog/2009/02/17/collective-code-ownership-some-thoughts/ Mark Needham, Collective Code Ownership: Some Thoughts]
#[http://www.extremeprogramming.org/rules/collective.html Collective Ownership, extremeprogramming.org]
#[http://www.c2.com/cgi/wiki?CollectiveCodeOwnership Collective Code Ownership, Cunningham & Cunningham, Inc.]
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-16T02:25:47Z

Srstarr:

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-16T02:17:34Z

Srstarr: Introduction and section breakouts

CSC/ECE 517 Fall 2010/ch6 6e sc

2010-11-15T02:00:28Z

Srstarr:

== Collective Ownership and Continuous Integration ==

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-15T01:42:21Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is one of the most common [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design patterns]. Its main idea is to define algorithms into familial groupings. The idea is to encapsulate each algorithm, then make those algorithms interchangeable. The Strategy design pattern allows each of the algorithms to differ autonomously from the various clients that use them.1 This allows those clients to be [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupled] to an interface not an implementation. At any time, the system can be expanded to allow multiple client implementations without changing the interface. As you can see in the diagram below, the client communicates with the interface, which then chooses the implementation based upon its strategy.4

[[Image:diagram.jpg]]

There are many real life examples of this design pattern in operation today. One that comes to mind would be opening a file. The interface is the Open command of some software. The implementations would be each of the various file types supported by the software. There would be an implementation for text file, an implementation for a comma delimited file, an implementation for a bitmap, and so on.

In the following sections we will compare how the Strategy pattern can be implemented in [http://en.wikipedia.org/wiki/Type_system static and dynamic languages], and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example:]

<pre>
// 1. Define the interface of the algorithm
interface Strategy { public void solve(); }

// 2. Bury implementation
abstract class TemplateMethod1 implements Strategy { // 3. Template Method
public void solve() {
start();
while (nextTry() && ! isSolution())
;
stop();
}
protected abstract void start();
protected abstract boolean nextTry();
protected abstract boolean isSolution();
protected abstract void stop();
}

class Impl1 extends TemplateMethod1 {
private int state = 1;
protected void start() {
System.out.print( "start " );
}
protected void stop() {
System.out.println( "stop" );
}
protected boolean nextTry() {
System.out.print( "nextTry-" + state++ + " " );
return true;
}
protected boolean isSolution() {
System.out.print( "isSolution-" + (state == 3) + " " );
return (state == 3);
}
}

// 2. Bury implementation
abstract class TemplateMethod2 implements Strategy { // 3. Template Method
public void solve() {
while (true) {
preProcess();
if (search()) break;
postProcess();
}
}
protected abstract void preProcess();
protected abstract boolean search();
protected abstract void postProcess();
}

class Impl2 extends TemplateMethod2 {
private int state = 1;
protected void preProcess() { System.out.print( "preProcess " ); }
protected void postProcess() { System.out.print( "postProcess " ); }
protected boolean search() {
System.out.print( "search-" + state++ + " " );
return state == 3 ? true : false;
}
}

// 4. Clients couple strictly to the interface
public class StrategyDemo {
public static void clientCode( Strategy strat ) {
strat.solve();
}
public static void main( String[] args ) {
Strategy[] algorithms = { new Impl1(), new Impl2() };
for (int i=0; i < algorithms.length; i++) {
clientCode( algorithms[i] );
}
}
}

</pre>

This code identifies an interface for the related algorithms as shown in section 1, defines classes to implement the individual algorithms as shown in section 2, and shows the client coupling to the interface as shown in section 4.4

This code snippet also makes use of the [http://en.wikipedia.org/wiki/Template_method_pattern Template method design pattern].

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example:]

<pre>
#include <iostream.h>
#include <fstream.h>
#include <string.h>

class Strategy;

class TestBed
{
public:
enum StrategyType
{
Dummy, Left, Right, Center
};
TestBed()
{
strategy_ = NULL;
}
void setStrategy(int type, int width);
void doIt();
private:
Strategy *strategy_;
};

class Strategy
{
public:
Strategy(int width): width_(width){}
void format()
{
char line[80], word[30];
ifstream inFile("quote.txt", ios::in);
line[0] = '\0';

inFile >> word;
strcat(line, word);
while (inFile >> word)
{
if (strlen(line) + strlen(word) + 1 > width_)
justify(line);
else
strcat(line, " ");
strcat(line, word);
}
justify(line);
}
protected:
int width_;
private:
virtual void justify(char *line) = 0;
};

class LeftStrategy: public Strategy
{
public:
LeftStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
cout << line << endl;
line[0] = '\0';
}
};

class RightStrategy: public Strategy
{
public:
RightStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
char buf[80];
int offset = width_ - strlen(line);
memset(buf, ' ', 80);
strcpy(&(buf[offset]), line);
cout << buf << endl;
line[0] = '\0';
}
};

class CenterStrategy: public Strategy
{
public:
CenterStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
char buf[80];
int offset = (width_ - strlen(line)) / 2;
memset(buf, ' ', 80);
strcpy(&(buf[offset]), line);
cout << buf << endl;
line[0] = '\0';
}
};

void TestBed::setStrategy(int type, int width)
{
delete strategy_;
if (type == Left)
strategy_ = new LeftStrategy(width);
else if (type == Right)
strategy_ = new RightStrategy(width);
else if (type == Center)
strategy_ = new CenterStrategy(width);
}

void TestBed::doIt()
{
strategy_->format();
}

int main()
{
TestBed test;
int answer, width;
cout << "Exit(0) Left(1) Right(2) Center(3): ";
cin >> answer;
while (answer)
{
cout << "Width: ";
cin >> width;
test.setStrategy(answer, width);
test.doIt();
cout << "Exit(0) Left(1) Right(2) Center(3): ";
cin >> answer;
}
return 0;
}

</pre>

The code above accepts input of how to justify the string and the width of the string. It then calls the appropriate class based upon the justification input.4

This code uses a base class as the interface and "subclasses" to implement the individual algorithms.

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example:]

<pre>
<?php

class StrategyContext {
private $strategy = NULL;
//bookList is not instantiated at construct time
public function __construct($strategy_ind_id) {
switch ($strategy_ind_id) {
case "C":
$this->strategy = new StrategyCaps();
break;
case "E":
$this->strategy = new StrategyExclaim();
break;
case "S":
$this->strategy = new StrategyStars();
break;
}
}
public function showBookTitle($book) {
return $this->strategy->showTitle($book);
}
}

interface StrategyInterface {
public function showTitle($book_in);
}

class StrategyCaps implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return strtoupper ($title);
}
}

class StrategyExclaim implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return Str_replace(' ','!',$title);
}
}

class StrategyStars implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return Str_replace(' ','*',$title);
}
}

class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle() . ' by ' . $this->getAuthor();
}
}

writeln('BEGIN TESTING STRATEGY PATTERN');
writeln('');

$book = new Book('PHP for Cats','Larry Truett');

$strategyContextC = new StrategyContext('C');
$strategyContextE = new StrategyContext('E');
$strategyContextS = new StrategyContext('S');

writeln('test 1 - show name context C');
writeln($strategyContextC->showBookTitle($book));
writeln('');

writeln('test 2 - show name context E');
writeln($strategyContextE->showBookTitle($book));
writeln('');

writeln('test 3 - show name context S');
writeln($strategyContextS->showBookTitle($book));
writeln('');

writeln('END TESTING STRATEGY PATTERN');

function writeln($line_in) {
echo $line_in." ";
}

?>
</pre>

This code replaces the spaces in a title with another character based upon the input received from the instantiation.

This code uses a context class that will identify the strategy to be used based upon a parameter given at instantiation.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>

As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

With both of these advantages, Ruby has the ability to utilize the Strategy Pattern quickly and cleanly. Ruby has a distinct advantage because of its built in features and because it is dynamically typed.

== References ==
(1) Freeman, Eric & Freeman, Elisabeth. Head First Design Patterns. O'Reilly, 2004.

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Olsen, Russ. Design Patterns in Ruby. Addison-Wesley Professional, 2007.

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-15T01:29:04Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is one of the most common [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design patterns]. Its main idea is to define algorithms into familial groupings. The idea is to encapsulate each algorithm, then make those algorithms interchangeable. The Strategy design pattern allows each of the algorithms to differ autonomously from the various clients that use them.1 This allows those clients to be [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupled] to an interface not an implementation. At any time, the system can be expanded to allow multiple client implementations without changing the interface. As you can see in the diagram below, the client communicates with the interface, which then chooses the implementation based upon its strategy.4

[[Image:diagram.jpg]]

There are many real life examples of this design pattern in operation today. One that comes to mind would be opening a file. The interface is the Open command of some software. The implementations would be each of the various file types supported by the software. There would be an implementation for text file, an implementation for a comma delimited file, an implementation for a bitmap, and so on.

In the following sections we will compare how the Strategy pattern can be implemented in [http://en.wikipedia.org/wiki/Type_system static and dynamic languages], and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example:]

<pre>
// 1. Define the interface of the algorithm
interface Strategy { public void solve(); }

// 2. Bury implementation
abstract class TemplateMethod1 implements Strategy { // 3. Template Method
public void solve() {
start();
while (nextTry() && ! isSolution())
;
stop();
}
protected abstract void start();
protected abstract boolean nextTry();
protected abstract boolean isSolution();
protected abstract void stop();
}

class Impl1 extends TemplateMethod1 {
private int state = 1;
protected void start() {
System.out.print( "start " );
}
protected void stop() {
System.out.println( "stop" );
}
protected boolean nextTry() {
System.out.print( "nextTry-" + state++ + " " );
return true;
}
protected boolean isSolution() {
System.out.print( "isSolution-" + (state == 3) + " " );
return (state == 3);
}
}

// 2. Bury implementation
abstract class TemplateMethod2 implements Strategy { // 3. Template Method
public void solve() {
while (true) {
preProcess();
if (search()) break;
postProcess();
}
}
protected abstract void preProcess();
protected abstract boolean search();
protected abstract void postProcess();
}

class Impl2 extends TemplateMethod2 {
private int state = 1;
protected void preProcess() { System.out.print( "preProcess " ); }
protected void postProcess() { System.out.print( "postProcess " ); }
protected boolean search() {
System.out.print( "search-" + state++ + " " );
return state == 3 ? true : false;
}
}

// 4. Clients couple strictly to the interface
public class StrategyDemo {
public static void clientCode( Strategy strat ) {
strat.solve();
}
public static void main( String[] args ) {
Strategy[] algorithms = { new Impl1(), new Impl2() };
for (int i=0; i < algorithms.length; i++) {
clientCode( algorithms[i] );
}
}
}

</pre>

This code identifies an interface for the related algorithms as shown in section 1, defines classes to implement the individual algorithms as shown in section 2, and shows the client coupling to the interface as shown in section 4.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example:]

<pre>
#include <iostream.h>
#include <fstream.h>
#include <string.h>

class Strategy;

class TestBed
{
public:
enum StrategyType
{
Dummy, Left, Right, Center
};
TestBed()
{
strategy_ = NULL;
}
void setStrategy(int type, int width);
void doIt();
private:
Strategy *strategy_;
};

class Strategy
{
public:
Strategy(int width): width_(width){}
void format()
{
char line[80], word[30];
ifstream inFile("quote.txt", ios::in);
line[0] = '\0';

inFile >> word;
strcat(line, word);
while (inFile >> word)
{
if (strlen(line) + strlen(word) + 1 > width_)
justify(line);
else
strcat(line, " ");
strcat(line, word);
}
justify(line);
}
protected:
int width_;
private:
virtual void justify(char *line) = 0;
};

class LeftStrategy: public Strategy
{
public:
LeftStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
cout << line << endl;
line[0] = '\0';
}
};

class RightStrategy: public Strategy
{
public:
RightStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
char buf[80];
int offset = width_ - strlen(line);
memset(buf, ' ', 80);
strcpy(&(buf[offset]), line);
cout << buf << endl;
line[0] = '\0';
}
};

class CenterStrategy: public Strategy
{
public:
CenterStrategy(int width): Strategy(width){}
private:
/* virtual */void justify(char *line)
{
char buf[80];
int offset = (width_ - strlen(line)) / 2;
memset(buf, ' ', 80);
strcpy(&(buf[offset]), line);
cout << buf << endl;
line[0] = '\0';
}
};

void TestBed::setStrategy(int type, int width)
{
delete strategy_;
if (type == Left)
strategy_ = new LeftStrategy(width);
else if (type == Right)
strategy_ = new RightStrategy(width);
else if (type == Center)
strategy_ = new CenterStrategy(width);
}

void TestBed::doIt()
{
strategy_->format();
}

int main()
{
TestBed test;
int answer, width;
cout << "Exit(0) Left(1) Right(2) Center(3): ";
cin >> answer;
while (answer)
{
cout << "Width: ";
cin >> width;
test.setStrategy(answer, width);
test.doIt();
cout << "Exit(0) Left(1) Right(2) Center(3): ";
cin >> answer;
}
return 0;
}

</pre>

The code above accepts input of how to justify the string and the width of the string. It then calls the appropriate class based upon the justification input.4

This code uses a base class as the interface and "subclasses" to implement the individual algorithms.

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example:]

<pre>
<?php

class StrategyContext {
private $strategy = NULL;
//bookList is not instantiated at construct time
public function __construct($strategy_ind_id) {
switch ($strategy_ind_id) {
case "C":
$this->strategy = new StrategyCaps();
break;
case "E":
$this->strategy = new StrategyExclaim();
break;
case "S":
$this->strategy = new StrategyStars();
break;
}
}
public function showBookTitle($book) {
return $this->strategy->showTitle($book);
}
}

interface StrategyInterface {
public function showTitle($book_in);
}

class StrategyCaps implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return strtoupper ($title);
}
}

class StrategyExclaim implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return Str_replace(' ','!',$title);
}
}

class StrategyStars implements StrategyInterface {
public function showTitle($book_in) {
$title = $book_in->getTitle();
$this->titleCount++;
return Str_replace(' ','*',$title);
}
}

class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle() . ' by ' . $this->getAuthor();
}
}

writeln('BEGIN TESTING STRATEGY PATTERN');
writeln('');

$book = new Book('PHP for Cats','Larry Truett');

$strategyContextC = new StrategyContext('C');
$strategyContextE = new StrategyContext('E');
$strategyContextS = new StrategyContext('S');

writeln('test 1 - show name context C');
writeln($strategyContextC->showBookTitle($book));
writeln('');

writeln('test 2 - show name context E');
writeln($strategyContextE->showBookTitle($book));
writeln('');

writeln('test 3 - show name context S');
writeln($strategyContextS->showBookTitle($book));
writeln('');

writeln('END TESTING STRATEGY PATTERN');

function writeln($line_in) {
echo $line_in." ";
}

?>
</pre>

This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

With both of these advantages, Ruby has the ability to utilize the Strategy Pattern quickly and cleanly. Ruby has a distinct advantage because of its built in features and because it is dynamically typed.

== References ==
(1) Freeman, Eric & Freeman, Elisabeth. Head First Design Patterns. O'Reilly, 2004.

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Olsen, Russ. Design Patterns in Ruby. Addison-Wesley Professional, 2007.

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-15T00:32:30Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is one of the most common design patterns. Its main idea is to define algorithms into familial groupings. The idea is to encapsulate each algorithm, then make those algorithms interchangeable. The Strategy design pattern allows each of the algorithms to differ autonomously from the various clients that use them.1 This allows those clients to be coupled to an interface not an implementation. At any time, the system can be expanded to allow multiple client implementations without changing the interface. As you can see in the diagram below, the client communicates with the interface, which then chooses the implementation based upon its strategy.4

[[Image:diagram.jpg]]

There are many real life examples of this design pattern being used. One that comes to mind would be opening a file. The interface is the Open command of some software. The implementations would be each of the various file types supported by the software. There would be an implementation for text file, an implementation for a comma delimited file, an implementation for a bitmap, and so on.

In the following sections we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

With both of these advantages, Ruby has the ability to utilize the Strategy Pattern quickly and cleanly. Ruby has a distinct advantage because of its built in features and because it is dynamically typed.

== References ==
(1) Freeman, Eric & Freeman, Elisabeth. Head First Design Patterns. O'Reilly, 2004.

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Olsen, Russ. Design Patterns in Ruby. Addison-Wesley Professional, 2007.

File:Diagram.jpg

2010-10-15T00:16:05Z

Srstarr:

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T02:09:39Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

With both of these advantages, Ruby has the ability to utilize the Strategy Pattern quickly and cleanly. Ruby has a distinct advantage because of its built in features and because it is dynamically typed.

== References ==
(1) Freeman, Eric & Freeman, Elisabeth. Head First Design Patterns. O'Reilly, 2004.

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Olsen, Russ. Design Patterns in Ruby. Addison-Wesley Professional, 2007.

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T02:01:32Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

With both of these advantages, Ruby has the ability to utilize the Strategy Pattern quickly and cleanly. Ruby has a distinct advantage because of its built in features and because it is dynamically typed.

== References ==
(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Design Patterns in Ruby Olsen

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T01:57:23Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold:

1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3

2. Ruby specific features such as duck typing and code blocks.

== References ==
(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Design Patterns in Ruby Olsen

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T01:56:38Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold.
1. Dynamic languages have a clear and distinct advantage over static languages in general. There are are not as many language limitations, a smaller amount of bookkeeping of objects and classes is needed, and design is not class restricted.3
2. Ruby specific features such as duck typing and code blocks.

== References ==
(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Design Patterns in Ruby Olsen

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T01:47:16Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

=== Ruby ===
<pre>
class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute
</pre>
As in the PHP example, this code uses a context class that will identify the strategy based upon an input parameter.

== What is Ruby's advantage? ==
Ruby's advantage with the Strategy pattern is two fold. Dynamic languages have a clear and distinct advantage over static languages with regards to the Strategy pattern. The ease of
== References ==
(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Design Patterns in Ruby Olsen

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T01:31:58Z

Srstarr:

== The Strategy Pattern ==
The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients that use them.1 Here we will compare how the Strategy pattern can be implemented in static and dynamic languages, and then explore if Ruby has an advantage with this design pattern because of its dynamic nature or because of the features of Ruby.

== Static Languages ==
The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc.2 The code in the hyperlinks below show various languages implementing the Strategy design patterns.

=== Java ===
[http://sourcemaking.com/design_patterns/strategy/java/1 Java Strategy design pattern example.]
This code identifies an interface for the related algorithms and shows the use of classes to implement the individual algorithms.4

=== C++ ===
[http://sourcemaking.com/design_patterns/strategy/cpp/1 C++ Strategy design pattern example.]
This code uses a base class as the interface and "subclasses" to implement the individual algorithms.4

=== PHP ===
[http://sourcemaking.com/design_patterns/strategy/php PHP Strategy design pattern example.]
This code uses a context class that will identify the strategy based upon an input parameter.4

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages.3 Each version of the algorithm is implemented as a different object which is then varied by supplying alternative strategy objects to the context.5

=== Ruby ===

class Context
def initialize(&strategy)
@strategy = strategy
end

def execute
@strategy.call
end
end

a = Context.new { puts 'One strategy for the context' }
a.execute

b = Context.new { puts 'Another strategy for the context' }
b.execute

c = Context.new { puts 'An additional strategy for the context' }
c.execute

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

(4) [http://sourcemaking.com/design_patterns/strategy Strategy Design Patterns]

(5) Design Patterns in Ruby Olsen

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-07T00:11:06Z

Srstarr:

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:51:43Z

Srstarr:

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:48:17Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc. (2)

===Java Example:===

===C++ Example:===

===Python Example:===

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages. (3)

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:46:30Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc. (2)

Java Example:
C++ Example:
Python Example:

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages. (3)

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:45:07Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc. (2)

== Dynamic Languages ==

The use of the Strategy design pattern in dynamic languages requires a variable that has a function as the value. Separate classes are not needed in dynamic languages. (3)

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

(3) [http://norvig.com/design-patterns/ppframe.htm Design Patterns in Dynamic Programming]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:41:14Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by extending classes, implementing interfaces, instantiating objects, invoking methods, etc. (2)

== Dynamic Languages ==

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:35:37Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by ''uses'' and ''inherits'' statements. (2)

== Dynamic Languages ==

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:33:18Z

Srstarr:

== The Strategy Pattern in Static and Dynamic Languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them. (1)

== Static Languages ==

The use of the Strategy design pattern in static languages requires the relations between classes and interfaces to be referenced by ''uses'' and ''inherits'' statements. (2)

== Dynamic Languages ==

== References ==

(1) Head First Design Patterns Freeman & Freeman

(2) [http://www.google.com/url?sa=t&source=web&cd=6&ved=0CDMQFjAF&url=http%3A%2F%2Fmb-pde.googlecode.com%2Ffiles%2FMasterThesis.pdf&rct=j&q=strategy%20design%20pattern%20static&ei=4MirTMuIJ8L78Aah8rSFBw&usg=AFQjCNHmD-Y7ojHKraML4IO3khrRrv-Ljw&sig2=AratIpJa6hit5xsOs6MJRQ OBJECTED-ORIENTED DESIGN PATTERN DETECTION USING
STATIC AND DYNAMIC ANALYSIS IN JAVA SOFTWARE]

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T01:30:09Z

Srstarr:

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T00:20:01Z

Srstarr:

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T00:17:04Z

Srstarr:

== The Strategy pattern in static and dynamic languages ==

The Strategy pattern is a common design pattern that defines algorithms into familial groupings. It encapsulates the individual algorithms and makes those algorithms interchangeable. Strategy allows the algorithms to differ autonomously from the clients who use them.

CSC/ECE 517 Fall 2010/ch3 3h ss

2010-10-06T00:06:15Z

Srstarr:

The Strategy pattern in static and dynamic languages

The text book, Head First Design Patterns, gives the best definition of the Strategy design pattern:

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:41:37Z

Srstarr: /* [http://www.gaiaflashframework.com/ Gaia] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit the following link: [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application. It uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial class myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term "front-end framework" means that no advanced knowledge of the Flash coding convention is required to use it allowing novice developers to use it. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages, the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below:[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:39:16Z

Srstarr: /* Scaffolding in .NET */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit the following link: [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application. It uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial class myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:38:58Z

Srstarr: /* [http://appfuse.org/display/APF/Home Appfuse] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit the following link: [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application. It uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial calss myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:37:00Z

Srstarr: /* [http://grails.org/ GRails] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit the following link: [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application that uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial calss myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:36:39Z

Srstarr: /* [http://grails.org/ GRails] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit the following link. [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application that uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial calss myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:36:04Z

Srstarr: /* [http://grails.org/ GRails] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy]. Groovy is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic Scaffolding, however, it does allow a developer to access the generated code if they want. If a developer tells GRails to install templates, the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below:[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding, you must install them. The installed templates would be stored in a new folder called 'templates' in the '/src' directory. An example would look like the code below:

<pre>
grails install-templates
</pre>

A popular tactic is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views, all the views will adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application that uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial calss myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]

CSC/ECE 517 Fall 2009/wiki1b 9 ss

2009-09-25T19:33:08Z

Srstarr: /* [http://cakephp.org/ CakePHP] */

'''Scaffolding in Web application frameworks

''Topic :We have discussed scaffolds for Ruby on Rails. The dynamic scaffold of Rails 1.x was replaced in Rails 2 by a generator of scaffolds for specific tables. Why did this change take place? What are the pros and cons of dynamic scaffolds? Many languages other than Ruby (Java, Python, and PHP, for example) provide Web application frameworks. Do any of these languages have the equivalent of scaffolding? If so, how does it compare to Rails?''

=The concept of Scaffolding=
Scaffolding in a [http://en.wikipedia.org/wiki/Web_application_framework web application framework] allows a software developer to create data-driven web applications quickly by automating [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] (Create, Read, Update, Delete) data operations. It achieves this by generating pages for the models within the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] architecture of the application. The pages have a working data form that can communicate with the database. This allows the developer to get an early look at the data presented in the application as a raw design from which they can build, modify, or rework the application in order to achieve a final product.

For the young developer, scaffolding has the advantage of quickly and easily building a functioning database-driven application. It also shows the developer what kind of methods and logic must be present within the application's controllers in order to produce a successful product. Scaffolding is a pragmatic tool to help young developers learn about creating web applications.

For the experienced developer, scaffolding gives them fast access to viewing and editing pages. With this, the experienced developer can customize the application through the use of metadata, templates, overriding the scaffold actions with custom ones, or they may use the quickly generated "build as a rough draft" option from which they will write their own structure.

Scaffolding has become very popular within the web development community and is showing up in several web frameworks. This is mostly because it increases work flow and allows web designers to spend more time designing instead of building interfaces to data. Scaffolding has become so wide spread that it can be found in such frameworks as Ruby on Rails, Python, PHP, Java, .NET, and Flash. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15], [http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 18]]

==Dynamic Scaffolding==
Dynamic Scaffolding generates the data interfaces at run time. With very little written code and no necessary knowledge of the underpinning data interfaces, a developer could get a web application up and running in very little time and with little effort by using Dynamic Scaffolding.

Young developers loved it because they could get a web application up and running without having to know the gory details, or having to know much about the framework they were working with. Many experienced developers also liked it because it allowed them to quickly prototype an application and wow clients as they saw the product come to life in a matter of minutes.

However, there were issues with Dynamic Scaffolding. Dynamic Scaffolding creates the data interfaces at run time causing the interfaces to be hidden from the developer. This left the developer clueless regarding the implementation. This lack of knowledge created problems. One problem was that the developer did not learn how to handle a typical CRUD scenario. Even if the developer did know how to build and customize their own CRUD scenario, the code created was hidden which maked it very difficult to access and work with. Because of these issues, many application development purists see Dynamic Scaffolding as doing more harm than good. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

==Scaffold Generation==
Scaffold Generation is another approach to scaffolding that generates the data interfaces for a developer, but it also gives them access to the generated code. This process is a bit less automated than Dynamic Scaffolding because changes to the model will not be automatically updated elsewhere in the application. What developers lose in automation, they gain in having a working site filled with examples from which to learn from. Developers also have immediate access to the data interfaces so they can make modifications quickly and efficiently. Furthermore, Scaffold Generation has the advantage of reducing the learning curve from a scaffold created controller to a custom one. Dynamic Scaffolding was easy for a developer to create a simple CRUD interface, but there was a large gap between that step and a custom interface to handle a specific job with specific needs. This gap is not nearly as wide now since the developer has access to the code created through Scaffold Generation and can use it as a foundation to branch out into custom interpretations of the simple CRUD scenario. [[http://en.wikipedia.org/wiki/Scaffold_(programming) 1], [http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://grails.org/Scaffolding 10], [http://www.djangobook.com/ 14], [http://guides.rubyonrails.org/ 15]]

=Scaffolding in Ruby on Rails=
Scaffolding became popular in [http://rubyonrails.org/ Ruby on Rails] and has since moved on to several other frameworks. The first generation of Ruby on Rails supported Dynamic Scaffolding. Scaffold Generation was also supported, however books, demos, and tutorials based on the first generation of Ruby on Rails largely omitted this fact. Beginning with the second generation of Ruby on Rails, Dynamic Scaffolding was no longer supported and Scaffolding Generation took center stage.

==[http://rubyonrails.org/ Ruby on Rails 1.x]==
In the first generation of Ruby on Rails a developer would generate a modal, then use a migrate file to create layout columns in the model's database table. After that they would generate a controller and add scaffolding. A scaffolding example in Ruby on Rails 1.x would look like the example below.[[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
scaffold :modelname
</pre>

==[http://rubyonrails.org/ Ruby on Rails 2.x]==
Ruby on Rails 2.x may have taken away Dynamic Scaffolding but it made Scaffold Generation simpler and involving less steps. This is due to being able to create your model, migrate file, and column layout all in one step. A scaffolding example in Ruby on Rails 2.x would look like the example below. [[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html 2], [http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion 3], [http://guides.rubyonrails.org/ 15]]
<pre>
./script/generate scaffold ModelName field1:type field2:type field3:type
</pre>

Once this script is executed the generator will build 14 files in your application, along with some folders, and edit one more.
Here’s a quick overview of what it creates:

*The model with the name you specified as ModelName
*Migration script to create the ModelNames table in your database
*A set of views for add, edit, display, and delete
*A view to control the overall look and feel of the views
*A cascading style sheet to make the scaffold views look better
*the ModalName controller
*Testing harness for the ModalName controller
*Helper functions
*Routing information
*Unit testing harness for ModalName
*Unit testing harness for ModalName helper

=Scaffolding in Python=
==[http://www.djangoproject.com/ Django]==
Django is a high-level [http://www.python.org/ python] web framework that was written in a newsroom to provide as much automation as possible for web developers under heavy deadlines. In Django you find scaffolding in what it calls the ''admin interface''. The idea behind the ''admin interface'' is that user pages differ greatly from client to client, but administrative tools largely remain the same and can be very repetitive to develop over and over; therefore it makes since to create a tool that will create these types of applications for us. By hooking to the metadata in your model, a fully functional web application can immediately be used as an administration tool to help manage your site. The way the ''admin interface'' is implemented is: for each model you want to associate with the admin interface, you mark that model. Then in your url.py file you add the url for the ''admin interface''. This would look like the example below:[[http://www.djangobook.com/ 14]]
<pre>
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
</pre>

This use of scaffolding in Django quickly and easily created an entire administration application.

This is accomplished mainly in two files. They are called scaffold.py and meta_scaffold.py. The scaffold.py file is used to generate a particular model. The meta_scaffold.py file is used to generate a template for all of the models.[[http://code.djangoproject.com/wiki/Scaffolding 17]]

=Scaffolding in PHP=
==[http://cakephp.org/ CakePHP]==
When Ruby on Rails began to take off, many frameworks decided to model themselves after what Ruby on Rails was doing. CakePHP is a web development framework written in [http://www.php.net/ PHP] that has incorporated many of the same concepts and design principles as Ruby on Rails. Because of this CakePHP prides itself on supporting scaffolding.[[http://en.wikipedia.org/wiki/CakePHP 7]]

CakePHP really has two types of scaffolding, one that it is actually called Scaffolding and another that is called Bake. What CakePHP calls Scaffolding is really like Dynamic Scaffolding. Here you have a model and then in your controller you declare a scaffold variable. CakePHP handles the rest behind the scenes. An example would look like the code below: [[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm 4], [http://book.cakephp.org/view/105/Scaffolding 5]]
<pre>
<?php

class MyController extends AppController {
var $scaffold;
}

?>
</pre>
The Bake console with CakePHP generates code for the models, views, and controllers. Bake works like Scaffold Generation and creates a fully functional structure a developer can learn from or build upon. An example would look like the code below:[[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ 6]]
<pre>
cake bake model [model name]
cake bake controller [controller name]
cake bake view [view name]
</pre>

=Scaffolding in Java=
==[http://grails.org/ GRails]==
GRails is an open source framework that integrates with a programming environment called [http://groovy.codehaus.org/ Groovy] which is based on the [http://www.java.com/en/ Java] platform. GRails supports Dynamic scaffolding however it does allow a developer to access the generated code if they want it. If a developer tells GRails to install templates then the current scaffold code will be created in a template file that can be modified to fit specific needs. GRails supports other Java technologies such as Spring and Hibernate. An example snippet of scaffoldng in GRails would look like the example below.[[http://en.wikipedia.org/wiki/Grails_(framework) 9], [http://grails.org/Scaffolding 10]]
<pre>
class myController{
def scaffold=true
}
</pre>

In order to edit the templates generated by the Dynamic Scaffolding you must install them. The installed templates would be put in a new folder called 'templates' in the '/src' directory. An example would look like the example below.

<pre>
grails install-templates
</pre>

A popular tactic to use is to generate the templates of the scaffolding before letting the scaffold create the views. This will allow the developer to edit the templates to meet the layout requirements of the project. That way, when the scaffold generates the views they all adhere to those layout requirements without having to modify each one. [[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates 16]]

For a short video tutorial on scaffolding in GRails please visit [[http://www.youtube.com/watch?v=LWoCfTyWG_E 19]]

==[http://appfuse.org/display/APF/Home Appfuse]==
Appfuse is an open source project and application that uses open source tools built on the java platform to help a developer build web applications quickly. Appfuse is not actually a framework. Appfuse is more of a tool for code generation that can be used with other Java web frameworks. It can be integrated into other open source technolgies such as Spring, Hibernate, and Struts.[[http://en.wikipedia.org/wiki/AppFuse 8]]

=Scaffolding in .NET=
[http://www.microsoft.com/NET/ .NET] is a Microsoft framework that can be used to develop applications on machines running Microsoft software. In .NET Microsoft includes scaffolding as part of a broader structure it calls Dynamic Data. Dynamic Data uses LINQ to SQL for it's data access from which it builds corresponding controllers and views. Dynamic Data was originally part of a project called Blinq but that project was terminated and Dynamic Data became a part of .NET in its 3.5 extensions package. An example of setting up a scaffold in .NET would look like the example below.[[http://www.infoq.com/news/2007/12/aspnet-dynamic-data 11]]
<pre>
ScaffoldTable(true)
public partial calss myClass{
}
</pre>

=Scaffolding in Flash=
==[http://www.gaiaflashframework.com/ Gaia]==
Gaia is an open source front-end framework for the [http://www.adobe.com/products/flash/ Flash] programming environment. The term front-end framework is meant to mean that no advanced knowledge of the Flash coding convention is required in order to get up and running and can be used by novice developers. The fact that Gaia prides itself on requiring little to no code to get going is nothing new compared to other frameworks, however, what makes Gaia interesting is its support for [http://en.wikipedia.org/wiki/Search_engine_optimization SEO] (Search Engine Optimization) scaffolding. The way that SEO scaffolding works is it generates the XHTML pages for every SEO enabled page on the site. For each one of these XHTML pages the copy for the developer's flash is included. This one file per page relationship makes it much easier for the developer to optimize his/her site for search engines. The scaffolding information is stored in a file called Scaffold.as. An example of accessing the scaffolding from a page would look like the example below.[[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ 12]]
<pre>
new Scaffold(this);
</pre>

=Resources=
1.[http://en.wikipedia.org/wiki/Scaffold_(programming) http://en.wikipedia.org/wiki/Scaffold_(programming)] 
2.[http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html] 
3.[http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion] 
4.[http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm http://www.developer.com/lang/php/article.php/3636686/Scaffolding-with-CakePHP---Managing-Your-Fantasy-Football-Team.htm] 
5.[http://book.cakephp.org/view/105/Scaffolding http://book.cakephp.org/view/105/Scaffolding] 
6.[http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/ http://www.webdevelopment2.com/cakephp-bake-baking-models-controllers-views-cakephp-12/] 
7.[http://en.wikipedia.org/wiki/CakePHP http://en.wikipedia.org/wiki/CakePHP] 
8.[http://en.wikipedia.org/wiki/AppFuse http://en.wikipedia.org/wiki/AppFuse] 
9.[http://en.wikipedia.org/wiki/Grails_(framework) http://en.wikipedia.org/wiki/Grails_(framework)] 
10.[http://grails.org/Scaffolding http://grails.org/Scaffolding] 
11.[http://www.infoq.com/news/2007/12/aspnet-dynamic-data http://www.infoq.com/news/2007/12/aspnet-dynamic-data] 
12.[http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/ http://www.stevensacks.net/2008/04/16/gaia-flash-framework-21-seo-scaffolding/] 
13.[http://en.wikipedia.org/wiki/Search_engine_optimization http://en.wikipedia.org/wiki/Search_engine_optimization] 
14.[http://www.djangobook.com/ http://www.djangobook.com/] 
15.[http://guides.rubyonrails.org/ http://guides.rubyonrails.org/] 
16.[http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates http://docs.codehaus.org/display/GRAILS/Artifact+and+Scaffolding+Templates] 
17.[http://code.djangoproject.com/wiki/Scaffolding http://code.djangoproject.com/wiki/Scaffolding]

=Literature=
18.[http://www.amazon.com/gp/product/1934356166/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=097669400X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0JWFRF8AMQGA8Z1X0YQ3 Agile Web Development with Rails]

=Media=
19.[http://www.youtube.com/watch?v=LWoCfTyWG_E http://www.youtube.com/watch?v=LWoCfTyWG_E]

=Official Sites=
[http://rubyonrails.org/ http://rubyonrails.org/] 
[http://www.djangoproject.com/ http://www.djangoproject.com/] 
[http://cakephp.org/ http://cakephp.org/] 
[http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/Home] 
[http://grails.org/ http://grails.org/] 
[http://www.microsoft.com/NET/ http://www.microsoft.com/NET/] 
[http://www.gaiaflashframework.com/ http://www.gaiaflashframework.com/] 
[http://groovy.codehaus.org/ http://groovy.codehaus.org/]