Все потоки

В данный период своей жизни я пытаюсь создать свой стартап. Но никакой стартап не будет существовать без инвестиций. Возможно, если бы за душой было несколько лишних миллионов долларов, то, возможно обошелся бы и своими силами. Но имеем что имеем. Сразу хочу рассказать немного о себе. У меня за мою жизнь уже было несколько стартапов, один из которых дошел до третьего раунда инвестиций в миллион долларов. Приятные ощущения, работающая компания, но кризис.com‑ов решил все иначе, к сожалению. Были еще небольшие разные стартапы, на которых получалось тоже немного заработать. Это я к тому, что опыт какой никакой все‑таки есть. И каждый раз, в каждом своем проекте всегда я слышал одни и те же вопросы от программистов в своей команде: «Зачем нам вообще пилить MVP?», «А сколько денег нам дадут?», «И что, а зарплаты не будет что ли?» Когда я им отвечал честно, что первые инвестиции не про заработок, то ответ мой их все время расстраивал, ведь денег хочется прямо здесь и прямо сейчас. Прежде чем продолжить, то думаю, что стоит рассказать вам о том, кто же такой бизнес ангел для стартапа. Зачастую, если вы небольшая молодая и зеленая компания, у которой в лучшем случае есть какой‑то прототип или минимально рабочий продукт, то всяким большим дядям из больших и богатых фондов вы не интересны, они не видят в вас реальную выгоду, не видят реальных клиентов (которых обычно даже и нет на начальных этапах), не видят то, куда все ваши фантазии могут их привести. Но вы можете найти бизнес ангела, который поверит вам и поверит в вашу идею. Он дает вам начальный капитал, с которого вы уже сможете стартовать и начинать развивать свой проект.

При работе с Claude Code я столкнулся с проблемой: по мере роста числа агентов стало сложно синхронизировать их правила между машинами и окружениями. Параллельно возник риск — потерять все наработки (скилы, команды, конфигурации) при смене аккаунта или среды.

Я решил считать ~/.claude/ обычным кодом и хранить его в Git.

Так появился claude-config-template — репозиторий, из которого ~/.claude/ собирается через симлинки. В нём лежат скилы, агенты, команды, хуки и MCP-конфигурации.

Это даёт:
- переносимую конфигурацию между машинами
- единый источник правды для всех агентов
- версионирование и откат через Git

За последний год появилось множество видеороликов и статей по использованию нейросетей для изучения английского языка. Очень часто авторы, среди которых попадаются и «дипломированные» учителя, в очень немногочисленных и расплывчатых промптах‑инструкциях просят ИИ ограничиваться каким‑то уровнем CEFR, от A1 до С2. Как ни странно, никто из этих авторов даже не потрудился изучить, понимают ли ChatGPT, Gemini, Claude, Grok, что входит в конкретный уровень, а что — нет. Как это можно проверить?

Эван Шпигель, сооснователь и CEO Snapchat, редко даёт интервью. Недавно он подробно рассказал, как его компания с миллиардом пользователей пережила 15 лет копирования их новых фичей конкурентами. Snapchat не просто выжили, они изобрели Stories, свайп-навигацию и AR-фильтры, которые клонировали все остальные соцсети. Шпигель объясняет, как ИИ меняет правила игры в продуктовой разработке и почему важно фокусироваться на дистрибуции продукта.

Что делает нас креативными? В течение многих лет нейробиологи указывали на «динамическое сотрудничество» между двумя противоположными системами. И нет, речь не идет о полушариях. Суть в куда более сложных структурах, таких как сеть пассивного режима работы мозга (DMN), которая обрабатывает спонтанные ассоциации, и сеть исполнительного контроля (ECN), которая отвечает за способность сводить мышление в фокус на цели.

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

Более того, зашифрованное сообщение можно сделать похожим на обычный текст или даже скрыть в обычном контенте — видео, звуковых файлах и тексте, который не вызовет подозрений у «цензора». Это область стеганографии

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

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

Всем привет! Хочу рассказать, как мы проектировали кэш поиска отелей и почему за полтора года прошли путь от 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.

Полгода прошло с первой статьи 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 инструмента, и про архитектурные проблемы, которые заставили его собрать.