Моя лента

Всем привет! Хочу рассказать, как мы проектировали кэш поиска отелей и почему за полтора года прошли путь от Infinispan к managed Redis а затем к Postgres. По стеку java-21, spring-boot-3, 1 вендор отелей, расчетная нагрузка 1000 RPS и 10M запросов в сутки.

Практический эксперимент с Meshtastic: две Heltec ESP32 LoRa 32 V4, связь на 702 м в городской среде, разбор LoRa-настроек, ролей нод, MQTT и Python-мост к локальной LLM через Ollama.

Браузер «Луна» (разработчик — ООО «Инновационная разработка» Innovative Development LLC, которое на 99% принадлежит компании «Мультибонус») в Apple удалили из App Store. При этом уже установленные версии проекта продолжают работать у пользователей в обычном режиме. Причины удаления пока неизвестны. Решение остаётся доступно в Google Play и RuStore.

Полгода прошло с первой статьи https://habr.com/ru/articles/969230/ , вариометр летает и сигнализирует о наборе высоты и о потере высоты, пилоты довольны. Код сыроват конечно. EMA фильтр стоит, линейная архитектура стоит, записи высот в полете нет и экспорта нет. Как-то работает. Но можно качественнее сделать. А вот когда лень переписывать с нуля, знакомая херня? Но решился.

Развернул Hermes Agent, закинул на аккаунт DeepSeek4 40 юаней, это 430 рублей, и начал диалог в терминал. Работал в диалоге с консолькой, ну просто магия. Без промптов. "Сделай FSM вместо ифов, добавь зуммер в стиле Браунигер, компенсацию акселерометра по трём осям с учётом гравитации, а не по модулю, трек полёта на флешпамять кольцевым буфером с CRC, WiFi экспорт через вебморду."

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

И в этот момент код перестаёт быть инженерной задачей. Он превращается в бесконечное тушение пожаров.

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

Почему Фрейд и квантовая механика объясняют бизнес-решения лучше, чем большинство MBA-курсов

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

И причина лежит не в стратегии, не в рынке, не в конкурентах.

Я работаю в 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, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.