Бэкенд

На реддите кто-то собрал с levels.fyi данные по з/п software engineer в tech hubs после налогов, добавил аренду скромного жилья с numbeo, учел стоимость жизни и rent index.

К точности данных могут быть вопросы, многим указанное на levels кажется завышенным. Может и так, но нам важна разница между городами. Выводы актуальны для любых айтишников, просто разработчики - самые горячие пирожки.

Данные хорошо иллюстрируют многие мои тезисы:

Иногда возникает странное ощущение: железо стало безумно быстрым, процессоры научились выполнять миллиарды операций в секунду, памяти стало больше, чем раньше было дискового пространства. Но почему-то программы всё равно тормозят. Открываешь простой веб-интерфейс — и ноутбук начинает шуметь вентиляторами. Запускаешь приложение для заметок — и оно ест полгигабайта RAM. Я долго думал, откуда это ощущение. Потом начал копаться: читать дизассемблер, смотреть профилировщики, запускать микробенчмарки. И постепенно стало понятно, что дело не в железе. Дело в том, как мы пишем код.

Предлагаю поговорить о кэше процессора, о том, сколько стоит случайный доступ к памяти, о том, как CPU исполняет ваш цикл.

Простой вопрос, который разделяет инженеров и «операторов фреймворков»

Дисклеймер для опытных: если вы знаете ответ – внутри реальный кейс, как этот баг сломал мой паспорт в проде, и история с собеседования, от которой хочется плакать.

Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

На практике я сталкивался с тем, что производительность хэш-таблиц оказывалась ниже, чем у линейного поиска по массиву.

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

Развитие LLM значительно изменило процесс разработки ПО. Однако, если присмотреться к тому, как разработчики на самом деле используют эти инструменты, картина оказывается весьма разнообразной. Одни применяют ИИ как продвинутое автодополнение, другие ожидают, что он создаст целое приложение по одному промпту.

Чтобы систематизировать подходы к ИИ-программированию, воспользуемся простой моделью. Вместо того чтобы воспринимать "кодинг с ИИ" как единый монолитный процесс, мы можем отобразить его на матрице 2×2, основанной на двух ключевых осях:

Вовлеченность человека в код: Пишете ли вы код вручную (читаете, редактируете и проводите код-ревью) или работа с ним полностью делегирована LLM.

Метод валидации: Проходит ли проверка результатов неформально (покликать в приложении, оценить интерфейс на глаз, убедиться, что вроде работает) или формально (автотесты, проверка типов, строгие спецификации).

Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса. Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:

• API отвечало слишком долго

• CPU базы был загружен почти на 100%

Если в настоящее время вы являетесь Go-разработчиком, то вне зависимости от того, из какого языка программирования пришли в Go, вы наверняка когда-то задавались вопросом «А есть ли тут тернарный оператор?»

Продолжаем серию статей для тех, кто начинает изучать Kotlin с нуля. Во втором уроке детально разбираем фундамент языка:
▪️Неизменяемые (val) и изменяемые (var) переменные
▪️Базовые типы: Int, Double, String, Boolean, Char
▪️Строковые шаблоны и многострочные строки
▪️Арифметические операции, целочисленное и вещественное деление
▪️Преобразование типов (явное и неявное)
▪️Ввод данных с консоли через readln()
▪️Символы и Unicode (коды символов)
▪️Особенности остатка от деления с отрицательными числами
▪️Инкремент и декремент (префиксная и постфиксная формы)

Все примеры кода — из реальной практики, доступны в открытом репозитории на GitHub (ссылка в статье). Материал подготовлен на основе опыта преподавания в OTUS и работы в FinTech. Статья поможет вам быстро войти в тему и избежать типичных ошибок новичков. Идеально для первого знакомства с языком или для систематизации знаний.

В AWS здорово то, что этой платформе уже почти двадцать лет. Печально в AWS то… что ей уже почти двадцать лет. Если вы уже долгое время пользуетесь ею, то вам может быть сложно заметить тем изменений её «фундаментальных» сервисов. Хуже того: даже если вы относительный новичок в AWS, вам всё равно довольно легко найти устаревшие посты, объясняющие всё так, как было раньше, но не сейчас. В своей статье я перечислю часть примеров такой эволюции, которые помогут вам, если вы запутаетесь.

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.

А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.

Эта статья — не туториал и не рекламный буклет. Это честный рассказ о том, почему я выбрал Gleam, какие шишки набил, что мне понравилось настолько, что я не хочу возвращаться, и что до сих пор бесит.

Иногда одна незаметная фича может сжигать гигантский объём ресурсов. В Netflix именно так и вышло: скоринг серендипности в Ranker оказался дорогой горячей точкой, а попытка слегка его ускорить в итоге привела к большой инженерной перестройке — от батчинга до SIMD через JDK Vector API.

В новом переводе от команды Spring АйО разберем, как SIMD AVX инструкции на практике позволили снизить потребление CPU.

Коротко для ленивых

В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.

Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.

В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.

Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.

Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.

Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

Продолжаем писать сервис DeadDrop: сегодня идём от монолита к чистой архитектуре

В предыдущей части мы реализовали готовый прототип, но его код был спорным: от смешанной логики до хранения секретов пользователей в открытом виде - пора вносить правки!

Сегодня мы:

1) Превращаем "толстый" хэндлер в хорошее архитектурное решение с разделением слоёв

2) Хэшируем с bcrypt

3) Внедряем зависимости (DI) через интерфейсы

4) Готовим код к дальнейшему масштабированию

Рефакторинг, который не ломает проект, а делает его удобным для дальнейшей разработки!

Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера.

Сообщение может потеряться между записью в базу данных и публикацией события, а может быть обработано повторно при сбое сервиса.

В этой статье разберём:

В данной статье мы разберем немаловажные регистры бухгалтерии и способы оптимизации запросов к СУБД при работе с ними для решения реальных задач.

Каждый пуш в main — и ты зажмуриваешься на 2 минуты: 502 или пронесло? Знакомо? Сотни разработчиков сталкиваются с этим при деплое Next.js на VPS. Решение — буквально замена одной команды и удаление одной строки. В статье: конкретный рецепт zero-downtime с PM2 cluster mode, две главные ловушки (restart vs reload и rm -rf .next), расчёт сэкономленных денег, и честное сравнение с Kubernetes.

Привет всем! Хочу поделиться небольшим личным проектом, который родился из чистой бытовой необходимости. Я давно хотел иметь возможность удаленно поглядывать на свою дачу, особенно когда уезжаю на несколько недель. Готовые решения в духе "умных камер" меня не совсем устраивают: то подписки дорогие, то Privacy Policy сомнительная, то функционал избыточный. В итоге я решил, что проще и надежнее будет написать свою собственную утилиту.

В этот раз мы рассмотрим операции своеобразного «деления функторов». Начнём с обобщения задачи поиска сопряжённых функторов, но потом убедимся, что расширения Кана являются фундаментальной абстракцией, лежащей в основе множества полезных инструментов.