Лаборатория Математики и Программирования Сергея Бобровского

"Чем более масштабируема сеть, тем более централизованной она становится, и в конечном итоге все эти ваши "масштабируемые" криптовалюты будут делать то же самое, что и обычный процессинг кредитных карт" (с) Гради Буч все криптопроэкты -- это зашкваренные версии классических highload-архитектур, старайтесь не вляпаться в 2022-м :) с Наступающим! 🎄

+16 Важные коаны проектирования :) - плоское лучше, чем вложенное; - разреженное лучше, чем плотное. Да, и конечно, если реализацию вашей схемы проектирования вам сложно словесно объяснить хотя бы котику -- значит, сама идея плоха. Переделывайте :)

8 когнитивных багов начинающих архитекторов распределённых систем: - сеть работает надёжно; - задержка нулевая; - полоса пропускания бесконечна; - сеть безопасна; - топология сети неизменяема; - стоимость трафика нулевая; - сеть гомогенна (только винда например :); - для суппорта сети достаточно одного админа на удалёнке. Бонус: "больше не воспроизводится". Ну, недетерминированные системы пытаться покрывать классическими детерминированными тестами, очевидно, просто глупо. Правильно: проектировать систему в детерминированных моделях, допускающих распределённые вычисления.

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

Я вообще большой сторонник TDD, всегда к нему призываю, всегда рекомендую, потому что это первый шаг в направлении TLA+ (мышление спецификациями) и полноценных формальных методов в перспективе. Однако всё же надо честно признать, что когда тимлид вроде как по моим рекомендациям пытается "внедрять" TDD в своей команде, в 70% случаев получается карго-культ ))) Код становится ещё более хрупким, чем получался раньше до TDD, а у разработчиков при этом создаётся ложное чувство повышенной надёжности проэкта. Вроде бы все сущности аккуратно спроектированы, хорошо изолированы, все сомнительные места покрыты моками... Только вот интерфейсы всех компонентов, сюрприз! оказываются в итоге спроектированы так, чтобы успешно проходить тесты, а не быть удобными в работе ))) Ну блин, ребята... Поизучайте сперва материалы из Сильных Идей про три уровня думания о программе. Как уходить от кода (и от тестов для уровня кода) на логический уровень абстракций, которых в коде не может быть по определению, и которые и надо учиться выражать в виде формальных спецификаций, реализуемых далее в виде тестов... Ok, это моя недоработка :) В следующем году будем с этим очень плотно разбираться.

Чем отличается гуру от хорошего сеньора (10+ лет опыта)? Если вы сеньор, то вы (или какой-то другой сеньор) можете вписаться в подавляющее число ИТ-проектов самого разного профиля, и помочь большому количеству людей практически в любом таком проекте. Если вы гуру (20+ лет опыта), то вы можете вписаться уже лишь в относительное небольшое число весьма специфических ИТ-проектов :) и при этом только вы тот единственный человек, кто может помочь небольшому количеству людей в этих конкретных проектах.

Сегодня довольно активно применяется GraphQL, довольно часто ребята кто у меня занимается эту СУБД упоминают. Ну, GraphQL -- это своего рода WSDL/SOAP для миллениалов и поколения Z :) (рассказывал про это всё) Что будет следующим? web3 , что-то типа WSDL с сильной типизаций, с акцентом на семантику, и уж совершенно точно не JSON-ы.

Читаю "Real-World Cryptography" David Wong -- очень классный учебник, рекомендую и по теме, и не только: много bad/best practices, которые отлично подходят к повседневному программированию. Каждому уважающему себя миддлу-сеньору желательно изучить, в спокойном темпе главка в месяц, в алгоритмы/код особо можно не погружаться, достаточно понимания, всё очень хорошо объясняется, с картиночками для малышей :) Узнал из этой книги, что Майкл Хайден, бывший директор АНБ и ЦРУ, заявил “We kill people based on metadata” :) В связи с этим вопрос, насколько вы доверенная сторона, насколько ваши ИТ-системы спроектированы так, что гарантируется (в идеале формально) что к этим метаданным нету нежелательного доступа, что они не могут быть скомпрометированы, сфальсифицированы? Викиликс вот говорит, что в АНБ дела с этим не очень... Впрочем, везде с этим не очень; более попсовую по теме можно почитать "The Perfect Weapon" David Sanger. В частности, одну из рекомендаций Вонга для повседневных нужд перефразирую так: Вежливое программирование -- это идея проектной абстракции, проектных интерфейсов, которые трудно реализовать плохо. Будьте вежливы.

+15 "Разворачиваемость" вашего проекта (скорость лёгкость простота его деплоя) -- это одна из неотъемлемых, ключевых, абсолютно обязательных целей любого правильного проектирования.

