Then I read the Critical Analysis.

The practical observations about AI adherence, review burden, and especially the MDD parallel are solid work. Where it lost me was the historical framing. The analysis builds its central tension around whether SDD is “waterfall dressed in AI clothing.” This is built on several layers of popular misconception, and like a house of cards at a toddler’s birthday party, it doesn’t survive contact with much scrutiny.

The Page 2 Problem

The analysis states: “Waterfall (1970s): Comprehensive upfront planning, failed due to inflexibility.” Wrong.

Winston Royce’s 1970 paper, “Managing the Development of Large Software Systems,” is eleven pages long. The famous sequential diagram appears on page 2. Royce presented it as the approach that does not work. He spent the remaining nine pages describing iteration, feedback loops, and the insight that you should plan to build the system twice — aligning directly with Fred Brooks’ “plan to throw one away” from The Mythical Man-Month.

Our industry read page 2 and spent fifty years arguing about what the other nine pages said. It’s the software engineering equivalent of reading the first chapter of a murder mystery, putting the book down, and writing a five-star review about how the butler did it. Royce wrote nine more pages. Nobody read them.

“Over” Is Not “Instead Of”

The Agile Manifesto says “working software over comprehensive documentation.” The word is over, not instead of. “I prefer vanilla over chocolate” does not mean I don’t like chocolate at all. I happen to like both! I just like vanilla a little more.

The nuance evaporated immediately. Training courses simplified preferences into prohibitions. “We’re Agile, so we don’t write documentation” became acceptable to say with a straight face. The dumber versions won because they were easier to teach, easier to sell, and easier to use as an excuse for not thinking through a problem before writing code.

I held these same simplified views early in my career. The original Agile principles were considerably more thoughtful than what most of us were taught. We just didn’t bother to read those carefully, either.

The Emperor’s New Sprint

Look at how most teams practice Agile today. Two-week sprints with fixed scope. Backlog refinement that functions as requirements gathering. A daily standup that is a status report wearing a casual Friday outfit. A retrospective nobody acts on.

Strip away the vocabulary and you have a two-week waterfall cycle. We took “respond to change over following a plan” and turned it into meticulously planned two-week plans we follow to the letter.

So when the analysis asks whether specs can coexist with Agile — coexist with which Agile? The one in the meeting room already runs on specs. They’re called “acceptance criteria,” and everyone pretends that’s different.

Same Song, Different Verse

Qoheleth had something to say about new paradigms: “there is nothing new under the sun,” or in our case, “under the [spec].”

Writing specifications before building software is what we have always done. Requirements documents, functional specs, user stories — these are all specifications. The format changed. The core activity didn’t. Calling it a paradigm shift is like calling a new bread recipe a paradigm shift in wheat.

What changed is the executor. When a human reads a spec, they walk over to your desk and say “this makes no sense.” When an AI reads a spec, you get hallucinated APIs and cheerful disregard for your instructions. Those are problems with the AI, not with writing things down. Blaming the recipe because the oven is unreliable won’t help anyone bake better bread.

The more interesting axis is time scale. Classic Waterfall planned in months. Agile plans in weeks. SDD plans in hours. Same song, different verse. When your spec-to-implementation cycle is measured in minutes, the distinction between “upfront planning” and “iterative development” dissolves. The pendulum didn’t swing. We just zoomed in.

What the Analysis Gets Right

The MDD parallel is the strongest section. MDD failed because the translation from spec to code was too rigid and too opaque. LLMs offer flexibility but introduce non-determinism — like trading a car that only turns left for one that occasionally invents directions that don’t exist.

The AI adherence problems need engineering solutions, not methodology debates. Hand-wringing about whether we’ve “returned to Waterfall” distracts from fixing them.

Wrapping Up

I’m tired of these poor regurgitations of popular versions of Waterfall and Agile history. They don’t serve anyone but the marketing departments of large vendors looking to sell you the next transformation. Call me pedantic if you must, but we should continually strive to be accurate with terms. When we build arguments on a version of Waterfall from page 2 of an eleven-page paper and a version of Agile from a certification course that turned preferences into prohibitions, we’re just passing around the same wrong answers and wondering why we keep asking the same questions.

Spec-driven development is what we’ve always done, only this time with an AI reading the spec. The interesting questions are about time scale, AI reliability, and whether the tooling can mature fast enough to deliver on the promise.

Have you run into these same misconceptions on your teams? Let me know in the comments.

FSharp.Data.JsonSchema 3.0.1

FSharp.Data.JsonSchema is now three packages:

• FSharp.Data.JsonSchema.Core: Core JSON Schema representation types that relies on only FSharp.SystemTextJson. This library can be uses to parse a JSON Schema into F# types and F# types into a JSON Schema. However, it no longer has a specific target.
• FSharp.Data.JsonSchema.NJsonSchema: This is equivalent to the previous version with a dependency on NJsonSchema as the target. This should be backward compatible with previous versions of the library.
• FSharp.Data.JsonSchema.OpenApi: The new target depends on the Microsoft.OpenApi library introduced with the net9.0 framework target. This target is intended for use with generating Open API documents from ASP.NET Core applications.

In addition, several long overdue bug fixes and enhancements should now be resolved:

