Kurgan-Telecom Ru | Информационные технологии

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

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

Привет, Хабр! Меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud и развиваю Statuser — сервис мониторинга доступности сайтов, который когда-то начинался как вечерний pet-проект. Я уже рассказывал, как он появился, как в нём выросли статус-пейджи и зачем я научил его следить за DNS.

Той самой первой статье недавно исполнился год. Мне захотелось отметить эту дату не праздничным постом, а в духе самого Statuser: цифрами. Повод удачно совпал с устройством сервиса. Историю инцидентов он хранит ровно год, так что в базе меня ждал аккуратный годовой датасет: 108 312 инцидентов с июля 2025-го по июль 2026-го. По сути, готовая статистика о том, как живёт и падает обычный сайт.

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

Готовиться к собесу по списку «2000 вопросов с ответами» невозможно. Я пробовал: открываешь, листаешь минут сорок, отвечаешь на те, что и так знаешь, закрываешь с чувством выполненного долга. Через неделю в голове ноль. Список не помнит, где ты плаваешь, и не знает, когда ты забудешь то, что вчера повторил.

Лечится это не списком подлиннее, а движком практики: системой, которая помнит каждую встречу человека с каждым вопросом и решает, что показать следующим. Такой движок я собрал для своего тренажёра собесов, и статья целиком про него: корзины Лейтнера для памяти, Elo с поправкой на угадывание для сложности, карта слабых мест, политика сборки сессии. Всё с кодом, графиками и граблями с прода, плюс два отступления: чем в этой задаче неудобен LLM и откуда берётся банк вопросов. Сам я ведущий дата-сайентист, кандидатов собеседую регулярно, так что на проблему смотрю с обеих сторон стола.

В 2026 году серия уязвимостей класса page-cache write вновь поставила под удар практически все актуальные дистрибутивы Linux. Их особенность в том, что злоумышленник может изменить содержимое файла в page cache, не затрагивая данные на диске. Из-за этого классические средства контроля целостности файлов не способны обнаружить такую компрометацию.

В этой статье рассмотрим две наиболее показательные уязвимости этого класса — Dirty Frag и Copy Fail, а затем настроим Wazuh так, чтобы он помогал выявлять признаки их эксплуатации и связанные с ними аномалии.

Пару лет назад я уже публиковал статью о реагировании на инциденты в Linux-системах. Она по-прежнему может быть полезна как практическая шпаргалка, но с тех пор изменился и мой опыт, и требования к таким материалам. В этом цикле статей  я хочу разобрать Linux live response более системно. 

Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. 

Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсудим принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. 

Добро пожаловать под кат. 

В первой части мы разобрали, зачем дизайнеру знать основы вёрстки и как это помогает создавать реализуемые макеты и экономить время. Теперь перейдём от теории к практике и познакомимся с главным языком разметки — HTML.

Если CSS отвечает за то, как выглядит страница (цвета, шрифты, отступы), то HTML (HyperText Markup Language) отвечает за то, что на ней находится и какую смысловую роль играет каждый элемент. Это скелет вашего сайта.

Тамирес Лима, профессор-исследователь в области химической инженерии в Университете Дрекселя, изучает свойства густых, вязких жидкостей — таких, например, как мёд или патока, хотя в лаборатории чаще можно встретить полипропилен или сырую нефть. Используя экстенсиональную реологию (изучение деформации полимерных систем при вытяжении), Лима растягивает жидкости между металлическими пластинами, чтобы определить условия, при которых они начинают течь.

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

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

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

Красным. Правильный ответ — валидация вывода на уровне приложения со схемой и retry-логикой. Я смотрю на объяснение и ловлю себя на раздражении: ну промпт же тоже работает, я сто раз так делал. А потом листаю свои прошлые мокрезультаты и вижу закономерность: я стабильно ошибаюсь в вопросах одного и того же типа. Не потому что не знаю материал — а потому что у меня в голове неправильно проведена одна граница.

Готовясь к CCA-F (Claude Certified Architect – Foundations), я ожидал, что буду зубрить параметры API и лимиты контекста. Вместо этого экзамен методично бил меня по одному и тому же месту, пока я не сформулировал, во что именно я неправильно верил.

Я собрала архивы интернета в карту из 323 задокументированных событий, 129 участников и 18 направлений. Она охватывает период с 2005 по июнь 2026 года

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

Деньги и внимание почти не пересекаются. К направлению интерпретируемости интереса примерно в 37 раз больше, чем можно было бы ожидать при его скромном финансировании около $1 млн. С governance все наоборот: там деньги шли впереди публикаций. То есть финансирование и исследования почти никогда не совпадают по времени.

Примерно к 2023 году государственные деньги обошли филантропию. Раньше поле держалось по сути на одном доноре, а полдюжины национальных институтов - UK AISI, ARIA, Канада, Австралия, NSF, ЕС - за пару лет сделали его международным и все более государственным. А рядом появились деньги другого рода: около $268 млн венчурных инвестиций в safety-стартапы, то есть деньги, которые ждут возврата, а не гранта.

То, что называют консолидацией, на деле скорее разрастание. Внимание и деньги действительно стягиваются к нескольким именам, но при этом 2024 год стал рекордным по числу новых организаций: их появилось 24, в основном небольшие команды по одному-пять человек - интерпретируемость, AI security, мониторинг chain-of-thought.

