QFE

301 и 302 Ну люблю я вопросы про коды ответа HTTP. Коды 3xx означают, что ресурс был перемещен. 301 говорит о постоянном переносе адреса, а 302 — о временном. Правильным ответом был второй.

502 и 504 Опытный глаз с первого взгляда различил в этом вопросе коды ответа с проблемами на стороне сервера. Коды начинаются с 5xx. Коды 5xx означают, что запрос был отправлен, но ответ от сервера либо не пришел, либо с ним были какие-то проблемы. Осталось понять разницу между 502 Bad Gateway и 504 Gateway Timeout. Код 502 означает, что ответ пришел, но он некорректен. Код 504 означает, что за выделенное время ответ не пришел. Правильным ответом был последний.

Снова про уровни OSI Возможно не все работают напрямую с OSI, но я думаю, что это отличный пример темы, когда понимание позволяет писать значительно более качественную документацию. Например, понимание разницы между балансировщиками на уровнях L7 и L4 позволяет лучше описывать взаимодействия по сети. Оба балансировщика перераспределяют трафик между серверами. В чем же разница? На транспортном уровне L4 у балансировщика есть доступ только к IP-адресам и портам. То есть он может перенаправить поток по-разному для портов 3306 и 80, но не для разных URL-адресов. На прикладном уровне L7 балансировщик может отправлять картинки на сервер server-img.local, а авторизацию — на server-auth.local. Правильным был ответ про то, что балансировщик на уровне L7 может перенаправлять трафик в зависимости от данных запроса.

GraphQL Я не буду пытаться сейчас объяснить всю сложность реализации GraphQL, да это и не нужно. Я хочу донести основную идею. Основная идея состоит в том, что в случае RESTful API мы получаем от сервера изначально известные поля с известной структурой, например:

user: Elena,

date: 25.07.2026,

occupation: technical writer

Этих полей может быть слишком много или недостаточно, поэтому в GraphQL есть возможность точно указать поля, который вы хотите получить, например, user и occupation. Итог: GraohQL дает возможность программе указывать определенные поля, которые нужно получить от сервера, и получать только их. Правильным ответом был первый.

Git rebase и git merge Ни одна из этих команд напрямую не связана с удалением веток или подключением к сети. Так что два последних ответа были совсем не про то. Основная разница между git merge и git rebase в том, что в результате первой команды в истории основной ветки появляется один мерж коммит, а в результате второй — история ветки, то есть порядок коммитов сохраняются, и новые коммиты добавляются в конец ветки. Представим это на примере двух очередей из людей, которые держат коробки: 🤩 git merge берет одну из очередей и все коробки передает одному человеку, который становится в конец соседней очереди; 🤩 git rebase расставляет в вашей очереди людей из другой очереди в том же порядке, как они стояли в своей очереди, а потом добавляет в конец очереди людей из вашей очереди.

⭐️⭐️ 16 июля пройдет бесплатный онлайн-митап TechDocs Поговорим о документации с разных сторон: как создавался портал разработчиков RWB, зачем техническим писателям единая система оценки задач и можно ли построить зрелые процессы документирования, если в команде всего один техписатель.

В программе: ⏹️ «Летопись документации разработчиков WB API» | Лидия Рудакова, лид команды документирования Public API. ⏹️ «Единая система оценки задач техписателей: как внедрить новый подход без боли» | Евгения Красильникова, технический писатель в команде разработки документации и методик обучения ПО. ⏹️ «100 к 1: Как организовать подход "документация как услуга" в одиночку» | Антон Гафаров, технический писатель в команде FinTech Infra.

Когда: 16 июля, 16:00 Формат: онлайн ➡️ Зарегистрироваться

