one of those games where i wish i could erase my memory just to play it again, still think about it, i think it's like a year ago i played it, maybe more. idk. great game.
I'm using my unrooted stock s23u with damaged screen as a server but only to me thru tailscale.
Termux. Proot ubuntu. Serving OWUI and syncthing. Works fine. Had to remove pw protection so runit starts services at reboot. Therefore encrypted at rest any sensitive data
I Ssh in into it with ai harness to make changes.
Made me not want to sell it after all.
Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic.
The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed.
My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time.
Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness.
Beautifully decoupled. Extremely testable.
Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests.
A welcome-page refactor breaks the profile page.
“Didn’t you check the nightly build?”
No. It runs at night.
“Well, that’s your responsibility.”
But you broke it.
“Yes, but it’s your code.”
Then why did we ship it?
Fine. Schedule the postmortem with my mother.
And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack.
What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component.
People react to that with horror: what if components are duplicated, behave or look slightly different?
Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed.
> I have to think about everything, everywhere, all the time.
I think this is familiarity speaking, which is what you're expressing earlier in the comment anyway. The reality is that we have to think of everything when telling a machine what to do. Exactly how we get that done is preference.
Might just resub. Will experiment with Luna next sessions.
5 h window is not working very well for me. But if I can drop down to Luna at 20-30 % left and comfortably ride out the wave then.. that might just work.
I did this too. But honestly, I was getting a little tired of it.
Now I use AI to build things I genuinely like and actually use. Nothing particularly fancy.
I built a weather website that I use all the time when planning hikes. I also built a generative hiking-route tool: give it a starting point and a distance, and it tries to find interesting paths for you. I’ve made plenty of small helper tools for work and health, and now I’m wrestling with Open WebUI, trying to make it work exactly the way I want while repurposing an old Android device as the server.
Do I miss nerding out over implementing a B-tree, or learning async programming in F#, Go, Crystal, Nim, C++, C#, JavaScript workers, or Java green threads?
I don’t know, man. Maybe a little.
But it has also never been easier to say: “Hey AI, teach me this concept using five examples. Give me one task, then evaluate my solution. And teach it in this particular style.”
We lost something. I genuinely think we did.
But I also think we gained much more.
It’s okay to mourn what was lost, as long as you can still look forward.
reply