Слово "Safety" постепенно уходит из названий. Только за 2025 год UK AI Safety Institute стал AI Security Institute, US AI Safety Institute - CAISI, а Open Philanthropy, с которой все начиналось, сменила имя на Coefficient Giving.

Затихнуть - не то же самое, что умереть. У reward modeling последнее собственное событие относится к 2017 году, но под названием RLHF направление дожило до 2025-го. Чаще всего направление не исчезает, а растворяется в чем-то большем или уходит на второй план

Появилась идея для серии постов про наши вайб-кодерские проблемы. Сегодня я расскажу про шишки, которые набила в самой сложной для меня части — в деплое.

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

Итак. У тебя есть гениальная идея гениального сервиса. Ты обсудил её с ИИ, ИИ выдал код и сулит деньги рекой. Осталась мелочь: этот код пока живёт и, вероятно, работает только на твоём ноутбуке. А надо, чтобы в интернете.

Проекты растут. Кодовая база растёт. Время компиляции растёт вместе с ними и переходит все границы разумного.

В какой-то момент я решил: а что если попробовать написать свой компилятор? Пока только для разработки, не для прода. На замену Clang++/G++/CL.EXE.

Эта статья — о первом шаге на этом пути. О парсере C++, который я написал на своём DSL специально сделанном для этого изначально.

Что делать, если системный CDN вашей e-commerce платформы внезапно попал под блокировки, саппорт не помогает, а корзина и галерея на сайте умерли? Рассказываю реальный кейс, как с помощью Яндекс CDN за 150 рублей в месяц, пары сниппетов и MutationObserver удалось ускорить загрузку ядра сайта в сотни раз и вернуть интернет-магазин к жизни. Честный разбор костылей, граблей и результатов в цифрах.

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

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

История о том, как внутренний программный инструмент для отладки вырос в проект, так и не ставший коммерческим, и почему в итоге мы выложили его в open‑source в надежде вдохнуть в него вторую жизнь. Заодно расскажу, что умеет этот инструмент.

TL;DR Digital Points — «программный осциллограф», инструмент для отладки систем реального времени. Может считывать переменные микроконтроллеров в реальном времени и по триггеру, математически обрабатывать их, измерять частотные характеристики, рассчитывать программные регуляторы. Пытались его коммерциализировать, не вышло, и теперь выкладываем в open‑source.

Меня зовут Станислав Герасимов. Я программист С++/Qt, а также Go и выпускник магистратуры НИУ ВШЭ. С детства живу с тяжёлым неврологическим заболеванием — вторичной генерализованной дистонией с выраженными гиперкинезами. После многих лет лечения, нескольких нейрохирургических операций и многочисленных отказов в дальнейшем лечении в России я прошёл повторную операцию глубокой стимуляции мозга (DBS) в Турции у профессора Аттилы Йылмаза. На этом сайте я делюсь своей историей, рассказываю о лечении, программировании DBS, реабилитации, жизни с неврологическим заболеванием, а также о работе в сфере информационных технологий. Надеюсь, мой опыт окажется полезным и поддержит тех, кто также продолжает бороться за своё здоровье и качество жизни.

В предыдущей части мы разбирали проблему командообразования, спровоцированную колебаниями рынка, павшими на благодатную почву слабой архитектуры социального устройства компании. Продиагностировали проблему исходя из Теории социального конструирования Питера Бергера и Томаса Лукмана.

Привет, Хабр! Текущая статья будет полезна тем, кто уже знаком с основами языка программирования Golang и хочет более углублённо изучить его. Исходя из названия стати понятно, что речь пойдёт об аллокаторах, основных видах, плюсах и минусах, а также о том, какой аллокатор используется в Go. Я настоятельно рекомендую прочитать статью целиком, прежде, чем приступать к чтению части конкретно относящейся к аллокатору Go.

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

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

Эта статья как раз про этот переход: от разовых LLM-находок к skills, agents и инструменту, который помогает доставлять их до команды.

Самый цитируемый текст про кодинг-агентов, «How to Build an Agent» Торстена Балла, прекрасен и вреден одновременно. Прекрасен, потому что снимает мистику: агент это LLM, цикл и достаточно токенов, 400 строк, и модель уже правит ваши файлы. Вреден, потому что оставляет ощущение, что дело сделано. А это примерно одна десятая пути.

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

Меня же интересуют оставшиеся девять десятых: конкретные инженерные решения, которые отличают демо от Claude Code, Aider и Amp. В этой статье мы соберём агента на Python с нуля и по одному добавим их: поиск по коду, диффы с подтверждением, модель разрешений для shell, чекпоинты через git, управление контекстом и планирование. Получится чуть больше 400 строк, весь код рабочий, полная версия лежит в репозитории (ссылка в конце).

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

Ко Дню фотографа (12 июля) в этой статье в блоге ЛАНИТ я расскажу про свои любительские эксперименты с фотографированием объектов в мягком ультрафиолете и приведу примеры того, как может измениться самый обычный предмет если над ним немножко «поколдовать» и сменить освещение с видимого спектра на ультрафиолет. Надеюсь, вам будет полезен этот небольшой гайд.