Day 22

Day 20 (UI specification)/User Interface Specification.md

@@ -0,0 +1,79 @@
+
+# Campus visit user interface specification
+
+Prepared by: Michael Kowalczyk  
+Revision date: 10/3/2024
+
+## Overview
+
+A [prototype for the software is available](<../Day 13-14 (prototyping)/clickable prototype/index.html> "Clickable prototype"), and there is only one developer on this project, so this document will only go into detail on those aspects that are unclear or unspecified in the prototype.
+
+The system will be deployed as a web app with a dedicated email address for sending notifications.  Users can sign in directly or use links from emails to perform certain actions without logging in.
+
+[In larger projects, explain here how each requirement is met.]::
+
+## Event responses
+
+Event responses are simple: most of the events in this system are concerned with bringing the internal data model up to date with what is going on in the problem domain.  This is true for VisitRequest, ClaimVisit, ConfirmVisit, CancelVisit, AbaondonVisit, VisitTimePassed, SetCommittmentLevel, EditAvailableTimes, CreateUser, EditUser, and ChangePassword.
+
+Internally, the system is going to model Visits, Users, and User Committments in a similar way as described in the requirements document.  The main difference is that internally, the software will keep visitor data as part of the visit itself.  There is little practical need to separate these, as repeat visits with the same visitor are rare; having both stored together simplifies the program and only costs a few extra keystrokes for the coordinator on rare occasions.  Also, many of the attributes can be folded together.  The result is indicated in the following internal data model.
+
+![Data model](dataModel.png "Data model")
+
+AdjustNotificationFrequency and SetEmailLinkTimeout are administrative tasks with simple internal representations.
+
+## Screens
+
+In general, the screens should behave as in a standard single-page web app: hitting the tab key should cycle through interactable user interface elements in top-to-bottom order and the browser back/forward buttons are deactivated.
+
+### Login
+
+![Login](<../Day 13-14 (prototyping)/clickable prototype/pages/login.png> "Login screen")
+
+The login screen should display an error message on failed login, and should also provide the option to do password reset by email.
+
+### User
+
+![Users](<../Day 13-14 (prototyping)/clickable prototype/pages/users.png> "Users screen")
+
+Tab order on this screen is left-to-right per row.  The *New user* button creates a new row with all blanks.  A name and email must be provided before hitting "Save changes".  Otherwise, a modal dialog will point out the omission.  If a password is left blank for a user, then they aren't able to log into the system but can still use email links.  Only faculty have editable/viewable availability.  It is possible to have a user with no roles.  Trying to close the browser or switch to the visits tab before saving will issue a warning about changes being lost (ok / cancel).
+
+### Visits
+
+![Visits](<../Day 13-14 (prototyping)/clickable prototype/pages/visits.png> "Visits screen")
+
+Proposed visits are highlighted in red on the faculty screen.  Proposed and assigned visits are highlighted in red on the coordinator screen (because the visit must still be confirmed with the Campus Visit office).  Any edit to the filter criteria immediately updates the list.  Results can be sorted increasing or decreasing by clicking on columns: visit number, date, student, times, guide, or status.
+
+### Email click confirmation screens
+
+![Confirm volunteer](<../Day 13-14 (prototyping)/clickable prototype/pages/confirmnonvolunteer.png> "Confirm volunteer screen")
+
+The prototype doesn't show it, but the message should imply what choice was recorded, i.e. `You have choosen "I am able to do it, but I'm not volunteering (yet).  If you change your mind, you can select a different email link or log in to volunteer for this visit"`.
+
+## Shared states
+
+There are no shared states or files with other software systems.
+
+## File formats
+
+No files are held in common with other systems or with the user.  Internally used file formats and/or database tables will be commented on in the architectural design stage.
+
+## New protocols
+
+No unique protocols will be necessary.
+
+## Administrative tasks
+
+See requirements document.
+
+## Operating procedures
+
+It is required that all users of the system check their email frequently (at least once every day or two) and respond to campus visit requests promptly.  Meeting the expectation of a quick turnaround time on campus visits relies crucially on this.
+
+## Installation procedures
+
+This section will be deferred to the architectural design stage, since it relies on decisions not made yet.
+
+## Preferences
+
+The system may be simple enough that keyboard shortcuts would have little use.  The plan is to develop the first version of this software and let users determine if such functionality would be useful enough to add subsequently.

Day 20 (UI specification)/dataModel.puml

