Все потоки

MFA для VPN в UserGate — штука полезная: никакого RADIUS, без дополнительных лицензий, всё — из коробки. Одна проблема: фирменный клиент есть только под Linux. При этом еще далеко не все российские компании целиком перешли на отечественные ОС. 

Конечно, можно дождаться, пока вендор выпустит клиент под все платформы. Или можно взять L2TP/IPsec, штатные VPN-клиенты ОС, пару скриптов, немного покопаться в реестре Windows и собрать рабочее решение прямо сейчас. Именно это мы сегодня и сделаем.

Ну что же накидаем на пропеллер импортозамещения...

В связи с тем что прошло много лет, но ситуацию можно описать как «нельзя просто так пройти в Мордор» решил поделиться опытом по установке КиберБэкап 18.5 на Астра Linux special edition 1.8.5
Пишу на коленке, прошу ногами не пинать, заранее понять и простить мой русский...

Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает.

Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров. Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами.

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

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

На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается.

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

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

Вы когда‑нибудь пользовались виртуальной машиной в Linux? Весьма вероятно, что это был QEMU/KVM + SPICE.

Виртуальные машины на spice://localhost:5900 работают достаточно бодро, тогда как подключение по сети может вызвать самые разные эмоции. Причиной тому является специфическая архитектура, которая идёт вразрез с современными диспетчерами среды рабочего стола. И вялая поддержка протокола open‑source сообществом.

Но нас, безбашенных русских инженеров, это нисколько не останавливает! Открываю цикл статей, где мы заглянем внутрь протокола SPICE и графической подсистемы Windows, чтобы провести увлекательный экскурс и разобраться в деталях. После чего создадим пилот нового решения — стриминговый агент для виртуальной машины на ОС Windows.

В первой части мы возьмёмся за сам протокол и увидим, почему SPICE ориентирован на Windows (да, я не шучу). В следующих частях пойдём разбираться в богатствах Windows и в возможностях для нас присосаться подключиться через системное API к потоку фреймов.

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

Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.

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

ДИСКЛЕЙМЕР

Данная статья отражает личный опыт автора и не претендует на статус эталонного или единственно верного решения. Некоторые моменты могут вызывать несогласие или внутреннее сопротивление, это совершенно нормально. Я описываю конкретную ситуацию, сложившуюся в моей команде в рамках одного проекта. Это довольно специфический кейс, который не обязательно окажется применим в других условиях. Однако для нас он оказался полезным, и я не утверждаю, что так должно быть у всех. Моя цель — просто показать один из возможных вариантов развития событий. Возможно, наше решение совсем не идеально и не безупречно, но оно помогло нам улучшить ситуацию. Поэтому, пожалуйста, не торопитесь с критикой, будет здорово, если просто поддержите.

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

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

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

Bitrix24 и amoCRM — две доминирующие CRM в России — отправляют email принципиально разным образом, но имеют общую проблему: ни одна из них не показывает, дошло ли письмо до инбокса получателя. Зелёный статус «Письмо отправлено» в карточке сделки означает только то, что SMTP‑сервер получателя принял письмо. Куда оно легло у клиента — спам, входящие, промоакции — CRM не знает.

В статье:

Low-code и zero-code платформы решают логику и бизнес-процессы, но не решают email deliverability. Между «платформа отправила письмо» и «получатель его увидел» лежит слой, который ни одна из этих платформ не контролирует:

С версии 23.0.0 Manticore может делать так, чтобы запрос xt850 находил xt 850, используя bigram_delimiter вместе с режимами bigram_index , учитывающими цифры.

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

Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 1]

LLM глючит в продакшене? 🤖 Хватит надеяться на «vibe-check»! Узнай, как внедрить инженерный подход к качеству ИИ-агентов. В статье, будет рассмотрена концепция Golden Set, его автоматической генерации для RAG системы, на примере библиотеки RAGAS

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

Два космических аппарата частично воплотили эту идею в жизнь. Аппарат IKAROS японского агентства JAXA и Lightsail-2 от Планетарного общества использовали паруса, но приводились в движение фотонами от Солнца, а не от лазера. Они продемонстрировали, что концепция может работать, по крайней мере частично.

Если честно, последние полгода тема AI для учебы начала немного утомлять. Каждую неделю появляется новая «лучшая нейросеть для диплома», очередной сервис обещает написать курсовую за 5 минут, а TikTok заполнен роликами в стиле:
«Вот промт - вот готовый диплом».

На практике всё оказалось намного интереснее.

Я решил провести нормальный эксперимент и попробовать собрать дипломную работу через два популярных инструмента:

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

Несколько лет назад на Хабре вышла статья от ДОК (Центр мм‑волновых технологий, СПб) про измерение плотности плазмы с помощью СВЧ‑интерферометра в Курчатовском институте «Измеряем плотность плазмы в проекте геликонного двигателя». Там разбиралась базовая архитектура интерферометра и ключевые ограничения: выбор рабочей частоты выше плазменной, гетеродинное преобразование сигнала и требования к фазовой точности, которые напрямую определяют погрешность измерения плотности.
В этом материале будет про следующий прибор — СВЧ‑интерферометр МИ-94-02/5, поставленный в НИУ «МЭИ» (Московский энергетический институт) и работающий на плазменном линейном мультикаспе ПЛМ‑М.

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

А потом оказывается, что сервер обрабатывает один запрос вместо сотни одновременно, мьютекс намертво виснет с одним-единственным вызовом, отмена в select! теряет половину сообщений, и синхронная версия того же кода работает быстрее. Корень всех этих проблем один: .await не означает «жди». Он означает «дай исполнителю право приостановить меня здесь». И пока вы держите в голове первое значение, асинхронный Rust будет вас наказывать.

В статье рассмотрим что компилятор делает с async fn, зачем нужен Pin, как Tokio решает какую задачу опросить следующей, почему std::sync::Mutex в асинхронном коде иногда срабатывает как мина, и почему даже tokio::sync::Mutex может зависнуть.

Когда требования расплываются, команда быстро теряет не только время, но и ощущение смысла: задачи переделываются, приоритеты скачут, заказчик недоступен, а разработчики всё чаще работают «наугад».

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

8–10 октября в Санкт-Петербурге пройдет INFOSTART TECH EVENT 2026 - конференция для тех, кто разрабатывает, внедряет, сопровождает и развивает решения на 1С.

В этом году в программе семь секций: от DevOps и тестирования до HighLoad, интеграций, архитектуры и развития команд. За каждой секцией стоят модераторы — люди, которые сами много лет работают в теме, знают боли участников и умеют собрать вокруг докладов живой разговор.

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

21–22 апреля в Москве прошла выставка Hi-Tech Building 2026. Мы обошли все стенды, пообщались с представителями компаний и собрали подробный разбор: что показали участники, какие решения уже работают на объектах и какие новинки готовят к запуску.

В первой части мы рассказали о пилоте и первых версиях системы Smart Timber для измерения и учета объемов древесины, внедрении продукта у клиента и переходе от технического наполнения к продуктовой составляющей решения. 

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