Современность требует современных решений.

- Во, так получаем примерно 3-4 тысячи ботов на IoT. Тренируем их на таргет, скармливаем им правильный вывод страницы покупки, варианты неправильных, делаем связи между неправильными выводами и причинами, делаем сценарии. Для управления и тренировки юзаем три джаббер канала - один для отдачи команд, другой для ответов типа "статус", третий для ответов по задаче. Нужное файло кладем на крупные порталы для художников, типа девиантарта, завернув в джипег - там обычно канал на отдачу окей и секьюрити хуи пинают.
В назначенный день боты группы А волнами заходят на сайт и чекают страничку, с разными юзерагентами, на предмет изменений. Если изменения есть - сразу пробуют бай, если бай не прошел - репортят об этом во второй чат, оттуда уже джаббер-бот кидает в первый чат команду группе ботов Б, они начинают сайт волнами ддосить сином и смурфом, причем делают из себя сеть для прохождения смурфов на 1000-2000 узлов, получается эффективно. В паузах между атаками четко заходит первая группа и пробует бай, под разными юзерагентами, если бай все же прошел - репортит во второй канал и в третий выдает результаты. Если на сайте вылезает что-то новое, чего не было во время обучения ботов - то тоже кидает в третий канал, чтобы оператор успел вовремя среагировать и поменять профиль атаки.
- Эээ, напомни, а зачем это все?
- Покупаем лимитки сникеров и всякие supreme box logo hoodie для перепродажи.
- ...

Дети нашли единственный эффективный способ бороться с трекингом — заспамить систему невалидными данными. Приём известен с давних времён, даже сказка есть на эту тему. И этот подход очень раздражает корпорации, так как бороться с ним крайне тяжело.

В ИТ-образовании идёт явный перекос на кодинг и алгоритмы, всё остальное вообще не фокусе массового внимания: тестирование, архитектура, процессы, техподдержка и документация. При этом кодеры занимают ну процентов двадцать всей рабочей силы по моим оценкам. В последние годы немного выдвинулись operations (даже не знаю, как это по-русски адекватно называть, «сопровождение», наверное), но тоже с уклоном в программирование-кодинг (“devops”).

В итоге из ВУЗа выходит человек со знаниями алгоритмов, но совершенно без знания всего остального, что нужно на реальной работе. И насколько я помню, в вузах даже нет спецкурсов, где бы объясняли, как работает тестирование, трекинг задач, техподдержка и другие ИТ-роли в проекте. Доходит до маразма: новички воспринимают баги как персональные оскорбления, а тестировщиков как персонажей второго сорта. А потом искренне удивляются, что именно тестировщики уходят на лидерские и архитекторские должности.

«Индустрия ИТ» по факту вообще не является инженерной индустрией, а остаётся ремеслом.

Одно из ключевых понятий в системной инженерии — жизненный цикл (life cycle). Концепт достаточно простой и обычно все его сразу схватывают: жизненный цикл — это стадии, через которые проходит жизнь системы. При этом для систем из разных предметных областей жизненные циклы примерно одинаковые, их общую структуру можно описать так:

рождение → жизнь → смерть

В каждой конкретной системе эти элементы разбиваются на более точные фрагменты. В стандарте ISO/IEC/IEEE 24748-1 приводится очень информативная табличка с примерами жизненных циклов в разных областях.

https://twitter.com/bitfield/status/1225694437482721282?s=20

Очень рекомендую подписаться в твиторе на этого товарища, он постит очень толковые ссылки (не копии с HN) с очень толковыми комментариями.

Понятие роли в системном подходе — это очень мощный инструмент, который оказывается полезным в самых неожиданных местах. Вообще, этот концепт не является чем-то радикально новым или незнакомым, все им так или иначе пользуются. А его сила начинается (как и для других концептов системного мышления) с осознанности.

Осознанность позволяет вывести разные вещи на более высокий уровень мышления, чтобы их можно было корректировать при необходимости (для разных контекстов, например).