@@ -0,0 +1,37 @@
+'Created with https://www.planttext.com/
+
+@startuml
+
+skin rose
+
+title Internal data model
+
+class User {
+  name
+  email
+  password
+  roles
+  availableTimes
+}
+
+class Visit {
+  studentInfo
+  otherVisitors
+  hometown
+  day
+  possibleTimes
+  decidedTime
+  status
+  notes
+  notificationFrequency
+}
+
+class Committment {
+  level
+}
+
+Visit "*\ndecided guide →" -right- "0..1\n← visits" User : "                                         "
+Visit "   1" -up- "*" Committment
+User "1" -up- "*" Committment
+
+@enduml

Day 21 (lifecycle models)/notes.md

@@ -15,7 +15,7 @@ In iterative development one iterates through the whole process (requirements
 Spiral is a type of incremental and iterative development where risk assessment occurs at the start of each cycle.
 
 ## Agile
-Agile is a form of incremental and iterative development with emphasis on frequent face-to-face communication, high customer visibility, adaptability to change, and minimizing non-software work products.
+Agile is a form of incremental and iterative development with emphasis on frequent face-to-face communication, high customer visibility, adaptability to change, and minimizing non-software work products.  For example, Extreme Programming (XP) is an agile methodology based on the principles of communication, simplicity, feedback, courage, and respect.
 
 ## Evolutionary
 In an evolutionary model, deliverables are given to the customer frequently and incrementally.  The focus is on high-value features first and getting customer feedback early and often.

Day 22-23 (architecture)/Programming language selection.txt

@@ -0,0 +1,16 @@
+
+Using a familiar programming language leads to significant productivity increases over an unfamiliar language.
+
+Using a high-level programming language leads to huge (many factor) productivity increases over low level languages, both in terms of development speed and lines of code (table copied from "Code Complete 2", by Steve McConnell).
+
+Language	Program size compared to C
+--------	--------------------------
+C		1.00
+Fortran 95	0.50
+C++		0.40
+Visual Basic	0.22
+Java		0.17
+Python		0.17
+Smalltalk	0.17
+
+Main takeaways: Know your tools.  Using the right tool for the right job is a great benefit, and this is true for libraries as well.  Among relatively equal choices, it is may be best to go with what is familiar.

Day 22-23 (architecture)/SystemArchitecture.md

@@ -0,0 +1,42 @@
+
+# Campus visit system architecture
+
+## Technology selection
+
+### Client side: Vue, HTML, CSS, TypeScript
+
+The client-side application is envisioned as a single-page web app, which will run in Vue 3.  The two main alternatives (Angular and React) were ruled out because of lack of developer familiarity with these.  The complexity of this application rules out JQuery; it will take much less code to develop in Vue.
+
+According to some cursory research, TypeScsript is much better suited over JavaScript when developing in Vue 3, and should only take a few hours to learn, given familiarity with JavaScript.  Of course, HTML and CSS go with the territory.
+
+### Server side: Node.js, Express, SQLite
+
+Speed and developer familiarity were the main rationale for selecting Node.js and Express.  Website files and AJAX requests can both be handled fine with these technologies.
+
+For a database engine, SQLite was compared with MySQL, as both are free.  According to the SQLite documentation, it should be able to handle upwards of 100,000 hits per day for a web application.  The main speed limitation in SQLite is with write transactions (especially concurrent ones), but given the small number of users (no more than a dozen) and infrequent requests (estimated at less than 100 per day), SQLite would be well within performance bounds and will probably outperform MySQL due to its simpler structure.  It is also expected to be simpler to configure and deploy.  Thus, SQLite was chosen over MySQL.
+
+#### Backups
+
+SQLite works based on a single database file, so it will be straightforward to schedule automatic backups.  For simplicity of deployment, the plan is to implement this in the Node.js server script itself.
+
+### Client-server data communication: JSON over AJAX
+
+JSON will be used for client-server data communication (e.g. visit and user data).  It is standard and integrates easily between Node/Express and client-side JavaScript.  AJAX is choosen as a default over WebSockets because server pushes are not strictly necessary.  For example, although it would be nice for a faculty committment to appear immediately on the coordinator's screen, it may not be worth the extra development time and email already serves this purpose.
+
+## Feasibility
+
+## File formats
+
+## Major database tables
+
+## Performance
+
+## Scalability
+
+## Internationalization
+
+## Security
+
+## Error processing
+
+## Fault tolerance