QUESTIONS C S 3 5 1 - D e s i g n o f L a r g e P r o g r am s LAST TIME: - Was no last time this is the first time TODAY: - Administrivia - Rant: Who are you - Do you have TDD? - Refactoring 1: The exploding class HOMEWORK DUE >>BY CLASS THURSDAY<<: (1) Read the syllabus and sign the declaration! You need a PIN! (2) Read for discussion: http://paulgraham.com/gh.html - How is he wrong? (3) Read http://junit.sourceforge.net/doc/testinfected/testing.htm HOMEWORK DUE >>TUESDAY AUG 27TH AT 9AM<< - Test and implement the DeathBox as discussed below If you can't read this you're too far away! QUESTIONS C S 3 5 1 - D e s i g n o f L a r g e P r o g r am s LAST TIME: - Was no last time this is the first time TODAY: - Administrivia - Rant: Who are you - Do you have TDD? - Refactoring 1: The exploding class HOMEWORK DUE >>BY CLASS THURSDAY<<: (1) Read the syllabus and sign the declaration! You need a PIN! (2) Read for discussion: http://paulgraham.com/gh.html - How is he wrong? (3) Read http://junit.sourceforge.net/doc/testinfected/testing.htm HOMEWORK DUE >>TUESDAY AUG 27TH AT 9AM<< - Test and implement the DeathBox as discussed below NINETY-NINETY RULE n. "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." QUESTIONS C S 3 5 1 - D e s i g n o f L a r g e P r o g r am s LAST TIME: - Was no last time this is the first time TODAY: - Administrivia - Rant: Who are you - Do you have TDD? - Refactoring 1: The exploding class HOMEWORK DUE >>BY CLASS THURSDAY<<: (1) Read the syllabus and sign the declaration! You need a PIN! (2) Read for discussion: http://paulgraham.com/gh.html - How is he wrong? (3) Read http://junit.sourceforge.net/doc/testinfected/testing.htm HOMEWORK DUE >>TUESDAY AUG 27TH AT 9AM<< - Test and implement the DeathBox as discussed below Rule #1: You're going to need more time. QUESTIONS C S 3 5 1 - D e s i g n o f L a r g e P r o g r am s LAST TIME: - Was no last time this is the first time TODAY: - Administrivia - Rant: Who are you - Do you have TDD? - Refactoring 1: The exploding class HOMEWORK DUE >>BY CLASS THURSDAY<<: (1) Read the syllabus and sign the declaration! You need a PIN! (2) Read for discussion: http://paulgraham.com/gh.html - How is he wrong? (3) Read http://junit.sourceforge.net/doc/testinfected/testing.htm HOMEWORK DUE >>TUESDAY AUG 27TH AT 9AM<< - Test and implement the DeathBox as discussed below Rule #1: It's going to take longer than that. QUESTIONS C S 3 5 1 - D e s i g n o f L a r g e P r o g r am s LAST TIME: - Was no last time this is the first time TODAY: - Administrivia - Rant: Who are you - Do you have TDD? - Refactoring 1: The exploding class HOMEWORK DUE >>BY CLASS THURSDAY<<: (1) Read the syllabus and sign the declaration! You need a PIN! (2) Read for discussion: http://paulgraham.com/gh.html - How is he wrong? (3) Read http://junit.sourceforge.net/doc/testinfected/testing.htm HOMEWORK DUE >>TUESDAY AUG 27TH AT 9AM<< - Test and implement the DeathBox as discussed below Rule #1: You're late. Start now. ADMINISTRIVIA - Attendance - Opening-day handout ADMINISTRIVIA - Attendance - Opening-day handout: READ IT - Be sure to SIGN and RETURN the back page, and pick a PIN ADMINISTRIVIA - Goals - The rest of Java, 1.6/6.0 (but: Java 7 has been out since _2011_) - Design + algorithms + the craft of programming ADMINISTRIVIA WARNING: NO AUDITS NO AUDITS GO FOR CR/NC EARLY IF YOU NEED TO, BUT NO AUDITS ADMINISTRIVIA WARNING: NO AUDITS NO AUDITS GO FOR CR/NC EARLY IF YOU NEED TO, BUT NO AUDITS THIS CLASS IS ABOUT 'OWNING' THE JAVA PROGRAMMING PROCESS ADMINISTRIVIA WARNING: NO AUDITS NO AUDITS GO FOR CR/NC EARLY IF YOU NEED TO, BUT NO AUDITS WARNING: THIS CLASS IS ABOUT 'OWNING' THE JAVA PROGRAMMING PROCESS PROGRAMMING TAKES TIME EVEN IF YOU DO IT RIGHT DEBUGGING TAKES FOREVER UNLESS YOU DO IT RIGHT ADMINISTRIVIA WARNING: NO AUDITS NO AUDITS GO FOR CR/NC EARLY IF YOU NEED TO, BUT NO AUDITS WARNING: THIS CLASS IS ABOUT 'OWNING' THE JAVA PROGRAMMING PROCESS PROGRAMMING TAKES TIME EVEN IF YOU DO IT RIGHT DEBUGGING TAKES FOREVER UNLESS YOU DO IT RIGHT WRITING TESTS IS BETTER AND FASTER THAN DEBUGGING WHO ARE YOU? WHAT'S YOUR TRAP? WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather - Back-To-School Recurver - True Hacker - Wannabe - SysAdmin - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver - True Hacker - Wannabe - SysAdmin - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver -> Time? What's that? - True Hacker - Wannabe - SysAdmin - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver -> Time? What's that? - True Hacker -> Actually graduating is boring - Wannabe - SysAdmin - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver -> Time? What's that? - True Hacker -> Actually graduating is boring - Wannabe -> Not admitting aintyet - SysAdmin - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver -> Time? What's that? - True Hacker -> Actually graduating is boring - Wannabe -> Not admitting aintyet - SysAdmin -> Just a SMOP - Whichever Pays The Moster WHO ARE YOU? WHAT'S YOUR TRAP? - Classic Golden Pather -> Hitting the wall - Back-To-School Recurver -> Time? What's that? - True Hacker -> Actually graduating is boring - Wannabe -> Not admitting aintyet - SysAdmin -> Just a SMOP - Whichever Pays The Moster -> Worry: .in/.cn/.ru; Reality: Burnout INTRODUCTION - Mechanics Hacking Projects Getting help Lectures Labs - TA Office hours: Instructor, TA Email Asking questions Web page - http://www.cs.unm.edu/~ackley/351/ INTRODUCTION - Mechanics Hacking Projects Getting help Lectures Labs - TA Office hours: Instructor, TA Email - Some answers may go to the list, w/o including asker's name. Asking questions Web page - http://www.cs.unm.edu/~ackley/351/ INTRODUCTION - Mechanics Grading Structure: 50% TESTING 25% Exams and in-class quizzes 15% Labs: Attendance, exercises, quizzes 10% Crits 50% PROGRAMMING = 30% individual projects 20% group project --- 100% INTRODUCTION Copying (aka CHEATING) From other students From other sources RL vs this class INTRODUCTION Copying (aka CHEATING) From other students From other sources RL vs this class `but I WROTE it all myself!' ==> At BEST: One Design, One Grade INTRODUCTION Copying (aka CHEATING) From other students From other sources RL vs this class `but I WROTE it all myself!' ==> At BEST: One Design, One Grade YOU HAVE BEEN WARNED INTRODUCTION - The labs = Focusing on the craft: Not just the what and why but the how = Labs / activities / quizzes / tools = Extreme Programming = Pair programming = Etc. = 15% of the class credit will be found in the labs! INTRODUCTION - The group project: 20% Self-selected groups of 3 or 4 different sets of DNA. Not 1 or 2 or 5. Who you work with will almost surely make a tremendous difference in your results! Groups will be officially formed around week 7 but start sniffing around for group members NOW! INTRODUCTION - The group project: 20% Self-selected groups of 3 or 4 different sets of DNA. Not 1 or 2 or 5. Who you work with will almost surely make a tremendous difference in your results! Groups will be officially formed around week 7 but start sniffing around for group members NOW! There's just no substitute for ability INTRODUCTION - The group project: 20% Self-selected groups of 3 or 4 different sets of DNA. Not 1 or 2 or 5. Who you work with will almost surely make a tremendous difference in your results! Groups will be officially formed around week 7 but start sniffing around for group members NOW! There's just no substitute for reliability INTRODUCTION - The group project: 20% Self-selected groups of 3 or 4 different sets of DNA. Not 1 or 2 or 5. Who you work with will almost surely make a tremendous difference in your results! Groups will be officially formed around week 7 but start sniffing around for group members NOW! There's just no substitute for compatibility INTRODUCTION - Books The Java(TM) Programming Language (4th Edition) Arnold, Ken, and Gosling, James, and Holmes, David, Addison-Wesley 2006 0321349806. INTRODUCTION - Books The Java(TM) Programming Language (4th Edition) Arnold, Ken, and Gosling, James, and Holmes, David, Addison-Wesley 2006 0321349806. Filthy Rich Clients, Haase, C, and Guy, R. Addison-Wesley 2007 Core Java 2: Volume 1, Fundamentals, 7th Ed Hortsmann, C.S. and Cornell, G. Sun Microsystems Press, 2005 Refactoring: Improving the Design of Existing Code, Kent Beck, John Brant, William Opdyke, and Don Roberts. Addison-Wesley, 1999. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Ed Martin Fowler Addison-Wesley 2003. Effective Java Joshua Bloch Addison-Wesley, 2001. INTRODUCTION - Books The Java(TM) Programming Language (4th Edition) Arnold, Ken, and Gosling, James, and Holmes, David, Addison-Wesley 2006 0321349806. Filthy Rich Clients, Haase, C, and Guy, R. Addison-Wesley 2007 Core Java 2: Volume 1, Fundamentals, 7th Ed Hortsmann, C.S. and Cornell, G. Sun Microsystems Press, 2005 Refactoring: Improving the Design of Existing Code, Kent Beck, John Brant, William Opdyke, and Don Roberts. Addison-Wesley, 1999. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Ed Martin Fowler Addison-Wesley 2003. Effective Java Joshua Bloch Addison-Wesley, 2001. - Schedule: Two substantial individual projects and one group large project ** Individual Project 1, likely out next Tuesday ** TDD - TEST DRIVEN DEVELOPMENT - Old days: Tests are a poor substitute for proofs of correctness! = "Tests can only expose flaws, they cannot prove there are no flaws" TDD - TEST DRIVEN DEVELOPMENT - Old days: Tests are a poor substitute for proofs of correctness! = "Tests can only expose flaws, they cannot prove there are no flaws" - New days: = Tests are like executable partial specifications TDD - EXAMPLE: TESTING THE DEATHBOX Someone gives you a 'spec'. They say: ------- Here are the rules for putting things into the DeathBox: 1. If you put anything that's not an integer, or a String containing an integer, into the DeathBox, you die. 2. If you put anything outside 6 to 60 into the DeathBox, you die. 3. If you put anything into the DeathBox that's more than three times the last thing put into the DeathBox, you die. 4. If you put the same thing into the DeathBox more than three times, you die. 5. You can't put anything into the DeathBox after you've died. 6. If the thing you put into the DeathBox doesn't cause you to die according to the rules 1-5, then you live. ------- TDD - EXAMPLE: TESTING THE DEATHBOX and they say, 'Here's the DeathBox interface -- ----------- package com.putable.deathbox; /** * The interface presented by a DeathBox, into which only some * objects may be safely put, otherwise you die. * * @author ackley * */ public interface DeathBox { /** * Attempt to put another object into a DeathBox. * * @param o the object to attempt to place in the DeathBox * @return true if o was put into the DeathBox successfully, and * false if 'you died' attempting to put it in (or were * already dead before the latest putInto attempt). */ public boolean putInto(Object o) ; } ----------- WARMUP EXERCISE: TESTING THE DEATHBOX - PURPOSE AND RESOURCES DUE TUESDAY AUG 27TH AT 9AM VIA ONLINE TURNIN Goals of the warmup exercise: (1) Review/ramp up on 'real world' Java concepts: testing and JUnit.. packages and packaging.. interfaces vs classes.. (2) Deconstructing specs, finding corner cases, etc (3) Get the hacking fingers going (4) Prove you have a PIN and can work the online stuff Resources: http://www.cs.unm.edu/~ackley/351/DeathBox.jar contains tons of stuff, including - DeathBox.java -- the DeathBox interface, in package com.putable.deathbox - DeathBoxImpl.java -- a class purporting to implement the DeathBox interface (but doing a pitiful botch of a job) - DeathBoxImplTest.java -- a JUnit.TestCase class purporting to test class DeathBoxImpl (but doing such a bad job that it claims that DeathBoxImpl is OK..) - Various doc and so forth Feel free to use any of those *Impl*.java files to get started if you want. DON'T modify DeathBox.java itself IN ANY WAY. WARMUP EXERCISE: TESTING THE DEATHBOX - SAMPLE TEST CODE DUE TUESDAY AUG 27TH AT 9AM VIA ONLINE TURNIN // DeathBoxImplTest.java package com.putable.deathbox; import junit.framework.TestCase; public class DeathBoxImplTest extends TestCase { private DeathBox deathBox; public void setUp() { deathBox = new DeathBoxImpl(); } /* * Test method for 'com.putable.deathbox.DeathBoxImpl.putInto(Object)' */ public void testPutInto() { assertTrue(deathBox.putInto(new Integer(24))); assertTrue(deathBox.putInto(new Integer(42))); } } WARMUP EXERCISE: TESTING THE DEATHBOX - TURNIN DETAILS DUE TUESDAY AUG 27TH AT 9AM VIA ONLINE TURNIN - Specific turn-in mechanics announced Thursday = But you will need the PIN you selected on your student declaration! - You will produce exactly three files: DeathBoxImpl.java Containing class DeathBoxImpl that implements com.putable.deathbox.Deathbox as correctly as you can make it. DeathBoxTest.java Containing class class DeathBoxTest that tests _ANY DeathBox_ as thoroughly and completely as you can make it, using JUnit 3.8x or 4 (your choice). -> In other words, you can ONLY test what the SPEC SAYS a DeathBox should do, not anything extra that's true of your DeathBox spec-problems.txt Containing text describing any problems, contradictions, incompletenesses, and/or ambiguities you encountered in the DeathBox spec, and how you chose to resolve them in your tests & implementation