Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
S0ER
Відкрити в Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Показати більше📈 Аналітичний огляд Telegram-каналу S0ER
Канал S0ER (@softwareengineervlog) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 511 підписників, посідаючи 11 614 місце в категорії Технології та додатки та 61 742 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 511 підписників.
За останніми даними від 29 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -52, а за останні 24 години на 0, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 25.18%. Протягом перших 24 годин після публікації контент зазвичай збирає N/A% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 647 переглядів. Протягом першої доби публікація в середньому набирає 0 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 56.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як rbp, архитектура, callme, mov, указатель.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Завдяки високій частоті оновлень (останні дані отримано 30 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
10 511
Підписники
Немає даних24 години
-137 днів
-5230 день
Триває завантаження даних...
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
червень '26
червень '26
+23
в 0 каналах
травень '26
+77
в 0 каналах
Get PRO
квітень '26
+41
в 0 каналах
Get PRO
березень '26
+127
в 0 каналах
Get PRO
лютий '26
+159
в 2 каналах
Get PRO
січень '26
+42
в 0 каналах
Get PRO
грудень '25
+37
в 2 каналах
Get PRO
листопад '25
+27
в 0 каналах
Get PRO
жовтень '25
+31
в 0 каналах
Get PRO
вересень '25
+37
в 0 каналах
Get PRO
серпень '25
+53
в 3 каналах
Get PRO
липень '25
+51
в 3 каналах
Get PRO
червень '25
+48
в 0 каналах
Get PRO
травень '25
+41
в 2 каналах
Get PRO
квітень '25
+54
в 0 каналах
Get PRO
березень '25
+108
в 1 каналах
Get PRO
лютий '25
+110
в 0 каналах
Get PRO
січень '25
+56
в 1 каналах
Get PRO
грудень '24
+151
в 5 каналах
Get PRO
листопад '24
+203
в 4 каналах
Get PRO
жовтень '24
+81
в 0 каналах
Get PRO
вересень '24
+125
в 2 каналах
Get PRO
серпень '24
+171
в 2 каналах
Get PRO
липень '24
+244
в 5 каналах
Get PRO
червень '24
+164
в 5 каналах
Get PRO
травень '24
+245
в 4 каналах
Get PRO
квітень '24
+198
в 5 каналах
Get PRO
березень '24
+211
в 5 каналах
Get PRO
лютий '24
+307
в 2 каналах
Get PRO
січень '24
+323
в 4 каналах
Get PRO
грудень '23
+907
в 4 каналах
Get PRO
листопад '23
+190
в 3 каналах
Get PRO
жовтень '23
+218
в 2 каналах
Get PRO
вересень '23
+173
в 0 каналах
Get PRO
серпень '23
+247
в 0 каналах
Get PRO
липень '23
+273
в 0 каналах
Get PRO
червень '23
+195
в 0 каналах
Get PRO
травень '23
+2 925
в 0 каналах
Get PRO
квітень '23
+397
в 0 каналах
Get PRO
березень '23
+321
в 0 каналах
Get PRO
лютий '23
+221
в 0 каналах
Get PRO
січень '23
+798
в 0 каналах
Get PRO
грудень '22
+385
в 0 каналах
Get PRO
листопад '22
+229
в 0 каналах
Get PRO
жовтень '22
+645
в 0 каналах
Get PRO
вересень '22
+208
в 0 каналах
Get PRO
серпень '22
+153
в 0 каналах
Get PRO
липень '22
+186
в 0 каналах
Get PRO
червень '22
+241
в 0 каналах
Get PRO
травень '22
+402
в 0 каналах
Get PRO
квітень '22
+1 176
в 0 каналах
Get PRO
березень '22
+2 018
в 0 каналах
Get PRO
лютий '22
+25
в 0 каналах
Get PRO
січень '22
+41
в 0 каналах
Get PRO
грудень '21
+60
в 0 каналах
Get PRO
листопад '21
+26
в 0 каналах
Get PRO
жовтень '21
+63
в 0 каналах
Get PRO
вересень '21
+375
в 0 каналах
Get PRO
серпень '21
+185
в 0 каналах
Get PRO
липень '21
+122
в 0 каналах
Get PRO
червень '21
+20
в 0 каналах
Get PRO
травень '21
+35
в 0 каналах
Get PRO
квітень '21
+61
в 0 каналах
Get PRO
березень '21
+40
в 0 каналах
Get PRO
лютий '21
+39
в 0 каналах
Get PRO
січень '21
+41
в 0 каналах
Get PRO
грудень '20
+1 613
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 30 червня | 0 | |||
| 29 червня | +1 | |||
| 28 червня | 0 | |||
| 27 червня | 0 | |||
| 26 червня | 0 | |||
| 25 червня | +1 | |||
| 24 червня | 0 | |||
| 23 червня | 0 | |||
| 22 червня | +2 | |||
| 21 червня | 0 | |||
| 20 червня | +2 | |||
| 19 червня | +1 | |||
| 18 червня | +2 | |||
| 17 червня | +1 | |||
| 16 червня | +1 | |||
| 15 червня | 0 | |||
| 14 червня | +1 | |||
| 13 червня | +1 | |||
| 12 червня | +1 | |||
| 11 червня | +2 | |||
| 10 червня | +1 | |||
| 09 червня | 0 | |||
| 08 червня | 0 | |||
| 07 червня | 0 | |||
| 06 червня | +1 | |||
| 05 червня | +3 | |||
| 04 червня | +2 | |||
| 03 червня | 0 | |||
| 02 червня | 0 | |||
| 01 червня | 0 |
Дописи каналу
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
this.analyticsService.track("lesson_started", { userId, lessonId })
.catch(err => this.logger.error("Analytics failed", err))
}
`
Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс.
Получается три разных варианта, все рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой.
Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять проблемы и переписывать... Опять.| 2 | Три варианта. Один выбор.
Допустим, у нас есть задача реализовать user story:
Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.
Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
const subscription = await this.subscriptionRepository.findActiveByUser(userId)
if (!subscription || subscription.expiresAt < new Date()) {
throw new Error("No active subscription")
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
await this.analyticsService.track("lesson_started", { userId, lessonId })
}
Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять:
- Проверка подписки здесь, хотя должна быть в отдельном слое доступа.
- Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос.
- Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался.
- Аналитика блокирует основной поток.
- Нет уникального индекса на прогресс.
Учитывая эти моменты, можно сделать более надёжную реализацию:
async startLesson(userId: string, lessonId: string) {
return this.unitOfWork.execute(async (uow) => {
const user = await uow.users.findById(userId)
const lesson = await uow.lessons.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
const updateResult = await uow.users.updateOne(
{ _id: userId, tokens: { $gte: lesson.tokensCost } },
{ $inc: { tokens: -lesson.tokensCost } }
)
if (updateResult.modifiedCount === 0) {
throw new Error("Not enough tokens")
}
return await uow.progress.create({
userId,
lessonId,
status: "started",
startedAt: new Date()
})
})
}
Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности.
Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work.
Поэтому из перечисленных проблем, наверное, единственное, что достаточно универсально - это разделение обязанностей. Всё остальное - преждевременная оптимизация.
Итоговый вариант кода с разделением обязанностей выглядел бы так:
`typescript
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost }) | 2 681 |
| 3 | ИИ база
Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать.
Почему стали проверять знания ИИ?
Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM.
Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии.
Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу.
Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь:
Теория:
- промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д.
- контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д.
- обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»);
- архитектура агентов (включая команды агентов)
Практика
Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно:
- построить структуру проекта c учетом spec-driven development, ADR и т.д.;
- подобрать набор инструментов (в том числе MCP) и скиллов;
- разбить задачу на этапы (планирование, проектирование, реализация, контроль);
- решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен).
И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ. | 4 690 |
| 4 | Курс по микросервисам стартует 20.04.2026.
Продолжаю создание курсов по теме архитектуры. Ранее в сообществе были созданы коллекции материалов по сервисам и монолитам, и вот настала очередь микросервисов.
О курсе:
❗️ приоритет на проектирование, документирование и анализ (будем разбираться, как проводить границы, формировать требования, распределять обязанности и т.д.)
❗️ изучать можно индивидуально или общаясь в группе
❗️ еженедельные семинары с разбором проблем и консультациями (только для Подписки №3)
❗️ часть созвонов предполагает интерактивный формат круглого стола (например, общая Event Storming сессия)
Важно! Это не формат обучения. Нет никаких обязательных лабораторных работ, программы обучения и прочих вещей. Вместо этого — набор материалов, доступных по подписке, и обмен реальным опытом.
Можно просто смотреть лекции (для этого нужна Подписка №1), можно дополнительно смотреть мастер-классы (подписка №2), а для обратной связи приходить на семинары (подписка №3).
Наибольшая польза достигается за счет участия в семинарах: у нас собрана команда из 10 человек — это специалисты разного уровня, от архитекторов до новичков.
Мы обсуждаем не только информацию из курсов, но и практические вопросы, которые есть у ребят. Поэтому встречи — это отличный способ обменяться опытом, задать вопросы, получить информацию, которая выходит за пределы курса.
Количество участников на семинарах ограничено, сейчас есть 4 места, которые доступны, если вы приобрели подписку №3.
Важный момент! Подписка предусматривает доступ ко всем имеющимся материалам, встречам, созвонам и т.д., в общем, всему тому, что входит в подписку. Поэтому не надо думать, что подписка идет на курс: курс — лишь часть того, что есть в подписке.
Мы реализуем идею поэтапного развития (движения к цели короткими шагами), постоянно шлифуем свои навыки, собираем актуальную информацию, которую можно применять на практике, обмениваемся опытом и т.д., а подписка определяет уровень доступа.
Например, после курса по микросервисам планирую курс по архитектуре агентных систем, дополнительные созвоны, публикацию материалов в ИИ-лаборатории и т.д.
В общем, приобретая подписку, вы получаете не только курс, а участие в нашем сообществе и его активностях. | 0 |
| 5 | Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критрии качества.
Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты.
Оказалось, что "плохие" промпты работают ничуть не хуже чем "хорошие", т.е. все это время я делал промпты не понимая, что делаю "шляпу". В итоге я собрал те моменты, которые реально дают изменения, перестал писать портянки текста, больше фокуса на примеры и техники размышления и вот здесь уже удалось показать разницу.
А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал. | 0 |
| 6 | Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на soerdev.space в картах знаний.
В итоге получилось очень плотное информативное видео, смотреть можно тут:
YouTube | Vk | RuTube | 0 |
