Rust🦀 is my first programming language, and here is my experience of writing my first OSS in Rust in 1979 loc.

Before sharing anything let's quickly see what I have made.

Project Overview

GitHub repo link ->

And I automate the git add and git commit commands so that you do not have to do the tedious task.

Also, I masked the git push command to adof push so that you can push the changes anywhere on your file dir in your terminal.

Then, with the readme feature, I tried to help the influencers just push the file to GitHub and the readme is autogenerated with instructions on how to get all the config files to their own system.

I hope you got the idea, I was only trying to make the tool frictionless as much as I could.

My Learnings

The best thing about building this tool is that I am now able to read any crate docs and quickly build with those crates.

This means, that before it I always found it hard to read the docs and build things with a crate, I also thought that I must read the crate's whole docs and learn how it works then I can able to use it.

But Adof helped me to read the docs a little bit at first, get the overall idea of what the crate does then start building with it and refer back to docs whenever you need to.

In this project, I used a lot of crates like

• git2 - to manage git task


• request - to do an HTTP request


• tokio - for async works


• web-browser - to open a URL in the browser


• URL - to work with URLs


• chrono - to work with time


• glob - to query file system


• other crates

But I took lots of help from Google, StackOverflow, Rust Forum and Reddit.

I was shocked while working with git2, most of the terms I never heard of. I thought just knowing the branching, merging and tagging is all about git but while working with git2 I quickly realised how dumb I am in my git knowledge. (takeaway - Going to read the "Git Pro" book soon.)

The second best learning is Vim/NeoVim.

Yes, I learned NeoVim.

Before that, I used VSCode but took the risk of switching to NeoVim. I never used Vim/NeoVim before or never built a project from scratch by myself.

It was so much exciting and also so painful.

No file tree, no auto suggestions, no error indentation nothing, just place terminal with a theme.

But it was worth it, it helped me or forced me to read the docs otherwise, if I used VSCode, the built-in function get indented to no need to look around the docs.

My Mistakes

First and foremost mistake was not handling errors from the start.

While I was building, I only focused on the features building and did not care about error handling, I thought after all features were completed I would do error handling.

But after completion, when I started working on error handling it was exponentially complex and I restructured my whole project which took me around 2 days.

So, afterwards, whenever I build my next project, I sure handle errors form the start.

My second mistake was to waste time on over-engineering.

This means I wasted much time building a feature that nobody going to use that much.

For example, I tried to build daily branching and merging features so that your commit history will remain small and easy to find correct commits.

Let me explain.

My tool does when there are changes, and you run the adof update command, it fetches the changes stages them and commits them.

But imagine, if you change your configs 10-20 times a day then your commit history going to contain lots of commits and it gets quick long commit history.

To solve that, I thought to implement a daily branching strategy, which means every day if there is a new commit then it creates a new branch and commits the changes to the new branch and the next day if there are new commits then it squash merge the previous branch into main with all the changes in a single commit and create a new branch and push the new commits to the newly created branch.

So, your main branch only gets one commit regardless of how many times you change your configs.

I hope you got the idea.

Then spent around 2-3 days learning about git branching, merging and how to do them in Rust using git2 but it feels really hard.

But somehow I was able to get 70% of it, which means whenever a new commit is there, it checks for old branches then merges them into the main creates a new branch and adds the new commit on top of it.

But the problem was, that I was not able to do the squash merge means the previous branch got merged into the main but the main got all the commits instead of containing only one commit.

But what is the point of this, I planned this feature to avoid the the long commit history but ended up making the main commit history long.

Then I realised something, I only configure my environment once and again when something goes wrong, likewise, most people just configure their env and forget about it, no need to implement this feature.

To back this thought, I did some research on GitHub, searched dotfiles in GitHub opened the top repo checked how often they committed to the repo, and then saw most of the repos had 4-5 commits in a month.

Then I realised, I was doing over-engineering which never going to be used by the users, and again I wasted around 2-3 days.

So the takeaway is, always do some research that "Are the users going to use it or not?" before building any additional feature for your tool/app.

Now, let's talk about some silly mistakes I made.

One mistake I made over and over again was type. As I was using NeoVim, it does not highlight the errors on the IDE when you run it you get the error.

But function or variable names were inferred by the compiler but when I type the file name as those are in the doubt quote("), the compiler never catches those bugs then I had to figure out why it is not working while the logic is right.

Most of the time file names are put me in trouble.

What's next?

I started this project on 31 Oct, it took me around 14 days to build it but learnt a lot.

So, if it took up means more people are going to use it then I will continue to deliver more features fix bugs and resolve issues if not then I am going to work on my next project.

Conclusion

I hope you find something helpful from my experiences. Also, do not forget to try my tool and give me some feedback and suggestions to improve it.

Have a great day.