Ну, началось! А я уже не один год говорю -- нейросетки это хорошо, но мир таки захватит AI на формальной логике :) В The NetHack Challenge 2021 (программы, мастерски играющие в легендарную рогульку) победил с ощутимым отрывом AutoAscend -- чистый символьный AI. Нейросетки тут не конкуренты, потому что они не умеют "думать стратегиями" и скорее всего никогда не научатся. Я на нетхак потратил когда-то наверное тысячу часов :) До Амулета Йендора добирался... P.S. И немного о грустном: в свежем Tortoise "The Global AI Index" Россия в мировой AI-гонке остаётся стабильно в третьем десятке, 32-е место. Мир с помощью AGI (символьного :) через 2-3 десятилетия захватят США + Великобритания, или Китай, на 99%. Довольно внезапно с 12-го на 5-е место (за год!) поднялся Израиль. Впрочем, нифига не внезапно: он на первом месте в мире по относительному финансированию темы AI и на душу населения, и по исследовательским работам.

Eric Von Reinhard, работавший ведущим программистом в швейцарском Google, в качестве лучшего языка программирования на перспективу в 2022-м рекомендует изучать Python. Отмечу только в дополнение к вот этому его аргументу "Companies compete all the time and they look for fresh developers who know a modern language… not the old Java and C++." что Python тащит сегодня с собой вообще всё, начиная с 1991 года, и почти всё из этого всего вам никогда не понадобится.

Если вы активно работаете с базами данных, или серверным программистом на бэке, и при этом не слышали о проблеме N+1 , то сейчас где-то заплакал котик.

Наблюдение: Python постепенно превращается в TypeScript 😁

+13 В продолжение темы библиотеки личных абстракций -- как её формировать? Отвечает Ричард Фейнман :) Когда его спрашивали, как стать гением, он советовал всегда держать в уме десяток отборных любимых задачек, и каждый новый лайфхак, каждый новый приём прогонять через все эти задачки и смотреть, как он сработает на них. Те, которые работают хорошо, и добавляете в свою библиотеку. Это примерно как своя тщательно отобранная и сформированная колода карт в MtG например (хотя все карты вроде как самостоятельны, но в то же время связаны определённой логикой друг с другом). Вы встречаете очередную задачку, очередной вызов -- и легко бьёте их своей супер-колодой! На любую проблему у вас есть работающее решение. А вокруг все офигевают: как он это делает? он гений!

Чтобы не получалось вот так и не возникало желания сбежать из айти: "Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни?" надо понимать прежде всего вот это. Не выгорание и не жажда новой жизни, а просто вы следуете неверной карьерной стратегии. Поэтому помогаю теперь по этим темкам индивидуально каждому занимающемуся.

Рекламные обещания Java: write once, run anywhere. Реальность: переписываете проект каждый раз как выходит новая версия Java, и молитесь, чтобы ваши контейнеры после этого продолжали работать.

+12 Стратегия развития в ИТ: формировать под профиль своей карьеры личную библиотеку абстракций, которые дают вам всё лучшие и лучшие результаты в ваших проектах, в вашем стеке, требуя при этом всё меньше и меньше ресурсов для реализации. Только не жадничайте, не жмотьтесь, не таите их, наоборот, смело рассказывайте другим. Окружающие вас бедолаги всё равно в 97% случаев не смогут этим воспользоваться, потому что сами привыкли жадничать на своих ничтожных крохах "знаний", и просто не верят, когда им объясняют например, что оказывается можно добиваться тысячекратной компактности кода :)

+10 Когда вам понадобилось в проекте что-то улучшить, не думайте об этом по схеме "что нового надо добавить" (какую очередную приляпку прифигачить :). Думайте по схеме "как получить результат, удалив что-нибудь из проекта". Удалив лишние функции, лишние классы, лишний код...

Сегодняшняя популярность Python и Java -- примерно то же самое, что популярность Microsoft Basic и Borland Delphi лет 20 назад, когда они годами оставались на пике популярности, и казалось, что ничто не сможет поколебать их доминирование. Не введитесь на "популярность" каких-то технологий, изучайте в первую очередь универсальные вечные вещи.

+9 Если у вас нет внутреннего интуитивного знания про O-большое, что определяет, сколь качественно вы реализуете требования, чувствительные к производительности, то вы никак не программист (не говоря уже об инженере-программисте). Вы притворяетесь, что пишете код. Настоящие программисты не только знают, как хотя бы приблизительно оценить O-большое для кода, который они пишут, но и учитывают это при использовании сторонних библиотек и готовых алгоритмов (в частности, дата-сайентистов очень касается, которые обожают юзать стандартные либы самым тупым способом из всех возможных). Начните хотя бы с того, что учитесь не писать вложенных циклов; а лучше, изучите азы сложности хотя бы вот на таком детском уровне. P.S. К тем, кто проходил мои курсы по АСД, не относится конечно.