Clojurians Log v2

Men det var heeelt ufyselig og umulig å lese med «transparent» mode eller hva det nå heter.

Jøss, hvordan gjorde du det?

Det var veldig skjult! Skal se om jeg kan lage en screen recording for å vise deg...

Slik!

Når man gjør "long press" på et tomt område på skjermen, kommer det opp en "Edit" kanpp øverst til venstre på skjermen. Trykk på den, så "Customize" i menyen som popper opp.

Hvis man velger "Default" så får man tilbake farger og et utseende som ligner mer på det gamle.

Se der

Jeg hadde allerede default på 🥺

Megatrist uten farger da.

Oh! Så rart. Kanskje "Default" er enda en setting et eller annet sted da.

hmm, ikke dumt. Særlig med Omarchy så trenger jeg et sted å ta vare på "mine ekstra greier" siden hele OS-et er basert på dotfiles

Jeg har også alle mine i et Git-repo. Det er helt uvurderlig for å prøve nye ting, hvis jeg konfigurerer noe feil, vet jeg med sikkerhet hva jeg hadde før!

har du noe opplegg for å symlinke ting til riktig sted?

eller er hele $HOME et git-repo med en saftig gitignore?

Jeg synes alt dette funker i teorien, men det er altfor mye mekk hvis jeg bare trenger å legge til et directory på $PATH (som et dårlig eksempel). Mulig at GNU Stow løser dette elegant…

Og, jeg har stort sett en maskin av gangen, så det å skulle holde flere maskiner i synk er ikke en greie.

repoet jeg "tar med overalt" har både dotfiler, notater og små programmer. Jeg kloner det inn i /home/teodorlu/kb eller /Users/teodorlu/kb. Inni kb kan jeg kjøre ./configure for å "skru på" symlinks. Configure hos meg er et vanlig shell script, og starter med dette:

#!/bin/bash

set -e

# Find setup folder in project
DIR=$(cd "$(dirname "$0")" && echo "$(git rev-parse --show-toplevel)/setup")
DOTFILES=$(cd "$(dirname "$0")" && echo "$(git rev-parse --show-toplevel)/dotfiles")

# Ensure that ~/.local/bin exists
mkdir -p ~/.local/bin

# i3 + sway config
mkdir -p ~/.config/i3
mkdir -p ~/.config/kanshi/
mkdir -p ~/.config/sway
mkdir -p ~/.config/waybar/
ln -sf "${DIR}/HOME/.config/i3/config" ~/.config/i3/config
ln -sf "${DIR}/HOME/.config/kanshi/config" ~/.config/kanshi/config
ln -sf "${DIR}/HOME/.config/sway/config" ~/.config/sway/config
ln -sf "${DIR}/HOME/.config/waybar/config" ~/.config/waybar/config
ln -sf "${DIR}/HOME/.config/waybar/style.css" ~/.config/waybar/style.css

Problemet til Erik blir ikke et problem for meg, fordi mapper kan symlinkes.

Hvorfor ikke? Hvis du endrer på en av dine dingser, må du vel commit’e det og få det opp på github?

Jo, jeg må committe. Trodde du mente å legge individuelle filer. Jeg anser det som en fordel — jeg får se det tydelig når jeg har endret en config-fil.

meh, har andre ting å gjøre 🙂

Jeg bruker chezmoi til samme formål. Virker for øyeblikket litt overkill, men jeg har flere maskiner og en stasjonær != en laptop, så en vakker dag vil jeg nok bruke templatingen der på en eller annen måte.

Personlig veldig fan av dette for backup da. Ha en vårrengjøring hvert år og det holder seg oppdatert med det du trenger osv.

