Hello everyone, my name is Zhewei Hu. I am a site reliability engineer at Pinterest. Before that, I was a Ph.D. student under the direction of Dr. Ed Gehringer. I was the teaching assistant for the Object-Oriented Design and Development (OODD) course, aka. CSC/ECE 517 for more than 4 years. I’d like to share some of my experience to help you conquer this course and get A+ (There are 1000 regular credits with many extra credits. If you could get 970 credits or more, you will receive an A+.). I will discuss my experience based on the syllabus and make the content as short as possible. This is the first part.

Part I - Homework (405 pts)

Programs (325 pts)

Ruby program (35 pts)

• You are required to solve LeetCode-like problems in Ruby.
• Teaching staff will use automated tests to test your code. If your programs pass all tests, you will get full credits.

Ruby on Rails program (70 pts)

• Please start as soon as possible.
• Try to meet all the requirements including extra-credit ones (trust me, they are not difficult).
• Most of the time, the UI does not need to be pretty unless explicitly mentioned in the requirements.
• Deploy your application to one cloud platform. Heroku is a good choice.

OSS project (80 pts) and Final project (140 pts)

• Please start as soon as possible.
• If you have any questions, please ask your mentor.
• Please read the general requirements at the top of project docs. It may only take 5 minutes, but you can earn 3-5 points or even more after reading.
• Please make sure your code pass the Travis CI. If you make some changes to the source code, please also change the corresponding tests.
• Please resolve the CodeClimate issues as many as you can. Some issues, such as abc complexity, can be ignored. You could ask teaching staff to approve these issues.

Writing assignments (80 pts)

• Please do not include the introduction to Expertiza. This is redundant and the professor does not like it.
• Please do not paste many code to the wiki page since we already have GitHub pull requests.
• Please fit your screenshots to the wiki page.
• If your project relates to UI changes, it is a good idea to manually change the html code and make screenshots to show the final version of the UI to the reader (although you haven’t written any code when writing the wiki page).
• User stories are a good ways to show the whole functionality.
• Please refer to wiki pages in previous years.

Part II (595 pts)

• Link

/end