With the Go 1.16 release the Go team added a new way to embed files and folders into Go application binaries. This is a great feature as it facilitates a practice that is common in the community and much likely loved by many gophers: shipping a single binary with embedded assets. In my case it even makes me wonder if there is a need to use Docker to deliver our Go binaries, but that’s another topic.

On a previous post I wrote about Go’s time locations and how to put those in an alpine Docker container. This was achieved by copying the timezone data zip file from the docker builder image into the distributable image. Then using an environment variable to point Go to the location of that file.

Over the years, Android developers have been doing networking with the use of some APIs from the Android SDK and other tools which always involved a lot of work. The use of Retrofit became the standard when we are talking about consuming APIs. This means having an additional layer on top of Java and the logic of our app. With the introduction of Kotlin a few years ago and with their native support for asynchronous operations with Coroutines, developers were provided with tools easier to use.

We may have come across the need of having to create multiple records in a single operation. Now, this can be achieved through a single insert command of course, but the more records we require to persist the longer it’ll take for this entire operation to complete. Let’s set up a basic example to go over this topic. We will be creating a list of contacts in bulk using the database/sql library in Go.

In Go, a build tag is an indicator that is added to a piece of our code, to indicate when a package will be included in the building process. This gives us the possibility to compile different versions or parts of our application from Go, switch between them in a fast and organized way, and all from the same source code.By using the build tags we can work on integration tests in development teams, which allows us to test the updates of our code without the need to make modifications to the already tested sections of it.

You might have read an article I wrote before on how to run your buffalo container on CloudRun, however a lot has changed in CloudRun since I wrote that article and I noticed that I missed important details that will be needed to run your application there. In this article I will cover how to run your buffalo application in CloudRun (GA now). Overview of the Application I think is important to describe a bit of the app we’re deploying in order to understand what we’re trying to accomplish.

Martin Fowler in his book defines refactoring as “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”. This book contains a long list of refactorings techniques that mean to be applied under certain scenarios and with the intention to eliminate “code smells”. Refactorings are a very extense topic and I’ve found them to have an important role in the software development process.

My team has faced an issue with timezones repeated times: Apparently, default Locations were not present in our production deployments of our apps, that took us by surprise given locally these were present and working nicely 🤔. This is an issue I’ve faced before. Every time I wanted to show dates in a certain timezone but such timezone was not present in our production environment, Our app ended up in GMT for everything, or we had to create our own locations.

One common Javascript flaw I see in repositories I get in touch with is the usage of both yarn.lock and npm-lock.json. This is not on purpose, in most cases is due to the lack of communication on the tooling the repo uses or different points of view on the best tooling for the problem at hand. In this short post, I’m not going to focus on communication strategies for the codebase, nor in which one is better between YARN and NPM.