first_page

studio status report: 2021-04

month 04 of 2021 was about prepping a Core Release and ripping the guts out of Songhay.Player

The SonghayCore version 5.1.0 release is almost complete. According to me, this release is mainly about addressing System.Text.Json support but there are other major improvements such as:

  • the return of ConfigurationManagerExtensions
  • moving Songhay.Publications discoveries down to the Core
  • modernizing certain patterns (e.g. using nameof with ArgumentNullException statements)

Last month strongly suggested that I would be working on Publications, specifically the LiteDB stuff. The herding cats bit 🐈 about software developers is a 🐈🐈 real thing! Instead, I have been stuck under the b-roll repo, Songhay.Player, experiencing revelations:

  • most YouTube index Activities is about querying JSON files
  • dependencies on the file-system and Songhay.Cloud* libraries should be removed/reduced and replaced by scripting
  • async Activities can work from the console with an async main method [docs]

These revelations slightly overwhelm me with new (or previously shelved) investigations:

The use of the Azure Storage REST API instead of my previous Songhay.Cloud* work. I see the REST API as cleaner and simpler than me taking the time to understand how Microsoft deprecated WindowsAzure.Storage and replaced it with Azure.Storage.Blobs [GitHub] based on the assumption that this will never happen again.

The possible use of JMESPath. JMESPath looks to be better than a LINQ-based approach to projecting from JSON. JmesPath.Net with System.Text.Json might be an immutable (functional-style), higher-performance replacement for the editing features in Newtonsoft.Json. Additionally, the entire az CLI uses the --query argument to implement JMESPath.

.NET 5 came to Azure Functions last month but…

A .NET 5 function app runs in an isolated worker process. Instead of building a .NET library loaded by our host, you build a .NET console app that references a worker SDK. This brings immediate benefits: you have full control over the application’s startup and the dependencies it consumes. The new programming model also adds support for custom middleware which has been a frequently requested feature.

While this isolated model for .NET brings the above benefits, it’s worth noting ==there are some features you may have utilized in previous versions that aren’t yet supported.== While the .NET isolated model supports most Azure Functions triggers and bindings, Durable Functions and rich types support are currently unavailable. Take a blob trigger for example, you are limited to passing blob content using data types that are supported in the out-of-process language worker model, which today are string, byte[], and POCO. You can still use Azure SDK types like CloudBlockBlob, but you’ll need to instantiate the SDK in your function process.

Anthony Chu

sketching out a development schedule (revision 16)

The schedule of the month:

  • rebuild Songhay.Player Activities with zero dependencies on the file-system and Songhay.Cloud* libraries
  • incorporate LiteDB [🐙🐈 GitHub] into Songhay.Publications.KinteSpace
  • build Web components required for new version of SonghaySystem.com 🖼
  • upgrade songhay-ng-workspace to Angular latest 📦↑
  • complete project associated with new version of SonghaySystem.com ✅
  • use @songhay/index as a side-car app for “Day Path” and “the rasx() context” 🚛📦
  • add proposed content Web component
  • use the learnings from existing npm packages to build @songhay/player-audio-??? 📦✨
  • modernize the kinté hits page into a progressive web app 💄✨
  • convert Day Path Blog and SonghaySystem.com to HTTPs by default 🔐
  • use the learnings of previous work to upgrade and re-release the kinté space 🚀

https://github.com/BryanWilhite/