IT-ХОЗЯЕВА

🤝 Технический книжный клуб 2

Брайант Р., О'Халларон Д. — Компьютерные системы. Архитектура и программирование (CS: APP)

📅 12.09.2026 в 11:00 (МСК)

Подробности на платформе

#сообщество

🚀 Толерантность к неопределённости: почему увольнение не должно быть катастрофой

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

Меня зацепила мысль про «количество вариантов» как меру устойчивости: когда есть запасные пути, увольнение перестаёт быть концом света. Согласен, что гарантий нет, но подготовка уменьшает страх и даёт свободу. Правда, сомневаюсь, что большинство реально начнёт готовиться заранее, пока не прижмёт.

Источник

#новости

📝 Как проходит техническое собеседование в IT: этапы, вопросы и подготовка в 2026

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

Читать на ithozyaeva.ru

#статьи

📰 RAG: eval и данные важнее кода

По данным статьи, автор построил RAG-бота для модерации крипточатов и обнаружил, что стандартные улучшения (BM25, реранкер) на его данных ухудшили метрики. Ключевой вывод: настоящая работа — в создании честного eval-харнеса и чистке корпуса, а не в коде. Например, из-за неверной разметки эталона метрика показывала 38%, хотя реальная точность была выше.

Меня зацепило, что автор честно признал: он чуть не пошёл улучшать рабочий поиск из-за кривой разметки. По-моему, это типичная ловушка для RAG-проектов — все гонятся за модными компонентами, но без качественного eval-набора любые «улучшения» — это гадание. Я бы добавил, что диагностика с разделением позиции правильного ответа и причины промаха должна быть обязательной, но её системно игнорируют.

Источник

#новости

🎙️ Бэкендеры заменят фронтов. Трансформация в корпорации.

Что делать фронтам? Всё так плохо?

📅 25.07.2026 в 12:00 (МСК)

Подробности на платформе

#сообщество

Поздравляем Серёгу! Какие же слоняры в сообществе 😀😌

​​Итоги CodeRun Summer: 15 задач и 636 попыток решения

Финал CodeRun Summer Challenge выглядит аккуратно: 15 задач из 15 и третье место среди JavaScript-решений.

Но за рейтингом остались 636 отправок, 443 WebAssembly-модуля и 548 тысяч строк тестов и бенчмарков. Финальные 15 файлов заняли всего 1 142 строки. На одну строку решения пришлось около 480 строк экспериментов.

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

Немного сухой статистики

- 15 решенных задач, итоговое 3 место
- 1 задача с лучшим результатом, 39 мс
- Репозиторий весом 1,35 ГБ и 4 708 файлов.
- 199 052 строк на C
- 1210 сессий с агентами
- 8 852 044 861 чистых токенов без форка для сабагентов

Главное открытие: Accepted — не конец работы.

Интересные факты

Самая большая задач имеет 507 кандидатов и 232 092 строк исходников, а самая маленькая 16 файлов и 1 821 строку.

Для одной из задач пришлось создать 394 МБ тестовых данных.

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

Мои главные уроки

В начале я воспринимал задачу буквально: выбрал JS — значит решай на Pure JS. Но смена парсера, структур данных и алгоритмов не давали впечатляющих результатов. Опыт полезный, но слишком много попыток потрачено на такой принцип, а они были ограничены. Нельзя было пользоваться отправкой как способом подбора идей.

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

Изначально выстраивать идеальный сценарий с агентом, который начинает не с кода, а с условия: фиксирует контракт задачи, ограничивает рантайм. Затем строит оракул, тесты и воспроизводимый бенчмарк на точной версии Node.js. Каждая идея проверяется в отдельном кандидате, и до браузера доходит только вариант, который сохраняет корректность и стабильно выигрывает на нескольких профилях. После отправки агент сверяет результат с тем исходником, который действительно ушёл в судью. Так CodeRun становится финальной проверкой измеренного улучшения, а не дорогим генератором случайных чисел.