• Recursive Types (#15): Recursive F# types no longer cause infinite loops. Self-referential DUs, records with optional self-references, and recursion through collections all generate proper $ref: "#" schemas, and a follow-up fix in 3.0.1 resolved an NJsonSchema serialization failure where Ref("#") in nullable contexts tried to look up the root reference in the definitions dictionary instead of referencing the root schema directly
• Choice types (#22): Choice<'A,'B> through Choice<'A,…,'G> now generate clean anyOf schemas instead of the verbose internal-tag encoding
• Anonymous records: Inline object schemas, no $ref
• DU encoding styles: InternalTag, AdjacentTag, ExternalTag, and Untagged via a new unionEncoding parameter on Generator.Create
• Format annotations: Proper date-time, guid, uri, duration, date, time, and byte formats for DateTime, Guid, Uri, TimeSpan, DateOnly, TimeOnly, and byte[]

Frank 7.2.0

Frank has had a long and winding history as my favorite hobby project for trying out different approaches to encoding web applications. The computation expression approach starting in (IIRC) v5.0 has stuck. The goal is still to produce an HTTP resource-style set of builders that provides a consistent means of defining HTTP resources and the ASP.NET Core WebHost in which to run them while allowing for a lot of flexibility and extensibility. As such, I’ve added some additional libraries I’ve found useful to test out the extensibility and support the new tic-tac-toe hobby project mentioned above.

Packages

• Frank: Added Metadata field to ResourceSpec, a list of (EndpointBuilder -> unit) convention functions applied during RouteEndpointBuilder.Build(). This generic extensibility point lets companion libraries (Auth, OpenApi, etc.) attach typed endpoint metadata without requiring changes to the core Frank library. This is a binary-breaking change but source-compatible with the empty default. Also added plugBeforeRouting, plugBeforeRoutingWhen, and plugBeforeRoutingWhenNot for middleware ordering control around UseRouting().
• Frank.Analyzers: F# Analyzer (FSharp.Analyzers.SDK) that detects duplicate HTTP handler registrations within a resource block at compile time, enforcing the constraint of a single HTTP method per resource. It works in IDEs (Ionide, VS, Rider) and CLI (dotnet fsharp-analyzers) for CI/CD.
• Frank.Auth: Adds WebHostBuilder registration and resource-level authorization via ResourceBuilder extensions, including requireAuth, requireClaim, requireRole, requirePolicy using AND semantics for resources and useAuthentication, useAuthorization, authorizationPolicy for WebHostBuilder.
• Frank.OpenApi: Adds long-planned, declarative OpenAPI 3.0+ document generation, including a handler computation expression for pairing handlers with metadata (name, summary, tags, produces, accepts). F# type schemas (records, DUs, options, collections) via FSharp.Data.JsonSchema.OpenApi. useOpenApi on WebHostBuilder wires services and middleware. Includes Scalar UI to provide a web-based client for viewing and testing endpoints. Targets net9.0/net10.0.
• Frank.Datastar: Native SSE implementation similar to the StarFederation.Datastar.FSharp library. Zero-copy buffer writing via IBufferWriter, zero external NuGet dependencies, full Datastar SDK ADR compliance. Added stream-based overloads (streamPatchElements, etc.) accepting TextWriter -> Task for zero-allocation HTML rendering. No breaking API changes. Targets net8.0/net9.0/net10.0.

New Samples

• Frank.Datastar.Basic: RESTful hypermedia patterns (click-to-edit, search, bulk ops) using Frank.Datastar with F# string templates.
• Frank.Datastar.Hox: Same patterns as Basic using the Hox view engine. Demonstrates stream-based SSE overloads via Render.toStream.
• Frank.Datastar.Oxpecker: Same patterns as Basic using Oxpecker.ViewEngine.
• Frank.OpenApi.Sample: Product catalog API demonstrating the handler CE with OpenAPI metadata, mixed plain/enriched handlers, useOpenApi, and Scalar UI.

Looking Ahead

I’ll spend some time in upcoming posts exploring each of these. In the meantime, I’d love feedback on any of the updates and changes. I hope I haven’t broken anyone with changes to FSharp.Data.JsonSchema, and there is a transition package with version 3.0.0 to make it easier to switch without changing package names. I don’t have any additional plans at the moment for either of these, but please open issues if you have ideas or bug reports.

Before we continue, let me define terms as I’m using them:

• strong – proactive, decisive, quick to correct, and minimize risk of failure
• weak – passive, indecisive, leaves a gap that needs to be filled, risk of failure

When I’ve searched for these terms online, I typically see something that looks more like a contrast of “good” versus “bad” leaders, for varying definitions of “good” and “bad.” When I use “strong” and “weak,” I assume both exhibit “good” leadership qualities, for whatever definition you wish to use for “good.”

The practice I tried to develop while at Texas A&M was to identify and intentionally give space for others to step up and grow as leaders. I provided backup to minimize the impact of failure and follow-up with a retrospective to learn and grow. This was moderately successful, in large part because I had a lot of room to learn and grow myself. Thankfully, the advisors at Texas A&M were wonderful and provided the same kind of environment to grow as leaders.

I’ve found this approach continues to work well throughout my career, though I have forgotten to use it at times. I recently started exploring new (to me) programming languages and came across Gleam, a typed, functional programming language for the Erlang runtime. Erlang is known for its resilience and fault tolerance, yet it achieves this by means of a “Let it Crash” philosophy. This seems counterintuitive. Success through failure? In Programming Erlang, Joe Armstrong notes that the difference is in expecting failure, one can focus instead on planning how to identify and recover.

There is a correlation between the “Let it Crash” philosophy and growing leadership abilities. We tend to think of success as good and failure as bad, but failure is only bad if it does not translate into a learning opportunity. Successful and unsuccessful outcomes can both be positive outcomes, but they need to be planned. Planning involves identifying opportunities for each person you want to grow in leadership, assessing risk, and providing for contingencies.

You may be wondering how this is different than coaching. I see the difference in coaching is an explicitly communicated opportunity, whereas what I propose above is not explicit. You have to make room for others to identify and then pursue the opportunity on their own. Coaching should certainly be part of the process, but it falls into the “strong” leadership category.

Leaving room for others is challenging. It means waiting on making improvements. You may get only a partial solution. However, your people will struggle to make it to the next step without opportunities. I’ve enjoyed reflecting on and rediscovering this approach. I’d love to know how others approach leadership development in their people. Let me know in the comments.

Undaunted, I decided to try a different approach. While looking for OSS Swift compilers, I happened upon RemObjects Elements Compiler. I was surprised I had not heard of them before. Their compiler platform is worth investigating, as it supports many languages, even within one project! However, I was interested in Swift, and their Silver compiler is kept very close to the latest Swift spec, including extensions for things like async/await. As the Elements compiler can be used to build apps for mobile, .NET, Java, WebAssembly, and more platforms, I wondered whether I could use Silver to build a Swift Azure Function against the .NET libraries. With a little help from Marc Hoffman, the answer is a resounding YES!

In this post, we’ll build an Azure Function that uses the dotnet runtime with the Swift language. We’ll follow the quickstart example from the docs, which you can find here.

Creating the Project

In order to generate a dotnet Azure Function with RemObjects, we’ll need to modify the project file. Since a dotnet Azure Function is just a class library, the best way to start is to generate a new Class Library (.NET Standard) project in either Water or Visual Studio (on Windows; Fire if on a Mac). You can download the Elements Compiler and IDE for your environment here.

This will generate a new .elements project file with something like the following contents:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <PropertyGroup>
    <ProductVersion>3.5</ProductVersion>
    <RootNamespace>silverfunc</RootNamespace>
    <ProjectGuid>{796792DD-F4C0-484D-9DA7-98D793F081B6}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AssemblyName>silverfunc</AssemblyName>
    <Configuration Condition="'$(Configuration)' == ''">Release</Configuration>
    <TargetFramework>.NETStandard</TargetFramework>
    <Mode>Echoes</Mode>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
    <Optimize>False</Optimize>
    <OutputPath>.\Bin\Debug</OutputPath>
    <DefineConstants>DEBUG;TRACE;</DefineConstants>
    <GeneratePDB>True</GeneratePDB>
    <GenerateMDB>True</GenerateMDB>
    <EnableAsserts>True</EnableAsserts>
    <CpuType>anycpu</CpuType>
    <EnableUnmanagedDebugging>False</EnableUnmanagedDebugging>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <OutputPath>.\Bin\Release</OutputPath>
    <CpuType>anycpu</CpuType>
    <EnableUnmanagedDebugging>False</EnableUnmanagedDebugging>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="Swift">
      <Private>True</Private>
    </Reference>
    <Reference Include="Echoes">
      <Private>True</Private>
    </Reference>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Class1.swift" />
    <Compile Include="Properties\AssemblyInfo.swift" />
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
    </EmbeddedResource>
    <Compile Include="Properties\Resources.Designer.swift" />
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
    </None>
    <Compile Include="Properties\Settings.Designer.swift" />
  </ItemGroup>
  <Import Project="$(MSBuildExtensionsPath)\RemObjects Software\Elements\RemObjects.Elements.targets" />
</Project>

We’ll need to edit multiple parts of this file. If you are working in Water, you need to open the file in a different editor, as Water doesn’t seem to allow you to edit the .elements file directly. I’m not sure about Fire.

Also, while the file looks a lot like an MSBuild file, it’s actually an EBuild file. You can read up more on EBuild here.

First things first, we need to replace the contents of the top PropertyGroup and remove the remaining PropertyGroup sections.

  <PropertyGroup>
    <TargetFramework>.NETCore3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <RootNamespace>silverfunc</RootNamespace>
    <Mode>Echoes</Mode>
    <ProjectGuid>{796792DD-F4C0-484D-9DA7-98D793F081B6}</ProjectGuid>
    <OutputType>Library</OutputType>
    <OutputPath>.\bin\output</OutputPath>
  </PropertyGroup>

To be fair, we don’t need to set the OutputPath to bin/output, but that’s the norm for dotnet Azure Functions projects, so I did it here for consistency. We are essentially changing the TargetFramework, adding the AzureFunctionsVersion element, and removing a bunch of stuff that isn’t necessary.

Next, we need to clean up the ItemGroup elements. We only need one, so you can remove the </ItemGroup><ItemGroup> in the middle unless you just like separate sections for references and files.

  <ItemGroup>
    <NuGetReference Include="Microsoft.NET.Sdk.Functions:3.0.1">
      <Version>3.0.1</Version>
    </NuGetReference>
    <Reference Include="Swift">
      <Private>True</Private>
    </Reference>
    <Reference Include="Echoes">
      <Private>True</Private>
    </Reference>
    <Compile Include="Class.swift" />
  </ItemGroup>

As you can see, we added a NuGetReference to Microsoft.NET.Sdk.Functions 3.0.1. We also again removed a bunch of files that are not necessary. Your .elements file should now look like this:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <PropertyGroup>
    <TargetFramework>.NETCore3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <RootNamespace>silverfunc</RootNamespace>
    <Mode>Echoes</Mode>
    <ProjectGuid>{796792DD-F4C0-484D-9DA7-98D793F081B6}</ProjectGuid>
    <OutputType>Library</OutputType>
    <OutputPath>.\bin\output</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <NuGetReference Include="Microsoft.NET.Sdk.Functions:3.0.1">
      <Version>3.0.1</Version>
    </NuGetReference>
    <Reference Include="Swift">
      <Private>True</Private>
    </Reference>
    <Reference Include="Echoes">
      <Private>True</Private>
    </Reference>
    <Compile Include="Class.swift" />
  </ItemGroup>
  <Import Project="$(MSBuildExtensionsPath)\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets" />
</Project>

We are now ready to start building our Azure Function. Since this is not using the dotnet compiler but an alternative tool, we will not be able to use attributes to generate the function.json bindings. We’ll have to add that just as we would for a Node.js, Python, etc. project. We also need to add a host.json file. A minimal host.json is simply

{
    "version": "2.0"
}

It’s easy to add this through either Water or Visual Studio and set it to Build Action: None and Copy to Output: PreserveNewest.

Let’s rename Class.swift to HttpExample.swift, as in the quickstart example. We also need to add a physical folder named HttpExample and then add a function.json to that folder. Set the function.json properties the same way you set host.json. This will set up the appropriate function binding. The HttpExample.swift can be stored anywhere since it will be compiled. I’ve left it in the root of my project, but you should be able to move it to the HttpExample folder if you want. Our binding is going to be a simple httpTrigger:

{
  "bindings": [
    {
      "type": "httpTrigger",
      "methods": [
        "get",
        "post"
      ],
      "authLevel": "function",
      "name": "req"
    }
  ],
  "disabled": false,
  "scriptFile": "../silverfunc.dll",
  "entryPoint": "silverfunc.HttpExample.Run"
}

You may wonder where the scriptFile and entryPoint come from, especially since we haven’t even written any code. This is essentially a copy of the generated function.json from a similar C# project. The compiled library is typically published in the bin/output root, and the function bindings are in folders named after the function with a function.json as the only content. The entryPoint is derived from the RootNamespace from the .elements project file and the class and method names we’ll define next.

I don’t know Swift that well, so I used Water to convert the C# version of the function to Swift for me.

I realize this is cheating a bit, but I did try and actually got pretty close. I mostly missed the _ before each param name and the ! on types. Also, the conversion was close but not complete. You’ll need to add another Swift class to deserialize the request body. (Well, that may not be required, but it’s what I did. I added a file named Named.swift, then added a generic to the deserialization:

Here’s the Named.swift file I added:

public class Named {
    var name: String?
}

Building

With all these things in place you can successfully build the project!

Unfortunately, you won’t be able to run it as you would a dotnet Azure Function.

1. You cannot run the Azure Function app from either Water of Visual Studio.
2. You cannot launch func host start from the project root. You will need to launch from bin/output.
3. You’ll also find that function.json was deployed to the root of bin/output. You need to add an additional element to the specify the output directory:

    <None Include="HttpExample\function.json" LinkBase="HttpExample\">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <FinalOutputFolderOverride>.\HttpExample\</FinalOutputFolderOverride>
    </None>

NOTE: according to this comment, the element to specify the output folder will change in the next version to <DestinationFolder>.\HttpExample\</DestinationFolder>

This will get you the correct output contents and should let you successfully run func host start from bin/output.

C:\Users\ryanr\Code\OSS\silverfunc\bin\output [master ≡]> func host start
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell]
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell]
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell]

                  %%%%%%
                 %%%%%%
            @   %%%%%%    @
          @@   %%%%%%      @@
       @@@    %%%%%%%%%%%    @@@
     @@      %%%%%%%%%%        @@
       @@         %%%%       @@
         @@      %%%       @@
           @@    %%      @@
                %%
                %

