Programming

STILL GOT IT

Yesterday, after a long day of my day job, in which I spend all of my time either hacking in Typescript and React or doing a lot of dev-ops, I decided that I was finally gonna sit down and write a little Rust. I picked a project off my stack: "Rewrite the Unix locate program in Rust." The last time I had tried this, my brain didn't work at all.

Web development

HTML TEMPLATES: NOT A NEW IDEA, DEFINITELY FASTER THAN ROLLING YOUR OWN

About fifteen years ago at a startup, I built a very data-heavy single page app for biologists to manage a map/reduce version of a gene sequencing engine, and because it was data heavy, it made use of templates to render much of the HTML. If you've ever been in this situation, you reach for a library.

With HTML Templates, you might not need a library. But I suspect you're going to want one.

Programming

YOUR COMPANY NEEDS ONLY FIVE PROGRAMMING LANGUAGES, NO MORE, NO LESS

If you've worked in this business for a long time, you've definitely encountered that mid-size company where every team has their own favorite language. And while this might work for awhile, it's a long-term disaster waiting to happen within your company. Eventually, every company that grows to a certain size and survives realizes that you need to clamp down and have at most four computer languages allowed inside your build process.

Here are the four languages:

Personal

MY PROCESS: NEVER USE PIDGIN IN TO-DOS.

Like most people, you probably write your to-dos in a shorthand way. I do, and most people do it as well. You know, this sort of thing, a one-day list I made for my latest project (which, ironically, includes a To-Do list manager). And along the way, I've discovered that I should never used shorthand or pidgin in my to-dos.

Full stack

WHAT 'FULL STACK' MEANS TO ME

Chris Coyier has an article called The Widening Responsibility of Front-End Developers and what I find most interesting about the article is how it skates over one of the most critical issue in web development since the release of Backbone.js: the emergence of data-driven websites. In the same way that a travel magazine, a cooking magazine, and a copy of the an annual farm report are different, so there are lots of different kinds of web development: the first is light and fluffy and needs no data; the second has some important data needs, especially if you allow for things like ingredient substitution, modifying serving counts, and nutritional information; the last is incredibly data-driven, being almost nothing but tables and charts.

Project

NOTESMACHINE: TWO CENTRAL OPERATIONS

As I've been working on my own little Zettelkasten engine, I've realized that there are exactly two operations that matter more than any other. The client will handle many of the details of showing notes and note collections (called "boxes", since Zettelkasten literally means "note box"), but the server needs to do exactly two things exactly right every time:

• ingest a note
• return a box when requested

Regular expressions

READING A PAPER: DERIVATIVES OF REGULAR EXPRESSIONS RE-EXAMINED

Reading paper in computer science is itself an important skill, one you should master. I've detailed some of my problems before in my series on A Play On Regular Expressions, and now that I have a little free time on my hand I'm going to dive into some of the issues that I want to cover in the future.

A MOMENT OF JOB SEARCH MELANCHOLY

I'm finishing my third week of looking for work, following the COVID 19-related layoffs at BigFish Games, and I'm coming to a very depressing conclusion: there aren't that many interesting new worlds to conquer.

THE TRANSFORMATION PRIORITY PREMISE AND FUNCTIONAL LANGUAGES

I know I've commented before on how, while Clean Code has its place, there are adherents who adhere to it so literally and unthinkingly that they've constrained their careers and condemned themselves to the same silos for the rest of their professional lives.

NOTESMACHINE: THE LAYOUT PROBLEM

As I'm building out the design and model of Scarlett (which seems dangerously likely to get renamed 'Notesmachine' at the rate I'm going), I've hit one of those architectural things that annoys me. Allow me to ruminate on the problem.

As mentioned in the previous post, the traditional organization of any notes system is that of the Forest; each Box contains notes, some of which are the roots of trees, and the rest of which are nodes of the tree leading to leaves, which are notes that have no descendant notes.

On the other hand, I have interests that are orthogonal to that design. Let's take them in order:

A WILD INSIGHT INTO MY CAREER

There's a difference between "What you do" and "What you really do."

An I mentioned earlier, I'm looking for work. Given that I'm not working, and doing the looking only takes half the day, I'm spending the other half of the day diving back into Rust. Those two events came together in a conversation I had today with a "career coach" in an unexpected way.

My career coach loves my elevator pitch:

NOTESMACHINE: ARCHITECTURAL DESIGN RECORD

If you're like me, you have more than one hard-drive full of random stuff: notes, PDF files, Epub files, ZIP and TAR files, GIT repositories of (mostly incomplete) projects, and so on and so forth. Also, if you're like me, these projects devolve into a bunch of different areas: my professional life, my artistic and creative life, my open-source footprint, my personal life like my kids and my wife, the infrastructure of my life like the current projects in home maintenance, and in my case an imperial buttload of recipes.

My Rust has gotten rusty, so to speak, so I've decided to try and write something to help me manage it. This post is mostly me rambling about what I'm going to write, gods help us all, and how I want to manage writing it.

Basically, I want a knowledge base. That's it. That's the simplest thing possible. In fact, pretty much what I want is some kind of Roam clone, but one with extra superpowers.

