Foundations of Computer Science от Alfred Aho и Jeffrey Ullman доступна бесплатно онлайн.
Классический учебник по информатике, который охватывает:

• конечные автоматы
• формальные языки
• теорию вычислений
• основы алгоритмов и вычислительных моделей

Хорошая отправная точка для тех, кто хочет разобраться в фундаментальных концепциях Computer Science, лежащих в основе компиляторов, языков программирования и теории вычислений.

Книга:
http://infolab.stanford.edu/~ullman/focs.html

#computerscience #book #theory #cs

👉 @BackendPortal

Если вы программируете на Windows, стоит обратить внимание на Windows Developer Config от Microsoft.

Инструмент позволяет подготовить машину для разработки одной командой.

Что умеет:

✓ Настраивает WSL и Ubuntu
✓ Устанавливает Windows Terminal
✓ Ставит Node.js, Python, Rust, Go, Java, .NET, PHP и другие инструменты
✓ Автоматизирует настройку рабочего окружения

Проект полностью открытый и доступен на GitHub.

👉 @BackendPortal

Salesforce внедрила 20 000 корпоративных AI-агентов.

Главный вывод оказался неожиданным:

Для классического ПО 90% работы происходит до релиза.

Для AI-агентов всё наоборот — 90% работы начинается после запуска.

В интервью с Джоном Кучерой, CPO Agentforce, обсудили, что отличает агентов, которые приносят реальную пользу бизнесу, от тех, что так и остаются красивым демо.

Одна из ключевых мыслей:

Команды, которые считают запуск финишной чертой, застревают на стадии пилота.

Команды, которые воспринимают запуск как стартовую точку, масштабируют решения дальше.

В материале разбирают:

→ Почему большинство корпоративных агентов терпят неудачу
→ Что нужно подготовить до запуска: scope, KPI и guardrails
→ Как выглядит feedback loop, без которого невозможно масштабирование
→ Три анти-паттерна, выявленных на основе 20 000 внедрений
→ Куда движется архитектура агентных систем

👉 @BackendPortal

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

Вот в чём разница:
Write-Through Cache → приоритет консистентности данных
Write-Behind Cache → приоритет производительности, допускается временная неконсистентность и риск потери данных
Write-Through — кэш и база данных обновляются одновременно при каждой записи.
(Представьте доску, которая в реальном времени синхронизируется с общим документом.)
Write-Behind — данные сначала записываются в кэш, а затем позже сбрасываются в базу данных.
(Представьте, что вы делаете заметки на доске, а в общий документ переносите их только в конце дня.)

Практическое правило:
Если устаревшие данные недопустимы → используйте Write-Through.
Если критична скорость записи → используйте Write-Behind.

👉 @BackendPortal

Твой запрос к JSONB — не медленный. Ты просто используешь не тот индекс.

Допустим, ты хранишь события вот так:

{
  "user_id": "123",
  "status": "completed",
  "source": "mobile"
}

И фильтруешь их примерно так:

SELECT * FROM events WHERE payload @> '{"status":"completed"}';

Ты повесил B-Tree индекс на всю колонку payload.

Это не сработает.

PostgreSQL не умеет эффективно оптимизировать глубокие запросы к JSONB через B-Tree.
В итоге он каждый раз делает полный скан таблицы.

Чтобы это починить — нужен GIN-индекс (Generalized Inverted Index).

PostgreSQL создаёт инвертированный индекс:

🔸Разбивает каждый JSONB-объект на ключи и значения,
🔸Мапит их на ID строк,
🔸И вместо полного скана сразу прыгает к нужным совпадениям.

Если не делаешь запросы на вхождение (@>), добавь опцию jsonb_path_ops — индексы будут компактнее и быстрее.

Быстрее. Меньше. Чище.

👉 @BackendPortal

Я видел, как инженеры с 10-летним опытом проваливали собеседования по System Design на Senior-позиции.

И ошибка почти всегда одна и та же.

❌ «Наша архитектура данных — это React + Node.js + MongoDB»

✅ «Мы используем микросервисную архитектуру с событийным взаимодействием между сервисами, REST API и документо-ориентированной базой данных для обеспечения масштабируемости и гибкости»

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

Более правильный подход на архитектурном интервью:

1. Начните с ключевых принципов.

Например: «Наша система построена на event-driven подходе, чтобы сервисы оставались слабо связанными друг с другом».

2. Объясните компромиссы.

Например: «Мы выбрали eventual consistency вместо строгой консистентности, чтобы обеспечить высокую доступность системы».

3. Только после этого переходите к инструментам, если это необходимо.

Например: «Для реализации этого подхода мы используем Kafka».

Архитектура — это стратегия: что, зачем и когда.

Инструменты — это тактика: как именно это реализовано.

Архитектура — стратегический уровень. Инструменты — тактический.

Хорошая архитектура переживает смену инструментов.

👉 @BackendPortal

Хочешь разобраться в распределённых системах с нуля?

Начни с этих 10 тем:

