Using Service Connections in Azure DevOps
I was recently setting up a build pipeline in Azure DevOps and realised I didn’t have access to the Azure resources to be able to pick the app service as a deployment target.
The easy way would be to get my account access to the Azure resources, but:
Some time ago, just after the first post on this blog, I started using Hugo Shortcodes.
The theme I was (still am) using didn’t have great support for some of the markdown stylings that I wanted, and instead of fiddling with that, I figured I’d create my own with custom styles and Hugo Shortcodes.
I recently came across a scenario where I had several components with the same structure in them, so I figured I’d extract it out into it’s own component.
Simple right? Everyday scenario?
Were it so easy…
Service workers are the new hotness when it comes to web applications.
They allow a website to have some offline behaviours similar to that of an app, including an “installable” desktop experience.
In essence, they’re a small app that browsers can interpret and run, caching info and queueing requests, enabling offline access and data-saving.
A colleague mentioned they weren’t aware of Logpoints in Visual Studio, so here’s some things that aren’t on or known about by default (usually because they’re experimental or stylistic)
Some that I’ve found useful:
Managing node versions can become painful when switching between projects.
There’s a mechanism to check node versions during an
npm install called Engines, but that doesn’t help if the projects are installed already.
The fix is to install node as a dependency. Who would have thought?
Dotnetcore 3 has been out for a little while now, and there were some changes I wanted in the project I was working on, so off I went and gave it a burl.
Needless to say, there were some issues, but in fairness, some of it was our fault.