S0ER

Monitoring as code Последние тренды АйТи перевести описание всей инфраструктуры в "код". Под кодом понимается не обязательно программный код, часто это YAML или JSON файлы, которые можно формировать полуавтоматическими или полностью автоматическими методами. Такие файлы удобно генерировать "на лету". Это, вместе с облачными технологиями и виртуализацией, позволяет генерировать инфраструктуру под любые задачи, при этом делать это быстро. Создание инфраструктуры через код получило название "Infrustructure as code" (IaC). Скорость создания и запуска в работу новых узлов составляет от нескольких секунд до десятка минут. Инфраструктура может расти как грибы после дождя, главное успевать накидывать ресурсы. Большие инфраструктуры всегда вызывают сложности в сопровождении, даже при сравнительно высоких показателях устойчивости, с ростом инфраструктуры растет и количество точек где система может дать сбой - точки отказа. Поэтому точки отказа покрываются средствами мониторинга. Это нужно делать с той же скоростью, с какой растет сама инфраструктура. Отчасти проблема решается автоматическим исследованием сети и умением средств мониторинга определять что за "зверь" этот новый "узел", так же помогают типовые политики и архитектуры с проработанными правилами и ограничениями. Чтобы быстро вносить изменения в конфигурацию системы мониторинга одной автоматизации недостаточно, нужен способ аналогичный созданию инфраструктуры - накатывать изменения через "код". Поэтому разработчики активно внедряют возможности управления средствами мониторинга через "код", это называется "Monitoring as code". В итоге конфигурирование мониторинга становится частью процесса развертывания новой инфраструктуры и средства мониторинга отслеживают изменения сразу после их внесения. Использование кода для конфигурирования прекрасно еще и тем, что AI (в лице генеративных сетей) умеет генерировать код. Что так же расширяет возможности применения AI на задачи девопсов. Может быть даже в этом направлении ИИ покажет большую эффективность, чем в разработке ПО. Вывод из всей этой истории следующий - Айти не помогает ошибаться меньше, вместо этого оно помогает ошибаться быстрее. Подходы "as code" как раз и служат для повышения скорости развертывания систем, но не повышению стабильности работы систем.

CORS замечательная идея и боль в продакшене Архитектура - это поиск баланса, как правило баланса между здравым смыслом и безопасностью. Известный факт, что если выполнить все требования подразделений безопасности, то система работать не будет от слова "совсем". Потому что даже укатанный в бетон и закопанный на два метра в землю системный блок с позиции безопасников не находится в безопасности. CORS - обозначает "совместное использование ресурсов из разных источников" (Cross-Origin Resource Sharing). Идея сама по себе очень классная, особенно в мире, где веб вытесняет все другие способы взаимодействия. Удобно, например, когда у тебя есть один общий сервис, который используется из множества одностраничных приложений, это позволяет сделать separation of concerns (разделение ответственности), упростить сопровождение системы, наращивая и разделяя мощности. Но вот оказывается, что все что можно использовать во благо можно использовать и во зло. Так как веб никогда не проектировался как платформа для запуска приложений, то те же куки - это такой забавный вебовский рудимент, который порой хранит очень ценную информацию, которая ну никак не может быть предоставлена третьим лицам. А третьи лица это знаю и внедряют всякие зловреды, которые в тихую делают XSS атаки, сливая все ценное и не очень злоумышленникам. В итоге для борьбы с проблемой используется старый добрый дедовский способ - запреты. Например, в preflight запросах (которые, кстати, тоже появились из-за требований безопасности) можно запретить отдавать cookie, а на сами эти запросы наложить жесткую политику ограничений, которая позволит точно определить кому и что можно сливать. В итоге эти политики становятся сложными, разбросанными по разным местам, с кучей нюансов и дыр. Эксплуатировать CORS становится больно и неудобно. Куда проще все спроксировать на один домен и жить долго и счастливо... А сама идея CORS хороша, ну прям очень хороша.

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

На что вы долго смотрите, то вам и нравится или почему споры о том, что лучше бессмысленны. Обычно люди уверены, что они выбирают лучшее на основе объективного сравнения всех конкурентов. На самом деле выбор сделан ещё до осознания потребности, а во многом даже возникновение "потребности" это не ваш выбор. Если интересно немного подорвать свои устои, то поищите в сети исследования на тему свободы выбора. Для нас же важно то, что весь маркетинг построен на узнаваемости бренда, которая сводится к тупому повторению во всех утюгах, что бренд А хороший. Как только понимаешь, что выбором каждого человека уже давно и успешно манипулируют, становится проще понимать людей. В первую очередь нужно посмотреть на что человек "смотрит" большую часть своего времени. Тогда очевидно, что от него ждать и уже так не подгорает от явных несовпадений во взглядах. Чтобы бы вам было проще понять меня, нужно знать, что я смотрю на код, на архитектуру и на хардскилы. Мне нравятся именно эти вещи, а не лейблы, которые вешают на айти. Если кому-то нравится смотреть на зарплату, софтскилы, тусовки, и лидеров мнения, то во многом нам будет трудно понять другу друга. Напишите в комментариях на что смотрите вы? P.s. и да, если вам кажется, что где-то там лучше чёс здесь, то это скорее всего значит, что вы больше смотрите куда-то туда, а не сюда.

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

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

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

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

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, объект значение идентифицируется всеми своими значениями - сущность имеет маскимально длинный жизненный цикл, объекты значения наоборот имеют очень короткий жизненный цикл - сущности могут изменять свой стейт (спорно, но в целом так), объекты значения только создаваться новые, изменять старые не принято - логика в объектах значениях обычно простая (объект делается "легким"), в отличии от сущностей Domain Service Чаще всего в доменные сервисы размещается общая логика, которую сложно связать с сущностями. Обычно доменных сервисов стараются много не создавать. Репозиторий Во многом это чисто техническое решение для того, чтобы инкапсулировать (не обязательно скрыть, но собрать вместе) логику свзяывающую СУБД и приложение, в сущностях не должно быть логики сохранения в БД. Плюс репозитории отвечают за создание коллекций сущностей. Репозиторий - "один ко многим", может включать логику массовых операций. Сущность - "один к одному", включает бизнес-логику и стейт. #DDD #знания #теория

