Пожалуй, сегодня была самая мощная встреча соеров, обсудили много важных вопросов, рассказали истории из жизни, провели короткий стрим. Были ребята из Питера, Краснодара и Сочи.
Спасибо всем кто пришёл, было очень классно.

Вчера пообщались про школу №21 от Сбера. Основная фишка их обучения - отсутствие наставников, вместо этого каждый оценивает каждого (peer-to-peer). В процессе обсуждения приши к мысли, что процесс их обучения очень похож на то, что мы делаем в Naris. Например, у нас принцип peer-to-peer называется devs2devs, который гласит что сами участники делают ревью кода других участников.

У нас наставничество не совсем исключено, но сведено к минимуму, по сути у нас так же используется принцип "равный среди равных" и в рамках ревью нужно не просто высказать свое мнение, но и конструктивно аргументировать. Если компетенция команды в школе 21 ограничена уровнем учеников, которые в массе своей - джуны, то у нас компетенция ограничена людьми уровнем мидлов, которые часто приходят в проект. Мне кажется, что это куда лучше, когда действующие разрабы общаются между собой (поэтому собственно devs2devs, а не peer-to-peer).

Еще одно отличие Naris и школы 21 в том, что мы делаем один проект, но по всем правилам разработки. Т.е. структура работы ничем не отличается от хороших "боевых" команд, которые используют современные практики программирования.

Почему я вдруг решил вспомнить этот разговор и сравнить Naris и школу 21? Для меня это подтверждение моих мыслей о том как должно быть выстроено обучение разработчиков, которых нужно быстро ввести в специальность. Идея объединить людей вокруг проекта и делать практические вещи находит поддержку в очень крутых компаниях таких как Сбер или Хуавей. А это в свою очередь говорит о том, что путь выбран правильно и нужно продолжать движение в Naris.

DDD основное, что нужно помнить

В предметно ориентированном дизайне задачу построения архитектуры приложения можно разделить на две части "Стратегическую" и "Тактическую".

Стратегия

Определяется решением следующих вопросов:

- Выделением общего языка
- Созданием пользовательских историй
- Выделение домена приложения

При этом для архитектур с централизованным хранилищем данных DDD чаще бывает излишним, чем полезным, DDD стоит рассматривать если у вас минимум 30-40 пользовательских историй.

Стратегия оправдывает себя даже если вы не реализуете конкртеные шаблоны DDD в коде, так как позволяет прийти к единому пониманию предметной области, отделить бизнес термины от технических терминов.

Тактика

Включает в себя реализацию шаблонов для организации объектной модели приложения. В первую очередь выделяются слои приложения (от внутреннего к внешнему):

- Entities, Value objects, Domain Events, Aggregates
- Repositores, Domain Services
- Application services
- UI

Aggregate

Агрегаты - это абстрактное понятие, которое на диаграммах можно представить как "границу" всех сущностей (entities) и объектов значений (value objects), а в коде агрегат представлены "корнем агрегата", который как правило является сущностью, включающей в себя другие сущности.

Value Object vs Entity

Чтобы лучше понять когда что создавать помните:

- идентификация сущности делается по Id, value object идентифицируется всеми своими полями
- сущность имеет маскимально длинный жизненный цикл, объекты значения наоборот имеют очень короткий жизненный цикл
- сущности могут изменять свой стейт (спорно, но в целом так), объекты значения только создаваться новые, изменять старые не принято
- логика в объектах значениях обычно простая (объект делается "легким"), в отличии от сущностей


Domain Service

Чаще всего в доменные сервисы размещается общая логика, которую сложно связать с сущностями. Обычно доменных сервисов стараются много не создавать.

Репозиторий

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

Репозиторий - "один ко многим", может включать логику массовых операций.
Сущность - "один к одному", включает бизнес-логику и стейт.


#DDD #знания #теория

У Вернона стратегия включает: единый язык, предметная область, предметная подобласть, смысловое ядро, ограниченный контекст, карта контекстов.

