Backend Portal | Программирование
16.3K subscribers
1.72K photos
164 videos
46 files
1.46K links
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки

Связь: @devmangx

РКН: https://clck.ru/3FobxK
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
Это тот самый гайд, который мне хотелось бы получить в первый день изучения Computer Science.
В нём шаг за шагом объясняется, начиная с одного транзистора, почему компьютер большую часть времени не занимается вычислениями, а просто ждёт данные из памяти. По сути, он гораздо меньше похож на калькулятор, чем кажется.

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

Если вы до сих пор не разобрались, что такое memory wall, то упускаете один из самых сильных моментов «озарения» во всей компьютерной науке.

Автору потребовалось больше 20 дней глубокого ресёрча и много работы, чтобы изложить это максимально просто.
Вот статья: https://abhisheklearn12.github.io/blogs/memory.html

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍31🤔1
Хотите понять, как подключить LLM к реальным рабочим процессам, а не просто гонять промпты в чате?
В этом курсе Ania Kubów показывает, как собрать и задеплоить AI-агента для Slack с нуля.

По ходу курса вы:
• Поднимете Slack-бота на базе GPT-4.
• Настроите Node.js, Express и Slack Bolt.
• Подключите PostgreSQL для хранения данных.
• Развернёте проект через Render.
• Научите агента искать и привлекать новых участников сообщества.
Получается не очередной демо-чатбот, а полноценный агент, встроенный в рабочий процесс команды.

Курс: Build Your Own AI Agent with Node.js and Slack

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
1
В 1991 году финский студент просто хотел разобраться, как устроены операционные системы.
Он начал изучать MINIX, небольшой Unix-подобный проект, который профессор Эндрю Таненбаум создал для обучения. Ничего масштабного, просто учебная ОС.

В какой-то момент студент написал в интернете:
«Я делаю (бесплатную) операционную систему. Просто как хобби, она не будет такой большой и профессиональной, как GNU...»

Этим студентом был Линус Торвальдс.
А его хобби со временем превратилось в Linux.

https://os.ecci.ucr.ac.cr/slides/Andrew-S.-Tanenbaum-OperatingSystems-Design-and-Implementation.pdf

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19🤯21😁1
Если делаешь приложение или API, где важна скорость ответа, Redis может сильно разгрузить бэкенд.

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

Полезный материал для тех, кто хочет уменьшить задержки, снизить нагрузку на базу и ускорить API.
https://freecodecamp.org/news/how-in-memory-caching-works-in-redis/

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Один вопрос по Kubernetes, который мне попадается снова и снова на собеседованиях:
Что происходит с запросом на пути от интернета до Pod'а?

Обычно ответ выглядит так:
User → ALB → Ingress → Service → Pod
И вроде всё правильно.

Но самое интересное начинается после этого.
Следом обычно спрашивают:
• Кто выбирает Pod, который получит запрос?
• Чем на самом деле занимается kube-proxy?
• Как работают iptables и IPVS?
• Зачем нужен CNI-плагин?
• Что будет с трафиком, если kube-proxy упадёт?

Для меня одним из самых полезных инсайтов было вот что:
Service в Kubernetes сам по себе не балансирует трафик.
kube-proxy создаёт правила iptables/IPVS на нодах, и именно они направляют запросы в живые Pod'ы.

Ещё интереснее становится, когда речь заходит об отказах.
Если kube-proxy упадёт, трафик обычно не перестаёт ходить мгновенно. Существующие правила уже находятся в ядре Linux и продолжают работать.

Ломается другое: Kubernetes больше не может обновлять эти правила, когда появляются новые Pod'ы, удаляются старые или меняются Service.

Смешно, но именно такие базовые вопросы чаще всего вскрывают самые глубокие пробелы в понимании Кюбернетеса.

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
7💊1
Foundations of Computer Science от Alfred Aho и Jeffrey Ullman доступна бесплатно онлайн.
Классический учебник по информатике, который охватывает:

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

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

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

#computerscience #book #theory #cs

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Если вы программируете на Windows, стоит обратить внимание на Windows Developer Config от Microsoft.

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

Что умеет:

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
5
Salesforce внедрила 20 000 корпоративных AI-агентов.

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

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

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

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

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

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

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

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
Многие инженеры добавляют кэш, чтобы решить проблему производительности.
В итоге получают две системы хранения данных. (Появляется второй источник истины.)

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Твой запрос к 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
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍3
Я видел, как инженеры с 10-летним опытом проваливали собеседования по System Design на Senior-позиции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Папка /internal в Go — одна из самых неправильно понятых вещей в структуре проекта.
Многие используют её один раз на верхнем уровне, просто чтобы спрятать код от внешнего мира.
Но мало кто знает главное.

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

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Многие разработчики путают эти 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
Please open Telegram to view this post
VIEW IN TELEGRAM
4
This media is not supported in your browser
VIEW IN TELEGRAM
Наткнулся на полезный open-source Email SDK

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

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

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

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

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Одна из самых детальных шпаргалок для Backend-разработчика на русском языке. Внутри: от базового устройства интернета и ПК, до работы с базами данным, разработки API и тестирования продуктов.

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Самые умные люди в интернете в последнее время буквально начали выкладывать свои знания в open source.

Эти 11 GitHub-репозиториев могут сэкономить тебе годы проб и ошибок.

Сохрани себе и изучай постепенно.

1. PilotDeck (OpenBMB)

Open-source фреймворк для AI-агентов. Позволяет развернуть автономного агента за считанные минуты.

GitHub: https://github.com/OpenBMB/PilotDeck

2. andrej-karpathy-skills

Один файл CLAUDE.md с набором правил и практик для AI-программирования.

GitHub: https://github.com/multica-ai/andrej-karpathy-skills

3. MemPalace

Система долговременной памяти для AI-агентов с сильными результатами на LongMemEval.

GitHub: https://github.com/MemPalace/mempalace

4. OpenClaw

Персональный AI-ассистент с открытым исходным кодом.

GitHub: https://github.com/openclaw/openclaw

5. autoresearch

Фреймворк для автоматизации исследований.

GitHub: https://github.com/karpathy/autoresearch

6. awesome-claude-code

Подборка гайдов, практик и рабочих процессов для Claude Code.

GitHub: https://github.com/hesreallyhim/awesome-claude-code

7. agent-skills

Набор production-ready навыков для AI-агентов.

GitHub: https://github.com/addyosmani/agent-skills

8. AI Agents for Beginners

Бесплатный курс из 12 уроков по AI-агентам.

GitHub: https://github.com/microsoft/ai-agents-for-beginners

9. awesome-llm-apps

Одна из крупнейших коллекций готовых LLM-приложений с исходным кодом.

GitHub: https://github.com/Shubhamsaboo/awesome-llm-apps

10. hermes-agent

AI-агент с акцентом на самообучение и развитие поведения.

GitHub: https://github.com/NousResearch/hermes-agent

11. Qlib

Платформа для количественного анализа и алгоритмической торговли.

GitHub: https://github.com/microsoft/qlib

Информационная асимметрия стоит дорого.

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

👉 @BackendPortal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
💊1
Нашёл 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
Please open Telegram to view this post
VIEW IN TELEGRAM
1🤔1
Как правильно работать с резервным копированием в облаке?

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

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

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

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

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

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

Зарегистрироваться
Please open Telegram to view this post
VIEW IN TELEGRAM