Саша Поломодов запилил книгу сайт про Систем дизайн и все что около. Саша давно форсит эту тему — круто, что у него дошли руки все это скомпилировать.
https://system-design.space/
https://system-design.space/
System Design Space
System Design Space — Главная, граф знаний, треки и материалы
Главная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.
🔥97👍2👏1
DDDevotion
В инженерных командах развитие часто пытаются рассматривать как индивидуальное качество: хочет человек учиться или нет. Кто хочет — вырастет, с остальными и возиться нечего. Мне в целом везло на коллег и компании. В большинстве случаев это были небезразличные…
Друзья, уже через час ждем вас на стриме, выбирайте удобную платформу и усаживайтесь поудобнее
Вопросы, кейсы, комментарии пишите в этом треде или в личку, если нужна анонимность
Youtube
Zoom
Велкам! 🎉
Вопросы, кейсы, комментарии пишите в этом треде или в личку, если нужна анонимность
Youtube
Zoom
Велкам! 🎉
YouTube
Мотивация, доверие и влияние в инженерных командах
Ася Исакова — организационный психолог (магистр Work, Organizational & Personnel Psychology) и приглашённый лектор университета Pompeu Fabra (Барселона). Почитать Асю можно в её канале Это База | Компас конгруэнтности (http://t.me/integritycompass).
👍5
Сегодня так много интересного!!!
1. Стрим с Владом Хононовым Loosely Coupled - Deep dive into coupling with Domain-Driven Design https://www.youtube.com/live/NGENigtNUck 🍾
2. Дискуссия Rebecca Wirfs-Brock и Mathias Verraes https://virtualddd.com/sessions/critically-engaging-with-models-a-conversation-with-rebecca-and-mathias/ 👏
3. Финальный тур ЛЧ 🙈
1. Стрим с Владом Хононовым Loosely Coupled - Deep dive into coupling with Domain-Driven Design https://www.youtube.com/live/NGENigtNUck 🍾
2. Дискуссия Rebecca Wirfs-Brock и Mathias Verraes https://virtualddd.com/sessions/critically-engaging-with-models-a-conversation-with-rebecca-and-mathias/ 👏
YouTube
Loosely Coupled - Deep dive into coupling with Domain-Driven Design
Welcome back to "Loosely Coupled," the Live Stream series brought to you by BridgingTheGap.eu.com!
“Context is king!” - I hear very often now, as we dive into various discussions about software architecture. “It depends” - is something I often say, and I…
“Context is king!” - I hear very often now, as we dive into various discussions about software architecture. “It depends” - is something I often say, and I…
🔥12❤8
Альберто Брандолини с командой выкатили паттерны для проведения Event Storming
https://www.eventstorming.com/patterns/
Рекомендую ознакомится, но кажется главная проблема теперь как позвать агентов на такой воркшоп
https://www.eventstorming.com/patterns/
Рекомендую ознакомится, но кажется главная проблема теперь как позвать агентов на такой воркшоп
EventStorming
Eventstorming Patterns - EventStorming
A growing selection of patterns and antipatterns to handle your workshop design and facilitation. We have been there too!
🔥15👍3💯2
Завидую джавистам в том что у них есть такие спикеры как Алексей Шипилёв (рассказывает всякое про сборку мусора) и Андрей Бреслав
Очень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlin
Очень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlin
Pragmaticengineer
The programming language after Kotlin – with the creator of Kotlin
Andrey Breslav, creator of Kotlin and founder of CodeSpeak, shares lessons from designing Kotlin and why he’s building a new language to keep humans in control in the age of AI.
в свете использования LLM для разработки людя много обсуждают покупать или строить. Если смотреть с позиции DDD, то все однозначно: generic сабдомен покупаем, core саюдомен строим сами, supporting -- как получится.
Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?
Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!
Когда вы берете готовый продукт, вы получаете не только код, вы покупаете:
- некую готовую методологию решения проблемы
- тонны продуманных и решенных корнер-кейсов
- какую-никакую секурность
- решенные инфраструктурные вопросы
- потенциальное развитие
Когда все таки кодить/вайбкодить с нуля имеет смысл?
1. На рынке нет устоявшихся/готовых решений для вашей проблемы. В том числе из-за санкций или других ограничений.
2. У вас какие-то специфические требования (реально специфические, а не просто "мынетакиекаквсе"). Например, требования регулятора или стратегическое решение компании. Но и то я бы начал с обзора опенсорсных решений под подходящей лицензией.
3. Вам нужен какой-то небольшой набор фич от огромного и дорогого сааса. Опять же можно посмотреть на конкурентов.
4. Когда продукт может стать частью портфеля компании. Если сфера SaaS близка компании и есть желание реализовать свою экспертизу в продукте, то вполне хороший повод стартануть такое как внутренний продукт. Но будьте готовы, что будут не только прямые затраты на разработку, но и на косвенные на адаптацию.
5. Вы крупняк и платить даже большой команде разработки заметно дешевле.
Вы начали уже вайбкодить что-то своё вместо подписки?
Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?
Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!
Когда вы берете готовый продукт, вы получаете не только код, вы покупаете:
- некую готовую методологию решения проблемы
- тонны продуманных и решенных корнер-кейсов
- какую-никакую секурность
- решенные инфраструктурные вопросы
- потенциальное развитие
Когда все таки кодить/вайбкодить с нуля имеет смысл?
1. На рынке нет устоявшихся/готовых решений для вашей проблемы. В том числе из-за санкций или других ограничений.
2. У вас какие-то специфические требования (реально специфические, а не просто "мынетакиекаквсе"). Например, требования регулятора или стратегическое решение компании. Но и то я бы начал с обзора опенсорсных решений под подходящей лицензией.
3. Вам нужен какой-то небольшой набор фич от огромного и дорогого сааса. Опять же можно посмотреть на конкурентов.
4. Когда продукт может стать частью портфеля компании. Если сфера SaaS близка компании и есть желание реализовать свою экспертизу в продукте, то вполне хороший повод стартануть такое как внутренний продукт. Но будьте готовы, что будут не только прямые затраты на разработку, но и на косвенные на адаптацию.
5. Вы крупняк и платить даже большой команде разработки заметно дешевле.
Вы начали уже вайбкодить что-то своё вместо подписки?
👍11❤6💯2🙈1
Опять про ллм- разработку.
Сейчас на работе у меня сложилась идеальная ситуация
Есть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)
Есть набор задач без горящих дедлайнов
Есть надежные процессы, которые не пропустят дичь на прод
Есть мое, как мне кажется, неплохое понимание прекрасного в разработке
И вот чувствую себя как на эмоциональных качелях: от восторга до полного разочарования и обратно.
Код он пишет и правда быстро, но с одной небольшой задачей я застрял уже на несколько итераций.
Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.
Но оказалось:
Тот токен который есть нельзя использовать для этого обращения
Передавать нужный токен в celery таску несекурно
Кэш основной аппки и селери разделен — нельзя использовать просто тот же метод получения токена
При переходе на треды могут начаться проблемы с утечкой коннекшенов.
И вот с каждой итерацией решение усложняется и усложняется, хотя на старте казалось что там «пять минут работы программиста»
И пока что я не понимаю что делать с подобными задачами. Изначально они все выглядят одинаковыми по сложности
Сейчас на работе у меня сложилась идеальная ситуация
Есть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)
Есть набор задач без горящих дедлайнов
Есть надежные процессы, которые не пропустят дичь на прод
Есть мое, как мне кажется, неплохое понимание прекрасного в разработке
И вот чувствую себя как на эмоциональных качелях: от восторга до полного разочарования и обратно.
Код он пишет и правда быстро, но с одной небольшой задачей я застрял уже на несколько итераций.
Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.
Но оказалось:
Тот токен который есть нельзя использовать для этого обращения
Передавать нужный токен в celery таску несекурно
Кэш основной аппки и селери разделен — нельзя использовать просто тот же метод получения токена
При переходе на треды могут начаться проблемы с утечкой коннекшенов.
И вот с каждой итерацией решение усложняется и усложняется, хотя на старте казалось что там «пять минут работы программиста»
И пока что я не понимаю что делать с подобными задачами. Изначально они все выглядят одинаковыми по сложности
🔥13❤3👍1
в свете утекшей кодовой базы claude code в сети опять обсуждают применимость чистого/совершенного кода в современных продуктах.
Основной тейк одной из сторон: фу таким быть, ужасный код и тп.
Им в ответ пишут: ваши паттерны (ооп, солид и прочее) никому не нужны, код и так генерит тонны денег.
На мой взгляд ничего нового в этом конфликте нет, ллмки и вайбкодинг просто дали еще один повод это пообсуждать.
Можно ли создать прибыльный продукт без процессов, грамотных инженерных подходов на всех уровнях и всего хорошего, что описано в различных книгах от Брукса и ГоФ до Хононова и Клепмана? Конечно можно! Если вам повезло угадать нишу и время, то любой работающий код будет успешен.
Но на самом деле важен другой вопрос: влияет ли качество кода на итоговый успех продукта? Раньше в целом был консенсус: да, в качественном коде меньше дефектов, проще читать и вносить изменения.
Предположим, что мы полностью перешли на агентскую разработку и пишем "код" на естественном языке в жире или еще где. Что меняется? Во первых нам становится все равно на devex нашей кодовой базы. Если LLM "понимает" код и может вносить изменения, то может и пусть пишет как вздумается? Если надо, вообще перепишем все заново! Оставим пока что за скобками потраченные токены.
Но проблема в том, что мы пока что не научились все задачи отдавать на аутсорс агентам. И пока светлое будущее не наступило — я буду писать код по старинке. И требовать того же от агентов.
Если хочешь, могу разобрать отдельно: как именно должен выглядеть “LLM-friendly код” — там уже появляются довольно конкретные паттерны.
Основной тейк одной из сторон: фу таким быть, ужасный код и тп.
Им в ответ пишут: ваши паттерны (ооп, солид и прочее) никому не нужны, код и так генерит тонны денег.
На мой взгляд ничего нового в этом конфликте нет, ллмки и вайбкодинг просто дали еще один повод это пообсуждать.
Можно ли создать прибыльный продукт без процессов, грамотных инженерных подходов на всех уровнях и всего хорошего, что описано в различных книгах от Брукса и ГоФ до Хононова и Клепмана? Конечно можно! Если вам повезло угадать нишу и время, то любой работающий код будет успешен.
Но на самом деле важен другой вопрос: влияет ли качество кода на итоговый успех продукта? Раньше в целом был консенсус: да, в качественном коде меньше дефектов, проще читать и вносить изменения.
Предположим, что мы полностью перешли на агентскую разработку и пишем "код" на естественном языке в жире или еще где. Что меняется? Во первых нам становится все равно на devex нашей кодовой базы. Если LLM "понимает" код и может вносить изменения, то может и пусть пишет как вздумается? Если надо, вообще перепишем все заново! Оставим пока что за скобками потраченные токены.
Но проблема в том, что мы пока что не научились все задачи отдавать на аутсорс агентам. И пока светлое будущее не наступило — я буду писать код по старинке. И требовать того же от агентов.
❤30😁19💯3👍2
Вслед за Антропиком, Гитхаб копайлот анонсировал новые тарифы. Формально стоимость планов не поменялась, но мякотка в множителях и они вырастут в 3-9 раз.
О чем это говорит: самая частая версия в блогах— заканчиваются деньги инвесторов, надо показывать рост выручки и прочую ебитду.
Но по мне, это говорит, что мы прошли стадию early adoption. Изначально вендоры "доплачивали" за использование, чтобы затащить новую парадигму: собирали сценарии, доказывали ценность, формировали привычку.
Решена ли задача кодинга — нет конечно, еще много проблем, нестабильного и опасного поведения, нет еще устоявшихся паттернов использования и тд. Но что для меня однозначно: агентская разработка теперь с нами, прыгайте в этот поезд, еще не поздно!
О чем это говорит: самая частая версия в блогах— заканчиваются деньги инвесторов, надо показывать рост выручки и прочую ебитду.
Но по мне, это говорит, что мы прошли стадию early adoption. Изначально вендоры "доплачивали" за использование, чтобы затащить новую парадигму: собирали сценарии, доказывали ценность, формировали привычку.
Решена ли задача кодинга — нет конечно, еще много проблем, нестабильного и опасного поведения, нет еще устоявшихся паттернов использования и тд. Но что для меня однозначно: агентская разработка теперь с нами, прыгайте в этот поезд, еще не поздно!
👍22🙈3😁2
Необычный взгляд на платформы и их роль в разработке. В некоторой степени перекликается с идеей фреймворка Cynefin. Если вы в простом домене (а само по себе создание нового сервиса с дефолтным профилем нагрузки — это простой домен), то best practice (right choice, golden path) в виде платформы и принуждения ее использовать скажется позитивно.
Но затаскивать платформу туда, где chaos/complex домены — это стрельба по ногам. Вот бы еще научиться легко отличать одно от другого 😅
https://www.linkedin.com/pulse/%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8F%D0%B3%D0%BA%D0%BE%D0%B5-%D0%BF%D1%80%D0%B8%D0%BD%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-evgeny-konechnyi-ajcmf/
Но затаскивать платформу туда, где chaos/complex домены — это стрельба по ногам. Вот бы еще научиться легко отличать одно от другого 😅
https://www.linkedin.com/pulse/%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8F%D0%B3%D0%BA%D0%BE%D0%B5-%D0%BF%D1%80%D0%B8%D0%BD%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-evgeny-konechnyi-ajcmf/
Linkedin
Платформизация как мягкое принуждение
Недавно, пока был в спортзале, наткнулся на философский подкаст про «технику» с комиками. Звучало как сомнительная комбинация, поэтому я, конечно, включил и впервые услышал тезисы французского философа Жака Эллюля.
👍3💯1
Такое мы смотрим https://www.youtube.com/watch?v=K-Xv8D8NjTk
Я как дотнетчик со стажем начиная с версии 1.1 очень благодарен ему за язык и платформу
Я как дотнетчик со стажем начиная с версии 1.1 очень благодарен ему за язык и платформу
YouTube
TypeScript, C# and Turbo Pascal with Anders Hejlsberg
Anders Hejlsberg is a living legend and one of the most influential programming language designers of all time. He created Turbo Pascal, Delphi, C#, and also TypeScript. As well as that, he spent nearly a decade at the pioneering dev tools company, Borland…
🔥16❤1
Интересный взгляд на агентскую разработку через DDD-призму.
А как вы работаете с агентами? Знает ли ваш агент, с каким доменом он сейчас работает? Понимает ли, в каком слое системы находится задача?
Я пока часто отдаю задачу «под ключ», надеясь, что агент сам разберётся. Но если мы считаем, что кожаным разработчикам важно понимать тип домена, границы модели и слой, в котором они работают, то для ИИ это тоже важно.
И, на мой взгляд, не только через явные проверки, тесты и контракты. Агенту нужно давать саму архитектурную рамку и описание частей, чтобы он сам мог подстраивать стиль изменений под это
https://www.linkedin.com/posts/romanov-pavel_this-article-explores-how-mature-software-ugcPost-7459876259515461632-Uh8G
А как вы работаете с агентами? Знает ли ваш агент, с каким доменом он сейчас работает? Понимает ли, в каком слое системы находится задача?
Я пока часто отдаю задачу «под ключ», надеясь, что агент сам разберётся. Но если мы считаем, что кожаным разработчикам важно понимать тип домена, границы модели и слой, в котором они работают, то для ИИ это тоже важно.
И, на мой взгляд, не только через явные проверки, тесты и контракты. Агенту нужно давать саму архитектурную рамку и описание частей, чтобы он сам мог подстраивать стиль изменений под это
https://www.linkedin.com/posts/romanov-pavel_this-article-explores-how-mature-software-ugcPost-7459876259515461632-Uh8G
👍6