Fornax is installed as a global .Net Core tool on the command line with:

dotnet tool install fornax -g

This will install Fornax. We can then create a new folder for our new Fornax site, then:

fornax new

This will create a new Fornax site using the default blog template.

Now that we have a default Fornax site set up we can run fornax watch which will spin up a little server that watches for changes to our project.

Let's take a look at the folder structure now that we have a working Fornax site.

• _lib
  • Any external libraries we might like to use go in here and can be referenced from the script files.
  • By default this contains:
    • Fornax.Core.dll
    • Markdig.dll
• _public
  • This is where the final production built files are created after a build.
• loaders
  • Contains all scripts that load data into the global context.
• generators
  • Contains all scripts that generate files in _public based on the global context created by loaders.
• images
  • Images used by our app
• js
  • JS used by our app
• posts
  • This is a domain specific folder used to hold blog posts written in markdown.
• style
  • CSS used by the app
• config.fsx
  • This script runs first, we use it to configure the behavior of our generators and add any additional data like secret keys or SQL connection strings.

Next time we'll take a look an in depth look at loaders and generators and what they can do.

Loaders

In order to talk about loaders we have to take a brief detour to talk about SiteContents. In Fornax, SiteContents is a type defined in the Fornax.Core.dll that can hold any arbitrary number of arbitrary lists of arbitrary objects. Normally, this is a collection of markdown files that are parsed into a collection of Post objects, but that's just the beginning.

Now that we have that out of the way, lets have a look at a loader from the project we made last time. Go ahead and take a peek at postloader.fsx. There's quite a lot to take in all at once, so let's break it down.

type Post = {
    file: string
    link: string
    title: string option
    author: string option
    published: System.DateTime option
    tags: string list
    content: string
    summary: string
}

We declare the post type. So that further down in our program we can add a collection of that type to SiteContents. F# has a fairly robust type system and there's a number of improvements we could make to ensure data integrity, but we'll leave it as it is. We'll jump down to the bottom of the file and take a look at the loader function.

let loader (projectRoot: string) (siteContent: SiteContents) =
        let postsPath = Path.Combine(projectRoot, contentDir)
        Directory.GetFiles postsPath
        |> Array.filter (fun n -> n.EndsWith ".md")
        |> Array.map loadFile
        |> Array.iter siteContent.Add

    siteContent

We can see here that we harness .NET Framework to use Directory.GetFiles from the postsPath that we declare above it. If you're new to F#, the syntax may be a little confusing, but conceptually it's very similar to chaining array methods in JavaScript.

With the collection of files we return from Directory.GetFiles, we Array.filter the collection and return a new collection of only .md files. Then we iterate over that collection with Array.Map and loadFile function which we'll look at in more detail later. After maping the collection we finally Array.iter and add each object in the collection to siteContent and return siteContent after our additions.

let loadFile n =
    let text = File.ReadAllText n

    let config = getConfig text
    let summary, content = getContent text
    let fileName = buildFileName n
    let file = Path.Combine(contentDir, fileName ".md").Replace("\\", "/")
    let link = "/" + Path.Combine(contentDir, fileName ".html").Replace("\\", "/")

    let filter = filterConfig config
    let title = filter "title" |> Option.map trimString
    let author = filter "author" |> Option.map trimString
    let published =
        filter "published" 
        |> Option.map (trimString >> System.DateTime.Parse)

    let tags =
        let tagsOpt =
            filter "tags"
            |> Option.map (trimString >> fun n -> n.Split ',' |> Array.toList)
        defaultArg tagsOpt []

    { file = file
    link = link
    title = title
    author = author
    published = published
    tags = tags
    content = content
    summary = summary }

The function loadFile does a lot of things I'll leave it to you to figure out the process of reading and parsing a given markdown file as passed in from the loader function. The thing I'd like to note, however, is that each time we iterate through this function we return an object that matches the shape of the Post type that exists at the top of the file.

Now that we've loaded our posts into SiteContents we can take a look at what generators do with that content.

Generators

Once we've churned through that loader and have our contents in memory we can generate some front end content. Let's have a look inside the post.fsx inside the generators folder.

