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.
For https://github.com-based projects, I most often just fetch
upstream/masterand branch from
FETCH_HEADto create topic branches, but occasionally I like to keep my local and
origin/masterbranches up to date:
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.
subscribe via RSS