Блог*
#prog #rust #rustlib #article Toward fearless cargo update I recently built cargo-semver-checks, a linter that ensures crates adhere to semantic versioning. This is why and how I built it. В FAQ также есть сравнение с аналогичными инструментами.
#prog #rust #rustlib #article
cargo-semver-checks today and in 2023
Following semver in Rust is a perfect example of a workflow worth automating:
* Important to get right, painful if done wrong: cargo requires all crates to follow semver, so breaking semver in one crate can have a ripple effect across the ecosystem. But if done right, semver is completely invisible.
* Countless complex rules: There are hundreds of ways to cause a breaking change, many of them non-obvious.
* Code that violates semver doesn't look wrong: No code reviewer can be expected to reliably flag most of the semver issues, even assuming they are well-versed in all the semver rules. The evidence on this point is particularly overwhelming (1, 2, 3, 4, 5).
Some might say the solution is to "git gud". I deeply respect operational excellence, but this is not the way.
Civilization advances at the rate at which we develop robust abstractions. I am writing this on a computer I cannot build, under a blanket I cannot weave, having enjoyed a meal with ingredients I cannot grow. I dedicated ten years to math competitions, and I can't even calculate a logarithm by hand! Can you?
Gatekeeping to only include people with a PhD in "Semver in Rust" won't cut it.
Yosh Wuyts quotes another Rust contributor as saying: "The job of an expert is to learn everything about a field there is to learn, and then distill it so that others don't have to." I couldn't agree more!
cargo-semver-checks today and in 2023
Following semver in Rust is a perfect example of a workflow worth automating:
* Important to get right, painful if done wrong: cargo requires all crates to follow semver, so breaking semver in one crate can have a ripple effect across the ecosystem. But if done right, semver is completely invisible.
* Countless complex rules: There are hundreds of ways to cause a breaking change, many of them non-obvious.
* Code that violates semver doesn't look wrong: No code reviewer can be expected to reliably flag most of the semver issues, even assuming they are well-versed in all the semver rules. The evidence on this point is particularly overwhelming (1, 2, 3, 4, 5).
Some might say the solution is to "git gud". I deeply respect operational excellence, but this is not the way.
Civilization advances at the rate at which we develop robust abstractions. I am writing this on a computer I cannot build, under a blanket I cannot weave, having enjoyed a meal with ingredients I cannot grow. I dedicated ten years to math competitions, and I can't even calculate a logarithm by hand! Can you?
Gatekeeping to only include people with a PhD in "Semver in Rust" won't cut it.
Yosh Wuyts quotes another Rust contributor as saying: "The job of an expert is to learn everything about a field there is to learn, and then distill it so that others don't have to." I couldn't agree more!
predr.ag
cargo-semver-checks today and in 2023
40,000 downloads, 30 lints, and many prevented semver issues in the real world. We're just getting started.
👍5
#article
The five-minute feedback fix
We universally accept that shorter feedback cycles are good—working them in between coding and testing, sprint planning and sprint retro, merging and deployment. But two critical areas lack early feedback: requirements and design.<...>
It doesn’t have to be this way. There’s nothing special about designs or requirements that make them impossible to analyze. It’s just that, historically, almost all of our feedback tools are built to analyze code. We never consider requirements or designs as something we can test, too. If we could, we could shorten the feedback cycle on thinking through our code, saving us and our clients a lot of time and money.
<...>
There are other design languages with other tradeoffs, but simply listing a bunch of technologies does not make for a good essay. Instead, let’s take a deep dive into an introductory technique called decision tables. Not only is it effective and widely used in specification, it’s so simple that you’ll be proficient enough to use it yourself by the end of this essay.
Но автор предупреждает:
I like decision tables because they are simple, easy, and powerful. Anybody can learn them in five minutes and use them, even without a technical background. But one thing we didn’t do with them is directly connect the decision table to our code. And this is the main limitation of modern formal specification: There’s no built-in way to guarantee that you faithfully implemented your design. It’s possible, and people have done it, but it takes a lot of hard work to do this.
This is an intentional choice. From experience we know that tools which connect design to code are much, much harder to use, making them less accessible for most programmers. Instead, it focuses on what it is best at: shortening the feedback loop from design to design.
The five-minute feedback fix
We universally accept that shorter feedback cycles are good—working them in between coding and testing, sprint planning and sprint retro, merging and deployment. But two critical areas lack early feedback: requirements and design.<...>
It doesn’t have to be this way. There’s nothing special about designs or requirements that make them impossible to analyze. It’s just that, historically, almost all of our feedback tools are built to analyze code. We never consider requirements or designs as something we can test, too. If we could, we could shorten the feedback cycle on thinking through our code, saving us and our clients a lot of time and money.
<...>
There are other design languages with other tradeoffs, but simply listing a bunch of technologies does not make for a good essay. Instead, let’s take a deep dive into an introductory technique called decision tables. Not only is it effective and widely used in specification, it’s so simple that you’ll be proficient enough to use it yourself by the end of this essay.
Но автор предупреждает:
I like decision tables because they are simple, easy, and powerful. Anybody can learn them in five minutes and use them, even without a technical background. But one thing we didn’t do with them is directly connect the decision table to our code. And this is the main limitation of modern formal specification: There’s no built-in way to guarantee that you faithfully implemented your design. It’s possible, and people have done it, but it takes a lot of hard work to do this.
This is an intentional choice. From experience we know that tools which connect design to code are much, much harder to use, making them less accessible for most programmers. Instead, it focuses on what it is best at: shortening the feedback loop from design to design.
GitHub
The five-minute feedback fix
Got 5 minutes? @hillelogram has a formal feedback method you can learn to deliver high-quality software that’s cheaper and faster:
Блог*
#prog #моё Если вы используете регулярные выражения — вам должно быть за это стыдно У регулярных выражений есть куча недостатков, и, на мой взгляд, их слишком часто используют там, где не надо. Сейчас я расскажу о том, что же с ними не так. Проблемы 1.…
#prog #regex #article
The true power of regular expressions
<...>
As the article was quite long, here a summary of the main points:
* The “regular expressions” used by programmers have very little in common with the original notion of regularity in the context of formal language theory.
* Regular expressions (at least PCRE) can match all context-free languages. As such they can also match well-formed HTML and pretty much all other programming languages.
* Regular expressions can match at least some context-sensitive languages.
* Matching of regular expressions is NP-complete. As such you can solve any other NP problem using regular expressions.
But don’t forget: Just because you can, doesn’t mean that you should. Processing HTML with regular expressions is a really bad idea in some cases. In other cases it’s probably the best thing to do.
The true power of regular expressions
<...>
As the article was quite long, here a summary of the main points:
* The “regular expressions” used by programmers have very little in common with the original notion of regularity in the context of formal language theory.
* Regular expressions (at least PCRE) can match all context-free languages. As such they can also match well-formed HTML and pretty much all other programming languages.
* Regular expressions can match at least some context-sensitive languages.
* Matching of regular expressions is NP-complete. As such you can solve any other NP problem using regular expressions.
But don’t forget: Just because you can, doesn’t mean that you should. Processing HTML with regular expressions is a really bad idea in some cases. In other cases it’s probably the best thing to do.
❤5
Никто:
Антон: забывает, что ему теперь переводят зарплату на карту другого банка
Антон: забывает, что ему теперь переводят зарплату на карту другого банка
❤3😁2
#rust
Хорошее дополнение к документации макроса
github.com/rust-lang/rust/pull/106453
Хорошее дополнение к документации макроса
include!. Это не замена модулям.github.com/rust-lang/rust/pull/106453
GitHub
Improve include macro documentation by coastalwhite · Pull Request #106453 · rust-lang/rust
As outlined in #106118, the include! macro is a SEO problem when it comes to the Rust documentation. Beginners may see it as a replacement to include syntax in other languages. I feel like this doc...