Core Java Volume 2 12th Edition Pdf Github
Dionne
This course moves fast, so I encourage you to keep up with the reading and programming assignments. If you get behind, it can be difficult to catch up. If you have any problems or questions, please come talk to me or the TA as soon as possible so that we can help.
There may be times when your background has holes relative to your classmates. In these situations, you should certainly seek extra help, but you will at times be expected to do a certain amount of reading and learning on your own. If you are unwilling to do this, you should consider dropping the course.
Let's talk about pair programming, because that happens for several assignments in this class. You may choose your pairs, but each pair must be unique throughout the semester. That means that you can only have a given partner for one assignment. Feel free to talk about partnering in class or use Ed Discussion to look for partners. Programming is a social activity!
Collaboration is a very good thing. On the other hand, plagiarism or cheating is considered a very serious offense. Please don't do it! Concern about cheating creates an unpleasant environment for everyone. We will use technological means including Stanford Moss and other means to detect cheating.
Protect Your Code: Do not leave your laptop unlocked. This is a good practice for security purpose as well. Also never post your code for the assignments online such as Github, Gitlab, etc.
Group Work Policy: You are free to discuss the course material and all aspects of the group assignments with your teammates/partner, but teams are expected to make clear their division of labor for each aspect of the project. Students are expected to do individual work on their portion of the project.
Discussion within/without teams is permitted, indeed, encouraged! You can learn a lot from others; you can avoid getting stuck; and teaching someone else can be the best way to cement your own understanding. You may have discussions with anyone you like, including other students following the rules and guidelins below.
Gillian's Island Rule This rule says that you are free to meet with fellow student(s) and discuss assignments with them. Writing on a board or shared piece of paper is acceptable during the meeting; however, you should not take any written (electronic or otherwise) record about the assignment away from the meeting. This applies when the assignment is supposed to be an individual effort or whenever two teams discuss common problems they are each encountering (inter-group collaboration). After the meeting, engage in a half hour of mind-numbing activity (like watching an episode of Gilligan's Island), before starting to work on the assignment. This will assure that you are able to reconstruct what you learned from the meeting, by yourself, using your own brain.
Code Reuse: The code you submit should be your own. The only exceptions: You may use code (with attribution) from our primary textbook and from the Java standard libraries. You must write up anything you submit on your own: Your code (which includes tests and documentation), problem answers, etc. must represent your own understanding, as explained solely by you, and your team members for the group assignments.
You may not view other people's code or solutions beyond your teammates: You may not share any of your own code (including, as always, tests and documentation) with others, including bringing it to a meeting with others. You may not allow anyone except the course staff to view/access your code. Don't post large amounts of your code (more than about 5 lines) to the forum.
As an exception to the prohibition against viewing another student's work, you are permitted to assist another student with tool-related problems (such as difficulty using IntelliJ, etc.), even if such assistance results in incidental viewing of snippets of code. But, regardless, each student is expected to write and debug the assignment code individually. Debugging your code is not a tool-related problem.
You may not represent someone else's work as your own: You must give credit where credit is due. When you turn in assignments, you must list everyone with whom you've had substantive discussions. Likewise, if you obtained a key idea from some other resource, such as a textbook or a website, then you should credit it.
You may not view and/or use any substantive material or solutions from similar assignments this term or previous terms at UT Austin or elsewhere, including anywhere on the Internet, transcribing solutions from any other source, etc.
It's about your integrity, not just your grade: Integrity is crucial to a working engineer. Computing is at the core of almost all societal systems, and its discrete nature makes it especially unforgiving. Software has been responsible for death and damage. If you cut corners in your work, or are unprepared for it, then you, too, could cause such problems. We expect you to show high ethical standards in CS 314 H, and in the rest of your career. Accordingly, violation of academic honesty (for instance, by cheating or by collaboration beyond what is permitted) will be taken very seriously.
No devices: I ask you to power down all phones for the exam. That does not mean putting the phone away, but it means actually powering it down. For exams given on Canvas the assumption is that you have a web browser open with a single tab that shows the exam. Accessing the Internet in any way during the exam is not allowed and will be considered cheating.
Summary sheet: The exam is closed book and closed notes. But you can bring a single, double-sided 8x5x11 inch paper to the exam. The sheet can be handwritten or it can contain printing in at least 10pt font. It may NOT contain a printout of "handwriting" from an iPad, any writing must be created by physical pressure on the receiving medium. I sort of can't believe that I have to spell this out but I do. My point is that the process of choosing and writing is useful. If you just take a picture of page and shrink it, you do not get the benefit of curating the information you bring to the exam.
Slip days: Every student gets 4 slip days for the semester, to be used when you want. If you turn in an assignment 5 minutes late, you can use a slip day so that it is no longer late. Slip days cannot be split up. You do not have to use all of your slip days.
Mail to you: You are responsible for regularly checking (at least every 24 hours) both your CS email and your email officially registered with UT for class work and announcements. Your CS address may be forwarded to another account (see ).
Office Hours: Please visit the staff during office hours if you have anything you'd like to discuss about the course or course materials. If the office hours are not convenient, then send email to schedule an appointment. It is most helpful if you suggest several times when you are available.
Constructive Comments (aka no "whining"): We always welcome feedback and comments about the course. We are excited to have you in the course building and improving the course together. Please remember to be constructive when making comments either privately or publicly. We all know whining is counter-productive, will only irritate the course staff, and will negatively impact other students. git source code management The course uses thegit software version control system. You can find a lot of tutorialinformation for git on the Internet. For example, here is a nicevisual tutorial on git branching, and here is a nice description of the model, and here is a very basic tutorial. More resources here.
We will post an invitation link on the discussion site for each programming assignment. Github will create a repo for you after you accept the assignment. The repo will contain a directory with starter code for the exercise. You can open this project directory in your code editor or integrated development environment (IDE). Inside this directory will be a README file that you need to fill in (e.g., with your eid). The name of your repository will have your github id. If your github id is supercoder, then you will clone prog1-supercoder. If we need to correct anything about the starter code, we will post it to the discussion site. Unfortunately, we can't change the starter code and push the changes to y'all.
We want to help you by answering your questions! We would much rather that you ask us than that you waste your time in confusion and frustration. Here we suggest some ways to make your question more likely to elicit a useful answer. The two key points are to explain what you know and to explain what you have tried.
When NOT to ask questions? When you haven't tried to solve it yourself. You shouldn't ask a question until after you've at least tried to solve it yourself. As a general rule, that is actually good advice: sometimes you'll solve it on your own and, in any case, you can provide much better information about the problem. That information will make it much more likely that you quickly get a useful answer. Otherwise, someone might just suggest something you have already done, or might be confused about your problem.
When to ask questions? When you are stuck! It's great to make some headway on your problem before asking a question. But, stop when you are no longer making headway! If you get stuck, then stop wasting your time and get help from someone else. We definitely don't want you to waste your time in frustration, afraid to ask a question. Just explain what you know and what you have tried and ask the staff (or others) for help. Oftentimes there is a simple answer that can get you going again.
c80f0f1006