No Clocks

What is a PowerShell profile?A PowerShell profile is a script that runs when PowerShell starts. It's a great way to customize the shell to your liking and to add functionality that doesn't exist out of the box.

The PromptThe first thing I wanted to change was the prompt. The default prompt is a bit boring and doesn't provide much information. I wanted to add some colour and some useful information.I've done this using a third-party module called Oh-My-Posh. This module provides a number of themes and allows you to customize the prompt to your liking. I've chosen the Material theme.

The prompt now shows the current directory, the git branch, and the time.

GitHub IntegrationI use two machines for my day-to-day work. My laptop, and my desktop. I wanted to be able to easily sync my PowerShell profile between the two machines. In order to achieve this, I have included a setup script in the repository. This script will create a symbolic link to the profile in the repository, and place it in the correct location. This allows me to make changes to the profile on either machine and have those changes reflected on the other machine.Within the profile, there is a function that runs each time the profile is loaded. This checks to see if the local git repository is up to date with the remote repository. If it's not, a friendly message is displayed to remind me to pull the latest changes (another function included in the profile).

Support For All Session TypesThe two main interactions I have with PowerShell are through the Windows Terminal and Visual Studio Code. I wanted to ensure that the profile worked in both of these environments.The first hurdle was the font. The material Oh-My-Posh theme requires a font that supports Powerline characters. I chose the Caskaydia Cove Nerd Font. This is not installed by default on Windows, so there is logic in the setup script that installs the font and sets it as the default font in the Windows Terminal.If you look at most documentation for customizing the PowerShell profile, you'll see that it's recommended to use the $PROFILE environment variable. This is a variable that is set by PowerShell and points to the location of the current user's profile script. This works great for the Windows Terminal, but not for Visual Studio Code.

In order to support both environments for a consistent experience, a slightly different (not well-documented) approach is required. You need to use the $PROFILE.CurrentUserAllHosts variable. This variable points to the location of the profile, regardless of the host. This means that the profile will be loaded in both the Windows Terminal, Visual Studio Code, and anywhere else you might use PowerShell on the local machine.

Linux-like AliasesBecause I'm constantly switching between bash and PowerShell, I often get confused about which commands are (and aren't) already aliased. For example, ls is aliased to Get-ChildItem, but there is no equivalent for touch.I've added a number of custom functions to mimic (as closely as possible) the behaviour of their Linux counterparts. For example, grep is now an alias for my custom Find-String function, and df is an alias for the built-in Get-Volume command.My favourite addition is su, which is an alias for Start-AdminSession. This opens a new elevated Windows Terminal window.

function Start-AdminSession { <# .SYNOPSIS Starts a new PowerShell session with elevated rights. Alias: su #> Start-Process wt -Verb runAs }

Secret ManagementWhen writing scripts, it's often necessary to store secrets. These could be passwords, API keys, or other sensitive information. In the past, I've haphazardly stored these in plain text variables. This is obviously not ideal, but it was the easiest way to get the job done.In order to create the lowest barrier to entry, I've created a function called Get-OrCreateSecret. This is a semi-interactive function that will prompt for a secret if it doesn't already exist. Now I only need one line in my scripts to get a secret.

Using the SecretManagement & SecretStore modules, the secret is encrypted and stored in a local vault. This means that the secret is only accessible to the user that created it, on the machine that it was created on. Much better than storing it in plain text!

Further ImprovementsYou'll notice that the repository name is not "PowerShell Profile" and is instead "Windots". Windots is a short form for Windows dotfiles. Dotfiles are a Linux convention for storing configuration files. Though this is not commonplace on Windows, I intend to hack together more centralised configurations for my Windows environments. Hopefully easing the pain of switching between and setting up machines.

Get-ChildItem -Path c:\tempabc

Function ExtractIcon { Param ( [Parameter(Mandatory=$true)] [string]$folder ) [System.Reflection.Assembly]::LoadWithPartialName('System.Drawing') | Out-Null md $folder -ea 0 | Out-Null dir $folder *.exe -ea 0 -rec | ForEach-Object { $baseName = [System.IO.Path]::GetFileNameWithoutExtension($_.FullName) Write-Progress "Extracting Icon" $baseName [System.Drawing.Icon]::ExtractAssociatedIcon($_.FullName).ToBitmap().Save("$folder\$BaseName.ico") } } ExtractIcon -folder "C:\Path"

A declarative statement made with the intention of guiding architectural design decisions in order to achieve one or more qualities of a system.

If we take a closer look at this definition, we find several interesting parts in this definition. "[...] intention of guiding architectural design decisions [...]" As a software architect or a team of software engineers, you have to deal with and decide on many architecture issues. But how do you decide these questions? Gut feeling? :-) That's is probably not the right approach. As we learn from the Software Architecture Canvas, there are quality goals that are drivers of architecture.

What are the basic characteristics of good architecture principles?

Comprehensible & clear

Architectural principles should be like marketing slogans.

Testable The principle should be verifiable, whether work is done according to the principle and where exceptions are made.

Atomic The principle requires no further context or knowledge to be understood. In summary, architectural principles should be written to enable teams to make decisions: they're clear, provide decision support, and are atomic.

What are the pitfalls of creating architecture principles? What do you think about the following principle 👇? "All software should be written in a scalable manner."

That's why we've adopted in a product team the following architecture principle. "Use cloud services if being lock-in to a particular cloud provider is acceptable."

Whether this vendor lock-in is acceptable depends on several criteria: The effort required to replace this managed service An acceptable lead time for providing alternatives. Let's take a look at an example technological decision we had to make in the past: We needed to evaluate a centralised identity and access management solution for our SaaS products. In addition to meeting the functional requirements, we had two powerful IAM solutions on the shortlist: Keycloak (self-hosted) Auth0 (Managed, cloud service)

Following the defined principle of "Use cloud services if being lock-in to a particular cloud provider is acceptable." we have concluded that a centralised IAM system should be self-managed and not managed by a third-party provider because it's a huge effort to replace a managed IAM product and therefore there is no reasonable lead time to deploy an alternative. In summary, vendor locking wasn't acceptable to us in this case. So this principle efficiently guides us to the right decision.

Example 2: "Prefer standard data formats over third-party and custom formats"

The next principle was about the selection of protocols for service communication. "Prefer standard data formats over third-party and custom formats"

If you have multiple services that need to communicate with each other, the question of protocol and format arises. In the protocol ecosystem there is a fairly new kid on the block: gRPC gRPC (gRPC Remote Procedure Calls) is a cross-platform, open-source, high-performance protocol for remote procedure calls. gRPC was originally developed by Google to connect a large number of microservices. So in our team, the question is: RESTful HTTP vs. gRPC?

The selection of a protocol thus depends heavily on the quality and change scenarios of the services involved. But if you can meet the quality goals and underlying requirements with both options, like RESTful HTTP vs. gRPC, then consider yourself lucky to have such a principle. This principle helped us choose RESTful HTTP over gRPC because RESTful HTTP is a widely accepted standard data format, while gRPC is more of a third-party format. So here this principle speeds up our decision making, which doesn't mean that we don't rely on gRPC in certain cases.

Software architecture may be changing in the way it's practiced, but it's more important than ever.