S0ER
前往频道在 Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
显示更多📈 Telegram 频道 S0ER 的分析概览
频道 S0ER (@softwareengineervlog) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 10 454 名订阅者,在 技术与应用 类别中位列第 11 383,并在 俄罗斯 地区排名第 60 850 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 10 454 名订阅者。
根据 27 八月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -7,过去 24 小时变化为 2,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 27.80%。内容发布后 24 小时内通常能获得 N/A% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 2 906 次浏览,首日通常累积 0 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 85。
- 主题关注点: 内容集中在 rbp, архитектура, callme, mov, указатель 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
凭借高频更新(最新数据采集于 28 八月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
10 454
订阅者
+224 小时
+27 天
-730 天
帖子存档
10 454
Repost from N/a
Первый подход - это задачи с транзакциями, когда у нас жесткие нефункциональные требования по согласованности и быстродействию, второй - это согласованность в конечном итоге (eventual consistency).
Это пример, но не единственный, следует из текста. Могу допустить что смысл передан не очень, но подходы принципиально разные.
Понятно, что и в том, и другом случае будет применяться "разделяй и властвуй", но принципиально тут именно логика и взаимодействие данных
10 454
Два подхода к разработке программного обеспечения
В мире разработки программного обеспечения существует два основных подхода к организации работы над проектами. Каждый из них имеет свои преимущества и недостатки, и выбор между ними зависит от конкретных требований проекта.
Первый подход заключается в том, что каждый член команды разрабатывает свою небольшую часть кода, а затем они объединяют свои усилия для создания конечного продукта. Этот подход часто используется при работе над сложными проектами, где большая доменная область и жесткие связи между задачами.
В этом случае основная нагрузка ложится на архитекторов и техлидов, потому что требуется большое количество координационных действий. Это роняет КПД, но позволяет решить проблему сложности.
Второй подход предполагает разделение проекта на несколько независимых проектов (например, как это делается в Яндексе). Каждый проект имеет своего руководителя и команду разработчиков, которые работают над своей частью кода. Такой подход позволяет лучше контролировать процесс разработки и уменьшить вероятность ошибок.
Такое решение в случае если у вас есть независимые задачи, которые не завязаны друг на друга или задачи которые могут функционировать как сервис. Во втором случае за счет внешних API возможно комплексировать независимые проекты для создания производных продуктов.
Какой из этих подходов выбрать зависит от конкретной ситуации. Если у вас есть большой проект со сложной структурой данных и множеством взаимосвязанных компонентов, то лучше использовать первый подход. Если же ваш проект состоит из нескольких небольших частей (сервисов), то второй подход будет более эффективным.
#мысли
S0ER | Boosty
10 454
Яндекс открыл YandexART API для генерации картинок по текстовому описанию. Эта сетка используется в Шедеврум и дает весьма неплохие результаты. Молодцы!
10 454
Среди архитектурных фреймворков есть "экзотические" экземпляры, например DoDAF (Department of Defense Architecture Framework)
Это полноценный фреймворк для создания больших автоматизированных систем, который имеет хорошо структурированный и продуманный набор ViewPoint-ов, позволяющих рассмотреть систему подробно и всесторонне.
В этом фреймворке так же велика роль проектного подхода на основе моделей.
Если интересуетесь темой энтерпрайз архитектура, то обязательно посмотрите на этот фреймворк, помогает поставить многие вещи на место.
10 454
Задача: в браузере нужно получать Push-сообщения от сервера
Есть два варианта, которые наиболее часто используются для решения:
- WebSockets
- Server-Sent Events (SSE)
Использовать веб-сокеты только для пушей - излишне. Да, в перспективе это может окупиться, но:
- сложно
- долго
- дорого
В то время как SSE легко ляжет поверх имеющихся HTTP-решений, вытащит нужные данные из заголовка (например, авторизационный токен). При разрыве соединения браузер сам его восстановит, да еще сэкономим на ресурсах.
Из ограничений неприятно то, что гоняется только текст, а так же небольшое количество одновременных соединений.
Совет: прежде чем городить огород вокруг сокетов рассмотрите SSE.
10 454
Repost from Рекрутинг, котики и апокалипсис (Кира Кузьменко)
История, которая разблокировала моё воспоминание из юности, когда я также уволилась с одной из первых своих работ 🙈
Просто ушла и не вернулась, и не отвечала на звонки. Просто физически не могла, так сильно выгорела.
До сих пор капец стыдно 🙈
Скажите, что мы с Толиком не одни такие на свете 😅
10 454
Так же ловите список книг по архитектуре очень часто просят, много раз уже писал про них, но повторить лишним не будет.
10 454
На boosty делаю зеркало записей стримов, размещенных на soer.pro, сегодня перенес запись Инверсия управления и инверсия зависимостей. В видео подробно рассмотрел два эффективных способа управлять сложностью кода - DIP и IOC.
10 454
еще б развернуть тему когда приходит новый разраб ему когнитивно сложно вникнуть в текущее решение и он бизнес принуждает к "а давайте всё перепишем"Переписывать или не переписывать - вот в чем вопрос!
10 454
Переписывание с нуля 💡
Написал пост в котором изложил свои мысли про то почему не стоит слепо полагаться на переписывание с нуля. Каждый раз, когда программисты говорят "сделаем из говна и палок, а потом перепишем" создается порочный круг зависимости - один раз сделали плохо, а потом уже некогда делать хорошо.
10 454
Repost from Эксплойт
Сегодня у Рунета юбилей — отечественный интернет отмечает 30 лет.
Осторожно: может свести олдскулы от ностальгии.
@exploitex
10 454
Repost from IT DIVA - Карьера в IT и BigTech
А вот и долгожданный подкаст с Женей S0ER про архитектуру.
Приятного просмотра:
https://youtu.be/Lx45YDD4xAc?si=eanH3I9VuTt5-kUC
[ТАЙМКОДЫ]
00:00:00 - Что будет в этом выпуске
00:01:27 - Знакомимся с гостем: кто такой S0ER, какой у него опыт в разработке и архитектуре?
00:08:40 - Сколько зарабатывает архитектор программного обеспечения (ПО)?
00:10:00 - Почему S0ER отказался от работы архитектором ПО? Минусы в работе опытного архитектора
00:14:34 - Как зарабатывать на консультациях по архитектуре для компаний?
00:18:09 - Как провести архитектурный аудит в проекте и в каких случаях он нужен?
00:25:00 - Какую задачу решает выстраивание архитектуры?
00:27:50 - Откуда приходят клиенты на архитектурный аудит?
00:28:17 - Нужно ли винить архитектуру в проблемах при разработке?
00:30:43 - Что входит в понятие "архитектура"? Какие уровни архитектуры существуют и как их различать? Зачем заботиться об архитектуре?
00:39:29 - Что такое "хорошая архитектура"? Есть ли универсальная архитектура, которая подойдет всем проектам?
00:42:49 - Как не написать говнокод? Как отличить хорошую архитектуру от плохой? На что обратить внимание при написании кода?
00:47:58 - С чего начинать погружение в архитектуру Junior-разработчику?
00:50:12 - Как развитие ИИ повлияет на работу нового поколения разработчиков?
00:58:07 - Какие разработчики будут всегда востребованы на рынке?
00:58:56 - С чего начинать погружение в архитектуру Middle-разработчику? Нужно ли изучать паттерны и стили проектирования?
01:04:39 - Какие шаблоны и стили проектирования полезно знать всем?
01:11:56 - Какие проблемы в архитектуре и процессах встречаются в стартапах и как их решать?
01:21:00 - Когда стартапам пора думать про решение вопросов на уровне архитектуры?
01:28:57 - Какие проблемы в архитектуре и процессах встречаются в компаниях средних размеров и как их решать?
01:35:15 - В каких проектах интереснее всего работать разработчику и при этом есть больше возможностей для развития?
01:36:40 - Как понять, какую нагрузку выдержит проект и подготовиться к масштабированию проекта?
01:40:27 - Зачем разработчикам, техлидам, тимлидам, CTO выстраивать стратегию по улучшению архитектуры и инфраструктуры проекта?
01:50:12 - Какие проблемы в архитектуре и процессах встречаются в крупных корпорациях и как их решать?
01:54:06 - Краткие итоги по архитектуре проектов в компаниях разных размеров
01:57:11 - Какие книги и видео стоит посмотреть после этого интервью?
01:57:44 - Советы от S0ER и меня для тех, кто хочет развиваться в IT, разработке и архитектуре
02:02:05 - Где можно получить еще больше пользы от S0ER после этого видео?
10 454
Хочу ещё порекомендовать видео с Мишей Фленовым, который обсуждали четвертую главу книги "От монолита к микросервисам".
10 454
Опубликовал публичный (бесплатный) пост "Разработка и документирование" в котором собрал советы и привел пример того как можно оптимизировать работу команды разработчиков за счет ведения документации.
10 454
Я не могу, поэтому это неважно
Вы наверное любите красивые автомобили, классные гаджеты, вероятно вы любите социальные сети и многие другие вещи, к которым привыкли и они вам нравятся. Вряд ли вы скажете, что новый айфон - это неважно, или ламба на день рождения - это ерунда.
Теперь задумайтесь, если вы пользуетесь YouTube, то вы 100% сталкивались с работой библиотеки ffmpeg, которая зашита практически в любой сайт по работе с видео. Код этой библиотеки лежит на github и вы можете легко его найти, но скорее всего вы не сможете понять, что там написано.
FFmpeg считается одной из самых сложных кодовых баз, для освоения которой нужные хорошие теоретические знания, математика, опыт и другие хардскилы (особенно часть со сжатием данных, кодировками и т.д.).
Есть много других сложных исходников. Большая часть людей, когда узнает о том, что есть кодовые базы, которые недоступны для их понимания говорят "это неважно". Небольшая часть говорит - "это интересно".
Так происходит не только с кодом, а со всеми сложными для восприятиями вещами , просто "это неважно".
- Сложная музыка? Это неважно!
- Приготовление сложных блюд? Это неважно!
- Авторское кино? Это неважно!
- Искусство? Это неважно!
Почему так происходит? На самом деле "это неважно" заменяет другу фразу, которую люди боятся и не хотят произносить "я не могу".
- Разобраться со сложной музыкой? Я не могу!
- Приготовить сложное блюдо? Я не могу!
- Посмотреть и понять авторское кино? Я не могу!
- Разобраться в живописи? Я не могу!
- Разобраться со сложным кодом? Я не могу!
- Принять участие в спортивном программировании? Я не могу!
Большая часть людей сталкиваясь с трудностями сразу сдается и прячется за фразой "это неважно".
Плохие разработчики уверены, что они ничем не отличаются от хороших, что они якобы решают те же задачи, получают те же зарплаты, так же растут по карьерной лестнице. Правда в том, что нет, не так же.
Уверен, что у вас есть (или был) коллега, которы не тянет свои задачи и ему помогают всем коллективом, но этот коллега будет всем говорить, что "посмотрите, я делаю тоже, что остальная команда".
Правда заключается в том, что в жизни много людей, которым интересно жить полной жизнью, принимать вызовы, изучать новое, двигаться по карьере от джуна до архитектора, работать с такими же интересными людьми и т.д. Им не интересно сидеть в баре с неудачниками, которые буквально на любую сложность отвечают "это неважно".
Я люблю пить кофе, и знаю много мест в городе, где делают классный кофе. Но большая часть людей, которые пьют откровенную ерунду, просто закидывают пару ложек сахара и получают кофейный напиток, в котором вкус кофе "убит" сладостью.
Простые удовольствия может получить каждый, я тоже переодически пью пиво, ем бургеры, смотрю тупые фильмы. Но так же я получаю удовольствие от сложных вещей, потому что мозг устроен так, что ему постоянно нужна пища для размышления, иначе он теряет пластичность и деградирует.
Поэтому там где одни скажут "это неважно", я скажу "это интересно, но я не могу понять/сделать/разобраться". Я не смогу разобраться со всеми интересными вещами и мне придется выбирать куда двигаться, но главное, что мне не надо обманывать себя говоря "это неважно", "я могу также".
В жизни есть много путей, в том числе и для тех, кому интересно развиваться, разбираться, расти по карьере, путешествовать, быть гармоничной личностью, не только потреблять простые удовольствие, но и интересоваться сложными вещами.
Поэтому кому-то нравится потреблять, кому-то создавать - Кесарю – кесарево, слесарю – слесарево
10 454
Repost from { между скобок } анонсы 📣
6 апреля 12:00 по мск “От монолита к микросервисам. Глава 5 Проблемы микросервисов / Илья Казначеев, Евгений Сергеев”
Разберемся с ключевыми проблемами, с которыми сталкиваются разработчики при переходе от классического монолита к гибким микросервисам. Мы рассмотрим такие проблемы, как большое количество сервисов, управление данными, согласованность, мониторинг и масштабируемость.
Помогать в обсуждении нам будут невероятно интересные гости - Илья Казначеев и Евгений Сергеев 🔥
Илья - эксперт в области PaaS и SaaS систем, Google Developer Expert по облачным технологиям, кандидат технических наук.
Женя - архитектор, разработчик, автор телеграмм и youtube канала S0ER.
Подключайтесь в субботу к YouTube трансляции или в Zoom
А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Илье и Жене ⤵️
