Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013

2013-10-08T01:26:43Z

Okdalvi:

* [[ CSC/ECE 517 Fall 2012/ch1 1w23 ph ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 nn]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w21 w]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w01 aj]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w24 nv]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w29 rkld]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w25 aras]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 ps]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w19 rj]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w18 bs]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w17 pk]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w22 ss]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w12 vn]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w14 st]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w08 cc]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w10 ga ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w26 as ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w27 ma ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w13 aa ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w11 sv ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w07 d ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w20 gq ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w03 ss ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w28 nm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w02 pp ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w6 zs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w04 y ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w05 st ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w09 hs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w32 av ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w48 x ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 av]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w46 ka]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w33 aa]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w35 sa ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w39 as ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w31 vm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 sm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w44 s ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w47 ka ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w34 fs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w40 ao ]]

CSC/ECE 517 Fall 2013

2013-10-08T01:26:31Z

Okdalvi:

File:Extreme1.png

2013-10-08T01:22:52Z

Okdalvi:

CSC/ECE 517 Fall 2013/ch1 1w40 ao

2013-10-08T01:22:38Z

Okdalvi: /* Practices in XP */

== '''Xtreme Programming''' ==

Extreme Programming XP is a Software Development Methodology which is a type of agile software development[]. It has proved to be very successful at many companies of
different sizes and scale. Frequent releases in short development cycles is one of the major fundamentals of extreme programming similar to agile software development.
The intention behind this is improved productivity and quality of software and higher customer satisfaction. [[File:Extreme_Programming.png|right]]

Pair programming, extensive code reviews and test driven development are some other important features of Extreme programming. It intends to create a flat management structure again like normal agile software development.

The name derives from the fact that normal principles of software engineering practices are taken to a level that would be categorized as extreme when it was put into use.

Criticism around agile revolves around drawbacks such as unstable requirements and the lack of documentation as far as the design specification is concerned.

== '''History''' ==
In 1990,there was a revolution in the domain of Software Development.Firstly,was the rise of object-oriented programming over procedural programming and secondly,was the rise of the internet.These factors demanded rapidly-changing requirements and shorter product life-cycles.The old software development strategies had begun to go obsolete.
Extreme Programming was created by Kent Beck when he was asked to work on the Chrysler Comprehensive Compensation System (C3) payroll project.
Chrysler Comprehensive Compensation System was a project started to determine as to what can be the best way to make use of object technologies with Smalltalk as the language and Gemstone as the data access layer.The motive was to use the payroll systems at Chrysler as the object of research.Kent Beck was a prominent practitioner of Smalltalk and hence, was chosen to lead this project.However,when he undertook the project,he noticed several shortcommings in the current development process.He formulated this and made use of this to make a new development methodology with the help of his colleague Ward Cunnigham.
The exact words of Kent Beck on starting with the development of a new methodology are as follows:[1]

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line.I thought,"Damn the torpedoes, at least this will make a good article,"and asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else."

Ron Jeffries was also asked to join the project by Beck.He acted as a coach to the project team.

Various sources for information about this new developing methodology published by the team itself are as follows:
* The original Wiki by Cunnigham [http://en.wikipedia.org/wiki/WikiWikiWeb WikiWikiWeb]
* The XP website itself: "http://www.extremeprogramming.org" circa 1999.
* Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6).

== '''Current State''' ==

XP gained fame in 1990s and early 2000s.It was being incorporated into fields and environments much different to what it was made for initially.
The original practices that were in existence in those days required a lot of high discipline and hence,where considered too rigid.As a result,they were often deprecated or left unfinished at times.
A less rigid schedule like XP,allows complex features to be fully developed.XP,unlike other agile development methodologies,is still evolving and incorporating changes.

== '''Concept''' ==

[[File:Extreme.gif|right]]
''' Goals'''

The fundamental goal behind extreme programming is to produce higher quality software in shorter periods of time. These goals can be achieved by improving the overall productivity of the development team.

Having multiple short term sprints facilitates this goal. That way the requirements are always unstable, and keep changing according to feedback received from the customer/s. The entire idea behind this is that change is good and should be embraced and not discouraged.

''' Activities'''