This file is a lot shorter than postloader. Let's start at the bottom.

let generate (ctx : SiteContents) (projectRoot: string) (page: string) =
    generate' ctx page
    |> Layout.render ctx

Immediately we call generate' and pass in SiteContents and page then we pipe the value returned from that function to Layout.render. Layout.render is outside the scope of this article, but it lives in layout.fsx.

For now though, let's look at generate'. we'll look at it block by block.

let generate' (ctx : SiteContents) (page: string) =
    let post =
        ctx.TryGetValues<Postloader.Post> ()
        |> Option.defaultValue Seq.empty
        |> Seq.find (fun n -> n.file = page)

First we try to find the post. We start by using TryGetValues method on SiteContents to pull back all posts that match the shape of the object Post that exists in the loader we looked at previously. Then we iterate through the sequence until we find one that matches the page we're currently iterating through.

    let siteInfo = ctx.TryGetValue<Globalloader.SiteInfo> ()
    let (desc, title) =
        siteInfo
        |> Option.map (fun si -> (si.description, si.title))
        |> Option.defaultValue ("", "")

We do the same thing to grab SiteInfo (held in globalloader.fsx) and map any description and title we have stored.

    Layout.layout ctx (defaultArg post.title "") [
        section [Class "hero is-info is-medium is-bold"] [
            div [Class "hero-body"] [
                div [Class "container has-text-centered"] [
                    h1 [Class "title"] [!!title]
                    span [] [!!desc]
                ]
            ]
        ]
        div [Class "container"] [
            section [Class "articles"] [
                div [Class "column is-8 is-offset-2"] [
                    Layout.postLayout false post
                ]
            ]
        ]
    ]

This part is pretty different from what we've looked at previously. This is a feature of Fornax that harnesses an interesting feature of F# called Domain Specific Language. Instead of writing HTML in Fornax we use this DSL to simplify the templating process. If you've done work with HTML markup. I'll admit it feels a little awkward to use DSL to write a template, but once I got the hang of it I've found it pretty compelling.

From there generate' returns the DSL HtmlElement we constructed where it can be parsed and turned into a string in Layout.render when we finally output the file into the _public folder.

That's the basic overview of loaders and generators. We only scratched the surface of what we can do with loaders. Because we're working with F# scripts we can get our data from any source we might want.

RESTful API? For sure.

SQL DB? No problem.

CSV? Absolutely.

Similarly, we can output data in a generator in any number of formats. RSS, CSV, JSON, plain text, and so on.

That's enough for today I think. Next time, we'll take a look at creating our own loader using an external API.

Before We Begin

To facilitate working with data from APIs or sources outside of markdown we're going to bring in a library. Because Fornax is, at heart, a small collection of F# scripts consumed by a library, we won't be dealing with a package manager. I went to FSharp.Data and downloaded the precompiled binaries and dropped FSharp.Data.dll and FSharp.Data.DesignTime.dll into the _lib folder.

FSharp.Data is a collection of parsers and type providers that simplify common data routines and allows a more F# centric, functional first, way than if we were to use built in .NET Framework or C# libraries.

The API we're going to use is Cat Facts because it's free, open, and is a collection of facts about cats.

Custom Cat Facts Loader

We'll make a new file in the loaders folder called catfacts.fsx.

At the top of the file we'll bring in our assembly references:

    #r "../_lib/Fornax.Core.dll"
    #r "../_lib/FSharp.Data.dll"
    open FSharp.Data

That's it, now we can use FSharp.Data to handle our HTTP request and JSON parsing.

We'll declare a JsonProvider with the basic shape of the response from the Cat Facts API and the CatFacts type that we'll be using internally.

type CatFactsTemplate = JsonProvider<"""
{
    "all":
    [
        {
            "_id": "string",
            "text": "string"
        }
    ]
}""">

type CatFacts =
    { Id : string
      Text : string }

We could make both of these type definitions more elaborate. We get a lot more information out of the Cat Facts API, but this is enough for now.

To explain, CatFactsTemplate uses JsonProvider out of FSharp.Data. When we go to parse the JSON from the HTTP request and translates it into an F# object we can use.