Azure Functions Core Tools (3.0.2630 Commit hash: beec61496e1c5de8aa4ba38d1884f7b48233a7ab)
Function Runtime Version: 3.0.13901.0
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell]
[7/27/2020 3:21:45 AM] Building host: startup suppressed: 'False', configuration suppressed: 'False', startup operation id: 'db702c1f-f267-4b9a-9a1b-ee81a048104b'
[7/27/2020 3:21:45 AM] Reading host configuration file 'C:\Users\ryanr\Code\OSS\silverfunc\bin\output\host.json'
[7/27/2020 3:21:45 AM] Host configuration file read:
[7/27/2020 3:21:45 AM] {
[7/27/2020 3:21:45 AM]   "version": "2.0"
[7/27/2020 3:21:45 AM] }
[7/27/2020 3:21:45 AM] File 'C:\Program Files (x86)\dotnet\dotnet.exe' is not found, 'dotnet' invocation will rely on the PATH environment variable.
[7/27/2020 3:21:45 AM] Loading functions metadata
[7/27/2020 3:21:45 AM] Reading functions metadata
[7/27/2020 3:21:45 AM] 1 functions found
[7/27/2020 3:21:45 AM] 1 functions loaded
[7/27/2020 3:21:45 AM] Loading extensions from C:\Users\ryanr\Code\OSS\silverfunc\bin\output\bin. BundleConfigured: False, PrecompiledFunctionApp: False, LegacyBundle: False
[7/27/2020 3:21:45 AM] File 'C:\Program Files (x86)\dotnet\dotnet.exe' is not found, 'dotnet' invocation will rely on the PATH environment variable.
[7/27/2020 3:21:46 AM] Initializing Warmup Extension.
[7/27/2020 3:21:46 AM] Initializing Host. OperationId: 'db702c1f-f267-4b9a-9a1b-ee81a048104b'.
[7/27/2020 3:21:46 AM] Host initialization: ConsecutiveErrors=0, StartupCount=1, OperationId=db702c1f-f267-4b9a-9a1b-ee81a048104b
[7/27/2020 3:21:46 AM] LoggerFilterOptions
[7/27/2020 3:21:46 AM] {
[7/27/2020 3:21:46 AM]   "MinLevel": "None",
[7/27/2020 3:21:46 AM]   "Rules": [
[7/27/2020 3:21:46 AM]     {
[7/27/2020 3:21:46 AM]       "ProviderName": null,
[7/27/2020 3:21:46 AM]       "CategoryName": null,
[7/27/2020 3:21:46 AM]       "LogLevel": null,
[7/27/2020 3:21:46 AM]       "Filter": "<AddFilter>b__0"
[7/27/2020 3:21:46 AM]     },
[7/27/2020 3:21:46 AM]     {
[7/27/2020 3:21:46 AM]       "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
[7/27/2020 3:21:46 AM]       "CategoryName": null,
[7/27/2020 3:21:46 AM]       "LogLevel": "None",
[7/27/2020 3:21:46 AM]       "Filter": null
[7/27/2020 3:21:46 AM]     },
[7/27/2020 3:21:46 AM]     {
[7/27/2020 3:21:46 AM]       "ProviderName": "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.SystemLoggerProvider",
[7/27/2020 3:21:46 AM]       "CategoryName": null,
[7/27/2020 3:21:46 AM]       "LogLevel": null,
[7/27/2020 3:21:46 AM]       "Filter": "<AddFilter>b__0"
[7/27/2020 3:21:46 AM]     }
[7/27/2020 3:21:46 AM]   ]
[7/27/2020 3:21:46 AM] }
[7/27/2020 3:21:46 AM] FunctionResultAggregatorOptions
[7/27/2020 3:21:46 AM] {
[7/27/2020 3:21:46 AM]   "BatchSize": 1000,
[7/27/2020 3:21:46 AM]   "FlushTimeout": "00:00:30",
[7/27/2020 3:21:46 AM]   "IsEnabled": true
[7/27/2020 3:21:46 AM] }
[7/27/2020 3:21:46 AM] SingletonOptions
[7/27/2020 3:21:46 AM] {
[7/27/2020 3:21:46 AM]   "LockPeriod": "00:00:15",
[7/27/2020 3:21:46 AM]   "ListenerLockPeriod": "00:00:15",
[7/27/2020 3:21:46 AM]   "LockAcquisitionTimeout": "10675199.02:48:05.4775807",
[7/27/2020 3:21:46 AM]   "LockAcquisitionPollingInterval": "00:00:05",
[7/27/2020 3:21:46 AM]   "ListenerLockRecoveryPollingInterval": "00:01:00"
[7/27/2020 3:21:46 AM] }
[7/27/2020 3:21:46 AM] HttpOptions
[7/27/2020 3:21:46 AM] {
[7/27/2020 3:21:46 AM]   "DynamicThrottlesEnabled": false,
[7/27/2020 3:21:46 AM]   "MaxConcurrentRequests": -1,
[7/27/2020 3:21:46 AM]   "MaxOutstandingRequests": -1,
[7/27/2020 3:21:46 AM]   "RoutePrefix": "api"
[7/27/2020 3:21:46 AM] }
[7/27/2020 3:21:46 AM] Starting JobHost
[7/27/2020 3:21:46 AM] Starting Host (HostId=desktopm63akg2-547175781, InstanceId=1a6698de-1147-4be2-893e-c9080f538890, Version=3.0.13901.0, ProcessId=17080, AppDomainId=1, InDebugMode=False, InDiagnosticMode=False, FunctionsExtensionVersion=(null))
[7/27/2020 3:21:46 AM] Loading functions metadata
[7/27/2020 3:21:46 AM] 1 functions loaded
[7/27/2020 3:21:46 AM] Generating 1 job function(s)
[7/27/2020 3:21:46 AM] Found the following functions:
[7/27/2020 3:21:46 AM] Host.Functions.HttpExample
[7/27/2020 3:21:46 AM]
[7/27/2020 3:21:46 AM] Initializing function HTTP routes
[7/27/2020 3:21:46 AM] Mapped function route 'api/HttpExample' [get,post] to 'HttpExample'
[7/27/2020 3:21:46 AM]
[7/27/2020 3:21:46 AM] Host initialized (229ms)
[7/27/2020 3:21:46 AM] Host started (245ms)
[7/27/2020 3:21:46 AM] Job host started
Hosting environment: Production
Content root path: C:\Users\ryanr\Code\OSS\silverfunc\bin\output
Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.