Мне стоило пояснить, что в "домен приложения" входит карта контекстов и предметная область.

Хорошее дополнение.

#DDD #теория

Качать хардскилы программистов или улучшать методы тестирования?

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

Кратко тезисы "за тесты":
- развитие инструментов тестирования - это прогресс
- программист все равно будет ошибаться, поэтому "без тестов" лучше не получится
- хороший программист решает проблемы бизнеса и не более того

Кратко тезисы за "хардскилы":

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

Мысль моя вот в чем:

- тесты - это условно "средство контроля", а программисты - это условно "средства производства", невозможно улучшить качество итоговой продукции улучшая только "средства контроля", поэтому улучшать и углублять свои знания программисты просто обязаны, чтобы совершать меньше ошибок.

- Основные усилия должны тратиться на развитие кодовой базы проекта, а не на развитие кодовой базы тестов.

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

YouTube | RuTube | VK

Эх, вот так всегда:

1. Железячники говорят, путаешь наносекунды с микросекундами, неправильно называю развертку и делитель напряжения, гребенкой называю осцилограмму, и вообще все не то и все не так;
2. Сетьевики говорят, что я не помню на зубок 7-ми уровневую модель OSI, не помню структуру пакета IP, не различаю ACK от SYN и FIN, да и вообще все не так и все не то;
3. Системные разрабы говорят что я плохо дизассемблирую код, неверно называю инструкции, плохо знаю теорию компиляции, неправильно называю биты и байты, и вообще все не так и все не то;
4. Бэкендеры говорят, что я плохо знаю java и php, не умею пользоваться Maven  и композером, не шарю в фреймворках и вообще все не так и все не то;
5. Веб-программисты говорят, что я плохо знаю React, не умею в каррирование и монады, не помню наизусть http протокол, не пишу на WebAssembly да и в целом все не то и все не так;

А архитекторы вообще со мной не разговаривают...

Куда податься бедному Соеру? Чужой среди своих, чужой среди чужих...

На что вы долго смотрите, то вам и нравится или почему споры о том, что лучше бессмысленны.

Обычно люди уверены, что они выбирают лучшее на основе объективного сравнения всех конкурентов. На самом деле выбор сделан ещё до осознания потребности, а во многом даже возникновение "потребности" это не ваш выбор. Если интересно немного подорвать свои устои, то поищите в сети исследования на тему свободы выбора.

Для нас же важно то, что весь маркетинг построен на узнаваемости бренда, которая сводится к тупому повторению во всех утюгах, что бренд А хороший.

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

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

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

Если кому-то нравится смотреть на зарплату, софтскилы, тусовки, и лидеров мнения, то во многом нам будет трудно понять другу друга.

Напишите в комментариях на что смотрите вы?

P.s. и да, если вам кажется, что где-то там лучше чёс здесь, то это скорее всего значит, что вы больше смотрите куда-то туда, а не сюда.

Приятно, когда сотрудники ведущих компаний приходят к тем же выводам, что и ты. У меня есть отличный стрим по тех. долгу (конспект вот тут), а полное видео только для подписчиков на платформе

У меня фокус на конкретном описании способа оценки тех. долга (бальный метод, экспертная оценка) в статье от Google можно прочитать почему такой подход и есть "самый правильный"

CORS замечательная идея и боль в продакшене

Архитектура - это поиск баланса, как правило баланса между здравым смыслом и безопасностью. Известный факт, что если выполнить все требования подразделений безопасности, то система работать не будет от слова "совсем". Потому что даже укатанный в бетон и закопанный на два метра в землю системный блок с позиции безопасников не находится в безопасности.

CORS - обозначает "совместное использование ресурсов из разных источников" (Cross-Origin Resource Sharing). Идея сама по себе очень классная, особенно в мире, где веб вытесняет все другие способы взаимодействия. Удобно, например, когда у тебя есть один общий сервис, который используется из множества одностраничных приложений, это позволяет сделать separation of concerns (разделение ответственности), упростить сопровождение системы, наращивая и разделяя мощности.

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

