Www.gsaadvantage.gov
AUTHORIZED FEDERAL ACQUISITION SERVICE
INFORMATION TECHNOLOGY SCHEDULE PRICE LIST
GENERAL PURPOSE COMMERCIAL INFORMATION TECHNOLOGY
EQUIPMENT, SOFTWARE AND SERVICES
Contract Number: GS-35F-163DA
SPECIAL ITEM NUMBER 132-50 - TRAINING COURSES (FPDS Code U012)
Clean Coders, LLC
1520 Artaius Pkwy #7038
Libertyville, IL 60048
P: 224-577-5642
Contract Administrator: Tadd Linderman
Email: tadd@
Business Size / Status: Small Business
Period Covered by Contract: February 1, 2016 – February 1, 2021
Pricelist current through Modification #A491, dated February 18, 2016
General Services Administration
Federal Supply Service
For more information on ordering from Federal Supply Schedules click on the FSS Schedules button at fss..
On-line access to contract ordering information, terms and conditions, up-to-date pricing, and the option to create an electronic delivery order are available through GSA Advantage! ®, a menu-driven database system. The INTERNET address GSA Advantage! ® is: .
TABLE OF CONTENTS
BASIC CONTACT INFORMATION……………………………………………………………………………...3
TERMS AND CONDITIONS APPLICABLE TO INFORMATION TECHNOLOGY (IT) PROFESSIONAL SERVICES (SPECIAL ITEM NUMBER 132-50) …………………………………...…………………...………5
GSA SCHEDULE PRICING………………………………………………………………………………………13
TRAINING DESCRIPTIONS ……………………………………………………………...............................14 - 44
1a. Table of awarded special item number(s):
|Contract # |SIN |Description |
|GS-35F-163DA |132-50 |Training Courses |
1b. Lowest priced model: See GSA Pricelist
1c. Professional Services Descriptions; Refer to attachment GSA Schedule Price list
2. Maximum order: $25,000
3. Minimum order: $133.30
4. Geographic coverage (delivery area): Domestic
5. Point(s) of production (city, county, and State or foreign country): US
6. Discount from list prices or statement of net price: 10-100=5.50%, 101-200=9%, 201-400=12.50%, 401-600=16%, 601-1000=23%, 1001-10,000=26.50%, 10,001-20,000=27.90%
7. Quantity discounts: 10-100=5.50%, 101-200=9%, 201-400=12.50%, 401-600=16%, 601-1000=23%, 1001-10,000=26.50%, 10,001-20,000=27.90%
8. Prompt payment terms: None
9a Notification that Government purchase cards are accepted at or below the micro-purchase threshold.
9b Notification whether Government purchase cards are accepted or not accepted above the micro-purchase threshold.
10. Foreign items (list items by country of origin): None
11a. Time of delivery: As negotiated between Contractor and Ordering Agency
11b. Expedited Delivery: As negotiated between Contractor and Ordering Agency
11c. Overnight and 2-day delivery: As negotiated between Contractor and Ordering Agency
11d. Urgent Requirements: As negotiated between Contractor and Ordering Agency
12. F.O.B. point: Destination
13a. Ordering address: 1520 Artaius Pkwy #7038, Libertyville, IL 60048
13b. Ordering procedures: For supplies and services, the ordering procedures, information on Blanket Purchase Agreements (BPA’s) are found in Federal Acquisition Regulation (FAR) 8.405-3.
14. Payment address: 1520 Artaius Pkwy #7038, Libertyville, IL 60048
15. Warranty provision: Contractors standard commercial warranty
16. Export packing charges: N/A
17. Terms and conditions of Government purchase card acceptance: Contact Contractor
18. Terms and conditions of rental, maintenance, and repair: Contact Contractor
19. Terms and conditions of installation: Contact Contractor
20. Terms and conditions of repair parts indicating date of parts price lists and any discounts from list prices: Contact Contractor
20a. Terms and conditions for any other services: Contact Contractor
21. List of service and distribution points: Contact Contractor
22. List of participating dealers: N/A
23. Preventive maintenance: Contact Contractor
24a. Special attributes such as environmental attributes: N/A
24b. Section 508 compliance information is available at:
25. Data Universal Number System (DUNS) number: 079120113
26. Contractor is registered in System for Award Management (SAM) database. CAGE code: 7EHA6
TERMS AND CONDITIONS APPLICABLE TO PURCHASE OF
TRAINING COURSES FOR GENERAL PURPOSE COMMERCIAL
INFORMATION TECHNOLOGY EQUIPMENT AND SOFTWARE
(SPECIAL ITEM NUMBER 132-50)
1. SCOPE
a. The Contractor shall provide training courses normally available to commercial customers, which will permit ordering activity users to make full, efficient use of general purpose commercial IT products. Training is restricted to training courses for those products within the scope of this solicitation.
b. The Contractor shall provide training at the Contractor's facility and/or at the ordering activity's location, as agreed to by the Contractor and the ordering activity.
2. ORDER
Written orders, EDI orders (GSA Advantage! and FACNET), credit card orders, and orders placed under blanket purchase agreements (BPAs) shall be the basis for the purchase of training courses in accordance with the terms of this contract. Orders shall include the student's name, course title, course date and time, and contracted dollar amount of the course.
3. TIME OF DELIVERY
The Contractor shall conduct training on the date (time, day, month, and year) agreed to by the Contractor and the ordering activity.
4. CANCELLATION AND RESCHEDULING
a. The ordering activity will notify the Contractor at least seventy-two (72) hours before the scheduled training date, if a student will be unable to attend. The Contractor will then permit the ordering activity to either cancel the order or reschedule the training at no additional charge. In the event the training class is rescheduled, the ordering activity will modify its original training order to specify the time and date of the rescheduled training class.
b. In the event the ordering activity fails to cancel or reschedule a training course within the time frame specified in paragraph a, above, the ordering activity will be liable for the contracted dollar amount of the training course. The Contractor agrees to permit the ordering activity to reschedule a student who fails to attend a training class within ninety (90) days from the original course date, at no additional charge.
c. The ordering activity reserves the right to substitute one student for another up to the first day of class.
d. In the event the Contractor is unable to conduct training on the date agreed to by the Contractor and the ordering activity, the Contractor must notify the ordering activity at least seventy-two (72) hours before the scheduled training date.
5. FOLLOW-UP SUPPORT
The Contractor agrees to provide each student with unlimited telephone support or online support for a period of one (1) year from the completion of the training course. During this period, the student may contact the Contractor's instructors for refresher assistance and answers to related course curriculum questions.
6. PRICE FOR TRAINING
The price that the ordering activity will be charged will be the ordering activity training price in effect at the time of order placement, or the ordering activity price in effect at the time the training course is conducted, whichever is less.
7. INVOICES AND PAYMENT
Invoices for training shall be submitted by the Contractor after ordering activity completion of the training course. Charges for training must be paid in arrears (31 U.S.C. 3324). PROMPT PAYMENT DISCOUNT, IF APPLICABLE, SHALL BE SHOWN ON THE INVOICE.
8. FORMAT AND CONTENT OF TRAINING
a. The Contractor shall provide written materials (i.e., manuals, handbooks, texts, etc.) normally provided with course offerings. Such documentation will become the property of the student upon completion of the training class.
b. **If applicable** For hands-on training courses, there must be a one-to-one assignment of IT equipment to students.
c. The Contractor shall provide each student with a Certificate of Training at the completion of each training course.
d. The Contractor shall provide the following information for each training course offered:
(1) The course title and a brief description of the course content, to include the course format (e.g., lecture, discussion, hands-on training);
(2) The length of the course;
(3) Mandatory and desirable prerequisites for student enrollment;
(4) The minimum and maximum number of students per class;
(5) The locations where the course is offered;
(6) Class schedules; and
(7) Price (per student, per class (if applicable)).
e. For those courses conducted at the ordering activity’s location, instructor travel charges (if applicable), including mileage and daily living expenses (e.g., per diem charges) are governed by Pub. L. 99-234 and FAR Part 31.205-46, and are reimbursable by the ordering activity on orders placed under the Multiple Award Schedule, as applicable, in effect on the date(s) the travel is performed. Contractors cannot use GSA city pair contracts. The Industrial Funding Fee does NOT apply to travel and per diem charges.
f. For Online Training Courses, a copy of all training material must be available for electronic download by the students.
9. “NO CHARGE” TRAINING
The Contractor shall describe any training provided with equipment and/or software provided under this contract, free of charge, in the space provided below.
Clean Code → Episode 1, Clean Code (Remake!) THIS COURSE IS FREE AND AUTOMATICALLY IS LOADED INTO EVERYONES ACCOUNT
Details
By Uncle Bob,Feb 27, 2011,54 min
Description
Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video!
This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style.
Indeed, this is the remake of the original, brought up to the standards we've learned after two and a half years!
So hold on to your hats and prepare yourself for a radically different kind of educational experience.
In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code?
So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest.
And besides, you don't really want to miss the astronomy lectures, do you?
b. To avoid an organizational or financial conflict of interest and to avoid prejudicing the best interests of the ordering activity, ordering activities may place restrictions on the Contractors, its affiliates, chief executives, directors, subsidiaries and subcontractors at any tier when placing orders against schedule contracts. Such restrictions shall be consistent with FAR 9.505 and shall be designed to avoid, neutralize, or mitigate organizational conflicts of interest that might otherwise exist in situations related to individual orders placed against the schedule contract. Examples of situations, which may require restrictions, are provided at FAR
9.508.
11. INVOICES
The Contractor, upon completion of the work ordered, shall submit invoices for IT Professional services. Progress payments may be authorized by the ordering activity on individual orders if appropriate. Progress payments shall be based upon completion of defined milestones or interim products. Invoices shall be submitted monthly for recurring services performed during the preceding month.
12. PAYMENTS
For firm-fixed price orders the ordering activity shall pay the Contractor, upon submission of proper invoices or vouchers, the prices stipulated in this contract for service rendered and accepted. Progress payments shall be made only when authorized by the order. For time-and-materials orders, the Payments under
Time-and-Materials and Labor-Hour Contracts at FAR 52.212-4 (MAR 2009) (ALTERNATE I – OCT
2008) (DEVIATION I – FEB 2007) applies to time-and-materials orders placed under this contract. For
labor-hour orders, the Payment under Time-and-Materials and Labor-Hour Contracts at FAR 52.212-4 (MAR 2009) (ALTERNATE I – OCT 2008) (DEVIATION I – FEB 2007) applies to labor-hour orders placed under this contract. 52.216-31(Feb 2007) Time-and-Materials/Labor-Hour Proposal Requirements— Commercial Item Acquisition As prescribed in 16.601(e)(3), insert the following provision:
(a) The Government contemplates award of a Time-and-Materials or Labor-Hour type of contract resulting from this solicitation.
(b) The offeror must specify fixed hourly rates in its offer that include wages, overhead, general and administrative expenses, and profit. The offeror must specify whether the fixed hourly rate for each labor category applies to labor performed by—
(1) The offeror;
(2) Subcontractors; and/or
(3) Divisions, subsidiaries, or affiliates of the offeror under a common control.
13. RESUMES
Resumes shall be provided to the GSA Contracting Officer or the user ordering activity upon request.
14. INCIDENTAL SUPPORT COSTS
Incidental support costs are available outside the scope of this contract. The costs will be negotiated separately with the ordering activity in accordance with the guidelines set forth in the FAR.
15. APPROVAL OF SUBCONTRACTS
The ordering activity may require that the Contractor receive, from the ordering activity's Contracting Officer, written consent before placing any subcontract for furnishing any of the work called for in a task order.
16. DESCRIPTION OF IT PROFESSIONAL SERVICES AND PRICING
Please see GSA price list for labor category descriptions and rates.
|BEST VALUE |
|BLANKET PURCHASE AGREEMENT |
|FEDERAL SUPPLY SCHEDULE |
(Insert Customer Name)
In the spirit of the Federal Acquisition Streamlining Act, (ordering activity) and Clean Coders, LLC enter into a cooperative agreement to further reduce the administrative costs of acquiring commercial items from the General Services Administration (GSA) Federal Supply Schedule Contract GS-35F-163DA.
Federal Supply Schedule contract BPAs eliminate contracting and open market costs such as: search for sources; the development of technical documents, solicitations and the evaluation of offers. Teaming Arrangements are permitted with Federal Supply Schedule Contractors in accordance with Federal Acquisition Regulation (FAR) 9.6.
This BPA will further decrease costs, reduce paperwork, and save time by eliminating the need for repetitive, individual purchases from the schedule contract. The end result is to create a purchasing mechanism for the ordering activity that works better and costs less.
Signatures
_____________________________ ____________________________
Ordering Activity Date Contractor Date
BPA NUMBER_____________
(CUSTOMER NAME)
BLANKET PURCHASE AGREEMENT
Pursuant to GSA Federal Supply Schedule Contract Number GS-35F-163DA, Blanket Purchase Agreements, the Contractor agrees to the following terms of a Blanket Purchase Agreement (BPA) EXCLUSIVELY WITH (ordering activity): (1) The following contract items can be ordered under this BPA. All orders placed against this BPA are subject to the terms and conditions of the contract, except as noted below:
MODEL NUMBER/PART NUMBER *SPECIAL BPA DISCOUNT/PRICE
________________________________ _______________________________
________________________________ _______________________________
________________________________ _______________________________
(2) Delivery:
DESTINATION DELIVERY SCHEDULES / DATES
________________________________ _______________________________
________________________________ _______________________________
________________________________ _______________________________
(3) The ordering activity estimates, but does not guarantee, that the volume of purchases through this agreement will be _________________________.
(4) This BPA does not obligate any funds.
(5) This BPA expires on _________________ or at the end of the contract period, whichever is earlier.
(6) The following office(s) is hereby authorized to place orders under this BPA:
OFFICE POINT OF CONTACT ________________________________ _______________________________
________________________________ _______________________________
________________________________ _______________________________
(7) Orders will be placed against this BPA via Electronic Data Interchange (EDI), FAX, or paper.
(8) Unless otherwise agreed to, all deliveries under this BPA must be accompanied by delivery tickets or sales slips that must contain the following information as a minimum:
(a) Name of Contractor;
(b) Contract Number;
(c) BPA Number;
(d) Model Number or National Stock Number (NSN);
(e) Purchase Order Number;
(f) Date of Purchase;
(g) Quantity, Unit Price, and Extension of Each Item (unit prices and extensions need not be shown when incompatible with the use of automated systems; provided, that the invoice is itemized to show the information); and
(h) Date of Shipment.
(9) The requirements of a proper invoice are specified in the Federal Supply Schedule contract. Invoices will be submitted to the address specified within the purchase order transmission issued against this BPA.
(10) The terms and conditions included in this BPA apply to all purchases made pursuant to it. In the event of an inconsistency between the provisions of this BPA and the Contractor’s invoice, the provisions of this BPA will take precedence. *******************************************************************************************
|BASIC GUIDELINES FOR USING |
|“CONTRACTOR TEAM ARRANGMENTS” |
Federal Supply Schedule Contractors may use “Contractor Team Arrangements” (see FAR 9.6) to provide solutions when responding to a ordering activity requirements.
These Team Arrangements can be included under a Blanket Purchase Agreement (BPA). BPAs are permitted under all Federal Supply Schedule contracts.
Orders under a Team Arrangement are subject to terms and conditions or the Federal Supply Schedule Contract.
Participation in a Team Arrangement is limited to Federal Supply Schedule Contractors.
Customers should refer to FAR 9.6 for specific details on Team Arrangements.
Here is a general outline on how it works:
• The customer identifies their requirements.
• Federal Supply Schedule Contractors may individually meet the customers needs, or –
• Federal Supply Schedule Contractors may individually submit a Schedules “Team Solution” to meet the customer’s requirement.
• Customers make a best value selection.
|GSA SCHEDULE PRICE LIST – SIN 132-50 |
|SIN |MFR PART NO |PRODUCT NAME |PRODUCT DESCRIPTION |UOI |GSA |
| | | | | |PRICE |
How to start a Clean Coders account:
1. Create an account with Clean Coders by contacting tadd@
2. Purchase a bank of licenses to share among any number of end users of an organization.
3. Account Administrator invites team members to join and authorizes what courses to take
4. Bank of license is depleted as a course is viewed
*Note- 1 License = 1 end user + 1 training course from our catalogue. License do not expire and do not have a renewal fee.
Clean Coders Catalogue of Training Course Descriptions
Clean Code: Fundamentals
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 1, Clean Code (Remake!) THIS COURSE IS FREE AND AUTOMATICALLY IS LOADED INTO EVERYONES ACCOUNT
Details
By Uncle Bob,Feb 27, 2011,54 min
Description
Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video!
This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style.
Indeed, this is the remake of the original, brought up to the standards we've learned after two and a half years!
So hold on to your hats and prepare yourself for a radically different kind of educational experience.
In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code?
So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest.
And besides, you don't really want to miss the astronomy lectures, do you?
Clean Code → Episode 2, Names++
Details
By Uncle Bob,Feb 27, 2011,44 min
Description
Episode II -- Names
So, you think this is just going to be like the second chapter of the Clean Code book? Think again! This is a completely different take on the topic. Oh the goal is the same, certainly. But there are things covered in this video that were never mentioned in the book. And even those things that are similar are covered in a very different way. So even if you've read Clean Code fifty times over, this episode will give you more to think about.
In this 40+ minute episode Uncle Bob will take you from the Earth to the Sun and then into the bowels of the Earth. You'll visit idyllic countrysides, urban back alleys, graffiti laden East London side streets, and even the Wild West as you explore the principles of names in your code.
Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline. He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other. Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.
From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.
Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why you don't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.
Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.
So don't wait. If you want to be a clean coder. If you want to improve your skill and discipline, then hit the button and watch this episode now. Clean Code Episode II -- Names, is about to begin…
Clean Code → Episode 3, Functions
Details
By Uncle Bob,Apr 1, 2011,59 min
After you watch this episode, checkout these screencasts:
• Clean Code Episode 3 - Screencast 2: primeGenerator
• Clean Code Episode 3 - Screencast I: testableHtml
• Clean Code Episode 3 - Screencast 3: Video Store
Description
How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size?
Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know?
Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule?
The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions.
In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing.
This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totaling about twenty minutes. So it's a wild ride.
On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.
Clean Code → Episode 4, Function Structure
Details
By Uncle Bob,May 21, 2011,94 min
After you watch this episode, checkout these screencasts:
• Clean Code Episode 4 - Screencast I: Stack
Description
In this episode Uncle Bob enlists the help of the craftsmen at 8th Light Inc to expose how functions should be organized and structured. Topics range from error handling, and the debate over checked exceptions, to functional programming and the discipline of Command-Query separation. He talks about the OO and Structured paradigms, and discusses why the Law of Demeter is so important. He tells you why switch statements should be avoided, and what to do about them when you can't avoid them.
In fact, it's really quite startling where this lesson goes. You wouldn't think that the simple topic of function structure would lead you into high level discussions of architecture and team management, but they do. So you'll learn about the importance of independent develop-ability, and the some of the theory behind modular and plugin structure and partitioning. Did you know, for example, that the main program should be a plugin to the rest of the application?
What's the trick to avoiding a morass of XML files that feed the insatiable maw of your dependency injector? How can you avoid temporal couplings by "passing a block". What number and types of arguments should a function have? And is Structured Programming really still important nowadays?
So set aside 90 minutes and get ready for a while ride through some lectures and code. Function Structure is about to begin!
Clean Code → Episode 5, Form
Details
By Uncle Bob,Jul 14, 2011,75 min
After you watch this episode, checkout these screencasts:
• Clean Code Episode 5 - Screencast I: Lychrel
Description
This episode starts with the form of individual lines of code and ends up describing the form of the partitions at the highest levels of a system. That's a huge range, and it all begins with comments.
Comments are lies.
OK, that's a pretty controversial statement. But in this episode Uncle Bob attacks much of the old conventional wisdom about comments, formatting, coding standards, white space, indenting, switch statements, classes, data structures, and even system design and the separation of applications, databases, and views.
How many comments should you write? When should you write them? Should you enforce comments with tools like checkstyle? You can bet that UB has a lot to say on these topics.
How big should a source file be? How long should a line of code be? How should you use whitespace within your source code. How should you indent? Should you have a coding standard? UB's answers to these questions will surprise you.
What is the difference between a class and a data structure? What things do they protect you from, and what risks do they expose you to? How can you use data structures and classes to cover those risks and create solid designs.
Did you know that databases don't contain business objects? What do they contain? How should you design the boundary between your application and the database. For that matter how should you design the boundary between your application and the views? Indeed, what about boundaries in general?
From the form of individual lines of code, to the form of the boundaries that criss-cross the system, this episode will load your brain with a lot of new ideas to think about.
So get ready... FORM is about to begin!
Clean Code → Episode 6, TDD - Part 1
Details
By Uncle Bob,Sep 1, 2011,61 min
Description
There was just so much Uncle Bob had to say about TDD that he needed two episodes to say it. This is part one.
This episode begins an epic debate between the vanguard of craftsmanship and the mirror forces of traditional development. The gauntlet is thrown when Uncle Bob describes the real reason that code rots over time, and how that rot can be prevented and even reversed by a comprehensive suite of tests created through the discipline of Test Driven Development.
The mirror forces rise to the challenge and demand answers to the traditional and entrenched objections that have, for years, convinced them that TDD is a discredited and vacuous doctrine. Uncle Bob begs for time to describe what TDD is and how it works before he tackles the objections directly. The mirror forces are restive, but agree.
After a brief time-out, during which Uncle Bob describes the origins of the Moon; Uncle Bob dives into the argument for tests. He talks about why code really rots, and what happens when it rots too much. He talks about the failure of big cleanup projects, and how development teams are often dominated by the fear of changing the code. "Code Rots", he says, "because we are afraid to clean it."
Then Uncle Bob addresses that fear, and makes the point that if you had a suite of tests that covered every line of code in the system and ran quickly, you would not be afraid to make changes. You would not be afraid to clean the code.
Next Uncle Bob dives into the three laws of Test Driven Development -- the central discipline of TDD. He describes each of those laws in turn, and answers the brief objections raised by the impatient mirror forces. Then Uncle Bob describes the benefits of following those three laws; the reduced debug time, the production of reliable low level documentation, the decoupling of the design, and the elimination of the fear of change.
Finally, in the face of rising skepticism and impatience from the mirror forces, Uncle Bob finds a messy function in an open source project that is covered by tests, and proceeds to clean it fearlessly. The results are impressive, and the mirror forces hold back their ire to await the promised debate.
Here endeth the lesson; or at least part one.
Clean Code → Episode 6, TDD - Part 2
Details
By Uncle Bob,Sep 1, 2011,75 min
Description
Part 2 of Episode 6 -- Test Driven Development.
This episode begins as the mirror forces of traditional software development lose patience with Uncle Bob's incessant preaching and demand a practical demonstration before allowing the debate to continue. Uncle Bob complies by walking through the famous example of The Bowling Game (You don't want to miss this!). In this example, Uncle Bob uses the three laws and the Red-Green-Refactor cycle to implement the algorithm for scoring games of 10-pin bowling.
The demonstration begins with a quick description of the scoring rules. Then Uncle Bob leads us on a quick UML design session. Then TDD commences, and we watch Uncle Bob create the algorithm by applying the three laws of TDD in the Red-Green-Refactor cycle. Finally, the end result is compared to the initial design.
Having satisfied, and impressed, the mirror forces with that demonstration, the debate begins in earnest. Point by point the mirror forces raise one objection after another:
• "TDD is slow"
• "Managers won't allow it"
• "Refactoring is rework"
• "Who tests the tests?"
• "Tests are fragile"
• "Tests can prove correctness"
• "TDD is too dogmatic"
• "Tests don't have to come first."
• "What about Legacy Code"
• "How do you test GUIs"
• "How do you test databases."
• "Programmers aren't testers."
• "TDD is too hard"
One by one, Uncle Bob answers those objections. Sometimes the mirror forces agree. Sometimes they are skeptical. But they cannot deny the logic. In the end... Well, you'll just have to see.
After the debate ends, Uncle Bob describes why TDD should be considered a minimum requirement for professional behavior. He likens the discipline of TDD to the discipline of double-entry bookkeeping used by accountants. He makes the point that developers should expect QA to find nothing. He concludes with the story of how Doctors learned to wash their hands.
The lesson ends with a summary, and a promise for the next episode: "Use cases and High Level Design”.
Clean Code → Episode 7, Architecture, Use Cases, and High Level Design
Details
By Uncle Bob,Oct 20, 2011,82 min
Description
This episode destroys the common myths about software architecture, and reveals what software architecture is really all about. Software architecture is not about databases, web servers, dependency injection, Rails, Hibernate, JSF, Struts, Spring, or any other framework or tool. Architecture is about intent.
When you see a web-based accounting system, the architecture of that system should scream accounting at you. The fact that it's a web based system should be unnoticeable. After all, the web is just a delivery mechanism; and we don't want our system architecture polluted with delivery mechanisms, databases, and other low level tools and concerns.
In this episode, Uncle Bob re-introduces the concepts first espoused by Ivar Jacobson, in his epic book: "Object-Oriented Software Engineering". Uncle Bob describes what use cases are, and how to make sure they are delivery agnostic. He shows you how to partition the system with use cases as the central organizing principle, and the primary abstraction. He also demonstrates how to isolate the system architecture from the rest of the system.
Uncle Bob illustrates how to use Jacobson's three primary architectural classes: Entities, Interactors, and Boundaries. He describes how this triplet helps to decouple the system architecture from the delivery mechanism, leaving the web to dangle off the side of the architecture like an appendix. Uncle Bob goes on to show how Model-View-Controller and Model-View-Presenter are used on the delivery side of the system.
Then Uncle Bob hammers the point home with a case-study taken from his classic book: Agile Software Development: Principles, Patterns, and Practices. After an informative briefing from the stakeholder, he performs a use-case analysis, and a high level object-oriented design to create the architectural superstructure on which the rest of the application will be built.
Finally, Uncle Bob tells us how to avoid a Big Ball of Mud, and tells us who the architects really are.
So raise your seat backs, and put your tray tables in the upright and locked position, because this episode of Clean Code is about to take off, and we are expecting turbulence as we pass through the preconceived notions of Architecture, Use Cases, and High Level Design.
Clean Code : SOLID Principles
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 8, Foundations of the SOLID principles
Details
By Uncle Bob,Jan 27, 2012,53 min
Description
In this video Uncle Bob begins his exploration of the S.O.L.I.D. principles, by beginning at the beginning, and laying out their foundations. This is the first of several new episodes that will do deep-dives into the principles one-by-one.
We begin with the question: "What is Design?". We make the case, based on Jack Reeves' famous 1992 paper, that the design of a system is best captured by the source code. That all other forms of design documentation, regardless of their usefulness, are preliminary and/or ancillary.
If the design of a system is it's source code, then cleaning the source code is cleaning the design. But what are the symptoms of poor design? How can we know when the design of our systems is starting to degrade? To answer that, we take a harder look at the Design Smells of Rigidity, Fragility, Immobility, Viscosity, and Needless Complexity. How can we identify these smells and clean them before they become a significant problem?
Next we watch a batch of code rot. We start with a pleasant and clean design and watch as change after change degrades that design into a festering mass. Then we study an alternate design that does not rot when the same changes are applied. We investigate the difference between those two designs and discover the principle that underlies all of Object-Oriented Design. We do a deep dive into the history of OO, and derive a new and unambiguous definition of OO based on Dependency Management.
Finally we take a brief look at the S.O.L.I.D. principles which will be the topics of the next several episodes.
Clean Code → Episode 9, The Single Responsibility Principle
Details
By Uncle Bob,Mar 26, 2012,69 min
Description
In this video Uncle Bob will take you on a deep dive through the Single Responsibility Principle. After a little General Relativity, you'll learn just what a responsibility is, and how it relates to the users of the system and the roles that they play.
You'll learn about the primary value of software, and why that value is not what you'd expect. You'll also learn how the proper allocation of responsibilities to modules impacts that value and means increased profits for your business.
Uncle Bob will teach you how misplacing responsibilities can lead to design smells like Fragility and Viscosity. He'll show you the importance of separating responsibilities into different functions, classes, and modules. And he'll demonstrate different techniques for achieving that separation.
Next, he'll walk you through several different Java functions and ask you to find the single responsibility violations. Then he'll show them to you and recommend ways to separate them.
Finally, he'll walk you through the case study of a simple application, from inception to delivery. He'll show you how to find the responsibilities; and, following the principles of architecture from Episode 7, how the system can be designed so that those responsibilities are separated. He'll also show you where to get the code so you can study it later.
So get yerselves saddled up and rarin' to go because yall're 'bout to stampede into The Single Reponsibility Principle. Yee Ha!
Clean Code → Episode 10, The Open-Closed Principle
Details
By Uncle Bob,Apr 14, 2012,62 min
Description
The Moral Center of Software Architecture.
That's how Uncle Bob describes the Open-Closed Principle (OCP). In this episode you'll learn all about Bertrand Meyer's remarkable insight into Object Oriented Design and the motivation behind good Software Architecture.
We'll discuss how it's possible for the source code of a system to be open for extension, but closed for modification. Then we'll show you how to construct designs that conform to that principle.
Next we'll look at a truly awful design that violates the OCP and we'll show how that violation creates the design smells of Rigidity, Fragility, and Immobility.
Then we'll present a truly elegant and beautiful design that conforms to the OCP. This design will startle you with it's essential simplicity; dazzle you with it's suave construction; enamor you with it's incredible flexibility. After seeing it, you'll begin to believe that software can be open for all extension and yet closed for all modification!
Then we'll break your heart by showing you why the promise of the OCP is, in fact, a big lie. We'll tear that elegant design to shreds, and we'll show you why all that protection it claimed to offer was an illusion that depended upon prescience and perfect foresight. In the end we'll shatter your hopes and dreams in software design.
Then we'll resurrect those hopes and dreams by describing a development process that helps to restore the truth behind the promise of the OCP. We'll show you that you can, in fact, make designs that conform to the OCP, if not in whole, then at least in part. We'll describe the disciplines that will help you to take the greatest advantage of the OCP.
So sit yourself down and settle on in, because after we learn about the Quantum Discontinuity, we're going to open the can of worms called the Open Closed Principle.
Clean Code → Episode 11, The Liskov Substitution Principle - Part 2
Details
By Uncle Bob,Jun 1, 2012,32 min
Wait!
Make sure to watch Clean Code Episode 11 - The Liskov Substitution Principle - Part 1 first.
Note: business licenses for that episode automatically include this one for free!
Description
This is Part 2 of Episode 11
Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming!
That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++.
Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest".
Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages.
Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate.
Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive.
So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!
Clean Code → Episode 12, The Interface Segregation Principle
Details
By Uncle Bob,Jul 11, 2012,65 min
Description
There may be no I in TEAM, but there sure is an I in SOLID, and that's what this episode is all about: The Interface Segregation Principle.
I remember, long ago, a nemesis of mine on comp.object used to accuse me of being a racist because I used the word "segregation" in this principle. He also took note that I called a particular design pattern "TaskMaster". Ah, Elliott, I sometimes miss your thorn in my flesh.
In this episode we're going to talk about the problem of too much knowledge. We'll show the strange backwards dependency that happens when classes know too much; and the problem that backwards dependency causes.
I'll tell you the story about how the Interface Segregation Principle came into being. It's a story about a company that had a big build-time problem. I'll show you the bizarre solution we discovered to fix that problem; and tell you why soot was so important to that discovery.
We'll talk about fat classes -- classes that have too many methods, and too many dependents. We'll discuss the problems they cause, and how to resolve those problems.
We'll watch a young novice under the tutelage of her master as she struggles through the ATM case study and investigates why too much knowledge harms system structure.
Then we'll investigate the physical structure of interface segregation, and once again assert the importance of the boundary between the application and main.
Finally, we'll talk about the principle behind the principle, and why this principle which on the surface of it seems to be about static typing, is actually not about static typing at all.
So pack the kids in the car, strap the bikes on the roof rack, and cram the tent in the trunk, because we're about to drive into the rugged territory of the Interface Segregation Principle.
Clean Code → Episode 13, The Dependency Inversion Principle
Details
By Uncle Bob,Aug 12, 2012,58 min
Description
And now, at last, it's time for the Dependency Inversion Principle -- the final principle in the SOLID suite.
Go back in time with Uncle Bob to 1979, when he was just a noobie software developer with only 6 years experience. Walk with him through the tale of telephone test equipment using 8085 microprocessors with 32K of RAM and 32K of ROM. See how he first discovered the magic and power of inverting source code dependencies in order to turn those ROM chips into independently deployable components.
Then hop into the time machine to the early '90s when Uncle Bob was becoming an accomplished C++ programmer. See how he, and his team, struggle, and at first fail, to create a huge reusable framework. Watch as he discovers the key to reuse, and to building frameworks that many applications can reuse.
In this episode we'll learn what dependencies are. We'll study the difference between source code dependencies, and runtime dependencies. We'll learn why that difference is important, and we'll learn how to invert certain key source code dependencies so that they oppose their corresponding runtime dependencies.
Then we'll spend some time looking at two case studies. First we'll look at IO drivers, and how they use dependency inversion to create device independence. Then we'll look at the good old furnace example, and see how dependency inversion allows us to separate high level policy from low level detail in order to create a plug-in architecture.
So get ready for a wild ride through time and technology and we DIP in to the Dependency Inversion Principle.
Clean Code → Episode 14, Solid Case Study
Details
By Uncle Bob,Sep 18, 2012,43 min
Description
OK, this one's a little different. No science lesson. The tone is a bit more serious. (a bit more.) It's the conclusion to the series on the SOLID principles. In this episode we look again at the Payroll Example from Episode 7; but this time we do so in the light of the SOLID principles.
In this episode we start from use cases, and work through each of the principles to create a design. We break up the use cases by using the SRP. We start to build the architecture using the OCP. We find LSP issues to solve in the complex polymorphism hierarchies. We find the ISP lurking in factories. And, of course, the DIP is everywhere.
As we walk through this case study, we examine each principle in depth. We allow the principles to illuminate issues in the design, and then we discuss several ways those issues can be addressed. Bit by bit we piece together the design.
Then we close by taking a lesson from Joel Spolsky when he criticized these principles several years back, without really knowing what they were.
So sharpen your pencils, you're going to need them, because this is an in-depth review and case study of the SOLID principles.
Clean Code : Component Design
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 15, SOLID Components
Details
By Uncle Bob,Oct 26, 2012,58 min
Description
Do you like coffee? This episode is all about coffee. Or, rather, it's all about making coffee.
This episode introduces our series on the SOLID principles of component design. In this episode Uncle Bob will tell you just what components are, and how they came to be. We'll learn how loaders evolved into linkers that evolved into linking loaders. We'll learn how object files evolved from absolute, to relocatable, to linkable, to dynamically linked components.
Then we'll do a deep investigation of the Coffee Maker case study. We'll learn the requirements and the API. We'll see how not to design it, and then we'll see a good SOLID component-ized design. We'll see how boundaries are created and crossed with the Dependency Inversion Principle. We'll see how high level modules are identified with the Single Responsibility Principle. And we'll watch yo-yos go up and down as we traverse up and down the layers of abstraction. By the time we're done we'll have laid the foundation for the next episodes on the principles of component design.
So, grab a nice hot steaming cup of really strong coffee, sit back, relax, and enjoy the buzz because were about to spend the next hour brewing component principles.
Clean Code → Episode 16, Component Cohesion
Details
By Uncle Bob,Jan 14, 2013,55 min
Description
Sticky, Icky, gooey! Cohesion. That's what this one's all about. Component Cohesion.
How and why do components cohere? What are the good forces of component cohesion, and what are the bad forces? Which classes belong together in components, and which should be kept apart?
Oh, and why do White Dwarf stars go Supernova?
In this episode we're going to explore the three principles of component cohesion:
• The Release Reuse Equivalence principle
• The Common Closure Principle
• The Common Reuse Principle
We'll learn about the goal of independent deployability, and why that goal causes certain classes to belong together, while other classes don't.
We'll also learn about the forces of false cohesion that tempt us to group classes together into ineffective components that aren't independently deployable.
We'll see, first hand, the erie connection between the component principles and the SOLID principles.
We'll see how components are governed by release procedures, by actors and their responsibilities, and also by how much knowledge they present to their users.
And we'll discover that the component structure of a system is a function of it's maturity as well as of it's behavior. We'll see that the component principles have a certain mutual exclusivity that creates a tension in the component structure.
So get a rag and some Acetone, because we've got a lot of gooeyness to deal with, as we slurp our way through the topic of component cohesion.
Clean Code → Episode 17, Component Coupling
Details
By Uncle Bob,Feb 14, 2013,60 min
Description
Stop all that giggling and get your minds back out of the gutter. It's Component Coupling people, Component Coupling.
In this video our intrepid cast of characters will explore the principles that govern the relationships between components. Those principle are:
• The Acyclic Dependencies Principle.
• The Stable Dependencies Principle.
• The Stable Abstractions Principle.
In this lesson we'll learn about the Morning After Syndrome, that hideous disease that affects large teams and causes them to step all over each other. We'll show how a large system can be safely and effectively managed by keeping the dependencies between the components free of cycles.
Then we'll take a look at the concept of stability. What makes a component stable, and why should we care? What effect does stability have on the dependencies between components?
Then we'll look at abstractness. What makes a component abstract? How does abstractness impact on the couplings between components?
Then we tie it all together. What is the relationship between stability and abstractness? How can we use that relationship to free our stable components from rigidity?
Finally, we boil it all down into numbers and metrics. We derive a set of simple mathematical expressions that describe the relationships between components, and provide numeric measurements of how well those components conform to some of the SOLID principles.
So, don your enchanted armor, get your iron picks and diamond swords ready, and get out of bed, because the sun is about to rise on the world of Component Coupling.
Clean Code → Episode 18, Component Case Study
Details
By Uncle Bob,Mar 29, 2013,58 min
Description
Oh, so you want an example eh? You want something real? You're tired of all the theory and lecture. You got through all those videos about the component principles, and now you want to see how they're actually used.
Well, do I have good news for you! Because that's just exactly what this episode is all about. We call it the Component Case Study and it's all about studying cases.
We're going to study big cases, small cases, round cases, square cases, suit cases, hat cases -- all kinds of cases. By the time you're done with this video you're going to know cases inside and out.
No, that's wrong. It's not about cases. It's about components. It's about component principles. In fact it's a detailed examination of just how those principles are used to solve a real problem.
The problem we tackle is the Payroll problem from Episode 14. Remember back in that episode we applied the SOLID principles in order to create an object oriented design that partitioned the problem into classes and relationships? Well now in this episode we're going to take those classes and we're going to apply the component principles to them, creating an architecture of independently deployable components.
But it's not just going to be as simple as that. Oh no! First we're going to look at lots of wrong ways to break the problem into components -- ways you might even recognize from past projects. We're also going to spend a considerable amount of time talking about, and using, component families as an organizational concept.
So make sure your cases are all packed and ready to go; because we're going to study those cases as we embark upon: The Component Case Study!
The diagrams for this episode can be downloaded here.
Clean Code : Advanced TDD
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 19, Advanced TDD - Part 1
Details
By Uncle Bob,May 22, 2013,61 min
Description
OK, so I completely blew it. For a year now I've been promising you this episode on advanced TDD. Tease, tease, tease -- advanced TDD. Blah, blah blah. So then, when I finally started writing the script for the episode, I realized that the script was far too long for one episode, and I wasn't even halfway done with the topics I wanted to cover!
So, I backed off and did a topic analysis on what I wanted to talk about, and found I had three or four episodes worth of material. I gathered the first topics together, and set the others aside for later. And then I finished off the script for the first episode.
Then, after shooting and editing, we realize that the episode is two hours long! Woah! We need to split it again!
So, here it is. Episode 19, part 1. Advanced TDD.
In this episode we're going to do a deep dive into the three laws of TDD; with lots of code examples. We'll study the process of TDD in minute detail as we gradually build a simple program to invert names.
As we explore the three rules, we'll also start the discussion about The Single Assert Rule; and then we'll set that aside for more exploration in a future episode.
So, wash your eyes out and clean your glasses, because this one's all about the code. And get ready for the first half of Episode 19. Part 1. Advanced Test Driven Development.
Clean Code → Episode 20, Clean Tests
Details
By Uncle Bob,Jul 26, 2013,84 min
Description
Woah! Twenty episodes! Wow! That's almost a full 24 hours of video. Who'd have thought that I had 24 hours of stuff to talk about? Who'd have thought that after nearly a full day of talking I'd have so much more to say!
Anyway, in celebration of the twentieth episode, we've included a couple of extra features for your enjoyment. We hope you'll like them. We sure had fun making them!
This episode is all about Clean Tests. We begin by examining the anatomy of a test: The four A's: Arrange, Act, Assert, and Annihilate. We spend a lot of time talking about the various forms of the Arrange.
Next we talk about the problem that setup functions can grow to become unmanageable; and we address that problem by introducing the fascinating topic of hierarchical tests. We show how hierarchical tests are natural in Ruby using Rspec, and how to implement hierarchical tests in C# and Java.
Finally, we put the icing on the cake by showing you how to create truly clean and readable tests by using the technique of test composition.
So get ready for a dimensionally transcendental experience, as we materialize inside the world of Clean Tests!
Clean Code → Episode 21, Test Design
Details
By Uncle Bob,Aug 21, 2013,56 min
Description
• Did you know that tests have a design?
• Did you know that the design of tests is critical to the success of the project as a whole?
• Did you know that the problem of Fragile Tests is a design problem?
• Did you know that the SOLID principles apply to tests as well as to the production code?
• Did you know that the code drives the tests just as the tests drive the code?
• Did you know that test naming is part of test design?
Those are some of the things you are going to learn in this episode of Clean Code. Episode 21: Test Design.
And the bottom line is this: Tests are part of the code of your system. They are not a different class of code. They are not a different species of code. They are not somehow inferior or less important. The code in your tests is part of the code of your system! And therefore the code in your tests has to be planned, and designed, and cared for with the same zeal, and effort, and conscience as the production code!
The penalty for failing to hold your test code to the same high standard of your production code, is that your tests will rot, and your production code will follow.
So, no pressure or anything, but in this episode you're going to learn some of the rules, techniques, and principles of: Test Design.
Clean Code → Episode 22, Test Process
Details
By Uncle Bob,Oct 3, 2013,83 min
Description
Have you ever heard of: Fake It Till You Make It? How about: Assert First or Test Triangulation? These are just some of the test writing techniques that we'll cover in this episode -- and cover with lots and lots of code.
Then we'll face the ultimate existential question of tests: What's more important, the tests or the production code? Indeed, we'll pose it a problem of two disk drives; one containing the tests and the other containing the production code. One of them has crashed. Which do you hope it is?
How much of your refactoring effort should be spent refactoring the tests? Any? And if you do refactor the tests, what is the goal of that refactoring? What does a good clean test look like?
Kent Beck often says: "First make it work. Then make it right. Then make is fast and small."
Ron Jefferies' rules of Simple Design tell us that the code should:
1 Pass all the tests.
2 Have no duplication
3 Express everything the author wants expressed.
4 Have a minimum of classes and methods
What do these rules have to do with tests? Should they be followed when writing tests? Or is there a different set of rules for tests? The answer may surprise you.
Finally, we'll talk about the term: Test First, and find out what it really means.
So get ready to read lots of code, to think lots of thoughts, and to face the ultimate truth of test driven development.
Clean Code → Episode 23, Mocking - Part 1
Details
By Uncle Bob,Dec 11, 2013,62 min
Description
EGAD! Another two-part episode! I just can't seem to get this advanced TDD topic under control! So, this is part 1. Remember to get part 2!
OBAFGKMLT
Welcome to Clean Code Episode 23 - Mocking; part of our sub-series on advanced Test Driven Development. In this episode we're going to learn about Test Doubles and Mocking.
We begin with a little puppet show. You'll recognize the characters. You'll also recognize the situation; because, in all likelihood, you've been there - done that. That situation will lead us to a software architecture replete with dependency-inverted boundaries. As the players in our drama discuss how to test the features in that architecture, we'll gradually make the case for using mocks.
Then we'll show you those mocks in a sequence of screencasts that begin with basic stubs and moving on to more involved spies. There's a lot of code to look at; and of course you can download it all from the extras link.
Then we get all academic and study the classification of Test Doubles. We talk, in depth, about dummies, stubs, spies, mocks, and fakes. And there is plenty of code describing each.
All that takes an hour. And at the end of that hour, part 1 comes to an end. But don't forget to watch part 2, because things get pretty interesting over there.
In part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists.
Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied.
Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the code so that the testable bits are all isolated from the GUI bits.
And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.
And that, at long last, will bring us to the close of Episode 23.
Clean Code → Episode 23, Mocking - Part 2
Details
By Uncle Bob,Dec 11, 2013,45 min
Description
OK, so now you know what OBAFGKMLT means...
This is part 2 of Episode 23 - Mocking. In the previous episode you learned all about the motivation for, and structure of, test doubles.
Now, in part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists.
Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied.
Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the code so that the testable bits are all isolated from the GUI bits.
And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.
And that, at long last, will bring us to the close of Episode 23.
Clean Code → Episode 24, Transformation Priority Premise - Part 1
Details
By Uncle Bob,Jan 31, 2014,51 min
Description
Yikes! Another two-parter. These topics just keep getting bigger and bigger.
OK, so what the devil is the Transformation Priority Premise? Well, it's an idea that's kind of at the front lines of Test Driven Development. The Bleeding Edge, so to speak.
The notion is pretty simple. You know what refactorings are, right? I mean they're small modifications to source code that change the structure of that code without changing the behavior. Well, a transformation is just the opposite. It's a small change to software that changes the behavior, without changing the structure.
Would it surprise you to learn that the number of transformations is relatively small -- perhaps only a dozen? Would it also surprise you to learn that these transformations fit neatly into the red-green-refactor loop of TDD? Finally, would you be surprised if I told you that some transformations are "better" than others?
In this episode we'll identify an even dozen of those transformations. First we'll walk through a familiar Kata (the Prime Factors) and show how a few transformations are used. Then we'll walk through each transformation in turn, and describe them in detail.
And that'll take the hour; and will bring part 1 to a close.
In Part 2 things get really exciting. Because in Part 2 we explore the notion that these transformations have an ordering, a priority, that helps developers create better algorithms better code, and better design. But that's part 2. No fair peeking.
Clean Code → Episode 24, Transformation Priority Premise - Part 2
Details
By Uncle Bob,Feb 17, 2014,50 min
Description
OK, so this is Part 2; and this is where things get really exciting.
I'm sure you've seen me do the Bowling Game, the Prime Factors, and the Word Wrap katas. You know how those algorithms just seem to kind of appear, as though the code was writing itself?
We'll we're going to see that again. But this time we're going to see it in the context of applying transformations using a certain priority. In fact, we'll do it twice, with two different priorities. And then we'll examine the different.
The difference will be (how do I say this without giving too much away?) -- interesting. Very interesting.
Finally, we'll state the premise. We'll also make the point that it is no more than that. It's not a law, not a principle, not a theory, not even a conclusion. It's just a premise. But if it's even partially correct, it's a premise that could have a significant impact on our profession.
Or not.
Anyway, enjoy the episodes.
Clean Code : Design Patterns
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 25, Design Patterns
Details
By Uncle Bob,Apr 4, 2014,56 min
Description
And so we begin our exploration into design patterns.
We begin by talking about the overall concept of design patterns. What are they, and what are they good for?
Next we do a quick overview of the GOF book; and we'll find out why it is one of the most important books to be written within the last three decades.
Then we put our heads down and focus tightly on the Command pattern. We learn that the command pattern is a way to decouple what is done, from who does it.
Next we find that it also helps us decouple what is done from when it is done.
Next we look at Undo and Redo, and how the Command pattern makes these features almost trivial to implement.
Finally we look at the actor model; a way to support hundreds or even thousands of threads in a memory constrained environment.
So hold on to your GOF because Design Patterns are about to begin.
Clean Code → Episode 26, Factories
Details
By Robert C Martin,Jun 13, 2014,65 min
Description
So. Now it's time to talk about Factories. Factories. Lots and lots of Factory patterns. And no XML.
In this episode we'll introduce three patterns in the family of factories. Factories! Lots .... And no XML.
First, we'll talk about Abstract Factory. We'll show you why and when you'll want to use it, and what interesting little traps to watch out for. And that will start us on a lovely discussion about independent deployability, component design, jar files, type safety, type wars, smalltalk, Java, Eclipse, and No XML!
Then we'll talk even more about the Factory Method and Prototype Patterns, and we'll discuss the problem of initialization. And we'll talk more about type safety, and language wars, and C vs. Pascal, and C++ vs. C, and Java vs. C++, and Smalltalk and Ruby, and NO NO NO XML!!
Because we don't want to talk about XML. You heard me, right. NO XML! I don't want to hear about XML. I mean, for goodness sake, what were those guys thinking? XML was not a language that was designed for people to write! It was just a convenient syntax for a binary representation. You know, like X400, and X209, and ... What the bleeping bleep were those XSLT guys thinking. Or those ANT guys. And don't even get me started about Maven. Sheesh, angle brackets everywhere and I mean who the... It just makes me nuts that anybody would try to use XML for anything other than just looking at a data stream. I mean writing XML? WRITING XML???? That's just nuts, nuts, nuts. It's nuts I tell you. It's crazy kookie, wiered out nuts in the worm hole, and I don't know what to tell you these angle brackets are everywhere like little paperclips, like little spider legs, crawling, crawling up my spine and down my legs, and I just can't tolerate them all over me anymore and …..
Clean Code → Episode 27, Strategy & Template Method Patterns
Details
By Robert C Martin,Aug 19, 2014,50 min
Description
At long last, the episode you've been waiting for. The episode on Strategy and Protocol. No. Protocol and Template Method. No. Uh. Strategy and Template Method. Yeah, that's it. S&TM!
In this episode we are going to tear into the unimaginably powerful, wildly complicated, and ultimately impenetrable Strategy pattern!
Applause!!!
In this episode the secrets will be revealed. The mysteries will be solved. The arcanities will be explained. The unknowable will be made known.
You, yes you!, will at last understand how to employ the Strategy pattern, and it's brother the Template Method pattern. We'll talk about the costs, the benefits, the uses, and the abuses of these patterns.
It'll be cool. It'll be really cool. It'll be revolutionarily coooool!
So come on, what are you waiting for? It's time to dive, head first into the maw of the beast and uncover the ultimate truths of:
**Strategy and Template Method**
Clean Code → Episode 28, Finite State Machines and The State Pattern
Details
By Robert C Martin,Oct 31, 2014,73 min
Description
Come all without. Come all within. You've not seen nothing like the mighty FSM.
This episode is all about Finite State Machines. What they are. Why and when to use them. How to represent them. And how to implement them. Including implementing them with The State Pattern.
Yes, this is part of our series on Design Patterns. It's also the first in at least three parts that will lead us from the State pattern to the Visitor pattern.
It's going to be an interesting journey. We begin it here by talking about state machines and how remarkably useful they are, and how frustrating they can be to implement. By the end of this episode we'll have decided that the solution to that frustration is to write a compiler that generates the code from a simple syntax.
The next few episodes will explore how to write that compiler; and how to use Finite State Machines to write that compiler.
These next few episodes are going to be fun, challenging, and important. You aren't going to want to miss them.Clean Code : Behavior Driven Development
Clean Code → Episode 29, SMC Parser
Details
By Robert C Martin,Dec 2, 2014,76 min
Description
OK boys and girls, things are really starting to heat up. In this episode we start writing a compiler!
Remember,that's what we said we were going to do. We said we'd write a compiler that generates finite state machines. Well, that's what were doing. And, boy, is it a hoot.
We begin by exploring the syntax of our state machine language. That syntax begins as a simple state transition table, and then we add a few cute bells and whistles, like super states, entry, and exit actions, that make writing state machines a bit more convenient.
Next we formalize our syntax by expressing it in Backus-Naur Form (BNF).
Then we write a lexical analyzer to identify the terminal tokens of our syntax.
Then we write a parser that identifies the grammar of those terminal tokens. And, ironically, that parser is a finite state machine!
Then we use the Builder Pattern to write a builder that constructs the internal representation of our syntax.
And if you don't think that's enough for one episode, you're crazy.
So, put your propeller caps on and take a big swig of brain juice, because we're about to plow headlong into the heady topic of Writing the State Machine Compiler!
The source code for the State Machine Compiler is included in the "extras"; and can also be found at:
Clean Code → Episode 30, SMC Generator
Details
By Robert C Martin,Feb 5, 2015,94 min
Description
Where is Uncle Bob? He invited us over for dinner and we've been waiting and waiting. Where could he be? It's unlike him to be this late?
Wait! What's that sound? Great Heavens! Who is that wretched creature at the door, guzzling our wine like a man bereft of his senses.
Prepare yourself for an interesting journey. A journey through the land of Code Generation and The Visitor Pattern.
In this episode we conclude the mini-series on the State Machine Compiler. In the last episode we had just finished the parser. In this episode we'll see the Semantic Analyzer, the Optimizer, the Generator, the Abstract Syntax Tree, and the code generating Visitors. And that means we've got a lot of code to look at.
While we are looking it over, we'll take a short diversion into the rationale, and variations of the Visitor Pattern. And we'll also do a quick review of the Composite Pattern.
We'll also see how the discipline of Test Driven Development differs in certain larger projects, from the small Katas and examples that we've seen in the past.
So clear your head, and free your mind. Red pill or blue? It's up to you.
Clean Code → Episode 31, The Observer Pattern
Details
By Robert C Martin,Mar 25, 2015,65 min
Description
OK, get ready for some fun. In this episode we're going to dive deep into the Observer pattern.
The first thing we'll do is derive the pattern from first principles. We'll begin with a simple real-time clock application and, step by step, apply one design principle after another until the Observer pattern emerges.
Well, actually, what emerges is a structure that our current most popular languages can't implement, because it requires multiple inheritance. So we'll explore the workarounds to that, and then we'll rant about why Java and C# don't have this useful feature.
The Observer pattern comes in two forms. The "Push" model, and the "Pull" model. We'll describe them both and discuss when and where each is appropriate.
Then we'll turn to the larger pattern that the Observer fits into: Model View Controller. We'll look at the history of MVC, and the unfortunate corruption of the pattern by current web frameworks.
Finally, we'll invoke the Humble Object pattern for testing GUIs, and we'll derive the Model View Presenter pattern from MVC.Java Case Study
Clean Code → Episode 32, Pile O'Patterns
Details
By Robert C Martin,May 5, 2015,68 min
Description
OK, so now we're really starting the make progress through the design patterns. In this episode we'll study five of the most useful.
First we'll discuss Singleton and Monostate; two patterns that help you enforce that only a single instance of a class is created.
The real challenge with these patterns is how you initialize the static variables that are involved. So we'll walk through the whole nine yards of initialization issues, including threading issues, locking, double-checked locking, etc.
You're going to love Monostate. It's a really cool pattern with lots of very interesting uses.
Then we'll talk about nothing. Or rather, objects that do nothing -- or rather objects that get away with doing nothing by doing nothing in just the right way. The pattern is called: Null Object.
Then, it's on to the Proxy pattern. This is the pattern used by most interprocess communication tools, and database isolation tools. Proxy is a pattern that is used when two objects need to communicate across a boundary, and should not know about that boundary.
Lastly, we'll discuss the Decorator pattern. Decorator is a member of the Visitor family of patterns. It is another way to add new behaviors to existing class hierarchies without modifying those hierarchies.
And after that we'll take a long deep breath to get read for the next episode -- and even more patterns.
Clean Code → Episode 33, Pattern Roundup
Details
By Robert C Martin,Jun 19, 2015,65 min
Description
This is the Patterns Roundup -- the Penultimate episode in our Design Pattern's series.
In this episode you'll learn about five more patterns. Facade, Mediator, Memento, Flyweight, and Extension Object.
The Facade and Mediator patterns are used when you have a group of objects that you want to impose a policy upon. Facade imposes that policy overtly from above. Mediator imposes it covertly from below.
Memento is used when you want to capture the state of of an object inside an opaque token that can be passed around the system; and that can later be used to reconstitute the state of the captured object.
Flyweight is used when you have a group of objects that share a large amount of common state. That state is moved into a separate object and shared amongst all the objects.
Extension Object is yet another member of the Visitor family of patterns that allow us to add new behavior to existing hierarchies without changing those hierarchies.
If the first 90 seconds of the video seems low resolution, don't worry, It gets better. We're working on fixing that how.
Clean Code → Episode 34, Pattern Apocalypse
Details
By Robert C Martin,Jul 18, 2015,82 min
Description
This is the Pattern Apocalypse! The final episode about design patterns. And it's a doosy!
In this episode we're going to talk about five patterns:
1 Bridge
2 Chain of Responsibility
3 Interpreter
4 Iterator
5 Adapter
You're going to love the discussion about the Bridge pattern. In it, I show you how to break down an subtype hierarchy with multiple degrees of freedom into a chain of several subtype hierarchies capturing one degree of freedom each.
In the Chain of Responsibility discussion we extend those hierarchies so that clients have no idea what server is serving them.
Then we explore Greenspun's 10th law by looking at the Interpreter pattern. And we learn that with great power comes great responsibility; and that most efforts to reduce programming workload by shifting it to the business simply cause that workload to bounce back to the programmers.
You're going to find the Iterator discussion particularly interesting. It's not what you think it is. This discussion will teach you how to turn loops inside out so that the loops are at the bottom, being driven by the algorithm, instead of at the top and driving the algorithm.
And then, at long last, the humble Adapter pattern. I'll go through a little history about comp.object discussions, and table lamps, and interface naming. And then we'll explore the two primary forms of the Adapter.
So, if you're ready, it's time to dive in to the final set of Design Patterns. Fire up the Pattern Apocalypse!
Clean Code : Behavior Driven Development
* Note- Exams and detailed reporting included with all episodes of this series.
Clean Code → Episode 35, Behavior Driven Development
Details
By Robert C Martin,Sep 1, 2015,69 min
Description
Programming is one thing. Writing programs that meet the needs of the business is another. How do the business people and the programmers communicate?
Answer: badly.
In this episode we're going to introduce the concept of Acceptance Testing and Behavior Driven Development (BDD) as a means to enhance that communication.
First we'll look at the problem itself; the problem of communication between business people and technical people.
Then we'll discuss some of the more successful solutions to this problem, including the tables developed by David Parnas; and the Fit Framework developed by Ward Cunningham.
In fact, we'll have a surprise visit from Ward, and hear some of that history from the horse's mouth.
Then we'll look at FitNesse, and some of the ways we've used acceptance testing and BDD to specify it.
Then we'll get into the guts of BDD and walk through some examples.
Finally, we'll talk about the Acceptance Test Rule. This is the rule that tells us the best form to present Acceptance tests in; and whether BDD is appropriate for your team.
And that will end part 1 of our series on Acceptance Testing.
Have fun. This one's a hoot. You'll meet a new character in here -- one you'll recognize!
Clean Code → Episode 36, Behavior Driven Development Design
Details
By Robert C Martin,Oct 5, 2015,48 min
Description
Have you ever wanted to be a business analyst? Well here's your opportunity to watch a new business analyst learn the ropes. She's new. She's inexperienced. But she'll have some experienced help getting started. In the end, she'll do fine.
In this episode we're going to watch a project get started. From the initial pitch and the mandate from executives, to the conversation between business analysts, programmers, and QA. And we'll learn the dynamics of that conversation.
We'll learn that the qualifications for being a good business analysts, and being a good QA technician, are similar in many ways; and that they require equal measures of technology and business background.
So, watch carefully as the first acceptance tests are written. Notice how the business analyst makes assumptions about those tests that are corrected by the QA technician and the programmers. Watch as the design of the initial tests take form.
And notice how the business analyst learns that the design of those tests is critically important to the success of the project.
Java Case Study
Java Case Study → Episode 1, Getting Nothing Done
Details
By Uncle Bob and Micah,Jun 4, 2014,66 min
Description
Welcome to the Clean Coders Java Case Study. This is Episode 1.
Over the next weeks and months, Micah and Uncle Bob will re-implement the website in Java before your very eyes. You'll see them applying all the principles, patterns, and practices that you've been learning in the Clean Code series. But instead of learning about those principles, patterns, and practices, you'll see how they use them in real life.
The first episode is entitled Getting Nothing Done because in this episode they use the first acceptance tests in FitNesse to set up the infrastructure and facilities they need to start getting real stories implemented. They do finish one story; but it's the story of the null case.
So get ready for some fun and education and you watch these two seasoned professionals work together to create a web system in Java.
If you want to follow along with the code, you can get it from github here:
Java Case Study → Episode 2, Let the Testing Begin - Part 1
Details
By Robert C Martin & Micah D Martin,Jul 16, 2014,70 min
Description
Welcome to the Clean Coders Java Case Study. This is Episode 2, part 1.
So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress.
We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful.
There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway.
We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair.
Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating.
We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.
If you want to follow along with the code, you can get it from github here: This episode is in the "E2 Complete" commit from May 13, 2014.
Have fun!
Java Case Study → Episode 2, Let the Testing Begin - Part 2
Details
By Robert C Martin & Micah D Martin,Jul 20, 2014,65 min
Description
Welcome to the Clean Coders Java Case Study. This is Episode 2, part 2. Make sure you watch part 1 first. This episode picks up right where part 1 left off.
So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress.
We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful.
There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway.
We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair.
Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating.
We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.
If you want to follow along with the code, you can get it from github here: This episode is in the "E2 Complete" commit from May 13, 2014.
Have fun!
Java Case Study → Episode 3, Sorting Our Issues
Details
By Robert C Martin & Micah D Martin,Sep 25, 2014,75 min
Description
Boy! All we had to do in this episode is sort one field and add another. And yet we stumbled and fussed all over the place. We even got derailed once by using the Java-6 documents instead of the Java-7 documents. Sheesh!
Watch Uncle Bob in the first half of the episode. He doesn't want to touch the keyboard! What's up with that? He just sits there and grunts imperiously while Micah does all the work.
With all the load on Micah, he starts to get tired too. By the end of the first tomato they're both so knackered that they can't remember how to make the sort function work.
What a difference a break makes. The energy comes back in the second tomato and is running high in the third. I guess all programmers go through periods where they just don't feel up to coding.
There are some interesting technical surprises in this episode. For example, there a classic case for inheritance that we eventually bail out of and use an enum instead. And we find some interesting issues with SimpleDateFormat.
We also dig a bit deeper into the FitNesse fixtures such as Decision Tables, Query Tables, and Ordered Query Tables.
By the end of the episode, you'll see that the code is starting to get pretty messy -- despite the refactoring we've done along the way. And that set's the stage for Episode 4 -- But then I don't want to give too much away.
You can get the source code from github. This episode begins at commit: be8d09 and ends at: 4b885f
Java Case Study → Episode 4, We Write a Web Server
Details
By Robert C Martin & Micah D Martin,Oct 8, 2014,66 min
Description
Knock knock.
Who's there?
No, not yet. Let's do this later in the episode.
No, not yet. Let's do this later in the episode who?
No. Stop. ... Oh rats.
In this episode we change directions entirely; and we announce a contest!
The episode begins by reviewing a big refactoring that Uncle Bob did off line. It's pretty cool, and you aren't going to want to miss it.
Then we announce the contest that you can participate in (See Below).
Then we take the whole project in a brand new direction. We begin to write our own simple web server. We got frustrated looking at all the other web servers out there, and decided it would be a better use of our time to write our own.
Have you ever written a web server? Its simple; and it's fun! Watch how we do it here; and listen to the rationale we present.
And then enter our contest...
Contest
We ask you to submit a video showing how you would have executed the refactoring that Uncle Bob did. Show it step by step, and keep all tests passing for each step.
The github repository for the Java Case Study is:
Begin at commit: D33B4, and end at a state similar to commit: 72724.
Put your video into a dropbox or something similar, and send a link to Contest@.
Micah and Uncle Bob will review the videos and select their favorites to be shown as part of an upcoming episode. We reserve the right to edit any videos we present.
Java Case Study → Episode 5, A Series of Twisty Little Threads
Details
By Robert C Martin & Micah D Martin,Dec 22, 2014,84 min
Description
Working on the web server leads to periods of befuddlement followed by periods of productivity.
This episode might be a little painful to watch as Micah and I stumble around trying to make this multi-threaded web-server code work. You'll watch us miss obvious things that you see right away. You might even be moved to leap up from your seat and shout at the screen.
Still, in the end, we solve the threading problems and make a lot of progress on our little web server. After three tomatoes, we can see our way clear to the end.
Working on multi-threaded code is always a challenge. TDD helps a lot with correctness; but imposes it's own complications too. If you've always wondered how to do TDD in a multithreaded environment, you can watch us do it here.
Java Case Study → Episode 6, Where Are We Testing?
Details
By Robert C Martin & Micah D Martin,Jan 16, 2015,74 min
Description
We solved all the race conditions in the last episode; so in this episode things go much more smoothly. There are a few tests left in order to finish the web server. We write them. And then we find that they weren't quite testing what we thought they were testing.
We quickly finish getting our little web server running, and then start using it to send simple "Hello, World" messages to the browser.
This forces us to investigate the high level structure of an HTTP Response; and make sure that our little web server delivers that structure.
Once we can reliably communicate with the our browser, we begin working on delivering the Front Page to the browser.
Along the way we discover that tests sometimes don't test what you think they do; and that sometimes the best tests are visual.
Java Case Study → Episode 7, The Customer Is Coming
Details
By Robert C Martin and Micah D Martin,Mar 3, 2015,73 min
Description
Uh Oh.
We just got a call from the customer. They want a demo -- in an hour!
Are we ready? Do we have enough to show? Can we cobble something meaningful together in the nick of time?
How do you deal with pressure? How should you behave when time is short, and there are obstacles ahead?
In this video, we solve a number of technical issues and prepare for a live demo with the customer. You'll watch us confront unexpected roadblocks, and confusions. You'll see how we respond. You'll recognize the emotions and the temptations.
You'll watch us stumble through the minefield. All the while solving the problem of getting real data on the screen in our minimal web server environment.
Java Case Study → Episode 8, Into the Tunnel
Details
By Robert C Martin and Micah D Martin,Apr 22, 2015,71 min
Description
Tunnel Vision.
We all get it. We get so focussed on what we are doing that we lose the bigger picture. We get so frustrated with the time it takes to arrange all the fiddly little details that we begin to take shortcuts.
This happens a bit in this episode. It's not a disaster. We recover quickly. But still, you can see it happen.
Another interesting occurrence in this episode is the identification of a bug from the subtlest of symptoms. It's actually quite remarkable that we saw it.
And then there's the function we thought was a constructor; but wasn't.
And then there was the unexplained malfunction that we fixed with a magic word.
Yes, this one is fun. It's a bit embarrassing; but it's fun.
Java Case Study → Episode 9, Lost In Space
Details
By Robert C Martin and Micah D Martin,May 19, 2015,70 min
Description
What does C57-D mean to you? What does it have in common with The Naked Gun?
In this episode we struggle for almost two tomatoes with how to manage two very similar data structures. Should they inherit? Should one use the other? Should there be a utility class?
Then we start to reorganize the code and move it into packages. And we debate whether the package principles should be applied or not. We also struggle with the fact that we have not properly partitioned the use cases and presentations.
And then there's that weird bug...
Batman vs. Darth Vader?
Java Case Study → Episode 10, The Persistent Bug
Details
By Robert C Martin & Micah D Martin,Jul 13, 2015,83 min
Description
So this one is interesting. In the process of fleshing out the CodeCast details page, we realize that we need to parse incoming URLs and build a router that selects the appropriate controllers. True to form, we simply write this ourselves rather than depending upon a framework.
Along the way we re-encounter the strange race condition that sometimes causes our tests to hang. We work around this problem, but grow ever more concerned about it.
By the end of the episode we have the architectural framework for many of the elements of a web serving system. And we still aren't using a framework.
Java Case Study → Episode 11, Squashing the Bug
Details
By Robert C Martin & Micah D Martin,Aug 24, 2015,80 min
Description
The the help of Corey Boyle's son (and Corey to some extent) we managed to track down and kill that nasty threading bug.
Actually it was a bug in our tests, not in the production code. Indeed, production code would never have exhibited the problem because production code would have been synchronized by sending messages between the sockets. The problem we were having was that the tests bypassed the normal conversations.
The Clean Architecture begins to appear.
After fixing the bug, we started to break up the silly main program that was putting up the front page. We moved part of it to a CodecastSummariesController, and more to a CodecastSummariesPresenter, and a CodecastSummariesView.
We were driven to do this by the need to write a unit test for for the Controller. You'll see this in the video. Every time we tried to add something to the test, we decided to refactor the code a bit more to make it more testable.
You might infer that this was caused by a lapse in our TDD discipline. That's not quite true. It was really caused by taking test code and turning it into production code; and then partitioning that code into the desired architecture.
Anyway, If you've been wondering where the Clean Architecture was in the last 10 episodes; you'll begin to see it appear here.
The transition isn't complete. We've got more to do in the next episode. But it's coming.
Java Case Study → Episode 12, Do Easily
Details
By Robert C Martin & Micah D Martin,Sep 24, 2015,93 min
Description
Everything started fine. We had a nice design discussion on the whiteboard about pulling the taffy threads of our application apart. We even got IntelliJ to show us the UML of the design as it existed, so we could compare it to the ideal.
But then, in the transition from UML to code, something happened. I couldn't adjust the speed of my brain properly. My brain was going too fast for the code. And so I started making silly dumb mistakes.
We made some progress in tomato 1, but not as much as we should have because we kept having to backtrack due to my brain overruns.
So we slowed way down in tomato 2 to try to resync my brain with the proper rate of code. And this worked pretty well. By tomato 3 everything was back to normal.
We made some very interesting decisions in this episode. We established a target architecture. We determined the difference between our current design and that target. And we started along a pathway to get from one to the other. -- And we got our brains going at the right speed.
And, perhaps most importantly, we engaged The Discipline of D. E (Do Easy).
Java Case Study → Episode 13, Flub-a-Dub
Details
By Robert C Martin & Micah D Martin,Oct 22, 2015,95 min
Description
As we pursue the architectural refactoring of the application, I make a silly mistake in the diagram on the board. And for two and a half tomatoes we don't spot it. Yikes!
This doesn't invalidate the work we do. And much of it is good. But it does create a kind of "friction" that we both feel and can't quite explain.
This is a reality show. This kind of thing happens in real life. It's frustrating. It's embarrassing. But it's real. And it's educational.
And, of course, there's lot of other things to learn in spite of the flub.
1 We talk about mocking tools.
2 We talk about dynamic vs static languages.
3 We talk about refactoring strategies.
4 We talk about big design vs TDD.
And, in the end, we have a lot of fun. Because, after all, programming is the second most fun thing in the world!
Build an App With Corey Haines
BAWCH → Episode 1, Where Do We Start?
Details
By Corey Haines,Jan 14, 2013,43 min
Description
Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
So, you've figured out what features you NEED to build. But now you have the problem of deciding which one to do first. And once you've decided, how do you go about building it? You could, of course, start with an easy one, like user management. But what value would that add? Or, perhaps you'll start with one that suits your mood. But does that add value? Maybe start building a data model diagram? Aaargh! How to decide?
In our first episode of "Build An App With Corey Haines" (lovingly referred to as BAWCH), we'll discuss just this question: where do we start. We'll talk about the fuzzy idea of "business value" and introduce a technique called Feature Support Diagrams. When finished, FSD diagrams literally have arrows pointing to the feature where you should start. And once we've chosen, we'll begin building. We'll look at creating our first two scenarios using Cucumber, then making them pass using a "Programming by Wishful Thinking" outside-in style of development.
Along the way, we'll discuss a lot of the little decisions around starting, all the while moving forward towards our first usable feature.
After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
BAWCH → Episode 2, Finishing Our First Feature
Details
By Corey Haines,Apr 2, 2013,56 min
Description
Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
In our last episode (check it out here), we got the basic skeleton of our first feature done with some dummy data. In this episode, we'll finish our feature "Viewing Running Coderetreats" by pushing our dummy data down into our stack. In the end, our dummy data will disappear, and we'll be left with a complete full-stack implementation, from browser to database. As we finish, we'll see how the use of "Programming by wishful thinking" in the last episode set us up nicely to see exactly what our next steps are.
Along the way, we'll begin our conversation about testing. Of course, testing techniques and strategies will be a point of discussion through the whole series, and this episode begins our dive into a better of understanding of the topic. We'll discuss a definition of the difference between test-first and test-driven development, and how these differences affect our strategy.
Fast tests are a big point of discussion these days, so we'll look at a couple initial ways to achieve them in Rails. Just as importantly, we'll spend time talking about the WHY behind fast tests and try to clear up some common misconceptions about the goals.
After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
Missed the first episode? Get it here: - Episode 1 - where do we start?
BAWCH → Episode 3, 2nd Feature
Details
By Corey Haines,May 21, 2013,61 min
Description
Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
Now that we've finished our first feature, where do we go from here? In episode 3 of "Build an App with Corey Haines" we'll not only talk about how our Feature Support Diagram can help us choose the next feature, but we'll dive right in and start it. This episode is all about the code, so we won't be satisfied with just starting it, we'll take it to the finish!
While building this new feature, "Updating the status of a coderetreat", we'll use a strict outside-in approach to our coding. Starting at the view layer and moving inward with a hearty dose of programming by wishful thinking, we'll see more and more of our design coalesce around our domain concepts. Our last episode introduced the concept of a presenter, distancing our business domain away from the Rails framework. In this episode, we'll benefit again from this philosophy, except on the updating side, creating a simple coordinator object.
In Episode 1 and Episode 2, we noticed some awkwardness around some names we chose. At the time, we postponed fixing them until we had more knowledge about our domain. In this episode, we'll see awkward names again, but this time we won't stand for it! After implementing the feature, we'll take time to clean up our design by extracting a new resource. We'll discuss the strategy of making structural changes incrementally, keeping our system working at each step. This is a coding series, so we won't just discuss it, we'll put hands to keyboard and make the changes!
And, of course, there is plenty of ongoing discussion about outside-in development, programming by wishful thinking and how our tests can influence our design. Check it out!
After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.
Missed an episode? Get them here. - Episode 1 - where do we start? - Episode 2 - our first feature
BAWCH → Episode 4, Eliminating Duplication
Details
By Corey Haines,Aug 23, 2013,50 min
Description
"Duplication is the root of all evil!" is a phrase we certainly hear a lot in software development. This is a bit harsh and over-the-top, of course, but it definitely is something we want to keep watch on. Eliminating duplication when we find it, early on in our lifecycle, is a good technique to master. It makes our software more accepting to change in the future, especially change we aren't able to anticipate.
Through our previous episodes, we allowed a bit of duplication to spread regarding the states that a coderetreat can be in. If we let this go on for much longer, it will become much more difficult later to change them. It is time to put our foot down and remove this duplication. When working on a new system, timing is the key and we won't wait any long to address this cleanup task.
In this episode, we'll take a break from adding new features and focus our attention at the concept of duplication, specifically the duplication of knowledge around the statuses of the coderetreats. We'll discuss the different types, and then investigate two different methods for eliminating it by isolating the knowledge it represents: an outside-in, wishful-thinking approach; and, an inside-out, pull-down approach. By the end of the episode, we'll have a central location in our system that contains this information.
And, of course, there is a lot of coding. The results of this episode's coding is in the git repo up on github.
Once you purchase the episode, send an email to Corey and get an invite to the "Discuss BAWCH" mailing list.
If you've missed any of the first 3 episodes, check them out here:
• Episode 1
• Episode 2
• Episode 3
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.