Уже доступно! Исследование 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 |