Http Functions:

        HttpExample: [GET,POST] http://localhost:7071/api/HttpExample

[7/27/2020 3:21:51 AM] Host lock lease acquired by instance ID '000000000000000000000000B6B01377'.

Deploying

I didn’t bother trying to deploy this direct to Azure Functions. There’s no reason it shouldn’t work, but as I’ve been doing all Docker deployments to Azure Functions for some time now, I went ahead and added a simple Dockerfile and created an Azure Function using a custom image. Here’s the contents of the Dockerfile:

FROM mcr.microsoft.com/azure-functions/dotnet:3.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true
COPY bin/output/ /home/site/wwwroot

Once I published my image, the instructions in the link above worked just as well for this image as for the other images I’ve used. Better still, it worked perfectly!

Conclusion

I was excited to find that I could use Swift to build Azure Functions. It’s also nice to have a choice of whether to use the official Swift compiler as in Saleh’s swiftfunc or the RemObjects Elements compiler. In particular, I really enjoyed learning about and using Elements. I was pleasantly surprised to find that their tools are nice to work with and better still, they have some of the best support I’ve ever experienced. Marc reached out directly and quickly through their discussion forums, fixing a few bugs he found and providing me with an update to continue experimenting. I’m interested to see how a mixed language function project might work next.

You can find the full source code for this project on GitHub.

