Skip to content

Latest commit

 

History

History
70 lines (50 loc) · 3.19 KB

DESIGN.md

File metadata and controls

70 lines (50 loc) · 3.19 KB
Raw

Design of Pachinko

Pachinko started a very long time (and several names) ago as a system for organizing my filing cabinet.

History

I was sick and tired of coming up with ways to organize my files. Everyone who's tried to keep important papers around has run into something like the following:

  • "Okay, I have my 'College' folder for school stuff. My student loan stuff goes in there."
  • "My W-2s from last year can go in the '2019 Taxes' folder."
  • "... now I have a document showing that I paid tuition last year, which I need to keep for this deduction... does it go in the 'Taxes' or 'College' folder?"

Librarians have struggled for centuries to come up with a Perfect Information Hierarchy and they're still arguing about it. I know I'm not going to be the genius that cracks the code. Worse, it's utterly unnecessary.

Two things really matter for important stuff:

  • I know roughly where it is.
  • Whatever folder it's in shouldn't be so full that I can't dig it out.

The exact hierarchy it's in doesn't matter. If I just had a set of numbered folders, spread everything evenly between them, and wrote down where everything ended up, all would be well.

A computer can do all of this in its sleep.

Dead Ends

I tried several different UXs and UIs for this before getting to Pachinko:

Content-addressed CLI

The first version used a content-addressed hash identifier for each item. The hope was that the organization could be rebuilt if the database was lost. This system had some issues:

  • It was too hard to come up with a hashing scheme that wasn't sensitive to word order or spelling.
  • The first digit of the resulting hash was used to pick a folder. This meant that folder assignment was effectively random and meant some folders were left uselessly empty.
  • The hex IDs were unwieldy. I tried several pronounceable-hash systems before giving up.

Web UI

The second version was a web UI with two big changes:

  • The content-aware hashes were completely abandoned. Picking items with a UI meant that their ID wasn't all that important.
  • Items' size was recorded and new items were assigned a bin based on how full each bin was.

This was far more effective and worked well for both paper in filing cabinet and random junk in a set of boxes.

I only abandoned this version because maintaining a webapp is a grueling treadmill. I also didn't want to implement authentication. I refuse to deal with oAuth without a paycheck involved.

Needs

Pachinko, the third version of this concept, had a few goals:

  • Be a CLI. Web UIs have a ton of advantages, but I don't have the spare time to keep my nose to the webpack/React/Flux/Immer/Express/GraphQL/etc. grindstone anymore.
  • As a CLI, be built in Rust. Most of my previous CLIs had been written in Python. I love Python deeply, but its startup delay is super painful for a non-interactive CLI. Plus I really wanted to learn Rust.
  • Be an early adopter of my SQlite-based document store, Qualia. Qualia began as a metadata-based tracker for computer files and its store ended up being the most interesting piece.

Besides that, it should address these needs:

  • Keep track of my possessions, for renters insurance.