Программирование *

Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти.

К 1991 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders?

В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже.

Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.

Язык T создавался как прямой наследник C для вычислительных систем, работающих в сбалансированной троичной логике. Подобно тому, как C стал универсальным языком для двоичных машин, T призван занять ту же нишу в мире троичных процессоров. Мы сохранили философию минимализма и эффективности, но заменили биты тритами, байты трайтами, а бинарные операции — их трёхзначными аналогами.

Книга следует проверенной структуре «Языка программирования C», чтобы читатель, знакомый с C, мог быстро освоить T, а новичок получил систематическое введение в троичное программирование.

Я занимаюсь разработкой ПО для строительной механики. В процессе работы над одним из проектов возникла потребность в простом инструменте для построения линий влияния в многопролётных шарнирных балках. Готового решения под рукой не оказалось, и я написал свой веб-модуль.

Результатом захотелось поделиться с сообществом — вдруг кому-то тоже пригодится. Под катом — описание того, что получилось, как это работает, и где может быть полезно.

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

500 гипотез за 3.5 месяца. 470 — мусор. 30 — правда, которую я не хотел знать. Например: я по 4 часа «анализирую новости», а по факту — избегаю одного телефонного звонка.

Система находит паттерны поведения, которые ты не видишь, потому что находишься внутри них. 10 аттракторов, корреляции метрик, AGENTS.md и открытый код на GitHub.

Часто бывает такая ситуация, что вы разрабатываете прошивку для электронной платы у которой есть ADC порты.

Рано или поздно Вам придется как-то убедиться, что ADC в самом деле измеряют то напряжение, что приложено со стороны улицы.

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

В жизни каждого разработчика иногда приходится рассматривать бинарные файлы через специальные HEX-редакторы.

Мы открываем его, видим три колонки цифр и букв, и кажется что все предельно ясно-понятно. Но почему адреса считаются шестнадцатеричными, что такое ниббл и зачем он вообще нужен? В этой статье мы не просто напишем свой hex-редактор на Python — мы разберем, как он устроен, от битового представления до цветовой подсветки. Выясним, чем подсветка по нибблам отличается от подсветки по категориям байтов, и почему градиенты в hex-дампе — это не просто украшение, а рабочий инструмент.

Также мы изучим, какие практики и паттерны используются при написании редактора — от mmap для чтения файла до интерпретации байтов.

Будет и код, и архитектура, и результат, и практика.

О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это.

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

И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.

Мир frontend-разработки за последние несколько лет изменился коренным образом. Если еще пять лет назад стандартом де-факто были одностраничные приложения (SPA), где вся логика выполнялась в браузере, а сервер был просто REST API, то сегодня мы наблюдаем массовый переход к гибридным архитектурам. Next.js с его Server Components и Server Actions стал не просто популярным фреймворком, а промышленным стандартом для enterprise-приложений.

Этот переход принес с собой множество преимуществ: улучшенную производительность, лучший SEO, упрощенную разработку. Однако он же изменил и модель угроз, с которыми сталкиваются разработчики. Привычные методы защиты, основанные на JWT в заголовках и CORS-политиках, больше не обеспечивают полную безопасность. Серверная логика теперь исполняется в непосредственной близости от клиента, а граница между фронтендом и бэкендом стала размытой (для некоторых сценариев).

По данным исследований Snyk и других security-вендоров, 39% облачных средств содержали уязвимые версии React и Next.js в 2024-2025 годах. Это не просто статистика. Это реальные приложения, обрабатывающие данные пользователей, платежную информацию и конфиденциальные бизнес-данные. Уязвимость CVE-2025-55182, получившая максимальный рейтинг CVSS 10.0, показала, насколько критичными могут быть последствия недостаточного внимания к безопасности в современных frontend-приложениях.

React Server Components (RSC) стали новым стандартом, но вместе с ними пришли новые векторы атак. Server Actions, предоставляющие удобный способ вызова серверной логики прямо из компонентов, фактически являются публичными HTTP-эндпоинтами. При неправильной конфигурации они могут стать лазейкой для злоумышленников. Традиционный подход security through obscurity здесь не работает: скрытие эндпоинтов не защитит от целенаправленного перебора.

В ML легко перепутать аккуратное число с честной вероятностью: модель выдаёт predict_proba = 0.9, и кажется, что событие произойдёт в 90% случаев. Но это не всегда так.

