wonger_
Joined 3 years ago
Karma
3,094
Submissions
577
Member since
Apr 24
View on Hacker News
Recent submissions
Comment · 2 months ago
Neat post, neat site
This broken link made me sad tho: https://radio.haze.cool/public/jungle
I was looking forward to jungle radio
Comment · 2 months ago
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
Comment · 2 months ago
Anywhere we can read some of your story? I'm always curious about devs that went into sales, or sales from a dev perspective
Comment · 2 months ago
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.
Comment · 2 months ago
Could you describe more? Your process, resources, use cases, user feedback
Comment · 3 months ago
Ah ok, thanks for clarifying contrived vs real. Like a videogame tutorial I suppose.
Comment · 3 months ago
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.
Comment · 3 months ago
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...
Comment · 3 months ago
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.
Comment · 3 months ago
True, but have you ever sliced your LATKE with a POCKETKNIFE?