DEV Community: Steven G. Harms

Madeline Miller's Circe: Describing the sorcery of programming

Steven G. Harms — Sun, 12 Jan 2020 01:57:45 +0000

I've spent the better part of a decade teaching people to code and one of the hardest questions I've encountered is "What's it like when you're doing it right?" What's it like to know that this class is too big? What's it like to not be sure you can learn a new framework "in time?" What's it like when you find the thing you needed, but which had eluded you, had been discovered a generation ago, but was forgotten, lain silent and fallow in a far off land?

A great source for these metaphors is literature; the humanities. Far too often downplayed if not outright scoffed by the pedagogy and disciples of the Computer Science mainstream, fiction can provide us the metaphors of the shape of the feeling that most aptly applies. I found a number of wonderful passages about creating in Madeline Miller's examination of the Odyssey / Minoan Myths, Circe (full review here).

Circe is a sorceress and her language for describing her craft rang exceedingly familiar to me for my own. Here are some metaphors that might serve you well too. Do a quick s/(witchcraft|sorcery)/programming/g and you'll be surprised by how many of the quotes still apply.

Let me say what sorcery is not: it is not divine power, which comes with a thought and a blink. It must be made and worked, planned and searched out, dug up, dried, chopped and ground, cooked, spoken over, and sung. Even after all that, it can fail, as gods do not. If my herbs are not fresh enough, if my attention falters, if my will is weak, the draughts go stale and rancid in my hands (p. 83).

Witchcraft is nothing but such drudgery (p. 84).

Day upon patient day, you must throw out your errors and being again. So why did I not mind? Why did none of us mind (p. 84)?

Then I learned that I could bend the world to my will, as a bow is bet for an arrow. I would have done that toil a thousand times to keep such power in my hands. I thought: this is how Zeus felt when he first lifted the thunderbolt (p. 84).

Each spell was a mountain to be climbed anew. All I could carry with me from last time was the knowledge that it could be done (p. 85).

I would like the whole business of it [loom-weaving], the simplicity and skill at once, the smell of the wood, the shush of the shuttle, the satisfying way weft stacked upon weft. It was a little like spell-work, I thought for your hands must be busy, and your mind sharp and free (p. 155).

Of course not, he said, it has been hidden in the foundation, but look, there it is, plain as day. See the cracked beam? See the beetles eating the floor? See how the stone is sinking into the swamp?...When there is rot in the walls, there is only one remedy...Tear down, I thought. Tear down and build again (p. 192).

Every creator knows these metaphors. I hope they provide you a sense of equanimity when considering where you and your code, your spells, fit within the great narrative of creating. Worse comes to worse, they're some great email signature quotes. :)

Automating Development With Tasks in VSCode

Steven G. Harms — Thu, 09 Jan 2020 15:53:31 +0000

Originally published: https://stevengharms.com/posts/2020-01-08-automating-development-with-tasks-in-vscode/

A great feature that ships with VSCode is the "tasks" capability. I've not seen many developers use it, so I thought I'd document how it's made my life blogging with a statically-generated site simpler.

Often, when doing any development, developers find themselves performing certain loops: drop to shell, run some command, capture output, paste output back into the editor, etc. Eventually most developers wind up curating a per-project set of shell aliases and functions to accelerate that loop. Perhaps the high-water mark for this behavior is the Rails framework which came with a task runner, rake, by default.

I'm glad to say that VSCode has a built-in task runner facility that can be leveraged to make whole series of routine tasks much more pleasant.

Getting Set Up

We define tasks in a file called project_home/.vscode/tasks.json. Think of each task as a "function" or a "method" in a programming language. It should do one shell operation. Much like functional programming, these small tasks can be composed together to create macro-level tasks.

Here's one of my tasks:

    {
      "label": "Publish to BLOG SITE",
      "type": "shell",
      "command": "rsync -azrP ${workspaceFolder}/public/ HOST:/web/server/directory",
      "dependsOrder": "sequence",
      "dependsOn":["Push Images to servers", "Hugo Build"],
      "problemMatcher": []
    }

Start with the dependsOn. When I run this task (which is available through VSCode's Command-Shift-P menu), it first runs the tasks "Push Images to servers" and "Hugo Build". The first synchronizes local assets I used to the production host, the second runs the static site generator and emits the processed site to ${workspaceFolder}/public. Then this task's "command" runs and uses rsync to send the completed web page content to the HOST. That's it! The dependencies are run in order because of the "dependsOrder" attribute being set to "sequence".

If I later decide to update the piece, no problem, simply run the command again. By allowing me to stay in the editor I don't have to do the context switch out to make the content go live.

Guide to Developing Chrome Context-Menu Applications

Steven G. Harms — Wed, 04 Oct 2017 14:47:09 +0000

Introduction

I recently shipped the amaJSON Chrome extension and I believe I've come up with an improved process for understanding how to build similar applications.

This tutorial will help you create a practical "context-menu" Event Page extension.

With Extensions, Google has delivered (yet) another astounding technical platform with superior reference documentation. Nevertheless this documentation leaves delivery practices beyond a trivial proof of concept hard to determine or worse leaves the guidance to — "look at these examples." This guide fills in any gaps and attempts to move step-by-step.

For beginners to programming there's also a meta-lesson in this post: how to approach programming to someone else's API. I'll describe my research methods and approach throughout the technical tutorial.

Background

JavaScript The reader is assumed to have proficiency with JavaScript and to have facility with core features / issues associated with the language particularly closures, callbacks, enclosed variables, and functions as first-class data. This tutorial will provide you opportunities to "put it on pause" and go learn about these concepts as well. So for those learning them, it provides practical applications.

Reading diff Output; git familiarity

Throughout this tutorial I'll post code as diffs or make passing reference to core git ideas ("branching" or "commits"). The ability to read a diff is quite important so you can see what was removed and added. Knowledge of git, while not strictly necessary to benefitting from this post will help contextualize the "steps" and, hopefully, cast light on good developer practice (or, at the very least, my practice!).

Code created in this tutorial can be found in the GitHub repository.

Please report bugs / issues / "didn't work for me" there.