What do you think? Have you wanted to write Swift but lacked a Mac? Interested in some other aspect of any of these topics? Leave a comment!

Microsoft introduced InfoPath in 2003 as part of Office 2003. InfoPath became the primary means of exposing forms within SharePoint and could even be hosted in a browser through a SharePoint Form Library. Microsoft discontinued development of InfoPath after the 2013 release in 2015. Power Apps is considered the successor to InfoPath.

As far as forms solutions go, I thought InfoPath was alright. I liked it, and I appreciated the visual aspect to building forms. It seemed to have all that I needed for the forms I needed to build at the time. However, aside from the visual designer, I didn’t understand the benefit to someone that could build forms in web pages with a bit of JavaScript. Indeed, if you did need to code up some additional behavior, InfoPath was little better, as can be seen from this post from Micah Dubinko, author of XForms Essentials.

Had it not been that I discovered XForms first, I likely would have found InfoPath quite a good solution. Unfortunately, I discovered them the other way around. Microsoft’s early efforts on InfoPath referenced and appeared to be an attempt at implementing XForms. If only they had done so! Perhaps we would have been writing windows apps with SVG + XForms rather than XAML all these years. This feels like a missed opportunity.

If you never encountered XForms, then you may wonder why I’m lamenting them. XForms was an XML document specification (not an application specification, a document specification) for laying out forms with a spreadsheet-like reactive dependency graph using a declarative notation. This StackOverflow answer does a nice job of laying out its uniqueness. XForms did not get any major browser implementation due to its being considered too difficult to implement, despite there being numerous plugins available. What this really means is that Google and Apple, who were working on what would become HTML5, decided to stick to the status quo and rely on JavaScript rather than adopting a new standard. Ajax was still relatively new at that point, and most scripting for form interactivity was still pretty minimal.

