1Password allows developers to sign git commits using SSH by setting up their own SSH agent. Doing this in your host platform e.g., Windows, is relatively straight forward but if you want to set this up in Windows Subsystem for Linux (WSL) there is additional configuration you need to perform.
As a terminal junky, many years ago I customized my PowerShell
$profileto define a custom
function:prompt. This included custom parsing for any
.hgfor Mecurial!), and eventually any
.gitfile to support worktrees and submodules. It was fast and, last I knew, still powered some internal environments we use at work.
While I haven’t yet left Twitter, I’ve joined many in the #TwitterMigration to Mastodon or, more specifically, Fosstodon. While I appreciate it’s a federated network of nodes - much like IRC of old - I am slightly disappointed I either deleted or let lapse my old mastodon.social account I opened many years ago when it first started going public. Being on that instance is like a badge of honor, but a pointless digital badge, so 🤷♂️.
If you’re new to Mastodon (rather, the Fediverse) or want to learn about it, see https://joinmastodon.org/.
Some repos can be huge, like Azure/azure-sdk-for-net (at the time this was written) due to a number of factors, like history, old binaries, or other large files. A repo could also have a relatively small history but a huge amount of files that take a very long time to check out. You can both reduce the time it takes to fetch such a repo and how long it takes to check out files.
Sometime ago I blogged about
git sync, an alias I created to concisely pull the upstream repo’s main branch, push that branch to my origin fork, and fetch origin branches to determine which branches have been deleted - likely from merged pull requests. As many repos I work in have changed from
main, not all of them have yet. Some also use
trunkwhich, personally, I like better but is less common than
One of the great aspects of working for a large global company like Microsoft is working with a lot of diverse people. Working across time zones has its difficulties, though. I know that India is about 12 hours ahead of us, but with different observed timezone offsets it’s difficult to remember exactly. For a recent project I started working on, I also work with a lot of people in or around Cairo, Egypt.
Some recent tests failures for the Azure Key Vault Certificates client libraries for .NET required debugging on Linux, and while I frequently use WSL2 (even to write this post), I needed a fresh Ubuntu 18.04 image similar to our live testing agents. Fortunately, recent versions of Visual Studio 2019 have included the component “.NET Core Debugging with WSL 2”.
I was helping a colleague the other day after they merged the
masterbranch into their older topic branch, which brought along a lot of other commits and made the pull request on GitHub huge - too many files to even review in full on GitHub or in Visual Studio Code. I commented that instead, rebasing onto
master(or whatever branch you want to merge) is cleaner. First, however, you have to get back to a good state.
While I use PowerShell on a daily basis, the Azure CLI has better support for Azure management and some data operations. It also runs faster on WSL2, since python.exe startup on Windows could use some performance work.
WSL2 has been amazing! It’s so much faster than WSL, and Git commands and Python scripts just run faster. But what really gets me giddy is Docker on WSL2. No Hyper-V VM - in fact, Hyper-V doesn’t even need to be installed. I loved Hyper-V, but with Docker and WSL2 I haven’t had much reason to run it. It’s just works…well, usually.
Globally-unique identifiers (GUIDs) are often the brunt of jokes. Windows Installer packages (.msi files) are full of them, from the required ProductCode, to highly-recommended UpgradeCode, package codes, and required component GUIDs. Authoring an MSI doesn’t require you create and manage so many GUIDs, however. In fact, Windows Installer XML (WiX) has in the last few years made great strides in making sure you don’t have to, and recommends you don’t.
Late in 2019 I start working with a colleague on a common pattern of creating test resources using ARM templates. A script deploys the template using a common set of variables and outputs both common variables and any custom variables that tests for a service needs. The Azure Cognitive Search service, for example, needs both admin keys for read-write operations, and query keys for read-only operations.
As a long-time vim user (though I more commonly use Code these days), I relish the opportunity to improve my experience. I’ve been using Powerline for my bash prompt for a while and even developed a pure PowerShell variant. I wanted to integrate it into my vim profile which I maintain as a Git repo across many different machines, physical or virtual.
The new Azure SDK has a lot of new features that make it worth migrating from Microsoft.Azure.* to Azure.* packages. Logging is greatly improved and is consistent across client libraries. All clients will log request and response information automatically when AppInsights or OpenTelemetry is configured.
Rebasing commits on one topic branch onto another topic branch is a great way to stay productive while waiting for pull requests to be reviewed. Even if subsequent commits are made to the original topic branch, you can still create a subsequent PR with only intended changes.
After many years of being https://blogs.msdn.com/heaths and changing positions, it was time to set up a new blog for technical tips and trips, as well as personal adventures.
Shortly after I joined Microsoft over 15 years ago, I started blogging as a means of helping customers find workarounds for many of the problems we had with Visual Studio and .NET Framework installs. Though it had a few URLs over the years, https://blogs.msdn.com/heaths quickly became one of the most-read blogs across MSDN or TechNet blogs at Microsoft. While that felt pretty cool, the reason why it was so popular - apart from being good at SEO, so much so the KB team asked me to stop, but instead I helped them get better - was concerning.
With 20 years of experience with Windows Installer and software deployment concepts in general, I knew another approach was necessary. Years prior, I was a very active developer on WiX - especially on the improved patch build pipeline, and several features of Burn including related bundles and package dependencies. But while Burn solved several of our problems with reliability of Windows Installer, it didn’t provide the flexibility Visual Studio needed to move at break-neck speeds with new features. Windows Installer itself was also just too slow and allowed our feature teams to do things they really shouldn’t, which prevented the product from being able to install to multiple places so customers could try new features in one instance while maintaining a separate, stable instance. So, after all the cries of, “Why can’t you just xcopy Visual Studio?”, I got us almost there.
This new system was inspired by NuGet and npm - a package manager. Packages were simplified to ZIPs (more specifically, OPCs like those used by Office, NuGet, and VSIX) with a limited grammar to support was Visual Studio required (we added a few more features over the years based on need). But the biggest change was a dependency graph of features that allowed feature teams to express feature dependencies like they tried to do all those years prior through package ordering and conditions - something that was incredibly hard to get right and more often failed.
With a great lead and team, we brought this vision - and insightful ideas from other developers backed by well-curated telemetry of issues - to reality. After a few initial bumps along the road, we made an engine that was 4x faster and about 99% reliable. As a happy consequence, I had no issues to blog about. Instead, I changed the blog URL from being /heaths to /setup and we used that for a few setup-related announcements, like the .vsconfig idea I proposed and customers love.
After 15 years of setup at Microsoft and seeing my “baby” succeed (Visual Studio setup went from being a bad joke to a sometimes beloved feature on socials), I decided it was time to move on. I always felt like I was where Microsoft needed me and my experience most, but it was time to leave the future of setup in others’ hands and for me to find something new and exciting. And since I already gave up ownership of what is now /setup but still wanted to share technical tips and tricks I’ve discovered, I started this blog.
I’ll mostly stick to technical information but may occasionally post about my family’s adventures here in the gorgeous Pacific Northwest. I’ll do my best to refrain from any political discussion, as there’s enough of that on socials already (which I also usually try to avoid).
I hope you’ll find some tips and tricks that help you be more productive.
subscribe via RSS