Wasm не оказался волшебной палочкой. Часто выигрыш съедала компиляция, иногда обмен с памятью.

Локальные миллисекунды врут. На результат влияют прогрев, скрытые данные, ввод. Поэтому локальная медиана стала не доказательством, а основанием продолжить эксперимент.

Однажды Monaco склеил старый код с хвостом нового. Так выяснилось, что сверка исходника перед отправкой — тоже часть алгоритма.

В итоге сработал не один трюк, а смена процесса: замороженный контроль, проверка корректности, разные профили, одна гипотеза за эксперимент и отправка только при измеримом запасе.

---

#CodeRun #Challenge #JavaScript #Benchmark #8bitJS

​​Ускоряем O(N + T), не меняя Big O. Часть 2. Четыре байта, которые могут изменить результат

В первой части мы получили решение через разностный массив со сложностью O(N + T) и результатом 1,589 секунды.

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

Теперь посмотрим не на количество операций, а на то, что именно лежит в памяти.

В JavaScript все обычные числа имеют тип Number. По спецификации это 64-битные числа с плавающей точкой IEEE 754.

Внутри V8 их представление может меняться: небольшие целые числа могут храниться как Smi, а остальные — как HeapNumber. Об этом подробнее писал ранее: Как V8 работает с числами. Small Integer теория и HeapNumber в V8. Как хранятся числа вне Smi. Теория часть 1

Но у TypedArray правила проще:

- Int32Array хранит ровно 32-битные знаковые целые;
- Float64Array хранит 64-битные числа с плавающей точкой.

При T = 10 000 000 только сам разностный массив занимает примерно:

Int32Array 4 байта на одну запись и для всего массива около 40 МБ
Float64Array8 байт на одну запись и для всего массива около 80 МБ

В два раза меньше памяти означает, что через иерархию кэшей процессора приходится протаскивать меньше данных.

Выбор очевиден, но есть небольшое «но».

Переполнение

По условию одна заявка содержит не больше 1 000 000 велосипедов. Такое значение спокойно помещается в Int32.

Но в одной точке разностного массива могут встретиться миллионы одинаковых событий:

diff[a] += s;

Отдельное значение s помещается в 32 бита, а их сумма — уже нет.

Int32Array не бросает ошибку и не превращает значение в обычный Number. При записи он просто оставляет младшие 32 бита:

const values = new Int32Array(1);

values[0] = 2_147_483_647;
values[0] += 1;

console.log(values[0]);
// -2147483648

Мы прибавили единицу к положительному числу и получили отрицательное — произошло переполнение.

Для JavaScript Number это все еще безопасное целое значение, но для одной ячейки Int32Array — уже нет.

Подведем итог

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

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

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

—-

#JavaScript #V8 #TypedArray #Int32Array #Overflow #Performance #CodeRun #8BitJS

Выступление от нашего гигачада

@fronted_engineer

https://youtu.be/XQ9E-r7i0oE

🗞️ Fedora 45 включает теневой стек: защита от ROP для новых процессоров

Fedora 45 собирается включить защиту на основе теневого стека (Shadow Stack) по умолчанию для бинарников, собранных под x86_64. Это аппаратная фича Intel CET, доступная начиная с 11-го поколения Intel (Tiger Lake, Rocket Lake) и AMD Zen3. Включат поддержку в GCC, Clang и rustc — то есть под раздачу попадают C, C++ и Rust.

Что это даёт на практике: если в приложении переполнят буфер на стеке и попытаются переписать адрес возврата, теневой стек это заметит — у него своя копия адресов в защищённой области памяти. ROP-атаки (Return-Oriented Programming) становятся значительно сложнее. Разумеется, на старых процессорах без аппаратной поддержки (Zen2 и старше) инструкции CET просто работают как NOP — защита не включается, но и не ломает совместимость.

