Introduction to Java Programming with Mr. Ferrante

Cupertino High School, August 2011

Course Description

Welcome to Mr. Ferrante’s Introduction to Java Programming! The goal of this course is to introduce students to a variety of programming concepts and techniques leading up to an introductory knowledge of the Java programming language. First semester will be spent learning programming concepts through media-based programming tools such as Scratch, StarLogo, Alice, and Greenfoot. Second semester will take more traditional approach to Java once the concepts have been learned first semester. Both semesters will cover data types, conditional statements, iteration, recursion, arrays, lists, etc, along with computer science concepts such as searching and sorting algorithms, parity checks, binary and hexadecimal number systems, run-length encoding, etc.

By the end of the year students will

· Understand the design, structure, and coding practices of object-oriented programming

· Design and implement computer based solutions to applied problems

· Create custom programs / video games from initial concept to completed project

· Apply programming concepts in a variety of environments

· Understand concepts involved in programming traditional searching and sorting algorithms

Grades

Grades are weighted as follows: Labs & Homework 50% Tests/Quizzes 50%

A ³ 90% B ³ 80% C ³ 70% D ³ 60% F < 60%

Homework and Academic Honesty Policy

You are encouraged to work with other students throughout this course. Note however, that there is a difference between helping someone and giving them your solution. And there is a difference between learning from someone else’s code and using their ideas versus copying their code. There will be a few large projects this year where you will be encouraged to copy code and build upon it, but unless explicitly told you are expected to come up with your own solutions to problems. If you are copying code or partial code for an assignment that is meant to be done individually, you are not doing the right thing and you may be cited for a cheating violation. You will find that a large portion of your time second semester will be spent debugging your programs. For debugging, you must spend time yourself finding your errors. Doing so is an important part of the learning and growth process. But don’t spin your wheels forever. After spending honest time searching for your errors, if you can’t find what’s wrong, it’s ok to seek the help of another student. You may even send another student your code to review. If you receive such help, you must reference what the error was and who helped you within your program documentation. And the other student must not modify your code or fix the problem for you. He/she should explain what the error is so that you can understand it and fix it yourself. Once the problem is solved, the student should remove the file from his/her computer. If you struggle to complete an assignment or life gets too busy, you have the option of turning your program in for late credit. You still get a B for one day late and a C for up to a week late. After that, it’s a zero. If you need an extension, please tell me about it on the assignment’s due date. Just don’t give up and turn in your own version of someone else’s code. It doesn’t pay off. Using someone else’s code as part of yours or as a template is considered cheating and will get you in more trouble than you realize.

Supplies

· A computer at home with the following software installed:

o Java SE Development Kit (JDK), latest release

o Scratch from MIT

o StarLogo TNG

o Greenfoot

o BlueJ

o Internet access

· “Composition” notebook for notes and warm-ups

· Having a laptop with wireless access is useful but not required.

Help

Besides the millions of online help pages and tutorials, I’m available during tutorial, and from halfway through 7^th period to 4pm. Additionally, we’ll have an online Discussion Board to answer questions and have everyone help each other.

Tardy Policy and Classroom Rules

Tardies

You are allowed three tardies each quarter. A fourth tardy and every second tardy thereafter earns a 30-minute detention with the office.

Attendance

Either come to class every day or drop the class. For a legal absence, you have as many days as you were absent to make up homework and you are additionally responsible for keeping up with the current homework. If you miss class to participate in a school activity, you are fully responsible for obtaining and completing regular homework. You are not allowed to makeup or turn in homework for unexcused absences.

Cell Phones, CD Players, etc.

If you carry them in your backpack and the sound is turned off, that’s fine. However, if I see or hear anything, it’s my job to turn them in to the office. I hold the school record for cell phones confiscated.

Parents

Please feel free to contact me whenever you have questions or concerns. E-mail is the best way to reach me: eric_ferrante@fuhsd.org. You can also leave me a voice message at school: 366-7388 x4845. If you have Internet access, please register for School Loop. Most of your student’s teachers will be using it for communication. Register at http://cupertino.schoolloop.com.

Student Signature ____________________ Parent Signature ____________________

Student Name _______________________ Parent Name _______________________
(Print) (Print)

Visit

http://www.MrFerrante.com

Homework and Academic Honesty Examples

The general guideline is that you may learn from others and teach each other but not at the expense of turning in work that is someone else’s or compromising the intended goal of you solving a problem yourself.

Writing your own code

BAD You copy someone else’s program and turn it in as your own.

BAD You copy someone else’s program and but change it to look like you did it yourself.

BAD You write your own program but get stuck with one or two parts. Someone else in the class already has a solution to those parts so you copy those parts without saying anything about it.

GOOD You write your own program. It’s not the best, but it works.

GOOD You write your own program. It’s not the best, and it doesn’t work. But you tried. If this happens it’s ok. Just explain what the problem is in your program documentation.

GOOD You write your own program. It’s not the best, but it works. You then review another student’s code and see a better approach or technique. Either turn in your ugly code and use the technique you learned next time or turn in both your ugly code and the improved version with documentation on what you learned and who you learned it from.

GOOD You are working on a LARGE project, like a full video game. You spend quality time working out your own ideas first and then you download and check out what other programmers have done and see how they’ve solved the same problems. Excellent! You then write your own program using a combination of your own ideas and those of other programmers. Sweet! You even copy small parts of other programmers’ code and spend time understanding how those parts work. You make it clear which parts of your code you got from where. Building upon the work of others is good. Copying their work as if it were your own is bad.

Debugging

BAD You get stuck and can’t find what’s wrong with your program so you send it to a classmate to review. Your classmate fixes the problem for you and sends it back to you.

GOOD You get stuck and can’t find what’s wrong with your program so you send it to a classmate to review. Your classmate finds the problem and explains what’s wrong and why it went wrong. You understand the problem and fix it yourself. The classmate removes your file from his/her computer.

When You Get Stuck Along The Way

BAD You have code written, but you get stuck with a particular part of the program and don’t understand how to attack the problem. You ask a classmate about it and he/she sends you his/her code. You use his/her idea or code as if it were your own.

GOOD You have code written, but you get stuck with a particular part of the program and don’t understand how to attack the problem. You ask a classmate about it and he/she explains it verbally. You try and get stuck again, so the classmate sends you his/her code. You look it over and a light bulb goes off. You then finish the program on your own and explain who helped you on which section in your program documentation.