Сегодня в Лиссабоне завершается очередной websummit. Если в том году были стенды AWS, Google, MongoDB и других технических компаний, то теперь от разработческого осталось только трек FullSTK. Надеюсь, что это связано с неудачными заявлениями ex-CEO вебсаммита и на крупнейшей технологической конфе будет место разработчикам.

Уже в этот четверг к нам в гости придет Влад Хононов, автор книги «Изучаем DDD — предметно-ориентированное проектирование»

Получить ссылку на трансляцию👈

Влад инженер-программист, архитектор с более 20 лет опыта в небольших и крупных компаниях, в разных ролях — от вебмастера до главного архитектора.

Возможно, вы уже читали его книгу «Что такое предметно-ориентированное проектирование?», которую мы недавно перевели для вас и выложили на сайте Systems.Education — читать👈

Хотите задать вопросы по книге или узнать о DDD из первых рук? Приглашаем всех.

Кому может быть особенно интересно:

🧑‍💻Разработчику корпоративного программного обеспечения

👩‍💻Системному аналитику

👨‍💻Архитектору ПО

Начало в 19:00 МСК
Интервью на русском языке.

Получить ссылку на трансляцию👈

Domain-Driven Design — подход к проектированию систем, основанный на создании в проекте общего языка между заказчиками и разработчиками. Этот язык используется как для моделирования предметной области, так и для создания и именования объектной структуры программной системы, включая разбиение её на части, что особенно актуально для современной разработки.

Получить ссылку на трансляцию👈

Отличный алгоритм от Ивана @emacsway

Может я бы поменял какие-то нюансы, но в целом можно брать как базовую модель. Отмечу самые важные и часто игнорируемые пункты:
3 - про костяк. Никаких изменений без команды единомышленников не полетят!
8 - про фокус. Часто свежим взглядом мы видим пачку проблем. И все важные, и для всех у нас есть хорошее решение. Важно их подсветить, но с руководителем и командой договориться, что сейчас решаем только одну или две. Не бросаем, порядок следующих проблем проговариваем, но не прибиваем намертво.

Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу.

Я обычно делаю так (но я не советую за мной повторять из-за высоких рисков, просто у меня с моим польским характером по другому не получается):

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

2. На новом месте есть три месяца, чтоб осуществить изменения. Если за три месяца не удалось, то уже вряд ли получится. Нужно менять работу. В РФ это делать болезненно, ибо остается запись в трудовой, поэтому испыталку лучше оформлять по ГПХ. В Европе многие программисты работают как предприниматели, поэтому там проще: не понравилось - ушел, и никому об этом не говоришь просто.

3. На новом месте нужно пустить корни. Провести встречи 1to1 с программистами, понять кто и что из себя представляет. Выбрать костяк, узнать их проблемы, чем-то помочь и заручиться их поддержкой.

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

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

5. Итак, поддержка есть (мы же сформировали костяк, да?). Всегда найдутся недовольные, которые постараются подорвать авторитет неуважительными выходками. Шопенгауэр в помощь. Языком нужно владеть. Деликатно, острослово и пропорционально поставить выскочку на место. Важно не перегнуть и вовремя протянуть руку, когда человек "уже все понял". Обычно после одного-двух прецедентов больше желания ни у кого не возникает - включается внешний конформизм. Но если это сделать до формирования костяка поддержки, то есть риск попасть в опалу. Поэтому всегда нужно взвешивать силы поддержки и силы сопротивления.

6. Внимательно прислушиваемся к среде. Обычно там, где не хватает знаний, возникают конфликты, особенно на Code Review. Разруливаем конфликты путем интервенции знаний, чем зарабатываем авторитет. Пару раз подсказать - потом сами спрашивать начнут.

7. Противоречия между руководителями - это ваш ресурс. Читаем "Дао Лидера" Джона Хейдера, или Дао Де Цзинь в оригинале. Изучаем диалектику во всех её проявлениях. Учимся использовать эти внутренние противоречия для синтеза. Если этого не сделать, то есть риск скатиться в донкихотство. На этом этапе вы из себя силы пока еще не представляете. Поэтому, находим заинтересованные стороны действующих сил. Тонкая политика. Но мы архитекторы, а архитектура - есть суть разрешение противоречий. Если арх умеет их разрешать, ему не важно, это противоречие требований или противоречие между двумя топами.

8. Выявляем проблемы, по принципу Парето определяем с какой проблемы начать. Смело и решительно решаем выбранную проблему. Дерзновенно, твердо, буйно и радостно.

Если решили проблему менее чем за три месяца - ура, кредит доверия оправдан. Если не решили - бывает. Я в госах тоже не смог ничего изменить. Тогда нужно уходить на резервный оффер - дальше будет хуже. Я проверял. Kent Beck изменил индустрию, но не смог ничего изменить в Facebook. А Eric Evans написал свою книгу по DDD в порыве отчаяния, как финальный аккорд.

Если удалось осуществить изменения - тогда в помощь:
https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