Лично я считаю это правильным шагом: лучше защитить пользователей современного железа, чем тянуть совместимость с процессорами десятилетней давности. Fedora всегда была дистрибутивом для тех, кто хочет новое, а не для тех, кто сидит на Pentium 4. Если у вас Zen2 — ну, может, пора подумать об апгрейде. А если боитесь, что какой-то старый софт сломается — всегда можно пересобрать пакет с флагом -fcf-protection=none. Но в целом, безопасность в продакшене того стоит.

Источник

#новости

🎉 Vue SOTA 2026: на чем строим фронтенд в эпоху ИИ

Доклад о том, где мы находимся сейчас в экосистеме Vue и почему его по-прежнему можно использовать несмотря на то, что большинство вокруг использует React. Будет немного (немного) истории, еще немного сравнения фреймворков, а затем поговорим о том как теперь пишем на Вью и Наксте с агентами.

📅 09.07.2026 в 19:00 (МСК)

Подробности на платформе

#сообщество

telega-gleam 2.0 🚀

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

Главная темка для меня была наконец завести канал зависимостей как R в Effect.ts чтобы из библиотечки можно было выйти действительно в станы фреймворков.

Проблема была такая: все сервисы (db pool, http-клиент, i18n) приходилось пихать в сессию (а это персистируемое состояние) и в адаптере я откидывал эти поля и это по сути утекшая абстракция.

Теперь у Context третий дженерик dependencies:

telega.new_for_polling_with_dependencies(
  api_client:,
  dependencies: Deps(db:, http:, i18n:),
)

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

Дальше всё нанизалось само:

💜storage-слой под одним контрактом сразу с реализацией для postgres / sqlite / redis
💜завел telemetry span-событий на BEAM которые можно нацепить на PromEx/otel
💜telega_webapp + telega_i18n позволяет по кайфу делать фуллстак-приложения целиком на Gleam
💜graceful shutdown теперь без потери апдейтов от телеграмма с полноценным дрейном соединений для всех адаптеров и RAII подходом для зависимостей
💜авто-команды для роутера и поддержка переводов для всего этого

Мне лично кажется что я довел проект до отличного состояния и теперь точно дальше только полишинг. Тч ставим звездочки и пробуем

Код от нейронки плоский — как и её тексты. Только в тексте это заметно всем

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

Возьмём конкретный пример — функцию secure_filename из Werkzeug. Наивный промпт «сделай безопасное имя файла» выдаёт вполне рабочую функцию: чистит пробелы, оставляет буквы и точки. Демка работает. Но она не обрабатывает кучу граничных случаев: имя файла «..» (ссылка на родительскую папку) останется как есть, «CON.txt» на Windows не переименуется в зарезервированное имя устройства, а «naïve.txt» не транслитерируется в ASCII. Оригинал делает всё это — и ещё кучу мелочей, которые автор просто знает, потому что писал не первый день.

И это ключевой момент. Разрыв между кодом сеньора и кодом вайб-кодера — это разрыв в промпте. Сеньор знает, о каких граничных случаях надо сказать нейронке, потому что наступал на эти грабли. Вайб-кодер не знает даже, что такие случаи существуют, и не может попросить то, о чём не догадывается. В итоге он получает «работающий» код, который на самом деле гнилой. И главная проблема: он этого никогда не узнает, потому что оценить код некому. Тесты пройдены? Работает. А что под капотом — никого не волнует, пока не грохнется прод.

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

📚 AI-агенты — что это, как работают и как собрать своего в 2026

«Сделайте нам AI-агента» — за год это превратилось из хайпа в обычную строчку в задаче. Но под словом «агент» каждый понимает своё: кто-то чат-бота с кнопками, кто-то автономную систему, которая сама ходит по сервисам и что-то делает. Разбираем, что такое агент на самом деле, из чего он собран, где уже приносит пользу и почему первая версия так любит сжигать бюджет.

Читать на ithozyaeva.ru

#статьи

💡 Netflix сделала карту микросервисов, которой не хватало каждому