Вчера пообщались про школу №21 от Сбера. Основная фишка их обучения - отсутствие наставников, вместо этого каждый оценивает каждого (peer-to-peer). В процессе обсуждения приши к мысли, что процесс их обучения очень похож на то, что мы делаем в Naris. Например, у нас принцип peer-to-peer называется devs2devs, который гласит что сами участники делают ревью кода других участников. У нас наставничество не совсем исключено, но сведено к минимуму, по сути у нас так же используется принцип "равный среди равных" и в рамках ревью нужно не просто высказать свое мнение, но и конструктивно аргументировать. Если компетенция команды в школе 21 ограничена уровнем учеников, которые в массе своей - джуны, то у нас компетенция ограничена людьми уровнем мидлов, которые часто приходят в проект. Мне кажется, что это куда лучше, когда действующие разрабы общаются между собой (поэтому собственно devs2devs, а не peer-to-peer). Еще одно отличие Naris и школы 21 в том, что мы делаем один проект, но по всем правилам разработки. Т.е. структура работы ничем не отличается от хороших "боевых" команд, которые используют современные практики программирования. Почему я вдруг решил вспомнить этот разговор и сравнить Naris и школу 21? Для меня это подтверждение моих мыслей о том как должно быть выстроено обучение разработчиков, которых нужно быстро ввести в специальность. Идея объединить людей вокруг проекта и делать практические вещи находит поддержку в очень крутых компаниях таких как Сбер или Хуавей. А это в свою очередь говорит о том, что путь выбран правильно и нужно продолжать движение в Naris.

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

Напоминаю, что завтра в 10 утра в Сочи состоится грандиозная встреча соеров )

Есть у нас группа для общения ютуберов между собой, называется "круги на поля IT" (https://t.me/itkrugi), мы там обычно просто стебемся друг над другом, выкладываем кружки из жизни и в целом бездарно тратим ресурсы интернета. Но сегодня получился конструктивный разговор, который многим может быть интересен. Все началось с вброса ExtreamCode мол если бы кому-то были важны оптимизации, то Bool бы занимал один бит. Понятно, что любой соер в этот момент делает "рука лицо" и ворчит про "и эти люди говорят, что образование не нужно". Потому что для юзеров высокоуровневых языков, которые видят все через абстракции над абстракциями, кажется: "ну а чо? выделим один бит и делов-то, это бесплатно и очень просто". На самом деле, если раскрутить абстракции и понять, что реально адресовать один бит данных нельзя (почему смотрите на канале), то становится понятно, что это один байт выбран не потому что создатели компиляторов - ленивые идиоты, которые не догадались выделить один бит, а все ровно наоборот, просто программисты сегодня вообще не понимают о чем рассуждают (что, впрочем, не мешает им делать умный вид и красиво говорить на камеру). Как говорится, фронтендеры они и в Африке фронтендеры, чего с них взять? Нужно понять и простить... Но что-то я слишком увлекся, если коротко, то в кругах мы сегодня знатно разъебали безграмотность современных экстримальных программистов, которые ляпнули глупость.

г. Сочи, ул. Войкова 4В "Мой кофе" в субботу 1 июля в 10:00 Сходка настоящих соеров - только хардкор, только программирование, только те кто реально любит наше дело. 😎

1 июля повторим?

Чем отличается "разработка решения" от "реализации решения"? Поясню на примере, вот есть у нас задача "Решение квадратного уравнения". Оно будет состоять из двух этапов "разработка" и "реализация" Разработка решения выглядит так: "Я посчитаю дискриминант (по формуле D = b^2 - 4ac), затем посчитают по формуле корней (+-b - sqrt(D)) / 2a значения х1,х2" Реализация решения - это уже готовый код, но можно описать в общем виде: "Я возьму Матлаб, создам новый документ, в нем заведу общие переменны a, b, c для квадратного уравнения виде ax^2 + bx + c, далее рассчитаю D, затем рассчитаю x1, x2" Т.е. разработка решения - это описание общей логики (алгоритма) решения, а реализация - это конечное решение, которое решает поставленную задачу. Проблема в том, что когда надо "Разработать решение", очень часто вместо разработки делается общее описание реализации, которое по сути тот же код, но на псевдоязыке. Это неправильно, нужно развивать алгоритмическое мышление и отделать "логику" от "реализации".

У Димы подписчик задаёт вопрос о том, что ему скучно на работе, потому что ему не хватает задач. Подозреваю, что проблема а том, что чувак хочет делать только интересные ему задачи и не заниматься рутиной, которойу среднего разраба обычно 80%. Исключение - сильные программисты, которых никто не будет кидать на покраску кнопок. Поэтому хочешь решать интересные задачи - развивайся. Что значит "развивайся"? Это значит, самому искать слабые места в коде и улучшать их, изучать архитектуру, покрывать код тестами и фитнес функциями, инициировать обсуждения с коллегами. В любом случае если сидеть и ждать задачи - это приведёт только к стагнации. https://t.me/seniorsoftwarevlogger/1287