"I would pay close attention to accessibility: forecasts would be in local languages..." There are many situations where somebody is interesting about the local weather but not speaking the local language. Why overwrite the users preferred language from the browser?
It doesn't. You can Always translate the text in your favourite language.
The project aims to send the forecasts to the users, so can't be multilingual.
Anyway, that's the reason why there are the emojis. Those ones are international.
Running some of the samples feels like those old SGI Iris GL demos, but implemented with a way nicer and concise language. I'll try to port some of my old code from that era.
There are CLI tools to fetch and submit solutions. At least one of them allows you to download the puzzle description as markup: https://github.com/scarvalhojr/aoc-cli
This seems to be used at Meta: "Ractor had a session at RustConf’24 about how it’s used for distributed overload protection in Rust Thrift servers at Meta."
Their presentation [1] contains a few slides with the motivation for this framework (they have existing Thrift services in C++ and Python, and want to start using Rust too) and why actors (answer: they scale better than a naive solution?). Also a slide "why a new framework" when so many already exist for Rust. (Answer: many are dead/unsupported, are too far from Erlang principles, not flexible enough, or use custom runtimes while ractor builds on Tokio.)
If you've ever used an ML descendant you'll miss sum types wherever you go. If you've ever used Erlang you'll miss the OTP actor implementation wherever you go.
Yeah I do lol. It was the big motivation since we were writing more and more rust and missed the concurrency model. Please feel free to ping me for any further questions
It's come a long way since it started and I'm thrilled I can talk about it publicly now and it's usage at Meta (some at least lol).
It can’t be far off that they ship a BLE or Wifi enabled Sonicare that reports your best brushing habits to the app that then posts it on Facebook for philipPoints you compete with your friends on… oh shit… what have I done!?
Anyhow, blocking unofficial heads is just an OTA firmware update away.
Although the points don't go to Facebook - you get "rewards" for them. Eg:
> Pair one or more brushes to our iOS or Android app, then you’re all set. quip’s Bluetooth® Smart Motor will automatically store your routine, no phone needed! To check your brushing stats and the points you’ve earned, tap the app.
> Earn bonuses for never missing a beat! Redeem points for rewards you’ll love
The Sonicare App already reports your brushing areas and how long you brush and other metrics. It wouldn’t be hard to add a “post to FB feature” (but let’s hope they don’t).
Also, how would you know? I have an IOT product that can delta OTA, so only the bytes of the firmware that change are sent to the device, I can do firmware updates that are crazy fast. ESP if it’s just something like turning a feature on.
locking down heads will hurt what market share philips still has far more than it hurts their consumers. there are alternatives, and even a locked brush is an alternative - it still works, and actively pisses off the user.
people skip brushing their teeth for all sorts of reasons. (yes you do. stop lying. your dentist doesn’t believe you, either.)
One of the strength of pulumi is to export and reimport state, which is represented as an easy to digest json. You can edit state and that is even suggested by pulumi when it's stuck.
You can do that with Terraform too, but that is missing the point. The tool should ignore the state and simply apply the desired configuration, like every other CM tool that has ever existed.
You don't need a state file for Ansible, or Puppet, or Chef, or Salt, or CFEngine, or literally any other such tool.
Ansible will not clean up after itself when you revert a diff. Once added, you can't remove a resource from the desired state unless the tool has a way to remember resources it created so that it can decommission them.
It's funny you mention this. Removing resources from AWS is the one thing that reliably breaks in Terraform all the time.
If you have never tried to destroy all your Terraform resources before, it will probably not work. You'll have to modify your Terraform to get it to jump through the correct hoops in the correct order in order to destroy without dying.
At this very moment I am fighting with Terraform to destroy some resources as part of a code change. AWS wants them destroyed in a very particular way, and Terraform won't create the resources I do want because apply is dying because the destroy is failing.
That's a good point, but sadly not how tools like terraform marketing themselves. If terraform markets itself as "we make clean up easier for that 10% of time when you need it, and to achieve that goal, we give you 3 times more headache by asking you to keep states", I am sure many more people wouldn't make the trade-off.