XP describes four activities that are done during the software development process. coding, testing, listening and designing.
-Coding
Code is considered to be the most important aspect of the software product. Code is clear, concise and is not subject to multiple interpretations. If there is some aspect of the programming problem that the programmer finds it difficult to explain to his teammates in words, he/she may simply use code to illustrate their point. Other programmers may make comments on this code or quite simply write code that suggests improvements over the current code.

''' Testing'''

Testing is a very important feature of Extreme Programming. In traditional software development, testing was an activity that was put off till the very end. However, extreme programming encourages the principles of test driven development. It is believed that some testing eliminates some flaws and a lot of testing eliminates many flaws. There are two major types of tests
Unit tests are used to test whether some features of the code are working as was the intention. The programmer should incorporate as many automated tests as they can which they think might break the code. When all tests get completed then the coding is complete. Every piece of code must be tested before moving on to the next feature.
Acceptance tests verify that the requirements have been understood correctly by the programmers.

''' Listening'''

Programmers should be mindful of what the customer wants the system to be like and the business logic when they are writing code. The flow of communication must be smooth and if there are any questions they must be resolved by careful discussions.

''' Designing'''

If you would like to keep things simple, you would think that good coding, testing and listening would result in a good software product. This doesn’t quite work that way though. Laying out a good design is one of the essential requirements of a good software product. Even though you might think that you can get by without good design in the initial stages of software development, there will come a time when one will get stuck. Such a state can be avoided by good software design which is well laid out and is logically sound.
stuck. Such a state can be avoided by good software design which is well laid out and is logically sound.

== '''Values of XP''' ==

Extreme Programming first had only four values till 1999 which are Communication,Simplicity,Feedback and Courage.The fifth value came in the second edition of Extreme programming Explained.

'''Communication'''

Communication was always handled through documentation in older software development practices.Extreme programming takes this to the extreme levels and incorporates simple designs,collaboration of users as well as programmers,frequent meetings and verbal communication and feedback from the customers as well as peers.

'''Simplicity'''

The simplicity in Extreme programming is that it stresses on starting with on the simplest task and reaching short term goals and then taking them to the extreme level as we progress.
The aim is to focus on the tasks that should be completed in short-term and get done with it.The flaw here is that somethings that are ignored as of today may require more efforts as regards to design as well as implementation changes in the future.The design should be simple as well as the code so that everyone in the team can understand it and work with it.

'''Feedback'''

Feedback is a quintessential part of the Extreme programming methodology.
Feedback can be from a person or can be from a system.
e.g.Feedback received on account of writing tests like Unit tests,Performance tests,etc.On the other-hand,feedback from the customer can be obtain after doing functional tests by the customer/testers.This should be planned every one or two weeks.
Feedback from the team is another form of feedback where the team as a whole reviews each others work and collaborates with the changing requirements of the customers.
Kent Beck says the following about feedback "Optimism is an occupational hazard of programming. Feedback is the treatment."

'''Courage'''

Courage is a required thing in Extreme Programming and lies in the fact that code can be refactored as per the requirements.This requires a lot of review for the existing system and making changes to accommodate changes that will come in future.
Another form of courage can be deciding on when to throw obsolete code away insoite of efforts neeeded to create the code in the first place.
Corage is the second word for persistence.A coder should be persistent till he gets his problem solved completely.

'''Respect'''

Respect should be given to one0self i.e. self-respect as well as to all members of the team.One should respect his/her own work by looking to create the highest quality and seeking best solution by making use of refactoring as much as possible.
Nobody should be ignored instead should be encouraged and respected.

== '''Rules of XP''' ==

Every software development methodology comes bundled with some rules.In the case of XP,we have rules which were laid down by Don Wells in 1999.There were total 29 rules.XP rules were also proposed by Ken Auer.He proposed two categories 1)Rules of Engagement:Define the environment 2)Rules of play:Define the activities.

'''Principles'''

Principles are a step further than values.Principles are supposed to be more practical and applicable to real situations.

'''Feedback'''

Feedback is something that we get from the reviewers after something is delivered.Feedbacks should be done frequently and periodically.Feedbacks are a means for the customer to give his/her two cents while the development is in it's iterative stages.It can act as a way to give a direction to the development process of the software as per the customization of the customer.The testing perspective for feedback is Unit testing.In which for each iterative development,unit tests are performed to check how the system reacts.A suite can act as a feedback mechanism giving quick feedbacks to every iterative development and the developer can understand that his changes cannot be incorporated and need to be further developed.

'''Assuming simplicity'''

