Все потоки

Если вы тимлид или техдир, ваше утро редко начинается с неспешного наслаждения чашкой кофе. Скорее, оно начинается с открытия пяти разных вкладок.
Картина знакомая и удручающая: бэклог продукта живёт в одной системе (которую либо давно не обновляли, либо вообще собрали из того, что было), код лежит в GitLab, саппорт отбивается от пользователей и заводит баги в каком-то отдельном ServiceDesk, а сборка релизов, планирование ресурсов и метрики трекаются… да-да, в «любимом» Excel или Google Таблицах.

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

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

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

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

OpenClaw очень просто для быстрого старта. После openclaw onboard у тебя работает Gateway и один агент отвечает в Telegram. Но дальше начинается самое интересное — и самое неочевидное: как устроен openclaw.json, что из workspace-файлов реально попадает в контекст, как включить heartbeat так, чтобы он не превратился в генератор мусора и расхода токенов, и как правильно разнести нескольких агентов по чатам и топикам.

Документация OpenClaw покрывает это фрагментарно, а большинство гайдов заканчиваются на «поставил — работает». Этим туториалом постараемся закрыть следующие шаги: разбираем конфиг секция за секцией, показываем рабочие примеры для Telegram, bindings, session policy и multi-agent — всё, что нужно, чтобы перейти от одного бота в личке к нормальной продакшн-конфигурации.

Стремительное развитие ИИ в последние годы привело к невиданному росту популярности Markdown. Почти все современные LLM — от ChatGPT до Claude — по умолчанию выдают ответы в этом формате. Мы привыкли оформлять в нем заметки в Obsidian, писать промпты, вести документацию в GitHub и общаться в рабочих мессенджерах. Markdown стал «лингва-франка» современного интернета.

Но есть одна проблема. Использовать Markdown с русским языком — это боль.

Вам нужно поставить заголовок? Alt+Shift -> # -> Alt+Shift обратно. Нужно выделить код? Снова чечётка по клавишам переключения раскладки. Стандартная русская раскладка в Windows будто застряла в прошлом веке. Клавиша Shift+3 выдает нам символ №, который в 2024 году нужен крайне редко, в то время как жизненно необходимые решетки, собаки и скобки заставляют нас постоянно прыгать между языками.

Я решил эту проблему для Windows с помощью небольшого скрипта на AutoHotkey (v2).

Картинка: Морозов Сергей

Думали ли вы когда-нибудь о том, что пускать пузыри носом может быть вполне взрослым делом? 

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

И такой вариант существует, а в роли перекачивающей силы может выступать одна из довольно удивительных вещей — обычный воздушный пузырь! 

Итак, некоторые, наверное, уже догадались, что сегодня мы поговорим о типе насоса под названием airlift (или эрлифт или «газлифт»).

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

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

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

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

Тут все стоявшие единой кучкой стали ныть что ей же три года, как они могут брать её в работу, да и документов на неё уже нет.

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

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

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

854 миллиона скачиваний за год. Пять дней работы Claude Code.

Вот и всё, что понадобилось, чтобы содрать двадцать лет копилефт-защиты с chardet — библиотеки определения кодировок для Python, которая сидит практически в каждой Python-среде на планете.

Прежде чем нырнём в историю, давайте проясним два типа лицензий, вокруг которых всё вертится. LGPL говорит: «Можешь использовать этот код, но если ты его изменил — делись изменениями на тех же условиях». MIT говорит: «Делай что хочешь». Первая защищает сообщество. Вторая позволяет корпорациям брать, ничего не отдавая взамен.

2 марта 2026 года Дэн Бланшар выпустил chardet 7.0.0. Назвал это «полной переписью с нуля под лицензией MIT». Лицензия LGPL, которая защищала библиотеку с 2006 года, — исчезла. Вместо неё — MIT. Инструмент, который выполнил переписку: Claude Code от Anthropic, модель Opus 4.6.

Через два дня вернулся Марк Пилгрим. Человек, который создал chardet в 2006-м. Человек, который в 2011 году стёр все следы своего присутствия в интернете. В сети это называют его «инфосуицидом». Пятнадцать лет тишины. Его первый публичный пост за более чем десятилетие — Issue #327 на GitHub: «Нет права перелицензировать этот проект».

1 468 человек поставили ему плюс. Issue теперь заблокирован.

Если вы пишете на Python, вы почти наверняка зависите от chardet. И судьба этой юридической битвы может определить, значит ли копилефт хоть что-нибудь в эпоху ИИ.

В прошлом месяце Intel обновили линейку CPU для рабочих станций и представили семейство Xeon 600 на архитектуре Granite Rapids — очередная попытку конкурировать с AMD. А еще «синие» продемонстрировали серверные процессоры Intel Xeon 6+ Clearwater Forest. Но и это не самое интересное...

Привет, Хабр! На связи Сергей Ковалёв, менеджер выделенных серверов в Selectel. В новом дайджесте собрал самые интересные новости за февраль — от процессоров и GPU до дисков и сетевого оборудования. Подробности под катом!

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

И здесь приходит на помощь RxJS

RxJS часто пугает своей сложностью. Прикол в том, что вам не нужно знать все 100+ операторов. Достаточно освоить базовую пятёрку, которая покроет 80% проблем.

Когда сервер с конфигом заблокировали — клиент отвалился. Разбираем способ доставки который сломать сложнее чем сам интернет

У любого прокси-сервиса есть слабое место которое не связано с протоколом. Сервер переехал, IP сменился, конфиг устарел — и пользователь сидит без связи пока не получит обновление вручную. Чем больше пользователей, тем острее проблема.

