wonger_

Neat post, neat site

This broken link made me sad tho: https://radio.haze.cool/public/jungle

I was looking forward to jungle radio

See also the Indian / Sri Lankan region of https://radio.garden

I love music from that part of the world

Indian metal crossover: https://www.youtube.com/watch?v=mi106DZJhuQ

This vocal percussion style is called konnakol: https://www.youtube.com/watch?v=aLCGKP6d55E

See also Nusrat Ali Fateh Khan, not too far away

Anywhere we can read some of your story? I'm always curious about devs that went into sales, or sales from a dev perspective

I'm working with .env and secrets and teamwide configs for the first time, trying to understand solutions from first principles.

Are these valid observations so far?

- .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?

- .env.example seems like a nice home for documentation about secrets

- but I'd rather avoid writing sensitive credentials at all -- instead, teams can use a cloud-based secrets manager and the project fetches secrets at runtime. Is this ever a hassle / any downsides? How standard is this practice these days? I hear this also helps updating secrets so you don't have to e.g. tell every teammate when you rotate a secret. Generally not a fan of introducing a network call and a saas dependency, tho

- non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local

- I hear lots of secrets and config management happens in container orchestration, but what if I barely have a container in the first place? I guess docker compose is one of the simplest tools at this layer?

I guess I'm just looking for a safe, simple solution for a small team, and maybe the problem is that every team does things differently, and that many tools are marketed towards huge enterprise teams.

Could you describe more? Your process, resources, use cases, user feedback

Ah ok, thanks for clarifying contrived vs real. Like a videogame tutorial I suppose.

Another documentation model: Fabrizio's seven actions [0]. People read docs to appraise, understand, explore, practice, remember, develop, and troubleshoot, usually in that order.

It feels so natural and obvious compared to Diataxis' forced abstractions, where I'm still left wondering "what's the difference between a tutorial and a how-to guide?"

But! I'm glad for anything that helps people organize and maintain docs.

[0] https://passo.uno/seven-action-model/

For other interested spectators, I found this post by the author to be a good example of architectural changes in pgrust (along with motivations): https://malisper.me/the-four-horsemen-behind-thousands-of-po...

Neat, I'm also planning a lil newspaper hobby project. I'm curious:

- what paper size are you going to use? Like full broadsheet size or zine size?

- and how many pages of content do you think you'll have, given that size?

- black and white, or color?

- where will you get all your content? Designing puzzles, experiments etc seems like it would take a long time

- do you recommend any printeries?

- anywhere we can follow your progress? I'd be super excited to see a first mockup

FWIW, as a web guy, I'm leaning towards designing my content in HTML + CSS and exporting to PDF at a certain page size, probably using playwright.

True, but have you ever sliced your LATKE with a POCKETKNIFE?

Seems like div is the only recommended wrapper element:

https://html.spec.whatwg.org/multipage/grouping-content.html...

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

EDIT everyone replied at once lol. I'm surprised too about div.

Also, screen reader support: https://a11ysupport.io/tech/html/dl_element

I too wish for better tooling for browsing repo histories.

I'm imagining a UI similar to 5-D chess (https://store.steampowered.com/app/1349230/5D_Chess_With_Mul...) and maybe like debase (https://toaster.llc/debase/index.html)

Cloests thing I know of is https://github.com/kristoff-it/superhtml#diagnostics

  SuperHTML validates not only syntax but also element nesting and attribute values. No other language server implements the full HTML spec in its validation code.

Good ideas. It's nice to hear a non-frontender's perspective.

For font sizing and spacing, I always recommend https://utopia.fyi. It generates CSS variables like:

  --step-0: clamp(1.125rem, 1.0739rem + 0.2273vw, 1.25rem);
  --step-1: clamp(1.35rem, 1.2631rem + 0.3864vw, 1.5625rem);
  --step-2: clamp(1.62rem, 1.4837rem + 0.6057vw, 1.9531rem);

  --space-s: clamp(1.125rem, 1.0739rem + 0.2273vw, 1.25rem);
  --space-m: clamp(1.6875rem, 1.6108rem + 0.3409vw, 1.875rem);
  --space-l: clamp(2.25rem, 2.1477rem + 0.4545vw, 2.5rem);

that you can copy-paste across projects. Note this is not a fixed scale (1em 2em 4em), but it grows with viewport size, so bigger screens can have bigger text and looser margins. No more breakpoints; only choose min and max supported viewports, and the rest is interpolated.

I do wonder about interpolating line heights, though. Does anyone who uses utopia.fyi have a good way to manage that?

Re organizing spacing and layout rules, I still struggle with that. One day I'd like to see what https://every-layout.dev/ recommends.

Very interesting idea! Adaptive UX seems under explored.

Have you ran into any issues with handling inputs? Like how vim Ctrl+P would maybe be intercepted by the browser Ctrl+P shortcut for print.

And have you run into any other issues, maybe like performance?

I feel like web-ified terminals get nerfed pretty hard and I'm not sure if/how people overcome that.

I like the idea of customizing multiplexed terminals with on-the-fly JavaScript, tho.

Maybe a fourth? https://shellsharks.com/indieweb#:~:text=Webrings

You can do both, because some people like having per-site color controls.

Like I prefer to read prose and literary website content in light mode while keeping my OS in dark mode.

Admittedly it's a niche use case.

A decent technical comparison: https://nullprogram.com/blog/2013/09/23/

Mostly about Atom requiring IDs and timestamps, and having an overall cleaner and less ambiguous spec