What is CoDr?
Features
An almost complete list of features can be found on the devstats route within the application (available only to admin users).
Frontend
- AdminLTE Dashboard - used for user dashboard - badges, boxes for easier management of the interface
- Visualization - mainly D3 stats on the user dashboard (barchart and piechart), badges on user dashboard, the
/datafilteringrelated routes showing json with solvedTasks or persons, and offering the possibility of visualizing in a Codepen - Codepen API Integration - as mentioned, solutions from FCC users can be visualized, making use of the Codepen API prefill through POST
- Grunt integration - for now, we use grunt for minification of the main .css file, and setup a grunt watch to do it on-the-fly (when changes are made to the .css, the file is minified by Grunt)
Backend
- Java json parser - used to parse the FCC json and insert into the relational database (to be faster, insertions require that no index is made before or during the process - indexations are made after a batch of insertions are done)
- Oracle DB - we make use of relational DB advantages and also of PL/SQL (for procedures needed for visualizations)
- REST API - any user can query the database (with a limit on the rows returned), and have access to data
- Authentication (RBAC) - we defined 2 roles - BASE and ADMIN - BASE users have access to the dashboard, settings, datafiltering routes, while ADMIN users have access to all BASE routes and additional routes like
/admindashor/devstats - Integrated Gitter chat - we used Sidecar to integrate a chat (FreeCodeCamp/FreeCodeCamp room), in case our users have any questions regarding FCC (provided they have a Gitter/Github account to login to Gitter)
- Contact form - used to contact our site administrators in case of a question, proposal or issue
Devops
- Logging - made with basic Node.js console.log, and with Winston
- Intermediate Github use - milestones, issues, labels, commits that link to issues, branches, READMEs
- Academic documentation - this documentation (implementation-side), the architecture documentation, and the main page that links to those 2
- Scripting - workspace script (.bat), deployment scripts (Vagrantfile, Dockerfile, utility.sh script)
How we used Github
We kept roughly the same branch structure as in the architecture phase, except for a new branch, frontend, when we worked simultaneously, and rebasing with each other would have lead to merge conflicts (this led to making a pull request when synchronizing the frontend branch with the master branch).
We used milestones to structure our work for beta (see Sprint for beta version. As such, we used issues to track our TODOs, bugs and enhanecements (see closed issue list).
To further describe the issues, we made a few custom labels (list here): backend, frontend, documentation.
In order to further version our application, we made use of the tagging/release system to make a release for the presentation (you can see it here). When the application will reach version ~1.x.x, the release will also contain scripts to easily deploy the application (dockerized Node.js and Oracle11g database, with a small subset of the FCC database to be imported with the json parser).
Relational Database
We store in the database the FCC user data obtained from the json, our users data (that have an account in our web application), and various statistics tables, used for aggregating and processing data. We also cover PL/SQL functions and procedures for easier querying of the database (defined here in files like pachete.sql, additional-functions.sql).
The database schema has been updated. The main changes that will be made to the database will only impact statistic tables (to store certain statistic values, and optimize the querying and transactions with the database) and PL/SQL functions and procedures.
Implementation Details
The application is built with a RBAC (role-based access control) system for login, for two types of users, a normal Base user and an Admin type user. Using specially tailored node libraries (to name a few: bcrypt, express-session, jsonwebtoken), once a user logs in, a token is generated. This token is saved in a session, which expires after 15 minutes of inactivity, and is used to validate if one has access to the routes the users are allowed to access.
The normal user has access to the app's special features, like a dashboard filled with rich statistics about the Free Code Camp data. Also, one may explore the database by using our custom made filters.
The REST API is open to all users, including the ones without an account. The API gives the option to retrieve different parts of our database. Using the API documentation included (based on swagger.yaml, you can either get the .yaml here, or access within the application the /help/rest route to see a .yaml static export), and you can start developing your custom apps today.
Scripting
To make developing easier, we wrote a .bat script to open the application and setup the workspace. It opens 3 terminals: grunt watch (opening the grunt watch to minify the main css file on change; synchronous/blocking call), npm start (running the server; synchronous/blocking call), git status (an extra window to use for git work or for other purposes - eg: npm install, networking).
We also have minimal deployment scripts (Vagrantfile, Dockerfile, and utility.sh on the docker branch), that have to be updated for the database dependencies.
Responsibilities / Task assignments
Frontend - Dan Alexandru ✉ ✉
Backend - Java (FCC json parsing and insert into the database) - Alberto Cieri , Iulian Luca
Backend - PHP (prototype for database querying, features, pagination) - Iulian Luca
Backend - Node.js (the main part of the application, REST API) - Dan Alexandru ✉ ✉ , Alberto Cieri
Database - Oracle 11g tables and procedures - mainly Iulian Luca with help from Dan Alexandru ✉ ✉ , Alberto Cieri
Scripting, github coordination, documentation - Dan Alexandru ✉ ✉
Conclusion
CoDr is currently a work in progress and is open to change. If you have feedback, simply open an issue on GitHub, or make a pull request.
CoDr currently has minimal documentation, wireframes and MVP made (almost complete). We aim to develop the full architecture, if our time allows it.