В телеге миллионы баррелей нефти и я её оттуда качаю. В последнее время часто использую этот прием, подумал, будет интересно и вам. Смысл прост: - Скачиваем нужные каналы и чаты (базовый экспорт JSON через Telegram Desktop). - Поднимаем по ним поиск. Если скачивание - это пара кликов, то поиск чуть сложнее. Но ничего такого, что не делается полностью за ночь агентом. Ниже правила, которыми я руководствуюсь при создании своего RAG по телеге: 1. Единица смысла - тред, а не сообщение. Искать по коротким вырванным репликам бесполезно. Reply-цепочки детерминированно склеиваются в один диалог-документ. А лонгриды, наоборот, режутся на чанки с нахлестом. 2. Один Postgres вместо зоопарка баз. Postgres 17 + pgvector тащит всё. Лексический поиск (FTS) и семантический (по векторам) идут параллельно. Плюс опечаточный поиск. Результаты сливаются через алгоритм RRF - а потом верхушка выдачи проходит через reranker. 3. Костыль для памяти Mac. Локальная векторизация (bge-m3) быстро забивает память Apple MPS на длинных текстах и вешает машину. Вылечилось адаптивным размером батча и принудительным torch.mps.empty_cache() после каждого коммита в базу. 4. “Бесплатный” RAG. Чтобы не платить за токены при генерации ответов, пайплайн скармливает результаты поиска в claude CLI (claude -p). Итого:

FTS ищет по словам + Vector ищет по смыслу + триграммный нечеткий поиск прощает опечатки -> RRF склеивает три выдачи -> Reranker перечитывает верхушку -> Claude делает синтез по найденным фрагментам

Как это выглядит на практике: Запрашиваю: «Проблемы промптов в агентских флоу и как их решали?» Скрипт находит куски в базе, отдает Клоду, и тот синтезирует выжимку: какие были жалобы (нестабильность, блуждание агента) и как решали (через флоу с уточняющими вопросами). А внизу ответа - список кликабельных t.me/ ссылок на конкретные посты, откуда он это взял. Таким образом я определяю, например, что интересует сообщество, как решались проблемы. Перегоняю нефть в высокооктановый бензин. —— Ставим лайки, подписываемся на канал @azalio_tech, заставляем друзей.

Принесла чудесный пост одного моего чудесного знакомого. Хороший канал, рекомендую.

JWT (JSON Web Token) Это стандарт для безопасной передачи информации между клиентом и сервером в виде JSON-объекта. Чаще всего его используют для авторизации: после входа пользователя сервер выдает ему токен, который клиент прикрепляет к последующим запросам как цифровой пропуск. Токен состоит из трех частей, разделенных точками: заголовка (Header), полезной нагрузки с данными (Payload) и цифровой подписи (Signature). Цифровая подпись — это финальная часть JWT, которая гарантирует его целостность и подлинность. Она создается на сервере путем хэширования заголовка и полезной нагрузки с использованием секретного ключа, известного только серверу. Важно понимать, что JWT по умолчанию не шифрует данные — любой может декодировать его содержимое из формата Base64. Однако цифровая подпись делает невозможным незаметное изменение этих данных. Если злоумышленник попытается отредактировать информацию в токене (например, изменить роль пользователя с обычного на администратора), сервер сразу обнаружит это при проверке, так как подпись перестанет соответствовать измененному содержимому.

CORS (Cross-Origin Resource Sharing) Это механизм безопасности в браузерах, который регулирует доступ к ресурсам с разных доменов. По умолчанию браузеры запрещают веб-страницам отправлять запросы к домену, отличному от того, с которого загружена сама страница. CORS позволяет серверу явно указать, каким внешним доменам разрешено запрашивать его ресурсы, используя специальные HTTP-заголовки. Частая ошибка возникает, когда на сервере не настроены необходимые заголовки, например Access-Control-Allow-Origin. В результате, когда фронтенд-приложение пытается отправить запрос к API на другом домене, браузер блокирует этот запрос по соображениям безопасности. В консоли разработчика при этом появляется сообщение о нарушении CORS-политики, хотя сам запрос мог успешно дойти до сервера.

Webhook (вебхук) Это способ оповещения одного приложения другим о наступлении какого-либо события в режиме реального времени. Его часто называют «обратным API» или «серверным уведомлением». В отличие от стандартного API, где ваше приложение должно постоянно опрашивать сервер («Появились новые данные?»), вебхук работает по принципу «не звоните нам, мы сами вам позвоним». Когда в системе происходит событие, она сама отправляет HTTP-запрос на заранее указанный вами URL.