I’ve now wrapped up my development on HostBlocker, a command line utility to manage my /etc/hosts file, and the project was very instructive. Particularly on things that I used to take for granted. There are nuances on how to do things in C that are not present in other languages, and those nuances will make themselves known even in a project like this.
With development completed on a “1.0” release, I decided that writing up a postmortem on the project is something I’d like to do, so here it is.
What I’ve Learned
C File I/O might seem simple at a first glance, but it really is complicated. I kept overwriting the file and had no idea why, looking through the code there was no reason for it to be happening, until I happened upon this line:
fopen(myFile, "w+")
This line happened to be opening my file for read/write, but overwriting everything in my file.
once I had changed the file mode to r+, things cleared up and the file stopped getting completely
overwritten.
What I Would Like to Improve
I think that to improve the project I’d like to add testing somehow, but I am unsure of how unit testing or testing in general is really done in C projects. Testing needs to happen for all of my File I/O functions but these functions naturally have a dependency on the operating system. Maybe I would build an abstraction for a file that could accept reads/writes/updates which would be instrumental to testing.
Also, I would like to improve the config file structure of the project. Currently the file is just a newline-separated list of hosts to block. If you add a host to the file, it will get picked up on the next wakeup and added to the /etc/hosts file. I would like the file to include a time range somehow, so that hosts are only added to the hosts file during specific times of the day. This would allow me to build out time periods (such as when I’m working), that I need to block certain sites.
Finally, I would like to improve the efficiency of my file modification operations. I feel as though I should have some data structure that builds up a host file “Diff” much like git, that applies the diff all at once versus iterating the file for each possible change. I am not sure what data structure I could use to build a diff or a patch, but I bet I could find some useful information in documentation for git itself? I’ll have to look into it.
What I’ll Work On Next
If I had a clear slate of projects, I would probably start on some embedded project. I do not have a clean slate though. My goal is to check projects off of my to-do list that I started an never finished, and the next such project is my Ally Invest API Wrapper.
I began the API wrapper to build my skills in Go and to not have to manually manage my investment portfolio. The work is not glamorous, but I do feel like it has something to teach me. So far I’ve left off with building data structures and parsing code to handle XML responses from the Ally API, and the tedium caused me to quit once. I will not quit again, reaching parity with the API documentation Ally has online. I would love to have this be my first true open source project, and I would love to not have to manually manage my portfolio anymore, and both are achievable goals with a little bit of discipline.
My Plan for the Future
I am disappointed with my lack of drive on my goal of writing code that runs in space, so I’m making a promise to myself to renew that goal and go full steam ahead into 2020 working on robotics and embedded software. On the way I will of course have projects that span all areas of software engineering as a whole, but I will try to have at least 2 projects this year that include some kind of robotics.