Для обучения программированию на Rust требуется:
Anonymous Poll
39%
Компьютер
35%
Доступ к интернету
21%
rustup
7%
TRPL
6%
Знание высшей математики
56%
Чулки
23%
Целеустремлённость
22%
Игрушка краба
11%
IDE
47%
Желание
#prog #article
Use of Formal Methods at Amazon Web Services (pdf)
Папир, на минуточку, от 2014 года. При этом довольно короткий и не обременённый формальностями, так что советую прочитать его целиком, а не только выбранные мною выдержки.
We have found that testing the code is inadequate as a method to find subtle errors in design, as the number of reachable states of the code is astronomical.
<...>
In industry, formal methods have a reputation of requiring a huge amount of training and effort to verify a tiny piece of relatively straightforward code, so the return on investment is only justified in safety-critical domains such as medical systems and avionics. Our experience with TLA+ has shown that perception to be quite wrong. So far we have used TLA+ on 10 large complex real-world systems. In every case TLA+ has added significant value, either finding subtle bugs that we are sure we would not have found by other means, or giving us enough understanding and confidence to make aggressive performance optimizations without sacrificing correctness.
<...>
Engineers naturally focus on designing the ‘happy case’ for a system, i.e. the processing path in which no errors occur. This is understandable, as the happy case is by far the most common case. That code path must solve the customer’s problem, perform well, make efficient use of resources, and scale with the business; these are all significant challenges in their own right. Once the design for the happy case is done, the engineer then tries to think of “what might go wrong?”, based on personal experience and that of colleagues and reviewers. <...> Almost always, the engineer stops well short of handling ‘extremely rare’ combinations of events, as there are too many such scenarios to imagine. <...> In contrast, when using formal specification we begin by precisely stating “what needs to go right?” <...> We have found this rigorous “what needs to go right?” approach to be significantly less error prone than the ad hoc “what might go wrong?” approach.
<...>
T.R. learned TLA+ and wrote a detailed specification of these components in a couple of weeks. <...> This time the model checker found a bug that could lead to losing data if a particular sequence of failures and recovery steps was interleaved with other processing. This was a very subtle bug; the shortest error trace exhibiting the bug contained 35 high level steps. The improbability of such compound events is not a defense against such bugs; historically, AWS has observed many combinations of events at least as complicated as those that could trigger this bug. The bug had passed unnoticed through extensive design reviews, code reviews, and testing, and T.R. is convinced that we would not have found it by doing more work in those conventional areas.
<...>
B.M.’s first spec was for an algorithm that had a known subtle bug. The bug had passed unnoticed through multiple design reviews and code reviews, and had only surfaced after months of testing [выделение моё]. B.M. spent two weeks learning TLA+ and writing the spec. Using this spec, the TLC model checker found the bug in a few seconds [выделение моё]. The team had already designed and reviewed a fix for this bug, so B.M. changed the spec to include the proposed fix. The model checker found that the problem still occurred, but via a different execution trace. A stronger fix was proposed, and the model checker verified the second fix.
<...>
While our results are very encouraging, some important caveats remain. Formal methods deal with models of systems, not the systems themselves, so the adage applies; “All models are wrong, some are useful.” The designer must ensure that the model captures the significant aspects of the real system. Achieving this is a difficult skill, the acquisition of which requires thoughtful practice.
Use of Formal Methods at Amazon Web Services (pdf)
Папир, на минуточку, от 2014 года. При этом довольно короткий и не обременённый формальностями, так что советую прочитать его целиком, а не только выбранные мною выдержки.
We have found that testing the code is inadequate as a method to find subtle errors in design, as the number of reachable states of the code is astronomical.
<...>
In industry, formal methods have a reputation of requiring a huge amount of training and effort to verify a tiny piece of relatively straightforward code, so the return on investment is only justified in safety-critical domains such as medical systems and avionics. Our experience with TLA+ has shown that perception to be quite wrong. So far we have used TLA+ on 10 large complex real-world systems. In every case TLA+ has added significant value, either finding subtle bugs that we are sure we would not have found by other means, or giving us enough understanding and confidence to make aggressive performance optimizations without sacrificing correctness.
<...>
Engineers naturally focus on designing the ‘happy case’ for a system, i.e. the processing path in which no errors occur. This is understandable, as the happy case is by far the most common case. That code path must solve the customer’s problem, perform well, make efficient use of resources, and scale with the business; these are all significant challenges in their own right. Once the design for the happy case is done, the engineer then tries to think of “what might go wrong?”, based on personal experience and that of colleagues and reviewers. <...> Almost always, the engineer stops well short of handling ‘extremely rare’ combinations of events, as there are too many such scenarios to imagine. <...> In contrast, when using formal specification we begin by precisely stating “what needs to go right?” <...> We have found this rigorous “what needs to go right?” approach to be significantly less error prone than the ad hoc “what might go wrong?” approach.
<...>
T.R. learned TLA+ and wrote a detailed specification of these components in a couple of weeks. <...> This time the model checker found a bug that could lead to losing data if a particular sequence of failures and recovery steps was interleaved with other processing. This was a very subtle bug; the shortest error trace exhibiting the bug contained 35 high level steps. The improbability of such compound events is not a defense against such bugs; historically, AWS has observed many combinations of events at least as complicated as those that could trigger this bug. The bug had passed unnoticed through extensive design reviews, code reviews, and testing, and T.R. is convinced that we would not have found it by doing more work in those conventional areas.
<...>
B.M.’s first spec was for an algorithm that had a known subtle bug. The bug had passed unnoticed through multiple design reviews and code reviews, and had only surfaced after months of testing [выделение моё]. B.M. spent two weeks learning TLA+ and writing the spec. Using this spec, the TLC model checker found the bug in a few seconds [выделение моё]. The team had already designed and reviewed a fix for this bug, so B.M. changed the spec to include the proposed fix. The model checker found that the problem still occurred, but via a different execution trace. A stronger fix was proposed, and the model checker verified the second fix.
<...>
While our results are very encouraging, some important caveats remain. Formal methods deal with models of systems, not the systems themselves, so the adage applies; “All models are wrong, some are useful.” The designer must ensure that the model captures the significant aspects of the real system. Achieving this is a difficult skill, the acquisition of which requires thoughtful practice.
brooker.co.za
Use of Formal Methods at Amazon Web Services - Marc's Blog
👍10
#life #article
Writing Is Magic, или почему в принципе стоит писать. Речь, впрочем, идёт не о художественной литературе, а скорее о утилитарных текстах.
Writing Is Magic, или почему в принципе стоит писать. Речь, впрочем, идёт не о художественной литературе, а скорее о утилитарных текстах.
brooker.co.za
Writing Is Magic - Marc's Blog
👍7
Forwarded from Птица Говорун
История с «ЧВК Рёдан» - это прямо эталонный пример того, как старики не понимают ни молодых, ни интернет, ни современный мир.
Что произошло?
- Гопники увидели в торговом центре анимешников в странной одежде, пошли пояснять им за шмот и бить морду.
- Анимешники оказались сильнее и побили гопников.
- Это оказалось настолько смешно, что в интернете анимешников прозвали «ЧВК Рёдан» (отсылка к старому аниме «Хантер Хантер»)
- Другие гопники обиделись, пошли искать это «ЧВК» и начали нападать на случайных анимешников. Те дали сдачи
- Полиция пошла пресекать драки и задерживать людей
- Пресса начала писать, что «задержаны лидеры агрессивной группировки ЧВК Рёдан» (в реальности задерживали именно гопников)
- Депутаты начали заявлять о необходимости запрета японских комиксов
- Депутаты назвали «субкультуру Рёдан» деструктивной и посвящённой наркотикам и суициду
- В реальности никакой субкультуры нет и не было
- Но после всех этих публикаций и заявлений толпы школьников ради лулзов начали называть себя членами этой «ЧВК»
- то есть, это самосбывающееся пророчество или, не знаю, сюжет из «Маятника Фуко». Медиа и депутаты придумали ужасную группировку и описали ее, а дети по этому описанию по приколу начали действовать.
- поклонники аниме депутатам показались опаснее, чем нормальная здоровая субкультура гопников
- против анимешников объединились гопники, скинхеды и этнические группировки с Кавказа
- Украинские власти тоже в это все поверили и пошли искать «ЧВК» у себя (и «нашли» - то есть, сами случайно и создали).
Аааааа.
Что произошло?
- Гопники увидели в торговом центре анимешников в странной одежде, пошли пояснять им за шмот и бить морду.
- Анимешники оказались сильнее и побили гопников.
- Это оказалось настолько смешно, что в интернете анимешников прозвали «ЧВК Рёдан» (отсылка к старому аниме «Хантер Хантер»)
- Другие гопники обиделись, пошли искать это «ЧВК» и начали нападать на случайных анимешников. Те дали сдачи
- Полиция пошла пресекать драки и задерживать людей
- Пресса начала писать, что «задержаны лидеры агрессивной группировки ЧВК Рёдан» (в реальности задерживали именно гопников)
- Депутаты начали заявлять о необходимости запрета японских комиксов
- Депутаты назвали «субкультуру Рёдан» деструктивной и посвящённой наркотикам и суициду
- В реальности никакой субкультуры нет и не было
- Но после всех этих публикаций и заявлений толпы школьников ради лулзов начали называть себя членами этой «ЧВК»
- то есть, это самосбывающееся пророчество или, не знаю, сюжет из «Маятника Фуко». Медиа и депутаты придумали ужасную группировку и описали ее, а дети по этому описанию по приколу начали действовать.
- поклонники аниме депутатам показались опаснее, чем нормальная здоровая субкультура гопников
- против анимешников объединились гопники, скинхеды и этнические группировки с Кавказа
- Украинские власти тоже в это все поверили и пошли искать «ЧВК» у себя (и «нашли» - то есть, сами случайно и создали).
Аааааа.
🔥36😁9👍3❤🔥1