I'm still on the fence (and distracted by Vision Pro). It's a good-ish idea, IMHO. I'd like to see a toolkit for "reading configs" where configs are some universal format (JSON, YAML, TOML, etc) for various languages. So that the app in Ruby can share config with "microservice" in Rust and they can also maintain compatibility with completely different app (but sharing infra resources) in Go. Using one config language that supports hierarchical templates, modules, imports, whatever. Because otherwise everyone starts inventing their own "YAML with functions", "JSON with templates", etc. Pkl seems like that. But I don't like that it's Turing complete. Powerful and dangerous. Configs are inherently declarative.
I just run a count, on the infrastructure configuration for a relatively small, but already public company. 13k lines of YAML alone. Some of it is generated (from "YAML with macros") by AWS CDK parody I invented before CDK became a thing (and being an old school Unix pervert I did it with awk and m4).
There's also 1400 lines of written or generated JSON that still needs to be managed.
And that's a successful, but single-product company. I also worked for a company which had a single product but ran it for their clients heavily (very heavily) customized, you can easily 10x the numbers above and you still have to do that with a single team and go back to your family every night and not riding an ambulance to the nearest mental facility.
YAML is like the object code, it's not a configuration language. (and that's why I prefer JSON, it's less error prone and easier to generate). Writing YAML manually is like programming in machine code back in the 80s. Possible, but why?
If we produced a gigawatt of energy by cleanest way possible, where do you think this gigawatt ends up? Some "energy dumpyard" somewhere outside the solar system?
The temperature is a balance between energy incoming from the sun and energy being radiated off into space. Wind and solar don't change that balance directly, although the lower reflectivity of solar panels makes a small local difference. Ultimately it's the transmissibility spectrum of the atmosphere that matters. Which is why we care about CO2 in the first place.
For the same type (shared whiteboard) and kind (getting back into the game) I chose Flutter for front (web/mobile) and Rust for back. Had a lot of fun and it even kinda worked :-)
the power cord has to have a data link (USB? or just networking over power line itself) through which the power outlet can tell the computer how much does the energy cost at any given time. this is a very welcome but very expensive addition to the infrastructure.
my wall outlet supplies power from 3 different sources: grid, solar on the roof and/or powerwall, depending on the weather, grid status (which sucks where I live) and time of day. computer only knows time of day off the bat, everything else it has to learn in a complex way.
if I have a "cost" or, better, "status" information integrated into the power itself, smart appliances (like computer) can make decisions what they can or can not run. right now I can start training my models on my 4090 at night, we have an outage, and 4090 will happily drain the powerwall, so I'll not have an A/C in the morning. models can wait, they're stupid anyway, or at least I like the A/C better.
ha-ha, brother, I feel you. Infra engineer (VP last position) and built an app with Refine. I was exactly in your position not a long time ago. I tried to choose "The Best Framework Ever" and made a lot of mistakes, and at the end, if you don't know frontend go with the flow: React + Next.js. Not because they are Best Ever, but because the majority of content online is dedicated to these frameworks. StackOverflow, ChatGPT, a friend who speaks frontend, etc.
I did some work as part of my consultancy, had data left and decided to try my hands at frontend. Oh, boy, I think it was a mistake, but it was a lot of fun, will do again.
https://cloudprice.io
The deceptive part of these types of frameworks is this: on the first day, you think it will solve all your problems. On the second day, you're happy, thinking about how much you've sped up because you chose this framework for your project. On the third day, you have a custom need, and you research how to do it within that framework. On the fourth day, you hack the framework to make it flexible. On the fifth day, you say, 'Why didn't I start from scratch myself?'
Our goal and motivation in developing refine is to ensure that the developer continues to feel the way they felt on the first day, even on the day they finish the project and begin to maintain it.
And on the sixth day you have uncontrollable flashbacks to the days of using jquery to manage your application state as a singleton in the global scope and you die a bit inside ;).
literally this. but to the benefit of refine.dev i should say that you made the framework extremely easily hackable, at least where lame me wanted to hack it. your data backend didn't work with my rest api, i've asked on discord and someone said: hey, it's actually in the docs, you just copy our default implementation into your project, import it, make sure it works as before and then hack it as your own code. a productized hack, i'd say.
If I understand correctly, using 'swizzle' to customize the data provider is not a hack for refine, but an expected behavior. But I'm curious about the conversation; could you possibly share the link?
the ease looks like a hack, since it's documented it's not a "hack as in workaround". in my vocabulary "hack" is a compliment, not a derogative. i grew up on jargon file.
I tried to use the site you mentioned at the end of your post, but when I tried to add an ec2 instance (searching for ec2 resource) I got a 500 error "Error talking to backend server: 500".
