You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
89 lines
5.2 KiB
Markdown
89 lines
5.2 KiB
Markdown
# Conclusion
|
|
|
|
The project of ReCodEx was a great experience with developing a bigger
|
|
application in team of people. We mostly enjoyed the time spent on the project,
|
|
however the deadline was too tight to implement all nice features we thought of.
|
|
Our implementation meets our predefined goals and is ready to be deployed
|
|
instead of current tool CodEx.
|
|
|
|
We made several design choices during planning and implementing the project.
|
|
From perspective of today we are mostly happy about them and we believe we have
|
|
done the best we could. One of the biggest questions was the broker/worker
|
|
programming language. The winner was C++, which is really great language
|
|
especially in revisions starting at C++11. But we are not sure if Python would
|
|
not have been better option. From the list of good choices we would like to
|
|
mention early unit testing with continuous integration, using ZeroMQ messaging
|
|
framework and the design with splitting logic into multiple components.
|
|
|
|
To sum up, we created an extensible base environment for years of further
|
|
development by numerous student projects. The faculty would benefit from higher
|
|
hardware utilization, less administration effort and a possibility to offer
|
|
ReCodEx as SaaS to partner grammar schools. Students would also appreciate
|
|
state-of-art development tools.
|
|
|
|
During the development we were using whole bunch of development tools. We would
|
|
like to thank authors, maintainers and contributors of these tools to help us
|
|
complete this project. Most notably we would like to mention explicitly the top
|
|
projects: Git and GitHub, Visual Studio Code, IDEs from JetBrains, ZeroMQ
|
|
framework, C++ spdlog library, Travis and AppVeyor CI, Nette framework and many
|
|
many others. Thank you.
|
|
|
|
Finally, we would like to thank our supervisor, Martin Kruliš, for his support
|
|
and great effort correcting text of this documentation.
|
|
|
|
## Further Improvements
|
|
|
|
A lot of work has been done, but it opened a whole bunch of new possibilities
|
|
for subsequent student projects and other kinds of contribution. We would be
|
|
happy to see people contributing to this project to make it even more awesome.
|
|
We are presenting a brief list of features we think might be worth of
|
|
completing. Surely, the list is not complete and may change in time.
|
|
|
|
- Finish web frontend. In time of the project submission it does not contain all
|
|
features for the best user experience in all roles. This task is suitable for
|
|
people with basic web programming experience, React and Redux knowledge is an
|
|
advantage.
|
|
- ~~Create web editor of job configuration. ReCodEx job evaluation follows quite
|
|
complex task flow. To create valid configuration, author of exercise has to
|
|
write a pretty long YAML file by hand. This of course can be partially or
|
|
fully automated but was not implemented at time. This task therefore consist
|
|
of creating web based editor of this configuration with prepared task
|
|
templates allowing user to change their properties and connect them. After
|
|
submit, YAML job configuration should be properly created.~~
|
|
- ~~Write alternative commandline frontend. A lot of users want to submit their
|
|
solutions directly from command line. That is newly possible in ReCodEx
|
|
because of REST API, but no suitable frontend exists yet. There is unfinished
|
|
attempt to create one in NodeJS, accessible in ReCodEx organization on
|
|
[GitHub](https://github.com/ReCodEx/cli). The goal is to finish this project
|
|
or create alternative tool. We would like to see one written in Python.~~
|
|
- Create mobile frontend. It would be really nice to have mobile application
|
|
when you can read exercise assignments and examine your progress and
|
|
statistics. All is possible due to ReCodEx REST API. The basic Android
|
|
application is in development by ReCodEx team as project for programming
|
|
mobile devices class. The code will be published as part of ReCodEx GitHub
|
|
organization.
|
|
- Design and implement backend monitoring. For administrator would be great to
|
|
examine status of backend (broker, workers, monitor, fileserver) directly in
|
|
browser. Key information are which machines are online, offline or failed,
|
|
which worker is now running a job (maybe with current progress) and view
|
|
configuration of worker. Also some statistics with graphs should be made, for
|
|
example workload of workers. More advanced feature is the ability to restart
|
|
workers on the change of their configurations.
|
|
- Finish .NET sandbox for Windows. We developed initial sandbox for Windows
|
|
environment, [WrapSharp](https://github.com/ReCodEx/wrapsharp). WrapSharp is
|
|
only for .NET platform assemblies and most notably for C# programs and cannot
|
|
be used generally for sandboxing on Windows. The goal is to finish
|
|
implementation and do a really detailed security audit of the project. Also,
|
|
integration to the worker is not fully done yet.
|
|
- ~~SIS integration. A very nice feature is (semi)automatic creation of groups and
|
|
assigning students to them depending on their timetable in student information
|
|
system (SIS). However there is no standardized API for such communication yet,
|
|
but we hope this will be possible in the future. Implementing this feature
|
|
means extending ReCodEx API by a SIS module in PHP.~~
|
|
|
|
|
|
<!---
|
|
// vim: set formatoptions=tqn flp+=\\\|^\\*\\s* textwidth=80 colorcolumn=+1:
|
|
-->
|
|
|