oDot

8 ms·

61.
by oDot 2y ago
Try iZotope RX
62.
by oDot 2y ago
Unfortunately for many of the HTMX/Turbo people, they did right to identify the problem but they have the wrong solution. The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it
63.
by oDot 2y ago
Is ATProto fully implementable by third parties? I last read there were still closed source parts
64.
by oDot 2y ago
I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production
65.
The Perfect Dating App(blog.eventful.is)
2 points by oDot 2y ago|0 comments
66.
by oDot 2y ago
Hi there! I am extremely glad to read someone else write about this necessity! I own and operate a "list-taking" app[0] in which every list/kanban-item can itself be a list/kanban. I currently use it for things I'm
67.
by oDot 2y ago
Indeed, I was just staying in context :)
68.
by oDot 2y ago
I research live-action anime[0] and this looks really cool, especially if there's fine-grained control over each sensor and especially if you can change the lenses (in a supported or unsupported manner). Anime has the advantage of bein
69.
by oDot 2y ago
I'll add Loro[0] to the author's list. While I utilise Yjs heavily for another project, Loro is fairly featureful and so I picked it to build a screenplay editor[1], which requires things like Peritext or tree structures. It'
70.
by oDot 2y ago
I wouldn't say it's outright wrong, I just much prefer the ergonomics of an orderly, TEA-like state management. Many of the projects I make lend themselves well to that approach.
71.
by oDot 2y ago
Yes, that is the major problem I have with TEA. The best thing about Flutter's design is that it employs a "reverse iceberg" where many of Flutter's own widgets are composed with other widgets, leaving few architectural
72.
by oDot 2y ago
After discovering and adopting[0] Lustre, I can't think of using anything other than The Elm Architecture. It is so much more ergonomic it's not even comparable to today's mainstream state management techniques. I'm also
73.
by oDot 2y ago
The evolution is Gleam + Lustre (its main FE framework). You get all of Gleam's advantages compared to TS (simple, truly type safe, errors as values, exhaustive match, etc), and Lustre is great because you get an Elm that can be run on
74.
by oDot 2y ago
Correct, these are all trade-offs we make when building a product. Choosing between the "1/0 crashes your program" problem and the "1/0 returns 0" problem is one such tradeoff. All I was doing was clarifying th
75.
by oDot 2y ago
You've missed the part of the internet where GrapheneOS resides
76.
by oDot 2y ago
You'll find that keeping my client information's integrity is as important to me as keeping the financials. That, however, is still not enough to alleviate OP's concerns, which is why I've explained how the `1/0=0`
77.
by oDot 2y ago
I use Gleam in production[0][1], and that is not really an issue. Gleam offers division functions that return an error type, and you can use those if you need that check. They fit a list-length use case well as they work better with a pipin
78.
by oDot 2y ago
Thank you for the thorough explanation
79.
by oDot 2y ago
Is anyone here using BTRFS and can comment on its current-day stability? I used to read horror stories about it
80.
by oDot 2y ago
Isn't that what every technology was at some point?
81.
by oDot 2y ago
I am a big fan of Gleam language's Lustre[0], and due to its functional nature, the full stack experience is much better. Instead of becoming this mishmash of backend and frontend, there's a clear delineation between the two. They
82.
by oDot 2y ago
Strix Halo is rumored to be about twice as fast but unfortunately not near Apple's speed.
83.
by oDot 2y ago
Every time there's a Bluesky or ATProto post I comment with how I think their killer feature is video. Their smart use of domains makes it so that their equivalent of "channel" can be an actual website, that will offer you re
84.
by oDot 2y ago
While this is generally true, is how I recommend to treat Slack, and how I treat it myself, the reality is that its nature is neither here nor there. It's true that if you treat it just right, you're going to get an async tool. Ho
85.
by oDot 2y ago
History preservation is not just about continued existence, but also about discoverability. Other forms of communication (issues, project planners, and email lists) are much better for the latter.
86.
by oDot 2y ago
I'd say avoid slack as much as possible. Use evergreen communication: https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...
87.
by oDot 2y ago
Nice, I wonder when the third documentary will be out
88.
by oDot 2y ago
Since the null-related blog post isn't published yet, anyone here knows the reason to implement null rather than write middle-layer in C# for whatever you want to use?
89.
by oDot 2y ago
Isn't unified memory* a crucial part in avoiding signal integrity problems? Servers do have many channels but they run relatively slower memory * Specifically, it being on-die
90.
List-Taking and Note-Taking(blog.nestful.app)
2 points by oDot 2y ago|0 comments

More ›