У кого-то встречал интересное наблюдение, что ролевому мышлению непосредственно учат только актёров, хотя этот навык необходим практически всем. И речь тут идёт не о внешнем поверхностном проявлении (типа изображать кого-то другого), а о глубоком осознании и погружении. Ведь по сути «играть роль» означает не буквальное превращение в другую личность, а превращение в личность, обладающую ключевыми фундаментальными свойствами целевой. То есть роль — это некий набор свойств (в общем случае необязательно даже личности, а даже вещи, например, или животного), который необходимо осознанно обработать в мозгу, чтобы максимально эффективно эти свойства затем воплотить в себе.

И когда начинаешь выводить этот концепт в плоскость осознанного сознания, возникает главный вопрос: А что же такое роль? Сразу же возникает идея, что роль — это набор «поведений», «взаимодействий», «реакций». И тут же возникает другой вопрос: А тогда получается, что любой человек (его поведенческая «проекция», аспект) в принципе только из ролей состоит? Мы всё время играем какую-то роль, сила актёров как раз в том и состоит, что они это осознают и поэтому играют эффективно. Они не притворяются, они действительно переключаются полностью в новый режим, полностью меняют поведение, реакцию и действия. Именно этого и нужно добиваться обычному человеку в обычной жизни.

Ну и под конец несколько примеров, хотя обычно именно с них всё начинается. Возьмём человека, скажем, Иванов Иван Иванович (ИИИ), это совершенно конкретный индивидуум, родился когда-то, где-то, прошёл через этапы «жизненного цикла» и продолжает их проходить. Какие роли играет ИИИ в жизни? Например, в семье_1 он выступает в роли мужа и отца. А в семье_2 — в роли сына. В поликлинике_1 он играет роль главного врача, а в поликлинике_2 — пациента (он там лечит зубы). Семья_1, семья_2, поликлиника_1, поликлинка_2 — это конкретные физические системы, играть роль можно только в них, нельзя исполнять роль в абстрактной семье, так как это вообще непонятно что. Очевидно, что для каждой из ролей требуется совершенно разное поведение. Однако это вот очевидно только на конкретных примерах. В других ситуациях без осознанности роли это совсем не так просто.

Возьмём для примера организацию, в которой работает Петров. У Петрова есть должность, он старший инженер-программист. Петров выступает в роли_1, когда он работает в отделе программирования и в роли_2, когда работает в отделе тестирования. Я специально выбрал такие абстрактные названия для ролей, чтобы подчеркнуть их внешнюю нечёткость. В такой постановке ситуации (когда мы роли разделили) уже становится понятно, что в них нужно вести себя по-разному, нельзя паттерны поведения из роли_1 использовать в роли_2. Например, в отделе программирования могут быть свои внутренние процессы, а в отделе тестирования свои, поэтому нельзя рассуждать в одном отделе, используя паттерны другого. Как минимум вас не поймут и вы не сможете договориться.

Итог: роли нужно вывести в область сознания, их нужно уметь выделять и применять правильно.

Тормознутость софта в банкоматах переходит все разумные границы. Это что-то запредельно кошмарное. Интервал между нажатием и реакцией часто одна-две секунды. Я пинкод не могу набрать быстро, так как нажатия «схлапываются», и должен после каждого нажатия смотреть на экран и ждать появления звёздочки. А если к этому приплюсовать тормоза и глюки сенсорных экранов… Тыкаешь на экран и не знаешь, то ли тыкнул недостаточно уверенно, то ли просто всё тормозит.

Это началось примерно год как массово, до этого всё было относительно хорошо, а теперь почти везде стабильно плохо.

В системной инженерии и системном мышлении оказалось неожиданно много науки и (западной) философии. Чтобы по-настоящему понять, нужен солидный научный и методологический багаж, который на данный момент пока только в вузах дают (но не все берут). Причём на этой науке и философии основана вся система мышления, без освоения которой полноценно использовать системный подход невозможно в принципе.