А третьи лица это знаю и внедряют всякие зловреды, которые в тихую делают XSS атаки, сливая все ценное и не очень злоумышленникам.

В итоге для борьбы с проблемой используется старый добрый дедовский способ - запреты. Например, в preflight запросах (которые, кстати, тоже появились из-за требований безопасности) можно запретить отдавать cookie, а на сами эти запросы наложить жесткую политику ограничений, которая позволит точно определить кому и что можно сливать.

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

#CORS

Monitoring as code

Последние тренды АйТи перевести описание всей инфраструктуры в "код". Под кодом понимается не обязательно программный код, часто это YAML или JSON файлы, которые можно формировать полуавтоматическими или полностью автоматическими методами.

Такие файлы удобно генерировать "на лету". Это, вместе с облачными технологиями и виртуализацией, позволяет генерировать инфраструктуру под любые задачи, при этом делать это быстро.

Создание инфраструктуры через код получило название "Infrustructure as code" (IaC). Скорость создания и запуска в работу новых узлов составляет от нескольких секунд до десятка минут. Инфраструктура может расти как грибы после дождя, главное успевать накидывать ресурсы.

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

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

Чтобы быстро вносить изменения в конфигурацию системы мониторинга одной автоматизации недостаточно, нужен способ аналогичный созданию инфраструктуры - накатывать изменения через "код". Поэтому разработчики активно внедряют возможности управления средствами мониторинга через "код", это называется "Monitoring as code".

В итоге конфигурирование мониторинга становится частью процесса развертывания новой инфраструктуры и средства мониторинга отслеживают изменения сразу после их внесения.

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

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

#IaC #Monitoring #code #мысли

Вчера на стриме спрашивали какой nvim конфиг я использую. Я использую nvchad у него есть стартовый конфиг который для typescript

Я уже кидал ссылку на этот сетап ранее, но продублировать нетрудно. )

Кто не успел посмотреть вчерашний стрим в реале, может посмотреть его в записи

Какой язык программирования учить

Мне кажется, что самый верный способ выбрать язык - это посмотреть на рейтинг языков от компании, которой доверяешь. Мне нравится команда RedMonk, которые регулярно выпускают свой рейтинг уже много лет.

Пятерка лидеров почти не меняется и выглядит так: JavaScript, Python, Java, PHP, C#

Сам рейтинг смотрите вот здесь

Для платных подписчиков на платформе вышла вторая часть стрим с разбором примера анемичной модели DDD.

- Для просмотра нужно иметь подписку "Stream", которая стоит 350р.

- Чтобы быстро найти последние стримы есть вкладка latest на главной странице https://platform.soer.pro/#!/pages/overview/latest

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

Понятно, что они может какую типовую форму регистрации дёрнули, но, блин, это же просто митап!

Определенно Кандинский моя самая любимая генеративная сетка, вот пример для промпта "обложка для подкаста "программисты решают проблемы мироздания"

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

Внимание! Топик будет жестко модерироваться, так что только прикольные картинки.

Когнитивные измерения

Если отказаться от мысли, что программирование - ремесло, то расширять свой кругозор можно бесконечно. Одно из интереснейших направлений для изучения - это оценка качества кода. Здесь есть такая штука как "когнитивные измерения".

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

По моим наблюдениям программисты хорошо понимают, что такое "приращение", "транскрипция" и модификация, а вот с исследовательским проектированием возникают проблемы.

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

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

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

Смысл в том, что вы не просто "решаете проблему бизнеса", предоставив готовый код для прода, а в том, что ищете решение для проблем, которые есть у бизнеса. Обычно результаты такой работы делаются отдельно от основного проекта, а в проект выносятся только итоговые изменения в виде библиотек и модулей.