Стандартное решение — раздавать конфиги через HTTPS. Удобно, пока URL не попал в реестр. После этого тысяча человек одновременно пишет в поддержку.

DNS TXT-записи решают эту проблему не через обход блокировок, а через выбор канала который блокировать политически сложно.

Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.

Приветствую всех!

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

Самое время узнать, как он устроен, и попробовать его запустить. Именно этим мы сейчас и займёмся...

Всем привет! Меня зовут Алексей Ковалов, я руководитель отдела модульной верификации в YADRO в департаменте разработки процессорных архитектур. В прошлой статье я рассказывал, как расти верификатору. А сегодня хочу обсудить, как люди вообще приходят в эту профессию, ведь в вузах до недавнего времени верификаторов не готовили. 

Дисклеймер: в статье нет технических деталей, так что матерые RTL-разработчики могут заскучать. А еще в ней нет лайфхаков, которые помогут за секунду определиться с карьерой и за три дня стать Илоном Маском. Зато есть реальный жизненный опыт.

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

Какая ИИ-модель лучше всего пишет код в реальных условиях? Чтобы ответить на этот вопрос, я взял 8 популярных моделей — от дорогих флагманов OpenAI и Anthropic до доступных открытых альтернатив — и поручил им одну и ту же задачу в действующем open-source проекте.

За подробным разбором результатов добро пожаловать под кат.

Привет, Хабр! Меня зовут Андрей Аврамчук, я редактор в команде техпиара в MWS. В разных профессиональных чатах, в разговорах коллег и публикациях часто вижу, что тема коммуникаций в онлайне воспринимается по инерции, как будто за десять последних лет ничего не произошло и мир остался прежним. При этом эти изменения влияют во всех направлениях, завязанных на онлайн-коммуникацию: рекрутинг, маркетинг, создание контента. В каждой из них идут свои процессы, но они очень похожи и сталкиваются с одними и теме же проблемами. 

О том, как они проявляются, покажу на конкретном примере — сфере найма и размещения вакансий: она сейчас одна из самых горячих. Обычно поиск проблем тут заканчивается объявлением крайних, будь то рекрутеры, автоматические фильтры на площадках, недобросовестные соискатели или ретроградный Меркурий, вляющий на них всех.  

Я об этом рассказывал на прошедшей конференции КаргоКульт 2025 — кроме моего, там были и другие доклады, затрагивающие эту тему.  В этом же посте расскажу о сложившейся ситуации на рынке вакансий и покажу два тренда: первый — как мы движемся в сторону отказа от онлайна; второй — как это может помочь строить эффективную HR-коммуникацию. Хороший и взвешенный обзор на эту тему можно найти тут: Рынок найма в IT — 2025: мифы, факты и взросление индустрии. Разбор от HRD МойОфис. Я же посмотрю на это все со стороны интернет-коммуникаций — среды, в которой сейчас идет большая часть взаимодействия. Сначала разберу это на пяти гипотезах: о состоянии рынка, реакции бизнеса и аудитории, а затем покажу, в какую картину это складывается. 

Представьте: вы закрыли периметр межсетевыми экранами, поставили антивирусы на все хосты, но вдруг понимаете, что любой человек с ноутбуком может прийти в офис, воткнуться в розетку и оказаться в вашей внутренней сети. Или сотрудник возвращается из командировки с просроченными обновлениями Windows, становясь идеальным вектором для атаки. Контроль доступа (NAC) закрывает именно эти бреши в защите сети. 

Тема NAC сейчас сильно актуализировалась. Его ставят уже не только для защиты Wi-Fi (как наиболее уязвимой среды), но и в проводных сетях. А значит пришло время обновить наш первый обзор российских NAC-решений. 

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

Когда я впервые подключился по UART к обычному бытовому устройству, я ожидал увидеть примитивную прошивку на микроконтроллере. Но вместо этого на экране терминала внезапно появились строки загрузки Linux. С тех пор у меня появилась странная привычка: если какое-то устройство попадает ко мне в руки, я почти автоматически ищу на плате UART, JTAG или хотя бы тестовые пины.

И знаете что? Linux внутри оказывается намного чаще, чем можно ожидать.

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

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

Человеку нужен горизонт. На Земле он есть всегда — даже в городе, даже в лесу ты знаешь, что где-то там, за домами или деревьями, небо встречается с землей. На Луне горизонта нет. Ты всегда стоишь в центре идеально круглой чаши, и звезды висят над тобой, никогда не мигая.

Я прожил здесь тридцать пять лет и не привык.

Меня зовут Михаил Ветров. Мне шестьдесят семь. Когда-то я был инженером систем жизнеобеспечения, молодым специалистом, выигравшим лотерею — желающих лететь на «Архимед-1» оказалось больше, чем мест. Теперь я старик, который чинит всё, что ломается, и рассказывает детям сказки о синем небе.

Детям... Впрочем, обо всем по порядку.

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

Знакомьтесь, CyberChef - веб-приложение, разработанное в Government Communications Headquarters. Его нередко называют «кибер-швейцарским ножом» для работы с данными. В одном интерфейсе собрано несколько сотен операций: кодирование и декодирование строк, криптографические алгоритмы, работа с бинарными форматами, сетевые структуры, временные метки, анализ сертификатов и множество других преобразований. При этом инструмент не требует установки и работает прямо в браузере, хотя при необходимости его можно скачать и использовать локально.