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 -> Adof (do not forget to give it a ⭐)

🎉 Adof v1.0.0 - Release! 🎉

This is the first stable version of the Automatic Dotfile Organizer Friend, designed to help you easily manage, track, and share your dotfiles across systems. With this release, you can seamlessly backup, restore, and synchronize your configuration files while keeping everything version-controlled with Git.

🚀 What's New in v1.0.0?

• Core Commands: We’ve launched several powerful commands to help you organize your dotfiles:

  • init: Automatically identifies and backups configuration files in a .adof/ directory, stages them for Git and commits the changes.
  • add: Lets you manually add files to be tracked, with fuzzy search support using fzf.
  • remove: Removes unwanted files from tracking and commits the changes.
  • link: Links your local dotfiles repository to a remote GitHub repository and generates a README.md file with usage instructions.
  • unlink: Removes the connection between your local and remote repositories.
  • push: Pushes changes from your local .adof/ to the linked remote repository.
  • update: Syncs changes from your dotfiles to your system and commits them.
  • deploy: Easily copy dotfiles from any remote GitHub repository to your local machine.
  • log: View detailed commit history and changes made to your dotfiles.
  • list: Lists all files being tracked by adof.
  • uninstall: Completely removes adof from your system.

• Enhanced Commit Messages: Automatic commit messages provide detailed information about file changes, including filenames, line numbers, and timestamps, making it easier to track the evolution of your dotfiles.

• README Generation: Automatically generates a README.md file for your dotfiles repository with instructions on how to use the configurations, perfect for sharing your dotfiles with others.

🛠 Key Features:

• File Backup & Version Control: Track, backup, and restore dotfiles in a safe and version-controlled manner using Git.
• Error Handling: Detailed error messages to help you troubleshoot issues quickly.
• Multi-repo Support: Link your local configuration to a remote GitHub repository and keep it updated.

📝 Future Plans:

• Auto-update: Periodic synchronization of your dotfiles across systems without manual intervention.
• Encryption Support: Secure your sensitive configuration files with encryption.
• Profile Management: Manage multiple profiles for different environments (e.g., work, personal, etc.).
• Cloud Optimization: Improve performance for cloud environments.

---

My Personal Exprience

As you already have the overall idea of what I have built. Let's talk about how I got the idea, how I built it, what problems I faced and how I overcame it.

How I Got the Idea?

In a single line, The idea came randomly. It's not a new or unique idea but I came up with the idea suddenly and iterated over it for a few days to finalize its features.

But the main motivation came from YouTube tech influencers, I found that lots of people ask for dotfiles and theme config in the comment section and the influencer made a GitHub repo, and users just copy them to their local system, then the idea hit my mind, why not make a tool that only takes the GitHub repo link and copies the config file to their respective places. Then the Adof was born.

Most of the features came to mind while building it.

My main focus was to make this tool as simple as possible so that no one had to read the docs to use it.

As I always say, "Make everything stupidly simple."

I crafted the commit messages in such a way that if you just look at the commit message you can easily tell, which file changed and how many lines were added or removed with day, time and date.

Here is a sample commit message;

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.