300 - 750 lines of code.5 classesuse PEP8 style
Post your .py file(s) to your GitHub.
Need 1 page proposal of the idea (post to git but also send to me if you want comments).Next week everyone does a very brief (Write a 1 page “self-reflection” that gives you a chance to think about how you learn and how you problem-solved during the project.The purpose of the project is demonstate using Object Oriented Programming - it isn’t to do something really amazing or hard. Code needs to be robust to errors, too.that’s it.
{ "cells": [ { "cell_type": "markdown", "metadata": {}, "source": [ "# W200 Python Fundamentals for Data Science, UC Berkeley MIDS\n", "\n", "# Project 1\n", "\n", "Project 1 is an individual project that will focus on the object-oriented principles. Your project needs to implement object oriented principles and should be interactive so that the user can play around with it. **The code base needs to be entirely composed of objects (at least 5 should be in your creation) and should be called from the command line as a .py file so it can be easily ported to to a production scenario.**\n", "\n", "Some examples:\n", "\n", "- A popular board or card game\n", "- A flower shop (you create and manage inventory, a simple cash register, etc.)\n", "- An adventure game where characters can do things like 1) explore a world 2) trade with other characters. Coding some element of chance into the world has made these even more interesting\n", "- Something relating to your everyday work, maybe some process you would like to model or code up\n", "- Look at our [showcase](https://github.com/UCB-INFO-PYTHON/MIDS_python_showcase) of previous projects to get inspiration \n", "\n", "## Project Phases & Due Dates\n", "\n", "Due dates are as follows - place each requirement in your github repository under the /submissions/project1 folder:\n", "- Week 1: Project Design Document - Rough Idea\n", " - Feel free to email your section instructor with your project idea (a paragraph or two) for feedback. Include what objects you think you will use.\n", "- Week 2: Finalize Design Document \n", " - Push your design document (in pdf) to your GitHub repository by 11:59PM PST the day before class, week of 11-16 October.\n", " - Live session 9 will include breakout rooms where you share code and get peer/instructor feedback\n", "- Week 3 & 4: Code project\n", " - Projects should be complete prior to class. Students will be allowed to update their projects for the next 24 hours after class to make adjustments as needed based on class feedback.\n", " - You will give a 5 minute presentation during your in-person class, week of 25-30 October.\n", " - Push your final code and reflection document (in pdf) to your GitHub repositiory by 11:59PM PST the day **after** class, week of 25-30 October.\n", "\n", "## Design document (10 points):\n", "\n", "For the first step, your assignment is to write up a one to two page design document detailing the project you will be working on over the next several weeks. This is essentially building out the requirements for your project. **Before you begin coding you need to get approval from your section instructor that your project is scoped well enough.**\n", "\n", "In this document, you need to describe:\n", " \n", "- The specifications of the classes you intend to write (at least 5!) \n", " - Briefly describe the purpose of each class\n", " - List expected methods/functions that belong to each class\n", " - List inputs and outputs for each method/function\n", "- How the user will interact with the program / objects\n", "- Include the features that you're going to include in the project and why you think it should be of sufficient complexity to meet the project goals.\n", "- Coding is iterative. Your final code may not match the proposal exactly.\n", "- Please make this document a pdf before uploading to github!\n", "\n", "## Requirements & Limits (80 points)\n", "\n", "You should aim for around 300 to 500 lines of code. You will not be graded on the number of lines of code you write nor will this be a comparison of projects implemented by your peers. For example, a project with 500 lines of code is not guaranteed to do better than a project with 300 lines of code. As we've seen, it's not necessarily the number of lines, it's the value in those lines. Being concise is a good thing and if you're at all worried that you're not going to hit that *soft* requirement please let us know.\n", "\n", "- **This project must be composed entirely of objects, with only scripting outside of objects when absolutely necessary**\n", "- This project must not exceed 750 lines of code\n", " - For example, if you have a text game you can put the text in a separate file\n", " - The line count requirement does not include whitespace or comments (please include both to make your code readable)\n", "- **Your code should be sufficiently complex to require at least 5 separate classes** (but are not likely to need more than 10 classes)\n", "- The objects should be different levels of complexity, for example some may be basic containers and others should manage those containers (i.e. a menu-serving object and/or a game-play object) as well as demonstrating various flow control and data types\n", "- The project will be run from the command line as a .py file.\n", "- The project needs to have a user-interface and be interactive with a user\n", "- The project needs to do some user error checking as well as have a help 'screen' or printed instructions for the user\n", "- All code needs to be well commented with both comments and docstrings\n", "- Without specific permission, you may not use anything outside of the standard Anaconda-installed libraries. \n", "- Please include all references that you used to build out your application.\n", "- **While it is acceptable and even desirable to take inspiration and learn specific syntax from previous projects and stackoverflow code, this code base must be your own work.**\n", "\n", "Please refence the [Projct 1 Tips](https://github.com/UC-Berkeley-I-School/mids-w200-assignments-upstream-fall2021/blob/main/project_1/Project_1_tips.ipynb) document for information on how to package your code. \n", "\n", "\n", "## In-class presentation\n", "\n", "The in-class presentation will consist of you quickly running through your program to show some of the interesting features. Be prepared to show or explain your code if questions arise. Overall the presentation should last about 5 minutes.\n", "\n", "## Reflection Document (10 points)\n", "\n", "When submitting your final code, include a ~one page reflection document containing:\n", "- Instructions about how we should go about testing and using your project\n", "- What you completed and anything that you didn't complete in the project that you would finish later\n", "- Discuss challenges you faced and how you overcame them\n", "- Please make this document a pdf before uploading to github!\n" ] } ], "metadata": { "anaconda-cloud": {}, "kernelspec": { "display_name": "Python 3", "language": "python", "name": "python3" }, "language_info": { "codemirror_mode": { "name": "ipython", "version": 3 }, "file_extension": ".py", "mimetype": "text/x-python", "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", "version": "3.8.8" } }, "nbformat": 4, "nbformat_minor": 1 } { "cells": [ { "cell_type": "markdown", "metadata": {}, "source": [ "# Project 1 Tips\n", "\n", "\n", "This notebook focuses on how to package your python program in a professional manner. \n" ] }, { "cell_type": "markdown", "metadata": {}, "source": [ "## Source Control\n", "\n", "If there's one thing I want you to take away from this document, it is: PLEASE USE GITHUB. That said, please also read the rest of this document. Project 1 is like climbing your first cliff after weeks of wall climbing; Git + GitHub are your tether line. As you work on bits of functionality, bug fixes, refactors, etc. you should get into the habit of committing said incremental work. Some of the benefits of using version control early and often are: \n", "\n", "* Backup in case anything goes wrong locally \n", "* Remote backup in case things go really wrong \n", "* The simple ability to \"look back in time\" at what may be deleted code\n", "* Snapshots of code you can revert to if you've made a mistake\n", "* History of evolution that will help you pick the code back up later on\n", "* The ability to `git branch` to try things and discard/merge as necessary \n", "* Comparable code through git plugins and github.com via pull requests\n", "* Instructors can help you asynchronously via a GitHub link rather than (typically awful) screenshots of code \n",