💾 Archived View for lyk.so › systems › bins captured on 2024-05-10 at 10:24:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Updated 2022-07-23
I've got a bunch of field boxes marked in ascending order: "Box 1," "Box 2," etc. using liquid chalk markers. These are stackable, plastic, water-resistant boxes with hinged, locking lids, often used for storing ammunition or other moisture-sensitive items. The dimensions of mine are 292x143x184mm, or 11.5x5.625x7.25in. This has been a good size for me. The bigger the box, the more digging you'll have to do to find what you're looking for in it. Field boxes are not especially cheap, however, and I would recommend something more affordable for most people, especially if environmental moisture is not of particular concern. My own use of field boxes comes largely from having used them before to keep shredded post-consumer plastic stock dry during my experimentation phase with DIY plastic recycling. I see a 25 pack of 279x152x152mm, or 11x6x6in, corrugated carboard boxes sells at around the same price as two and a half field boxes. In hindsight it may have been better for me to have disregarded my existing stock of field boxes and used those instead.
I also have some larger, stackable plastic boxes marked likewise with permanent black marker: "Bin 1," "Bin 2," etc. These I reserve for anything too big to fit in a field box. I mark these as "bins" in order to cut down on the time it takes to locate the correct container for an item. (To maximize confusion, I also use "bin" as a generic term to refer to all the containers in this system. Assume all instances of "bin" here are meant in this generic sense unless it's clear, due to context, that I mean these larger plastic "bins" specifically.)
I have a hardshell case with foam cutouts for protecting some of my more sensitive instruments. Marked "Case 1" in anticipation of maybe needing more such cases someday.
I mark items with an identifier written on a bit of tape or directly, if the item is large enough. I put items that are too small to mark in small bags and mark the bag instead. Identifiers are unique to type of item and include the category of item as a leading character. E.g., I have six 300mm micro-USB cables with the identifier "C5." "C" indicates the "cables" category, and "5" simply indicates it was the fifth item entered in that category.
Each category has its own TSV file, which allows me to add or remove category-specific fields. For example, "Cables.tsv" has a "Length" field. The first line of that file looks like this:
ID Type Length Description Condition Project/Use Quantity In Use Available Location Notes
This may be more information than necessary ("In Use" and "Available" seem questionable), so I reserve the right to remove fields that prove more trouble to maintain than they are worth. "Notes" has been useful for noting *what* the missing "In Use" items are being used for and where they might be found, as well as for keeping brief descriptions of next steps to be taken on the associated project. I've also used this field to include additional match strings for grep when I notice myself searching for something using alternate spellings or names. E.g., "white-out" versus "white out" versus "whiteout" versus "correction fluid."
Until July 2022, I had been using a command-line utility to make entries:
sc-im, a vim-like spreadsheet editor for the command line
The goal here, as ever, was to minimize the time between me deciding to make an entry and me being able to make an entry. Any lag whatsoever in a process tends to quickly sap my energy. (I find many web apps, mobile apps, and Electron-based apps mostly unusable because of this.)
Unfortunately I kept running into bugs in sc-im. I had to remember to escape quotation marks and to keep commas out of my values because these tended to trigger sc-im's bugs. Rows lost columns sometimes, which meant losing the entered value. Sometimes this rendered an item's entry almost useless. So I wrote a simple bash script, shown below, to allow adding entries to any of my inventory TSVs. Eventually I would like to create an interactive, TUI-based version of this:
#!/usr/bin/env bash
set -e
[ "$1" ] || { >&2 echo "usage: $0 <tsv file>"; exit 1; }
[ -f "$1" ] || { >&2 echo "no such file: $1"; exit 1; }
prefix="$(tail -n1 "$1" | cut -f1 | grep -o "[A-Z ]\+")"
last_id="$(tail -n1 "$1" | cut -f1 | grep -o "[0-9]\+")"
next_id="$(expr "$last_id" + 1)"
new_line="$prefix$next_id"
while read -u 3 heading; do
if [ "$heading" = "ID" ]; then
printf "%s: %s\n" "$heading" "$prefix$next_id"
else
printf "%s: " "$heading"
read value
new_line="$(printf "$new_line\t$value")"
fi
done 3< <(head -n1 "$1" | tr '\t' '\n')
echo "$new_line" >> "$1"
Until the end of December 2021, I'd been looking up items in my inventory using grep. To further decrease lookup lag, I installed fzf, wrote a script for pretty-printing inventory entries, connected the two up with another script, and assigned the script a hotkey in sway.
The pretty-printing script:
#!/bin/bash
set -e
[ "$1" ] || { >&2 echo "usage: $0 <inventory ID>"; exit 1; }
# A bit brittle, but...
id="$(echo "$1" | cut -f1)"
match="$(grep -m1 -r "^$id" ~/intramuros/documents/inventory)"
file="$(echo "$match" | cut -d: -f1)"
line="$(echo "$match" | cut -d: -f2)"
fields="$(head -n1 "$file")"
i=1
field="$(echo "$fields" | cut -f$i)"
while [ "$field" ]; do
value="$(echo "$line" | cut -f$i)"
printf "%s:\t%s\n" "$field" "$value"
i="$(expr "$i" + 1)"
field="$(echo "$fields" | cut -f$i)"
done \
| column -t -s