Моя лента

Я работаю в PR с 2001 года. Тогда профессия пиарщика активно развивалась, на рынке было много политтехнологов и консультантов. За 25 лет профессия сильно трансформировалась, в том числе и по части подготовки контента в различных форматах. И если раньше мы по крупицам собирали информацию и превращали ее в разные материалы, то сегодня контент создается намного быстрее.

Каждый раз читаешь новую статью с мыслью: а уникальный ли это контент? Написано самостоятельно, по собственным примерам, тут нет нагенерированных нейронкой кусочков? Со временем стала задумываться – а как проверить? Ведь продвинутые модели генерят текст очень нативным языком, почти не отличить от естественного. Я стала искать материалы по теме – выручили наши техрайтеры, предложив почитать статью в журнале Multilingual, как раз про выявление элементов ИИ в тексте. Это довольно сложный лингвистический материал, но и упрощать тему желания нет. В общем, кто хочет углубиться, как и я — добро пожаловать под кат.

Привет, Хабр.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Я готовил участок под модульный дом в тайге, находясь за 3 500 км от объекта. Нулевой цикл занял четыре месяца и стоил около 2,8 млн ₽ еще до первого фундаментного блока. В статье разбираю, как искал землю, делал топосъемку, подводил электричество, организовывал подъезд и контролировал подрядчиков удалённо – с цифрами, ошибками и выводами по планированию. 

Меня зовут Самир. Я не строитель и не инженер, а маркетолог, поэтому подходил к стройке как к своего рода удаленному проекту: с подрядчиками, сроками, бюджетом и рисками. Главным ограничением было сохранить участок в кедровой роще – разместить дом между деревьями и минимально вмешаться в лес. 

В прошлой статье мы с вами полностью разобрали схемотехнику и изучили компонентную базу легендарного телефона из 90-х годов — Motorola StarTAC. Девайс 1997 года отличался очень низким уровнем интеграции: даже такие базовые вещи, как модем (бейсбенд), DSP и RF-фронтэнд представляли из себя отдельные модули на плате. Однако уже через год, в 1998 году, Motorola представила StarTAC, где наконец объединила DSP, аудиокодек и процессор в единый кристалл.

Казалось бы, вот оно чудо инженерной мысли и дальше развиваться некуда. Но уже в 2001 году, Texas Instruments представила легендарную систему на кристалле Hercules, которая позволяла засунуть практически весь телефон в один чип. Одним из самых известных аппаратов на базе Hercules стал легендарный Sony CMD-J7, о котором мы с вами сегодня и поговорим!

Последние несколько лет в рамках своей работы в коммуникационном агентстве «ЛАМПА» я  активно занимаюсь  пиаром  IT-бизнеса: облачные провайдеры, инфраструктурные продукты, ИБ-вендоры, стартапы на разных стадиях. За это время насмотрелась на сотни корпоративных сайтов, пресс-релизов и экспертных статей, могу с уверенностью назвать главный парадокс рынка: компании, которые разрабатывают сложнейшие IT-продукты, нередко оказываются совершенно беспомощны в том, чтобы объяснить, зачем они нужны. Потенциальный клиент заходит на сайт, читает первый абзац, ничего не понимает и уходит. Даже если сам продукт качественный, удобный и решающий бизнес-задачи, текст не объясняет, почему продукт нужен именно ему прямо сейчас.

Откуда берется облако из buzzwords (модных слов и сложных терминов) 

Посмотрите на главные страницы большинства российских облачных провайдеров, и вы увидите удивительное единообразие: «надежная масштабируемая инфраструктура», «высокая доступность», «гибкое ценообразование», «инновационные решения для цифровой трансформации вашего бизнеса». Если убрать логотипы, вы, скорее всего, не отличите один провайдер от другого. Дело не в случайности и не в лени конкретного копирайтера. Это системная болезнь отрасли, у которой есть понятная причина: технические специалисты, которые пишут или согласовывают тексты, говорят на языке архитектур и стандартов, им кажется, что «IaaS с SLA 99,982%» уже достаточно понятно и убедительно. В то же время маркетинговые команды, насмотревшись на западные тексты корпоративных ИБ-вендоров, копируют их интонацию и специфический новояз, в котором каждое слово звучит внушительно, но не несет конкретного смысла. А у многих PR-специалистов, занимающихся коммуникациями таких компаний, существует страх сказать что-то конкретное и ошибиться, поэтому им кажется, что гораздо безопаснее писать расплывчато. Но расплывчатые тексты не запоминаются.