I'm going to use a term that doesn't exist in the real world: "egotonin." Egotonin is a mythical substance that gets used when you're exerting willpower; it is the thing that is depleted in the concept of ego depletion.

So lets talk about Knowledge Bases.

System administration

ORGANIZING YOUR BASH PATH

If you've ever looked at your .bashrc file and wondered how the heck it got so weirdly out of control, look no further than the slow migration of "local changes" to the .local folder, and the number of language– or framework-specific environments that are now kept there.

There's much to recommend this move, not the least of which is decluttering the $HOME directory. But my biggest pet peeve was the $PATH variable, which seemed to just grow and grow in my .bashrc file into an unreadable string. I've decided to fix that. Here's how.

Personal

HOMEWORK ASSIGNMENT: WHAT I LEARNED

I just finished one of those take-home programming assignments that companies are sending out these days in lieu of whiteboarding exercises, a process that I'm genuinely thankful for. Whiteboarding is just a way to stress someone out; it doesn't prove anything (except excessive cleverness, sometimes). We work with a fully immersive IDE (even if Emacs is still making itself difficult in that regard), we work with StackOverflow available, and we work surrounded by books, notes, and cheatsheets. We even work with our fellow workers on the other end of Slack and Zoom.

A lot of what I did was "re-learning," but it's always good to go over it again, just in case. Here's a lot of what I absorbed:

Personal

A NEW LOOK FOR A NEW PHASE

You may have noticed a few changes in the place. I've gone to an all-static engine. I chose Zola, because although it wasn't sufficient for what I wanted out of my story site, it's perfectly fine here.

Rust

WORKING ON SCARLETT 2.0, AND THE SQL IS FUN!

I’ve been hacking on a secret project that I’ve had in the works since, oh grief, the first check-in was:

<code>commit ccb93ca5f2b256babfa0f2ef9110ac0ac4019527
Author: Elf M. Sternberg <elf.sternberg@gmail.com>
Date:   Mon Feb 4 23:03:01 2013 -0800

Initial check-in for Scarlett.</code>

The original project (yes, it’s named “scarlett”, deal with it) was in a combination of Python and Javascript, with Backbone as the front-end. It was, quite frankly, a terrible project, but it did what I wanted it to: it kept track of my notes. I have a directory named “Wiki” into which I dump markdown files, and have for years, and all it does is give me a slightly better UI for ‘grep,’ but it’s better than nothing.

IF YOU CAN SPOT THE LEAK IN AN ABSTRACTION, YOU CAN DESIGN ALMOST ANY PROGRAM

I’m going to use the word “abstraction” in two different ways, but bear with me for a moment and consider this:

  1. Every startup is based on an insightful abstraction of a complex idea.
  2. Every software abstraction is leaky in some critical way.

Uber is an abstraction of taxis. How do we abstract “what a taxi is” using the higher-level technologies we have now? Amazon is an abstraction of mail-order sales, which have been around since Sears pioneered them in 1897. Google is an abstraction of card catalogs and yellow pages. And so forth.

In programming, an abstraction is a higher-level description of a process or mechanism that is designed to hide some level of complexity behind a simple set of controls. The menu on a word processor hides the complexity of the software behind it. The API we use to “log in with Facebook” or “log in with Google” hides the complexity of securing your authorization across multiple websites and applications while revealing your identity to advertisers.

Design

IS AGILE COMPATIBLE WITH CLEAN CODE?

I’ve been through Agile training several times before at different jobs, and the current job is no different. June is Agile Training Month, and since I started last September I’m obliged to go through this again. Previously, we had a Clean Code Training period that lasted two months, and I realized today why I’m having such a hard time with the Clean Code part of the training.

The Agile process says that the product should have value to the customer at the end of the first month, and that the value to the customer grows as the development team puts more intellectual work into building out its functionality.

Programming

REVIEW: CLEAN CODE, BY ROBERT MARTIN

It might seem like I’ve been harsh on Robert Martin’s Clean Code for the past couple of posts, and that’s valid. I have been. It’s such a good book, full of strong advice on any number of topics.

It’s just that it feels old. Programming is a young discipline in the world, probably one of the youngest, and one of the most consequential. It changes with absurd speed, and everyone in it struggles to keep up. Clean Code came out in 2006 and already there are dusty corners within that feel out of date, even irresponsible.

Engineering notebook

IF YOU'RE A SENIOR DEVELOPER, YOU HAVE TO ACCEPT SOME WET CODE.

In some programming languages there is an essential, powerful tension between two common pieces of advice: Don’t Repeat Yourself and Meaningful Names over Code Comments. Both are really good pieces of advice.

“Don’t Repeat Yourself” (DRY) means that if you can find an abstraction that allows you to avoid repetition in your code, you can remove the need to debug multiple code blocks if you find an error, and you can test the abstraction more reliably and more efficiently. The opposite of DRY is, of course, WET, “Written-out Every Time.”

“Meaningful Names over Code Comments” means that if you have strong, descriptive names for classes, functions, and variables, then code comments are often not merely unnecessary but possibly harmful as they drift out-of-date with the actual content of the code.

At my ${DAY_JOB}, I ran into this conflict in a big way. This example is in Python, but it applies to any language with metalanguage capabilities, which includes Ruby, Lisp, Rust, and even C++.