6.0 KiB
Criterion A: Planning
Defining the problem
Pak Hidayat, and Pak Phie, two members prominent members at JIS in IT requested me to create a queueing program. Being a relatively large school, JIS have many students and visitors requring help from the IT team.
Pak Hidayat has mentioned during our meetings thata currently, the solution is very confusing for clients, as they are unsure who will be serving them, and often the staff get overwhemed trying to serve multiple clients at the same time. Another issue with the current system is that many staff members handle a lot more staff members than others.
A promininent feature of this program will be that it will help store usage data, and produce statistics in regards to which members handle how many clients, how long they spend with each client, and average amount of time spent idling (without any client). This project's primary purpose is to make it easier for visitors to queue up for any assistance they require.
This queueing system is planned to support multiple branches (multiple queues), sends information regarding queueing via web sockets to keep it updated. Because having ticket numbers and being environmentally friendly are both important, the project will have two different modes; high capacity and low capacity mode. Ticket numbers will be assigned via a printed receipt during high capacity mode (during/after orientations, when many clients arrive at the IT office), and just a number a member will have to remember in their memory during low capacity mode.
Rationale for the proposed solution
The application will be a full-stack web application, with a microservice - esque archetecture. Golang will be running a web server and serve the front end statically, while running on a docker (containerised). Another strong reason why I chose Go for this application is because it is cross platform, but it does not run on a virtual machine. The Go team created such a compielr so that you can compile a binary to any operating system from any host.
- For my persistent storage, I will be using SQLite. SQLite gives me the best of both worlds. It is very light weight, as it runs in a single file, and gives me the power of a structured query language (SQL) system. SQLite supports rows being upto 1GB in size. Furthermore, having entire tables being larger than 1.5TB is also no problem for SQLite. SQLite also supports storing data in ram, which can help make it be much quicker (not needed for this use case). Finally, SQLite has about 138 thousand lines of source code (omitting blank lines and comments), but over 91,945 thousand lines of testing code -- 91,945,000 lines of testing code!
- For my backend system, I have chosen to use Go. Go was a programming language created by Google in 2009. Quoting from it's website, "Go arose, first as a set of ideas and desiderata, then as a language. An overarching goal was that Go do more to help the working programmer by enabling tooling, automating mundane tasks such as code formatting, and removing obstacles to working on large code bases." This is a core feature of Go. It makes the process of writing code much faster, and allows you to create a minimal viable product (MVP) much quicker. Go has a heavy focus on interfaces and structural subtyping, making code format be consistent throughout the lifespan of a project. More specifically, Go also makes deploying a HTTP(S) application stupidly simple, working with sockets trivial, and interfacing with SQLite is also very well supported. Overall, Go is the perfect candidate for quick web applications that keep a structured format.
- For the frontend, my plan is to use ReactJS. React is a framework created by Facebook that makes writing frontend code very easy. In essense, it is a templating language that runs in the client. React also has a state (Redux), which allows you to move your applications logic/state (e.g. logged in user status, current branches, queue status, etc.) into a centralised location. I already have experience using VueJS alongside Vuex (alternate for Redux), and am deciding to use React to see which is better for my programming style. Another advantage of React is that due to the templating style, many components are heavily reused, heavily modularising the front end, making debugging and working with complex views much simpler. ReactJS also has fantastic developer tools making it trivial to inspect the current status of the application, access the state live, and showing the hierchy of the templates.
Stating the success criteria:
- The program has a high capacity mode, where a large number of clients are being handled, with receipts and ticket numbers
- During Low capacity mode, ticket numbers will just be displayed and expected to be memorised by the client
- Have a dynamic setup for branches and tables, editable via a visual User Interface.
- Have operations to create new tables
- Have operation to assign a user to a specific branch (users can not be in different branches at the same time)
- Have the operation to create new branches.
- The program shows allows the export of statistics, showing specific information for each table, and the history of each client. Statistics include (but are not limited to)
- Average time per ticket
- Average time idling
- Tickets handled per day, month, and total
- Total time working with a client
- Total uptime
- The program works with a centralised "TV", where the live data for each branch table is shown.
- The program is interfaced with a printer and prints the client queue number
Sources
- Open Source Community. “How SQLite Is Tested". SQLite, 10 July 2019, sqlite.org/testing.html.
- Sahin, Kutlu. "7 Reasons why you should use React". JotForm, 27 January 2017, stories.jotform.com/7-reasons-why-you-should-use-react-ad420c634247.
- Open Source Community. "Frequently Asked Questions (FAQ)?". Golang, Accessed 19 September 2019 golang.org/doc/faq.
- Abramov, Dan. "Why Use React Redux?". React Redux, 29 May 2019, react-redux.js.org/introduction/why-use-react-redux.