Это мой собственный алгоритм. У меня это работало. Но это рискованный алгоритм. Я бы сам был бы рад поступать по другому, но не получается.

Сходил на митап про team topologies. Очень благодарен этим ребятам, что подняли тему когнитивной нагрузки. Наши коробочки не бесконечны, как бы это не казалось очевидным)

Если пропустили — рекомендую посмотреть)

Вышла запись интервью с Владом https://youtu.be/pwoBA88nAe0?si=ecbmJWJfzeYMH8IT

Классная заметка Кента Бека про TDD и быстрый фидбек (как один из важных аспектов разработки, имхо).

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

https://open.substack.com/pub/tidyfirst/p/tdd-isnt-design

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

С чего же начать, если вы всю жизнь пилили формы и мапили джейсончики работали с бизнес-приложениями?

1. Сперва пройти что-то базовое типа https://www.coursera.org/learn/ai-for-everyone от Andrew Ng. Освоить базовые понятия и ubiquitous language этого контекста.
2. Следующий пункт LLMs (aka Large Language Models). Здесь могу порекомендовать часовое интро еще одного Andrej https://www.youtube.com/watch?v=zjkBMFhNj_g
3. Если не хватит, то можно опять сходить на курсеру https://www.coursera.org/learn/generative-ai-with-llms.
4. Дальше облака. У всех ведущих провайдеров уже есть те или иные решения, посмотрите что предлагает ваш облачный провайдер (если в компании уже используется). Например, блоги от Azure https://learn.microsoft.com/en-us/azure/ai-services/openai/, Google https://cloud.google.com/ai/llms и AWS https://aws.amazon.com/generative-ai/
5. Иногда нам хочется немного донастроить/дообучить модель. На помощь нам приходит Fine Tuning. Можно пройти курс https://learn.deeplearning.ai/finetuning-large-language-models, чтобы получить практические навыки.
6. У Gen AI есть проблема. Его данные устаревают или вовсе отсутствуют доменные знания. На помощь идет RAG (или Retrieval-Augmented Generation)! Теперь мы можем дообогатить модель нашими собственными актуальными данными. Обзорное видео https://www.youtube.com/watch?v=T-D1OfcDW1M и курс https://learn.deeplearning.ai/building-evaluating-advanced-rag
7. Язык программирования. Исторически сложилось, что абсолютное большинство примеров будет на Пайтоне, так что рекомендую учить хотя бы базовый синтаксис, чтобы уметь читать.
8. Инструментарий. Здесь куча всего. Выделю https://www.langchain.com/ - фреймворк для всего того что я понаписал выше. Есть курс https://learn.deeplearning.ai/courses/langchain.

Хватит на новогодние?🙈

Поделитесь полезностями в комментах🙏

Ахтям Сакаев на днях опубликовал отличную статью https://habr.com/ru/companies/m2tech/articles/782986/

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

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

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

Обнимаю каждого, ваш Женя Пешков.
Пусть наше общение будет источником вдохновения!❤️

Ник Тьюн, известный своим вкладом в инструменты и популяризацию DDD в целом, дописал свою книгу Architecture Modernization. По содержанию и отзывам очень хорошая. Жду когда появится на платформе O'Reilly.

https://www.manning.com/books/architecture-modernization

У Саши Поломодова вышел подкаст с обсуждением книги Team Topologies. Если вам некогда читать — послушайте подкаст, возможно захочется погрузиться больше. https://youtu.be/q34rPXEErXA

Почитаем?🤓

В рилсах-тиктоке есть популярный поджанр: видеообзор. Обычно берется какое-то нашумевшее видео и ведущий добавляет свои (обычно негативные) комментарии.
Интересно, что этот тренд проникает в ИТ и в более длинные видео. Например, Adam Dymitryuk делал вчера такой стрим https://m.twitch.tv/videos/2077247644

А еще недавно узнал о формате совместного просмотра видео:
1. Выбирается доклад.
2. Смотрят вместе.
3. В любой момент любой из участников может поставить на паузу и накинуть/спросить.

Интересно было бы попробовать)

P.S. Стрим не смотрел 🙈

Классный референс для проектирования API, респект компаниям, которые собирают и шарят знания🔥

Postman, кроме того, что производит инструмент для тестирования API, ещё собирает лучшие практики проектирования.

Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.

Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)

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

На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)

🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires

🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа

🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset

🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям

🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept

🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)

Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.

Классная метафора Кента Бека про уровень воды во время прогулки по острову.

Несколько предположений:
- Вода всегда на одном уровне (нет)
- Следует во что бы то не стало забираться на вершину (нет)
- У нас только один остров (нет)
- Мы можем навсегда обосноваться на одном острове (нет)

Ну и в конце про мою любимую адаптивность:

Being prepared for both overland and underwater travel is the best preparation for software design success.

Подробнее в статье https://tidyfirst.substack.com/p/design-is-an-island, рекомендую подписаться ✍️