If need anything more complicated than simple $var substitution, it's time to use a general purpose scripting language with appropriate libraries to generate your data structure. A half-baked template DSL will never work.
This should give a second life to Test-Driven Development.
One of the under-appreciated wisdoms of TDD is that there is a complexity asymmetry in many problems between finding a solution and (fully or partially) verifying it. Examples of asymmetric problems: inverting matrices, sorting an array, computing a function's gradient, compressing a byte stream, etc.
Human writes the easier part -- the test suite, the language model writes the harder part -- the solution. This can be a net gain in productivity.
There is a major flaw in placement of the EC2 instance in this diagram.
Each EC2 instance has 1 or more Network Interfaces, where each Network Interface resides in 1 subnet and can have multiple public and private IP addresses. The diagram currently suggests that an EC2 instance is located in a single subnet — it’s not. Each Network Interface connected to an EC2 instance is only required to be in the same Availability Zone where the instance was launched.
I would rephrase this concern as "dconf is not a stable API" rather than "you are not supposed to do this". It's my computer, I am supposed to do whatever I want, but using unstable API comes with costs that should be understood.
I find SQL very hard to use when the data schema and/or transformation graph needs to be dynamic (e.g. depends on the data itself). It's hard to make SQL dynamic even at build time -- Jinja+SQL is one of the worst development experiences I have ever had.
Yeah, I am also struggling to interpret the metrics in this post positively.
The 50% success rate is also best out of 3200 completions. For best out of 1 completion, the success rate is in low single digits.
I think the lesson here is that these models bring a lot more value when:
1. you have unit tests,
2. can afford compute/time to let the model try many solutions,
3. have enough isolation to run unverified code.
> Authenticators are fine, except if you lose a couple of smartphones too close together, or you need a team to access one account.
When you enable TOTP with a service, you can extract the TOTP secret and do all of the above with it -- backup to storage, copy to new devices, distribute to multiple people, etc.
In my recent job, I committed Jupyter notebooks to Git, and they tend to be giant JSON files. I had 10x SLOC of anyone who did not commit Jupyter notebooks.
I have been working on an iOS/MacOS app that reminds me to stand up and/or take breaks at certain intervals. It's using the iPhone's camera and local computer vision to collect ground truth.
A lot of concerns are focusing on (person) -> (tiktok) -> (CCP) data flow.
What about the reverse information flow?
A foreign political party tuning the algorithm to affect public opinions? I think this is even more impactful than data snooping. It's also a lot harder to detect and prevent.
What if US government makes a (secret) deal with China to get data from them? It might seem unlikely today, but politics can change any time. Data markets can be fairly efficient. Once someone has your data, they can always (re)sell it to the highest bidder.