Sometimes you can't help but call a function that might panic. Rather than letting it blow up your code, we learn how to use a deferred function and named return variables in order to capture the result as a standard Go error.

In over a decade of driving, moving, and everything in between I have never needed a heavy duty truck like a Ford F-350, so clearly they aren’t useful and Ford should stop making them, right? Oh construction workers might complain, but they could just use dump trucks to haul their heavy loads. And farmers might have issues, but they have tractors which could suffice. So what is the big deal? Let’s stop making those trucks!

Caddy's licensing change makes it problematic for many bootstrapped projects. Learn to build Caddy from source which is still open source with no EULA.

Learn how to properly secure cookies from tampering, theft, XSS, CSRF, and more in Go.

In Java, it is pretty common to see libraries that use method chaining (aka the builder pattern) to construct resources. For example, we might construct a user by doing something like: User user = new User.Builder() .name("Michael Scott") .email("michael@dundermifflin.com") .role("manager") .nickname("Best Boss") .build(); Builders are handy for a variety of reasons, but in the example above we are using a builder in order to define a subset of our User attributes before constructing the user object.

One of the most common change requests I get with my Web Development course is to stop using GORM, and instead use the database/sql package that is part of Go’s standard library. When I receive feedback like this I often respond asking, “Why?” Why do they feel the database/sql package would be better suited for their education? Why do they feel ORMs will be problematic long term? I don’t ask these questions to be snarky or because I don’t care; I ask because I truly want to understand a problem before I look for solutions, and oftentimes people will tell you their problem is X, when in reality X is only a symptom of a deeper problem.