11 | Update the specification and design documents based on the progress you made so far. 12 | - Update the implementation and testing plans (in the design document) to reflect what you have already accomplished. 13 | - Identify the features you are going to implement in the current sprint. Add user stories (to the requirements document), task breakdowns (design doc), and assignments (design doc). You may need to update tasks that weren't completed in the last sprint. Reassess the task difficulties if necessary. 14 | - Flesh out your list of possible features for future sprints (requirements document). Ideally, you should have a rough outline in place for all sprints. You will change this as we do each sprint, but having a general plan in place will be helpful to everyone involved. 15 | - Identify any changes in the requirements, system architecture and design details. 16 | - Ensure the design document is current for the set of features you've implemented to date and will implement in the next sprint. 17 | - Discuss design decisions that affect testing and describe any test interfaces built into the system (in the testing plan section). 18 | 19 | You must mark clearly the parts of the document that were changed. Use the Changes section at the start of the document and use a different font color for the changed parts. 20 | 21 | 22 | **Sprint Progress Report**
23 | Write a short (1~2 pages) summary for sprint and submit it along with the revised documents. 24 | 25 | - What were the main difficulties so far? You should consider both technical and organization issues. 26 | - Were there any features you did not implement as planned, and why? Are you pushing some features to later sprints, and if so, why? 27 | - What tests did you prepare for this sprint, and what are they covering? Did the tests you wrote deviate from your plan? What features are you not testing yet? Did you use any test frameworks? 28 | - You must include in your progress report a test coverage report. The coverage metric must be over 80%. If it's below 80%, you will lose 10% of the overall score of that sprint. This number may change each sprint. 29 | You must specify what tool did you use, and you must include one or more screenshots showing: 30 | - The overall coverage metric 31 | - The list of classes with lowest coverage. Explain why is the coverage low, and what (if anything) you plan to do about it 32 | - Contribution of team members 33 | - Tag a branch or revision in your repository to identify the code you want to submit for sprintN (replace N with 1, 2, ...). The date and time of this revision should be before the deadline. This branch should include a README file with instructions on how to run the application and tests. 34 | 35 | **Submission**
36 | Each team must send an email to swpp-staff@spl.snu.ac.kr by the deadline. The subject line of the email message must start with the word “[SWPP] sprintN” (replace N with 1, 2, ...) followed by your project's name. The email should contain: 37 | Pointers to the (previously submitted) requirements document and design document. 38 | The sprint summary progress report, as described above. 39 | Instructions for your TA to be able to check out a tagged version of the code that constitutes your sprint release. 40 | A url and instructions for using the app in the current stage. 41 | 42 | Additionally, in the project progress presentation you will have to demonstrate a running version of your sprint release. 43 | -------------------------------------------------------------------------------- /hw2/skeleton/src/serviceWorker.js: -------------------------------------------------------------------------------- 1 | // This optional code is used to register a service worker. 2 | // register() is not called by default. 3 | 4 | // This lets the app load faster on subsequent visits in production, and gives 5 | // it offline capabilities. However, it also means that developers (and users) 6 | // will only see deployed updates on subsequent visits to a page, after all the 7 | // existing tabs open on the page have been closed, since previously cached 8 | // resources are updated in the background. 9 | 10 | // To learn more about the benefits of this model and instructions on how to 11 | // opt-in, read https://bit.ly/CRA-PWA 12 | 13 | const isLocalhost = Boolean( 14 | window.location.hostname === 'localhost' || 15 | // [::1] is the IPv6 localhost address. 16 | window.location.hostname === '[::1]' || 17 | // 127.0.0.1/8 is considered localhost for IPv4. 18 | window.location.hostname.match( 19 | /^127(?:\.(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}$/ 20 | ) 21 | ); 22 | 23 | export function register(config) { 24 | if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) { 25 | // The URL constructor is available in all browsers that support SW. 26 | const publicUrl = new URL(process.env.PUBLIC_URL, window.location.href); 27 | if (publicUrl.origin !== window.location.origin) { 28 | // Our service worker won't work if PUBLIC_URL is on a different origin 29 | // from what our page is served on. This might happen if a CDN is used to 30 | // serve assets; see https://github.com/facebook/create-react-app/issues/2374 31 | return; 32 | } 33 | 34 | window.addEventListener('load', () => { 35 | const swUrl = `${process.env.PUBLIC_URL}/service-worker.js`; 36 | 37 | if (isLocalhost) { 38 | // This is running on localhost. Let's check if a service worker still exists or not. 39 | checkValidServiceWorker(swUrl, config); 40 | 41 | // Add some additional logging to localhost, pointing developers to the 42 | // service worker/PWA documentation. 43 | navigator.serviceWorker.ready.then(() => { 44 | console.log( 45 | 'This web app is being served cache-first by a service ' + 46 | 'worker. To learn more, visit https://bit.ly/CRA-PWA' 47 | ); 48 | }); 49 | } else { 50 | // Is not localhost. Just register service worker 51 | registerValidSW(swUrl, config); 52 | } 53 | }); 54 | } 55 | } 56 | 57 | function registerValidSW(swUrl, config) { 58 | navigator.serviceWorker 59 | .register(swUrl) 60 | .then(registration => { 61 | registration.onupdatefound = () => { 62 | const installingWorker = registration.installing; 63 | if (installingWorker == null) { 64 | return; 65 | } 66 | installingWorker.onstatechange = () => { 67 | if (installingWorker.state === 'installed') { 68 | if (navigator.serviceWorker.controller) { 69 | // At this point, the updated precached content has been fetched, 70 | // but the previous service worker will still serve the older 71 | // content until all client tabs are closed. 72 | console.log( 73 | 'New content is available and will be used when all ' + 74 | 'tabs for this page are closed. See https://bit.ly/CRA-PWA.' 75 | ); 76 | 77 | // Execute callback 78 | if (config && config.onUpdate) { 79 | config.onUpdate(registration); 80 | } 81 | } else { 82 | // At this point, everything has been precached. 83 | // It's the perfect time to display a 84 | // "Content is cached for offline use." message. 85 | console.log('Content is cached for offline use.'); 86 | 87 | // Execute callback 88 | if (config && config.onSuccess) { 89 | config.onSuccess(registration); 90 | } 91 | } 92 | } 93 | }; 94 | }; 95 | }) 96 | .catch(error => { 97 | console.error('Error during service worker registration:', error); 98 | }); 99 | } 100 | 101 | function checkValidServiceWorker(swUrl, config) { 102 | // Check if the service worker can be found. If it can't reload the page. 103 | fetch(swUrl) 104 | .then(response => { 105 | // Ensure service worker exists, and that we really are getting a JS file. 106 | const contentType = response.headers.get('content-type'); 107 | if ( 108 | response.status === 404 || 109 | (contentType != null && contentType.indexOf('javascript') === -1) 110 | ) { 111 | // No service worker found. Probably a different app. Reload the page. 112 | navigator.serviceWorker.ready.then(registration => { 113 | registration.unregister().then(() => { 114 | window.location.reload(); 115 | }); 116 | }); 117 | } else { 118 | // Service worker found. Proceed as normal. 119 | registerValidSW(swUrl, config); 120 | } 121 | }) 122 | .catch(() => { 123 | console.log( 124 | 'No internet connection found. App is running in offline mode.' 125 | ); 126 | }); 127 | } 128 | 129 | export function unregister() { 130 | if ('serviceWorker' in navigator) { 131 | navigator.serviceWorker.ready.then(registration => { 132 | registration.unregister(); 133 | }); 134 | } 135 | } 136 | -------------------------------------------------------------------------------- /project/project-requirements-and-specification.md: -------------------------------------------------------------------------------- 1 | ## Project Requirements and Specification 2 | 3 | **Project Requirements and Specification**
4 | (Borrowed and Adapted from UCB CS169) 5 | 6 | Your Project Name
7 | Requirements and Specification Document
8 | ??/??/????, version major.minor 9 | 10 | **Instructions**
11 | This is a requirements and specification document template for Software Development Principles and Practices. Please follow these directions for filling out this template. Items in italics are information that you are to fill in, beginning with the project name, date, and version number above. See below for an explanation of version numbers. 12 | 13 | There is no standard for requirements or specifications documents and in fact many organizations blend aspects of requirements, specification, and design in a single document. We will use a simple template for requirements and specification. Inevitably in preparing this document you will discuss design and planning, but limit this document to requirements, a description of how the system should interact with the outside world. 14 | 15 | This will be a living document. For the first sprint you will fill in the overview sections (Abstract, Customer, Competitive Landscape), and a few of the requirements that you plan to implement in the first sprint. In subsequent sprints you will expand the applicable sections. 16 | 17 | You have to use the Github wiki of your private team repo. 18 | 19 | **Submission**
20 | You must send an email to swpp-staff@spl.snu.ac.kr with a PDF version of your document. 21 | You must send the email by the deadline in the class calendar. This is a HARD deadline. 22 | 23 | 24 | **Project Abstract**
25 | A one paragraph summary (about 200 words) of what the software will do. (**Must include in the first version.**) 26 | 27 | **Document Revision History**
28 | Your first version of this document is version 1.0. When you evolve this document for future sprints of your project you will increment the minor version number (e.g., 1.1, 1.2, ...). We do not expect that you will have to increment the major version number in the course of this semester. For every version after the initial version, you should list a short bullet list with the main changes and extensions that you made to the document: 29 | 30 | Rev. 1.0 YYYY-MM-DD - initial version 31 | 32 | **Customer**
33 | A brief description of the customer for this software, both in general (the population who might eventually use such a system) and specifically for this document (the customer(s) who informed this document). (**Must include in the first version**) 34 | 35 | 36 | **Competitive Landscape**
37 | Briefly identify the competitors in this market, and list the main ways in which your project is going to be different. 38 | (**Must include in the first version**) 39 | 40 | **User Stories**
41 | This section will include the specification for your project in the form of user stories. For each user story, you should have at least a Feature and one or more Scenarios, each of which can have one or more Acceptance Tests. Acceptance Tests list one or more acceptance tests with concrete values for the parameters, and concrete assertions that you will make to verify the postconditions. Each user story should also have a field called "Sprint" where you specify in which sprint you implemented or plan to implement this feature. 42 | You should list only the user stories for the previous sprints and those for the current sprint. 43 | 44 | At the end of this section you should maintain a bullet list of user stories that you plan to get to in future sprints, with only minimal detail for each such story. We expect that in future sprints some of these items will be promoted to full fledged user stories. 45 | (**Must include in the first version, and must be expanded for future sprints**) 46 | 47 | **User Interface Requirements**
48 | Describes any customer user interface requirements including graphical user interface requirements. Here you should have sketches or mockups for the main parts of the interface. To save time you may want to use scanned drawings of interface mockups here, instead of Photoshop drawings. 49 | 50 | Just like for the User Stories section, you need to list here only the parts of the user interface that are applicable to the previous sprints and the current one. 51 | (**Must include in the first version, and must be expanded for future sprints**) 52 | 53 | 54 | **Requirements grading guidelines:**
55 | These are the grading guidelines that staff will use to evaluate your document. 56 | 57 | 58 | | Max Points | Content | 59 | |------------|---------| 60 | | 5 | Do the requirements state the customers needs? | 61 | | 5 | Competitive analysis | 62 | | 5 | Do the requirements avoid specifying a design (customer-specified design elements are allowed) ? | 63 | | 5 | Do you believe all parts are possible to implement? | 64 | | 5 | Is the project scope big enough? | 65 | | | **Completeness** | 66 | | 20| Are the user stories written in sufficient detail to allow for design and planning? | 67 | | 5 | Do the user stories have acceptance tests ? | 68 | | 5 | Do the user stories mention error conditions and required behavior ? | 69 | | 5 | Are there sufficient user stories for the first iteration? | 70 | | 5 | Is there a discussion of the stories for future iterations ? | 71 | | 20 | Are the User Interface Requirements given with some detail? Are there some sketches, mockups?| 72 | | | **Clarity** | 73 | | 5 | Is the document carefully written, without typos and grammatical errors? | 74 | | 5 | Is each part of the document in agreement with all other parts? | 75 | | 5 | Are all items clear and not ambiguous? (Minor document readability issues should be handled off-line, not in the review, e.g. spelling, grammar, and organization).| 76 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # M1522.000100 Principles and Practices of Software Development 2 | 3 | ## Announcements 4 | - Team formation due 9/10 (Tue) 6pm 5 | - HW1 out; due 9/15 (Sun) 6pm 6 | - Sep.04: Skeleton code of HW1 python updated (to import os package) 7 | - HW2 out; due 10/8 (Tue) 6pm 8 | - Sep.18 (16:05): Minor modification of HW2's backend 9 | - Sep.21 (23:15): Clarification of `article/:id/edit` spec, modification of api `put` description ([diff](https://github.com/swsnu/swppfall2019/commit/07dae919eba6b72155c64a9aa67fcacdcf7dfd1f)) 10 | - Sep.23 (09:38): Deadline of hw2 changed (10/4 for feature implementation, 10/11 for testing) 11 | 12 | 13 | ## Assignments 14 | 15 | - Sep. 02 : [homework 1](hw1) is out 16 | - **Due : 9/15 (Sun) 18:00 (hard deadline)** 17 | - This is an individual assignment 18 | 19 | - Sep. 17 : [homework 2](hw2) is out 20 | - **Due : 10/4 (Fri) 18:00 (feature), 10/11 (Fri) 18:00 (unittest) (hard deadline)** 21 | - This is an individual assignment 22 | 23 | - Oct. 07: [homework 3](hw3) is out 24 | - **Due : 10/27 (Sun) 18:00 (hard deadline)** 25 | - This is an individual assignment 26 | 27 | ## [Project Guideline](project) 28 | 29 | ## Schedule (TBD) 30 | | Week | Lecture | Practice Session | Homework / Project / Exam | 31 | |-------|---------|------------------|--------------------| 32 | |9/2,4 | Course overview; project examples ; Project examples | Python, Javascript Basics Review | HW1 out | 33 | |9/9,11| What softwares do, requirements and challenges to make them good, safe, and reliable; How to collaborate as a team and the methods and tools for it | Choosuk (No practice session) | Team formation due 9/10 (Tue) 6pm; 34 | |9/16,18 | Good coding habits. Comments and code conventions | React Tutorial | Project proposal due 9/17 (Tue) 6pm, HW 1 due 9/15 6pm || 35 | |9/23,25 | Complexity problem and software structures | Redux Tutorial | Project sprint 1 begin (bi-weekly meetings with TAs at the end of sprint) | 36 | |9/30,10/2 | Complexity problem and software structures | React + Redux Testing | | 37 | |10/7,9 | Testing and throwing exceptions, Requirements and specification | CI, Project Setup, Django Intro | HW 2 due 10/11 6pm, Project sprint 2 begin | 38 | |10/14,16 | Software development processes, Design patterns I | Django, React + Django Setup | | 39 | |10/21,23 | Software structure and modeling | Django Testing | Project sprint 3 begin | 40 | |10/28,30 | Code refactoring | Mid-project check | HW 3 due 10/27 6pm | 41 | |11/4,6 | Design patterns 2 | DB + Backend, Writing Good Code | Project sprint 4 begin | 42 | |11/11,13 | Design patterns 3 | Design Pattern, Code Refactoring | | 43 | |11/18,20 | Operation | Code Review | Project sprint 5 begin | 44 | |11/25,27 | Operation (load testing, security) | Deployment + Optimization | Coding exams (Minimum 3 hours) | 45 | |12/2,4 | Code optimization |Deployment + Optimization | Project sprint 6 begin | 46 | |12/9,11 | Advanced topics | | | 47 | |12/15 | Project demo video submission due (6pm) | | | 48 | |12/16 | Project poster session | | Project final report (due 12/18 6pm) | 49 | 50 | ## Office hours 51 | **Professor** : 52 | - Office: Bldg. 302, Rm. 322 53 | - MonWed 4PM-5PM, by appointment 54 | 55 | **TAs** : 56 | 57 | Taebum Kim 58 | - Email: k.taebum@snu.ac.kr 59 | - Office: Bldg. 302, Rm. 420 60 | - Office hour: Wednesday 16:00~17:00 61 | 62 | Kyunggeun Lee 63 | - Email: gurumo0917@gmail.com 64 | - Office: Bldg. 302, Rm. 420 65 | - Office hour: Thursday 17:00~18:00 66 | 67 | Haeyoon Cho 68 | - Email: chohy0555@gmail.com 69 | - Office: Bldg. 302, Rm. 420 70 | 71 | (Please send TAs an email ahead of time, we can set up a specific time and place) 72 | 73 | ## Project Teams 74 | 1. [Matchmaker: Do activities with whoever you want - Smart match making service](https://github.com/swsnu/swpp2019-team1) 75 | 2. [CosMOS : your cosmetics personal shopper](https://github.com/swsnu/swpp2019-team2) 76 | 3. [PapersFeed: Browse and Organize papers, Share and Expand your ideas](https://github.com/swsnu/swpp2019-team3) 77 | 4. [ASSA: Auto Scheduling & Sharing App](https://github.com/swsnu/swpp2019-team4) 78 | 5. [WearHouse: Your very own fashion Warehouse](https://github.com/swsnu/swpp2019-team5) 79 | 6. [Triplannet: Powerful travel planner that helps you to share and organize your travel plans easily](https://github.com/swsnu/swpp2019-team6) 80 | 7. [PillBox : Keep Your Pills Managed. Service that notifies users automatically when to take pills using OCR technology, so that users never miss their pills](https://github.com/swsnu/swpp2019-team7) 81 | 8. [SNUVOICE: Collects SNU Students' Voice](https://github.com/swsnu/swpp2019-team8) 82 | 9. [Fever Time: Let yourself focus. Take record of your concentrated Time](https://github.com/swsnu/swpp2019-team9) 83 | 10. [FoodBook(Food Cabinet): User-experience based review and recommendation service](https://github.com/swsnu/swpp2019-team10) 84 | 11. [surBing: Provides integrated services for survey, response, and result sharing](https://github.com/swsnu/swpp2019-team11) 85 | 12. [MeetingOverFlow: A powerful service that allows you to write and manage your meeting notes efficiently and helps you visualize the flow of your meeting](https://github.com/swsnu/swpp2019-team12) 86 | 13. [Club For You: Create and Join clubs in SNU](https://github.com/swsnu/swpp2019-team13) 87 | 14. [Booksbridge: SNS with your book-reading experience](https://github.com/swsnu/swpp2019-team14) 88 | 15. [OGA: What You See Is What I Need. A location-based Q&A Service](https://github.com/swsnu/swpp2019-team15) 89 | 16. [Ya-Ta!: Taxi sharing for SNU students](https://github.com/swsnu/swpp2019-team16) 90 | 17. [Tu(to)ring Machine: Automate your match, for both tutor and tutee](https://github.com/swsnu/swpp2019-team17) 91 | 18. [S.DA (Sentiment Diary Assistant): Diary Service - Write Easily, Keep Wisely, Share Widely](https://github.com/swsnu/swpp2019-team18) 92 | 19. [SNUBot: Chatbot related to SNU](https://github.com/swsnu/swpp2019-team19) 93 | 20. [Pay me Back!: Manage Dutch Pay, by taking care of complicated accounting and using automatic notification](https://github.com/swsnu/swpp2019-team20) 94 | 21. [Adit - All new advertising platform](https://github.com/swsnu/swpp2019-team21) 95 | -------------------------------------------------------------------------------- /project/design-and-planning.md: -------------------------------------------------------------------------------- 1 | ## Design and Planning Document 2 | 3 | Project Name
4 | Design and Planning Document
5 | ??/??/??,
6 | Version major.minor
7 | 8 | **Instructions**
9 | This is a design and planning document template for SWPP. Please fill out this template carefully. 10 | 11 | This will be a living document. For the first sprint you will fill in the document with the design details as you can see them before the first sprint. In subsequent sprints you will expand this document. 12 | 13 | You have to use Github wiki for this document. 14 | 15 | **Submission**
16 | You must send an email to swpp-staff@spl.snu.ac.kr with a PDF version of your document by the deadline. 17 | 18 | You must send the email by the deadline in the class calendar. This is a HARD deadline. 19 | 20 | **Document Revision History**
21 | Your first version of this document is version 1.0. After that minor changes increment the minor version number (e.g., 1.1, 1.2, …) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, …). We will follow this convention with other documents as well. 22 | 23 | Rev. 1.0 YYYY-MM-DD - initial version 24 | 25 | **System Architecture**
26 | Here you should describe the **high-level architecture** of your system: the major pieces and how they fit together. Use graphical notations as much as possible in preference to English sentences. For example, you could describe the architecture using UML, if your system lends itself to these descriptions. Try to use standard architectural elements (e.g., pipe-and-filter, client-server, event-based, model-view-controller). Make sure to describe the major interfaces between components, which you will describe in more detail in the "Design details" section below. 27 | 28 | **Design Details**
29 | In this section go those important facets that are not at the level of “architecture,” such as descriptions of critical algorithms, protocols, and key invariants. Also, wherever possible items should be linked back to your specification. Ideally, you can match up everything in the specification with where it is implemented in the design. 30 | 31 | We expect that once this document is completed you will split into subteams to implement the various major components. To be ready for such a split, you need to have a precise idea of how the components are interacting, and how you are going to start implementing them. A complete class-level design might not be always possible so early, but you need to specify at least the API among the major components. Use UML when appropriate. 32 | 33 | If there are messages sent between clients and servers, you should identify **what messages and what data they contain, and in what format, and in what order they should be sent.** 34 | 35 | We expect to see a more refined design for the features to be included in the current sprint, and perhaps a more rough design for the features to be implemented in future sprints. 36 | 37 | If you have considered alternative designs, please describe briefly your reasons for choosing the final design. 38 | 39 | **Implementation Plan**
40 | Break down each user story described in your requirements document into programming tasks. Determine the difficulty of each task, and try to estimate the number of developer-days that the tasks should take. Try to also determine dependencies among tasks. Then, you should list all of the tasks to be done in the current sprint, a preliminary assignment of tasks to people in the group, estimates of the time for each task, dependencies between tasks, and a preliminary division into sprints (e.g., which features are implemented in the first sprint, second sprint, and so on). The plan should be designed to get some prototype system running as quickly as possible and then growing towards to the full project over a sequence of sprints. Please pay extra attention to the dependency relationships between tasks; you will almost certainly run into the situation where one bit isn't done but everything else is waiting for it. In that case, you want to know exactly where resources need to go, and how urgent each bit is (hint: NOT proportional to its size or importance in the whole system). 41 | 42 | Try to identify the major risks for the project in general and the plan in particular. Explain what the risks are and discuss how you plan to mitigate them. 43 | 44 | **Testing Plan**
45 | In this section goes a brief description of how you plan to test the system. Thought should be given to how mostly automatic testing can be carried out, so as to maximize the limited number of human hours you will have for testing your system. The effort you put early on on automated testing will pay off when you have to ensure that you are not breaking existing functionality in future sprints. 46 | Consider the following kinds of testing: 47 | 48 | - **Unit testing**: explain for what modules you plan to write unit tests, and what framework you plan to use.
49 | - **Functional testing**: What APIs you plan to test? How will you test them? What tools you will use? Will you write mocks?
50 | - **Acceptance & integration testing**: how do you plan to test the user interface and scenarios?
51 | 52 | **Registering Issues**
53 | You have to register Github issues regarding tasks for design, implementation, and testing and mark them with milestones. 54 | 55 | **Design and planning document grading guidelines**
56 | These are the grading guidelines that staff will use to evaluate your document. 57 | 58 | | Max points | Design | 59 | |-------------|--------| 60 | | 8 | Are all parts of the document in agreement with the product requirements? | 61 | | 10 | Is the architecture of the system described, with the major components and their interfaces? | 62 | | 10 | Are all the external interfaces to the system specified in detail? | 63 | | 10 | Are the major internal interfaces (e.g., client-server) specified in detail? | 64 | | 8 | Is there sufficient detail in the design to start Iteration 1? | 65 | | 4 | Is there reasonable detail in the design for features in future iterations? | 66 | | | **Planning** | 67 | | 8 | Is the plan for Iteration 1 sufficiently complete to start the implementation ? | 68 | | 4 | Are the subteams identified and has enough thought been given to parallelization of effort and team dependencies? | 69 | | 4 | Is there a discussion of the risks associated with this plan? | 70 | | 4 | Are the testing activities scheduled at the appropriate times? | 71 | | | **Testing** | 72 | | 5 | Does the design take into account testability of the various units, components, and subsystems ? | 73 | | 4 | Is there a discussion of how unit testing will be done? | 74 | | 6 | Is there a discussion of how functional (API) testing will be done automatically? | 75 | | 4 | Is there a discussion of how acceptance/integration testing will be done? | 76 | | | **Clarity** | 77 | | 4 | Is the solution at a fairly consistent and appropriate level of detail? | 78 | | 4 | Is the solution clear enough to be turned over to an independent group for implementation and still be understood? | 79 | | 5 | Is the document making good use of semi-formal notation (UML, diagrams, etc) | 80 | | 4 | Is the document identifying common architectural or design patterns, where appropriate? | 81 | | 4 | Is the document carefully written, without typos and grammatical errors? | 82 | -------------------------------------------------------------------------------- /hw2/skeleton/api/db.json: -------------------------------------------------------------------------------- 1 | { 2 | "articles": [ 3 | { 4 | "id": 0, 5 | "author_id": 1, 6 | "title": "10 React JS Articles Every Web Developer Should Read", 7 | "content": "Hello Guys, React or React JS is a JavaScript front-end library from Facebook which lets you create HTML based GUI. It makes the task easier by providing a component-based architecture which was only available to languages like Java and C# before." 8 | }, 9 | { 10 | "id": 11, 11 | "author_id": 2, 12 | "title": "React: A JavaScript library for building user interfaces", 13 | "content": "React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes." 14 | }, 15 | { 16 | "id": 12, 17 | "author_id": 1, 18 | "title": "Building the New facebook.com with React, GraphQL and Relay", 19 | "content": "Open source projects like React, GraphQL and Relay are powering more and more Facebook services. In this session, we'll discuss how we use the latest features of these technologies, like React Suspense, to help deliver a high quality, modern web experience at Facebook." 20 | }, 21 | { 22 | "id": 13, 23 | "author_id": 1, 24 | "title": "React State with Hooks: useReducer, useState, useContext", 25 | "content": "If you haven't used state management excessively in React Function Components, this tutorial may help you to get a better understanding of how React Hooks -- such as useState, useReducer, and useContext -- can be used in combination for impressive state management in React applications. In this tutorial, we will almost reach the point where these hooks mimic sophisticated state management libraries like Redux for globally managed state. Let's dive into the application which we will implement together step by step." 26 | }, 27 | { 28 | "id": 14, 29 | "author_id": 3, 30 | "title": "From Redux to Hooks: A Case Study", 31 | "content": "Having a single store in Redux comes with benefits, but at the same time you end up putting everything into global namespace. Most applications profit from this, you can even create nested reducers and use naming conventions for actions. But if your global state is small and you know for sure that specific slices of state will only be used by specific areas of your application, making them global makes you feel.. uneasy." 32 | }, 33 | { 34 | "id": 15, 35 | "author_id": 2, 36 | "title": "Application State Management with React", 37 | "content": "One of the reasons redux was so successful was the fact that react-redux solved the prop drilling problem. The fact that you could share data across different parts of your tree by simply passing your component into some magical connect function was wonderful. Its use of reducers/action creators/etc. is great too, but I'm convinced that the ubiquity of redux is because it solved the prop drilling pain point for developers." 38 | }, 39 | { 40 | "id": 16, 41 | "author_id": 2, 42 | "title": "What I wish I knew when I started to work with React.js", 43 | "content": "After its initial release on May 29, 2013, React.js has taken over the internet. It’s not a secret that myself and many other developers owe their success to this amazing framework." 44 | }, 45 | { 46 | "id": 17, 47 | "author_id": 2, 48 | "title": "React’s Five Fingers of Death. Master these five concepts, then master React.", 49 | "content": "A few years ago, my friend Sean started telling me how this brand new front-end library called React was going to take over the web. At first I dismissed it as just another framework fad. But then I started hearing about React more and more, to the point where I felt like ignoring it just wasn’t an option anymore." 50 | }, 51 | { 52 | "id": 18, 53 | "author_id": 3, 54 | "title": "Semantic UI: User Interface is the language of the web", 55 | "content": "Semantic 2.4 brings a new components for handling content loading ui placeholder, as well as a new type of segment used to reserve space for content: ui placeholder segment." 56 | }, 57 | { 58 | "id": 19, 59 | "author_id": 3, 60 | "title": "Bootstrap: Build responsive, mobile-first projects on the web with the world’s most popular front-end component library", 61 | "content": "Bootstrap is an open source toolkit for developing with HTML, CSS, and JS. Quickly prototype your ideas or build your entire app with our Sass variables and mixins, responsive grid system, extensive prebuilt components, and powerful plugins built on jQuery." 62 | }, 63 | { 64 | "id": 20, 65 | "author_id": 3, 66 | "title": "ReactJS Testing", 67 | "content": "Jest is a delightful JavaScript Testing Framework with a focus on simplicity." 68 | } 69 | ], 70 | "comments": [ 71 | { 72 | "id": 1, 73 | "article_id": 0, 74 | "author_id": 2, 75 | "content": "What do you mean wow?" 76 | }, 77 | { 78 | "id": 2, 79 | "article_id": 0, 80 | "author_id": 3, 81 | "content": "I was surprised" 82 | }, 83 | { 84 | "id": 4, 85 | "article_id": 11, 86 | "author_id": 3, 87 | "content": "I agree with you" 88 | }, 89 | { 90 | "id": 5, 91 | "article_id": 12, 92 | "author_id": 3, 93 | "content": "Haha this is funny" 94 | }, 95 | { 96 | "id": 6, 97 | "article_id": 12, 98 | "author_id": 2, 99 | "content": "Yes, it is hilarious" 100 | }, 101 | { 102 | "id": 7, 103 | "article_id": 13, 104 | "author_id": 1, 105 | "content": "I am sad" 106 | }, 107 | { 108 | "id": 8, 109 | "article_id": 13, 110 | "author_id": 2, 111 | "content": "I do not want to see you sad" 112 | }, 113 | { 114 | "id": 9, 115 | "article_id": 14, 116 | "author_id": 3, 117 | "content": "I do not want to work" 118 | }, 119 | { 120 | "id": 10, 121 | "article_id": 15, 122 | "author_id": 3, 123 | "content": "What time is it?" 124 | }, 125 | { 126 | "id": 11, 127 | "article_id": 15, 128 | "author_id": 2, 129 | "content": "It is 5 in the morning" 130 | }, 131 | { 132 | "id": 12, 133 | "article_id": 16, 134 | "author_id": 1, 135 | "content": "I like it" 136 | }, 137 | { 138 | "id": 13, 139 | "article_id": 17, 140 | "author_id": 1, 141 | "content": "I don't think so" 142 | }, 143 | { 144 | "id": 14, 145 | "article_id": 17, 146 | "author_id": 2, 147 | "content": "Me neither" 148 | }, 149 | { 150 | "id": 15, 151 | "article_id": 18, 152 | "author_id": 2, 153 | "content": "I am so stressed out" 154 | }, 155 | { 156 | "id": 16, 157 | "article_id": 18, 158 | "author_id": 3, 159 | "content": "Stress is bad" 160 | }, 161 | { 162 | "id": 17, 163 | "article_id": 18, 164 | "author_id": 2, 165 | "content": "Yeah, I should try to feel better" 166 | }, 167 | { 168 | "id": 18, 169 | "article_id": 19, 170 | "author_id": 1, 171 | "content": "My dog is cute" 172 | }, 173 | { 174 | "id": 19, 175 | "article_id": 19, 176 | "author_id": 2, 177 | "content": "I think so as well" 178 | }, 179 | { 180 | "id": 20, 181 | "article_id": 20, 182 | "author_id": 3, 183 | "content": "Tornado has hit our town" 184 | }, 185 | { 186 | "id": 21, 187 | "article_id": 20, 188 | "author_id": 1, 189 | "content": "Oh, what a misery" 190 | }, 191 | { 192 | "author_id": 1, 193 | "article_id": 0, 194 | "content": "Wow!", 195 | "id": 22 196 | } 197 | ], 198 | "user": [ 199 | { 200 | "id": 1, 201 | "email": "swpp@snu.ac.kr", 202 | "password": "iluvswpp", 203 | "name": "Software Lover", 204 | "logged_in": false 205 | }, 206 | { 207 | "id": 2, 208 | "email": "alan@turing.com", 209 | "password": "iluvswpp", 210 | "name": "Alan Turing", 211 | "logged_in": false 212 | }, 213 | { 214 | "id": 3, 215 | "email": "edsger@dijkstra.com", 216 | "password": "iluvswpp", 217 | "name": "Edsger Dijkstra", 218 | "logged_in": false 219 | } 220 | ] 221 | } 222 | -------------------------------------------------------------------------------- /hw3/skeleton/.gitignore: -------------------------------------------------------------------------------- 1 | 2 | # Created by https://www.gitignore.io/api/vim,linux,macos,python,django,pycharm,windows,intellij 3 | # Edit at https://www.gitignore.io/?templates=vim,linux,macos,python,django,pycharm,windows,intellij 4 | 5 | ### Django ### 6 | *.log 7 | *.pot 8 | *.pyc 9 | __pycache__/ 10 | local_settings.py 11 | db.sqlite3 12 | db.sqlite3-journal 13 | media 14 | 15 | # If your build process includes running collectstatic, then you probably don't need or want to include staticfiles/ 16 | # in your Git repository. Update and uncomment the following line accordingly. 17 | #
` in the `form.html` like above. 169 | 170 | If the form satisfies the requirements, the alert message **must** be: 171 | ``` 172 | Successfully Submitted! 173 | ``` 174 | 175 | **2) correct label and tooltip** 176 | 177 | Even when closing the pop-up, it should tell once something is wrong with the form, with an 'X' icon next to each fields. Hovering the mouse over the icon should tell what is wrong with a tooltip like below. 178 | 179 |  180 | 181 | The error message in that tooltip **must** be identical with each requirement above. 182 | Also, if an entry becomes valid after another check, the 'X' label have to be disappeared. 183 | 184 | Tip: using regex might be useful for detecting wrong forms 185 | 186 | ## Grading 187 | 188 | ### Python (10 points) 189 | 190 | We will test your code under Python 3.6. 191 | 192 | - `check_filename_existence` decorator method in `babyname_parser.py` (2 points) 193 | - `parse` method in `babyname_parser.py` (4 points) (automatically include the `__init__` constructor) 194 | - `run.py` (4 points) 195 | - Partial points for minor errors 196 | 197 | ### JavaScript (10 points) 198 | 199 | We will grade the `form.js` and `form.html` file under the `javascript` directory in your GitHub repository. 200 | We will see the outputs to validate your answers. 201 | 202 | - Valid form checking with proper alert message (5 points) 203 | - Label (proper 'X') and modal tooltips (5 points) 204 | - Partial points for minor errors 205 | 206 | 207 | ## Submission 208 | 209 | Due: 9/15 (Sun) 18:00 (This is a hard deadline) 210 | 211 | You must create your own *private* repository under your account ~~and **send them by email to `swpp-tas@spl.snu.ac.kr`**~~. 212 | **Be sure to add the TAs as collaborators in your repository settings!** (Detailed instructions below). 213 | We will check the snapshot of the *master* branch of your Github repository at the deadline and grade it. 214 | Please create a `python` and `javascript` folders, and put your homework files in them appropriately. 215 | Because there are many students in this class, we need to automatize the grading process, so your homework may not be graded properly if your directory hierarchy doesn't look like this: 216 | ``` 217 | repository_root/ 218 | README.md (this file) 219 | python/ 220 | baby1994.html 221 | babyname_parser.py 222 | run.py 223 | ... 224 | javascript/ 225 | form.html 226 | form.js 227 | ... 228 | ``` 229 | Also, make sure to push your work on Github on time. 230 | 231 | ### Instructions on creating a private repository 232 | 233 | #### I. Get GitHub Student Developer Pack 234 | 235 | 1. Go to `https://education.github.com`. 236 | 2. Follow instructions to `Request a discount`. 237 | 238 | #### II. Make your private repository 239 | 240 | 1. Go to your github profile: `https://github.com/YOUR_USERNAME`. 241 | 2. Under `Repositories`, click on `New`. 242 | 3. Fill in `swpp-hw1-USERNAME` as your repository name, and mark is as `Private`. (e.g., `swpp-hw1-ktaebum`) 243 | 4. Hit `Create repository`. 244 | 5. In terminal, go to the directory that you will be working in (e.g., `~/workspace/swpp-hw1-USERNAME` or `~/swpp-hw1-USERNAME`) 245 | 6. Type in and run the following commands, which is also shown on the page that you will be looking at after step 4: 246 | 247 | ``` 248 | echo "# asdf" >> README.md 249 | git init 250 | git add README.md 251 | git commit -m "first commit" 252 | git remote add origin https://github.com/USERNAME/swpp-hw1-USERNAME 253 | git push -u origin master 254 | ``` 255 | 256 | Alternatively you can start by copying skeleton codes :) 257 | ``` 258 | cp -r ${swppfall2019-home}/hw1 ~/workspace/swpp-hw1-USERNAME 259 | git init 260 | git add . 261 | git commit -m "first commit" 262 | git remote add origin https://github.com/USERNAME/swpp-hw1-USERNAME 263 | git push -u origin master 264 | ``` 265 | 266 | 7. Under `Settings` then `Collaborators` tab, Add TAs as your collaborators: `ktaebum`, `kyunggeun-lee`, and `hy00nc`. 267 | 8. You're all set! After finishing your homework, push your contents to your repository on time! 268 | -------------------------------------------------------------------------------- /hw2/README.md: -------------------------------------------------------------------------------- 1 | # Homework 2 - React Library & Testing 2 | 3 | #### **Due (These are hard deadlines)** 4 | - ##### **Feature Implementation Due: 10/4 (Fri) 18:00** 5 | - ##### **Testing Implementation Due: 10/11 (Fri) 18:00** 6 | 7 | You will implement a front-end for a blogging service using React library. This is an **individual** assignment. 8 | This assignment will help you 9 | 10 | - Make a simple React (version 16.9.0) application before diving into your projects 11 | - Make test suites for the React application you implement 12 | - Let you try out stuff we have learned in our practice sessions 13 | 14 | ## Features 15 | 16 | Our blog will support three models: User, Articles, and Comments. 17 | You are required to create a total of five pages as shown in the below storyboard, meeting the following requirements: 18 | 19 |  20 | 21 | - Log In page (`/login`) 22 | - You must have the following fields: 23 | 24 | | JSX Tag type | id | 25 | |---------------|--| 26 | | input | email-input | 27 | | input | pw-input | 28 | | button | login-button | 29 | 30 | - Users should be able to log-in by filling up the email and password inputs and hitting the log-in button. 31 | - As we don't have a proper backend, we don't do real, security-aware authentication yet, but users should only be able to log-in with an account with an email of 'swpp@snu.ac.kr' and password of 'iluvswpp'. 32 | - When a user tries to log-in with invalid inputs, the frontend should emit `Email or password is wrong` message through `alert` command (in Javascript). 33 | - After logging-in, users should find themselves at the article list page. (`/articles`) 34 | - This is the only page that unauthorized users will have access to. Unauthorized users trying to access any other pages should be redirected to this page! 35 | - Article list page (`/articles`) 36 | - Users should be able to clearly make out the **whole** list of articles including article id, (full) article title, and author name in this page. 37 | - Also, user must be able to go to article create page (`/articles/create`) by hitting: 38 | 39 | | JSX Tag type | id | 40 | |-------------|--| 41 | | button | create-article-button | 42 | 43 | - Upon clicking on the article title, users should be able to access the article's detail page (`/articles/:id`). These article titles must be `button` but not `link`. 44 | - Article write(create) page (`/articles/create`) 45 | - You must have the following fields in Write tab: 46 | 47 | | JSX Tag type | id | 48 | |-------------|--| 49 | | input or textarea | article-title-input | 50 | | input or textarea | article-content-input | 51 | | button | back-create-article-button | 52 | | button | confirm-create-article-button | 53 | | button | preview-tab-button | 54 | | button | write-tab-button | 55 | 56 | - Also, you must have the following fields in Preview tab: 57 | 58 | | JSX Tag type | id | 59 | |-------------|--| 60 | | any plain text (like h1, h3, p, …) | article-author | 61 | | any plain text (like h1, h3, p, …) | article-title | 62 | | any plain text (like h1, h3, p, …) | article-content | 63 | | button | back-create-article-button | 64 | | button | confirm-create-article-button | 65 | | button | preview-tab-button | 66 | | button | write-tab-button | 67 | 68 | - When users fill up the title and contents under Write tab and hit the confirm button (either in Preview tab or Write tab), a new article having the given title and contents should be posted. 69 | - The created article, of course, should be tagged with your own author id. 70 | - After creating the article, the user should be redirected to the created article's detail page (`/articles/:id`) 71 | - While creating the article, the user should be able to preview the contents (under the Preview tab by hitting `preview-tab-button`), in the way that it will be shown in the details page. The user should stay in `/articles/create` page while seeing the preview. 72 | - After checking the preview, the user should be able to resume writing (under the Write tab by hitting `write-tab-button`). The user should stay in `/articles/create` page after hitting the `write-tab-button`. 73 | - If the title or content input are empty, the confirm button should be disabled. 74 | - The back button will go back to the article list page (`/articles`) (also without any alert). 75 | - Article detail page (`/articles/:id`) 76 | - You must have the following fields: 77 | 78 | | JSX Tag type | id | 79 | |-------------|--| 80 | | any plain text (like h1, h3, p, …) | article-author | 81 | | any plain text (like h1, h3, p, …) | article-title | 82 | | any plain text (like h1, h3, p, …) | article-content | 83 | | input or textarea | new-comment-content-input | 84 | | button | confirm-create-comment-button | 85 | | button | edit-comment-button | 86 | | button | delete-comment-button | 87 | | button | edit-article-button | 88 | | button | delete-article-button | 89 | | button | back-detail-article-button | 90 | 91 | - Users should be able to clearly make out the title, contents, and author name of the article. 92 | - Also, users should be able to see the whole comments for the corresponding article including the author name and contents of each comments. 93 | - Simple comments functionalities (Create for everyone / Edit/Delete for the comment author through the buttons) should work. 94 | - When a user hits the `confirm-create-comment-button`, a new comment with the contents provided through `new-comment-content-input` and the author's name should be added to this detail page (without any alert). However, `confirm-create-comment-button` should be disabled when the `new-comment-content-input` is empty. 95 | - When a user hits the `edit-comment-button`, a `prompt` taking some string input should be popped up (by using Javascript `prompt` command) and initial value of the prompt should be same as current comment's content 96 | - When the user fill the prompt input with new contents and confirm the pop-up, the contents of the comment should be updated with the new contents. 97 | - When the user confirm the pop-up with empty content, the contents should not be modified (consistent to `user cannot create empty comment`) 98 | - When the user canceled the pop-up, the contents should not be modified. 99 | - When a user hits the `delete-comment-button`, the comment should be deleted without any alert. 100 | - The edit and delete button for each comment must be visible for the author only. 101 | - Edit/Delete button for the article should work. 102 | - These buttons must be visible for the author only. 103 | - When a user hit the `edit-article-button`, the user should be redirected to the edit page (`articles/:id/edit`) 104 | - When a user hit the `delete-article-button`, the user should be redirected to the article list page (`articles/`) and the article should be deleted without any alert. 105 | - When a user hits `back-detail-article-button` button, the user should be redirected to the article list page. 106 | - Article edit page (`/articles/:id/edit`) 107 | - You must have the following fields in Write tab: 108 | 109 | | JSX Tag type | id | 110 | |-------------|--| 111 | | input or textarea | article-title-input | 112 | | input or textarea | article-content-input | 113 | | button | back-edit-article-button | 114 | | button | confirm-edit-article-button | 115 | | button | preview-tab-button | 116 | | button | write-tab-button | 117 | 118 | - Also, you must have the following fields in Preview tab: 119 | 120 | | JSX Tag type | id | 121 | |-------------|--| 122 | | any plain text (like h1, h3, p, …) | article-author | 123 | | any plain text (like h1, h3, p, …) | article-title | 124 | | any plain text (like h1, h3, p, …) | article-content | 125 | | button | back-edit-article-button | 126 | | button | confirm-edit-article-button | 127 | | button | preview-tab-button | 128 | | button | write-tab-button | 129 | 130 | - Users should see similar stuffs with article create page: Write tab and Preview tab. All requirements for the plain texts and tab buttons are identical to the create page (except the url). 131 | - However, the `article-title-input` should contains current article's title and `article-content-input` should contains current article's content 132 | - When a user hits `confirm-edit-article-button`, the user should be redirected to the article detail page (`articles/:id`) and the edited title and contents should be saved. Any comment for the article should not be modified or deleted by this process. 133 | - When a user hits `back-edit-article-button`, the following features should be supported: 134 | - If the title and contents have not been modified yet but are the same as the title and contents before editing, just go back to the detail page without any alert. 135 | - If the title or contents has been modified modified, you should make a confirmation pop-up (through Javascript `confirm` command) with message `Are you sure? The change will be lost.` 136 | - If the user accept the confirmation, the user should be redirected to the detail page and the title and contents of the article should not be modified. 137 | - If the user dismiss the confirmation, the user should just stay on the edit page and be able to resume editing. 138 | - If the title or content input are empty, the confirm button should be disabled (consistent to `/create`). 139 | - Common things for **all pages**: 140 | - If the user is logged-in, the user should be able to log-out from any of the pages by clicking `logout-button`. Upon logging-out, the user should end on the initial Log In page (shown as dotted lines on the storyboard). 141 | 142 | 143 | | JSX Tag type | id | 144 | |---------------|--| 145 | | button | logout-button | 146 | 147 | - Each user should be able to update or delete articles and comments only which they have created. 148 | - **All pages/components should have proper unit tests to test its functionalities, using Jest and Enzyme that are covered in the practice session. Your tests are expected to cover all of your code, and we will give credits according to your coverage results. You can see the coverage information of your application by using `npm test -- --coverage`. Also, all of your tests must pass.** 149 | 150 | We provide a simple [json-server](https://github.com/typicode/json-server) backend with our skeleton code (`skeleton/api`). 151 | Due to its simplicity, we do not go over too much into authentication and security for now, but later on (with HW3 and your project), it should be considered. 152 | 153 | To run server, just type following command at the root of the project 154 | ``` 155 | $ yarn install (only for the first time) 156 | $ yarn run backend (or npm run backend) 157 | ``` 158 | 159 | You should be able to implement your redux action creators by sending appropriate http requests to the following URLs: 160 | 161 | | API | GET | POST | PUT | DELETE | 162 | |------------------------|-----|------|-----|--------| 163 | | `api/user` | Get user list | X | X | X | 164 | | `api/user/1` | Get user information containing whether or not the user is logged_in | X | Update user's `logged_in` value to log-in/log-out | X | 165 | | `api/articles` | Get article list | Create new article | X | X | 166 | | `api/articles/:id` | Get specified article | X | Edit specified article | Delete specified article | 167 | | `api/comments` | Get comments | Create new comment | X | X | 168 | | `api/comments/:id` | Get specified comment | X | Edit specified comment | Delete specified comment | 169 | 170 | Articles should have an `id` (number), `author_id` (number), `title` (string), and `content` (string). 171 | Comments should have an `id` (number), `author_id` (number), `article_id` (number), and `content` (string). 172 | Users should have an `id` (number), `email` (string), `password` (string), `name` (string), and `logged_in` (boolean). 173 | 174 | Each field names are as specified above. You should be able to implement the pages required with these APIs. 175 | 176 | ## Comments on files 177 | 178 | Files that are created inside the `skeleton` (root) and `src` folder have been already discussed during the practice session (contents in [this link](https://github.com/facebook/create-react-app)). As we have done so in our practice sessions, you are expected to add proper components, containers, redux-store (actions, reducers) under the `src/` directory freely, according to your needs. Nicely refactored code will result in better readability and is recommended. 179 | 180 | The `skeleton/api` directory is added to provide simple backend for you to test out your application, and serves as specified above. **Please do not modify this directory.** You are expected to create `store` that manages redux-store by communicating using HTTP, and `containers` and `components` that produce each pages' requirements. The existing `App.js` is expected to be the root component of the entire application. 181 | Also, please do not make any un-requested alerts. It will largely harm the e2e test result. 182 | We will test your code after conducting `yarn install`, so you can import other libraries through `package.json`. However, you should not change the version of already imported dependencies. 183 | 184 | ## Tips 185 | 186 | - Most of things have been covered in the tutorial during the lab session. Please look carefully through the slides and the tips provided. 187 | - It might be useful and more pleasing to the eyes by using a CSS framework like [Bootstrap-React](https://react-bootstrap.github.io/) and [SemanticUI-React](https://react.semantic-ui.com/). However, this is **optional**, please proceed on your own willings. You might be needing them for your projects ahead, so it would be nice to have some head start. 188 | 189 | ## Grading 190 | 191 | This assignment is composed of a total of 80 points. We will score your feature implementation (**lastest commit before 4 October 6:00 PM**) with our e2e test code, having 55 test cases that reflects the requirements given above. You will get 1 point for each passed test case. Also, we will check your unit test coverage (**latest commit before 11 October 6:00 PM**), which is 25 points in total. Grading details are shown below. 192 | 193 | ### Feature Implementation Score 194 | The e2e test consist of cases about: 195 | - Log in page features (4 points) 196 | - Article list page features (5 points) 197 | - Article create page features (10 points) 198 | - Article detail page features when the user is the author of the article (14 points) 199 | - Article detail page features when the user is not the author of the article (13 points) 200 | - Article edit page features (9 points) 201 | 202 | ### Unit Test Score 203 | Your unit test score will be given based on both test coiverage and completeness of your feature implementation. 204 | This is to make sure that your test code is faithful to the feature requirements. 205 | To be more precise, your unit test score will be given as follows: 206 | (*scorefeature* denotes your feature implementation score) 207 | 208 | |
| 15 | Social Security Online 16 | | 17 | Popular Baby Names 18 | | 19 |
| 22 | Popular Baby Names |
23 | 
26 | Popular Names by Birth YearSeptember 12, 2007 |
27 |
|
32 | Background information
33 |
|
41 | Popularity in 199442 |43 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 | 1058 | Privacy Policy 1059 | | Website Policies 1060 | & Other Important Information 1061 | | Site Map | 1062 ||