Now that our data types are out of the way, let's dig into the loader function.

let loader (projectRoot: string) (siteContent: SiteContents) =
    let httpRequest = Http.RequestString("https://cat-fact.herokuapp.com/facts")
    let jsonResponse = CatFactsTemplate.Parse(httpRequest).All

    let facts = seq {
        for record in jsonResponse do
            { Id = record.Id ; Text = record.Text }
    }

    facts
    |> Seq.take 10
    |> Seq.iter (fun f -> siteContent.Add f)

    siteContent

Taken in steps we can see that we make an HTTP request to the API and pull back a list of facts. FSharp.Data handwaves away a lot of the details that we might have had to do if we used WebClient out of .NET Framework.

After that, we call CatFactsTemplate.Parse to take the JSON body and convert it into an F# object. We tack All on the end so we have only the Array of objects with Id and Text.

Under the hood, the Array we get out of the parse doesn't actually implement IEnumberable<'T> so we can't iterate over it by piping it into Seq.xyz. Instead we'll create an IEnumerable<'T> ourselves with:

let facts = seq {
    for record in jsonResponse do
        { Id = record.Id ; Text = record.Text }
}

This creates a sequence, which does implement IEnumberable<'T>, by looping through jsonResponse and returning our CatFacts type with the data defined in CatFactsTemplate.

facts
|> Seq.take 10
|> Seq.iter (fun f -> siteContent.Add f)

siteContent

Now that we have our sequence we can pipe that into Seq.take to cut down on the objects we're going to add into siteContent. Then we just Seq.iter to loop through our ten objects and add them to site content so we can generate HTML from them.

That's it, we now have a custom loader that consumes an external API.

Custom Cat Facts Generator

Now that we have all of our Cat Facts data loaded into SiteContents, let's bring it out into a generator. We'll make a new file called catfacts.fsx in the generators folder.

Then we'll whip up something that looks like this:

#r "../_lib/Fornax.Core.dll"
#load "layout.fsx"

open Html

let catfactCard (fact : Catfactsloader.CatFacts) =
    div [Class "card article"] [
        div [Class "card-content"] [
            div [Class "media-content has-text-centered"] [
                !! fact.Text
            ]
        ]
    ]

let generate' (ctx : SiteContents) =
    let facts =
        ctx.TryGetValues<Catfactsloader.CatFacts>()
        |> Option.defaultValue Seq.empty
        |> Seq.toList
        |> List.map (catfactCard)

    Layout.layout ctx "Home" [
        div [Class "container"] [
            section [Class "articles"] [
                div [Class "column is-8 is-offset-2"] facts
            ]
        ]
    ]

let generate (ctx : SiteContents) (projectRoot: string) (page: string) =
    generate' ctx
    |> Layout.render ctx

We pull in the files we need at the top and open the module we'll be using, in this case HTML, to handle the Domain Specific Language (DSL) that we talked about in the last article.

let generate (ctx : SiteContents) (projectRoot: string) (page: string) =
    generate' ctx
    |> Layout.render ctx

Like we also talked about last time, generate gets called first by Fornax at build time. It calls another function called generate' and pipes the resulting HtmlElement content into the Layout.render function. Render then parses the template into a string for the resulting HTML document.

let generate' (ctx : SiteContents) =
    let facts =
        ctx.TryGetValues<Catfactsloader.CatFacts>()
        |> Option.defaultValue Seq.empty
        |> Seq.toList
        |> List.map (catfactCard)

    Layout.layout ctx "Home" [
        div [Class "container"] [
            section [Class "articles"] [
                div [Class "column is-8 is-offset-2"] facts
            ]
        ]
    ]

First, we try get to our CatFacts out of SiteContent with ctx.TryGetValues<Catfactsloader.CatFacts>(). Then we set a default value if we wind up not having records in SiteContents. Next, we turn the Sequence into a List. Finally, we map over the List with the catfactCard function to return a List.

let catfactCard (fact : Catfactsloader.CatFacts) =
    div [Class "card article"] [
        div [Class "card-content"] [
            div [Class "media-content has-text-centered"] [
                !! fact.Text
            ]
        ]
    ]