Assume that the problem at hand is simple and can be handled easily.Make iterative releases and involve the customer.This way,the customer will be involved and have more control.

'''Embracing change'''

Take account of the changes that are needed to be incorporated and make strategies to do so efficiently.

== '''Practices in XP''' ==
[[File:Extreme1.png|right]]

Extreme programming has 12 practices which are grouped into four areas:

Fine scale feedback
* Pair programming
* Planning game
* Test-driven development
* Whole team
Continuous process
* Continuous integration
* Refactoring or design improvement
* Small releases
Shared understanding
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
Programmer welfare
* Sustainable pace

Coding
The customer is always available
The unit test must be coded first
Optimization must be done last

Testing
All code must have unit test
Code must pass unit tests before continuing
Acceptance tests should be run often and tests must be published

== '''Controversial aspects''' ==
XP has been a topic of great discussion. People who support this programming methodology claim that extreme programming adds flexibility to the process and reduces costs associated with formal meetings. However, critics claim that extreme programming can lead to rework, which may cause costs to increase from what was previously agreed upon.

Change-control boards are a sign that there might be some conflicts in project objectives and constraints between multiple users. Also, XP’s expedited method depends on the programmers being able to assume a unified client viewpoint to avoid time getting wasted in documentation and the programmer can focus on writing good code.

Other controversial aspects include:

* Requirements are expressed incrementally, so there is no requirement specification at the start.
* Software developers are required to work in pairs and this causes problems when there are two opposite personalities who don’t like to work with each other.
* Requirements are expressed as acceptance tests rather than documents.
* There is just one customer representative which can cause a single point of failure

'''Scalability'''

The problem with XP is that it traditionally works with teams of 20 or so people which is not exactly tailored to every big organization. One way to overcome this is to work in smaller teams within the organization.

