Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
S0ER
Відкрити в Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Показати більше📈 Аналітичний огляд Telegram-каналу S0ER
Канал S0ER (@softwareengineervlog) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 536 підписників, посідаючи 11 765 місце в категорії Технології та додатки та 62 121 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 536 підписників.
За останніми даними від 15 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -29, а за останні 24 години на -6, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 27.28%. Протягом перших 24 годин після публікації контент зазвичай збирає N/A% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 874 переглядів. Протягом першої доби публікація в середньому набирає 0 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 137.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як rbp, архитектура, callme, mov, указатель.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Завдяки високій частоті оновлень (останні дані отримано 16 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
10 536
Підписники
-624 години
-117 днів
-2930 день
Архів дописів
10 537
О стратегии наращивании ресурсов. Вопрос о том, что лучше сразу взять больше ресурсов, чем надо, либо наращивать их по мере возникновения необходимости. Как правило, взять сразу обходится дешевле (так как миграция редко бывает zero cost), но брать по мере необходимости - это "отложить" затраты в будущее и тогда можно делать из за счет полученной прибыли.
Я делю так: если ожидается бурный рост проекта (например, у проекта дикий рекламный бюджет), то применяем стратегию "на вырост", т.е. берем сразу с запасом, если рост медленный, то стараемся "откладывать" расширения в будущее.
10 537
Кстати, последний пример это империческое правило, которое реально используется при проектировании "правило 50%": максимальное capacity решения должно быть не мене чем в два раза больше среднего. Среднее можно рассматривать как текущее.
10 537
Довольно легко продемонстрировать, что специалисты всегда думают о "будущем", не буду приводить программерский пример, слишком много условий описывать. Но давайте приведу пример при выборе ресурсов. Представьте что вы покупаете сервер для СУБД, объем данных, который требует хранения 100 Гб, у вас стоит выбор взять сервер с объемом диска 100Гб (представим, что его гарантированно хватит под "текущее" состояние) или сервер с объемом диска 200Гб. Вопрос, какой сервер вы возьмете?
Если с 200 Гб, то палец вверх, если ровно решающий "текущие" требования, то палец вниз. ))))
10 537
Интересный факт - считается, что хороший программист - это прагматик, который решает только текущие проблемы, одновременно с этим хороший программист должен уметь выбирать оптимальные решения, оптимальность которых можно проверить только "в будущем". Т.е. при выборе решения "хороший программист" таки должен уметь заглядывать на пару шагов в "будущее".
Я считаю, что прагматичность текущих решений - это миф, любой хороший разраб всегда прогнозирует вектор развития. Иначе просто будешь собирать все грабли на проекте.
10 537
Почему так важно определить является архитектура монолитной или распределенной? Все просто - монолитные архитектуры хорошо растут "вертикально" и плохо "горизонтально", распределенные же архитектуры хорошо растут и "вертикально" и "горизонтально".
Осуществить вертикальный рост всегда проще чем горизонтальный.
10 537
Есть довольно хороший критерий для оценки степени "монолитности" модульной архитектуры (или "модульный монолит"). Он состоит в том, что в монолитной архитектуре выход из строя одного из модулей приводит к отказу всего приложения. В распределенной же архитектуре отказ происходит только в одной точке. Это относится и к этапу сборки / развертывания приложения или системы. Если развертывание системы не может быть выполнено по частям, или должно прекратиться в случае ошибки развертывания одного из модулей, то это признак монолита.
10 537
Как то на стриме спрашивали про то как найти проекты чтобы предложить свою помощь.
Я смотрю трендовые репозитории вот здесь - https://github.com/vitalets/github-trending-repos
10 537
Для проекта Devs2Devs делал небольшой видос о том как обновлять форкнутый репозиторий с основным репозиторием (через upstream), а свою разработку делать в своем remote origin.
Вероятно будет полезно тем кто будет участвовать в OpenSource проектах.
10 537
У меня есть платные видосы, которые размещены на сайте https://soer.pro - это стримы по архитектуре (более 20 часов видео), воркшопы, исходники проектов. Доступ к этим материалам теперь можно получить не только за деньги, но и через бартер.
Принцип простой - "пишешь код, получаешь сертификат". Правила следующие:
- нужно делать любые Pull Request к любому репозиторию на https://github.com/soerdev
(любые - значит считается все: правка опечаток, верстки, написание кода, написание документации т.е. все что может быть оформлено в виде PR)
- Единственное условие - Pull Request должен быть логически законченным (т.е. начал и бросил не пройдет)
Если Pull Request принят, то далее идет следующий расчет:
- за каждые 10 принятых PR - получаешь сертификат на 30 дней уровня "stream"
- за каждые 20 принятых PR - получаешь сертификат на 30 дней уровня "workshop"
раз в месяц самый активный участник получает сертификат на 30 дней уровня "PRO"
10 537
Опубликовал репозиторий gitlo на github - https://github.com/soerdev/gitlog
Если есть желающие добавить информацию о своих проектах, то это можно сделать через pull request.
10 537
Когда-то слышал фразу: "ничто так не стимулирует к движению вперед, как ноль". Речь шла о статистике продаж в стартапах, на маркерной доске рисуется огромный "ноль", который напоминает о том, что первый шаг еще не сделан.
Вспомнив эту фразу решил выводить статистику soer.pro только за сутки. До этого выводил просто суммарное значение показателей, но по ним не видно динамику.
10 537
В донатах иногда забавные комментарии встречаются:
"Когда вы поженитесь с Димой Рожковым?"
Вообще не понял к чему это, но, видимо, людей этот вопрос волнует ))))
10 537
Идея двигать OpenSource меня не покидает, поэтому решил сделать небольшой информационный сайт, где буду собирать всю информацию по проектам и видео, которые снимаю. https://gitlog.ru/
10 537
Планирую сделать несколько видосов по формальному анализу проектов.
Для начала хочу поговорить про зависимости и развитие проекта, вот такой график "количество зависимостей / версия" для npm. Много чего интересного из него можно "вытащить".
10 537
Есть ли у вас проблема с доведением идей до реализации?
Поясню о чем я, делая контент и развивая свои социальные проекты я реализую всего-лишь около 30% тех идей, которые у меня появляются. У меня есть много наработанного материала, который лежит и пылится, а я не могу снять по нему видео.
Понимая, что распыляюсь, я пытаюсь сузить фокус, но все равно КПД остается низким.
Не думаю, что это плохо, потому что лучше выполнить 30% от большой цели, чем 100% от маленькой. Смотреть на абсолютные цифры тоже надо.
Мне просто интересно узнать если такая проблема у вас - если так же реализуете далеко не все, что задумали, то палец вниз, если реализуете более 75% своих целей, то палец вверх.
