¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
S0ER
Ir al canal en Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Mostrar más📈 Análisis del canal de Telegram S0ER
El canal S0ER (@softwareengineervlog) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 536 suscriptores, ocupando la posición 11 765 en la categoría Tecnologías y Aplicaciones y el puesto 62 121 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 536 suscriptores.
Según los últimos datos del 15 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -29, y en las últimas 24 horas de -6, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 27.28%. Durante las primeras 24 horas tras publicar, el contenido suele obtener N/A% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 874 visualizaciones. En el primer día suele acumular 0 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 137.
- Intereses temáticos: El contenido se centra en temas clave como rbp, архитектура, callme, mov, указатель.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 16 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
10 536
Suscriptores
-624 horas
-117 días
-2930 días
Archivo de publicaciones
10 535
Идея простая - есть одна основная ветка (trunk) весь код непрерывно сливается в нее, чтобы отсечь неработоспособные фичи (те фичи, которые находятся в разработке) используются флаги.
Таким образом мы постоянно ревьюим код через Pull Request, а фичу включаем через флаг когда она готова.
10 535
на изображении схематично показан алгоритм работы trunk flow, из плюсов:
- простой и легкий
- подходит для частых релизов и CI
- не имеет проблем "длинных" слияний (когда ветка долго в разработке находится)
10 535
Если меня попросят порекомендовать flow для разработки проекта, то пожалуй это будет Trunk based + Feature flag + Branch by abstraction
10 535
Вывод: ML - это конкретно методы обработки данных (в том числе и интеллектуальные), а DS - это общее направление, в которое входит весь спектр решения задач по обработке, хранению и визуализации данных.
10 535
ML же занимается:
- обучением с подкреплением
- компьютерным зрением
- Deep Lerning
- системами рекомендаци
- обучением с учителем
- обучением без учителя
- и т.д.
10 535
В решении своих задач DS, если смотреть обобщенно, использует:
- Визуализацию
- Хранение данных
- Структурирование данных
- Математические методы
- Языки программирования
- Решения для машинной обработки данных (ML)
10 535
Частенько встает вопрос о различии ML и DS, эта картинка хорошо показывает и различия, и состояние дел на сегодняшний день.
10 535
Эта модель затрудняет статический анализ, например, сложно выдать список пользователей с необходимыми правами, потому что требуется предьявить атрибуты каждого пользователя в каждое правило. Но очень при этом очень эффективна в небольших приложениях, основанных на ролевой модели, так как позволяет делать правила на основе ролей.
10 535
Из интересного:
здесь отображена модель ABAC - это механизм разграничения доступа на основе атрибутов. В ней обычно доступ определяется не на основе списка или таблицы доступа (как в ACL), а на основе правил и при подставлении конкретных атрибутов идентификатора в правило на выходе получаем информацию о том имеет ли пользователь право на доступ к ресурсу.
10 535
Вспомогательные процессы:
- аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций
- шифрование - основной способ сокрытия данных от доступа третьих лиц
- лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.
10 535
Два основных элемента:
Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности
Авторизация - проверка того, что пользователь может сделать
10 535
Полный текст конспекта на эту тему - https://s0er.ru/codelabs/arch_stream_1/index.html?index=..%2F..index#4
10 535
Список проблем, который я делал для архитектурных стримов, по прежнему актуален:
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
