S0ER
Ir al canal en Telegram
Архитектура | Программирование | Профессиональное развитие По всем вопросам писать на @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 376 suscriptores, ocupando la posición 11 757 en la categoría Tecnologías y Aplicaciones y el puesto 61 064 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 376 suscriptores.
Según los últimos datos del 05 noviembre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -49, y en las últimas 24 horas de -4, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 37.72%. 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 0 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 0.
- 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:
“Архитектура | Программирование | Профессиональное развитие
По всем вопросам писать на @soerdev”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 06 noviembre, 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 376
Suscriptores
-424 horas
-117 días
-4930 días
Archivo de publicaciones
10 376
Вывод: ML - это конкретно методы обработки данных (в том числе и интеллектуальные), а DS - это общее направление, в которое входит весь спектр решения задач по обработке, хранению и визуализации данных.
10 376
ML же занимается:
- обучением с подкреплением
- компьютерным зрением
- Deep Lerning
- системами рекомендаци
- обучением с учителем
- обучением без учителя
- и т.д.
10 376
В решении своих задач DS, если смотреть обобщенно, использует:
- Визуализацию
- Хранение данных
- Структурирование данных
- Математические методы
- Языки программирования
- Решения для машинной обработки данных (ML)
10 376
Частенько встает вопрос о различии ML и DS, эта картинка хорошо показывает и различия, и состояние дел на сегодняшний день.
10 376
Эта модель затрудняет статический анализ, например, сложно выдать список пользователей с необходимыми правами, потому что требуется предьявить атрибуты каждого пользователя в каждое правило. Но очень при этом очень эффективна в небольших приложениях, основанных на ролевой модели, так как позволяет делать правила на основе ролей.
10 376
Из интересного:
здесь отображена модель ABAC - это механизм разграничения доступа на основе атрибутов. В ней обычно доступ определяется не на основе списка или таблицы доступа (как в ACL), а на основе правил и при подставлении конкретных атрибутов идентификатора в правило на выходе получаем информацию о том имеет ли пользователь право на доступ к ресурсу.
10 376
Вспомогательные процессы:
- аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций
- шифрование - основной способ сокрытия данных от доступа третьих лиц
- лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.
10 376
Два основных элемента:
Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности
Авторизация - проверка того, что пользователь может сделать
10 376
Полный текст конспекта на эту тему - https://s0er.ru/codelabs/arch_stream_1/index.html?index=..%2F..index#4
10 376
Список проблем, который я делал для архитектурных стримов, по прежнему актуален:
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
10 376
На прошлых выходных участвовал в митапе по обсуждению архитектуры,
такое ощущение, что все специально делают одни и те же ошибки.
10 376
Рома Труфанов написал хороший пост в тему:
Trufanov Roman — Сегодня, в 13:18
Вброшу немного своего мнения xD
Вообще про суффиксы все сказанное кажется немного вырванным из контекста.
Тут нужно строго зафиксировать несколько моментов.
- Мы говорим про ООП, то бишь про объекты и их взаимодействия.
- Также нужно учитывать возможность языка программирования.
- И также нужно учитывать контекст в котором приходится работать.
Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров.
Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.
10 376
Ну а мое отношение такое - я считаю, что паттерны (например, Observer) и "поведение" могут быть реализованы через класс, но нужно быть осторожным, так как лучше придерживаться максимально "чистого" ООП и создавать объекты, которые действительно являются объектами, а не абстрактной логикой.
