Did you ever want to check licenses of third-party dependencies in your Go project? Me neither. However, if you want to do something like that, I made a simple tool written in Go - glice. By running it in your Go project, it gets project’s dependencies (with a possibility of recursive dependencies), then for third-party ones gets the license from GitHub API.
For quite long I wanted to start working on OSS projects, for many reasons. Learning to code better by getting feedback from others and working on large projects, giving back to the community, and last but not least promoting myself a bit.
My previous company wasn’t very supportive of this. Even though we had over 50 developers, none had any activity on GitHub - one of the reasons I left. I moved to another company, 1500 ft away, and switched from Java to Go(lang). Perhaps another time I can write about Java->Go feelings, even though lots of stories were told on that topic already.
I was working on RESTful backend in Java, and technically I still do it with Go, so it felt natural to write an OSS project that covers that. I started a few months ago, but the project is quite big and I feel it’ll take a couple more months before I feel good about open sourcing it.
Three weeks ago a redditor posted on /r/golang how he made a license checker for Go projects - in Powershell. It felt strange, and lots of commenters said that it would be good if he had written it in Go.
So I gave myself a task - rewrite the PowerShell script in Go. Sounds fun! And it was.
It took me about five nights working 2-3 hours each night from starting the first line to publishing on GitHub. During the first night I’ve written most of the functionality, but in an odd way without pointers, to the code was way too long. The next working night was refactoring, removing large chunks of code while keeping the functionality the same.
I started being happy about what I made, I saw the end result and it felt good. Then I added GitHub integration and some additional functionality.
Last two nights were spent mostly on writing tests, or to be more precise learning how to write them. I’m still unhappy with how they look, but they did help me implement an additional functionality (the -i flag) and fix one bug. At the end, I went through Travis’s and Coverall’s documentation to set-up CI and automated testing.
Besides learning a lot, what I’m eagerly waiting for is pull requests containing suggestions (quality improvements) on how to improve the code I’ve written, with comments from other experienced developers. I feel that’s the best way I could learn how to be better - code reviews on things I’ve written myself, not just small chunks of code.
I feel the tool might be used in some cases, so at the end, it’s not completely useless. Glice is available on GitHub, licensed under MIT license.