Here we see catfactCard is just a function that takes a CatFact and returns an HtmlElement with CatFact.Text in a div. With that, we should have a working generator ready to build some content.

Final Steps

The last thing we have to do is register the generator in config.fsx in the root of our project.

let config = {
    Generators = [
        {Script = "less.fsx"; Trigger = OnFileExt ".less"; OutputFile = ChangeExtension "css" }
        {Script = "sass.fsx"; Trigger = OnFileExt ".scss"; OutputFile = ChangeExtension "css" }
        {Script = "post.fsx"; Trigger = OnFilePredicate postPredicate; OutputFile = ChangeExtension "html" }
        {Script = "staticfile.fsx"; Trigger = OnFilePredicate staticPredicate; OutputFile = SameFileName }
        {Script = "index.fsx"; Trigger = Once; OutputFile = NewFileName "index.html" }
        {Script = "about.fsx"; Trigger = Once; OutputFile = NewFileName "about.html" }
        {Script = "contact.fsx"; Trigger = Once; OutputFile = NewFileName "contact.html" }
    ]
}

This array of Generators determines how Fornax treats the generators we make. In this case we want to generate the file once by adding the following entry to the collection.

{Script = "catfacts.fsx"; Trigger = Once; OutputFile = NewFileName "catfacts.html" }

Script is the generator script we're using and Trigger defines how to handle the generation of the HTML file. We are choosing the built in Fornax value of Once but we could define our own logic for how to handle file generation. Then we have the OutputFile and we're going to call it catfacts.html.

With that, we can fornax watch and visit localhost:8080/catfacts.html to see our result.

Now that we've created a very simple loader and generator to consume an API we could expand that out to any arbitrary data source. We can see that Fornax gives us a very simple method of pulling in and transforming that data. Moving forward we could, for instance, bring in Tweets, dev.to interactions, CSV data, or arbitrary database connections. Any data we can manipulate in F# can be turned into static content.

Next time I think we'll look into some of the features of Fornax and what it's lacking from other static site generators.

What happened? Well, three things: podcasts, YouTube, Twitch, and office changes.

Podcasts

I've long been a podcast guy. Since roughly 2011 I've listened to podcasts numbering in the triple digit ranges. Some of them ended prematurely and were mourned and some continue on in a zombie like state. Of particular dominance in 2023 were "Chapo Trap House", "True Anon", and the Merlin Mann family of two-guys-podcasting-shows but specifically "Roderick on the Line." Post election and semi-post-pandemic CTH kept my toe dipped in political discourse enough. TA is a show about human misery and routinely features the worst possible things people do to one another. As for RotL, I like John and I like Merlin. Simple as.

The side effect of listening to that much podcasting is that it tends to just make me miserable. A long form version of doomscrolling piped directly into my ears. Most of my adult life has been a delicate balance between feeling informed and being utterly depressed about being informed, and it just so happens 2023 is the first full year I've been on a form of depression medication.

YouTube

Long form video essays took over a large portion of my listening time. Brief seven-hour retrospectives of games I've never played. Also 9 hour brief retrospectives on games I've played so much that I could nod sagely as the narrator described some story beat or mechanic.

Twitch

In 2023 I also ended up putting on more Twitch streams as background noise. There's a small collection of streamers that took up a bulk of that time, biggest of which was: Barricade. There's about a half dozen other developer streams that I picked up over this period of time. I'll have them listed in a separate page under the About section.

Office

2023 saw two major changes here. Directlink moved offices and we had some departures. The reduced size of the team led toward more time spent being open to answering questions. The change in office meant that I could no longer get up and walk around downtown on breaks. That means less time sitting at my desk with noise canceling headphones and even less time walking around with my AfterShokz Aeropex.

What am I going to do about it?

Well, I don't know. So far this year I've started playing music as part of my morning routine.

