I’m torn between extracting auth credentials in the handler from a Go Context and passing them as arguments to service methods, or just passing the context and having the service methods get it from the Context themselves.

Previously, when the auth credentials just had a user ID, we were doing the former. But we’re now using more information about what the user has access to and if we were to continue doing this, we’ll need to pass more parameters through to the service layer. Not only does this make things a little less neater, it’ll mean the next time we do this, we’ll have to do the whole thing again.

But, it means that the service methods would need to get the user IDs themselves, along with this new stuff. Not that that’s an issue: there will be providers that are also using the context to get this info. So this is a viable option. And yet, I feel uneasy about using the context for this. 

🦆: So what are your options?

L: I guess I could replace the use of the user ID with a structure that holds both the user ID and this extra stuff.

🦆: Would that work?

L: I mean, I guess it would? It would make it clearer as to who’s request this. It would also mean that we’re being explicit about what the method needs.

🦆: Do you see any downsides with this approach?

L: The only thing I can see is that it would be inconsistent with other parts of the system that are getting it from the context.

🦆: Your hesitating. You don’t seem sure about this.

L: Well, I just don’t like the fact that we’re passing both the context which holds this auth info and the auth info alongside it. And I know that it’s unclear, and would mean that the tests would need to be changed (I mean they’ll need to be changed anyway if we went with this “principal” approach). 

🦆: So what’s really going on? Why are you unsure about this?

L: Well, it’s just showing this in a review and having people say “oh, that’s not the right way to write Go.”

🦆: They say that?

L: We’ll, not exactly. But they do have opinions about how best to do this (like pretty much everyone, I guess).

🦆: Do they have an opinion about this decision?

L: Well, not really. In fact, I think they’re pretty okay with either approach.

🦆: So if they’re okay with either approach, it probably doesn’t matter that much. But if it were me, I’d probably prefer something a little more readable.

L: Well, yeah. But how can I trust you? You’re me.

🦆: Am I? I’m a duck. Are you a duck?

L: No, I’m not. But you’re not a duck either. You don’t exist. You’re just a figment of my imagination.

🦆: Really? Then how are you speaking to me?

L: Because I conjured you up so I can work through this problem I’m having.

🦆: So you’re having a go at me because I don’t exist, yet you still need me because you’re stuck on this decision and you need a resolution.

L: Well, I didn’t say I don’t need you. It’s probably still helpful to me to have this conversation. 

🦆: Ok, I think we’ve gone off track a little. What are you going to do about this context decision?

…

🦆: Well?

L: Ok, I’m not certain that implicitly including the user ID will work, as the user ID may be different to what is actually in the context. I also don’t like how it’s implicit in the context, and I think I do prefer something a little more readable. It pains me to think that I’ll be effectively duplicating values that are already available to the method. But we’re doing that anyway with the user ID.

So here’s what I’ll do. I’ll replace it with a dedicated type, retrievable from the context and holding all the information that is needed to authorise the user. I’ll also retroactively make those changes to other areas of the code that are doing it.

🦆: Okay. And what of your peers?

L: If they ask about it, I’ll just tell them that I prefer something a little more explicit. I know it’s a departure from how I did things previously. But the benefits outweigh the costs I think in this case.

🦆: Okay. Sounds like you’ve got a way forward now.

L: Great. This has been helpful. Thanks for that, D.

🦆: No worries. 

I’ve been having occasional trouble with the debugger in Goland. Every attempt to debug a test would just fail with the following error:

/usr/local/go/bin/go tool test2json -t /Applications/GoLand.app/…
API server listening at: 127.0.0.1:60732
could not launch process: EOF

Debugger finished with the exit code 1

My previous attempts at fixing this — upgrading Go and Goland — did get it working for a while, but recently it’s been happening to me again. And being at the most recent version of Go and Goland, that avenue was not available to me.

So I set about looking for other ways to fix this. Poking around the web netted this support post, which suggested upgrading the Xcode Command Line tools:

$ sudo rm -rf /Library/Developer/CommandLineTools
$ xcode-select --install

I ran the command and the tools did upgrade successfully, but I was still encountering the problem. I then wondered if Goland used Delve for debugging, and if that actually need upgrading. I’ve got Delve via Homebrew, so I went about upgrading that:

$ brew upgrade dlv

And indeed, Homebrew did upgrade Delve from 1.21.0 to 1.22.0. And once that finished, and after restarting Goland¹, I was able to use the debugger again.

So, if you’re encountering this error yourself, try upgrading one or more of these tools:

• Goland
• Go
• Xcode Command Line tools (if on a Mac)
• Delve

This was the order I tried them in, but you might be lucky by trying Delve first. YMMV

If anyone else is weary about posting about what projects they’re working on, fearing that others would think they’re showing off or something, here’s two bits of evidence that I hope would allay these fears:

Exhibit 1: I’m a bit of a fan of the GMTK YouTube channel. Lots of good videos there about game development that, despite not being a game developer myself, I find facinating. But the playlist I enjoy the most is the one where Mark Brown, the series creator, actually goes through the process of building a game himself. Now, you’re not going to learn how to use Unity from that series (although he does have a video about that), but it’s fun seeing him making design decisions, showing off prototypes, overcoming challenges — both external and self imposed, and seeing it all come together. I’m aways excited when he drops one of these videos, and when I learnt today that he’s been posting dev logs on his Discord, so interested am I in this topic that I immediately signed up as a Patreon supporter.

Exhibit 2: I’ve been writing about my own projects on a new Scribbles blog. This was completely for myself, as a bit of an archive of previous work that would be difficult or impossible to revisit later. I had no expectations of anyone else finding these interesting. Yet, earlier this week, while at lunch, the conversation I was having with work colleagues turned to personal projects. He ask if I was working on anything, and when I told him about this blog, he expressed interest. I gave him the link and that afternoon I saw him taking a look (I not expecting him to be a regular visitor but the fact that he was interested at all was something).

It turns out that my colleague gets a kick out of seeing others do projects like this on the side. I guess, in retrospect, that this shouldn’t be a surprise to me, seeing that I get the same thrill. Heck, that’s why I’ve subscribed to the tech podcasts like Under the Radar: I haven’t written an iOS app in my life, yet it’s just fun listing to dev stories like this.

Yet, when it comes to something that I’m working on, for a long time I’ve always held back, thinking that talking about it is a form of showing off. I like to think I’m getting better here, but much like the Resistance, that feeling is still there. Wispering doubt in my ear. Asking who would be interested in these raw, unfinished, things that will never go beyond the four walls of the machine from whence then came? I don’t think that feeling will ever go away, but in case I loose my nerve again, I hope to return to the events of this week, just to remind myself that, yeah, people are interested in these stories. I can put money on that assurance. After all, I just did.

So don’t be afraid to publish those blog posts, podcasts, or videos on what you’re working on. I can’t wait to see them.

See also, this post by Aaron Francis that touches on the same topic (via The ReadME Project).