Ночные инциденты в микросервисах — это всегда детектив: метрики орут, логи сыплются, трейсы показывают путь конкретного запроса, но ответа на вопрос «кто кого убил» нет. Netflix построила инструмент, который решает эту проблему в лоб — Service Topology. Это живая карта зависимостей между сервисами, которая обновляется в реальном времени и показывает не только «кто с кем говорит», но и статус здоровья каждого узла, бизнес-домен и владельца.

Главный трюк в том, что они не полагаются на один источник данных. eBPF-сетевые потоки дают полноту (все соединения, даже неинструментированных сервисов), IPC-метрики добавляют прикладной контекст (конкретный endpoint, ошибки, задержки), а распределённые трейсы показывают реальное поведение запросов. Ни один слой не идеален, но вместе они компенсируют слабости друг друга. Система строит три независимых графа и сливает их по запросу за доли секунды.

Что это даёт на практике? Инженер может за секунду узнать, кто upstream и downstream у любого сервиса, оценить зону поражения перед плановым отключением, одним кликом перейти от узла к трейсам или логам, а главное — наложить статус здоровья на граф и сразу понять, локальная проблема или каскадный сбой. Плюс «путешествие во времени»: можно посмотреть топологию на любой момент в прошлом без взрыва хранилища. Вся архитектура — графовая база поверх KV-стора, gRPC-API с фильтрами и ответом быстрее секунды.

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

Источник

#новости

🎙️ Хватит сливать токены! Базовая гигиена для экономии лимитов ИИ-агентов

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

📅 20.06.2026 в 20:00 (МСК)

Подробности на платформе

#сообщество

📰 Переработки: как компании превращают вашу ответственность в бесплатный ресурс

Исследование: переработки в IT редко начинаются с прямых требований — компании просто создают среду, где отказаться "неудобно". Автор разбирает механизм: сначала «чуть-чуть дожать», потом «важный релиз», и вот ты уже в 23:17 с холодным ужином. Главный вывод: переработки — это не про плохое планирование инженера, а про системные проблемы — сжатые сроки, игнорирование рисков и героический менеджмент. Если в твоей команде «авральный режим» стал нормой — это не твоя вина, а повод пересмотреть процессы.

Источник

#новости

🤝 Локальные LLM: как и зачем запускать ИИ у себя дома.

Краткое введение в локальные большие языковые модели: что это такое, чем они отличаются от облачных frontier-моделей, на каком железе их запускать и какие задачи они уже могут решать. Разберём практические сценарии для разработчиков, ограничения локальных моделей, роль RAG, tooling вокруг моделей и почему будущее, скорее всего, не в выборе “локально или облако”, а в гибридном AI-runtime.

📅 23.06.2026 в 20:00 (МСК)

Подробности на платформе

#сообщество

⚡️ Мы попробовали Claude Code в энтерпрайз-разработке и собрали за вас восемь проблем

Коллеги из Циана попробовали Claude Code в энтерпрайз-разработке и собрали 8 проблем. Главная боль: хранение конфигов в репозиториях — если не класть .claude и claude.md в компонент, помощник теряет настройки. Решение — плагины для общей конфиги и MCP для компонентоспецифичной. Вторая проблема — Windows: Claude Code путается в bash-командах, а инструменты сборки отличаются. Циан видит выход в WSL или отказе от Windows. Ещё петли обратной связи: корневой агент должен проверять субагентов, иначе код может не соответствовать требованиям. Итог: Claude Code мощный, но внедрение в большую компанию — это не «поставил и забыл», а настройка инфраструктуры и процессов.

Источник

#новости

📚 RAG на практике — как построить поиск по своим данным для LLM

RAG (Retrieval-Augmented Generation) — самый частый запрос к AI-инженеру: «сделай, чтобы модель отвечала по нашим документам». На бумаге всё просто: нарезал документы, сложил в векторную базу, достал релевантное, подсунул модели. На практике первая версия почти всегда отвечает мимо. Разбираем, как RAG устроен на самом деле, где он ломается и когда его вообще не нужно строить.

Читать на ithozyaeva.ru

#статьи