Чем отличается "разработка решения" от "реализации решения"?

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

Разработка решения выглядит так: "Я посчитаю дискриминант (по формуле D = b^2 - 4ac), затем посчитают по формуле корней (+-b - sqrt(D)) / 2a значения х1,х2"

Реализация решения - это уже готовый код, но можно описать в общем виде: "Я возьму Матлаб, создам новый документ, в нем заведу общие переменны a, b, c для квадратного уравнения виде ax^2 + bx + c, далее рассчитаю D, затем рассчитаю x1, x2"

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

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

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

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

Есть у нас группа для общения ютуберов между собой, называется "круги на поля IT" (https://t.iss.one/itkrugi), мы там обычно просто стебемся друг над другом, выкладываем кружки из жизни и в целом бездарно тратим ресурсы интернета.

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

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

Но что-то я слишком увлекся, если коротко, то в кругах мы сегодня знатно разъебали безграмотность современных экстримальных программистов, которые ляпнули глупость.

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

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

Вчера пообщались про школу №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

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