#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...
#prog #rust
Esteban Kuber продолжает улучшать диагностики парсера rustc. Теперь парсер ещё и восстанавливается от маркеров конфликта слияния.
github.com/rust-lang/rust/pull/106242
Esteban Kuber продолжает улучшать диагностики парсера rustc. Теперь парсер ещё и восстанавливается от маркеров конфликта слияния.
github.com/rust-lang/rust/pull/106242
GitHub
Detect diff markers in the parser by estebank · Pull Request #106242 · rust-lang/rust
Partly address #32059.
🔥7👍2
#prog #rust
Я просто оставлю это здесь (btw это Вафель сделал)
github.com/rust-lang/rust-analyzer/pull/13857
Я просто оставлю это здесь (btw это Вафель сделал)
github.com/rust-lang/rust-analyzer/pull/13857
GitHub
feat: Implement yeeting by WaffleLapkin · Pull Request #13857 · rust-lang/rust-analyzer
See tracking issue: rust-lang/rust#96373
Before:
After:
Before:
After:
❤2👍1