Blogs

Okay, part 3! At this point, I’m assuming that you have already familiarised yourself with part 1 and part 2 of the series. As a quick recap, part 1 focused on why we would consider using GPG Keys in general. Part 2 focused on how to generate GPG keys along with some recommended practices on splitting out our master (Certification) key, from our specific purpose-driven keys. This post (part 3) focuses on using those keys as part of our usual development workflow using Git. We’ll be assuming that GitHub is our end target, as GitHub supports commit signature verification using GPG Keys.

Hopefully by now you’ve had a chance to read part 1 of this series, which explains why you may be interested in using GPG keys to sign your commits. Congratulations on getting to the second part! In part two, we’re going to focus on how I worked through setting up GPG in my Windows environment, and generating a set of keys for use. There were some challenges/hurdles along the way, and we’ll talk through those too!

For a while now, I’ve been using GPG Keys to sign my Git Commits to prove that my commits on GitHub are genuine and from me. Over the last few weeks, I’ve been inspired by a couple of colleagues (Kudos to Adrian and Julie if you’re reading this) to dig out my YubiKey and use these for my key signing activities. While there are several blog posts on the topic already, I encountered a number of roadblocks along the way. The intent of this blog post is to be the first of a series, where we’ll explore what GPG is, why it may be valuable to you and how you can get going using them. We’ll then take this forwards an additional step, and show how you can use YubiKeys as a second factor of verification and the benefits of this approach. By no means am I the world’s expert in cryptography, and some of these topics, but I wanted to document my own understanding for posterity, as I’ll inevitably need to repeat/review the process in the future. I hope that this may be useful to you.

For the past four years, I’ve been part of a team at Microsoft called FastTrack for Azure. FastTrack for Azure is part of Azure Engineering’s Customer Experience Team, focused on successfully on boarding customers on a project-by-project basis as they bring production workloads online. There is never a perfect time to say goodbye, but for me - now is the time. From Monday, I’ll be taking on a new role within Microsoft as a Senior Cloud Solution Architect within Microsoft UK’s Customer Success Unit, focusing on the Manufacturing & Resources Industries. Career changes can be big moments of change, and a good opportunity to reflect.

I’ve talked in the past about my Open Source journey, and some of the contributions that I have made in the community. In my current role, I’ve been leading on the global strategy for my team’s DevOps practice, defining the areas of focus and initiatives that may be beneficial for the team. In this post, I’m going to talk through one of these initiatives, and how you can contribute towards the Azure GitHub Actions experience!

A few people have recently been asking about my setup, so I figured it may be a good time to start writing about it! This is the second part of the series, where I’ll focus on the Lights, Recording Equipment and my overall setup. If you’re interested in the PC setup, then take a look at my previous blog post!

A few people have recently been asking about my setup, so I figured it may be a good time to start writing about it! I’ll break this into a few posts to keep it digestible. The first part will be focused on the main powerhouse behind it all - My PC!

When I mention the term JAMStack, I’m not pretending that I’m Paddington bear with a stack of Jam sandwiches! If you hadn’t heard, JAMStack is a term that describes applications based on JavaScript, APIs and Markup. That means, we’re referring to files that are content in nature. Think about files like HTML, CSS, Images, etc. Ok, now with that context - why has it risen in popularity? Surely this is something that could have been done for many years, so why now? My hypothesis… Cloud.

Contributing to Open Source Software. It sounds so formal, doesn’t it? I thought that for quite a long time, and it put a bit of a mental barrier in place for me to begin my journey. I am a classic over thinker, but that’s perhaps another blog in its own right! Contributing to Open Source isn’t as scary as it may first initially seem. Let’s start with a few thoughts.

During the 2020 Festive Break, I had a lot of time on my hands. I took 4 weeks of my Annual Leave, which meant I had the majority of December to personal time. Personal time / time off is great, but I also wanted to push myself and catch up on some pieces that were on my personal learning or achievement list for some time. I started refreshing my knowledge around Rails (having developed in it some years ago, it’s progressed quite a bit!), NodeJS, GoLang and Rust. All interesting to learn, and I’m sure I’ll be continuing on my journey with these throughout 2021. But that’s not the point in this blog post. One of the activities that I kicked off was contributing into the Hugo Community. Read on to find out more.