В пятницу была интересная дискуссия про то как следует коммитить. Я озвучил идею удаления кода, если он не может пройти тесты/линтеры/конвенции. На самом деле это не моя идея, я подсмотрел ее у Кент Бека, но даже не он автор (так бывает у великих художников). Подход называется TCR: test && (commit || revert)

Готовы такое попрактиковать на своей работе?)

Теперь и в наличии)

UPD: электронная версия, по информации из издательства, выйдет через 6-9 месяцев.

https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/

Когда речь заходит про корзины, то мне сразу вспоминается этот доклад https://www.youtube.com/watch?v=KkzvQSuYd5I

кажется, я его уже постил. Ну да.... А что вы, как говорится, мне сделаете?) всем хорошей пятницы 🛒

Вместо страшилки на хелоуин. Зумеры переизобрели Classic ASP (или JSP, кому что ближе)👻

Извините, сегодня не про DDD, но я уверен, что наша индустрия безвозвратно меняется. И проблемы которые мы обсуждали последнее время просто перестанут быть актуальными.
Например, создание кастомной GPT – нам больше не нужна база знаний, мы все наши знания (в том числе код) загрузим в GPT. И любой разраб сможет писать туда вопросы и новые знания. И доменные эксперты тоже. Причем они смогут не только загружать ответы, но и спрашивать «а как оно сейчас-то реализовано?»
Очень резонировал спич Сатьи про инфраструктуру – да, кто-то должен думать про электричество и сервера, но в итоге мы поднимаемся по слоям абстракций все выше. И новый уровень программирования уже на пороге. Только не понимаю пока что, какое знание/ценность условный я буду добавлять.

https://www.youtube.com/watch?v=U9mJuUkhUzk

Недавно Ахтям Сакаев поделился своим взглядом на агрегаты, рассказал какие проблемы он решал и к каким решениям пришел. https://youtu.be/WTu7EgYFYGU

Если вы из мира дотнет, или просто стараетесь отслеживать технологии вокруг, то не пропустите релиз дотнет 8 и конференцию https://www.dotnetconf.net

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

1. Native AOT - худые бинарники и быстрый запуск.
2. Dynamic PGO и прочее.

Ну и куча других докладов про новый c#12, ef8, blazor, etc.

Сегодня в Лиссабоне завершается очередной 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/

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

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

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

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