Tech Team Meetings Meeting minutes for each week. April 2nd Meeting Minutes Start 5:30 PM End 6:10 PM Eric has created the attendance object and the records repository as well as the handlers Nicole is making progress on surveys Terrance has finished everything. Changed address Terrance is working on getting user_mangement integration testing with redis Terrance is also working on Dockerizing. Done with everything else Zuting, Thomas introduced to team Zuting and Thomas task pending Christopher E. working on issue #21 on blueprint_admin. Should be done by the end of the week. (couldn't provide update at meeting due to scheduling conflict, provided updates in DMs to ezri) Thomas is working on application CRUD for admin backend No one to work on application forms for admin backend Audrey can do design opportunities Will followup with miguel to discuses separately April 4 Meeting Minutes Start 7:00 PM Attendance:  Kyle Kouch, Miguel Merlin, Cameron Marotti, Christopher Engelbart, Eric Zhang, Ezri Zhu, M. Bertan Tarakcioglu, Nicole, Maya Patel, Terrence Zhang. Ezri: k8s meeting with miguel, bertan, thomas went well. They will work on the following: documenting existing infrastructure & process look into k3s document plans for k8s infrastructure document ideas for future workshops, e.g., (git, docker, etc..) reached out to github for enterprise will reach out to cs dept & SGA for funding re: servers, AI, etc.. team 1 aad infrastructure deployed successfully, google auth working team c4p website deployed slightly, had an issue with mongo db and avx cpu flag, using alternative container. will finish deploying it later this week. Lucas: Added more to the PR but failed the node build test. There is a slight error regarding return types. Should be able to fix by tomorrow Christopher: finalized the alert and made aesthetic changes to the loading spinner. Is having issues with fetching data from the API. SQl script Eric Zhang: moved AttendanceService/AttendanceServiceImpl to their own repository called attendance in service repo. moved AttendanceRecordRepository to its own repository so its separate from users Deleted content of the methods. Miguel Added some features to the backend Wrote onboarding documents Need backend and user api Terrence Resolving some issues in the pull request Maya Saw comments and will make changes End  7:26 PMApril 9th Meeting Minutes Start 5:34 PM Attendance: Kyle, Miguel, Audrey, Eric, Lucas, M. Bertan, Nicole, Sneha, Terrance, Ezri, Jason Christopher: Working on creating a SQL script for creating and populating tables. Audrey Started wireframing for blueprint admin on figma. Will move onto revising the design and creating mockups that will reflect the real product Prioritize website first, Admin second Ask Sahana about working together Lucas Debugging the add user button Eric Added a redirection from the read more button to the information section of the page Added OpenGraph tags to each file on the website, created a common OpenGraph file to be shared across all pages and in each independent page added its own unique title and URL Miguel Java backend: Added new class (exeptions) Frontend: Added new types of objects Adding the API calls Added some of the stops for missing pages Nicole Finished the event servace repository Submit a pull request New task (Create CRUD for blog) Ezri Worked w/ jason to deploy admin backend Wrote some initial documents of the stag and k8s setup on the wiki Reached out to swics to potentially collaborate on events Admin backend db deployed successfully, waiting for the upstream code to read db conn url Created github issue #11 (seeing VM warning) Sneha Welcome email Submitted a pull request New task (change favicon to blueprint logo) Terrance Should be done with everything Assigned new tasks (Look into static site generator, figure out format for each members file) Jason Working with ezri on the staging environment postgres deployment Fixed error Need template for project descriptions End 6:01 PM April 11 Meeting Minutes Start 7:04 PM Attendance: Kyle Kouch, Miguel Merlin, Audrey Yoo, Christopher Engelbart, Eric Zhang, Ezri Zhu, Bertan Tarakcioglu, Maya Patel , Miguel Merlin, Terrence Zhang Christopher Working on the SQL script Audrey Finished the first iteration of the wireframe for the blueprint website's homepage on figma Ezri Adm dash+usermgmt cors fixed Preliminary debugging on admin panel for user management feature Miguel working on fixes Will work on finishing up c4p server setup and more documentation on k8s Will talk to eboard about turning one of the tech team meetings into a more open GBM for a bigger presence on campus Will work more on general tech team docs Bertran Made changes to github rules Maya Implemented changes for pr Miguel Java backend End 7:17 PMApr 16 Meeting Minutes Starting time: Started 1730 Attendance: Ezri, Eric, Terrence, Audrey Kyle absent due to school trip Scribe: Ezri Christopher Engelbart I finalized the script and (I think) made the necessary changes in docker-compose.yaml. I’ve tested the SQL script itself in a SQL environment, but haven’t with the Docker container. Draft PR created Audrey no update Eric AttendanceServiceImpl (not tested, will make PR after) Terrence website: Updated project team page website: template for user page done Ended 1738April 18th Meeting Minutes Start 7:06 PM Attendance: Kyle, Eric, Christopher, Bertan Audrey Working on the wireframe for the homepage Chrisopher The SQL script  has been merged into the backend. End 7:08 PM September 10th Meeting Minutes Projects List of projects the Tech Team has worked on Blueprint Admin - Spring 2024 Blueprint Admin Spring 2024 We are glad that you have decided to join the Tech Team this semester. We hope this experience serves as an introduction to the world of software development. By the end of the semester, you will be able to improve your coding skills and have a greater understanding of Web/API development. Overview of the project To help our Project Teams develop software faster, we provide the teams with a staging environment. Here, Project Teams are able to deploy a production-ready application that will help them test new features and showcase their progress to the NPOs. We don't want anyone to have access to this staging environment. Therefore, we use a tool named SSO (Authelia). Have you noticed that whenever you try to access Canvas or Workday, you are prompted to log in to a page? This is an SSO. It is a way for Blueprint to have a homogenous login. The SSO we use is called Authelia. The way Authelia retrieves the users with permission is through a YAML file. For example: users: user1: disabled: false displayname: Blueprint User 1 password: existingpassword email: user1@blueprint.com groups: - admin - dev user2: disabled: true displayname: Blueprint User 2 password: existingpassword email: user2@blueprint.com groups: - admin The main feature of our project is having a way to manage this YAML file. We need to be able to add, delete, disable, and update users in this YAML file. However, we also want to extend the functionality of our application by adding new features such as Team Management, Finances, Blog management, and Event Management. Blueprint Admin (Frontend) The frontend application is currently being developed with React using TypeScript. The web application should have the following pages: Member Management Application Management Team Management Budget Management Member Management The User Management page serves as the central hub for administrators to oversee and control user access and profiles within the system. This page allows for creating, editing, and deleting user accounts, enabling administrators to assign or revoke permissions and access levels. Key features include user search, filter options to locate users quickly, and detailed user profile views that display login history, activity logs, and personal settings. Through this interface, administrators can also reset passwords, manage roles (e.g., admin, user, guest), and set up multi-factor authentication to enhance security. Application Management The Application Management page is tailored to oversee and process applications submitted to the organization. This platform serves as a centralized system for administrators to review, sort, and respond to various applications efficiently. Key functionalities include viewing and assessing each application, tracking its status (e.g., received, under review, approved, rejected), and managing communications with applicants directly from the interface. Team Management The Team Management page focuses on facilitating team organization, collaboration, and productivity within the company or system. It provides tools for creating and managing team structures, including working groups. Administrators can assign members to teams, set roles and responsibilities, and track progress on team objectives or projects. Features may include shared calendars, task assignments, performance metrics, and communication tools to support effective teamwork. The page aims to centralize team resources and information, making it easier to manage workflows and ensure that team members are aligned with their goals and deadlines. Budget Management The Budget Management page provides a comprehensive way to track Blueprint's budget. Throughout the semester, we organize various events for which we need a budget. This page will help us track how much of our budget we have allocated to events and how much we have left for future events. Since we are migrating our servers to a cloud provider, we need to see if our server usage will exceed the budget. Blueprint Admin (Backend) User ManagementKudos Design Document Problem As students and developers, our lives move fast, and accomplishments for our work often goes unnoticed. Since we are tasked with executing and delivering software on top of schoolwork and other responsibilities, it is easy to feel overworked and burnt out. The Tech Team will create a tool that facilitates interconnectivity across project teams by allowing developers to leave feedback under each other's work during sprints. Feedback can be positive or constructive, and will always be anonymous. Features The app consists of two main pages. Features for page 1, the main page: a 4 x 4 card layout, where each card contains the following: commit content headline author streak/trend info (if applicable) a text input box a sidebar that allows users to navigate team archive. It has: teams dropdown -> clickable sections to view the commits for each project team team 1 team 2 team 3 archive dropdown -> clickable archives with commits and kudos from past sprints 3/21 sprint 3/14 sprint 3/7 sprint 1 each of these components will have filter, sort, and search functionality Features of page 2, the admin page: Page 2 will have admin access only. dashboard layout where an admin can do the following: start a kudos session. admins can open up the kudos board for developers to visit and interact with. the vidibility of the board changes at the admin's discretion. review all comments. admin can see comments on all commits (with username attached?) (identify user who made comment, but dont display content?) view comment analytics. admin can see how many comments a developer has made by sprint or all time. set timed start and end. admin can set a timer that will be displayed on the maoin page indicating when the next session will be. once a session is in progress, another timer will be dispalyed indicating when the session will close. End-to-End User Workflow 1. General User (Developer) Experience - Initial Access: The user opens the application in their web browser. The frontend makes an API call to the backend to fetch the latest commit data and active session status. The main page (4x4 card layout) is rendered, displaying commit headlines, authors, and any existing streak/trend information. The sidebar is populated with team and archive navigation options. - Browsing Commits: The user can scroll through the 4x4 card layout to view different commits. They can use the sidebar to navigate to specific teams or archived sprints. Filtering, sorting, and searching functionalities allow them to find specific commits. The frontend send the filter, sort, or search parameters to the backend via API calls, and the backend returns the filtered, sorted, or searched data. - Leaving Feedback (Kudos): If a kudos session is active (indicated by a timer or clear visual), the user can enter feedback in the text input box within each commit card. When the user submits feedback, the frontend sends a POST request to the backend API, including the commit ID, user ID (anon), and the comment content. The backend stores the comment in the database, associating it with the commenter, the commit, and the author. (If using websockets, the comment is broadcasted to other users in real-time???) - Viewing Session Status: The user can see the status of the current kudos session (active, inactive, time remaining) on the main page. This information is fetched from the backend and updated in real time if web sockets are implemented. 2. Admin User Experience - Accessing Admin Page: The admin user logs in with their credentials. The frontend checks the user's role and redirects them to the admin page if authorized. - Starting/Ending a Kudos Session: The admin uses the dashboard to start or end a kudos session. The frontend sends a POST request to the backend API to update the session status in the database. The backend updates the database and, if using WebSockets, broadcasts the session status change to all connected users. - Reviewing Comments: The admin can view all comments on the dashboard. The frontend sends a GET request to the backend API to retrieve all comments. The backend retrieves the comments from the database and returns them to the frontend, possibly with user identification (for admin review only, not public display). - Viewing Comment Analytics: The admin can view comment analytics, such as the number of comments per developer and per sprint. The frontend sends a GET request to the backend API to retrieve the analytics data. The backend performs the necessary data aggregation and returns the results to the frontend. - Setting Timed Start/End: The admin can set the start and end time of a kudos session. The frontend sends the start and end times to the backend via a POST or PUT request. The backend stores the times in the database and uses them to control session status and display timers on the main page. If web sockets are used, the time remaining will be updated in real time. High Level Architecture Frontend (Client-Side): React/TSX UI handling user interactions, and displaying data. rendering the 4x4 card layout, sidebar navigation, and admin dashboard. API calls to backend db. Backend (Server-Side): Django/Python for the APIs. manages data retrieval from GitHub API handles auth using GitHub API implements logic for filtering, sorting, and searching commits and comments. Database???: MongoDB to store commit data, user information, comments, and session details. Real-time Communication???: websockets? Outstanding Questions should we store commit data? or just pull instances from API?Staging Environment The blueprint staging environment serves two primary purposes. Hosting the staging environments for our project teams Hosting the infrastructure powering blueprint internal operations Currently the staging environment is hosted on one singular machine sponsored by EzriCloud. As Stevens IT is unable to provide us with a working cloud machine. In the future, we hope to move our infrastructure to AWS once we have a stable funding for it. Ezri Zhu should be the primary contact for any server issues. They can be reached via their discord. The server's NixOS configuration code is made available here https://github.com/stevensblueprint/techops/ Below are the things that is currently on stag0.nyc.sitblueprint.com NYCMesh team staging service (deployed via docker compose) AAD-ADMIN team staging service (deployed via docker compose) C4P team staging service (deployed via docker compose) Authelia SSO w/ nginx reverse proxy (deployed via NixOS configuration) Vaultwarden password manager (deployed via NixOS configuration) Bookstack (this wiki) (deployed via NixOS configuration) Blueprint internal admin dashboard (deployed via docker compose) Blueprint internal admin backend (deployed via docker compose) Blueprint internal user management service (deployed via docker compose)Kubernetes For the fall 2024 semester, we are planning on launching our internal k8s platform to run the things that we're currently running on docker compose. Although using kubernetes at our current scale is probably not the greatest idea in terms of maintainability, we are still choosing to do this so that interested tech team members can learn to operate k8s containers. We will likely be using k3s - https://k3s.io/ Ezri Zhu will be the project owner for the k8s cluster, they can be reached via discord. This page is currently WIP.Blueprint Admin Design Spec Blueprint Admin Design Spec Problem Overview We develop software for non-profits at no cost. To promote talent at Blueprint we run the Tech Team that serves as low commitment team where Stevens students can come and learn software engineering skills. Currently, Blueprint has around 40 active members that work on the projects with the NPOs and in the Tech Team. Software development and the usage of computing and building tools. Managing the access of said resources for every member has become unsustainable for the Blueprint e-board and Tech Lead for the project Teams. Having a centralized solution to administer Blueprint resources and manage member is necessary for the future success of the organization. Solution Overview To mitigate the need for a management solution, the Tech Team has started building a user/resource management solution. Most of the backend service that will power the admin has already concluded, however designs for the front-end have to be formalized. Feature Description The admin dashboard should provide the following features: Be able to log-in as an e-board, Teach Lead. Note: A single member might belong to multiple roles, so when the member logs in they should have the feature available for each of the roles they belong to. Once logged in, the member should have a sidebar where they can edit their information, such as name and password. A member should also have profile photo (Mostly all member will have a default profile photo, it could be the blueprint logo, or a stock user photo) E-board functionality Blueprint E-board members should be able to do the following: Send an invitation email to an interested member given the email and name of the member who wants to join View a table of all the members The displayed information of the members is the following: Roles (List of Strings) Team they belong to (List of String) Date joined (LocalDate) Active (Boolean) The table can be filtered by the afore mentioned columns The e-board member can edit each of the field of a member Team Lead functionality Blueprint Team Leads should be able to do the following: View a list of all the member associated to their team Edit the active status of a member team Take attendance of each of the meeting The Team Lead should be able to create an attendance record with some basic information such as Date and Location The Team Lead can only take attendance on the active members of the team View statistic on the attendance of the Team such as: Drop out rate of the team (How many people have been deactivated since the start of the project?) Attendance rate Kudos Week 1 + 2 Goals Learn about Kudos! Gain an understanding of some essential developer tools Install git, Node, and VSCode Create and clone your own repository How will this work? Weekly session where we will: Go over the session's goals Code together Get support if needed Recap By the end, we will have a finshed project! Why Kudos? At Blueprint, recognizing the contributions of our developer members is crucial for fostering a positive and productive project team environment. This tool is specifically designed to highlight the efforts of these members and gather valuable feedback. By acknowledging their hard work, especially amidst their academic and other commitments, we aim to improve their overall project team experience and prevent potential feelings of being overworked or burnt out. Setup For any project, it is essential to have certain 'tools' installed... These tools go by many names: libraries environments packages dependencies etc. But they all serve one broad purpose: help developers build. So, before we begin building our project, lets first install all of the necessary tools we'll need along the way. Git and GitHub A key foundation of software development is collaboration. Across industry, developers collaborate using two essential tools: Git and GitHub Later on, we will explore these two tools, but for now lets just install them. Windows install Go to the official Git website at https://git-scm.com/downloads The download for Windows should begin automatically. Once the installer finishes downloading, run the .exe file. Follow the prompts in the installation wizard. After installation, open a new terminal and type git --version to verify the installation. macOS install The easiest way to get Git on macOS is in the terminal. Open your Terminal application. Type git --version and press enter. If Git is not installed, a pop-up will appear asking you to install the command line developer tools. Click "Install" and follow the on-screen instructions. Now, lets create and authenticate a GitHub account. Creating Your GitHub Account Creating a GitHub account is a simple process. Go to the GitHub Website: Open your web browser and navigate to github.com. Sign Up: On the homepage, you'll see a sign-up form. Enter your email address, create a password, and choose a username. Verification: You'll likely need to solve a quick puzzle to verify you're human. After that, GitHub will send a verification code to the email address you provided. Go to your inbox, find the email, and enter the code on the GitHub site. That's it! You now have a GitHub account. Authenticating Your Account Authentication proves your identity when you want to push (upload) or pull (download) code from your computer. Using your password for this is no longer supported for security reasons. Instead, you should use a Personal Access Token (PAT). A PAT is like a long, secure password that you use only for accessing GitHub from the command line or apps. Go to Your Settings: Click on your profile picture in the top-right corner and select Settings. In the left sidebar, scroll down and click on Developer settings. Click on Personal access tokens, then select Tokens (classic). Generate a New Token: Click the Generate new token button. Set an Expiration date. For better security, don't set it to "No expiration". 90 days is fine. Under Select scopes, select the repo scope. Copy and Save Your Token: Click the Generate token button at the bottom. This is the only time you will see the token!!! Copy it immediately and save it in a secure place, like a password manager. If you lose it, you'll have to generate a new one. Using Your PAT: Now, when you perform a Git operation in your terminal (like git push) that requires authentication over HTTPS, you'll be prompted for your username and password. Enter your GitHub username. When asked for your password, paste your Personal Access Token. You're all set! Your GitHub account is now created and authenticated for use on your computer. Node Like git, Node is a tool in the software development world that is a must-have. Among many other things, it allows us to see the changes in our code live in our browser! So as we add components of our app, we can ensure they look and function as we want them to. Windows Go to the official Node.js website: https://nodejs.org/en/download Download correct verion. Run the installer and follow the on-screen instructions. Once the installation is complete, you can open the terminal and verify the installation by typing: node -v npm -v These commands should return the version numbers for Node.js and npm, confirming a successful installation. macOS The easiest way is to download the official .pkg installer from the Node.js website: https://nodejs.org/en/download Choose the LTS version and run the installer after it downloads. Follow the installation steps. The installer will guide you through the process. After installation, open a new Terminal window and run the same commands as above to verify: node -v and npm -v. Visual Studio Code We will be writing all of our code using Visual Studio. Visual Studio has a simple install. Simply use this link and follow the steps: https://code.visualstudio.com/download Troubleshooting Before we move on, lets address some common issues that you may run into during setup. Checking Node Versions (Windows Users) If you recieve an error when running the node - v and npm -v commands: Search 'Terminal' in your taskbar start menu. Hover over the Terminal Icon, then right-click. A menu should appear. Click on the option to 'Run as Administrator'. This should open a new terminal that indicates you are an Administrator in the title bar. Run this command: Set-ExecutionPolicy RemoteSigned. Now, try running node - v and npm -v once again, and you should be able to see their versions, confirming your Node has installed correctly. Creating a Repository You now know the basics of git and GitHub! The next step is to create your own repository where you'll store all of your code for the project. On the main page of GitHub's site, you will see a green box in the top left corner that says 'New'. Click it, and you will be redirected to a new page that looks like this: On this page, you will enter the details of your repository. In our case, this includes a specific set of options that oyu should copy from the screenshot above. Your repository name should be my-kudos, visibility should be public, and add README option shoud be toggled on. Click create, and you will again be redirected. This is your repo! Now, all you have to do is follow some of the steps from the prior section. The first is cloning your repo with git clone. Like before, to check that the clone was successful, cd into your new directory. Note: In this example, I also used the ls command, which lists the contents for your directory. Since we just created our repo and initialized it with a README.md file, the only thing in our project folder should be that file - and it is. Making a Change As a way to test what we've done so far, lets try actually making changes to file and seeing them reflected in our repository. Our goal will be to edit a file in our project - then upload the changes to our GitHub repo using the commands we just learned. Editing a file In VSCode, open your README.md file. It should look something like this: Lets make a simple change: add a short sentence about yourself! It should look like something like this: Note: Those green bars next to each of the lines we just wrote indicate that these are new (uncommitted) lines. This is good! It means that we now have code to upload (commit) to our repo! Making a Commit Once the change is made, use the git add command in order to include or 'stage' our changes for the next commit. Commits can be thought of as checkpoints; more on that later. In this case, we made changes to the README.MD , so our file path is /README.MD and we type in: git add /README.MD Note: You can use git add to add as many files as you need, and another common option is to use git add . to add all files with changes. Also, The file path is case sensitive. Checking Changes to be Committed You can use the git status command to check what files have been added or "staged" for a commit to ensure you added the right things. In this case, it's only the one contributors file that we added. You can see here that our file is under changes to be committed and is in green text. Changes not staged for commit will be in red (if there are any). Committing Changes With our changes made and staged, we can create a commit which can be thought of as a checkpoint for our code. We can revert to this point if we make mistakes or need to look at the version of the code at this point in time. It is also good practice to include a commit message by using the -m flag to describe what changes were made. For us, we will just say that we are adding a new contributor, like so: git commit -m "Added info about me!" Commit Messages: When writing a commit, it is usually good practice to follow a convention. At Blueprint, we use the Conventional Commits specification: www.conventionalcommits.org, but don't worry about that right now! We can commit as often as we want, or when we feel it is necessary before making big changes. Pushing a Commit In order for our changes to appear on the remote repository (the one on Github, which is online), we need to push our changes using the git push command. If we run it as is, however, we will encounter an error: It is no big deal - the reason it happens is because when we create the branch contributors/johnDoe, we only created it locally and it does not exist on the Github repository. Therefore, we must run the command shown: git push --set-upstream origin contributors/ Once the branch is set up remotely, or if the branch already existed remotely and was not created locally, we can simply use git push. Seeing our Changes Finally, we can confirm that all of these steps were done correctly by going over to our repo on GitHub and refreshing the page. Upon doing so, we should see any changes we made reflected on the web, like this: Note: Another way to check is by opening VSCode again, and seeing if those green bars from earlier are still there. If not, then that means there are no new lines to stage, and your commit was successful! Project Outcomes At the end of our time together, I hope that you all improve on a two key areas of software development: Technical Skills Development Patterns: Hooks, Context, functional components State Management: Complex state updates and data relationships User Experience Design: Responsive, accessible, intuitive interfaces Problem Solving: Handling edge cases and data integrity Project Management Skills Incremental Development: Built feature by feature Requirements Analysis: Translated real needs into technical specifications Testing Strategy: Systematic verification of functionality Documentation: Clear code organization and commenting Week 3 Goals Intro to CSS Building a demo page Implementing the KudosCard component A Note About Project Versions and Installations... I knwo we had some mix-ups and discrepencies last session when trying to create a project. So, we need to do some cleaning to ensure there is no confusion in the future with project names, versions, etc. Let's take a few minutes to delete all prior projects relating to Kudos (blueprint_kudos, kudos-me, etc.) For the last time (fingers crossed) let's create a React project configured to use TypeScript. In your root directory, run: npx create-react-app blueprint_kudos --template typescript After running, you may be asked a few questions. Simply respond yes to all of them. Then, to open your project in VSCode and start your live development server, run: cd blueprint_kudos npm install npm start Part 1: CSS Basics Last week you saw some live changes made to the browser, and hopefully gained some understanding of why we really need tools like Node and git. This week, we will be getting hands-on with one of the main languages of our app: CSS. What is CSS? CSS, which stands for Cascading Style Sheets, is a style sheet language used for describing the presentation of a document written in a markup language like HTML. Basically, it makes websites look nice. HTML You may have heard of HTML, but what does it actually do? HTML is the structure of a webpage. It's like the skeleton or framework that holds everything together. Here is some brief info about HTML before we begin diving into CSS. Feel free to check out some tutorials/videos on HTML ifn you want to learn more tha what is in these docs. How HTML Works HTML uses tags (words in angle brackets) to define different parts of a webpage:

This is a heading

This is a paragraph

Cheatsheet Use this as a cheatsheet for whenever you forgot/don't know which tags to use.

,

,

- Headings (big to small)

- Paragraphs

- Container/box