SOERDEV | клуб инженеров-программистов
رفتن به کانال در Telegram
SOERDEV - современный подход к разработке программного обеспечения. Вместе пытаемся разобраться как работать и развиваться в быстро меняющихся условиях рынка. Наша LMS - soer.pro
نمایش بیشتر1 557
مشترکین
+124 ساعت
+297 روز
+10630 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئیه '26
ژوئیه '26
+117
در 2 کانالها
ژوئن '26
+56
در 2 کانالها
Get PRO
مه '26
+135
در 1 کانالها
Get PRO
آوریل '26
+45
در 1 کانالها
Get PRO
مارس '26
+126
در 2 کانالها
Get PRO
فوریه '26
+149
در 2 کانالها
Get PRO
ژانویه '26
+81
در 2 کانالها
Get PRO
دسامبر '25
+48
در 1 کانالها
Get PRO
نوامبر '25
+17
در 0 کانالها
Get PRO
اکتبر '25
+50
در 1 کانالها
Get PRO
سپتامبر '25
+10 143
در 1 کانالها
Get PRO
اوت '25
+52
در 3 کانالها
Get PRO
ژوئیه '25
+50
در 3 کانالها
Get PRO
ژوئن '25
+55
در 3 کانالها
Get PRO
مه '25
+101
در 2 کانالها
Get PRO
آوریل '25
+54
در 3 کانالها
Get PRO
مارس '25
+8 027
در 4 کانالها
Get PRO
فوریه '25
+57
در 5 کانالها
Get PRO
ژانویه '25
+115
در 3 کانالها
Get PRO
دسامبر '24
+81
در 4 کانالها
Get PRO
نوامبر '24
+118
در 4 کانالها
Get PRO
اکتبر '24
+68
در 1 کانالها
Get PRO
سپتامبر '24
+404
در 3 کانالها
Get PRO
اوت '240
در 2 کانالها
Get PRO
ژوئیه '24
+1
در 2 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 23 ژوئیه | +5 | |||
| 22 ژوئیه | +2 | |||
| 21 ژوئیه | +6 | |||
| 20 ژوئیه | +3 | |||
| 19 ژوئیه | +6 | |||
| 18 ژوئیه | 0 | |||
| 17 ژوئیه | +5 | |||
| 16 ژوئیه | +11 | |||
| 15 ژوئیه | +10 | |||
| 14 ژوئیه | +4 | |||
| 13 ژوئیه | +5 | |||
| 12 ژوئیه | +5 | |||
| 11 ژوئیه | +9 | |||
| 10 ژوئیه | +7 | |||
| 09 ژوئیه | +4 | |||
| 08 ژوئیه | +4 | |||
| 07 ژوئیه | +1 | |||
| 06 ژوئیه | +5 | |||
| 05 ژوئیه | +1 | |||
| 04 ژوئیه | +9 | |||
| 03 ژوئیه | +6 | |||
| 02 ژوئیه | +4 | |||
| 01 ژوئیه | +5 |
پستهای کانال
Последний пост подсветил проблему, которую рассмотреть в рамках комментариев очень сложно. Это называется "синдром отложенной жизни", когда кажется, что сейчас - это не по-настоящему, что в будущем когда будут выполнены какие-то особые условия, начнется настоящая жизнь.
Мне кажется это интересная тема для дебатов, так что если среди моих оппонентов есть желающи пообщаться на тему нетворкинга, отложенной жизни, карьерного роста. То пишите на @soerdev можем попытаться что-то придумать.
| 2 | Стоит столкнуться с реальностью – и былая уверенность «если надо, выучу за одну ночь» куда-то испаряется, а вместо неё приходит понимание: без качественных хардов успешной карьеры в IT не построить.
Решил собрать топ заблуждений, которые умножают на ноль любые усилия по созданию карьеры в IT.
Главное получить первую работу, а там уже всё пойдёт само собой.
Сегодня IT не просто большое, оно огромное. Сейчас нет однородного набора стандартов, которые гарантированно соблюдаются в любой компании, – вместо этого каждый гребёт как может. Есть галеры, фирмы-однодневки, созданные для освоения бюджетов, с другой стороны – бигтехи с огромными амбициями и возможностями, а между ними сотни вариаций компаний со своими целями и задачами. Но нигде среди этого разнообразия нет людей, которые заинтересованы в том, чтобы взять ответственность за ваше развитие и построение карьеры. Всё, что вы достигнете в карьере, вы достигнете благодаря себе. Не надо иллюзий, что за вас кто-то будет развиваться, подбирать нужные задачи, искать новые пути.
И нет, я не призываю увольняться с первой работы, если она не идеальна. Но относиться к ней стоит как к полигону для отработки своих навыков, а не как к университету, который обязан вас доучивать.
Сейчас пойду к ментору, он меня научит всему, что надо, напишет правильное резюме, даст рефералки – и я легко пройду все ограничения и фильтры.
Это опять перекладывание ответственности и рафинированная жизненная позиция, которая вместо результата приводит в тупик. В первом пункте человек надеялся, что волшебным образом начнёт качаться на работе, во втором – надеется на не менее волшебного ментора, который точно знает, как надо.
Хороший ментор – это тот, кто помогает закрыть пробелы ваших знаний, а не завлекает кричащим маркетингом и обещаниями показать простой путь. Ваш основной капитал – это вы сами, а не сторонние помощники.
Чем больше резюме я разошлю, тем быстрее найду работу
Логика в этой идее присутствует, действительно: «под лежачий камень вода не течёт». Проблема в том, что рынок найма через резюме сегодня скорее мёртв, чем жив. Конверсия настолько низкая, что на рассылку резюме могут уйти годы. И в итоге человек тратит бесценное время вместо того, чтобы рассматривать проблему комплексно и использовать методы, которые работают.
Технические знания сегодня не нужны, ИИ способен заменить любого инженера.
На самом деле ИИ не способен заменить инженера. Все достижения ИИ сегодня лежат в области кода, и даже там не все задачи закрываются полноценно. Сегодня ИИ может с натяжкой заменить кодера, привыкшего копировать решения со StackOverflow, – инженерный стек пока остаётся за инженерами.
Попробуйте, вы ничего не теряете.
На самом деле теряете, причём теряете самое дорогое – время. Чем раньше человек осознает, что волшебные таблетки – это сомнительный товар, включит критическое мышление, посмотрит вокруг и посмотрит на тех, кто реально чего-то добился в IT, тем быстрее заметит: типаж успешных айтишников – это профессиональный инженер с хорошими техническими скилами и опытом решения сложных задач.
Посмотрите на их профили повнимательнее: у них за плечами не просмотр роликов «JavaScript за 2 часа», а глубокое понимание архитектуры, технической базы и, самое главное, идеи того, как помочь бизнесу и продукту. Это нарабатывается не за одну ночь перед собеседованием, и к этому нужно стремиться.
Кем быть – «темщиком» или «инженером», решать, конечно, вам, но помните: результат всегда зависит от того, что вы выберете.
Если выбираете инженерию – учите не фреймворки и языки программирования, а архитектуру, устройство процессов, теорию разработки. Если выбираете быть темщиком – то не зацикливайтесь только на резюме, ищите реферальные программы, общайтесь с инженерами, возьмите ответственность за свою жизнь на себя. Как известно, выход есть всегда, даже если вас съели. | 447 |
| 3 | Интересно разобрать на конкретном примере как архитектура может повлиять на развитие продукта. Опытные ребята помнят взлет и падение замечательного фреймворка Ruby on Rails (RoR). Изначально ставка была на быстрый старт, небольшой размер, быструю разработку (за счет высокой связанности модулей внутри фреймворка), работать с ним было легко и приятно за счет удобной консоли, позволяющие генерировать код по шаблону.
Как водится, проблемы архитектуры проявляются не на старте, а на этапе бурного роста. Со временем сильное зацепление стало мешать внедрению новых фич. Я как-то пытался вытянуть код отвечающий за Active Record и не смог этого сделать потому что связи были "всего со всем". При таком зацеплении нельзя не только "выделить" нужный код, но и заменить один подход на другой, например, хочется использовать гибкую ORM, но сделать это нельзя, так как все "прибито гвоздями". В итоге решения, принятые на ранней стадии, определили ограничения на более поздних стадиях.
Долгое время ROR сохранял позиции по популярности и активно применялся для MVP, но со временем стал сдавать позиции, особенно на фоне более модульного конкурента Merb. В 2008 году было принято стратегическое решение объединить усилия с Merb, чтобы использовать в Rails модульную архитектуру. Разработчикам ядра фреймворка пришлось пойти на тяжелый шаг - в третьей версии они начали рефакторинг в сторону модульности (во многом благодаря наследию Merb, в частности через Railties), но из-за того же исторического жесткого зацепления внутри кодовой базы полностью перестроить архитектуру не удалось, Active Record так и остался глубоко вплетен в ядро. Связанность на уровне сборки ослабла, но на уровне публичных API и привычек экосистемы глобально ситуация не поменялась.
Усугубило ситуацию то, что время было упущено, после 2010 года мир веба стал стремительно разворачиваться в сторону SPA и реактивных фронтенд-фреймворков, ROR со своей завязкой на MVC попытался переориентироваться на API бэкенд и тоже неудачно, тут свою роль сыграл не столько медленный Ruby (в API узким местом обычно является БД), сколько тяжелая модель параллелизма и высокое потребление памяти, из-за которых горизонтальное масштабирование обходилось дороже, чем у конкурентов (даже не самый лучший Node.js выигрывал у Ruby), поэтому в итоге архитектурные ошибки и сложности их устранения привели к потере популярности и превращению ROR в нишевый продукт.
Когда говорят "Неважно какая архитектура, если надо будет поправим", забывают, что практика показывает другое - продукты с хорошей архитектурой эволюционируют под меняющиеся требования, с плохой остаются в прошлом. | 535 |
| 4 | بدون متن... | 718 |
| 5 | Прикольно раскритиковали мои мысли о философии. Соглашусь, что в технических вузах это далеко не оснвоной предмет и я в нем не особо разбираюсь 👇👇👇 | 755 |
| 6 | Обсудили вчера на созвоне такую штуку, как "умение доносить свои мысли". Нам кажется, что те решения, которые мы принимаем на проекте, очевидны, понятны и логичны. Особенно это проявляется в архитектурных вопросах: "я хочу сделать так, разве можно как-то иначе?".
Оказывается, не только "можно", но и каждый участник обсуждения зачастую видит проблему совсем не так, как вы, а следовательно решение для него может быть другим.
Для себя не нужно ничего обосновывать, а вот для других членов команды это обязательно. В этот момент оказывается, что сформулировать свои мысли - задача довольно сложная. То, что в голове кажется понятным и очевидным, на словах выглядит уже не так уверенно. Я встречал ситуации, когда для общепринятых терминов (конвейер, очередь, шлюз и т.д.) люди придумывали свои названия или, не зная термин, просто объясняли его описательно. Со стороны выглядит как профессиональная некомпетентность.
Поэтому важно не замыкаться в себе и своих фантазиях, нужно пробовать общаться с коллегами, учиться формулировать мысли четко, знать и уметь правильно применять термины. Иначе всю жизнь будете мерить нагрузку "городами" и не понимать, почему соеры не воспринимают вас серьезно. | 991 |
| 7 | Кто бы мог подумать, что спустя 20 лет после окончания ВУЗа буду вспоминать темы по философии и делать это с таким удовольствием.
"Мыслю - следовательно, существую" - это явно не про LLM, поэтому мыслить за машину должны мы.
Ища ответ на вопрос "Как заставить ИИ мыслить?", оказывается, что эти вопросы уже имеют ответы в учебниках по философии, если совсем упрощенно: Платоновская диалектика - это готовая методика, помогающая составлять промпты, а Аристотелевская логика - это прямой набор требований к тому, как должен быть построен ответ, чтобы не содержать противоречий.
На всякий случай напомню, диалектика - это метод ведения диалога, при котором через столкновение противоположных мнений и наводящие вопросы рождается истина. Платон называл это майевтикой, искусством извлекать знание, а не вкладывать его.
Аристотель формализовал мышление: логические умозаключения, где из двух суждений выводится третье (силлогизмы) - это прототип того, как сегодня формируются промпты, чтобы ответы LLM были логичными и последовательными.
Вот и возникает вопрос "Так ли бесполезна эта философия?", если мы напрямую столкнулись с тем, что используем идеи этого предмета, правда, сами того не осознаем. | 1 066 |
| 8 | Часто замечаю, что в АйТи успешный продукт порождает обещания, которые превращаются в завышенные ожидания. Рано или поздно "пузырь", конечно, лопается, но осадочек остается.
Сейчас очень много шума вокруг автономных SDLC с использованием ИИ, бигтехи вкидывают жирные бюджеты в надежде, что еще чуть-чуть и появится та самая LLM, которая наконец-то сможет принимать решения не хуже инженеров. Проблема в том, что такая LLM все не появляется, а реальные возможности сильно скромнее ожиданий.
Скептически настроенные соеры видят, как бюджеты вылетают в трубу, и даже понимают, в чем глубинная проблема такого подхода. Любой сложный софт - это не сам код, а комбинация бизнес-аналитики, архитектурных решений, баланса требований и многих других аспектов, которые не имеют единственного правильного ответа. По сути, надежда на ИИ - это вера в чудо, которое непременно должно произойти, совсем скоро, буквально еще чуть-чуть и точно произойдет.
Если убрать завышенные ожидания и оттолкнуться от реальности, то окажется, что автономные внедрения - это утопия, конечная стоимость этой автономии - скрытые расходы на дополнительный персонал и ботситтинг. Освоение ИИ-бюджетов - это, безусловно, интересная игра, но статистика показывает, что цена неуклонно растет и не в пользу ИИ.
Если перестать гнаться за "автономностью" и надеждой сэкономить на инженерах, то по-прежнему остаются циклы, использующие идею "Human ON the loop" (т.е. человек проектирует цикл, а затем он выполняется самостоятельно) - это куда более реалистичный сценарий, который, правда, тоже сыроват, но хотя бы можно собрать рабочий прототип и посмотреть на вопрос с позиции практики.
Чего сейчас не хватает рынку? Как всегда - не хватает хороших примеров. Вместо тысячи слов и красивых презентаций нужно создать git-репозиторий, который на практике покажет как работают SDLC-циклы. Без такого примера все остальное - вода. | 1 016 |
| 9 |  Продолжаю перенос материалов сообщества на новую платформу.
Раньше у нас не было общей структуры для объединения материалов в рамках одной темы. Теперь у нас есть "Коллекции", которые созданы как раз для того, чтобы логически связать все видео.
Сегодня собрал коллекцию Технология разработки ПО | 894 |
| 10 | Есть, кстати, еще один момент, который хочется разобрать. Это возросший интерес к теме того как заставить ИИ выдавать детерминированный результат при написании кода, естествено, за разумное количество токенов.
Почему-то нам показывают много красивых демок в стиле "посмотрите что я навайбкодил за вечер", но как только речь заходит о каком-то системно воспроизводимом результате, то появляется куча оговорок и ограничений.
Еще интереснее, что каждые полгода появляются заявления "ну поход Х не работал, сейчас подход Y точно работает", а через полгода подход Y так же меняется на что-то еще.
Есть ощущение, что реальных задач, которые успешно решаются ИИ, не так уж много, так что верить или не верить - это дело каждого, но лично я стараюсь смотреть на ИИ без розовых очков. | 1 037 |
| 11 | Интересно наблюдать как люди заново изобретают вещи, которые давно описаны в книгах по архитектуре программного обеспечения. Приведу только три примера, но на самом деле их намного больше.
Вместо постановки одной задачи агенту, нужно делать агентские циклы. Агентские циклы - это новый подход к разработке.
Начнем с того, что "агентский цикл" - классический контур управления с обратной связью, известный в кибернетике со времен Винера. Агент итеративно подбирает параметры, пока состояние системы не совпадёт с целевым, никакого "нового подхода" в такой разработке нет.
Что не упоминается, так это то, что "принятие решений" лежит вне "цикла" и по-прежнему делается человеком. В этой части ничего не меняется и вряд ли изменится.
ИИ не умеет принимать решения, это должен делать человек. Так же человек должен говорить ИИ критерии приемки. Нуже Human in the loop или human on the loop.
Постепенно приходит понимание, что теперь разработка разделилась на macro-итерации (спринты, задачи, границы) и micro-итерации (автономные циклы агентов). Но глобально принципы остались прежними: человек должен сначала собрать требования, выделить бизнес-домен, провести анализ, выделить границы, распределить обязанности, потому что ИИ пока не умеет этого делать хорошо.
Вы должны воспринимать ИИ как помощника, но внимательно следить за кодом, котрый он пишет.
Здесь тоже хочется напомнить, что рефакторинг, парное программирование, ревью кода - это те практики, которые были всегда, они никуда не исчезли с появлением ИИ.
Классическое 'Make it work. Make it right. Make it fast' остается по-прежнему основным способом для поиска оптимального решения.
По факту у нас нет глобальной смены парадигмы, мы по-прежему работаем по канонам, разработанным за последние 50 лет, но есть новый инструмент с которым нужно учиться работать, не на уровне кода, но на уровне архитектуры: учиться строить грамотные процессы разработки ПО, учиться использовать архитектурные принципы и подходы и т.д.
Благодаря ИИ наконец-то появился стимул к развитию инженерных знаний, а не тупому копированию кода из stackoverflow. И мне кажется, что это лучше чем толпы программистов обсуждающих как лучше "красить кнопки". | 846 |
| 12 | Ну что, господа-соеры, поздравляю с очередной цифрой в копилке наших достижений - 1,5К подписчиков на этом канале.
Я обратил внимание, что темпы роста этого канала значительно выросли в этом году: за последние полгода мы прибавили почти в два раза. Что это значит?
Кроме того, что это приятная цифра, это доказательство того, что наши идеи работают и приносят пользу. Один из самых крутых инструментов, который мы прокачали за последний год, - регулярные встречи и фокус на технические знания.
Особенно ценно то, что у нас сложилась сильная команда с одной стороны есть эксперты, которые умеют в аналитику, с другой ребята, которым интересно прокачивать свои харды. В результате получается эффективный обмен опытом и знаниями.
На последнем курсе мы работали в командах, разрабатывали микросервисную систему, упирались в реальные ограничения, решали проблемы, учились проектировать и т.д.
На мой взгляд, практика - это лучший учитель, именно её мы активно используем для развития наших навыков.
Ещё приятнее осознавать, что мы лидируем в своей области. Мы сосредоточились не на пересказывании документации, а на обмене реальным опытом. Не зря я проводил консультации, работал с сотнями разных проектов, прокачивал насмотренность и умение проектировать сложные системы. Теперь вся эта сложность упакована в материалы и разбирается на созвонах.
Идея маленьких шагов работает почти незаметно. Казалось бы, год назад мы просто начали проводить встречи, сделали свои наборы материалов, начали постепенно разбирать вопросы монолитов, сервисов, микросервисов. Год пролетел незаметно, но кто-то за это время реально вырос, а кто-то просто откложил свой прогресс на потом.
Я вошел во вкус, поэтому продолжу упаковывать опыт в полезные материалы с фокусом на практику и постепенное движение к цели. На очереди у нас темы по ИИ и Observability.
Как постоянно бывает в жизни, кто-то снова использует это время с пользой, а кто-то продолжит ждать волшебную таблетку. Никому не навязываю свой выбор, но помните, что часики тикают.
Важно! Наше сообщество открыто для всех, и мы рады всем кто хочет развиваться вместе с нами. | 849 |
| 13 |  Интересно, насколько сообщество соеров вообще готово к тому, чтобы работать исключительно с ИИ. Хочу задать тебе прямой вопрос, если бы у тебя был выбор - работать с ИИ вместо реальных людей, или все же коллеги-люди для тебя важнее, то что бы ты выбрал? | 996 |
| 14 | Глеб Михеев поднял интересную тему - настройка параметров облака через внутреннего агента.
Мы у себя в рамках последнего курса пошли дальше - научились управлять облаком через Terraform, по сути у cloud.ru есть адаптер, через который можно управлять большей частью инфраструктуры. О том как это делат - вот тут (нужна подписка №2) | 1 510 |
| 15 | Говорить, что ИИ заменит человека, так же как говорить, что калькулятор заменит математика
Суть метафоры понятна, но ирония в том, что сама метафора подтверждает мысль, что придется конкурироваьт с ИИ на уровне кода, но не архитектуры.
1. Математик не конкурирует с калькулятором, просто потому что математик - это скорее архитектор, а не кодер. Он работает с теоремами, абстракциями, доказательствами, а не считает, что-то на калькуляторе.
2. Была такая профессия "вычислитель", вот у этих ребят как раз возникли проблемы с появлением вычислительной технике, им пришлось конкурировать со сособностью быстро и точно считать, и по итогу победили машины.
Любые метафоры неточны, важно понимать, что конкуренция возникает когда возникают общие функции, у хороших инженеров много функций, которые не пересекаются с ИИ, а вот у чисто кодеров пересечений много. | 5 841 |
| 16 | На мой взгляд видео уже устарело. Могу согласиться, что большинство моделей не могут в хорошую архитектуру. Но стоит попробовать новейшие модели - GLM-5.2 или топовые Клода, как понимаешь, что архитектуру он делает лучше, чем большинство разработчиков.
Это очень опасное заблуждение, которое возникает из-за того, что на уровне кода (одного приложения) ИИ может выдавать результат, который работатет (проходит тесты). Архитектура системы - это другой разговор.
Первый: архитектура оценивается не в моменте, а на дистанции. Хорошая архитектура позволяет сопровождать и развивать систему в течение длительного времени. Проблема в том, что даже самые сильные ИИ-модели принимают решения, которые накапливают техдолг - неверные границы доменов, жесткое зацепление, слабая связность, дублирования и т.д. На дистанции 2–3 месяцев (без человеческих корректировок) внесение изменений в проект порождает эффект домино и кучу побочек. ИИ не "видит", какие части системы меняются синхронно, какие требуют унификации в виде общих интерфейсов и абстракций, часто LLM создаёт распределённый монолит, вместо микросервисов и т.д.
Второй момент — есть разница между архитектурой приложения (архитектура на уровне кода) и системной архитектурой. По приложению довольно много типовых схем, которые ИИ может воспроизвести и под контролем человека даже более-менее сопровождать. Системная архитектура - это всегда компромисс между стоимостью, рисками и конкретными ограничениями: бюджетом инфраструктуры, легаси, требованиями регуляторов, реальной командой, которая будет это развивать. ИИ выдаёт архитектуру которая не учитывает нюансов, эта архитектура некая средняя температура по полате, которая получиалась из кучи схем, используемых в обучении, В результате решения не соответствуют конкретной ситуации и не решают проблем системы. | 5 270 |
| 17 |  Количество опубликованных iOS-приложений заметно выросло за последний год, а вот с пользователями по-прежнему проблема. Сможет ли ИИ помочь с каналами сбыта, маркетингом, продвижением и прочими нюансами распространения? Сомнительно. Здесь важно помнить: приложением начинают пользоваться, когда оно приносит понятную и измеримую пользу — качественно и в срок. Проблема даже не в количестве, а в однообразии: очередной трекер привычек, очередной AI-чат, очередной планировщик — пользователь уже устал от этого раньше, чем скачал. | 1 102 |
| 18 |  Мы строили, строили и наконец построили. Теперь SOERDEV - это товарный знак.
Теперь есть только один настоящий SOERDEV, остерегайтесь подделок. | 1 160 |
| 19 | Год назад я поставил себе масштабную цель - обобщить свой опыт построения сложных программных систем и выпустить три курса: монолиты, сервисы, микросервисы.
Какие у меня были цели?
Я сторонник идеи, что знания, которые мы приобретаем, должны приносить конкретные практические результаты. Лекции должны быть связаны с проектированием и написанием рабочих систем, которые затем разворачиваются на реальной инфраструктуре. Меньше персональных заданий, больше командной работы.
Чего добились?
Во-первых, научились проводить полноценные групповые семинары с интерактивным взаимодействием на большом white board.
Во-вторых, смогли собрать команду с разным уровнем и опытом, в результате обмен опытом шел не только между мной и ребятами, но и между друг другом.
В-третьих, от индивидуального формата перешли к командной работе, которая включает проектирование и реализацию проектов.
Если на монолитах каждый делал свой монорепозиторий со своим проектом, то на микросервисах уже совместный проект, где у каждого свой микросервис и общая инфраструктура (включая репозитории на gitlab).
Что это дало участникам?
- Опыт разработки проектов с документацией: требования, ограничения, пользовательские истории, ADR. Важно, что у нас документация стала частью процесса, а не отдельной задачей под конец.
- На практике попробовали разные варианты проектирования - C4, Event Storming, DDD и т.д. Обкатали каждый подход на реальных задачах, поняли, что применимо, а что нет.
- Научились проводить границы приложения, разделять обязанности. Много копий было сломано вокруг деления по зонам ответственности, и это тоже было очень полезно.
- Научились формулировать свои мысли, отстаивать и защищать своё решение. Я всегда фокусировал внимание на том, что нужно учиться объяснять, *почему* мы принимаем то или иное решение, а не просто отмахиваться общими фразами.
Я надеюсь, что эти знания все участники будут применять на своих рабочих проектах, грамотно выстраивая процессы с самого начала.
Какие планы на будущее?
Следующая цель - курс по оркестрируемым агентным системам. Старт в конце августа или начале сентября, скоро определюсь с датами. В ближайшее время проведу несколько активностей по разработке: круглые столы, мастер-классы, семинары для разных уровней подписок. В общем, все в том же ключе, только дальше и глубже.
Это, кстати, последний набор материалов в формате "курс", далее я хочу попробовать более легкий формат клубной работы - регулярные практические семинары, интенсивы и обмен опытом по небольшим темам. Чтобы не грузить людей объемом информации, а брать отдельные темы и рассматривать их в течение 3-4 недель, затем перерыв и новая тема (примеры тем: observability, создание своего VPC, работа с требованиями и ограничениями и т.д.). Таким образом подписка начнёт по-настоящему работать, позволяя двигаться к цели короткими шагами, без затяжных изматывающих курсов, но с хорошим ритмом "работа/отдых".
Особенно радует, что у нас сохраняется команда, многие ребята продливают подписку, а это уже кое-что значит. Если год назад ориентироваться можно было только на мои обещания, то продление подписки - это уже понимание, что наши встречи приносят пользу.
Так что спасибо всем участникам, продолжаем работу. | 1 204 |
| 20 | С недавних пор мода на создание сообществ дополнилась желанием непременно делать свой продукт, сейчас приложения растут как грибы после дождя - создаются свои LMS, лендинги, приложения для проведения мок-собеседований, даже информационные ленты и блоги снова набирают обороты.
Все потому что создавать приложения стало "дешево". Я уверен, что большая часть новых решений почти полностью созданы ИИ. Все что нужно - один вечер и десяток другой промптов с уточнениями и исправлениями.
Но если на старте творить с помощью LLM весело и задорно, то со временем наступает проблема, о которой я рассказывал на последней встрече клуба - инкрементальные обновления накапливают ошибку. В итоге LLM делает улучшение в одном месте, и забывает сделать правки везде, где нужно, в результате старые сценарии отваливаются.
Раньше как было? Есть несколько популярных OpenSource решений, есть авторы этих решений, есть комьюнити, все вместе устраняют баги, выпускают новые версии, чтобы в конечном итоге мы с вами могли поставить готовый софт себе на проект и не ломать голову над проблемами и ошибками. Нет, конечно, запрошенных проектов на GitHub всегда хватало, но они часто не доживали до стадии MVP и поэтому были не так заметны.
Думаю, что эйфория закончится быстро, постепенно созданные приложения (которые теперь многие именуют не иначе как "свой бизнес") перестанут обновляться, развиваться и постепенно сойдут на нет. В итоге останутся единицы, которые будут действительно нести пользу и предлагать что-то уникальное, в первую очередь за счет содержания, а не формы. Потому что форму теперь за копейки скопирует любой, а уникальный опыт, знания или экспертизу - нет. | 994 |