В статье разбираем, почему выход модели может быть просто внутренней оценкой уверенности, чем калибровка отличается от AUC, как увидеть смещение через reliability diagram и Brier score — и когда вероятности нужно обязательно калибровать, прежде чем использовать их в бизнес‑решениях.

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

RAG-Anything устраняет ненужные телодвижения.

С помощью RAG Anything возможно обрабатывать подавляющее большинство ходовых форматов файлов(PDF, DOC, PPTX, XLS, JPG, BMP, GIF и др. )

В этой статье мы разберем механизм работы фреймворка и на примере посмотрим, как он работает.

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

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

Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них — простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

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

Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме.

Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds, которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться.

Более явный пример для шейдеров будет, когда lighting.fx, скомпилированный с дефайном SIMPLE_BUMP_MAPPING, и lighting.fx, скомпилированный с PARALLAX_BUMP_MAPPING, физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый.

С мешами история та же самая, и ship.mesh, загруженный в менеджере ресурсов, и тот же ship.mesh, лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет.

15-й выпуск IT-новостей от OpenIDE!

Вредоносная версия плагина провисела в VS Code Marketplace 18 минут и этого хватило, чтобы слить конфиги Claude Code, ключи AWS и 3800 репозиториев GitHub. 

Параллельно двое братьев удалили 96 правительственных баз данных за ~1 час после увольнения по Teams, а Bolt вообще уволил весь HR-отдел.

Есть такие анти‑паттерны, которые выглядят нормально и даже проходят код‑ревью, но тихо убивают производительность в горячих местах: 

- Конкатенация строк в циклах

- String.format() в горячем коде

- Автобоксинг 

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

Если вы пишете на Java и у вас всё вроде работает, но под нагрузкой сервисы начинают задыхаться, в новом переводе от команды Spring АйО рассмотрим конкретные паттерны, на которые стоит посмотреть.

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

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

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

Гоняю Codex CLI каждый день параллельно с Claude Code. За январь-май 2026 OpenAI выкатил столько релизов, что я честно сбился со счёта — GPT-5.3-Codex, GPT-5.4, GPT-5.5, Desktop app, Codex в ChatGPT mobile, Browser Use, Computer Use на macOS, стабильные hooks, plugin marketplace, /goal, Windows sandbox, Chrome extension. Это дайджест по реальному changelog с моим ранжированием — что зашло, что нет, и одна важная инверсия популярного мнения. Топ-1: GPT-5.5 — на голову выше 5.4, честно говоря, удивлён, что не назвали GPT-6. Топ-2: наблюдаемость субагентов через spawn — раньше я вручную копировал промпты, чтобы видеть, что делает дочерний агент. Теперь кликаю в карточку и вижу всё. Тотально поменяло работу команды. Что не зашло: автоматизации глючат, скорость уступает Opus 4.7, у Codex два режима запуска агентов и в каждом промпте приходится напоминать о правильном. Инверсия: лимиты у ChatGPT-плана сейчас БОЛЬШЕ, чем у Anthropic, и сбрасываются регулярно. Это контр-интуитивно, но это так. В статье: ранжированный топ-5, грабли, что я НЕ включил (потому что про это были отдельные статьи), и отсылка на архив со скиллами оркестратора в моём Telegram-канале.

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Алексеем Федулаевым — руководителем отдела облачной безопасности МТС Web Service, бывшим руководителем ИБ в Wildberries, автором Telegram-канала «Ever_Secure» и постоянным спикером профильных конференций – о том, как на деле устроена профессия: от детского взлома родительских паролей до защиты корпоративных облаков, почему DevSecOps-специалисты входят в топ самых высокооплачиваемых ИТ-профессий и как в этой сфере не выгореть, когда угрозы появляются каждый день.    

Привет! Я Ильдус Тукаев, разработчик в команде образовательной платформы Т-Банка. Мы помогаем школьникам, студентам, молодым специалистам и сотрудникам получать знания и качать свои софт и хард навыки. Основной язык у нас Go, но сегодня расскажу больше про архитектурную тему: как у нас в команде использовался паттерн Outbox и как он эволюционировал.

За полтора года реализация Outbox прошла четыре итерации. По пути мы ловили VACUUM, который останавливал сервис на три часа, теряли 5% событий за полтора дня и заваливали поддержку обращениями. Расскажу, какие реализации мы пробовали, на какие грабли наступали и почему остановились на варианте, который сами же не считаем идеальным.