This is the story of a tool, released as open source.
Open source is something we use every day, even though giving nothing or just a few in return. I had already contributed with money. I helped individual developers, donated to Mozilla, Wikipedia and add-on creators. I even bought swags to help oh-my-zsh and more. I even paid
US$80 for the great Sublime Text, a proprietary text editor in which people accept a pop up once in a while for the free version.
You probably know the philosophy and all the benefits of open source, so I’ll skip more of this. In this post, I want to focus on how chatting with a friend on a Friday evening, inspired by Linux philosophy of small tools and our love for Go, we created something interesting.
I’d finished writing Ruby code and decided to explore a bit deeper Go’s tooling and how to improve the workflow of my tests. I wanted faster feedbacks, but after exploring docs and more docs, I noticed Go had nothing similar. Back then, in 2014, when I was working with Ruby (I’m back with Ruby!), I used Guard to receive constant feedback of passing and breaking tests. Wow, why not in Go?!
Before I got into analysis paralysis I called my friend Victor to tell him about this idea. He was just starting with Go and could give an unbiased feedback of how he felt writing tests. He liked the proposal, so I decided to try. I wrote a very minimal idea of how it should work. We chatted over Telegram to discuss a usable tool we could develop, with as few as possible code. You might call it a “MVP”. A few interactions and the following list emerged:
- It should be focused on Go developers - It should monitor *.go files - It should be simple - It should belong to the community
Small is better, so we embraced our initial philosophy of Linux small tools and stuck with it. We relied on Go’s file, filepath and os packages. Initially, anything beyond that we judged as a waste of time. At this point, the tool didn’t have a name. It wasn’t the right time to worry about it. Commit by commit we learned how this tool could help us. The first interaction was nothing but background notifications.
How it works
As we made the tool stable, before pushing to GitHub, we found a name:
Given a certain path, snitch watches Go files. If you don’t pass the path param, it assumes the current directory. Defaults are great! Particularly, snitch came to me by helping with TDD. You can write your tests or save my Go files and it tells you the current state of successes and failures.
As a good snitch person, it tells the good and bad news! The name sounds good and people on Reddit said it was the best name for a tool like that!
Snitch was born in the ecosystem. It was created for Go developers by Go developers. I won’t praise Go again :P
This was that project that, with a few LOC, gave us a very interesting in return. With the help of GitHub, people interact,
love star the project, fork it and open pull requests. It’s beyond the code. To make it work, I have a few advices:
- Start small - Don't be so ambitious - Iterate and improve - Don't be afraid of criticism - Write down your ideas - Use "what if..." to play with new ideas - Ask for honest feedback and go grab a coffee
The current state
I believe snitch has reached a stable state with interesting features. We love beautiful code, but there’s always room for improvements. The most recent PR added a colorized terminal output. I loved it and it was easy to write with the help of color package. I must say that Go enabled us to write clear and legible code very fast!
The repo has no more than 310 LOCs today, including tests:
find . -name '*.go' | xargs wc -l 61 ./platform/notifier.go 52 ./parser/result_test.go 20 ./parser/result.go 177 ./main.go 310 total
I’d like to thank people on Telegram, GitHub and Victor for the code and support!
Thanks for reading!