-- Leo's gemini proxy
-- Connecting to alpha.lyk.so:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
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:
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 $'\t'
The script for launching fzf to search my inventory and use the pretty-printing script for the preview pane:
#!/bin/sh
set -e
ls ~/intramuros/documents/inventory/*.tsv \
| xargs -I{} tail -n+2 "{}" \
| fzf --reverse -e -i --preview="format-inventory-entry {}" --preview-window="33%"
The line in my ~/.config/sway/config file which invokes the script when I hit $mod+i:
bindsym $mod+i exec footclient --title cli-popup -W 156x24 ~/intramuros/scripts/explore-inventory
If any of the bins contain items I access frequently, I make a note on the bin itself indicating the frequently-accessed contents. This saves me from having to refer to my spreadsheets most of the time, at the expense of having to update the note if I ever change the location of the item in storage. I don't know if this system would be usable at all if not for this optimization, as I find myself referring to these notes several times a day.
Finally, I stack my field boxes one deep and at most two high on a shelving unit that formerly held now-binned items. This keeps access time low, which I hope will keep the system convenient enough for me to continue using it. I already find the shelves where I have to pull out *two* bins to get to one somewhat irritating, so I am fairly sure that greater density of bins would not work for me.
I have my big plastic "bins" stacked two high in my closet. Some of these are pretty heavy, and Bin 1 and Bin 2 are not accessible without moving Bin 3 and Bin 4 first, but I have only had to access these larger bins once in the past week, so I'm hopeful that this will work for me.
Not everything has been catalogued yet, and I've stopped cataloguing for the time being, but fortunately this system is still quite useful even when only partially implemented.
Sort out "must have" items into their own bins and mark these as such. This will allow for rapid packing and leaving in case of disaster.
Try lightweight methods of accessing the spreadsheets to lower the friction of returning forgotten items to their bins. (Might have to use paper.)
-- Response ended
-- Page fetched on Fri May 3 05:21:52 2024