Historically, after getting out of bed I would put on a podcast or YouTube video, make breakfast, jump in the shower, get dressed, and drive to work. This year I've tried to listen to recommendations and morning mixes and the like. It's worked to an extent. I've also started blocking out certain periods of the day where I can put headphones on for an hour and be a bit more productive. In general it's helped increase my mood (although I'm sure the anti-depressants also helped).

I'm not sure what other steps to take. I think the most I can do is re-prioritize music in my day-to-day and see what happens.

A world of fast mana

A cursory glance across the card files for Alpha, Beta, and Unlimited (ABU) reveals a staggering amount of fast mana. Sol Ring, Mana Vault, Basalt Monolith, the Mox cycle, and Black Lotus all deliver an incredible amount of mana very quickly. This reality would almost certainly inform a large portion of design in the first four expansions.

Why were creatures weak?

I'd like to submit that they weren't. Not really anyway. Yes, instant and sorcery cards (to use the modern names) were substantially more powerful, but conceptually they could only be cast once. In reality the existence of Regrowth made the nascent four-of rule basically invalid. We see that reflected in DCI quickly restricting it three months into competitive play.

A card like Craw Wurm could be cast on turn two on the play. It would stick around and put the opponent on a four turn clock. Even if it only did six damage that would be over a quarter of the starting life total.

No, Craw Wurm never saw real tournament play. Competitive play was never the only, or even the primary, way people played Magic. To this day the most common and popular format people play is a pile of cards I own, played at my kitchen table. It's a certainty that the crew designing the sets would have been cognizant of this. Further, they would have known after ABU proved there was a consumer appetite for Magic that some players would spend hundreds of dollars to own the best cards.

Ultimately, then, the general power level of creatures was conservative rather than actively bad. The flaw was in over-estimating the primary draw back of instants, sorceries.

The Case for Lady Orca

Lady Orca is a much maligned legendary creature from the set Legends.

She is a 7/4 legendary creature for 5RB.

Compare it to a similarly massive creature from ABU like Force of Nature. 2GGGG for an 8/8 trampler that has an upkeep cost of GGGG every turn. Or all stars like Erhnam Djinn a 3G 4/5 with what was intended to be a downside of making your opponents creatures unblockable.

Today we see an overcosted vanilla creature. To the designers, Lady Orca in this format is a three turn clock with 0 the only downside being BR casting cost and Legendary supertype and it dodges two of the premium removal spells in the format (Terror and Lightning Bolt) and receives a chunky 7 life when hit with Swords to Plowshares. Compared to other creatures this is an insane rate.

To be clear, I never really stopped I just moved twice, changed jobs thrice, and lived through a once in a lifetime pandemic. In that time I mostly played Hearthstone to scratch the competitive itch. HS never really cut it, but it was enough. When MtG: Arena came out I tried to play the MacOS client but it had consistent issues updating and other performance bugs.

In December 2023 Kelly started getting into Magic. She started playing MtG:A, watching streamers and commander gameplay. Her getting into it is what started me back into the breach.

After spending, roughly, 5-6 years away my skills are lacking. Especially in commander. I was always trash at commander. I'm a 1v1 competitive player at heart. I don't have a huge amount of practice mentally loading 4-5 player board states into my brain while also maintaining strict adherence to the basic rules of Magic.

In the FFA environment I'm deeply prone to missing triggers, draw steps, and doing what the cards say, so I beat myself up a bit and go on to make more blunders. As the night goes on and my mental game deteriorates after playing 1-2 hour grind-fests so does the play.

The other major challenge is the card pool has increased by leaps and bounds since 2017. Every time I sit down to a pod there are at least a dozen or more cards that I've never heard of provides some insane on-board trick that I need to load into working memory. It hasn't gone smoothly. Of course that permanent on the board with three discrete paragraphs of text is an enchantment. No, that's a 5/4 creature, also it has first strike and when it deals damage it gets +1/+1 counters equal to the damage it does. Idiot.

The other night I had the miserable experience of digging for combo pieces in my Alesha deck. After three games in three hours I just didn't have the mental left to do it in under ten minutes.

I know commander != Magic and that 1v1 events still fire around here. I feel like I could still hang in a 3 round Swiss but the mental drain from commander has me worried. If I can't play this casual ass format acceptably, let alone perfectly, how can I play competitively?

Am I just going to be some Uncle Rico talking about the good old days? "Back in 2015 I used to be able to Top 4 modern RPTQs. Hell, I 2-1 or better'd every Khans block draft I entered." Just to get combo-killed by some kid on Lotus Field on a win and in into top 8.

My History with Kaust, Eyes of the Glade:

I'll admit, I was a little bit excited when Kaust was revealed during preview season. I've loved the face-down/face-up morph/manifest/cloak/disguise concept for years and it looked substantially different from earlier attempts at the theme like Kadena, Slinking Sorcerer or Animar, Soul of Elements. Still, I probably wouldn't have bought it with my own money. Instead, I won the pre-con in an end-of-month giveaway at my LGS (shout out Dame Games).

Since then I've been tinkering with it. At first attempting to make a value toolbox in the style of Kadena, a colorless beatdown deck, and a D&T-style stax and tax monstrosity. None of these really worked. The themes all fought with the commander and the face-down card pool to choose from.

Instead, there's one thing that's extremely important to understand about Kaust: he isn't a morph/disguise commander. Not in the traditional sense anyway. He doesn't provide you with immediate card and board advantage that can take over a game just by playing face-down creatures. Nor does he reduce the cost of face-down creatures. Instead, Kaust is a manifest/cloak commander. He let's us abuse those mechanics to cheat out some interesting threats for very, very cheap.

Gameplan gives us the two core cards of the deck; Mastery of the Unseen and Ugin's Mastery.

Manifest Masteries

How do we make the most of these two cards? Their overall effect is fairly similar, but operate in distinct ways.

We have two distinct lines then, both resulting in different flavors of infinite mana. There are plenty of ways to do this in Naya.

To get the most out of Mastery of the Unseen we simply need the ability to make infinite (white) mana. Some of our options include:

• Emiel the Blessed + Dockside Extortionist + four artifacts/enchantments on opponent boards
• Emiel the Blessed + Selvala, Heart of the Wild + Misc. Haste Enabler
• Selvala, Heart of the Wilds + Staff of Domination + Misc. six power creature And so on, we can adjust to taste and budget.

In the case of Ugin's Mastery we need don't necessarily need infinite mana, we just need to loop casting a colorless spell. For this we can

Of Manifests and Cloaks

Once we have those enablers, what are we trying to manifest? We have some criteria to look out for:

• Expensive beaters for a reduced price
  • Our primary win condition is reducing life totals to 0 and we can save some mana doing it by flipping some big beef.
• Negative ETB effects
  • Since we're manifesting, positive ETB triggers are wasted. Negative ETB triggers are effectively dodged though. We can skim some value on some value from big stat lines with awful ETBs.
• Triggers on combat damage to players
  • If we attack with 2/2 face-down creatures we miss out on "when this creature attacks" triggers. We do however still get combat damage and "while this creature is attacking" effects.
• Immediate status effects
  • Flip over a creature that grants some status, like indestructable

With that in mind we can immediately consider some stand-alone win condition all-stars like Blightsteel Colossus. In fact, we immediately end the game if we flip our Colossus while we have a Pyrotechnic Performer on board.

We can bring in a package of 10-12 creatures that include some fun cards, here's a non-exhaustive list at three different pricepoints (as of 6/4/2024):

Big time John Hammond players, spare no expense:

• Blightsteel Colossus
• Ancient Copper Dragon
• Old Gnawbone
• Avacyn, Angel of Hope
• Kozilek, Butcher of Truth
• Ulamog, the Ceaseless Hunger
• Ulamog, the Infinite Gyre

Some hitters at mid-tier prices:

• Elesh Norn, Grand Cenobite
• Bloodthirster
• Cavern-Hoard Dragon
• Balefire Dragon
• Blinding Angel
• Angel of Destiny
• Ancient Bronze Dragon
• Ancient Gold Dragon

Some choice budget options:

• Steel Hellkite
• Giant Adephage
• Port Razer
• Siege Behemoth
• Akki Underminer
• Kutzil, Malamet Exemplar
• Dragon Mage

Is it Good?

Well, no. Still bad.

Sorry.