Наверное, сильные методологи и педагоги смогут рекомпозировать обучение так, чтобы стало понятно, скажем, детям или школьникам, но я пока не встречал такого. Есть, конечно, попытки (раз и два, например), но они всё равно концептуально очень сложны и неочевидны для детей. В общем, школьного учебника не нашёл. Речь, естественно, про англоязычные, в русском языке такое искать бессмысленно. Есть какие-то начальные курсы, но там так себе.

Теория вероятностей и математическая статистика — это, пожалуй, самые сложные топики, с которыми мне приходилось сталкиваться во время учёбы в вузе. Во многом из-за их контринтуитивности, когда понятие означает не то, к чему мы привыкли в бытовом лексиконе, или когда правильный ответ конфликтует с ожидаемым (самый известный — парадокс дней рождения). В итоге вся популяция студентов чётко разделилась на две группы: кто сразу всё понял и кто не понял, но как-то что-то заучил, чтобы сдать экзамены.

Причём тервер ещё как-то можно было понять, а вот матстат — это ад.

Современной прикладной социально-психологической философии пост: https://twitter.com/G_S_Bhogal/status/1225561131122597896?s=20

Достойно оформления отдельным постом.

Думаю, процентов девяносто карточек-пропусков (которые нужно к датчику прикладывать, чтобы в офис пройти) копируются на простейшем оборудовании за секунду. При желании их можно награбить пачками в ближайшей к офисному зданию столовой.

У меня совсем не прижился UML. Я честно пытался его втащить в рабочие процессы, но не взлетело. Единственный прижившийся тип — sequence diagrams. Class diagrams не прижились, так как у нас нет классов, а остальное такая эзотерика, что вообще не находит понимания ни у кого из участников.

Вообще, семантика UML очень сложная и я не встречал ни одного человека, который бы её понимал досконально (для всех типов диаграмм!)

Куча программистов любит декларативщину в (условных) конфигах, почему-то негласно считается, что функциональщина в конфиге — это плохо. И таким образом полностью исключают функциональный аспект из конфигурации, как будто этап конфигурации менее важен, чем операционный.

И ещё один отличный тред про инциденты и как с ними справляться:

https://twitter.com/SwiftOnSecurity/status/1226672245705232384?s=20

И ещё насчёт инцидентов. Самое главное — этот вопрос нельзя пускать на самотёк, обязательно должны быть готовые сценарии, как реагировать на проблемы. Обязательно должны проводиться тренировки персонала. Каждый участник должен знать и уметь отыгрывать свою роль в этом процессе. Психологический аспект очень важный, люди должны быть морально готовы ко взаимодействию и к возможной эскалации. Я лично на эти грабли наступал и понял, что был конкретно не готов и поэтому зафейлил часть процесса, так как просто боялся действовать, а опытный человек рядом повёл себя как мудак и никак не помог.

Тоже рекомендую подписаться в твиторе на этого товарища, пишет очень толков и очень предметно.

https://twitter.com/maxua

В русском языке, похоже, нет адекватного перевода слова emergence в значении “arising as a natural or logical consequence or outcome, appearing as or involving the appearance of something novel in a process of evolution”. И поэтому целиком заимствовали эмерджентность. Это понятие вообще ключевое для системного мышления и в англоязычных текстах встречается очень часто. В русском официально есть как минимум с 2006 года в Словаре иностранных слов Комлева.

Гарантированным признаком «энтерпрайзности» продукта является поддержка FTP. Этот мерзейший протокол там никогда не умрёт, наверное.

Слово «легаси» изначально никакой негативной коннотации не несёт. Просто почему-то стали называть старый говнокод словом «легаси» и понеслось.

Отличный текст в коммерсанте, как работает госуправление в РФ:

https://www.kommersant.ru/doc/4241879

Это отличный пример системы, которая работает по «контрольным показателям».