1. Prof. Matthew Hertz SH 1029F / 888-2436 hertzm@canisius.edu

2. Objectives Met in CSC212  Develop solution over entire software lifecycle  Implement & test computational solutions  Describe which tools to use & why, given a problem  Know theoretical foundations of computing  Trace & analyze algorithms

3. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques

4. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques

5. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques  Master basic tools needed for all future work  Will cover topics from about 50% of GRE subject test critical  “Data structures critical for good performance”  Have fun

6. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques  Master basic tools needed for all future work  Will cover topics from about 50% of GRE subject test critical  “Data structures critical for good performance”  Have fun

7. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques  Master basic tools needed for all future work  Will cover topics from about 50% of GRE subject test  “Data structures critical for good performance”  Have fun

8. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques  Master basic tools needed for all future work  Will cover topics from about 50% of GRE subject test  “Data structures critical for good performance”  Have fun

9. High-level Objectives  Become programmers, not just “code monkeys”  Working on your own, develop solutions from scratch  Explain your decisions and why they were best choice  Learn common real-world development techniques  Master basic tools needed for all future work  Will cover topics from about 50% of GRE subject test  “Data structures critical for good performance”  Have fun

10. Expectations of Me  Lectures prepared and organized  Give interesting, thoughtful, fun problems  Be (reasonably) available to answer questions  Be honest and forthright

11. Expectations of Me  Lectures prepared and organized  Give interesting, thoughtful, fun problems  Be (reasonably) available to answer questions  Be honest and forthright

12. Why Most Classes Suck

13. Teaching Style

14. Adult Learning  Students read material before class  Answer initial questions at start of class  (Short) lecture explains key ideas  Provides 2 nd opportunity to see material  Also will limit long, boring droning  Students work in teams to solve problems  Make sure you actually understand material  Easy to correct mistakes if caught at the start

15. Adult Learning

16. Expectations of You  Work hard  Come to class prepared  Support & help all your teammates  Ask for help early and often  Let me know what you are thinking

17. Attendance  Attendance is mandatory  Talk to me when you know you must miss class  You are responsible for every class  Missing class is never acceptable excuse  Best way to earn a poor grade: skip class

18. Deadlines  Have 2 virtual “extensions”  Each used to get 1 day extension on assignment  Can use both on single assignment for 48-hour delay  Late work not accepted without extension  If you know you cannot make a deadline, talk to me  Earlier we talk, the better the chance solution possible

19. Grading Philosophy  Grades reflect student's demonstrated ability  Not a competition where grades are relative  I will quite happily give A to entire class, if all earn it  A not automatic just because score is highest in class  Remain fair for students past, present, & future  When in doubt, I consider what most equitable  Hard work alone insufficient to raise a score  Working efficiently important life skill to be rewarded

20. Grading Philosophy Doctor Who Cures YouDoctor Who Works Hard Would you rather have:

21. Course Grading Midterms24% Final25% Quizzes10% Projects18% Weekly Assignments11% Daily Activities6% Templates6%  Grades available via Angel  Midterms given on Oct. 1 st & Oct. 31 st  3 programming projects during semester

22. Course Grading Goals  Learn & build skills used by “real” programmers  Develop understanding needed for future work  Catch and correct problems early  Many ways presenting material during the term  Increases chances that all students can “get it”

23. Course Grading Goals  Learn & build skills used by “real” programmers  Develop understanding needed for future work  Catch and correct problems early  Many ways presenting material during the term  Increases chances that all students can “get it”  I am mean & like watching students suffer

24. Weekly Assignments  Posted on Angel each week  Usually due by 5PM following Tuesday  Virtual extensions okay to use on all but first one  Before submitting, ask me questions you still have  Several goals for these assignments  Provide additional programming opportunities  Reinforce material from each lecture  Questions should seem easy & take under 10 min.  Means you are doing well

25. Templates  Take notes on readings’ important details  Main Angel page links to templates you must use  Notes written by classmates so easier to use  Each template is due before lecture topic is discussed  (Don’t care where you get information from)  Use notebooks during labs & tests  Without notebook, no answers to related questions  Can also use book, but book less useful than good notes  Write 2, but get whole set; notes handed out to class

27. PowerPoint Slides  Students need to take notes on their own  Writing increases odds of remembering ideas  Really, really bad idea to not take notes  Trapped me into specific way of lecturing  Limited opportunities to use clever memory tools  Lectures often resembled

28. Students During Lecture

29. Workings of My Slides  Slides contain many pictures, little text  Lectures interesting & fun (or at least better)  Provides you with good way to reinforce lessons suck  Will suck as actual notes  Print handout & take notes on the side  Write down what the steps animated on the slide  Slides (with notes) actually usable on tests, labs, class…

30. Collaboration  Fellow students are a great resource  Provides multiple viewpoints & understandings  Get together, discuss material, and study  Can have them answer lingering questions  Clarify assignment and what it requires  Learn and practice some basic social skills

31. Collaboration  Work you submit must be done by you  When discussing homework or projects  Leave conversation with memories only  Wait 15+ minutes before starting on your own  Solutions always unique after waiting  Once started, each student should work alone  STEP AWAY FROM COMPUTER  STEP AWAY FROM COMPUTER then talk code