Back to the missed opportunity. While Google and Apple were pushing “web standards” and taking back ground from Microsoft, Microsoft was still building their own walled gardens of formats. InfoPath was one, and XAML was another. Imagine if, had Microsoft consented to engage with the standards at that time, how we may have seen adoption of better technologies. SVG was rolled into HTML5. Why not XForms?

Although the W3C XForms charter was discontinued in 2015, the community has continued work on it and is currently working on XForms 2.0. They’ve even added ways to interact with datasets in JSON rather than just XML. You can find current XForms implementations in XSLTForms and Orbeon Forms. XSLTForms allows you to render XForms as HTML5 forms using an XSLT stylesheet and provided JavaScript library in an XHTML document. Steven Pemberton’s “A Game in XForms” is a fun demonstration of XForms in use. Orbeon Forms is a solution that appears quite similar to Power Apps but with XForms as its internal engine.

As for Power Apps, I really like the platform, though I don’t love that it is still within the walled garden, this time Dynamics rather than Office. The Power Platform as a whole is a really nice suite of tools, and the Excel-like formulas for hooking up actions feels very similar to the design of XForms. If you are looking for a way to quickly build out forms and even apps, Power Apps is a pretty great solution, though it’ll cost you.

I enjoyed reviewing and remembering these tools. I spent a lot of time in the mid-2000’s working with XForms and ultimately InfoPath before finally getting into .NET at the end of the decade. The only loser here seems to be HTML Forms which remains merely a document layout format requiring another tool, i.e. JavaScript, to make it do anything. I’m surprised modern UI frameworks have never done more with these. Maybe there’s still an opportunity to improve the HTML Forms space for web developers.

Did you ever use any of these tools? Would you like to see improvements in HTML Forms interactions? Leave a comment, and share your thoughts!

Highly coupled teams are like an assembly line. Everyone is specialized, and everything moves along well until something breaks. In a team with low cohesion, the only ones who can fix the break are those responsible for the area of the assembly line that broke, which means most of the team is not working while the problem is identified and fixed. If a team has high cohesion, then some members can switch roles to help out with the area that is broken, but the rest of the assembly line is still stopped.

Highly cohesive teams are those that have high collaboration with one another and typically are composed of members with different specializations. Everyone can contribute to any part of the work. If the team is highly coupled, however, then the loss of one team member or the need for that team member on any given task causes the rest of the team to grind to a halt while waiting on that team member to free up. A loosely coupled team can continue working on multiple tasks concurrently with no hard dependencies on any one person.

Much like in software, my experience suggests highly cohesive but loosely coupled teams are far more efficient and effective at achieving their objectives. I’m curious whether you’ve had a similar or different experience, and I’m interested in any research on this topic. Please share in the comments.

