Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
S0ER
Kanalga Telegram’da o‘tish
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Ko'proq ko'rsatish📈 Telegram kanali S0ER analitikasi
S0ER (@softwareengineervlog) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 536 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 765-o'rinni va Rossiya mintaqasida 62 121-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 536 obunachiga ega bo‘ldi.
15 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -29 ga, so‘nggi 24 soatda esa -6 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 27.28% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining N/A% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 874 marta ko‘riladi; birinchi sutkada odatda 0 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 137 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent rbp, архитектура, callme, mov, указатель kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 16 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
10 536
Obunachilar
-624 soatlar
-117 kunlar
-2930 kunlar
Postlar arxiv
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 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
