متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
S0ER
الذهاب إلى القناة على Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام 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 |