Если подумать, наши предки обрекли нас на изучение других языков, пытаясь облегчить себе жизнь. Да-да, те самые, которые бегали когда-то по евразийской равнине и говорили на общем праиндоевропейском языке. Со временем они стали распространяться по разным землям, и их общее наречие постепенно изменилось настолько, что носители русского и английского уже не понимают друг друга без учебников. Почему вообще это случилось?

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.

Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

Celery популярен. Модель prefork работает по умолчанию. Autoscale смотрится неплохим вариантом для любого воркера.

Идея посмотреть, как выглядит механизм изнутри родилась давно, когда по работе сталкивался с проблемами у клиентов в отложенных задачах, но никаких артефактов или задокументированного аномального поведения не было. Это стартовая статья об архитектуре, моделях и масштабировании Celery.

Обычно, когда говорят про чиптюн, вспоминают звуковой чип SID на Commodore 64, или же Амигу и её MOD-файлы. Если речь про ПК, это будет тот же MOD и его наследники в лице форматов XM и IT. Но в истории программ для MS-DOS был один краткий музыкальный период совершенно другого рода. Он одновременно родственен и самому ПК, и чиптюну на 8-битках, и компьютерам практически с другой планеты, многочисленным японским ПК — небольшая, малоизвестная, замкнутая на саму себя и параллельная всему и вся вселенная.

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

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

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

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

Моки — достаточно крутой инструмент, если использовать его правильно.

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

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

Финал серии: Agent Teams, GitHub Actions, Agent SDK, TDD, Ralph-loop на ночь и осторожный прогноз на 2027

Серия на Хабре: часть 1 - что Claude Code умеет из коробки · часть 2 - настройки, хуки и Context Rot · часть 3 - автономная работа и параллелизм.

Однажды вечером я дал Claude Code не задачу "сделай фичу", а уже написанную спеку и сложный план. Дальше работал не один чат, а цепочка: оркестратор разобрал план на независимые куски, поднял кодеров в отдельных worktree, дождался их diff'ов, потом вызвал ревьюеров на каждый кусок и собрал итоговый отчёт. Утром у меня был не "ответ ассистента", а несколько веток, замечания ревью и список решений, которые всё равно должен принять человек.

Это третья и финальная часть серии. В первой я показал что такое Claude Code и почему я называю его командой из 15. Во второй - десять настроек, которые эту команду делают управляемой: CLAUDE.md на 30 строк, permissions, хуки, совещание ботиков через Codex и Gemini, Context Rot.

Сегодня про следующий уровень. Когда конфиги настроены и работаешь каждый день, упираешься в новый потолок. Даже команда из 15 человек внутри одной сессии Claude имеет предел. Субагенты конкурируют за контекст, ветки мешают друг другу, ты переключаешься между задачами и теряешь состояние.

Дальше начинается параллелизм, автоматизация и автономия. Десять приёмов, которые превращают Claude Code из "умного помощника" в систему из отдельных агентов, scheduled tasks и CI-задач.

И в конце - честный разговор про то, куда всё это идёт в 2027 и что останется разработчику.

Я поставил себе два челленджа.

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

Второй — попробовать сделать полноценную игровую механику, причем не просто UI-игрушку, а что-то с 3D, сценой, камерой, эффектами и состояниями персонажей. Я не разработчик в классическом смысле, поэтому для меня это был хороший способ проверить, насколько далеко можно уехать с Codex, если у тебя есть продуктовая голова, дизайн-насмотренность и нормальное понимание, что именно ты хочешь получить.

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

Логика такая: сначала можно добавить один чек сразу. Потом включается игровая механика — чтобы сканировать дальше, нужно поиграть. За каждые 9000 метров в гонке или за каждые 3 победы в файтинге открывается новый скан. Так полезное действие, то есть учет расходов, связывается с игровым действием: проехал, победил, заработал прогресс, получил возможность снова распарсить чек.

Altos Computer Systems — американская компания, которая одной из первых сделала многопользовательские системы и Unix‑серверы доступными для малого и среднего бизнеса. Фирма появилась в 1977 году в Сан‑Хосе (Калифорния) и изначально продавала собственные одноплатные компьютеры, на базе которых партнеры строили целые системы.

В отличие от производителей массовых персональных ПК, Altos изначально делали ставку на многопользовательские конфигурации: один сервер и несколько терминалов, подключенных по последовательным линиям. Это была попытка перенести возможности миникомпьютеров и систем уровня IBM в ценовой диапазон, приемлемый для небольших предприятий. Уже к концу 1980‑х Altos установили порядка 128 тысяч систем по всему миру. Рассказываем, как это было и что же пошло не так. 

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

