This post is 50% a build log, 10% thoughts on vanity, and 40% about dev ops/project structure/CI/CD/etc. Everything should be easily navigable from the headings below. If you want to get in touch, find me on Mastodon, write me an email, or follow me on Github (My vanity will appreciate it!).

Introduction

 Everybody is a little vain. Vanity frequently spurs people to action where other, more pure, motives fail.  There's an interesting relationship between vanity and perfectionism. Perfectionism is often driven by vanity, the wish to be perceived as being a master in whatever actions you are currently undertaking. This is clearly an impossible task, but striving towards an impossible ideal can often lead to successful results along the way.

 Recognizing that perfectionist tendencies could have a different root cause than you previously thought leads to a different perspective on them. For me, perfectionist tendencies have been counterproductive to my desire for acknowledgement and recognition in the things I (at least think!) am knowledgeable about. However, you need to be visible in order to be recognized, so perfectionism really gets in the way. If my perfectionist tendencies were allowed to run free, I would rarely, if ever, release anything. The concept of "Building in Public" has been a great perspective for me in this regard, even though almost all it ever leads to is me writing half-baked blog posts and creating things like my most recent project - git-vain.

Buildlog

 Gitvain is a simple Python project that sends you a notification whenever the follower/stargazers on a Github change. It supports notifications using Apprise which is a fantastic tool that allows you to specify some simple configuration and then send notifications using many, many services. PyGithub is used to fetch changes on the watched repositories. There are many outstanding issues, that will most likely never be completed. This is by design, however, as I set out a plan to get to a point where I could be satisfied enough to leave it alone, say I sufficiently completed it, and thereby prevent my perfectionism from getting in the way.

 A major part of my recent work in software development has focused around best practices and ops-adjacent work. Recognizing that setting up CI/CD at the start of a project is very easy compared to getting it set up midway through, and that actually defining the feature you want to work on and writing short functions with no side-effects to get it done makes you progress quickly. Being realistic with the scope of what you're working on allows you to keep motivation and leave your work in a state that's trivial to restart whenever you next get the chance. To achieve this, I simply started by writing out a minimum set of features I wanted to have before being happy to cut a v1.0.0. I then broke these features down into small components and added them to Vikunja my favorite todo list application.

 I started by getting a basic Python project set up with continuous deployment using Github Actions to build a Dockerfile that would deploy to my home server. This is so simple that it literally just prints a Hello World statement in the Dockerfile! Even though this seems insignificant, from here you have the perfect jumping off point; a stable point you can solidly build on.

 After this, I prioritised one type of event I wanted to be notified on - stargazers - and wrote a basic script to star/unstar a repo, and another to use ntfy to send a notification when this list changed. Already it was starting to take shape enough to keep my motivation going.

 Once this was complete, I used the simple Python stdlib shelve to add some persistence, and integrated with Apprise to support a wider variety of channels for notification.

 There's no point in going into any further detail, because A) it's not very interesting, and B) it didn't progress much further! But this is a feature, not a bug - I set out with the intention of cutting a v1.0.0 and this was almost there already!

 But what next?

Next Steps

 I realised I had a few things I wanted to add as I was going through the development process. This is typical, and it's the source of all feature creep. I curtailed this by putting anything I wanted to do into Vikunja, and deciding to convert them to issues once v1.0.0 had been completed. If I didn't, I would certainly still be adding little bits and pieces here and there now as opposed to enjoying the feeling of having "finished" a piece of work. Even if it only lasts as long as it takes to go back to working on v2.0.0!

 Some things I want to improve in v2.0.0 or in the next side project I work on are as follows:

• Use pre-commit to add more stability and standardisation to the work
  • This feels particularly powerful and would be a good way to finally upgrade my development process which still consists of a pretty vanilla vim setup. Who knows? Maybe I'll even switch to NeoVim with this new-fangled LSP!
• There are some bugs such as not accounting for pagination of the response from Github.
  • I deliberately didn't try to address these during this effort as I could easily have gotten bogged down in it and it's a small, contained piece of work that should be easy to add in the future if I leave the project and come back to it after a period of time.
• SemVer and Conventional Commits seem to be a fantastic way to completely automate the release cycle.
  • If there's no Github Action for it, it shouldn't be too difficult to make either as I didn't find a suitable service for my needs so far - next project maybe??
• Python has a good few issues when it comes to naming conventions and project setup.
  • This is potentially exacerbated by the fact that the tooling I'm familiar with is outdated by now.
    • Using setup.py works nicely (especially if you have experience with it) for a small project like this, but it's not a good idea for more serious work.
  • The naming conventions I was having issues with surrounded small things like - vs _ vs camelCase. Package names vs module names vs binary names. Small things, that actually ended up adding some annoying decision fatigue and cognitive load to keep consistent.

Conclusion

 The Python standards and conventions are a bit of a mess. Dev Ops/best practices actually do provide great help when used in conjunction with common sense, and the "perfect" project template likely cannot exist due to the subtle variations in what "perfect" looks like for different purposes.

 Nonetheless, that's what my vanity is currently driving me towards finding, so for now, I'll keep looking.

  Hopefully not in vain!