BLOG POSTS

STILL GOT IT

S

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.

Continue Reading

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

H

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.

Continue Reading

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

Y

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.

Four languages is the minimum every company needs, because every company needs the following:

  • A shell language for builds and runbooks
  • A script language for rapid development cycles and low-performance
  • A compiled language for performance and long-term deployment
  • A front-end language for user interfaces.

You need to decide up front which of these you're going to use, and stick with them. The reason is simple: if you limit the languages that are in use in your company's software projects, no project will be a mystery to anyone else. No one will have to deal with "Microservice X is failing, but only three people know how to fix it" problem. By restricting the list of languages your company uses, you guarantee portability of skills across the enterprise, and you provide a safety margin in case one of your core developers gets hit by a bus.

Continue Reading

WHAT FULLSTACK MEANS TO ME

W

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.

Continue Reading

NOTESMACHINE: TWO CENTRAL OPERATIONS

N

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
Continue Reading

READING A PAPER: DERIVATIVES OF REGULAR EXPRESSIONS RE-EXAMINED

R

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.

My Regular Expressions series talked mostly about two different papers: Fischer, Huch and Wilke's A Play on Regular Expressions, and Matt Might's Parsing with Derivatives. One isn't about Brzozowski's derivatives at all; it's about identifying a common mathematical principle by which the boolean yes/no Finite State Automata of the classic Kleene Algebra can be tranformed into a Finite State Transducer by abstracting "up one level" what the automata does. The second describes a long-neglected algorithm for solving the Kleene Algebra that promises some interesting characteristics. My contribution was to show that these papers are compatible— that Might's combinators are actually semirings in disguise— and that Brzozowski's algorithm can be expressed in a systems language with strict memory requirements.

But that's not where the story starts. The story starts with two other papers, one of which I'll be reviewing today. The first paper is Joshua Goodman's 1999 paper, "Semiring Parsing," which I'll be addressing later.

Today's paper is

Regular Expression Derivatives Re-Examined

... by Scott Owens, John Reppy, and Aaron Turon.

Continue Reading

THE TRANSFORMATION PRIORITY PREMISE AND FUNCTIONAL LANUGAGES

T

Alice laughed. "There's no use trying," she said. "One can't believe impossible things."

"I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."

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.

Continue Reading

NOTESMACHINE: THE LAYOUT PROBLEM

N

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:

Continue Reading

A WILD INSIGHT INTO MY CAREER

A

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:

I have a very broad range of experiences, but what I do comes down to this: using industry standard application servers like Django and Swagger for the back-end and familiar tools like React or Backbone for the front-end, I build user interfaces for complex business process that make them easy to understand and a pleasure to use.

Continue Reading

NOTESMACHINE: ARCHITECTURAL DESIGN RECORD

N

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.

Continue Reading

ORGANIZING YOUR BASH PATH

O

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.

Continue Reading

HOMEWORK ASSIGNMENT: WHAT I LEARNED

H

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:

Continue Reading

A NEW LOOK FOR A NEW PHASE

A

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.

Continue Reading

WORKING ON SCARLETT 2.0, AND THE SQL IS FUN!

W

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.

Continue Reading

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

I

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.

Continue Reading

IS AGILE COMPATIBLE WITH CLEAN CODE?

I

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.

Continue Reading

REVIEW: CLEAN CODE, BY ROBERT MARTIN

R

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.

Continue Reading

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

I

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++.

Continue Reading