There are times when all you need is a bit of hand crafted HTML. A home page. An about page. Maybe one to list your favorite brownie recipe.
And then there are times when you thought all you needed was a brochure site, and a few months later you realize that every few days you’re adding another page, which involves annoying things like copy/pasting the same header and footer everywhere, and fiddling with navigation.
If you already know how to use Hugo, and you’ve never used GitHub Pages before, and you just want to figure out how to get everything wired up and deployed with the least amount of fuss necessary, then a lot of the blog posts and tutorials you’ll find are going to be a bit frustrating.
Some tutorials will explain the GitHub Pages part in detail, but will make assumptions about how you’re generating your site, which won’t necessarily match what Hugo does.
If you’re practically illiterate when it comes to colors and graphics (as I am), and you need to create a presentation that is not going to make the audience cringe, then there’s a yak that is begging to be shaved.
The process might go something like this:
Step 1: Generate a pleasing color palette using something like Coolers.
Step 2: Pick a font that isn’t embarrassing.
Step 3: Find the right graphics.
You start out with just the right number of parentheses: the bare minimum. Well, as few as you can get away with, without having to worry about remembering operator precedence. (Does || bind more tightly than &&?)
Then edge cases happen. You wrestle with logic, try out variations, and parentheses accrete.
Bugfix 1, simplicity 0.
This leaves you trying to spot the actual logical expressions amidst all the spurious parentheses.
If you travel a lot (or if you live in the boondocks, like I do), then you’ll probably find yourself in a situation where you need to browse the documentation for the packages in the Go standard library, but the internet connection is terrible or just plain non-existent.
To get around this, run a godoc server locally on an available port. I’ve often seen people use 6060 or 4040.
godoc -http=":6060" This gives you access to all the installed packages at localhost:6060/pkg: the Go standard library, as well as any other packages you may have installed.
Writing code in a new language can sometimes make you feel like an introvert at a party where you don’t know anyone, in a country where you’re not sure about the customs.
For the most part you’re not going to insult anyone too badly, and you’ll probably have a reasonably good time, even if occasionally people will think that you’re quaint or a bit daft or have kind of bad manners.
It’s quite possible to run golint without complaint and end up with documentation that is mediocre and unhelpful.
Part of the problem is that programmers coming to Go from other languages have a lot of baggage.
If you took Java classes in college, there’s a chance that you’ve been taught to document all your inputs and outputs for every public method. The comments end up being oh-so machine-readable, and oh-so tedious to parse with your eyes.
Sometimes you wonder if the program is mocking you.
> all goroutines are asleep
Asleep. That sounds wonderful. Instead, here you are wondering whether deadlock would make a good bandname, and if you have any ketchup and mayonnaise left so you can make goopy red ramen noodles. Oh, yeah. And wondering why your app is hanging.
Perhaps all you need is a good night’s sleep and a decent meal, and you’ll find the unclosed channel or the WaitGroup that is missing a call to Done(), or whatever it is this time that has you perplexed and frustrated.
You can wish for a proper JSON array all you like, it’s not going to turn your file full of JSON objects into valid JSON. It’s not that each bit of JSON isn’t valid, it totally is. It’s just that you’ve got hundreds of these JSON objects that were all dumped into the same file.
If you’re new to Go, you might find yourself hunting through the io and ioutil packages for a way to read a file full of JSON objects and turn them into Go structs, but these packages will only get you partway there.
Many people are scared of pointers when they first get started in Go, especially if they’re coming to Go from dynamic languages that don’t expose the concept. Even after they’ve gotten a good grasp on what pointers are and how they work, many new gophers feel a bit anxious about when they should be defining a method on a value rather than a pointer.
The Go team has given a good set of guidelines in their FAQ, listing three basic considerations.