Nå gjenstår det bare å skrive enda en dotfile manager i Clojure (https://github.com/babashka/babashka/wiki/Self-contained-executable#uberjar?) som kan legges til på https://www.chezmoi.io/comparison-table/ 😅 "NIH syndrome" for the win.

Ser at GNU Stow heller ikke er med i sammenligningen der.

Jag använder samma setup för dotfiles tillsammans med https://github.com/nix-darwin/nix-darwin (jobbar tyvärr på en Mac just nu). Så en sprillans dator installeras enkelt med

1. Install nix-darwin + git
2. git clone my-nix-darwin-repo
3. git clone my-dotfiles-repo
4. cd my-dotfiles-repo && stow -t ~ -S *
5. sudo darwin-rebuild switch

> "NIH syndrome" for the win. 😂

Intensjon er best!

har folk en favoritt-oppskrift til commit-meldinger? Kan/bør det finnes? One size fits all, oppskrift avhenger av kontekst?

Tror "fang intensjonen" er det beste vi har. Vi bruker det også litt til å fortelle hverandre om ting vi har oppdaget / lært.

Jeg tok tak i en commit-melding nå på mandag. Den sa noe ala "endre dette i html-en til å bli mer som noe annet." Etter litt diskusjon, fikk vi fanget den egentlige intensjonen: å skjerpe UI-et ved å fjerne unødvendige, distraherende detaljer.

bør alle commits derfor postes til en Slack-kanal o.l?

Vi gjør i alle fall det!

(synd det ikke går an å amende til en git-melding uten force push)

Men jeg pleier å lese commits i magit. 1. Fetch 2. Les committene fra folk 3. Rebase Fu LES commits Ru Husk som FURU. (takk til Magnar!)

tenker av en eller annen grunn alltid på @anders når jeg bruker magit. Fu-ru-pu(s) har blitt mitt mentale kallenavn, selv om jeg vet etternavnet hans ikke har "Furu" i seg. Xoxo 😘

Jeg har rebase som default, så min flyt er fu-Fu 🙂

> (synd det ikke går an å amende til en git-melding uten force push) Leste først "anmelde en git-commit". Det har jeg lyst til innimellom

magit-humor faller kraftig i kategorien "I have noone to show this to" - bortsett fra den flotte gjengen i #clojure-norway 🤗

gir det mening å tenke at alle commit-meldinger skal starte med "Our intention with this commit is to: <melding her>"?

Høres ikke dumt ut det!

Github + Slack insisterer på å bare vise første linje i commit-meldinga 🥲 Den svelger de flotte essayene mine!

Vi har skrevet custom Slack-meldinger for exceptions i prod, men har ikke rørt commit-meldinger.

rart hvor begrenset ting laget av selskaper med tusener av utviklere ansatt noen ganger kan være 🥲

Jeg lar førstelinjen si hva commit'en gjør, på en kort og konsis måte innenfor de 72 tegnene (som ikke blir klippet av enkelte viewere), og så en beskrivelse som forklarer intensjon og hensikt.

Jeg har en git commit template som minner meg på å formulere committene min i henhold til det @gar sa

nå har vi kanalen #jasså-git 🔥

Jeg brukte den templaten til @anders i mange år. Nå er det så innebygget at jeg for det meste skriver fornuftige meldinger på auto. MEN! Det er ikke så rent sjeldent at jeg finner en commit-melding der jeg skulle ønske at det også var et forklarende avsnitt tekst under.

Det er vanskelig å vite hva som er viktig å huske når du er midt oppe i noe

Det er også krevende å skrive en god commit-melding og beskrivelse. Enkelte ganger tar jeg meg selv i å slurve fordi jeg ikke orker. "Er det så viktig da?". Erfaringsmessig, ja 🙂

hehe, ja

Noen ganger er det jo ikke så viktig, men det er overraskende vanskelig til å ta den avgjørelsen i øyeblikket

synd at pull requests på github er eneste stedet man kan forfine en commit-melding over tid som et team 🥲 git commit --amend-message "message here" hadde vært nice

Dette sammenfaller også med god commit-hygiene. Istedenfor å skyte fra hofta og lage bittesmå commits for alt mulig rart ("fix lint error", "forgot about foo", "stuff") som egentlig hører hjemme i en annen commit, så rebaser jeg med fix-up/stop-to-edit før jeg pusher. (forutsetter at man ikke "pusher fra hofta" også da)