Gandhara University did not have an Admissions Portal. We needed to digitalize their admission process. The university had been using paper-based application forms that the candidates filled by hand, payment slips along with the data entry process did not use automation. It was our job to provide a software solution to this this problem.
This study will follow a pattern of problems, followed by our solution to each of them.
Gandhara University has multiple institutes under its wings. Each of which have their own academic and non-academic programs. Although we were tasked to only provide online admission services to two of their five institutes, it was our plan from the get-go to ensure that if the university desires, they should be able to conduct all admissions through the portal we create and develop for them.
With that in mind, let us go through the hurdles as we faced them.
Current Project Status: Complete
1. Technologies that we used were not compatible with the pre-existing setup
Summary: We provided a low-cost cloud-based solution to Gandhara University instead of asking them to purchase an on-site server.
Most web developers and software houses in Pakistan exclusively work in PHP frameworks. There is absolutely nothing wrong with that but when it comes to building robust web applications as quickly and rapidly as possible, we prefer Python. The University had recently acquired a server to be used for hosting a moodle installation.
This server was more than capable of hosting our admissions portal, but the local internet services were nowhere as reliable as a cloud service provider. Additionally, it should be noted that most clients and customers do not care about what programming language you use as long as you can fix their problem.
We recommended a cloud VPS instance and brought it up the same day. This meant that costs were incredibly low and the server could be scaled up and down as needed.
2. Deadline for an MVP was only ten days!
Summary: We followed standard feature-driven development practices to ensure that we could meet deadlines.
Short deadlines seem to be our specialty now. An MVP in this instance was an admissions portal that could be accessed by applicants and hopeful candidates. Thankfully we use Django.
We started a new Django project, started a Vue.js web application and got to work. Only the public frontend needed to be delivered initially and that is exactly what we did. For registration and logins we use Django’s built in authentication system and a proprietary django app that builds on top of django-registration.
Although we stated that we followed a feature-drive development process, tests for a specific feature were written alongside the feature itself to ensure that we don’t break anything unknowingly when we undoubtedly come back to improve the application process in the future.
3. Updates and modifications needed to be provided as quickly as possible
Summary: This project was being developed and was in use simultaneously, this meant that any changes and features that are urgent need to be completed usually on the same day.
You only need two things to ensure that everything doesn’t go down the drain.
- Tests should be written every step of the way.
- Automated deployment of your new features through a CI/CD pipeline.
For the second one, we simply use Github Actions. And for the first, well, any professional software developer will write tests for a project of this scale.
4. Functionality kept changing due to Pakistan Medical Commission
Summary: Since we followed best-practices when writing our code, modifications and changes in the web application were easily completed and delivered on.
This was the first year that the Pakistan Medical Commission enforced a single, national, and computer-based test, for admissions into the medical colleges and universities of Pakistan. This test was called the MDCAT and local students as well as international students appeared in it. Unfortunately, we also had a wave of COVID-19 peaking through the educational year. Causing all sorts of anomalies and creating doubt about the admissions process this year.
Details that needed to be collected from candidates were changing on a weekly basis, and these changes needed to be implemented into the system as soon as they were communicated to us. In short, the tests paid off in the end.
5. We needed to integrate House Job applications too
Summary: We had to integrate new types of applications into the web portal. We did so by cleaning up our code first and then implementing our solution.
We knew this request would eventually come our way, so we had already split up a single application form into various modules. For example: Biological Information, Guardian Information, Academic Information, Entrance Test Information, Attachments, etc. However we were not planning on this request coming to us as quickly as it did.
We had to develop a new module that can have as many “Yes” or “No” questions as we desire and we integrated that into the portal. At this point, we also decided that academic and non-academic programs will have separate integration and application review process in the backend.
6. Applications for other academic programs had different requirements
Summary: We used our modular application system to its fullest and removed the modules that we did not require. In this case, we removed the Entrance Test module from the application process for programs that did not have them.
At this point in time, our team was creating the programs not the university itself. We had already added a boolean True/False for the house job module. And now we needed a second one.
- First boolean – is_academic – controls whether or not this programme is academic in nature
- New boolean – has_mdcat – controls whether or not this programme needs the entrance test module
Whenever you start adding true/false columns to a model, you need to draw the line at a certain point and consider if it’s good design to keep doing so or maybe it would be better to simply use choices instead. But then how do you handle a scenario where say, a program is not academic in nature but will require an entrance test?
We decided that if we ever need more variants for this project, we will instead develop a more elegant solution.
7. Technical Problems and their solutions
We will try to keep these short but due to the nature of these problems, it’s redundant to provide a non-technical explanation. We’re building an admissions portal after-all!
Django by default sends emails synchronously!
Explanation: Every time you send an email, you cannot do anything else. This is how emails work by default in django.
Detail: Since this was a rapid-development project, we had not integrated Celery and redis into our project yet. What this means for the future is that whenever we do run into tasks that need to be run in the background and don’t concern the user, we have that framework completely ready for us. We are only using the framework to send emails for now, but it can do a lot more if needed.
Browsers cache SSL certificates and throw a hissy fit like there’s no tomorrow
Explanation: Due to the implementation of the house jobs module, we wanted to use porta.gandhara.edu.pk instead of admissions.gandhara.edu.pk
Detail: Be patient and wait for the admissions process to finish up and then change it during off-peak hours.
There is no need to store the data displayed in Merit List as they consist of calculated information only visible to staff
Explanation: It is inefficient to store a merit list’s data in the database, not to mention there is no elegant method of doing so.
Detail: We opted against storing merit information in the database and instead we will be enforcing strict mechanisms to ensure that once a session is complete, no staff member can modify the status of an application.