My Unconventional use of Github, the making of a totally offline but collaboratory App
Yes you read it right, it is totally offline and collaboratory as well!
The title may sound weird, though very true and possible, and in the next couple of paragraphs I’ll be sharing with you guys the HOWs and the WHYs of both my unconventional of use of github as well as how I was able to succeed in developing the said application.
I am faced with a problem whereby a client wants an application that can be used with or without internet connectivity. I am very sure if you are following the current trends in the technologies landscape, some things like PWA’s Service Workers, Database replication etc, must have popped into your mind and said:
“What’s so special about this then?
While acknowledging the fact that all of the technologies mentioned above, if used appropriately, are capable of providing the user with a rich of both offline and online experiences, I’ll like to categorically state that my own case is different. Let me refine the requirements more so that you can see it in a clearer perspective.
For simplicity purpose, let me summarize the requirements in the list below:
1. Develop an application that will automate the financial record keeping system of a company
2. The app should be a desktop application and should be installed for all the employees in the company’s accounting department as well as those in the managerial dept.
3. The App should be used with or without internet connectivity
4. Each of the App should have its own local database but has to synchronize with a remote centralize database
…and other requirements that may be unrelated to the purpose of this write up.
It’s obvious from the requirements that Progressive Web App (or PWA in short) is completely relegated from the candidate technologies. But one thing you might have still thought of, especially if you are a Java guy, is Database Replication.
Database replication is the frequent electronic copying of data from a database in one computer or server to a database in another so that all users share the same level of information –Tech target
From the definition above, Database replication may sound like a perfect candidate technology for this project, but it wasn’t. Because, apart from being very hard to set up and integrate, database replication has some inherent problems that has to do with difficulty in concurrency and slow update process among others. Implementing database replication in the technology I wanted to use, .NET to be specific, is not a simple task; coupled with the fact that hosting an Access database is close to impossible task. So I had to devise another means that could best suit the requirements and the constraints.
One very afternoon, after spending lots of my time researching about this problem, while pushing a github commit to a project that I was working on, in collaboration with other developers, an idea just popped into my mind and it says “what of if you can use github to achieve the same effect in your other project?
I instantly developed a hypothesis that says “Github can be used to achieve database replication as long as the Application points to a local directory that exposes the database” and the next is to prove it.
To prove my hypothesis, I firstly did some little modification to the software which involved changing the connection string to point to another directory and placed the db in there. I recompiled the softwae and it works perfectly. Next is to prove it from the github’s end. I created a repository, but a private one indeed, bearing the name of the folder which I supplied in my connection string and then cloned the repo. I cloned, added the database file into the repo, commit the change and then pushed it to the master branch. Next is to test the app again.
I opened the software, made some entries of data and log out of it. When I opened the repo, in a git bash, boom! it tracked the changes and I successfully committed and pushed it to the remote repo! But I still thought it was too early to celebrate, I decided to further prove the workability of my unconventional approach by installing the software as well as cloning the repo in other computers.
I deployed the software in a couple of computers and installed git software in each of them and cloned the repo as well. I couldn’t believe it that the hypothesis is proven, beyond a reasonable doubt, to be working at least for my own problem.
But my work is not over as I had to deploy the project for the client’s computers. The difficulty here was telling the users what gihub is and how to use it. Hell! I just didn’t know where to start coz you can’t tell a non-developer that he has to learn git commands for him to use the software (that would be ’good’ as not developing the solution). But thanks to Github Desktop for saving my time(though they have no 32-bit version, as at the time of this write up). I just had to explain to them that after making some entries they should click on commit and then push. And when they want an update from others, they should click on fetch origin and then pull! PeRiOd!
Conclusion:
Though this project might not be a very complex and tedious one, where scalability might be an issue, I think it’s something unusual, though worthy of note and sharing as well. I’ve really learnt a lot while undertaking it. And my main takeaway is thus:
Technologies are meant to be a tools for solving problems, but how people use them shouldn’t restrict us from thinking outside the box on the kind of problems we can use them to solve.
If you think that there is a better way, and may be even more easier one, that you think I should have used to solve this problem, please feel free to share with us in the comment section, and don’t forget to clap and follow if you think I’m making sense :)