Azure Static Web Apps generates and commits the GitHub Actions configuration for your project when you create your project. After that, it’s just a standard GitHub Actions configuration, and you are able to do anything you want with it. Since it’s already been committed to source control, you can freely try out any additions you want. So long as you don’t git push -f and erase the original, you’ll always be able to safely return to a working configuration.

Azure Static Web Apps is intended to build your web app and deploy it, but you can also host a truly static site. Azure Static Web Apps uses a tool called Oryx to infer the kind of app you are deploying and run the appropriate commands to build the application. If it cannot determine what kind of application you have pushed, it will assume it is already built (or just a plain, static site). This is great news! That means you don’t have to try to bypass anything if you want to run another tool.

To demonstrate how this works, I’ll start with a failed build. It’s the heart of TDD, after all. While setting up my new Azure Static Web App, I specified / as my application root. My static files are actually in /src. Here’s what Oryx determined:

Taking a look at the generated GitHub Actions configuration, you can see that there’s a section explicitly marked off as “safe to edit” with comments beginning with ###### marking the boundaries.

If I change app_location: "/" to app_location: "src", my build and deploy should succeed.

The site itself is nothing exciting. It’s a simple event registration form. It has an event drop-down, but it’s currently empty.

In the same repository, I have a services.csv file that we could load with a JavaScript CSV parsing library like d3 or PapaParse. However, where is the fun in doing this with JavaScript? We’re building a static site, after all, and as that’s far more bleeding edge than the latest front-end JavaScript library, we’re going to populate the drop-down options with some static site generating magic!

Below is the F# script file I added to the /src directory to “build” my static form. It retrieves the data from the CSV and inserts it into the HTML page, writing the modified HTML and other files in the /src folder to the /out folder. I won’t go into the details in this post. If you are familiar with either F# or JavaScript, you should find this fairly readable.

Once you add a build script and output folder, you’ll need to modify the GitHub Actions configuration again. The easy bit is specifying the output folder. You just need to change the app_location parameter again from app_location: "src" to app_location: "out", or whatever you name your output folder. You may wonder whey app_location instead of app_artifact_location, and the answer is that without a build, Oryx will deploy from the app_location. If it detects and runs a build, it will then look in the app_artifact_location.

The other easy bit is adding a build step. That’s right. That’s all that’s required to use a custom static site generator. If you’ve used GitHub Actions at all, this should be fairly trivial. I added two steps to run the F# script, between the -uses: actions/checkout@v1 and the - name: Build And Deploy section added by Azure Static Web Apps:

    - uses: actions/checkout@v1
    - name: Setup .NET Core 3.1
      id: setupdotnet
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.300
    - name: Generate
      id: generate
      run: dotnet fsi --langversion:preview ./src/build.fsx
    - name: Build And Deploy

The first piece sets up .NET Core 3.1, and the second runs the F# script with dotnet fsi --langversion:preview. The --langversion:preview flag enables the use of the NuGet references in the script above, which is really convenient.

The form now provides a list of events in the drop-down for the user to select.

Azure Static Web Apps does not yet support every static site generator and likely never will. However, the platform can certainly be used by any of them, as long as you are willing to make a few tweaks to the GitHub Actions configuration. Trust me when I say that this is still preferable to the alternative of setting up all the pieces separately. (I will likely do a follow-up post on that topic, as well.)

I hope you enjoyed this little jaunt into custom static site generation with Azure Static Web Apps. Feel free to try it for yourself. You can find the source for this post here. Leave a comment if you do try this or find any other interesting tricks to using Azure Static Web Apps. Happy generating!

However, I’ve been reconsidering my use of FAKE as a default build scripting tool in smaller projects and wanted to write up my reasons for switching to dotnet CLI builds for new projects and migrating some OSS projects to do the same.

Build Script

I have always thought FAKE was quite easy to set up for a project, as you can see from the Getting Started page. With the addition of installation as a dotnet local tool, it’s really easier than ever. However, compare that with the following:

dotnet restore
dotnet build --no-restore -c Release
dotnet test --no-restore --no-build -c Release
dotnet pack --no-restore --no-build -c Release -o bin --include-symbols

I can run that from the command line or put it into a script or .yml file for use in a CI/CD tool. It’s simple, consistent, and portable without trying hard. It’s certainly simpler than even a simple FAKE script.

Versioning

I have used several methods for managing version is my FAKE scripts in the past. I generally copied the same set of functions from project to project. Note: that’s functions, plural. In the past, this required setting up things for modifying AssemblyInfo, but with the introduction of VersionPrefix, Version, and VersionSuffix in the .*proj formats, managing this with a Directory.Build.props and a little bit of PowerShell, which is also cross-platform, is even simpler. Here’s an example from the FSharp.Control.Reactive project:

[xml]$doc = Get-Content .\src\Directory.Build.props
$version = $doc.Project.PropertyGroup.VersionPrefix # the version under development, update after a release
$versionSuffix = '-build.0' # manually incremented for local builds

function isVersionTag($tag){
    $v = New-Object Version
    [Version]::TryParse($tag, [ref]$v)
}

if ($env:appveyor){
    $versionSuffix = '-build.' + $env:appveyor_build_number
    if ($env:appveyor_repo_tag -eq 'true' -and (isVersionTag($env:appveyor_repo_tag_name))){
        $version = $env:appveyor_repo_tag_name
        $versionSuffix = ''
    }
    Update-AppveyorBuild -Version "$version$versionSuffix"
}