== '''References''' ==
1.Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns-
[http://www.cis.upenn.edu/~matuszek/cit591-2003/Lectures/49-design-patterns.ppt]

2."Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-[http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,66192,00.html]

== '''Further Reading''' ==

== '''External Links''' ==

* [http://www.extremeprogramming.org A gentle introduction]
* [[WikiWikiWeb:ExtremeProgramming|Extreme Programming]]

CSC/ECE 517 Fall 2013/ch1 1w40 ao

2013-10-08T01:20:08Z

Okdalvi: /* Concept */

== '''Xtreme Programming''' ==

Extreme Programming XP is a Software Development Methodology which is a type of agile software development[]. It has proved to be very successful at many companies of
different sizes and scale. Frequent releases in short development cycles is one of the major fundamentals of extreme programming similar to agile software development.
The intention behind this is improved productivity and quality of software and higher customer satisfaction. [[File:Extreme_Programming.png|right]]

Pair programming, extensive code reviews and test driven development are some other important features of Extreme programming. It intends to create a flat management structure again like normal agile software development.

The name derives from the fact that normal principles of software engineering practices are taken to a level that would be categorized as extreme when it was put into use.

Criticism around agile revolves around drawbacks such as unstable requirements and the lack of documentation as far as the design specification is concerned.

== '''History''' ==
In 1990,there was a revolution in the domain of Software Development.Firstly,was the rise of object-oriented programming over procedural programming and secondly,was the rise of the internet.These factors demanded rapidly-changing requirements and shorter product life-cycles.The old software development strategies had begun to go obsolete.
Extreme Programming was created by Kent Beck when he was asked to work on the Chrysler Comprehensive Compensation System (C3) payroll project.
Chrysler Comprehensive Compensation System was a project started to determine as to what can be the best way to make use of object technologies with Smalltalk as the language and Gemstone as the data access layer.The motive was to use the payroll systems at Chrysler as the object of research.Kent Beck was a prominent practitioner of Smalltalk and hence, was chosen to lead this project.However,when he undertook the project,he noticed several shortcommings in the current development process.He formulated this and made use of this to make a new development methodology with the help of his colleague Ward Cunnigham.
The exact words of Kent Beck on starting with the development of a new methodology are as follows:[1]

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line.I thought,"Damn the torpedoes, at least this will make a good article,"and asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else."

Ron Jeffries was also asked to join the project by Beck.He acted as a coach to the project team.

Various sources for information about this new developing methodology published by the team itself are as follows:
* The original Wiki by Cunnigham [http://en.wikipedia.org/wiki/WikiWikiWeb WikiWikiWeb]
* The XP website itself: "http://www.extremeprogramming.org" circa 1999.
* Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6).

== '''Current State''' ==

XP gained fame in 1990s and early 2000s.It was being incorporated into fields and environments much different to what it was made for initially.
The original practices that were in existence in those days required a lot of high discipline and hence,where considered too rigid.As a result,they were often deprecated or left unfinished at times.
A less rigid schedule like XP,allows complex features to be fully developed.XP,unlike other agile development methodologies,is still evolving and incorporating changes.

== '''Concept''' ==

[[File:Extreme.gif|right]]
''' Goals'''

The fundamental goal behind extreme programming is to produce higher quality software in shorter periods of time. These goals can be achieved by improving the overall productivity of the development team.

Having multiple short term sprints facilitates this goal. That way the requirements are always unstable, and keep changing according to feedback received from the customer/s. The entire idea behind this is that change is good and should be embraced and not discouraged.

''' Activities'''

XP describes four activities that are done during the software development process. coding, testing, listening and designing.
-Coding
Code is considered to be the most important aspect of the software product. Code is clear, concise and is not subject to multiple interpretations. If there is some aspect of the programming problem that the programmer finds it difficult to explain to his teammates in words, he/she may simply use code to illustrate their point. Other programmers may make comments on this code or quite simply write code that suggests improvements over the current code.

''' Testing'''

Testing is a very important feature of Extreme Programming. In traditional software development, testing was an activity that was put off till the very end. However, extreme programming encourages the principles of test driven development. It is believed that some testing eliminates some flaws and a lot of testing eliminates many flaws. There are two major types of tests
Unit tests are used to test whether some features of the code are working as was the intention. The programmer should incorporate as many automated tests as they can which they think might break the code. When all tests get completed then the coding is complete. Every piece of code must be tested before moving on to the next feature.
Acceptance tests verify that the requirements have been understood correctly by the programmers.

''' Listening'''

Programmers should be mindful of what the customer wants the system to be like and the business logic when they are writing code. The flow of communication must be smooth and if there are any questions they must be resolved by careful discussions.

''' Designing'''

If you would like to keep things simple, you would think that good coding, testing and listening would result in a good software product. This doesn’t quite work that way though. Laying out a good design is one of the essential requirements of a good software product. Even though you might think that you can get by without good design in the initial stages of software development, there will come a time when one will get stuck. Such a state can be avoided by good software design which is well laid out and is logically sound.
stuck. Such a state can be avoided by good software design which is well laid out and is logically sound.

== '''Values of XP''' ==

Extreme Programming first had only four values till 1999 which are Communication,Simplicity,Feedback and Courage.The fifth value came in the second edition of Extreme programming Explained.

'''Communication'''

Communication was always handled through documentation in older software development practices.Extreme programming takes this to the extreme levels and incorporates simple designs,collaboration of users as well as programmers,frequent meetings and verbal communication and feedback from the customers as well as peers.

'''Simplicity'''

The simplicity in Extreme programming is that it stresses on starting with on the simplest task and reaching short term goals and then taking them to the extreme level as we progress.
The aim is to focus on the tasks that should be completed in short-term and get done with it.The flaw here is that somethings that are ignored as of today may require more efforts as regards to design as well as implementation changes in the future.The design should be simple as well as the code so that everyone in the team can understand it and work with it.

'''Feedback'''

Feedback is a quintessential part of the Extreme programming methodology.
Feedback can be from a person or can be from a system.
e.g.Feedback received on account of writing tests like Unit tests,Performance tests,etc.On the other-hand,feedback from the customer can be obtain after doing functional tests by the customer/testers.This should be planned every one or two weeks.
Feedback from the team is another form of feedback where the team as a whole reviews each others work and collaborates with the changing requirements of the customers.
Kent Beck says the following about feedback "Optimism is an occupational hazard of programming. Feedback is the treatment."

'''Courage'''

Courage is a required thing in Extreme Programming and lies in the fact that code can be refactored as per the requirements.This requires a lot of review for the existing system and making changes to accommodate changes that will come in future.
Another form of courage can be deciding on when to throw obsolete code away insoite of efforts neeeded to create the code in the first place.
Corage is the second word for persistence.A coder should be persistent till he gets his problem solved completely.

'''Respect'''

Respect should be given to one0self i.e. self-respect as well as to all members of the team.One should respect his/her own work by looking to create the highest quality and seeking best solution by making use of refactoring as much as possible.
Nobody should be ignored instead should be encouraged and respected.

== '''Rules of XP''' ==

Every software development methodology comes bundled with some rules.In the case of XP,we have rules which were laid down by Don Wells in 1999.There were total 29 rules.XP rules were also proposed by Ken Auer.He proposed two categories 1)Rules of Engagement:Define the environment 2)Rules of play:Define the activities.

