tips-and-tricks

Background I’ve mentioned VS Code dev containers on this blog before and like using them from WSL. I’m also a fan of azbrowse for working with Azure resources from the terminal, and lately have found myself running azbrowse from within a dev container for various reasons. There are several features in azbrowse that copy data to the clipboard, and when run from WSL it detects that and copies to the Windows clipboard, which is convenient. [Read More]

Background As I mentioned in my previous post, I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and found it a positive experience. At first I was a bit lazy and didn’t use passphrases on my keys, and just kept a copy of my keys in the .ssh folder in my User folder in Windows and another copy in ~/.ssh in WSL. [Read More]

Disclaimer: this post is one to file under “things I’m blogging in the hope that I find the answer more quickly next time”. Background I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and never looked back. For a while I was using SSH keys without passphrases but got round to adding passphrases a while back. I set up the Windows OpenSSH Authentication Agent - the service defaults to Disabled so I set it as Automatic start and nudged it to Running. [Read More]

If you’re working with Kubernetes then there’s a pretty good chance that you’ve been working with kubectl! There’s also a pretty good chance that you end up working with more than one cluster context. So, how do you manage multiple contexts? KUBECONFIG One way that you might have encountered is obtaining a kubeconfig file that contains the details of how to connect to a cluster. kubectl allows you to pass a --kubeconfig option to commands to specify which kubeconfig should be used to connect to a cluster to execute the command. [Read More]

Following the git theme for mini-posts, I thought I’d give git rebase a mention this time. When I first started working with git I found a way to pretend that it was a source control system like any other that I’d used. Eventually, I was working on a pull request for an OSS project and a maintainer asked me to rebase my changes. Now, I’d heard of rebase at that point but I hadn’t used it, so I was a bit daunted. [Read More]

My last post seemed to go down quite well, so I’m going to try a few mini-posts with a ‘tips-and-tricks’ theme. This works well for me as I’d started making some notes about productivity tips I use as part of my prep for an internal no-prep presentation ;-) This one is a really small tip that is covered in the Visual Studio Code docs, but lots of people using Visual Studio Code seem to have missed it so I’m going to mention it here: you can set Visual Studio Code to be your git editor. [Read More]

I like working at the terminal. No judgement if you don’t, but for me the terminal feels like a comfortable and productive place :-) I also like to find ways to gradually improve my experience with the termina, and a while back I mentioned to Lawrence that I’d created some git aliases to help me easily check out pull requests on github. He immediately replied pointing me to github.com/ldez/prm (Pull Request Manager) which is an awesome tool for checking out pull requests locally and working with them. [Read More]