Various musings of Brock Wilcox (@awwaiid)

2021.05.09 Meet In The Middle

When I compose a bit of code there tend to be two opposing approaches in my mind -- Top-Down and Bottom-Up. Generally Top-Down starts off as an outline, an overview of the program that I wish I had. Sometimes this is behavior-driven-development, which works well for libraries. I think ... if this library already magically existed, how would I want to interact with it? Then it's sort of this fill in the blank exercise to actually implement it, going down layer by layer until it actually works.

Sometimes I take a Bottom-Up approach. I think, what is a small end thing that can move this forward, or is a reusable tool that I can use to make this problem more tractable? How would I build up a language to express my problem? If I can work out that language then ultimately, hopefully, expressing my problem becomes trivial.

Ultimately though I do a bit of each. I sketch out the problem a layer or two, then I think about what the language, or general modeling, is that I'm using and thinking, then I codify that a bit, and then I stitch it all together.

Comments on TLT - 2021.05.09 - Meet In The Middle



-- siska 2022-01-03 05:30 UTC

This is awesome, thanks for sharing this post here.

-- fence companies minneapolis 2022-01-05 14:11 UTC

I do really feel you on this one when dealing problems, not just in coding because it can also be related and applied to real life problems. When I encounter one or provide a solution to it, I always tend to think all different perspective and possible outcome, then look for the best one. It's a good practice though to be able to deal problems accordingly.

-- window repair toronto 2022-01-06 13:38 UTC

Thanks for sharing. I will help me someday

-- IPO GMP 2022-01-08 17:56 UTC

Great article you shared.

-- hardwood flooring refinishing Columbus Ohio 2022-01-13 16:23 UTC

Meet me

-- Stafaband 2022-01-14 00:18 UTC

I've been reading some good news from this new software.

-- counseling 2022-01-19 14:34 UTC

Add Comment

2020.09.04 Rusty Slides

To keep from getting rusty, and also because all the cool kids are doing it, I'm picking up a bit of Rust.

I remember at one point I was learning a few new programming languages pretty deeply every year or so and then all of a sudden a year went by when I thought "hmm. I didn't learn a new language this year! I'm getting soft!". Upon further reflection I realized that I was learning languages previously at a high rate by working on them 20+ hours a week instead of doing any homework in college. So then I started thinking it's not so much that I'm getting dumber or learning more slowly, but that I am learning completely different things like how to make real-world software or how to make a business effective at all levels and things like that. Ahh tradeoffs.

Annnnyyywaayy. Rust.

I had a lot of fun with OCaml, doing all sorts of things but especially building tiny toy programming languages and parsers. The strong types and type inferencing there are very cool, and I took great joy in trying to NOT put any explicit types in my code and let the language figure it out. Earn it's keep. If I accidentally write something more general-purpose, type-wise, than I intended, well so be it. OCaml would delight in telling me when I contradicted myself, though often the errors felt backwards. Part of this is because it was written by some cool Frenchies, but also because you'd often make a type-mistake first and a correct-type second. Then it'd get to the correct-type and complain because it was expecting the type-mistake, complaining "I expected an Int but here you used an Str" or similar. You think to yourself... well yeah I used a Str because that's what it's supposed to be. After a while you learned the language of its errors and it all gets much faster, but still.

So the cool kids told me that Rust has type inference and much better error messages. So far... it definitely has good error messages, but I'm not too impressed by the type inference. This is probably because I'm doing some real-world work or something.

The learning project that I've made the most progress on is porting Pinpoint, an old gtk-based slide-presentation software that I like, from C to Rust. I call it Pertinent. Well not really porting -- I tried porting and that didn't work out very well. So more like re-implementation. This program takes in a nice text file of slides separated by dashes like this:






-- [kittens.jpg] [fit]


and it displays "HELLO" and "WORLD" in big letters on the center of the screen as slide 1 and slide 2 and so on. It has some ways to indicate background image and some other markup, but that's the core of the thing.

First up is to parse the file, and for that I've turned to nom, a parser-combinator. This part of the project has gone pretty well, and has made for nicer code than the hand-written parser in the C code (though not TOTALLY dissimilar). Here's a snippet:

