Sergei Gorlov
СтатистикаSoftware Engineer @ Banco Plata @gorlovq https://sergeigorlov.com/ https://www.youtube.com/@gorlovq
- Последний пост
- 10 авг.
- Последнее чтение
- 13:27
- Постов за неделю
- 1
- Всего постов
- 20
- Тип
- открытый
- Язык
- русский
- Категория
- Видео
- В каталоге с
- 13 авг.
- 1/24сутки в ленте
- 601
- 1/48двое суток
- 688
- 1/72трое суток
- 742
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
Два совета для жизни в корпоративном мире Спрашивайте фидбек на каждом 1-2-1. Что я делаю хорошо? Что могу улучшить? Звучит очевидно, но на моё удивление это делают единицы, большинство не просит фидбек вообще. А для менеджера такой вопрос это знак, что вы хотите расти и развиваться. Второй совет: найдите боль в команде или процессе, которую можно решить просто. Обычно поступают наоборот и берут амбициозную проблему, на которую нужно много ресурсов. В срок с ней не справляются, и на годовом ревью писать нечего. Кажется, что таких простых задач не бывает, но это вопрос насмотренности.
Я снова взялся за английский, в связи с этим появилась идея организовать звонки раз в неделю, где можно было бы поговорить на английском на технические и не только темы. Если есть желающие, то отпишите в комментарии.
Я снова взялся за английский, в связи с этим появилась идея организовать звонки раз в неделю, где можно было бы поговорить на английском на технические и не только темы. Если есть желающие, то отпишите в комментарии.
Мой младший брат построил платформу для изучения программирования. Это уже не первый его проект. Советую посмотреть, любой фидбек приветствуется.
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
822 задач на LeetCode. 430+ дней стрика в 18 лет. https://leetcode.com/u/dima853/ Пару месяцев назад начал писать платформу для практики через пазлы. Сети, базы, алгоритмы, DevOps и не только. Что внутри: 🧩 500+ пазлов. Не читаешь теорию, а логикой находишь правильную формулировку среди похожих вариантов и собираешь её в стек. Java, Go, Rust, Python, сети, базы, DevOps, K8s, безопасность, алгоритмы — почти всё, что нужно разработчику ⚔️ Дуэли и арена. Решаешь на скорость против других, ставишь монеты, дерёшься за топ 📚 30+ планов подготовки. Структурированные пути по направлениям, с прогрессом Junior → Middle → Senior 🛍️ Магазин. Бейджи, темы, ауры, кейсы Скоро новые типы пазлов: 2D-цепочки для кибербеза и LeetCode-задачи через логику и пазл-механику. Ссылка 👇 https://selfuniversity.site/en/welcome Android APK + iOS PWA | Full RU/EN support
Перешёл в новую команду Больше двух лет я был в команде Operfeed. Мы отвечали за всё, что связано с операциями: их сборку, подсчёт статистик, отправку нотификаций и много чего ещё. Основные сложности были в большом объёме бизнес-логики и постоянно растущих нагрузках: за это время объёмы данных выросли на несколько порядков, и решения, которые хорошо работали в начале, со временем приходилось пересматривать. Теперь я перешёл в новый продукт Financial Assistant. Мы делаем помощника, который помогает клиенту с разными вопросами: от «проанализируй мои траты» до «как открыть сберегательный счёт». Это лишь пара примеров, а на деле пул вопросов огромный: от аналитики и советов по финансам до подсказок по самому приложению. Причём мы не ограничиваемся ответами: ассистент должен уметь и выполнять действия за клиента. В новой команде я единственный backend-инженер и работаю вместе с двумя AI-инженерами. Они больше сосредоточены на самих агентах и их логике, а стабильность, наблюдаемость и безопасность лежат на мне, и интересных задач тут хватает. Например, собрать общий Go-фреймворк для агентов, чтобы каждого нового не приходилось писать с нуля. Разобраться с безопасностью: начиная с защиты от prompt-injection и заканчивая тем, как конфигурировать инструменты, чтобы пользователь не мог получить данные других клиентов. Выстроить наблюдаемость и процесс evaluation, чтобы объективно понимать, что агент отвечает нормально, реагировать, когда что-то ломается, и следить, чтобы качество ответов не деградировало с каждым изменением. Сейчас мы разрабатываем MVP-версию, и до полноценного релиза нужно сделать ещё много всего. Про самое интересное буду писать в канал.
Подарили на день рождение полный сетап, теперь грех видео не записать 😎
Меня и тут, и там показывают. https://youtu.be/pSrutxVx2sA?si=i4B7SA6UbMrovXJA
Теперь за старшего.
Как пагинация может убить ваш перформанс 😰 95-й перцентиль ручки GetOperations выглядел как пила: редкие тяжёлые запросы то и дело увеличивали время ответа до секунды и выше. В среднем перцентиль держался на 405 мс. Деградация затрагивала не всех подряд, а клиентов с большим числом операций: чем больше у клиента данных, тем дольше отвечала ручка. Сам метод отдавал бесконечную ленту, страницу записей плюс общее их количество. Сама выборка страницы работает быстро: LIMIT ... OFFSET ... с индексом отрабатывает мгновенно у всех. Тормозит параллельный запрос SELECT count(*), который мы дёргали ради общего числа записей. Он шёл с теми же фильтрами, что и выборка страницы, только без LIMIT. Многие считают count(*) дешёвой операцией, которая просто возвращает готовое число. На деле база каждый раз физически проходит по всем строкам, подходящим под фильтр, и пересчитывает их заново. У клиента с парой сотен операций это незаметно. У клиента с десятками тысяч это уже ощутимый скан, который заметно увеличивает время ответа. И обиднее всего, что это и есть наши самые активные пользователи. Тогда мы задались вопросом: а зачем нам вообще это число? Лента бесконечная, точное «347 операций» мы нигде не показываем. Всё, что реально нужно потребителю, это понять, есть ли ещё записи, чтобы подгрузить следующую страницу. Поэтому мы выкинули подсчёт и стали возвращать флаг HasMore. Идея простая: запрашиваем на одну запись больше, чем нужно для страницы, LIMIT pageSize + 1. Если база вернула pageSize + 1 строку, значит дальше есть ещё данные: лишнюю запись отбрасываем, а HasMore ставим в true. Если вернулось меньше, лента закончилась. rows := query(filter, limit=pageSize+1) hasMore := len(rows) > pageSize if hasMore { rows = rows[:pageSize] } return Page{Items: rows, HasMore: hasMore} Никакого скана всей таблицы: мы читаем ровно pageSize + 1 строку через индекс. После этого среднее по 95-му перцентилю просело до 128 мс и перестало зависеть от объёма данных у клиента. Вывод: count(*) это не дешёвая операция, а скан всех записей, подходящих под условие. Чем больше данных у клиента, тем дороже он обходится. Прежде чем добавлять его в нагруженную ручку, проверьте, действительно ли вам нужно точное число, или хватит флага «есть ли ещё».
AI Прогноз USD/RUB Обновлено: 25.06.2026 в 14:27 (UTC+3) Сейчас: 74.77 ₽ 1 дн → 74.85 ₽ (+0.1%) 1 нед → 75.00 ₽ (+0.3%) 1 мес → 76.40 ₽ (+2.2%) 6 мес → 80.50 ₽ (+7.7%) 1 год → 83.50 ₽ (+11.7%) Диапазон 1 мес: 73.50 – 79.50 ₽ Диапазон 1 год: 74.50 – 95.00 ₽ Описание: Доллар медленно дорожает: нефть подешевела почти на треть за месяц, а доллар укрепляется по всему миру. Около 28 июня компании платят основные налоги — это ненадолго поддержит рубль, но спрос на валюту сейчас сильнее. Главные события впереди — заседание ЦБ 24 июля и решение по ставке в США 28–29 июля; высокая ставка ЦБ удерживает рубль от резкого падения, но в течение года он постепенно слабеет. Procentum может совершать ошибки. Не является инвестиционной рекомендацией. @procentum_bot авторы @sergei_gorlov, @proydov