How I write HTTP services in #golang has changed over the years... here's my current style.

(Please consider sharing this with somebody you know who's learning Go.)

It's a yarn... 🧶

1/13 I make a server type that holds the dependencies.

2/13

I agree with @ScribblingOn

It's time to get rid of estimates in software engineering. They don't work, do more harm than good, and drive people to act in dishonest ways.

Buckle up people, it's a thread. "How long is this going to take?" feels like a completely reasonable question, but how come "I don't know" isn't a
reasonable answer?

"We just need a ballpark figure, you won't be held to it," they lie.

Well how come we just had to work the weekend?

I always call into a run function from main in #golang passing in any system dependencies as arguments.

If I am going to parse flags, use arguments, and write to stdout, my run func looks like this:

func run(args []string, stdout io.Writer) error

pace.dev/blog/2020/02/1…

1/6 This means I can write normal Go tests that can call the run function, and there's no global state to mess around with.

func Test(t *testing.T) {
args := []string{"tool", "--debug=true", "./testdata"}
var stdout bytes.Buffer
err := run(args, stdout)
//...

2/6

A bit more context on how we organise our #golang services at Pace.

https://twitter.com/pacedotdev/status/1305122410090426370

Oto has a very simple definition format:

type Service interface {
Method(Request) Response
}

Which turns into:

func (s *Service) Method(context.Context, Request) (*Response, error) {
// todo: implementation
}

This is the best PR I've ever opened. Someone has a PDF of my book in their GitHub repo. UPDATE: the PR got merged 😂🥳

To celebrate I am going to BUY five copies of my own book (Go Programming Blueprints: Second Edition) for anyone who wants, it but can’t get it themselves.

Reply if interested and I’ll abuse a Go map to randomly pick five winners.

#golang tip

You can use documented consts for simple values (like bools) to make code much easier to read and understand AT A GLANCE.

I wouldn't do this _all_ the time, but when I notice code is tricky to read, I do it.

Example follows... 1/4 Consider this:

Greet("Mat", true)

I'd have to look up the method signature to figure out what that 'true' was for.

2/4