I added a few new pages to the Guides section:
The Docker Compose guide goes over how to use the docker-compose commands and explains the configuration in the docker-compose.yml file.
On the documentation front, it feels like inception - I'm using documentation to write documentation around how to generate documentation!
I've used Hugo in the past, but I decided to give Docusaurus a shot and it's been a pretty good process so far. I'm haven't spent much time with React but the project is pretty easy to use. It's great you can build sidebars referencing pages and when you load that page, it will load the sidebar with it. Their documentation is a little limited but I easily fall back to plain HTML to get the layouts working the way I want.
When I first wrote the code and tests in note.go and note_test.go, I wanted to see if I could get to 100% code coverage. It's a good exercise if you've never done it before to see what you have to do to get there. It requires a lot more effort than it's worth for most applications, but still a good exercise. View commit.
In Go, table driven tests is very common. You can read able them here. It helps cut down on all the boilerplate code you have to repeat everywhere.
It's also helpful if you have a setup and teardown process that is run with each of your tests. Since that code was copy and pasted in many different places, considated they to easy to use functions. View commit.
Code samples below.
It's hard to argue that Cypress doesn't make an engineer's life easier. I originally wrote tests for Jest, but after seeing a bunch of vulnerabilities pop up in the packages that it's using, I decided it was a good time to switch to Cypress so I could access the wonderful GUI that's available. View commit.
I'll admit, I'm not a JavaScript developer, but Cypress does make it more fun to write tests because you can see your progress live. A video is below.
I finally figured out how to get ESLint to work properly with Visual Studio Code (VSCode). View commit.
It was quite a challenge getting ESLint to work properly when the .eslintrc.js file is not in the root of the project - the trick was the "eslint.workingDirectories" setting. All the settings are included in the .vscode/settings.json file. I use VSCode open only to the root of the project with no other projects. I also recommend the following VSCode extensions:
I did a little deep dive learning today on npm modules. There were some vulnerabilities and dependencies that were in the wrong places in the package.json file. View commit.
I added some notes to the README.md file on how to interact with the package manager and Nuxt.js. The code is also below:
I really want to use Go modules but it seems the community ("⚠️ These tools do not provide a good support for Go modules yet.") is not quite ready for them yet. Visual Studio Code is one of my favorite tools by the Microsoft team. It's a really great editor with a great open-source community behind it. I've enjoyed playing with the latest and greatest tech, but the older I get, the more I want my tools to just work reliably. I stopped testing the iOS betas because I didn't like restarting my phone every time I hopped in the car to get music to start playing.
I need my IDE to allow me to be as productive as possible so I'm switching back to vendoring depdendencies using gvt until modules is better supported by popular tools. We've used gvt on large teams for years so even though it's deprecated, it still works extremely well for our purposes. View commit.
Instead of keeping all the frequently used commands in a text file that team members have to copy and paste, I added a Makefile to simply a lot of the work. This should help streamline the process for all the engineers on your team so each person can run the same commands quickly instead of hunting for that text file they created a while ago. View commit.
Every project needs a good CI/CD solution - now we've got a Travis-CI integration. View commit. Travis will help us check our code when we commit it to ensure all of our unit tests and end to end tests are still passing. It will also generate Swagger spec to make sure it's valid from our annotations.
If you haven't already, check out all the work Martin Fowler has on his website - he shares a lot of great concepts and methodologies on development and testing. A good read is The Practical Test Pyramid by Ham Vocke that talks about one approach to testing.
Let's improve those HTTP handlers! In 2018, I released code that forces an HTTP status code and an error to be returned by all of the handlers so it's very clear what happens in each of the code paths. View commit.
There is a new bind package (thanks to the go-playground) that handles mapping data from a request to a struct and also validates it. View commit.
No one likes to write an API spec by hand so I added in Swagger annotations which allows us to use Swagger Codegen tool to generate a Swagger spec from it!