dotnet tool restore
dotnet build -c Release /p:Version=$version$versionSuffix
dotnet test --no-build -c Release tests
dotnet pack --no-restore -c Release /p:Version=$version$versionSuffix -o $psscriptroot/bin

Feel free to disagree. I don’t love PowerShell like I love F#, but this is a worthwhile tradeoff for me.

Release Notes

The one thing that kept me with FAKE the longest was its excellent support for managing versions and release notes with its RELEASE_NOTES.md support. I recently stumbled across a post describing how to manage release notes outside of a .*proj file. While I don’t love using MSBuild tasks, this is another one where the benefits outweigh the cost. The nice thing here is that I’m able to include this once in my Directory.Build.props file and have it apply to all of the packaged .nupkgs. Here’s the relevant snippet from the FSharp.Control.Reactive project:

  <Target Name="PreparePackageReleaseNotesFromFile" BeforeTargets="GenerateNuspec">
    <ReadLinesFromFile File="..\..\RELEASE_NOTES.md">
      <Output TaskParameter="Lines" ItemName="ReleaseNoteLines" />
    </ReadLinesFromFile>
    <PropertyGroup>
      <PackageReleaseNotes>@(ReleaseNoteLines, '%0a')</PackageReleaseNotes>
    </PropertyGroup>
  </Target>

This will put the full contents of the RELEASE_NOTES.md file into my FSharp.Control.Reactive.*.nupkg package. I still need to do a little work to take only the relevant lines for the current version, I don’t mind the simplicity.

What’s Left for FAKE?

With all of the above, you may wonder whether there is anything for which I would still use FAKE. I certainly continue to use FAKE for many other purposes. Here’s a list of things for which I continue to use FAKE:

• Generating documentation
• Building and migrating SQL Server databases with SqlPackage
• Complex deployments
• Slide decks

FAKE is a really good tool, and I still highly recommend it. I think the team working on it is doing a great job, and if the things I describe above are not trade-offs you are willing to make, then by all means stick with FAKE.

What do you think? Agree or disagree with any of the directions I’ve taken above? I’m open to changing my mind on these things, and I would love to hear your opinions. Leave a comment!

I debugged through the issue by trying different things like using an in-memory data store, re-checking against a smaller data set, and wrapping StateHasChanged to make sure it was actually called. Everything was working as expected with the in-memory store and smaller data set, and StateHasChanged was always called. However, with the larger data set, the components’ lifecycle methods were not called.

I finally stumbled upon a solution using an old JavaScript trick: adding await Task.Delay(1); This magically worked. If you run into something similar, you may try await Task.Delay(1); and see whether that resolves the issue.

You can find the previous post on WebForms here, if you missed it.

The Bad

I never really had many gripes with WinForms except for its very plain, “battleship gray” theme that seemed somewhat insurmountable to replace. I’ve since seen some fantastic efforts to fix this, e.g. MetroFramework, Winform.Metroframework, and MetroModernUI.

Forms are also the driver for WinForms applications. It’s in the name, after all, but the concept of an application as a form has always struck me as strange. I greatly prefer the terminology used in WPF and other platforms, where a form is the thing into which you enter data.

Lastly, I never really loved the code-behind model that was the default when working with the designer. The generated code was pretty messy, and the code-behind approach made things difficult to test. As I noted in the last post, I have since learned how to extract and test logic independently of how it was wired up to framework code, so I no longer consider the testability issue of much concern.

The Good

Unlike WebForms, this fit the OO model I was learning when I first started with .NET. It keeps things simple and provides a consistent and easy composition model with .Controls.Add, and sticks to .NET’s core eventing model to provide callbacks. WinForms is therefore far simpler to think about than, for example, WPF, which is more powerful but also provides other means of triggering events and UI updates.

I think the first WinForms app I wrote that was not based on a tutorial was from Tomas Petricek‘s Real World Functional Programming using F#. I later learned that you can create and run a Form directly from F# Interactive:

NOTE: with F# Interactive now running as a dotnet tool, I wondered whether it would continue to be possible given WinForms has moved to the Microsoft.WindowsDesktop.Sdk framework reference. Phillip Carter, Microsoft Senior Program Manager for F#, responded that this would no longer be possible in the dotnet fsi (.NET Core F# Interactive):

Aside from mapping very well to OO design, it is quite flexible. Aside from being able to launch it from a script or code it from scratch starting with a console application, you can do also implement many more design patterns, such as MVP or MVU.

This flexibility to adapt to different UI architectures strikes me as something Don Syme referred to as “Object Programming” in his Code I Love talks. In any case, WinForms is in many ways very much like React in that it provides a way to render a UI and leaves the details of how to do that to the implementer.

Lastly, to parallel the last bit from The Bad section, the designer was actually a nice feature that worked quite well. Although I noted how I dislike the code-behind model above, I like that it feels a little like Smalltalk, where you compose the UI with visual objects and then fill in the details with what chunks of code. It’s more or less the same thing. Had I put that together sooner, I don’t think I would have given the code-behind model such a hard time.

Final Thoughts

I think WinForms has stood the test of time, aside from its strict adherence to battleship gray as its primary and dominant appearance. I wouldn’t choose to build many apps in it, but it’s consistency and simplicity make it a terrific platform for quick solutions and adapts really well to any architectural style if you just need something simple to prototype a solution.

What do you think? Was I too easy on WinForms? Is there more to learn from this framework? Leave a comment below!