// Slide headers look like "-- [a] [b]\n"
fn header(input: &str) -> nom::IResult<&str, SlideOptions> {
    let option_list = many0(option);

    let (input, options) = terminated(
        preceded(many1(tag("-")), option_list),
        alt((whitespace_or_comment, line_ending)),

    let options = options.iter().map(|s| s.to_string()).collect();
    return Ok((input, options));

Now for unrelated reasons I did at one point make a Raku parser for this slide format. It is way prettier in Raku ... here is roughly the same thing (where "setting" is like the "option_list" kinda):

token header { ^^ "--" [ \h* '[' <setting> ']' ]* \h* \n }

So it's kinda like writing a regex out longhand in nom. This might be a little prettier in OCaml, but that is mostly because of needing less parenthesis and having more operators overloaded. Probably there is some macro sugar in Rust that could make this shorter.

More interesting to read is the data structure that I'm parsing this thing into.

type SlideOptions = Vec<String>;

#[derive(Debug, PartialEq)]
pub struct Slide {
    options: SlideOptions,
    content: String,

#[derive(Debug, PartialEq)]
pub struct SlideDeck {
    global_options: SlideOptions,
    slides: Vec<Slide>,

Pretty cool. Have a nicely readable SlideDeck, individual Slide, and a list of options. The derive stuff is neat too, kinda auto-generates functions to pair with the datastructures. Recent OCaml (or libs) have some helpers for this sort of thing too, and they are pretty common in Haskell I think.

You can see the current Pertinent parser on github!

Next up is turning out to be the hard bit, actually displaying the slides. Pinpoint uses Gtk and Cairo with Pango markup. Looks like I have all of those things already all wrapped up in Rust crates (libraries) and I'm making progress. I don't really plan on implementing all the features of Pinpoint, and I MIGHT not ever actually USE this application. But it's fun anyway :)

Comments on TLT - 2020.09.04 - Rusty Slides


Good job

-- mp3 quack 2022-01-03 05:31 UTC

You clearly know what you're doing. It shows in how you write your blogs and explain things. There is no rust at all! :)

-- Mobileboatdetailers 2022-01-11 03:40 UTC

Any update on this Rusty Slides software?

-- counseling 2022-01-11 11:59 UTC

Add Comment

2020.06.21 Sugary Sunday - Javascript Object Property Shorthand

In today's sugary exploration, let's take a look at a shorthand for object key expansion in Javascript (ECMAScript 2015+, es6+). For an overview of the TON of delicious sugar that was added to Javascript at around es6, check out

Most of the "scripting" languages (Python, Ruby) have "dictionaries" or "hashes", a datastructure of key-value pairs. In JS these are called "objects", and they do a lot of other things beyond this basic data-storage behavior. In JSON -- JavaScript Object Notation -- you can see the basic literal declaration syntax. Let's build an addressbook, keyed (indexed) by name.

let addressBook = {
  "alice": {
    "street": "123 Elsewhere Lane",
    "zip": "32341"
  "bob": {
    "street": "221 Baker Street",
    "zip": "00234"
  "clarence": {
    "street": "P.O. Box 17",
    "zip": "88877"

console.log("Bob's info", addressBook["bob"]);

For our first dash of sugar, we can remove the string notation on keys. They are still strings! We can also access bob using property notation.

let addressBook = {
  alice: {
    street: "123 Elsewhere Lane",
    zip: "32341"
  bob: {
    street: "221 Baker Street",
    zip: "00234"
  clarence: {
    street: "P.O. Box 17",
    zip: "88877"

console.log("Bob's info", addressBook.bob);

Pretty fun. But that's not what we're here for. Let's say we have a variable, doug, which contains an address entry. We might do something like this:

let doug = {
  street: "6453 Canyon Canyon",
  zip: "53425"

let addressBook = {
  doug: doug

It's that last bit where we can add The Sugar. Remember that the key is actually a string, "doug", whereas the value is a reference to the variable doug (which contains an address). What we can do here when these two things are exactly the same is collapse them!

let addressBook = {

This crazy bit of sugar does something pretty strange -- it uses the NAME of the variable as the stringified key! In most circumstances and languages the name of a variable doesn't really matter to the running of the program. This sugary feature sort of breaks the 4th wall, reaching into the source code and lifting the specific variable name into the key (property) of the object.

Real World Example

In VueJS a component can use other components inside the template, but only if they are declared first. Here's a snippet extracted and summarized from the codebase:

    <SearchBar />
    <SearchResults />

// Importing alone does NOT register the components for use in the template
import SearchBar from "@/components/SearchBar.vue";
import SearchResults from "@/components/SearchResults.vue";

export default {
  components: { SearchBar, SearchResults }

Pretty slick. If you wanted to, you can give the components local-names (or I suppose register a single component with several names, weirdo).

components: { coolSearch: SearchBar, coolSearchResults: SearchResults }

Providing a "list" of components in VueJS is done by providing this object, which gives VueJS not only the component but also the NAME of the component, without VueJS needing to reach inside the component to ask it what its official name is.


I like to sprinkle console.log all over the place while exploring code. In addition to static strings, I often throw in the contents of variables. But generally I want to know the NAME of the variable, in addition to the content. So I used to do:

function addAddress(newAddress, otherStuff) {
  console.log("Adding newAddress:", newAddress, "otherStuff:", otherStuff);
  // ...

Using today's sugary shorthand, I now usually do this:

function addAddress(newAddress, otherStuff) {
  console.log("Adding", { newAddress, otherStuff });
  // ...

This will output something like:

  newAddress: { street: "...", zip: "..." },
  otherStuff: ...

You can see that the variable name is handily provided. Here when I had multiple variables I want to log it is even more handy.


Comments on TLT - 2020.06.21 - Sugary Sunday - Javascript Object Property Shorthand

1 Comment.

Any article with complete details about Javascript Object Property Shorthand?

-- couples therapist 2022-01-18 13:18 UTC

Add Comment

2020.04.26 What Even Is Firebase

We're using Firebase as the hosting service for and the experience has been kinda weird, coming from a more traditional server-database world.

First, I didn't even realize that Firebase was more than a cloud-JSON-blob! Our initial use of it was only for static asset hosting. This is a VueJS application that so far mostly lives in the browser, so static hosting is perfect. I generally use Github Pages for this purpose, but another team member had already set up Firebase for us.

Once I learned that it was even a thing, all was good. I wrapped the CLI that Firebase provides into yarn land, and now you can do yarn deploy and it'll build up the local assets and push them up. Works quite well! The auth is stored somewhere else on my computer. If a new dev wants to deploy, you add their google account to the Firebase project and presto!

We now have 3 devs on this project, and I'm starting to wonder about staging environments and such. As far as I can tell this isn't a thing in The Cloud, and instead we need to set up a separate project. I guess I'll do that eventually?

Our first user-serviceable data store was the almighty Google Sheets. You might not know this, but you can craft a URL to a public sheet and get down a very lovely CSV. When our app "boots" in the browser, we pull down this csv, parse it, turn it into a nice JSON tree that we stick into Vuex. If you edit the Google Sheet, the next app reload gets the new data. This is a disturbingly effective way to prototype. I grabbed a markdown rendering Vue component and ... now we have a SheetyCMS(tm) (haha).

As we look to expand the type of data we are storing and who can edit the data, I decided that we should switch over to the only thing I thought Firebase did in the first place, a hosted and magically live JSON "database". This is called the "Real Time Database", and for good reason -- all of the client libs know how to watch this thing for changes. In the VueJS one-way world, it goes Firebase -> Vuex -> component -> [edit-event] -> Firebase, and then wraps back around.

I built this admin tool to edit content, and now when you change the description text of something it updates every browser viewing it ... LIVE. Like, even as you type things. We went from having to do a lot of work to make things that live to now maybe having to create a "commit" button so that people can't see you typing and re-typing your text.

Things to discuss further:

  • Firebase Rules
  • Staging environments vs staging data
  • I wonder how much this is going to cost?
  • Firebase data migrations
  • Tracing the round trip of a text update

Comments on TLT - 2020.04.26 - What Even Is Firebase

1 Comment.

Finally! Someone discussed Firebase with us.

-- couples therapist 2022-01-19 15:49 UTC

Add Comment


META INFORMATION: This is the technical blog and wiki of Brock Wilcox (awwaiid). Entries focus on my current projects, interests, and sometimes life events. If you'd like you can check out the list of All Entries or the RSS Feed. I also have a LiveJournal syndication feed for LJ friends.


Blog Blog RSS Feed




Follow @awwaiid

Wiki Edits Wiki RSS Feed

... more changes