Когда-то давно мне подарили кучу VoIP-телефонов, которые списали на моей старой работе. Среди них были два Snom 360 Business, выпущенные в 2005 году. Изначально я хотел настроить АТС на основе Asterisk для всех доставшихся мне телефонов, но в процессе обновления прошивки на одном из аппаратов Snom 360 мне пришла в голову идея получше. У телефона есть экран и клавиатура... получится ли на нём запустить Doom?
«Что есть "реальность"? И как определить её? Весь набор ощущений: зрительных, осязательных, обонятельных — это сигналы рецепторов, электрические импульсы, воспринятые мозгом.» — Морфеус, фильм «Матрица»
Если процессор — это мозг компьютера, то может ли он быть ещё и частью некой виртуальной реальности? Симулированная память, программно-определяемая периферия, искусственно сгенерированные прерывания...
Моим первым компьютером был 286 с 1 МБ ОЗУ и жёстким диском на 50 МБ (если я правильно помню). Поэтому я решил взять процессор 286 и попробовать симулировать остальную часть компьютера вокруг него. Или хотя бы сделать так, чтобы он мог запускаться и выполнять какой-то простой ассемблерный код.
Два года назад я купил два процессора Harris 80C286-12. Мои воспоминания довольно туманны, но кажется, буква C в их маркировке важна, потому что она означает меньшую чувствительность к точности таймера (12 в конце означает, что процессор предпочитает работать на 12 МГц), и что на нём даже допустимо пошаговое выполнение.
Поначалу я не добился особых успехов, и мой проект перекочевал в ящик, но в этом году я снова к нему вернулся и решил разобраться, что же пошло не так.
Хотите прокачать React и Kotlin, разобраться, как устроены саги и брокеры сообщений в распределённых системах, подтянуть Docker и Linux, а заодно понять, где в 2026-м заканчивается ажиотаж про хранилище данных (DWH) и начинается работающая практика? В этом дайджесте собрали 60 бесплатных уроков марта по ключевым направлениям: программирование, архитектура, инфраструктура, информационная безопасность, тестирование, машинное обучение и наука о данных, аналитика и управление.
Мехника прежняя: прикладные разборы от экспертов, инструменты и подходы из реальных проектов, возможность задать свои вопросы. Выбирайте тему, регистрируйтесь и приходите за конкретикой.
Эта статья - не попытка критиковать конкретный банк и не утверждение, что алгоритм ошибся. Я не знаю внутренних правил скоринга, не видел модели и не утверждаю, что решение было неверным.
Это разбор частного случая глазами человека, который внезапно оказался в очень неприятной жизненной ситуации в связи с тем, что в ответственный момент классификатор «принял решение» об отказе в ипотеке. В данный момент ситуация продолжает оставаться неясной и я нахожусь в стрессе. В какой-то степени, попытка хоть как-то разобраться в том, какие факторы повлияли на отказ в выдаче ипотеки, хоть как-то снижает уровень стресса.
Связка React+MobX хорошо себя зарекомендовала при работе с формами, в то время как за реактивность модели данных в Angular обычно отвечает библиотека RxJS. Но что делать, если вы хотите воспользоваться преимуществами Angular в React или Node.js? В этой статье речь пойдет о новой библиотеке от Cloud X, которую мы разработали для того, чтобы проложить “мостик” из мира Angular, где всё богато, но дорого в мир React, где все дешево, но скудно. В этой статье я описываю применение ядра @cloudx/react-ui-kit-forms, которое отвечает за структуру модели данных, реактивность модели данных и контроль состава данных (валидацию), позволяя “скрестить” плюсы React и Angular на одном проекте.
Третья эпоха разработки ПО с помощью ИИ
На прошлой неделе в инженерном блоге Cursor был опубликовал манифест «The third era of AI software development». В посте описываются три эры AI-разработки в контексте использования самого продукта. Пост содержит интересную внутреннюю статистику Cursor, которая показывает: смена парадигмы — это уже не прогноз, а то, что происходит прямо сейчас.
Я перевёл этот текст, потому что он хорошо отражает то, что я сам наблюдаю в своей работе последний год. Пост короткий и лаконичный, но заставляет хорошо задуматься. Приятного чтения.
По первоначальному замыслу эта статья должна была стать моей первой публикацией на Хабре, но не сложилось. Немногим более года назад, наткнувшись на статью про шахматные доски, я вспомнил о своём старом проекте антропоморфного шахматного робота и было взялся за текст, но спустя пару недель у меня родилась дочь, и работа снова остановилась.
Сам проект растянулся на долгое время и оказался, в целом, не слишком удачным (хотя и был доведён до условно рабочего состояния). Из-за длительных перерывов как минимум один раз мне пришлось переписывать код практически с нуля – я уже не мог понять, как именно он работает и, главное, почему не работает. В итоге проект всё же был доведён до логического завершения и функционирующего прототипа, но по ряду причин я считаю его практически провальным – о них я расскажу в конце статьи.
Если вы пишете бэкенд на Python или только собираетесь вкатиться в эту тему, вы точно слышали про FastAPI. Он обещает скорость NodeJS, автодокументацию из коробки и строгую типизацию. Звучит круто, но для новичка любая новая технология выглядит пугающе.
В этом гайде я хочу взять вас за руку и провести по всем базовым концепциям фреймворка. Мы напишем свой первый API-сервис с нуля, разберем частые ошибки новичков с асинхронностью и поймем, как писать чистый код с помощью APIRouter. Спойлер: баз данных и сложных ORM сегодня не будет, сосредоточимся на чистом понимании магии FastAPI.
Большинство разработчиков думают об офлайн-режиме в последнюю очередь - когда приложение уже готово, дизайн согласован, а PM давит на дедлайн. В результате пользователь видит белый экран, зависший спиннер или, что хуже - молча потерянные данные. Эта статья про то, как выстроить честный UX для состояний без сети: от психологии тревоги до кода с экспоненциальным откатом, от визуального языка ошибок до стратегий разрешения конфликтов. Всё это пригодится при разработке любого мобильного или веб-приложения, которое работает в условиях нестабильного соединения - а таких большинство.
В любой традиционной профессии путь в специальность выглядит одинаково: школа → пту/вуз → работа.
Врачи учатся порой аж 9 лет, прежде чем получить право лечить людей.
Инженеры-строители. Учителя. Юристы. И многие другие профессии, требующие высококвалифицированные навыки от сотрудника, учат кадры не менее 4 лет.
И только в IT всё работает иначе.
Здесь люди приходят отовсюду: из физики и лингвистики, из продаж и маркетинга, из «гаражных» проектов (привет амазон) и самообразования. Здесь можно за полгода стать востребованным специалистом без единого профильного диплома.
Это уникальное явление, перевернувшее мир. И оно заслуживает отдельного разговора.
Приветствую.
В 1936 году Алан Тьюринг опубликовал статью, которая среди прочего доказала одну неприятную вещь: невозможно написать алгоритм, который для любой программы и любого входа определит, остановится программа или нет. Проблема остановки. Мы натыкаемся на неё гораздо чаще, чем кажется. Иногда прямо в Cargo.toml.
На коротких задачах coding-агент выглядит почти как живой разработчик: читает код, гоняет тесты, находит проблему, предлагает diff, но на длинной дистанции магия заканчивается. Стоит агенту или пользователю подмешать еще пару логов, несколько файлов "на всякий случай" или еще один MCP-сервер, и агент начинает забывать договоренности, повторять уже проверенные шаги и терять план.
Обычно это объясняют так: "модель тупит" или "надо лучше промптить", но на практике проблема часто в другом: мы складируем состояние задачи в историю чата и надеемся, что модель удержит его сама. Не удержит.
Контекст у LLM - это не бездонный мешок, а рабочая часть "памяти" модели, ее нужно проектировать: что хранить отдельно, что подмешивать just-in-time, что выбрасывать после шага и что обязательно возвращать после compaction.
В этой статье я разберу context engineering на примере coding agents, а конкретно на Claude Code: почему long context до сих пор деградирует, почему проблема особенно больно бьет по агентам, чем полезны /compact и Plan Mode, и как собрать минимальный контекстный конвейер без магии и лишней философии.
В позапрошлом году вышла статья https://habr.com/ru/articles/814529/ про синхронизацию позиции персонажа между клиентом и сервером в Lineage 2. После прочтения появилось желание перенести эту логику в свои сырцы от когда-то разрабатываемого сервера и, возможно, запустить его где-то для себя и старых друзей поразвлекаться. Понятное дело, что современного ПК с кучей рам, хорошим процом и nvme дисками при желании было бы за глаза даже для запуска тысяч игроков, но заниматься организацией доступа из дикого интернета на свой ПК желания не было, да и обеспечивать постоянный доступ - дело такое себе. В наличии была самая дешманная впска у хостера F с доменом, но с сильно ограниченными ресурсами: одно ядро и 512Мб рам. Мягко скажем, памяти маловато.
Наспех восстановил сырцы, актуализировал сборку под современные версии java и либ, запустил - потребление хипа примерно 400Мб на старте. Без геодаты. А с геодатой - 1200Мб.
И тут появился спортивный интерес влезть в 512Мб, да еще и с геодатой.
Результатом стал оптимизированный драйвер геодаты, зашаренный на гитхабе https://github.com/mosinnik/l2-geo, репорт о потенциальном баге в JDK и эта статья.
За последние 25 лет в IT не просто обновились версии библиотек, а успели появиться и исчезнуть технологии и отрасли целиком. Сменили друг друга целые парадигмы разработки, каждая из которых ощутимо меняла подходы программиста к работе.
Меня зовут Алексей Мартынов, я разработчик и предприниматель с 25-летним опытом в IT, программный директор и ведущий эксперт направления веб-разработки в Яндекс Практикуме. В этом материале я хочу рассказать об уроках, которые я извлёк на своём долгом пути, и поделиться советами. Возможно, они будут полезными для начинающих разработчиков.
Как мы добываем железо из руды? Бурим горную породу и руду в карьере, закладываем взрывчатку и взрываем, чтобы экскаватор мог зачерпнуть породу. Огромные куски до 1,2 метра вывозим на БелАЗах на перегрузочные пункты, затем перегружаем в железнодорожные думпкары, потом дробим до состояния пыли, отсеиваем вскрышу и извлекаем железо.
Работа у нас масштабная: экскаваторы высотой с четырёхэтажный дом, 240-тонные БелАЗы и много взрывов. При этом мы имеем одно из самых низких в отрасли содержаний (в процентном соотношении) железа в руде. Поэтому просто бурить, взрывать и возить недостаточно. Эффективность начинается с качества руды, которое мы отслеживаем буквально в каждом ковше экскаватора.
Меня зовут Вячеслав Загирный, я руководитель проектов в ЕВРАЗе. Мы стали первыми в России, кто создал IT-систему, позволяющую прослеживать качественные показатели руды от блочной геологической модели до дробильно-обогатительной фабрики. Проект называется «Геометаллургия». В этой статье расскажу, как всё устроено.
Встроенный WebSearch в Claude Code стоит $0.01 за запрос и регулярно падает с «Rate limit reached» — даже на подписке за $200/мес. Я поднял локальный SearXNG, подключил через MCP — и теперь поиск бесплатный, без лимитов, а запросы не уходят на серверы Anthropic. Установка — 10 минут, три файла конфигурации.
Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.
Бывает так: ушёл на тренировку, сел в кафе, поехал куда-то. В голове крутится задача, которую хочется уже добить. Раньше приходилось ждать, пока вернёшься за стол. Теперь нет.
Codex Remote даёт браузерный интерфейс к Codex CLI на вашей машине. Открываешь с телефона, управляешь сессией, видишь изменения файлов до того, как они применились. Машина работает у тебя дома или на работе, ты где угодно.
Есть также возможность просматривать незакомиченные изменения в git'е в самом диалоге с моделью.
У программистов много проблем со временем. Сегодня речь пойдет не о time managment'е, управлении планированием и вечно горящих сроках, а о подводных камнях работы со временем при разработке ПО.
Как мне удалось создать свой полноценный продукт с функционалом и системой лицензирования с нуля без навыков программирования используя и IDE Cursor. Полный разбор в статье по шагам с инсайтами.