В этой статье я пробую сформулировать облегчённую методологию разработки для кросс-функциональных команд. Центральная идея — явный handover: задача не переходит молча, каждая передача — это осознанное действие с контекстом. По идее, методология должна одинаково работать, когда в команде 3 человека, 15 человек, или когда один или несколько из «участников» — AI-агенты. Это концепт, идея, черновик, открытый для критики и комментариев.

---

Откуда это взялось

Я руковожу центром разработки клиентских и аналитических решений — 50+ человек в семи кросс-функциональных командах с разными стеками. Аналитики, разработчики, QA, DevOps, сопровождение — всё в одной цепочке, от детализации требований до эксплуатации.

За несколько лет мы перепробовали стандартный набор: Scrum, Kanban, Scrumban. Каждый из них решал что-то своё, но во всех трёх я обнаружил одинаковый пробел.

Ни одна из методологий не отвечает на вопрос: что происходит, когда задача переходит от одной роли к другой?

Вот разработчик написал код и поставил статус «Готово к тестированию». Что дальше? Тестировщик это видит? Знает контекст? Понимает, что конкретно нужно проверить? А если тестировщик заболел — задача просто лежит? Кто за это отвечает?

Ни Scrum, ни Kanban на эти вопросы не отвечают. Они описывают итерации, доски, роли — но не сам момент передачи. А именно там живёт большинство операционных потерь.

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

Автор: Александр Никулин, архитектор цифровых двойников ГК "ПЛМ Урал"

Статья посвящена анализу причин отставания проектирования от производства во внедрении гибридных цифровых двойников (ГЦД). Приведена реализация ГЦД электродвигателя на единой платформе. Отмечено, что ключевым барьером является отсутствие нормативной базы и экономических стимулов для использования ГЦД как доказательной базы при сертификации. Сделан вывод о риске потери конкурентоспособности российских разработчиков сложной техники.

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

Факт 1.  Максимально циничная и максимально честная фраза, услышанная мною от одного из топ-менеджеров компании Siemens. В переводе на русский она звучит как «Деньги все расставляют по своим местам».

Факт 2.  Более 25 лет на просторах всемирной сети существует шутка, потрясающе точно отражающая реальный мир. В споре двух ученых, один воскликнул: «Вспомни историю человечества! Первая обезьяна, которая взяла в руки палку и начала работать, стала человеком!». Второй же ученый сочувственно взглянул на своего коллегу и сказал: «Не хочу обижать старика Дарвина, но, когда первая обезьяна взяла в руки палку, работать начала вторая».

Теперь вернемся к цифровым двойникам. Четвертая промышленная революция (Индустрия 4.0) постулирует цифровой двойник как основу жизненного цикла изделия. Причем в качестве изделия может выступать как физический объект, так и технологический процесс, логистический процесс и даже конкретный индивид. (да-да, цифровой двойник клиента уже реальность: имитация поведения, предпочтений и реакций на внешние воздействия в реальном времени. Все уже используется для вашего… разумеется удобства).

Выдуманный мир тёплых (до)ламповых технологий – это не обязательно «стимпанк». Можно заглянуть и глубже, в «клокворкпанк», ведь спиральная пружина – двигатель более древний и при этом более компактный, чем паровая машина. Она широко используется с середины XVII века: именно благодаря металлической спирали часы стали карманными. Часовая пружина крутила шестерёнки заводных игрушек, музыкальных шкатулок, граммофонов и много чего ещё, зачастую совершенно шедеврального a la лесковская блоха. Послужила она и науке — вспомним хоть «аэродинамическую машину» Ломоносова. А в конце XIX века её пытались приспособить для привода «серьёзной» техники: мотоциклов, автомобилей, торпед... и трамваев!

Два американских марсохода продолжают кататься по поверхности этой планеты, пытаясь найти что-нибудь интересное. И не без успеха. Около месяца назад в Nature Communications вышла очередная статья про подвиги устройства под названием Perseverance. В статье подводятся промежуточные итоги его работы в западной части кратера Jezero, в котором миллиарды лет назад было озеро.

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

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

Именно под такие задачи и создавалось отраслевое решение 1С:ERP Агропромышленный комплекс. Оно построено на базе 1С:ERP Управление предприятием и дополняет корпоративный контур специализированными инструментами для растениеводства и животноводства. По сути, это цифровая основа для современной агрокомпании: от планирования посевной и учета полевых работ до аналитики по стаду, технике, затратам и эффективности.

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