Distributed Systems Reading List
https://github.com/theanalyst/awesome-distributed-systems
System Design Primer
https://github.com/donnemartin/system-design-primer
MIT 6.824 (Distributed Systems)
https://github.com/chaozh/MIT-6.824
System Design 101
https://github.com/ByteByteGoHq/system-design-101
Awesome Scalability
https://github.com/binhnguyennus/awesome-scalability
Raft Consensus Visualization https://github.com/ongardie/raftscope
Apache Kafka https://github.com/apache/kafka
Apache Cassandrahttps://github.com/apache/cassandra
etcd github.com/etcd-io/etcd

👉 @BackendPortal

Папка /internal в Go — одна из самых неправильно понятых вещей в структуре проекта.
Многие используют её один раз на верхнем уровне, просто чтобы спрятать код от внешнего мира.
Но мало кто знает главное.

internal можно вкладывать в internal.
И это меняет всю идею.

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

Так ты собираешь модульный монолит не из “папок с кодом”, а из жёстко изолированных блоков, где каждый живёт в своём контуре.

👉 @BackendPortal

Многие разработчики путают эти 3 HTTP-метода:

PUT
PATCH
POST

Самый простой способ запомнить:

POST → создать новый ресурс
POST /users
Создаёт нового пользователя.

PUT → полностью заменить ресурс
PUT /users/123
Если отправить только имя, остальные поля могут быть перезаписаны, потому что PUT подразумевает замену всего объекта целиком.

PATCH → обновить только изменённые поля
PATCH /users/123
Отправляешь только:
{ "email": "[new@example.com }

Обновится только email.

Короткое правило:

POST = создание
PUT = полная замена
PATCH = частичное обновление

Мнемоника:

POST → отправить новый объект
PUT → поставить новую версию вместо старой
PATCH → наложить патч на существующий объект

Правильный выбор HTTP-метода делает API более предсказуемым, REST-совместимым и проще в поддержке.


👉 @BackendPortal

Наткнулся на полезный open-source Email SDK

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

Идея простая: если в будущем решишь перейти с одного провайдера на другой, не придётся переписывать большую часть кода, связанного с отправкой почты.

Подходит для:

* SaaS-продуктов;
* веб-приложений;
* AI-автоматизаций;
* AI-инструментов, которые используют email-уведомления, рассылки или почтовые workflow.

Исходники:
github.com/opencoredev/email-sdk

👉 @BackendPortal

Одна из самых детальных шпаргалок для Backend-разработчика на русском языке. Внутри: от базового устройства интернета и ПК, до работы с базами данным, разработки API и тестирования продуктов.

Весь материал преисполнен разными таблицами и картинками для лучшего усвоения, вся информация подаётся кратко и понятно, а если захотите изучить детальнее — везде есть ссылки на источники.

👉 @BackendPortal

Нашёл GitHub-репозиторий, который помогает AI-агентам не сжигать токены впустую.

Называется Headroom.

Его создал Теджас Чопра, инженер из Netflix.

Идея простая: Headroom сжимает всё, что читает AI-агент, ещё до того, как данные попадут в LLM.

Например:

- вывод инструментов;
- логи;
- файлы;
- RAG-чанки;
- результаты поиска по коду;
- историю диалога.

По словам автора, это позволяет сократить расход токенов на 60–95% без потери качества ответов.

Сейчас Headroom можно использовать как:

- библиотеку для Python и TypeScript;
- локальный прокси;
- MCP-сервер;
- обёртку для Claude Code, Codex, Cursor, Aider и Copilot.

Если твой AI-агент становится дорогим, медленным или начинает теряться в огромных логах, на этот проект стоит взглянуть.

GitHub: https://github.com/tejaschopra/headroom

Спасибо за внимание.

👉 @BackendPortal

Как правильно работать с резервным копированием в облаке?

25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.

⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.

⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.

⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.

Зарегистрируйтесь, чтобы не пропустить!

⏰ 25 июня в 14:00 (мск)

✅ Зарегистрироваться

Мелкие архитектурные решения в софте могут сильно влиять на производительность.

Хороший пример — Array of Structs (AoS) против Struct of Arrays (SoA). Казалось бы, небольшое различие в организации данных в памяти, но оно радикально меняет эффективность использования кэша процессора и частоту cache hit'ов.

В результате разница в производительности может достигать целого порядка.

Похоже на выбор между построчным и колоночным хранением данных в СУБД. Всё упирается в паттерны доступа: OLTP и OLAP требуют разных подходов.

У Farad вышла отличная статья на эту тему — читается быстро и объясняет всё на понятных примерах. Ссылка ниже.

https://fzakaria.com/2026/06/01/every-byte-matters

👉 @BackendPortal

Избегать SQL — значит избегать настоящего бэкенда.

API меняются.
Фреймворки уходят в историю.
Базы данных переживают миграции, переписывания и смену стека.

Большинство проблем с производительностью на бэкенде возникают не из-за медленного кода приложения.

Обычно виноваты:

* плохие запросы;
* отсутствующие индексы;
* неудачная схема БД;
* слабая модель данных;
* неправильные паттерны чтения и записи.

Отсутствующий индекс не лечится микросервисами.

Дублирование данных не исправляется кэшем.

Медленные отчёты не ускоряются переписыванием API.

Если ты не понимаешь ACID, уровни изоляции, блокировки, дедлоки, индексы, партиционирование и планы выполнения запросов, рано или поздно система начнёт разваливаться под нагрузкой.

SQL — это не опция.

Хорошее знание SQL делает тебя сильнее в проектировании систем, распределённых системах, производительности и надёжности.

Изучи SQL.

Всё остальное строится поверх него.

👉 @BackendPortal

ИИ не уравнял всех разработчиков.

Он просто разделил рынок на несколько направлений, и многие до сих пор не поняли, в каком из них находятся.

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

Что остаётся после этого?

1. Оркестраторы

Люди, которые проектируют процесс целиком.

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

Они не обязаны писать каждую строчку кода.

Они отвечают за систему в целом.

2. Системные инженеры

ИИ отлично генерирует код.

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

Чем быстрее генерируется код, тем больше потенциальный радиус поражения ошибок.

Поэтому люди, которые понимают производительность, надёжность и устройство систем, стали только ценнее.

3. Переводчики между бизнесом и технологиями

ИИ сильно сократил путь от идеи до реализации.

Но он не умеет определять, какие идеи вообще стоит реализовывать.

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

Обычно они работают тихо.

Их редко замечают, пока они не уходят.

Мне кажется, главный эффект ИИ оказался не в замене разработчиков.

Он сделал гораздо заметнее разницу между теми, кто просто пишет код, и теми, кто проектирует системы, принимает решения и отвечает за результат.

👉 @BackendPortal

Блин... оказывается, в VS Code можно встроить таймер Pomodoro прямо в редактор

Это расширение добавляет Pomodoro-таймер непосредственно в VS Code, так что можно сохранять концентрацию, не переключаясь между вкладками и не открывая отдельные приложения.

Что умеет:

→ Таймер Pomodoro прямо внутри редактора
→ Помогает держать фокус во время работы
→ Не нужно переключаться на браузер или сторонние программы
→ Несколько настраиваемых режимов работы и отдыха
→ Гибкая настройка длительности таймеров под свои привычки :)

