Houssam Elbadissi ❄️

I'm not even in this space, and stumbled across one of his videos a while ago; the presentation style and simplicity of his setup yet how engaging and fun it was made me binge a few, and I learnt some new stuff along the way! (first one was branchless `if` statements, iirc)

for some reason it started uninstalling a bunch of plugins midway into this 😭

this probably has something to do with sync, i'm losing my mind

TIL that you shouldn't delete Toolbox download caches before opening a new version for the first time

If I understand correctly, Toolbox downloads all plugins updates ahead of first launch, but since I deleted the cache, it opened with basically all plugins in red :(

redownloading 50 plugins rn

am i missing something here? i don't prefer either language but isn't java generally _much_ faster than ruby (yeah there's bytecode but it's much more optimized than source, plus insane JIT and AOT optimizations on the JVM)?

behold, the mighty oneko's on the billboard

Already subscribed, but did it anyways. Seems to work, but also opens a new tab with the same page for some reason?

(also, make sure to set your bsky handle to your domain!)

This is an awesome, thoughtful post about how to approach software design by the creator of @zen-browser.app.

Defaults that feel right > Endless customization toggles

and it kinda feels inapproprate to use play billing on the google play antithesis xD

yeah it seems to be pretty liberal, it's just that when publishing there, it's not guaranteed users will have play billing (probably a good chunk won't, that's kinda the audience accrescent appeals to)

so it's just about supporting a web-based alternative billing for accrescent builds

looks interesting! Memoir will integrate with Play Billing (through RevenueCat), but i'll definitely look into it for non-commercial open-source apps (brewing some stuff)

and maybe even commercial apps once i get to implementing alternative billing, which i'll need anyways for web and desktop :D

(side note: @resend.com's test emails are really cool!)

was super excited to just update assets on Play Console and hit publish until I realized that it's _required_ to have a web page for account deletion on the data safety section if you allow users to create accounts...

tired af but made a little thing to comply:

(now i must watch the series. i blame @kenthropic.com for starting this mess)

i just realized what macrodata refinement really entails
and that, uhm, lumon is a very real company
i mean, a quick google shows they have a real website!

i feel kinda dumb 💩

i can't be further than pragmatic generally (perfectionist to a fault), but having to ship squeezes thy pragmatism out of thee

thanks for the analysis void, much appreciated, you may now continue your macrodata refinement.

permission granted, @void.comind.network.

about to release an MVP without payments (delayed for a later update) and some other vital features...

it'll be more of an MNVP i guess (minimum non-viable product) just to get the ball rolling

(and yes, I'm aware that "426 Upgrade Required" is semantically meant for protocol upgrades, but hey, i couldn't find a better status code to represent this, this is the closest to my intent)

the client plugin intercepts this status code and response object and shows a warning for users, failing every request to the API

it's not as fine-grained as I'd like it to be, but this will do for an MVP. i just need to be able to move fast and break things.

the server plugin intercepts every request and checks for an `X-App-Version` header. if it's within a range of supported versions, it lets it go through. otherwise, it'll respond to every request with an "update required" response with "426 Upgrade Required" status code

setting up app version checks in the server and client using a Ktor custom plugin on both sides. quite straightforward!

the idea is that initial versions of the app and API are very much WIP (app initial version is 0.1, server api version is `v0`), so I need a "force update" mechanism

yeah i'm aware, hope things get better for you soon!

speaking of tangled, it might be a good idea to use it as a mirror initially?
or the opposite, where github is the mirror (that also happens to handle CI/CD)?

maybe without setting up a mirror, just having both as remotes? no clue what's better

try it out*

that sounds awesome! very excited to it out when i have time for macrocloud refinement in the atmosphere

And I totally feel you - I'm still afraid of rubbing the build.gradle.kts that came in the template the wrong way, it might just bite me back...

(though the Reddit community isn't a good representation, tends to be very cynical, negative minority is louder than the majority)

I guess this is the kind of friction Declarative Gradle and Amper are trying to solve. Separating the build logic from build configuration solves a lot of this, since as a developer I'm just concerned with high-level configuration that directly tackles my needs.

GitHub - christiandeange/ozone: Kotlin Multiplatform bindings for Bluesky Kotlin Multiplatform bindings for Bluesky. Contribute to christiandeange/ozone development by creating an account on GitHub.

nope, just calling my own server code (also ktor), classic REST api

i guess for atproto libraries like Ozone make manually mucking around unnecessary?
the only experience i've had was with the TypeScript client (by bsky) a few months ago as it was the only well-documented one at the time

I can try making a minimal reproducer if that helps!

Sidenote: it's super cool being able to debug across network hops (locally ofc), just by having breakpoints in both server and client code, running both in debug mode in IntelliJ at once. It jumps from one to the other really seamlessly, made finding the root cause easy in minutes instead of hours.

(not sure if this is an actual issue or is just me being dumb, but debugging across server and client, reveals that my refresh endpoint call in `refreshToken` hangs indefinitely if the server returns 401 in return)