'''Principles'''

Principles are a step further than values.Principles are supposed to be more practical and applicable to real situations.

'''Feedback'''

Feedback is something that we get from the reviewers after something is delivered.Feedbacks should be done frequently and periodically.Feedbacks are a means for the customer to give his/her two cents while the development is in it's iterative stages.It can act as a way to give a direction to the development process of the software as per the customization of the customer.The testing perspective for feedback is Unit testing.In which for each iterative development,unit tests are performed to check how the system reacts.A suite can act as a feedback mechanism giving quick feedbacks to every iterative development and the developer can understand that his changes cannot be incorporated and need to be further developed.

'''Assuming simplicity'''

Assume that the problem at hand is simple and can be handled easily.Make iterative releases and involve the customer.This way,the customer will be involved and have more control.

'''Embracing change'''

Take account of the changes that are needed to be incorporated and make strategies to do so efficiently.

== '''Practices in XP''' ==

Extreme programming has 12 practices which are grouped into four areas:

Fine scale feedback
* Pair programming
* Planning game
* Test-driven development
* Whole team
Continuous process
* Continuous integration
* Refactoring or design improvement
* Small releases
Shared understanding
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
Programmer welfare
* Sustainable pace

Coding
The customer is always available
The unit test must be coded first
Optimization must be done last

Testing
All code must have unit test
Code must pass unit tests before continuing
Acceptance tests should be run often and tests must be published

== '''Controversial aspects''' ==
XP has been a topic of great discussion. People who support this programming methodology claim that extreme programming adds flexibility to the process and reduces costs associated with formal meetings. However, critics claim that extreme programming can lead to rework, which may cause costs to increase from what was previously agreed upon.

Change-control boards are a sign that there might be some conflicts in project objectives and constraints between multiple users. Also, XP’s expedited method depends on the programmers being able to assume a unified client viewpoint to avoid time getting wasted in documentation and the programmer can focus on writing good code.

Other controversial aspects include:

* Requirements are expressed incrementally, so there is no requirement specification at the start.
* Software developers are required to work in pairs and this causes problems when there are two opposite personalities who don’t like to work with each other.
* Requirements are expressed as acceptance tests rather than documents.
* There is just one customer representative which can cause a single point of failure

'''Scalability'''

The problem with XP is that it traditionally works with teams of 20 or so people which is not exactly tailored to every big organization. One way to overcome this is to work in smaller teams within the organization.

== '''References''' ==

1."Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-[http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,66192,00.html]

== '''Further Reading''' ==

== '''External Links''' ==

* [http://www.extremeprogramming.org A gentle introduction]
* [[WikiWikiWeb:ExtremeProgramming|Extreme Programming]]

== '''Extreme Programming''' ==

== '''History''' ==
This type of programming methodology was created by Kent Beck when he was working on a project entitled "Chrys;er Comprehensive Compensation System(C3).When he became the project leader in March 1996,he revamped the methodology for this project and also wrote a book on the same entitled "Extreme Programming Explained" in October 1999.The individual practices enlisted in Extreme programming have been around for a long time on their own.Extreme programming just combines all these practices and takes them to the extreme levels.
series went through various aspects attending XP and its practices. The series included a book that was critical of the practices.

== '''Current State''' ==

== '''Concept''' ==

CSC/XtremeProgramming

2013-10-04T22:56:18Z

Okdalvi: moved CSC/XtremeProgramming to CSC//ECE 517 Fall 2013/ch1 1w40 ao

#REDIRECT [[CSC//ECE 517 Fall 2013/ch1 1w40 ao]]

CSC//ECE 517 Fall 2013/ch1 1w40 ao

2013-10-04T22:56:18Z

Okdalvi: moved CSC/XtremeProgramming to CSC//ECE 517 Fall 2013/ch1 1w40 ao