Let's not fool ourselves: their goal isn't to build a design tool, it's another training tool for a field where training data is hard to collect. We collectively reinforce predictions to sharpen the models. The pattern is clear across all their products. This is training for future one-shot generative UIs. UIs are already generative; this will scale that up to a world where applications are mostly UI-less.
Regarding time and timezones, it's best to not prematurely optimise. Ideally store both. It's much more valuable to track the timezone from your source then to have to worry about it later. ISO8601 is the universal standard.
A case where you see this issue play out is the horrible Strava-*device sync. You track in a different timezone and they store+visualise activities against some weird client-side profile setting, which causes morning runs to render at 11pm. Only adding timezone later on. They totally mess this up.
The approach should be digital knobs, which work relative to their setting and roll-through endlessly magnetically. So software can react, but user is in control.
The worst change in recent years is kitchen plates all having these horrible touch systems or magnetic detachable knobs.
It's horribly slow in usage, monster learning curve, locking systems which all behave differently, fails when wet. It's so over-designed and over-engineered. It's so bad. Just provide a knob for **'s sake and when you turn it right, it turns on.
Proof of work is no different in this regard: more capital, more mining power, more control.
Miners interests don't always align with the network's users interests (see gas fees).
Proof of work isn't more decentralized either (a few mining pool delegators control bitcoin), eth2 proof of stake is more secure because of the pseudorandom validator selection.
Don't agree, in the past metabase was good, now it's just getting worse.
I was a big fan of metabase (to the point I deployed it in 4 companies and rolled it out for many people to use in their daily workflow). All was nice.
Somewhere around 0.31 something changed in the internal dev/release flow. I get the feeling they have some kind of internal push to add unnecessary untested features which all look nice on paper, and work on a 5-row 5-column user tables. Until you actually use those features and all functionality fails miserably..
Had weird issues with it, which usually occurred after upgrades, on both small and bigger decently indexed DB's (pg and mysql), things like:
- had sets of reports which all worked fine until they hit a 1001 rows.. and suddenly the UI had a react race condition.
- X-Rays which silently fail and break the UI, while on the DB server you see the queries complete.
- Deployed new versions which would hammer databases by distincting every column individually every hour, instead of handling statistics a bit more intelligently. Disabled that ofcourse.
- Deployed versions in other countries, where the UI client-server latency caused the whole UI to break (probably the limits of setTimeout reached? :-)).
If you check the github issues, it's just ignored problems and they are focus on releasing new functionality instead of fixing the issues. Doesn't really motivate to report anymore problems.
They had one good thing: they would allow you to work in sql and write efficient queries, but clearly they decided it's time to remove the last good feature and now only want graphical query builders.
If you use metabase: deploy it on a replica such it doesn't whack your prod DB. And take backups before upgrading, because there is no revert.
I've spent enough time on Metabase problems, won't touch it anymore.
Fully agree, pipes are awesome, only downside is the potential duplicate serialization/deserialization overhead.
Streams in most decent languages closely adhere to this idea.
I especially like how node does it, in my opinion one of the best things in node. Where you can simply create cli programs that have backpressure the same as you would work with binary/file streams, while also supporting object streams.