Developing Einstein 2.0

Having opted for a project which entails having one Dockerised application run another, getting to grips with Docker an inevitability. The first item on the agenda was to get something resembling a production environment running inside a container. Instinctively I opted for doing with within a single container. I started by basing the container/image on Alpine Linux a popular light-weight distribution which uses Busybox. While we had originally proposed to use MySQL for our production database, a little research on the topic showed that the Django developers recommend PostgreSQL. (They express far fewer caveats about it at any rate). FROM alpine:3 # apache runs on port 80 by default EXPOSE 80 # install system packages RUN apk add --no-cache python3 py3-pip postgresql15 apache2 apache2-ctl \ apache2-mod-wsgi py3-psycopg2 Using Alpine also allows us to take advantage of its convenient package manager apk . Here where thing got a little sticky however as apk installs an older...

Since we have already been using bootstrap to style the nav bar, login and signup forms and various buttons, Michael had the idea of implementing django-bootstrap5, which would allow us to further style our app. In just a few hours we had much improved UI.

 We are making good progress, we have all the "models" set-up, we have a basic user-interface, a basic User Account System. Users are able to view their modules, labs and exercises. Instructors are able to create and edit Modules etc. We started brainstorming a system that would allow a student to enrol into a module. We thought about ways of automating the process of registering a large amount of students. In this way the system would be similar to the actual Einstein system, in that, students wouldn't need to do anything themselves. We finally decided on creating a system similar to poodle or moodle, where a student would need a code, usually given by the lecturer, to enrol themselves in a module and view its contents.

In our project’s function specification, we said user registration would work though emails. This would have worked in a manner we are all familiar with. User registering would need to confirm that a given email address was theirs by entering a code or clicking on a link they received via email. It was also envisaged that instructors when creating a class would enter a list of their students’ emails addresses. Somethings are easier to describe than code. In order to write this system, we would have needed some kind of stub email system to make up for the fact that we don’t have easy access to smtp servers. Accordingly, we have opted for a simpler system where students can register for a class by using a unique registration code. This simplifies development and registration and could always be supplemented by an email and/or system authentication plugins were development to proceed further. Another change we have made was to rename the class "class" to "module...

 As part of your 3rd year in DCU, you must complete your 3rd year project. Michael and I decided on recreating "Einstein" which is a system DCU uses to automatically verify scripts sent by students and give back grades. The core idea of our project, however, is that this system would be redistributable,  meaning, anyone could use this system in their own school, college, or even home. With just under 2 months of time, we began working.     We decided to use Discord for communication, as we already had it setup and were using it before beginning the project. After a turbulent start we got ourselves organised and started by agreeing which tasks each of us would work on. We would keep each other updated so as to not end up working on the same thing.     We decided to use django, since we were already familiar with it and it would allow us to build and deploy a working system it fairly quickly. We needed to get the basics right. So we started by creat...