Modern Auto Layout is the most up-to-date book about the Auto Layout system from Apple. It does not assume any previous knowledge on laying out your UI for your Mac or iOS apps. It also covers both Interface Builder and programmatic ways to lay out your UI.

Hands down, it is the best book I’ve found which covers all modern practices such as how to use scroll views with Auto Layout, how to use stack views, dynamic type, and more. Of course, coming from the author of Use Your Loaf who has written numerous blog posts about the subject, it is not a surprise that the subject is covered well. Even common bugs are discussed as well as workarounds.

I think even advanced users of Auto Layout may learn at least one or two things, but it is heartily recommended. I wish I had this book when I was starting to use Auto Layout.

Hugo has an asset pipeline feature which can basically get an asset resource file, manipulate it (e.g. compress it, concatenate it, etc.), and then generate a final output file. I imagine most people use it for CSS and JavaScript where they minify the source, fingerprint the resource (e.g. calculate the SHA sum of the contents) and then publish the generated file. (Embedding a hash of a file into a resource’s URL works great for caching since you can add the appropriate headers and ask the browser to cache that effectively unique URL forever. When your resource changes, the resource URL will change because the generated hash in the file will be different.)

In order to make things fast, Hugo caches aggressively. So if it sees that the contents of your file has changed, it will re-build the asset. Unfortunately, my issue was that I had an asset (say asset S which is an SVG file) which included a link to another generated resource. In short, it depended on the generation of another asset (say asset C which is a CSS file). Hugo would not recognize the dependency. So if I made changes to the CSS in asset C, Hugo would re-build asset C but not my SVG asset S with the new link to C. If I made changes to asset S, it would then update with the latest link to asset C.

It was somewhat annoying but understandable why this issue exists. The solution I settled on was varying the final output path of asset S based on the final output path of asset C. By varying the output path, a newly generated asset S would be created if C were to change.

Here’s the sample code with an image SVG (e.g asset S) linking to a CSS stylesheet and the template code which was building the SVG. The custom.scss is just a random stylesheet.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">
<?xml-stylesheet type="text/css" href="{{ .style_link }}" ?>
<svg version="1.1" xmlns="" xmlns:xlink="">
<!-- ... -->
{{- $style := resources.Get "custom.scss" | resources.ToCSS | resources.Fingerprint -}}
{{- $linkSVG := resources.Get "image.svg" | resources.ExecuteAsTemplate (printf "image-%s.svg" (index (split (path.Base $style.Permalink) ".") 1)) (dict "page" . "style_link" $style.Permalink) | resources.Fingerprint -}}

{{ $linkSVG.Permalink }}

The final SVG output file would take the fingerprint from the generated CSS file and use the CSS fingerprint in its own filename. Not exactly the prettiest solution (it effectively becomes image-<css fingerprint>.<svg fingerprint>.svg which is a long filename), but it’s a way to force the pipeline to re-generate assets with hidden dependencies.

The Go Programming Language is the premier Go book. It is similar in purpose to The C Programming Language which I consider one of the few must-read books for any programmer.

The Go Programming Language covers the core language very well, dives into more advanced language features, gives an overview of how your code fits into the world with packages and tooling and finally showcases some rarely used language features.

The core language consists of discussions about types (int, runes/characters, etc.), control flow, scopes, arrays, slices, and maps.

Next, I would consider advanced features to be Go’s approach to interfaces and object-oriented programming along with the chapters about channels and concurrency. These middle chapters were perhaps the most interesting with practical advice on how and when to use the language features.

Giving an overview of packages and the go tooling, it really shows how you can consume and produce production code. Go 1.11’s module system has made some of the text outdated, but some of the advice is probably under-appreciated at first glance like how to benchmark and profile code using the Go tools.

Finally, the book does a brief into to reflection and how to interact with C code. While a bit lighter (and the authors admittedly believe that these features are not commonly used in most Go code), I have started appreciating any language’s ability to interact with C code. Reflection has also been useful when I was programming in Java, and I imagine whenever you have to write a marshaller/encoder for a custom format, it will be just as useful.

While someone without programming experience can pick up this book, several of the concepts such as concurency, closures, and object oriented programming are only briefly discussed before diving into the application of those concepts with Go. Several chapters felt like they needed prior programming experience with a different programming language to appreciate what the authors were illustrating with their examples and explanations.

A Tour of Go gives most programmers enough to start programming in Go. However, this book goes further in explaining what is idiomatic Go code. For example, it gives an explanation on Go’s philiosophy on error handling, explains why Go does not have a set type, and discusses why the testing package is so sparse without assertions compared to other languages’ testing libraries. Whether or not you agree with the design decisions, having those explanations in mind will lead to more idiomatic Go code.

My suggestion for anyone looking to pick up Go is to work through A Tour of Go, write or port a few simple programs from another language to Go, and then read The Go Programming Language. You may discover several tips (like how to create internal packages, why there is a doc.go file in packages, why slices are not comparable, and embedded/anonymous struct fields). Go does make it “easy to build simple, reliable, and efficient software”, but there are still conventions, inconsistencies, and fairly uncommon language features which are well explained in The Go Programming Language.