Это кстати не к тому, что всем нужно доверять себе. Если вы принимаете плохие решения, то доверять себе стоит только трижды все перепроверив. Доверие должно быть подтверждено опытом. Но стоит избегать ситуации, когда вы уже неплохо принимаете решения, но все равно себе не доверяете.

К предыдущей заметке надо кое-что добавить: доверие к себе не распространяется сразу на все аспекты жизни, как я сегодня выяснил.

Мне приснился сон: человек говорит мне в лицо, что собирается меня избить и пытать. Если ты понимаешь, что тебя попытаются убить, есть только один разумный выход: убить первым. Во сне я понимал это, но оцепенел и не решался. Проснулся со сжатыми мышцами и весь в поту. Я так и не узнал, осмелился я ударить первым или нет.

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

Видимо познание закончится только после смерти.

Хоба, сейчас попробуем, что мы там производим

#лабораторный_журнал

В компании проходит ассесмент (есть такое слово?) архитектуры, практик кода и всего такого прочего внешним консультантом. Я вышел на работу к его концу, поэтому увидел только результаты. Ожидал набор баззвордов про клин аркитекчу, но оказалось очень хорошо. Я понял, что человек понимает о чем говорит, когда дошел до пункта о том, что тесты это спецификация кода, а не QA. Этот аспект часто не понимают даже тертые калачи-сеньоры. Юнит-тесты это инвариант для вашего кода, а тесты в целом это инвариант для системы.

В целом советы такие: делайте Continious Integration, делайте Test Driven Development, гоняйте тесты автоматически в CI, делайте Continious Delivery (деплой в CI), пишите документацию, нарисуйте уже схему архитектуры.

И не делайте всякой херни:
* Не пишите тесты, которые ничего не проверяют.
* Не тестируйте на продакшн бд. Обычно в этом повинны фронтендеры.
* Не делайте прямых зависимостей сервисов от инфраструктуры. Захардкоженные connection string это зло. Нужно что-то из БД соседнего сервиса? Не лезь в БД, спроси API. Нужна какая-то нетривиальная обработка? Положи задачу в очередь сообщений.
Читаешь такие рекомендации и думаешь: неужели кто-то так делает? Потом вспоминаешь: да, все это делают, повсеместно. Страшно жить.

Так же узнал для себя много нового. Оказывается Git Flow это уже не модно, а модно Trunk Based Development. Выглядит как безумная ересь, но может я чего-то не понимаю. Так же есть нечто под названием Hexagonal Architecture, тут мне пока нечего сказать.

Если бы мне нужно было выделить две главные компоненты качества софта, я бы выбрал такие:
* Минимум связности (в смысле coupling)
* Тесты

Ассесмент с этим взглядом совпадает.

Из нового узнал про Mutant Testing.

Главная проблема с тестами всегда в том, что ты не знаешь, насколько твои тесты отлавливают проблемы. В пределе у тебя может быть 100% coverage тестами, которые ничего не проверяют.

Идея mutant testing: меняем код немного (например, там где в коде if True, ставим if False) и проверяем, провалились тесты или нет.

Вот инструмент для Python
https://mutatest.readthedocs.io/en/latest/

1. Находит тесты (подхватил pytest сразу)
2. Строит AST кода покрытого тестами
3. Случайно меняет AST в нескольких местах
4. Проверяет, упали ли тесты, затрагивающие места изменений.

Запустил, сразу обнаружилось пару мест, которые тесты не проверяют. Клевая штука.

Впервые увидел океан. Край континента! Ожидал, что это будет как сходить на море, но оказалось, что океан это стихия совсем другого масштаба.

4% - 16% шанс применения ядерного оружия в течение года по разным прогнозам. What a time to be alive.

https://astralcodexten.substack.com/p/mantic-monday-101722?utm_source=post-email-title&publication_id=89120&post_id=78827762&isFreemail=true&utm_medium=email

https://www.bloomberg.com/opinion/articles/2022-10-12/defi-discovers-new-market-manipulations

Так так, DeFi позволяет манипулировать ценами торгуя самим с собой с разных счетов. При этом такое почти невозможно провернуть с кожаными человеками из-за наличия у них т.н. common sense.

#лабораторный_журнал

Наблюдаю все плюсы и минусы работы в офисе. Мне очень помогает собраться. Всем синьорам явно не мешает, работают как машины. Джуны же точат лясы едва ли не больше, чем работают. Пока не понимаю: офис это net bad или net good. Пока что вывод, что офис это net good для middle+, net bad для джунов.

Настроение стать тираном и микроменеджить.

Разбираюсь потихоньку в оптике и камерах
https://ciechanow.ski/cameras-and-lenses/

#лабораторный_журнал

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

Для описания процессов на верхнем уровне мне нравится BPMN. Но Miro почему-то хочет за него дополнительных денег несмотря на платный тариф. Поэтому в качестве близкой альтернативы есть Swimlane Diagram.

Относительно архитектуры мне нравится C4 model. В отличие от других моделей не накладывает каких-то ограничений на то, какие именно квадратики надо рисовать. Просто передает общую идею: рисуем диаграммы на 4 уровнях детализации. На практике хватает двух: уровень сервисов, где каждый сервис это один квадратик, и уровень контейнеров, где каждый кусок софта (API, БД, Async job, Redis, RabbitMQ, итд) это один квадратик.

Довольно прикольный новый мир. Все эти разные способы рисовать квадратики напоминают мне разные фреймворки в программировании.

Неприятное интересное. Если твой доход в год >= 75 000 евро, то для налоговой ты попадаешь в категорию самых богатых людей. И платишь 48% налогов. Так вот он какой заветный top 1% (неожиданно бедный)!

Думал сделать лонгрид в стиле “обычный человек пытается разобраться в глобальном потеплении”. Понять, насколько угроза реальна, чем нам грозит увеличение средней температуры на четыре градуса, какие есть альтернативные взгляды и критика.

Оказалось, что разбираться не в чем. Вопрос не научный, а сугубо политический. Этот лонгрид уже существует в лучшем виде: на страницах википедии. Весь спор сводится к желанию или не желанию зайти и прочитать, может быть перейти по нескольким ссылкам и убедиться своими глазами.

Tldr: это буквально самая масштабная проблема в истории человечества. Если не случится чуда, то треть наших детей или внуков вероятно будут жить в условиях Сахары. Чуда скорее всего не случится, потому что оно требует кооперации примерно всех стран мира. Мы в первом мире почувствуем сильные эффекты уже лет через 15-30, так что нам повезло, мы застанем пиздец несравнимых масштабов при жизни!

Не могу не поделиться (и не орать)

Когда прочитал в ОТУСе вводную лекцию по Байесу и добавилось причин жить