├── Final-Order.md ├── GROUPS.md ├── README.md ├── assignments ├── Final-Presentation.md ├── Final-Product-Rubric.md ├── M.V.P.-Presentation.md ├── M.V.P.-Rubric.md ├── Product-Description-Presentation.md ├── Report-Rubric.md ├── Social-Contract-Outline.md └── instructor-evaluations.md └── build.sh /Final-Order.md: -------------------------------------------------------------------------------- 1 | ### Monday, December 13th 2 | 3 | #### 1:15pm - 3:00pm, Last scheduled class time 4 | 5 | 1. Lens Cleanse 6 | 7 | 2. Bookmarked 8 | 9 | 3. Stock Mocket 10 | 11 | --- 12 | 13 | ### Thursday, December 16th 14 | 15 | #### 1:45pm – 3:45pm, Scheduled exam time 16 | 17 | 1. Drip Me Out 18 | 19 | 2. Reservify 20 | 21 | 3. Study Buddy 22 | 23 | 4. Codenames 24 | -------------------------------------------------------------------------------- /GROUPS.md: -------------------------------------------------------------------------------- 1 | ## P[0] = Lens Cleanse 2 | 3 | #### Members 4 | - Mena Bebawy 5 | - Nursima Donuk 6 | - Rafsan Hasan 7 | - Jiaying Wu 8 | 9 | #### M.V.P. 10 | - [🗸] Public main/front page 11 | - [🗸] Public view of photo posts 12 | - [🗸] Post a photo and data related to that image 13 | - [🗸] Photos persistently stored in database 14 | 15 | #### Final 16 | - [ ] Comment on photo posts 17 | - [ ] Capture (like/favorite) photos 18 | - [ ] Only "Capture" once per user 19 | - [ ] Edit posts 20 | - [ ] Delete posts 21 | - [ ] Displayed timestamp on posts 22 | - [ ] Personalized user profiles 23 | - [ ] Display metadata (contact/captures/post count) 24 | - [ ] List all posts (by time? by captures?) 25 | - [ ] Hosted on FireBase 26 | 27 | #### Stretch 28 | - [ ] Chat/DM functionality 29 | - [ ] Draft posts 30 | 31 | 32 | --- 33 | 34 | 35 | ## P[1] = Bookmarked 36 | 37 | #### Members 38 | - Fariha Hossain 39 | - Nuzhat Khan 40 | - Mahir Mahboob 41 | - Lakshmi Palchuri 42 | 43 | #### M.V.P. 44 | - [🗸] Have minimally functional backend REST endpoints 45 | - User profiles available 46 | - [🗸] Registration/Authentication 47 | - [🗸] Minimal dashboard 48 | - Minimal pages for: 49 | - [🗸] Pick Genre 50 | - [🗸] Take Quiz 51 | - [🗸] Surprise Me (Random) 52 | - [🗸] Search 53 | - [🗸] Minimal recommendation algorithm 54 | 55 | #### Final 56 | - Functional pages for: 57 | - [ ] Pick Genre 58 | - [ ] Take Quiz 59 | - [ ] Search 60 | - Blog for media 61 | - [ ] Enable user comments for media 62 | - [ ] Support pictures/links in media comments 63 | - [ ] Suggest an external post 64 | - [ ] External links to purchase options 65 | - [ ] Genre-specific recomendation quiz 66 | - [ ] User dashboard 67 | - [ ] Top 10 list 68 | - [ ] Read log 69 | - [ ] Bookshelf 70 | 71 | #### Stretch 72 | - [ ] Expanded database 73 | - [ ] Flim/other media 74 | - [ ] Up/down votes on books 75 | 76 | 77 | --- 78 | 79 | 80 | ## P[2] = "Codenames" the Website 81 | 82 | #### Members 83 | - Stephanie Bravo 84 | - Amy Ghotra 85 | - Daniel Rizzo 86 | - Micheal Tse 87 | - Kevin Xie 88 | 89 | #### M.V.P. 90 | - Minimal frontend pages 91 | - [🗸] Landing 92 | - [🗸] User info 93 | - [🗸] Game 94 | - [🗸] Connect frontend and backend 95 | - [🗸] Connect backend and database 96 | - Generate game sessions 97 | - [🗸] Create room and assign unique ID 98 | - [🗸] Select random words from word bank and assign to team 99 | - [🗸] Allow users to join room 100 | - [🗸] Django working on backend 101 | 102 | #### Final 103 | - [ ] Concurrent, multiplayer game-state updates 104 | - [ ] Team and role selection, limit 1 spymaster 105 | - [ ] Spymaster cluebox 106 | - [ ] Player minimum of 4 107 | - [ ] Propper turn passing 108 | - [ ] Double-agent win condition 109 | - [ ] Point win condition 110 | 111 | 112 | #### Stretch 113 | - [ ] Multiple games simultaneously 114 | - [ ] Animated actions 115 | - [ ] Deployment 116 | 117 | 118 | --- 119 | 120 | 121 | ## P[3] = Reservify 122 | 123 | #### Members 124 | - Ivan Bilyk 125 | - Istiaque Khan 126 | - Deren Lin 127 | - Hayley Robinson 128 | 129 | #### M.V.P. 130 | - [🗸] Activity Finder 131 | - [🗸] Search Function 132 | - [🗸] Minimal purchase/booking 133 | - [ ] Able to write reviews 134 | 135 | #### Final 136 | - [ ] Fully functional purchase booking 137 | - [ ] A price comparison for the bookings 138 | - [ ] Receipt emails 139 | - [ ] Purchase/transaction log 140 | 141 | #### Stretch 142 | - [ ] Location-based recommendations 143 | 144 | 145 | --- 146 | 147 | 148 | ## P[4] = Study Buddy 149 | 150 | #### Members 151 | - Vladimir Andreev 152 | - Boubacar Diallo 153 | - Stacey Li 154 | - Valentine Shidlovskiy 155 | - Alex Taradachuk 156 | 157 | #### M.V.P. 158 | - [🗸] Uploading audio files 159 | - [🗸] Transcribing audio files to text 160 | - [🗸] Generating study notes 161 | - [🗸] Authentication functionality 162 | - [🗸] CRUD operations with user data 163 | - [🗸] Search feature 164 | 165 | #### Final 166 | - [ ] In-app recording 167 | - [ ] Video to transcript 168 | - [ ] Spaced learning reminders 169 | - [ ] Sharing and collaboration 170 | - [ ] Course sharing 171 | - [ ] Creating extra study tools 172 | - [ ] Flash cards 173 | 174 | #### Stretch 175 | - [ ] Export notes to text 176 | - [ ] Deployment via website 177 | - [ ] Model tuning via lecture data set 178 | 179 | 180 | --- 181 | 182 | 183 | ## P[5] = Drip Me Out 184 | 185 | #### Members 186 | - Rachel Tieu 187 | - Hashir Khan 188 | - Betty Valdivia 189 | - Michael Wong 190 | 191 | #### M.V.P. 192 | - [🗸] Weather API integration 193 | - [🗸] User inventory databases 194 | - [🗸] Generate a relevant outfit 195 | 196 | #### Final 197 | - [ ] Save outfits 198 | - [ ] Manually create outfit 199 | - [ ] Edit profile 200 | - [ ] Ability to filter clothing 201 | - [ ] Edit closet items 202 | - [ ] Delete closet items 203 | 204 | #### Stretch 205 | - [ ] Celcius/Fahrenheit in user profile 206 | - [ ] Generate outfit based on weather in future 207 | 208 | 209 | --- 210 | 211 | 212 | ## P[6] = Stock Mocket 213 | 214 | #### Members 215 | - Dibba Roy 216 | - Dewan Sunnah 217 | - Jordan Sze 218 | - Ivan Yatsko 219 | - Shu Qiang Wu 220 | 221 | #### M.V.P. 222 | - [🗸] Basic user accounts 223 | - [🗸] Balances, deposits and withdrawals 224 | - [🗸] Current price of stocks, portfolio value 225 | - [🗸] Buying and selling stocks 226 | - [🗸] Search for stocks 227 | 228 | #### Final 229 | - [ ] Graph visualizations 230 | - [ ] Latest new cycle 231 | - [ ] All trading options ex: options 232 | - [ ] Net gain/loss 233 | - [ ] Transaction history 234 | - [ ] Stock watchlist 235 | - [ ] Diversity pie chart 236 | 237 | #### Stretch 238 | - [ ] 2FA 239 | - [ ] Stock Likes/Dislikes 240 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CSCI 49900 — Advanced Applications 2 | ## Hunter College of the City of New York 3 | ## Department of Computer Science 4 | 5 | | Key | Value | 6 | |:------------------|:--------------------------------------------------------------------------------------------| 7 | | **Instructor:** | Alex Washburn | 8 | | **Email:** | [aw2918@hunter.cuny.edu][email] | 9 | | **Section:** | [CSCI 49900/53432/5][course-description] | 10 | | **Semester:** | Fall 2021 | 11 | | **Credit Hours:** | 4 credits | 12 | | **Textbook:** | None | 13 | | **Format:** | Online; Synchronous | 14 | | **Time:** | [Monday & Thursday 1:10pm - 3:00pm][class-time] | 15 | | **Office Hours:** | [Thursday 3:00pm - 4:00pm][office-time] or [by appointment][email] | 16 | | **Zoom Info:** | [Zoom Meeting ID: `891 9980 7340` Passcode: `0xC499FA11`][zoom] | 17 | | **Course Page:** | [github.com/recursion-ninja/CSCI-499-2021-Fall][course-page] | 18 | 19 | [class-time ]: https://time.is/compare/0100PM_in_New_York 20 | [course-description]: http://www.hunter.cuny.edu/csci/curriculum/hunter-college-computer-science-courses-and#cs493 21 | [course-page ]: https://github.com/recursion-ninja/CSCI-499-2021-Fall 22 | [email ]: mailto:aw2918@hunter.cuny.edu 23 | [office-time ]: https://time.is/compare/0300PM_in_New_York 24 | [zoom ]: https://us02web.zoom.us/j/89199807340?pwd=Rnhwcktic0RCejJobG5ySmhyOXJHQT09 25 | 26 | 27 | # Table of Contents 28 | 29 | * [Overview](#overview) 30 | * [Course Description](#course-description) 31 | * [Course Schedule](#course-schedule) 32 | * [Assignments](#assignments) 33 | * [Product Reporting](#product-reporting) 34 | * [Minimum Viable Product](#minimum-viable-product) 35 | * [Final Product](#final-product) 36 | * [Grading](#grading) 37 | * [Standard Information](#standard-information) 38 | * [Academic Violations](#academic-violations) 39 | * [Email](#email) 40 | * [Computer Science Facilities & Labs](#computer-science-facilities--labs) 41 | * [Counseling & Wellness Services](#counseling--wellness-services) 42 | * [Special Needs](#special-needs) 43 | * [Sexual Misconduct](#sexual-misconduct) 44 | * [Legal Considerations](#legal-considerations) 45 | * [ADA Compliance](#ada-compliance) 46 | * [Family Educational Rights and Privacy Act (FERPA)](#family-educational-rights-and-privacy-act-ferpa) 47 | 48 | 49 | # Overview 50 | 51 | A capstone course which offers a chance for computer science majors to test their mettle on major projects. Working in small groups, they will implement systems that involve at least two platforms running programs written in at least three languages. 52 | 53 | The instructor has extensive experience with functional programming and encourages students to employ functional programming languages and techniques to their projects in order to maximize the guidance the instructor can provide. Some languages with functional programming support with which the instructor has proficiency include: 54 | 55 | - Elm 56 | - Java 57 | - JavaScript 58 | - Haskell 59 | - ML 60 | - TypeScript 61 | - Scala 62 | 63 | The learning goals for the course are *two-fold;* understanding product development and learning collaborative software development techniques. 64 | 65 | Modern software product development tends to utilize *Agile* methodology to varying degrees. Consequently, the course is structured in weekly "sprints." Each week teams plan what they will accomplish for the next week. After a week of work teams report on their progress, reassess feasibility of future work based on the progress of last week, and revise a new plan for the following week of work. The theory of this methodology is to provide rapid feedback and iteration for software development, so that minimal time is spend on "dead-end" feature which will not enhance the product. 66 | 67 | Collaborative software develompment is a crucial skill for any computer science major, regardless of their intended plans after graduation. This course will require students to use `git`, facilitated by GitHub, to add, modify, and merge code while developing their product. Additionally, and equally important, is the ability to communicate clearly and promptly with team mates to facilitate and coordinate tasks. Teams are expected to develop their own, preferred communication channels, be that email, IRC, Slack, Discord, BlackBoard, or another agreed upon medium. 68 | 69 | Lastly, team performance is an important consideration. Prior to starting on their project, each team will author a "social contract" for their team which outliens the expectations of team members and consequences for failing to meet the expectations. This "social contract" document often includes, stating the preferred medium of communication, setting regular meeting times for collaborative work, expected number of hours each team member will devote to working on the course project each week, how to communicate if a team member cannot meet their obligations for a given week, what to do if a team member consistently doesn't meet their weekly obligations. 70 | 71 | 72 | # Course Description 73 | 74 | The capstone course can be broken up into three phases. 75 | 76 | 1. **Planning** *(1 week)* 77 | - Students will create GitHub accounts to facilate collaboration with their peers 78 | - Students will pitch potential project ideas for the semester 79 | - Students will be organized into project teams, one team per viable project idea 80 | - Viable projects will be initialized on GitHub 81 | - Teams will develop and submit their social contracts, outlining team expectations 82 | 83 | 2. **Minimum Viable Product** *(8 weeks)* 84 | - Each week on *Mondays:* 85 | - Each team member will present their *completed* contibutions to the project since the *last* week 86 | - Each team member will present their *planned* contibutions to the project for the *next* week 87 | - Teams will have an opportunity to ask questions and solicit feedback from the instructor and their peers in other teams regarding issues with their project 88 | - Each week on *Thursdays:* 89 | - The scheduled class period will be reserved for teams to collaborate independently 90 | - The instructor will be available during the scheduled class period for consultation on technical difficulties with projects 91 | - The instructor will *also* be available during office hours immediately *after* the scheduled class period 92 | - Teams will present their Minimum Viable Product at the beginning of November 93 | - Teams must submit a script / slides of their presentation before class begins on 11/1 94 | - Each team member must present an aspect of the project 95 | - The presentation should demonstrate a minimal example of the project's functionality 96 | 97 | 3. **Final Product** *(6 weeks)* 98 | - Each week on *Mondays*, the same as the **Minimum Viable Product** phase 99 | - Each week on *Thursdays*, the same as the **Minimum Viable Product** phase 100 | - Teams will present their Final Product at the end of December 101 | - Teams must submit a script / slides of their presentation before class begins on 12/13 102 | - Each team member must present an aspect of the project 103 | - The presentation should demonstrate the final and complete functionality of the project 104 | 105 | 106 | # Course Schedule 107 | 108 | | **Mondays** | **Thursdays** | Monday Activities | Thursday Activities | 109 | |:-----------:|:-----------:|:------------------------------------------|:------------------------------------------| 110 | | | 08/26 | | Syllabus, GitHub, project brainsorming | 111 | | 08/30 | 09/02 | Group assignments, social contracts | No Class, dedicated work time | 112 | | | 09/09 | | Product definition presentations | 113 | | 09/13 | | Project report № 1 | | 114 | | 09/20 | 09/23 | Project report № 2 | No Class, dedicated work time | 115 | | 09/27 | 09/30 | Project report № 3 | No Class, dedicated work time | 116 | | 10/04 | 10/07 | Project report № 4 | No Class, dedicated work time | 117 | | | 10/14 | | No Class, dedicated work time | 118 | | 10/18 | 10/21 | Project report № 5 | No Class, dedicated work time | 119 | | 10/25 | 10/28 | Project report № 6 | No Class, dedicated work time | 120 | | 11/01 | 11/04 | **MVP presentations** (1/2) | **MVP presentations** (2/2) | 121 | | 11/08 | 11/11 | Project report № 7 | No Class, dedicated work time | 122 | | 11/15 | 11/18 | Project report № 8 | No Class, dedicated work time | 123 | | 11/22 | | Project report № 9 | | 124 | | 11/29 | 12/02 | Project report № 10 | No Class, dedicated work time | 125 | | 12/06 | 12/09 | Project report № 11 | No Class, dedicated work time | 126 | | 12/13 | 12/16 | **Final presentations (1/2)** | **Final presentations** (2/2) | 127 | *Notes:* 128 | 129 | - 12/13 The instructor will be out of state presenting at a confrence. We will have class for the first round of final presentations and hope that there are no connectivity troubles. 130 | - The final presentations will take place 12/16/21 from 1:45 – 3:45 pm per the [registrar's posting][final-times]. 131 | 132 | [final-times]: https://hunter.cuny.edu/students/registration/academic-calendar/final-exam-schedule 133 | 134 | 135 | ## Due Dates 136 | 137 | Assignments are due at **`11:59PM`** on the date specified below. 138 | 139 | | **Date** | **Day** | **Assignment** | 140 | |:-----------:|:-----------------|:-----------------------------------| 141 | | 08/27 | Friday | Skills and interests survey | 142 | | 09/01 | Wednesday | GitHub account | 143 | | 09/03 | Friday | Social contract | 144 | | 09/08 | Wednesday | Product definition presentation | 145 | | 10/31 | Sunday | MVP presentation script & slides | 146 | | 12/15 | Wednesday | Final presentation script & slides | 147 | | 12/20 | Sunday | Peer assessment | 148 | 149 | 150 | # Assignments 151 | 152 | | Course Component | Weighted Score | 153 | |:------------------------|---------------:| 154 | | Skill & Interest Survey | 1% | 155 | | GitHub Account | 1% | 156 | | Social Contract | 1% | 157 | | Product Definition | 2% | 158 | | Product Reporting | 44% | 159 | | Minimum Viable Product | 25% | 160 | | Final Product | 25% | 161 | | Peer Assessment | 1% | 162 | 163 | 164 | ## Product Reporting 165 | 166 | Each week students will report on the progress of their product. *Each* student is expected to report on the contributions they made since the *last* product report, and state their planned contributions to complete for the *next* project report. After team members have reported on their recent and tenetive contributions, the floor will be opened up for any team member to solicit assistance or feedback on one or more technical issues they are experiencing. The instructor or their peers will attempt to provide them with assistance addressing their issue(s). Students who can provide guidance to members of another tem will be given additional consideration on their project reporting for that week. 167 | 168 | 169 | ## Minimum Viable Product 170 | 171 | The minimum viable product (MVP) is the state of a project in which the basic functionality can be demonstrated. The product does not need to have a polished user interface nor does it need to have a refined user experience. The core technical functionality needs to be demonstratable. 172 | 173 | The requirements for a MVP will be discussed and refined each week of product reporting with the instructor. If a previous MVP goals appear to have been too ambitious, some functionality maybe be deferred to the final product or removed entirely. If all previously established MVP functionality has been met prior to the MVP presentation date, the instructor and team will decide on additional functionality which can be implemented before the MVP presentation. 174 | 175 | Note that removal of significant functionality from an MVP is likely to negatively impact the scoring of the MVP repopt. Conversely, presenting additional functionality at the MVP presentation will likely result in positive scoring impact. Presenting the exact MVP specifications is considered **B-grade** work (`20/25` points). 176 | 177 | 178 | ## Final Product 179 | 180 | The final product is the state of a project in which all planned functionality can be demonstrated. The product should present a servicable user interface and a thoughtful user experience. The core technical functionality needs to be demonstratable and expanded upon from the MVP. 181 | 182 | The requirements for a final product will be revised based on the MVP presentation and then subsequently discussed and refined each week of product reporting with the instructor. If previous final product goals appear to have been too ambitious, some functionality maybe be removed from the final product. If all previously established final product functionality has been met prior to the final presentation date, the instructor and team will decide on additional functionality which can be implemented before the final product presentation. 183 | 184 | Note that removal of functionality from the final product is likely to negatively impact the scoring of the final repopt. Conversely, presenting additional functionality at the final product presentation will likely result in positive scoring impact. Presenting the exact final product specifications is considered **B+ grade** work (`22/25` points). 185 | 186 | 187 | # Grading 188 | 189 | | Grade | Score Earned | 190 | |:-----:|-------------:| 191 | | A | `>=` 90% | 192 | | B | `>=` 80% | 193 | | C | `>=` 70% | 194 | | D | `>=` 60% | 195 | | F | `< ` 60% | 196 | 197 | The letter grade earned by a student will be *at least* what is described in the table above. A plus or minus to a letter grade may be determined by the relative performance of the student to their peers in the course, their participation in helping peers in other teams with technical problems, and the team assessment at the end of the semester. 198 | 199 | 200 | # Standard Information 201 | 202 | 203 | ## Email 204 | 205 | Emails to the instructor must be from a student's CUNY Hunter College email address to the instructor's CUNY email address [aw2918@hunter.cuny.edu][email] for [FERPA reasons](#family-educational-rights-and-privacy-act-ferpa). 206 | 207 | > **You must *include the class number* `CSCI-499` in the subject line of the email!** 208 | 209 | 210 | ## Academic Violations 211 | 212 | Hunter College regards acts of academic dishonesty (e.g., plagiarism, cheating on examinations, obtaining unfair advantage, and falsification of records and official documents) as serious offenses against the values of intellectual honesty. The college is committed to enforcing the CUNY Policy on Academic Integrity and will pursue cases of academic dishonesty according to the Hunter College Academic Integrity Procedures. 213 | Special attention is given to CONTRACT CHEATING (this is where students have work completed on their behalf which is then submitted for academic credit). 214 | 215 | 216 | ## Computer Science Facilities & Labs 217 | 218 | All computer science students can use any of the general-purpose labs throughout Hunter College. In addition, computer science majors and students enrolled in CSCI courses can an obtain an account on the Computer Science Department Network. More information can be found on the [Computer Science Department's website][cs-labs]. 219 | 220 | [cs-labs]: http://www.hunter.cuny.edu/csci/about-cs/computer-science-facilities-labs 221 | 222 | 223 | ## Counseling & Wellness Services 224 | 225 | Counseling & Wellness Services (CWS) provides mental health, health and wellness services aimed at enhancing students' quality of life and maximizing personal and academic growth and development. More information can be found on the [Counseling & Wellness Services website][ref-CWS]. 226 | 227 | [ref-CWS]: http://www.hunter.cuny.edu/studentservices/counseling-and-wellness 228 | 229 | 230 | ## Special Needs 231 | 232 | Students with special needs should see me for accommodation. 233 | 234 | 235 | ## Sexual Misconduct 236 | 237 | In compliance with the CUNY Policy on Sexual Misconduct, Hunter College reaffirms the prohibition of any sexual misconduct, which includes sexual violence, sexual harassment, and gender-based harassment retaliation against students, employees, or visitors, as well as certain intimate relationships. Students who have experienced any form of sexual violence on or off campus (including CUNY-sponsored trips and events) are entitled to the rights outlined in the Bill of Rights for Hunter College. 238 | 239 | a. Sexual Violence: Students are strongly encouraged to immediately report the incident by calling 911, contacting NYPD Special Victims Division Hotline ([646-610-7272][phone-hotline]) or their local police precinct, or contacting the College's Public Safety Office ([212-772-4444][phone-safety]). 240 | 241 | b. All Other Forms of Sexual Misconduct: Students are also encouraged to contact the College's Title IX Campus Coordinator, Dean John Rose ([jtrose@hunter.cuny.edu][email-rose] or [212-650-3262][phone-rose]) or Colleen Barry ([colleen.barry@hunter.cuny.edu][email-barry] or [212-772-4534][phone-barry]) and seek complimentary services through the Counseling and Wellness Services Office, Hunter East 1123. CUNY Policy on Sexual Misconduct Link: 242 | 243 | [http://www.cuny.edu/about/administration/offices/la/Policy-on-Sexual-Misconduct-12-1-14-with-links.pdf][misconduct] 244 | 245 | [email-barry ]: mailto:colleen.barry@hunter.cuny.edu 246 | [email-rose ]: mailto:jtrose@hunter.cuny.edu 247 | [phone-barry ]: tel:2127724534 248 | [phone-hotline]: tel:6466107272 249 | [phone-rose ]: tel:2126503262 250 | [phone-safety ]: tel:2127724444 251 | [misconduct ]: http://www.cuny.edu/about/administration/offices/la/Policy-on-Sexual-Misconduct-12-1-14-with-links.pdf 252 | 253 | 254 | # Legal Considerations 255 | 256 | 257 | ## ADA Compliance 258 | 259 | In compliance with the American Disability Act of 1990 (ADA) and with Section 504 of the Rehabilitation Act of 1973, Hunter College is committed to ensuring educational parity and accommodations for all students with documented disabilities and / or medical conditions. It is recommended that all students with documented disabilities (Emotional, Medical, Physical and / or Learning) consult the Office of Accessibility located in Room E1124 to secure necessary academic accommodations. For further information and assistance please call ([212-772-4857][phone-ADA-1])/TTY ([212-650-3230][phone-ADA-2]). 260 | 261 | [phone-ADA-1]: tel:2127724857 262 | [phone-ADA-2]: tel:2126503230 263 | 264 | 265 | ## Family Educational Rights and Privacy Act (FERPA) 266 | 267 | The Family Educational Rights and Privacy Act (FERPA) ([20 U.S.C. § 1232g; 34 CFR Part 99][ferpa-law]) is a Federal law that protects the privacy of student education records. The law applies to all schools that receive funds under an applicable program of the U.S. Department of Education. 268 | 269 | FERPA gives parents certain rights with respect to their children's education records. These rights transfer to the student when he or she reaches the age of 18 or attends a school beyond the high school level. Students to whom the rights have transferred are "eligible students." 270 | 271 | - Parents or eligible students have the right to inspect and review the student's education records maintained by the school. Schools are not required to provide copies of records unless, for reasons such as great distance, it is impossible for parents or eligible students to review the records. Schools may charge a fee for copies. 272 | - Parents or eligible students have the right to request that a school correct records which they believe to be inaccurate or misleading. If the school decides not to amend the record, the parent or eligible student then has the right to a formal hearing. 273 | After the hearing, if the school still decides not to amend the record, the parent or eligible student has the right to place a statement with the record setting forth his or her view about the contested information. 274 | - Generally, schools must have written permission from the parent or eligible student in order to release any information from a student's education record. However, FERPA allows schools to disclose those records, without consent, to the following parties or under the following conditions ([34 CFR § 99.31][ferpa-law-consent]): 275 | - School officials with legitimate educational interest; 276 | - Other schools to which a student is transferring; 277 | - Specified officials for audit or evaluation purposes; 278 | - Appropriate parties in connection with financial aid to a student; 279 | - Organizations conducting certain studies for or on behalf of the school; 280 | - Accrediting organizations; 281 | - To comply with a judicial order or lawfully issued subpoena; 282 | - Appropriate officials in cases of health and safety emergencies; and 283 | - State and local authorities, within a juvenile justice system, pursuant to specific State law. 284 | 285 | Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance. However, schools must tell parents and eligible students about directory information and allow parents and eligible students a reasonable amount of time to request that the school not disclose directory information about them. Schools must notify parents and eligible students annually of their rights under FERPA. The actual means of notification (special letter, inclusion in a PTA bulletin, student handbook, or newspaper article) is left to the discretion of each school. 286 | 287 | For additional information, you may call [1-800-USA-LEARN][phone-LEARN] ([1-800-872-5327][phone-LEARN]) (voice). Individuals who use TDD may use the Federal Relay Service. 288 | 289 | Or you may contact us at the following address: 290 | 291 | 292 | Family Policy Compliance Office 293 | U.S. Department of Education 294 | 400 Maryland Avenue, SW 295 | Washington, D.C. 20202-8520 296 | 297 | [ferpa-law ]: https://www.law.cornell.edu/cfr/text/34/part-99 298 | [ferpa-law-consent ]: https://www.law.cornell.edu/cfr/text/34/99.31 299 | [phone-LEARN ]: tel:8008725327 300 | -------------------------------------------------------------------------------- /assignments/Final-Presentation.md: -------------------------------------------------------------------------------- 1 | # Instructions for Final Product Presentation 2 | 3 | Each team will give a 10-15 minute presentation, detailing their progress made and the product's current state. 4 | 5 | At the end of your presentation, we should all understand the existing functionality of your product as well as the functionality which has yet to be implemented. 6 | 7 | **Note:** The presentation should include a live demo of your product's functionality. 8 | 9 | **Note:** Each student in the team has to speak during the presentation. 10 | 11 | **Note:** The slide deck should include a list of functionality for your final product. 12 | 13 | **Note:** The slide deck should include a link to your GitHub repository. 14 | 15 | **Note:** Ensure that the code used in your demo has been pushed to GitHub. 16 | 17 | 18 | ### Format 19 | 20 | - 1-2 minutes to get set up 21 | - 15-20 minutes presentation 22 | - 5-10 minutes of questions 23 | 24 | 25 | ### Deliverables 26 | 27 | - PDF/PPTX of the slides 28 | - PDF of the presentation script 29 | 30 | 31 | ### Instructions 32 | 33 | - Walk us through how users would use your product. 34 | - Tell us a story from a user's perspective 35 | 36 | 37 | ### Goals of the demo 38 | 39 | - Convince the audience that your product achieves its stated final project goals. 40 | - Show case extra functionality you implemented 41 | - Become comfortable giving presentations on your work 42 | 43 | 44 | ### Slides Guideline 45 | 46 | You are encouraged to use slides for the beginning and end of your final product presentation. 47 | However, the main focus of your presentation should be a live demonstration of your product. 48 | A short slide deck will likely be sufficient. 49 | Consider the following example slide deck. 50 | 51 | **Slide 0** 52 | > Product Name, Team Members, Date, and Context. 53 | 54 | **Slide 1** 55 | > Keep this page blank except for the words "Demo". 56 | > Stay on the demo while demonstrating your product. 57 | 58 | **Slide 2** 59 | > Bullet points of extra functionality you demonstrated 60 | 61 | **Slide 3 and beyond** *(all optional)* 62 | > Tool/technologies/sources used. 63 | > Which team member contributed to what. 64 | > Anything else which provides insight or context for your product. 65 | 66 | **Slide (n - 1)** 67 | > Summarize your presentation, thank your audience, and ask for any questions from the audience. 68 | > **Include a link to your** GitHub repository 69 | 70 | Be sure to reference the [Product Description Slide Guideline][slides] for guidance on slide format. 71 | 72 | [slides]: https://github.com/recursion-ninja/CSCI-499-2021-Fall/blob/master/assignments/Product-Description-Presentation.md#slides-guideline 73 | 74 | 75 | ### Demo Flow - Guided User Experience(s) 76 | 77 | Very similarly to the M.V.P Presentation, the goal is to demonstrate the functionality of your product. 78 | Focus on walking through the different user experiences your product offers. 79 | As you do so, showcase the existing functionality while commenting on the techniques you used to implement them. 80 | 81 | 82 | ### Tips for Strong Presentations 83 | 84 | Please practice your presentations. You should not stand up and give them cold. 85 | 86 | Look at your slides on a zoom screenshare. 87 | The color and quality of your computer screen is way better than what the screenshare can reproduce. 88 | 89 | 90 | ### Presentation Script Guidelines 91 | 92 | For each slide, you should write in full sentences what you plan on saying, and who will be saying it. 93 | 94 | Having a script for public presentations serves multiple purposes: 95 | 96 | - Forces you to think about what exactly you will be saying. In turn this provides self-feedback and practice of sorts, making for better presentations. 97 | - Helps you during the presentation. If you lose track of what you wanted to say, you can just check the script. 98 | -------------------------------------------------------------------------------- /assignments/Final-Product-Rubric.md: -------------------------------------------------------------------------------- 1 | # Final Product Presentation 2 | 3 | ## Team Name 4 | 5 | 6 | | Category | Total | Earned | 7 | |:-|-:|-:| 8 | | Slides & Script | 2 | | 9 | | Everyone Speaks | 2 | | 10 | | Presentation Timing | 2 | | 11 | | Presentation Quality | 6 | | 12 | | Final Features | 30 | | 13 | | Extra Features † | 4 | | 14 | | Code Review ‡ | 4 | | 15 | | Presentation Points | 50 | | 16 | | Final Grade Weight | 25 | | 17 | 18 | 19 | A score of `(22/25)` coresponds to both a successful, final product implmentation and a successful presentation. 20 | To receive a score higher than `(22/25)`, a presentation displaying features beyond the final product specifications and exceptional code quality are required. Exemplary deleivery are recorded in the *Extra Features* and *Code Review* category. 21 | 22 | (†) Score of `(0/4)` points in the *Extra Features* category coresponds to meeting, but not exceeding the M.V.P. expected features. 23 | A Score of `(4/4)` coresponds presenting *two* additional, fully functional and significant features. 24 | Partial credit for additioanl lesser features or partially complete significant features. 25 | 26 | (‡) Score of `(2/4)` points in the *Code Review* category coresponds to the expected level of software architecture cleanliness. 27 | A higher score coresponds to software architecture which exceeds expectations. 28 | Examples include good usage of `git` branches, descriptive commit messages, and README/INSTALL/SETUP files(s). 29 | 30 | \clearpage 31 | 32 | ### Slides & Script 33 | 34 | ### Attendance 35 | 36 | ### Presentation Timing 37 | 38 | ### Presentation Quality 39 | 40 | ### Code Review 41 | 42 | ### MVP Features 43 | 44 | ### Extra Features 45 | 46 | ### Presentation Grade 47 | -------------------------------------------------------------------------------- /assignments/M.V.P.-Presentation.md: -------------------------------------------------------------------------------- 1 | # Instructions for Minimum Viable Product Presentation 2 | 3 | Each team will give a 10-15 minute presentation, detailing their progress made and the product's current state. 4 | 5 | At the end of your presentation, we should all understand the existing functionality of your product as well as the functionality which has yet to be implemented. 6 | 7 | **Note:** The presentation order of groups will be determined randomly. 8 | 9 | **Note:** The presentation should include a live demo of your product's functionality. 10 | 11 | **Note:** Each student in the team has to speak during the presentation. 12 | 13 | **Note:** The slide deck should include a list of functionality for your final product. 14 | 15 | **Note:** The slide deck should include a link to your GitHub repository. 16 | 17 | **Note:** Ensure that the code used in your demo has been pushed to GitHub. 18 | 19 | 20 | ### Format 21 | 22 | - 1-2 minutes to get set up 23 | - 10-15 minutes presentation 24 | - 3-5 minutes of questions 25 | 26 | 27 | ### Deliverables 28 | 29 | - PDF/PPTX of the slides 30 | - PDF of the presentation script 31 | 32 | 33 | ### Instructions 34 | 35 | - Walk us through how users would use your product. 36 | - Tell us a story from a user's perspective 37 | 38 | 39 | ### Goals of the demo 40 | 41 | - Convince the audience that your product achieves its stated MVP goals. 42 | - Become comfortable giving presentations on your work 43 | 44 | 45 | ### Slides Guideline 46 | 47 | You are encouraged to use slide for the beginning and end of your MVP presentation. 48 | In fact, incorporate slides wherever you feel they enhance the presentation. 49 | However, the main focus of your presentation should be a live demonstration of your product. 50 | A short slide deck will likely be sufficient. 51 | Consider the following example slide deck. 52 | 53 | **Slide 0** 54 | > Product Name, Team Members, Date, and Context. 55 | 56 | **Slide 1** 57 | > Keep this page blank except for the words "Demo". 58 | > Stay on the demo while demonstrating your product. 59 | 60 | **Slide 2** 61 | > Bullet points of your claims (Product Definition), with simple visuals if possible. 62 | 63 | **Slide 3** 64 | > Remaining work. 65 | > Because this is a mid-semester demo, you won't have finished everything. 66 | > Define the next steps for your product, in order to fulfill the goals of your product definition, and present them. 67 | > **Include a bulleted list of functionality for your final product presentation.** 68 | 69 | **Slide 4 and beyond** *(all optional)* 70 | > Tool/technologies/sources used. 71 | > Which team member contributed to what. 72 | > Ideas for future development (reach goals for final product). 73 | > Technical details you predict you will be asked questions about (1-page per). 74 | > Anything else which provides insight or context for your product. 75 | 76 | **Slide (n - 1)** 77 | > Summarize your presentation, thank your audience, and ask for any questions from the audience. 78 | > **Include a link to your** GitHub repository 79 | 80 | Be sure to reference the [Product Description Slide Guideline][slides] for guidance on slide format. 81 | 82 | [slides]: https://github.com/recursion-ninja/CSCI-499-2021-Fall/blob/master/assignments/Product-Description-Presentation.md#slides-guideline 83 | 84 | 85 | ### Demo Flow - Guided User Experience(s) 86 | 87 | The goal is to demonstrate the functionality of your product. 88 | Focus on walking through the different user experiences your product offers. 89 | As you do so, showcase the existing functionality while commenting on the techniques you used to implement them and also note where future functionality will be in the final user experience. 90 | 91 | 92 | ### Tips for Strong Presentations 93 | 94 | Please practice your presentations. You should not stand up and give them cold. 95 | 96 | Look at your slides on a zoom screenshare. The color and quality of your computer screen is way better than what the screenshare can reproduce. 97 | 98 | 99 | ### Presentation Script Guidelines 100 | 101 | For each slide, you should write in full sentences what you plan on saying, and who will be saying it. 102 | 103 | Having a script for public presentations serves multiple purposes: 104 | 105 | - Forces you to think about what exactly you will be saying. In turn this provides self-feedback and practice of sorts, making for better presentations. 106 | - Helps you during the presentation. If you lose track of what you wanted to say, you can just check the script. 107 | -------------------------------------------------------------------------------- /assignments/M.V.P.-Rubric.md: -------------------------------------------------------------------------------- 1 | # Minimum Viable Product Presentation 2 | 3 | ## Team Name 4 | 5 | ## Student 6 | 7 | 8 | | Category | Total | Earned | 9 | |:-|-:|-:| 10 | | Slides & Script | 2 | | 11 | | Everyone Speaks | 2 | | 12 | | GitHub Link | 2 | | 13 | | Presentation Timing | 2 | | 14 | | Presentation Quality | 5 | | 15 | | MVP Features | 25 | | 16 | | Extra Features † | 8 | | 17 | | Code Review ‡ | 4 | | 18 | | Presentation Points | 50 | | 19 | | Final Grade Weight | 25 | | 20 | 21 | **Reminder:** The sylabus describes the Minimum Viable Product Presentation grading as follows: 22 | 23 | > Presenting the exact MVP specifications is considered **B-grade** work (`20/25` points). 24 | 25 | A score of `(20/25)` is coresponds to both a successful, mid-semester implmentation and a successful presentation. 26 | To receive a score higher than `(20/25)`, a presentation displaying features beyond the M.V.P. specifications is required and recorded in the *Extra Features* category. 27 | Additionally, a code review revealing exceptional software architecture may, to a lesser extent, earn a score higher than `(20/25)` recorded in the *Code Review* category. 28 | 29 | (†) Score of `(0/8)` points in the *Extra Features* category coresponds to meeting, but not exceeding the M.V.P. expected features. 30 | A Score of `(8/8)` coresponds presenting features which would be sufficient for a *Final* Product Presentation. 31 | 32 | (‡) Score of `(2/4)` points in the *Code Review* category coresponds to the expected level of software architecture cleanliness. 33 | A higher score coresponds to software architecture which exceeds expectations. 34 | 35 | \clearpage 36 | 37 | ### Slides & Script 38 | 39 | ### Attendance 40 | 41 | ### Presentation Timing 42 | 43 | ### Presentation Quality 44 | 45 | ### Code Review 46 | 47 | ### MVP Features 48 | 49 | ### Extra Features 50 | 51 | ### Presentation Grade 52 | -------------------------------------------------------------------------------- /assignments/Product-Description-Presentation.md: -------------------------------------------------------------------------------- 1 | # Instructions for Project Proposal 2 | 3 | Each team will give a 10-15 minute presentation, detailing their project's planned work. 4 | 5 | At the end of your presentation, we should all understand the goals of your projects as well as the means you plan to use to achieve them. 6 | 7 | ### Deliverables: 8 | 9 | PDF/PPTX of the slides 10 | PDF of the presentation script 11 | 12 | The presentation order of groups will be determined randomly. 13 | **Note:** each student in the team has to speak during the presentation. 14 | 15 | ### Slides Guideline 16 | 17 | Aim to spend in between 30s and 1min per slide of content. 18 | 19 | - Project Title in large. Your name, the course name/number for context, the date (smaller). 20 | - Introduction / Example 21 | - Give us an example of what your app will look like or how it will be used with a user story. 22 | - Grab our attention and make us interested in your app 23 | - Product Definition 24 | - Vision, target audience, problem, strategy and goals 25 | - Each word you add to a product definition is a point you are trying to make about your project. 26 | - What is your app's unique value proposition? 27 | - For each point in your product definition, spend 1-2 slides detailing it. 28 | - example: "our strategy is a mobile application. We want it to be mobile because our users will often be outside, where phones are more accessible than laptops or desktops. We want it to be an application as opposed to a mobile-friendly website because we need access to the local storage, camera, and location information, which our research shows is more complicated to access from a browser. After researching our options and consulting with the strengths of the team members, we've decided to use the React Native as it lets use develop for both iOS and Android." 29 | - Try to illustrate your points with pictures as much as with words. 30 | - example: to illustrate 'user-friendly' use mock-UIs (mock-UIs in general are useful and strongly recommended for the proposal) 31 | - Each point of the product definition is important, but pay particular attention to explaining your goals. Having well defined goals provides accountability for the team. 32 | - A few slides describing what technologies and platforms you plan to use. 33 | - Web, mobile, or something else 34 | - Front end UI 35 | - Back end, database infrastructure 36 | - Data source/API 37 | - A few slides with the description of work distribution. 38 | - What are the strengths of each student in the team? 39 | - What aspect of the project will each student be responsible for? 40 | - A few slides on your project plan and timeline 41 | - What are the features you are targeting for the MVP? 42 | - What are the nice-to-have features that you plan to include after the MVP? 43 | 44 | **Note:** All the work you do for the slides should be useful preliminary research work for your project. Your mentality should be: you are planning out the project first, and presenting the plan to us second. 45 | 46 | ### Product Thinking - Defining your project 47 | 48 | The goal is to focus on shaping the thought process in defining a product keeping in mind the user, the experience, and how to come up with realistic achievable goals and features in order to achieve them. 49 | 50 | The following layout helps define your project (adapt as you see fit): 51 | 52 | > In order to ______ (vision) 53 | > 54 | > our product will solve ______ (target audience) 55 | > 56 | > problem of ______ (user problem) 57 | > 58 | > by giving them ______ (strategy). 59 | > 60 | > We know if our product works when we see ______ (goals). 61 | 62 | **Example:** In order to *improve the life of New Yorkers* (vision), our product will *solve frequent commuters'* (target audience) problem of *wasting time/being late because of not knowing when the next bus arrives* (user problem) by giving them a *responsive mobile application that displays live bus arrival times nearby* (strategy). We know if our products work when we see: *a new user successfully navigates our UI, and growing numbers of satisfied users* (goals). 63 | 64 | More details on Product Thinking: https://github.com/appnexus/capstone-course/blob/master/notes/PRODUCT.md 65 | 66 | More details on product pitch presentations: 67 | 68 | https://medium.com/swlh/how-to-pitch-your-app-to-investors-8fc6f93c31d 69 | 70 | https://mindsea.com/mobile-app-pitch-deck/ 71 | 72 | ### Tips for Strong Presentations 73 | 74 | Please practice your presentations. You should not stand up and give them cold. 75 | 76 | Look at your slides on a zoom screenshare. The color and quality of your computer screen is way better than what the screenshare can reproduce. 77 | 78 | ### Presentation Script Guidelines 79 | 80 | For each slide, you should write in full sentences what you plan on saying, and who will be saying it. 81 | 82 | Having a script for public presentations serves multiple purposes: 83 | 84 | - Forces you to think about what exactly you will be saying. In turn this provides self-feedback and practice of sorts, making for better presentations. 85 | - Helps you during the presentation. If you lose track of what you wanted to say, you can just check the script. 86 | 87 | ### Additional resources: 88 | 89 | https://uxdesign.cc/how-to-conduct-user-interviews-fe4b8c34b0b7 90 | 91 | https://medium.springboard.com/the-art-of-the-user-interview-cf40d1ca62e8 92 | 93 | https://www.ycombinator.com/library/6g-how-to-talk-to-users 94 | 95 | https://about.gitlab.com/handbook/engineering/ux/ux-research-training/discussion-guide-user-interviews/ 96 | 97 | https://www.business2community.com/mobile-apps/how-to-lead-productive-user-interviews-for-your-mobile-app-02184885 98 | -------------------------------------------------------------------------------- /assignments/Report-Rubric.md: -------------------------------------------------------------------------------- 1 | 2 | | Member | Progress | Issues | Action Items | 3 | |:--------|:----------|:---------|:---------| 4 | | Alice | Implemented feature X | None | Implement feature Y | 5 | | Bob | Progress on feature Z | API integration woes | Finish feature Z | 6 | | Charlie | Read API documentation | Illness | Help Bob with feature Z | 7 | | Daniel | Mocked up GUI & UX flow | None | Implement part of landing page | 8 | | Eve | Collected ML data sets | Data is unusable | Clean data so it's usable | 9 | -------------------------------------------------------------------------------- /assignments/Social-Contract-Outline.md: -------------------------------------------------------------------------------- 1 | # Team Contract 2 | 3 | #### Team name: `name` 4 | #### Date: `date` 5 | #### GitHub Repository: `link` 6 | 7 | ## GOALS 8 | > What are our team goals for this project? 9 | > What do we want to accomplish? What skills do we want to develop or refine? 10 | 11 | ``` 12 | Place you team's answer here 13 | ``` 14 | 15 | ## EXPECTATIONS 16 | > What do we expect of one another in regard to attendance at meetings, participation, frequency of communication, the quality of work, etc.? 17 | 18 | ``` 19 | Place you team's answer here 20 | ``` 21 | 22 | ## POLICIES & PROCEDURES 23 | > What rules can we agree on to help us meet our goals and expectations? 24 | > What are our expectations for conduct among team members? 25 | 26 | ``` 27 | Place you team's answer here 28 | ``` 29 | 30 | ## CONSEQUENCES 31 | > How will we address non-performance in regard to these goals, expectations, policies and procedures? 32 | > How will we address conflict? 33 | 34 | ``` 35 | Place you team's answer here 36 | ``` 37 | 38 | --- 39 | 40 | ### We share these goals and expectations, and agree to these policies, procedures, and consequences. 41 | 42 | - `Team member name` 43 | - `Team member name` 44 | - `Team member name` 45 | - `Team member name` 46 | - `Team member name` 47 | -------------------------------------------------------------------------------- /assignments/instructor-evaluations.md: -------------------------------------------------------------------------------- 1 | ### Hello Class, 2 | 3 | *It is **teaching evaluation** time!* 4 | 5 | Monday, December 13th is the deadline to complete an evaluation for each of your instructors. 6 | 7 | ### Why do it? 8 | 9 | **It is completely *anonymous*.** 10 | 11 | I personally am interested in your feedback on the course so I can continue to improve the course and adjust it to student needs and backgrounds. 12 | 13 | Teacher evaluations serve a number of important functions such as: 14 | 15 | - Improving classes by providing instructors feedback on their teaching. 16 | 17 | - Refining course requirements and design based on student feedback. 18 | 19 | - Helping future students make decisions about what courses and instructors are right for them. 20 | 21 | - Serving as supporting documentation in a faculty’s reappointment, tenure and promotion. 22 | 23 | Teacher evaluation results are readily accessible at [www.hunter.cuny.edu/myprof][myprof]. 24 | 25 | [myprof]: https://www.hunter.cuny.edu/myprof 26 | 27 | 28 | ### How to do it? 29 | 30 | 1. Visit [www.hunter.cuny.edu/te][eval-desk] OR [www.hunter.cuny.edu/mobilete][eval-lite] 31 | 2. Sign in with your net ID and net ID password. 32 | 3. Complete the evaluation for your instructor(s). 33 | 34 | If you need to reset your password, you can do so here: 35 | 36 | [netid.hunter.cuny.edu/verify-identity][passwords] 37 | 38 | If you don’t have a working netid, please contact the Service Desk via email: 39 | 40 | [helpdesk@hunter.cuny.edu][help-desk] 41 | 42 | 43 | [eval-desk]: https://www.hunter.cuny.edu/te 44 | [eval-lite]: https://www.hunter.cuny.edu/mobilete 45 | [help-desk]: mailto:helpdesk@hunter.cuny.edu 46 | [passwords]: https://netid.hunter.cuny.edu/verify-identity 47 | 48 | 49 | Thank you for your participation! 50 | 51 | Alex Washburn 52 | 53 | -------------------------------------------------------------------------------- /build.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | syllabus=CSCI-499-Fall-2021 3 | target=$syllabus.tex 4 | pandoc -V documentclass=book -s README.md -o $target 5 | sed -i 's/\\documentclass\[/\\documentclass[openany/g' $target 6 | sed -i 's/]{book}/]{book}\\usepackage[a4paper,margin=0.75in,tmargin=0in,footskip=-0.25in]{geometry}/g' $target 7 | pdflatex $target 8 | rm -f $syllabus.aux $syllabus.log $syllabus.aux $syllabus.tex 9 | --------------------------------------------------------------------------------