32. Collaboration  Work you submit must be done by you  When discussing homework or projects  Leave conversation with memories only  Wait 15+ minutes before starting on your own  Solutions always unique after waiting  Once started, each student should work alone  STEP AWAY FROM COMPUTER  STEP AWAY FROM COMPUTER then talk code  When in doubt, ask me

33. Coding Help  Will work on testing & debugging skills  To get debugging help in CSC212  Method(s) must be commented (javadoc)  Must use a trace or similar to look for bug  Students find own solution once they start doing this  If problem not fixed, gives us starting point to work  Learn to fix your own errors & not rely on the Professor

34. Textbooks  Goodrich & Tamassia, Data Structures and Algorithms in Java, 5 th Edition, Wiley, 2010. GT  Readings from book listed as " GT " in schedule  Available at bookstore & online (Amazon, etc.)  Will cover about 50% of the textbook  CSC213 looks at other half of the book  Only new textbook for the year

35. Textbooks Horstmann  Readings listed as “ Horstmann " in schedule  Textbook from CSC111 last Spring  Early in term used to review CSC111 concepts  Few Java concepts introduced as we go along, also  But this is your choice, new concepts also in textbook

36. Course Website  Pages for course found on Angel  Handouts, slides, assignments posted before class  Can also find solutions after work is due  May not include everything said in class  Better than nothing, but worse than being here!

37. Ever Have A Bug?  At some point, everyone must fix bug in code  What should you do first after discovering the bug?

38. Ever Have A Bug?  At some point, everyone must fix bug in code  What should you do first after discovering the bug?

39. Ever Have A Bug?  At some point, everyone must fix bug in code  What should you do first after discovering the bug?

40. Ever Have A Bug?  At some point, everyone must fix bug in code  What should you do first after discovering the bug?

41. Ever Have A Bug?  At some point, everyone must fix bug in code  What should you do first second after discovering it?

42. Fixing Bugs  Three common ways students fix bugs:  Guess where error is and make random change  Use Eclipse debugger to run program & find source  Get out your pencil & paper and draw a memory trace

43. Normal Method of Debugging  Also called "debugging-via-drunken-walk" SMALL  Can work for SMALL programs with limited choices  Guessing for millions of lines of code harder  Not at all effective at actually fixing errors  Entire point is to avoid understanding bug's cause  "Fix" may cause other errors later on in program  Cannot prevent future errors using this approach

44. Better Method of Debugging  Could use Eclipse debugger to find and fix bug  Set breakpoints to stop program where bug likely  Use step filters to walk through the program bit by bit  Spend a few hours learning how to make it work  Can get to root of problem once it is executed  But requires executing entire program to trigger bug  Cannot work backward to try and understand why

45. Best Method of Debugging  Generating memory trace has many benefits  Could check algorithm – don’t need any code to try  Can make up situations and just trace a method  Look back through trace to see root cause of bug  Trace code by running it like you were computer  DON’T SKIP STEPS  DON’T SKIP STEPS – easy to (wrongly) assume things  As you go along update variables’ values  GIGO effects limit tracing’s effectiveness

46. Best Method of Debugging  Generating memory trace has many benefits  Could check algorithm – don’t need any code to try  Can make up situations and just trace a method  Look back through trace to see root cause of bug  Trace code by running it like you were computer  DON’T SKIP STEPS  DON’T SKIP STEPS – easy to (wrongly) assume things  As you go along update variables’ values  GIGO effects limit tracing’s effectiveness

47. Benefits of Heap Traces  Draw what actually occurs in memory  Pictures used to debug rather than bare text  Much easier to understand what a method does  Excellent way to learn new programming topics  Scientific studies found improves student grades  Debugging time decreased greatly at same time  Greater support for these traces in Eclipse  Drawing of static trace integrated with debugger  Over this term should see tools improve

48. Starting a Heap Trace  Paper holds 2+1 areas separated by vertical lines  Program stack drawn on one side of page  Other side of page holds the program heap  (Program output shown on page as well)  Objects allocated during run drawn in the heap  Will discuss how this is done next week  Draw frame on top of stack each method call  Fancy name for box labeled with method name  All parameters & local variables added within box

49. Data Types  8+1 primitive data types  Examples: boolean, byte, char, int, double, String *  Only types that work with Java operators  Operators include: +, -, %, &&, ||, >=, <, !  Primitives used natively by computers  Means using them is very quick  Implies greater support within the language

50. Primitive Types  Primitive variables are simple to use  Each variable is “xerox” holding a value  Assignment copies value  Update assigned variable only; changes not reflected

51. Starting a Heap Trace public static void main(String[] args) { String s = “”; for (int i = 0; i < 5; i+=2) { s = s + i; System.out.println(s); } }

52. Announcements  Interested in joining programming team?  Register for CSC299 (0-credit course) & learn more!  Relaxed & ungraded “class” meets Thurs. 4:30 – 5:30  CSC tutoring center starting to ramp up  Starting next week (or so) tutors available in SH1029G  May have limited openings if you know HTML or C++  Consider getting flash drive to hold coursework  Life much easier  Life much easier to use single workspace for year

53. For Next Lecture  Mourn summer’s end & start of homework  Weekly assignment problems start today  For 1 st week of classes, will be due before each lecture  Help you review your Java and get rust out of system  There is reading for Wednesday or  From Horstmann or course’s text (pick one to use)  Chapters listed on Angel & in syllabus