# 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

It remains one of the best-looking Ultrabooks around.

-- backyard cottage builders seattle 2021-05-27 07:40 UTC

What you're saying is completely true. I know that everybody must say the same thing, but I just think that you put it in a way that everyone can understand.

-- service entretien arbres 2021-08-04 10:36 UTC

It looks great and they have improves the ergonomics for this laptop. Very nice for students and professionals.

-- roofing company apollo beach 2021-08-10 14:37 UTC

Take your time to think about what approach works best for you. Good luck!

-- www.roofbaltimore.com 2021-08-13 23:43 UTC

Hello, I'm from toca boca life page, I'm definitely going to bookmark your blog, I just love your post, thanks for such a nice sharing..Hope to get some info on your blog in future

-- toca boca life free 2021-08-18 07:59 UTC

The comments are pretty insightful post. Never thought that it was this simple after all. I had spent a good deal of my time looking for someone to explain this subject clearly and youâre the only one that ever did that. Keep it up.

I find this post very interesting to read. I just check out the site and I am very excited to read more.

-- Minneapolis Mold Removal Services 2021-08-25 04:11 UTC

Definitely one of the best for me!

-- atlanta wedding photographer 2021-08-26 10:30 UTC

Love what Im seeing here!

-- Anonymous 2021-08-26 10:30 UTC

Good job people!

-- lime pellets for lawn 2021-08-26 10:31 UTC

Continue what you do! Good job.

-- concrete contractors greenville sc 2021-08-26 10:32 UTC

I have perused a couple of the articles on your site now, and I truly like your way of contributing to a blog. I added it to my top choices site list and will inquire soon. If it's not too much trouble, look at my site also and let me know your opinion.

-- jackson french drain 2021-08-30 08:18 UTC

Great post! Glad to know this wonderful content, totally thumbs up!

-- Ryan Leonard 2021-08-30 13:13 UTC

Some really nice and useful info on this web site, also I conceive the design and style holds good features.

-- Best Roofers in Huntsville 2021-08-30 13:26 UTC

Thanks for sharing this great information. Glad to see this post.

-- kitchen renovation sandy springs ga 2021-08-31 13:02 UTC

Very interesting post you shared.

-- SAM gov search 2021-09-02 13:21 UTC

I need to say that your article is incredible. Continue to do what makes you happy.rnI am particularly stunned with this huge information.

-- minor lanscaping 2021-09-07 05:40 UTC

# 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:

HELLO

--

WORLD

--

of

-- [kittens.jpg] [fit]

kittens

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)),
)(input)?;

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

Wow, I actually had to bookmark a site! this is a first. Keep it up

-- AdVenture Capitalist by Kongregate 2021-08-18 02:49 UTC

If it's not too much trouble, let me know whether you're searching for a creator for your site. You have some extraordinary posts, and I figure I would be a decent resource. In the event that you at any point need to take a portion of the heap off, I'd prefer to think of some material for your blog in return for a connection back to mine. If it's not too much trouble, give me an email whenever intrigued. Much obliged.

-- free on emulatorpc.com 2021-08-18 02:52 UTC

I really love this wonderful post! Keep it up!

-- Ryan Leonard 2021-08-30 13:16 UTC

-- Columbusgatreeremoval.com 2021-09-09 05:13 UTC

# 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 es6-features.org.

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"
};

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 = {
doug
};

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 covidcanidoit.com codebase:

<template>
<div>
<SearchBar />
<SearchResults />
</div>
</template>

<script>
// 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 }
};
</script>

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.

## BONUS

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) {
// ...
}

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

function addAddress(newAddress, otherStuff) {
// ...
}

This will output something like:

Adding
{
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.

DELICIOUS!

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

For those who are not familiar with the term, Javascript is a high-level scripting and programming language. With it you can edit content and control various forms of multimedia ranging from images to animations.

-- these free fps games on PC 2021-08-18 07:15 UTC

You will require a good knowledge of programming, variables, strings and correct orders to essentially crack it and program websites the way you want.

-- pixel gun 3d play now 2021-08-18 07:16 UTC

This is interesting! I'm exciting to know this updates!

Ryan for https://www.kentremodeling.net/

-- Ryan Leonard 2021-08-30 13:19 UTC

# 2020.04.26 What Even Is Firebase

We're using Firebase as the hosting service for https://covidcanidoit.com 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.

interesting discussion! keep us updated!

-- Ryan Leonard 2021-08-30 13:20 UTC

Cool things I saw on the internet at some point:

Great idea! I must try this!

Ryan for https://www.stpaulasphalt.com/

-- Ryan Leonard 2021-08-30 13:21 UTC

Thanks for sharing this.

-- Roofing Companies in Northern Kentucky 2021-08-30 23:33 UTC

This is crucial to the SEO strategies for the company. Thank you so much! :)

-- SEO Tampa 2021-08-31 02:08 UTC

Great write-up, I am a big believer in commenting on blogs to inform the blog writers know that theyÃÂ¢ÃÂÃÂve added something worthwhile to the world wide web!..

-- All-Terrain Electric Wheelchair 2021-09-16 10:56 UTC

More...

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.