Nothing, because I want this for open source projects that I give away for free. That doesn't work if I have to tell my users to go pay a license fee for one of the components.
The output from Jules is a PR. And then it's a toss-up between "spot on, let's merge" and "nah, needs more work, I will check out the branch and fix it properly when I am the keyboard". And you see the current diff on the webpage while the agent is working.
Oh definitely. How can you suggest adding a binary to a git repository? It's a bad idea on many levels: it bloats the repository by several orders of magnitude, and it locks you to the chosen architecture and OS. Nope, nope, nope.
The issue with binaries is when they are large, change often, is often a duplication of information already present, and that you can't diff them. A program is neither large, it doesn't change often, is not duplicate information and you don't want to diff them. IMHO this idea is fine, this is not added the build artifact in every commit type of situation.
Second this. Once I setup GitHub actions with Hugo (there’s one readily available), I rarely build the blog locally anymore. New article drafts become GH pull requests, and once ready they get merged and published. This also works on mobile well enough.
> I am assuming the message durability guarantees lean towards YOLO rather than ACID?
"Core" nats doesn't have durability. Nats jetstream is the api built on top of nats that in the main nats-server impl provides durability. Jepsen tested Nats Jetstream.
Also from your link:
> Regular NATS streams offer only best-effort delivery, but a subsystem, called JetStream, guarantees messages are delivered at least once.
The project linked here does not implement the nats jetstream api, just normal nats.
So yes, it seems its same (documented, understood) "yolo" as normal nats.
IBM Plex is very good. Recently, I have been enjoying https://rsms.me/inter/ for interfaces a bit more (with ss02 for body and ss02+tnum for tables activated).
Inter is the only libre typeface that has good coverage, and produces readable small text on terrible 80 DPI displays. I've tested probably hundreds of them.
I guess I can try to argue that it if it weren't as generally useful as Helvetica it wouldn't have been made the default in Figma and it wouldn't be, well, so generally used.
Hah, this one can go on Wikipedia as an example for "chicken or the egg"! IMO, there's probably a number of other fonts that could've been chosen rather than Inter as default Figma font, and if they had been, they'd now be more ubiquitous than Inter. Of course, we'll never know. Unless someone here is looking to do a research study into popularity of fonts over time compared to popularity of Figma and seeing how strong the correlation is - maybe a weekend project for someone into typography ;)
Ah, it initially appeared that the capital I and the lowercase L have identical-looking glyphs. But scrolling down, I see the ss02 and tnum features add noticeable glyphs. Looks like a nice typeface.
Modified Condition/Decision Coverage (MC/DC) is a test coverage approach that considers a chunk of code covered if:
- Every branch was "visited". Plain coverage already ensures that. I would actually advocate for 100% branch coverage before 100% line coverage.
- Every part (condition) of a branch clause has taken all possible values. If you have if(enabled && limit > 0), MC/DC requires you to test with enabled, !enabled, limit >0, limit <=0.
- Every change to the condition was shown to somehow change the outcome. (false && limit > 0) would not pass this, a change to the limit would not affect the outcome - the decision is always false. But @zweifuss has a better example.
- And, of course, every possible decision (the outcome of the entire 'enabled && limit > 0') needs to be tested. This is what ensures that every branch is taken for if statements, but also for switch statements that they are exhaustive etc.
MC/DC is usually required for all safety-critical code as per NASA, ESA, automotive (ISO 26262) and industrial (IEC 61508).
To test 'limit > 0' according to MC/DC, you need only two values, e.g. -1 and 1. There may be other code inside the branch using limit in some other ways, prompting more test cases and more values of limit but this one only needs two.
But yes, exhaustively testing your code is a bit exhausting ;)
reply