studio status report: 2022-10

month 10 of 2022 was about releasing AzureBlobStorageRestApiUtility and planning to release AzureKeyVaultRestApiUtility

The release of AzureBlobStorageRestApiUtility (see issue #149) establishes one of two Azure utilities that are fundamental to the “cloud strategy” of this Studio. Completion of issue #151 will release AzureKeyVaultRestApiUtility making the following the statement true:

This Studio uses REST APIs in the cloud for secrets and storage.

How To Access Azure Key Vault Secrets Through Rest API Using Postman” by Anupam Maiti was the breakthrough message to me and my brain 🧠 that finally showed me the way to a fundamental that should have been in place years ago. I should have been demanding a RESTful approach to storage and secrets instead of getting lost in SDKs. The Core should be as primal as possible.

what month 10 looked like

Obsidian Graph View of month 10

Month 10 highlights:

something that can run locally and in the cloud with very little modification without using containers (or WebJobs)?

My lack of interest in containers is based on the reasonable fear that containers will be a rabbit hole 🐇🕳 —and they also feel too heavy and cumbersome for a my work (no lift-and-shifty DBMS behind micro-service(s) here). Moreover, I feel that Activity DLLs should be used in the cloud in [[Azure Functions]] for both local and cloud runs—because [[Songhay Activity]] DLLs contain stateless Activities, working on one input to produce one output. The biggest obstacle in front of this is where to store/retrieve secrets 🐇🕳.

Once the secrets challenge is met, then PowerShell can loop through things (synchronously) locally, effectively testing how Azure Functions run sequentially. Finally, Azure Function Orchestrations will be the last piece to put in place, looping through for parallel runs.

Step zero, before the secrets bit, is replacing PowerShell-based Azure Storage calls with REST calls in dedicated Activities. In summary:

  1. replace PowerShell-based Azure Storage calls with REST calls in dedicated Activities (a [[Songhay Dashboard]] Activity is improvisationally on the way)
  2. add secure secrets layer to the cloud
  3. replace PowerShell-based Activity-DLL calls with calls to an Activity hosted in an Azure Function
  4. Orchestrate Activity-DLL Azure Functions

add your own tooling to the [[.NET]] CLI

How to create your own .NET CLI tools to make your life easier

The dotnet pack command will save a NuGet package to the relative path specified below:

.NET *.csproj markup

To install globally for the CLI, we use the following command, punctuated by the namespace, Weather.Cli, of the packaged app:

dotnet tool install --global --add-source ./nupkg weather.cli

“Lazy load assemblies in ASP.NET Core [[Blazor]] [[WebAssembly]]”

Blazor WebAssembly app startup performance can be improved by waiting to load app assemblies until the assemblies are required, which is called lazy loading.

[📖 docs ]

I assume the [[b-roll player]] will leverage lazy loading to switch among players.

some of my code is kind of famous this week F# weekly

sketching out a development schedule (revision 26)

The schedule of the month:

  • install Studio ‘floors’ in Songhay.Player.ProgressiveAudio and Songhay.Player.YouTube☔☔
  • add a GitHub Project for Songhay.Player.ProgressiveAudio🐝✨
  • change Songhay.Player.YouTube to support kinté space presentations 🔨 🚜✨
  • replace the Angular app in with a Bolero app 🚜🔥
  • generate Publication indices from LiteDB for Songhay.Publications.KinteSpace
  • generate a new repo with proposed name, Songhay.Modules.Bolero.Index ✨🚧 and add a GitHub Project
  • switch Studio from Material Design to Bulma 💄 ➡️ 💄✨