TheGitGatsby : Basic Idea and Technical Stack Specifications
“An idea is the cornerstone of an amazing project, however useless it might sound”
After continuous full stack open source contributions and the Google Summer of Code period earlier this year, it’s safe to say that a break was intended to shake away the accompanying burnout. After the well deserved chill tenure, it’s time to get back to the ‘a-commit-a-day’ mode.
This time, it’ll be a mini project, specifically focusing on comparison of two profiles on Github itself to observe the difference between contribution patterns between the two developers, their activities and other retrievable components regarding their experience.
Inspiration
It’s October. It’s Hacktober. As simple as that.
The inspiration behind this lies in the fact that Hacktoberfest organised by Digital Ocean focuses on gamifying the current scenario of open source contributions. Their idea is simple, make a particular number of contributions (only Pull Request Merges) which are usually not more than 5 and you are one of the first 50,000 or 40,000 developer who manage to do that, you’ll receive a premium Hacktoberfest T-Shirt.
Even though the rules have changed this time out and Pull Requests which focused on tasks such as “adding your name in the given list” which, well doesn’t align with the open-source values and are pull requests for the sake of these open source swags, the jurisdiction of who gets the T-shirt still lies in the first come- first serve basis.
What if maximum deserving candidates with a potential and zeal for the community were rewarded for their contributions. My project doesn’t have the jurisdiction to judge whether the developer is good enough to receive the accolades, but can at least provide a platform for judging two developers based on their skills and contributions, this is the motto of TheGitGatsby
Planned Tech Stack
Front-end Designs
For the UI, I’ll be using the classic Bootstrap, HTML and CSS combination. Reuse as many templates as possible and I plan to follow the DRY methodology (Don’t Repeat Yourself) which happens to be a pretty useful approach in projects of huge code base.
I was introduced to these standards during my Google Summer of Code’19 period, and my mentor Areeb Jamal forced the team to work this way only. Little did we know that it actually was a blessing in disguise and not random extra workload.
For any visualization, D3.js or chart.js will be used, I am not sure which will be more compatible with the same but let’s see.
Back-end Architecture
I will be relying on Django Framework for my back end along with Github API v3 which will serve as backbone of this project. I will try and keep the user input as minimum as possible. In this case, hopefully, just two usernames.
The database to be used during the development phase will be the inbuilt sqlite file and during deployment or production phase ( probably on Heroku / GH pages) , I’ll switch to Firebase .
The following posts will be about the planned Test Driven approaches followed along with template credits, if I decide to use any and of course, the Use Case scenarios and the Wire Frames of the project, if procrastination doesn’t swallow me up.
Until next time!