Удобная штука для тех, кто проводит в VS Code большую часть дня и хочет отслеживать рабочие интервалы, не выходя из редактора.

👉 @BackendPortal

Вы когда-нибудь задумывались, на что база данных на самом деле тратит своё время?

Большинство из нас предполагает, что она в основном занимается чтением и записью строк. Реальность куда интереснее.

Есть классическая статья Майка Стоунбрейкера, в которой производительность традиционной транзакционной СУБД анализировалась вплоть до отдельных инструкций процессора.

Вывод оказался неожиданным: менее 10% инструкций выполняют действительно полезную работу. Остальные 90%+ уходят на накладные расходы, которые почти поровну распределяются между четырьмя задачами:

1. Работа с буферами (перемещение страниц между буферным пулом и диском).

2. Блокировки (row-level locks для координации параллельных транзакций).

3. Защёлки (latches — облегчённые блокировки, обеспечивающие целостность внутренних структур данных).

4. Журналирование (запись операций до их выполнения, чтобы обеспечить возможность восстановления).

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

Если именно эти четыре источника накладных расходов потребляют процессорное время, что будет, если необходимость в них исчезнет?

- нет буферов → база данных полностью хранится в памяти;
- нет блокировок и защёлок → однопоточная архитектура;
- нет журналов → репликация вместо логирования.

Именно на этом строилась идея H-Store, а позже и VoltDB. Вы жертвуете частью гибкости, но взамен получаете производительность, в которую сложно поверить.

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

https://15721.courses.cs.cmu.edu/spring2016/papers/hstore-lookingglass.pdf

👉 @BackendPortal

Вы арендуете собственный код у Microsoft.

Один разработчик создал Git-сервер, который можно запустить на своей машине. Это значит, что ваш код никогда не покидает ваше железо, а приватные репозитории не используются для обучения Copilot.

И никаких ежемесячных платежей. Называется Gitea

Закидываете один файл на сервер — и получаете свой GitHub. Pull Request'ы, Issues, Wiki, реестр пакетов и даже CI-систему, которая умеет запускать ваши существующие GitHub Actions без переписывания конфигурации.
→ Поставляется одним файлом. Никакой боли с настройкой.
→ Работает на 256 МБ ОЗУ. Можно хостить даже на Raspberry Pi.
→ Совместим с GitHub Actions из коробки.
→ Умеет импортировать репозитории, Issues и Pull Request'ы.
→ Поднимается менее чем за 15 минут через Docker.

Более 55 000 звёзд на GitHub.

Полностью открытый исходный код. Лицензия MIT. Бесплатен навсегда.

👉 @BackendPortal