В 2025 году интернет-цензура в России, Китае и Иране достигла беспрецедентного уровня. Традиционные VPN-протоколы вроде OpenVPN и даже WireGuard обнаруживаются и блокируются системами Deep Packet Inspection (DPI) за считанные секунды. На сцену выходит VLESS — легковесный протокол, который становится последним работающим решением для обхода современной цензуры.

Эта статья объясняет, как работает VLESS на техническом уровне, почему он так эффективен в обходе обнаружения, и делится реальным опытом создания VPN-сервиса во враждебной среде России.

Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.

Как разработать источник отрицательного напряжения? Легко, это делается из классического Buck конвертера!

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

В общем-то и целом, мой предыдущий эмулятор ZX Spectrum, написанный на go, работал. Показывал нужное (или очень близко к нужному) и давал чувство приближенности к программистам. Однако у него были очень фундаментальные проблемы, связанные исключительно с языком разработки. Ну по крайней мере я сейчас так думаю.

Другим движущим фактором все-таки была бесплатность БЯМок от cloud.ru (не реклама, да и бесплатности больше нет). Ну где еще можно на халяву пожечь сотни миллионов токенов и получить хоть что-то работающее?

В общем, я принял волевое решение переписать все на С++. Под катом дневник "переписчика", в котором я последовательно описываю все боли и страдания начинающего писателя эмуляторов. Желающим сразу посмотреть на конечный результат можно сходить на https://github.com/kiltum/zxcpp

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

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

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

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

Начну с остренького. В ИТ есть только одна настоящая система виртуальных машин. Это zVM. Всё остальное претендующее на это название на самом деле является системами виртуальных ... систем.

Давайте разбираться с котлетами и мухами.

Mobile System Design — один из ключевых навыков мобильного инженера.

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

Но вокруг этой темы полно разночтений и разных трактовок — отсюда споры, путаница и хаос.

В этой статье я систематизирую Mobile System Design как дисциплину: покажу, какие навыки действительно важны и как они проверяются. Это не личное мнение, а выжимка из опыта инженеров, требований собеседований, литературы и практики команд.

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

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

Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью Outbox Pattern.

Когда проект растёт, а вместе с ним — количество проверок, CI превращается в марафон. Мы в Циан через это прошли: кодовая база растёт, тестов становится всё больше, и каждое изменение начинает тормозить весь пайплайн.

В этой статье расскажу, как мы сократили время выполнения unit-тестов с помощью Impact-анализа — метода, который позволяет запускать только те тесты, которые действительно нужны. Это продолжение моего подхода к оптимизации проверок в Android — в первой статье я показывал, как ускорить статические анализаторы. Теперь — про unit-тесты.

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

Так были ли такие ловушки в гробницах, и если да, то какие именно? Ведь на самом деле — раз древние египтяне вместе с усопшим царем хоронили несметные сокровища (в одной только весьма скромной гробнице Тутанхамона нашли более тонны золота!), то им стоило позаботиться о защите этих сокровищ. В том числе и установив ловушки для тех, кто мог посягнуть на вечный сон царя — на его жизнь после смерти.

Организм человека — это, как часто говорят, сложный механизм, состоящий и множества систем, каждая из которых выполняет определенную функцию. Результат работы некоторых из них мы даже не замечаем либо не задумывается о них, другие же нам очень даже заметны. Боль тоже является важным аспектом жизни, так она сигнализирует о нарушении работы той или иной системе ввиду травмы, заболевания или других факторов. Однако есть виды боли, которые мы бы хотели никогда не испытывать, несмотря на всю важность этого сигнала организма. Одним из таких является боль при камнях в почках. Ученые из Американского химического общества (Вашингтон, США) провели исследование рептилий и того, как они справляют нужду. Как оказалось, змеи и другие рептилии образуют мелкие кристаллические шарики мочевой кислоты. Почему рептилии это делают, и какая связь между туалетными привычками змей и борьбой с камнями в почках человека? Ответы на эти вопросы мы найдем в докладе ученых.

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

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

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

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.

Может ли Rust заменить C? Этот вопрос беспокоил меня много лет. Тем временем я успел написать upb — библиотеку C для работы с Protocol Buffers, и сейчас являюсь её техническим руководителем. Вполне понятно стремление обеспечить безопасность памяти в пределах всего программного стека — поэтому и возникла идея портировать upb на Rust.

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

Но недавно я открыл для себя одну технику, которая заставила меня немного переосмыслить этот вопрос. Я назову её «Rust без паник». Притом, что этот метод определённо не нов, мне нигде не удалось найти подробного разбора, в котором бы рассказывалось, как именно этот метод используется и какие проблемы решает. Правда, интересная дискуссия по этому поводу велась в теме Enforcing no-std and no-panic during build, где есть ссылки на некоторые релевантные треды из почтовой рассылки, посвящённой разработке ядра Linux. Вот другой интересный тред: Negative view on Rust: panicking

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

Привет! Я Андрей Леонтьев, тимлид разработки в вертикали Авито Товары. В этой статье рассказываю, зачем тимлиду осознанно прокачивать visibility — управляемую «видимость» инженеров — и как это напрямую влияет на калибровки, промо и скорость получения ресурсов. Покажу, куда «светить фонариком», как выровнять систему ценностей и подбирать инструменты под мотиваторы. Материал пригодится тимлидам, техническим лидерам, PM/PO и инженерам.

Каждый, кто прошел через курс линейной алгебры или физики в универе, помнит этот странный дуализм. Нас учили, что у векторов есть целых ДВА вида произведения. Первое, скалярное, съедает два вектора и выдает число. Геометрически — это что-то про проекции и углы. Второе, векторное, тоже съедает два вектора и… внезапно выплевывает третий вектор, перпендикулярный первым двум. Причем работает этот фокус только в 3D и 7D.

Всегда казалось, что это какой-то математический «костыль».

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

Что, если я скажу вам, что это действительно «костыли»? Что существует единое, универсальное и элегантное геометрическое произведение, которое включает в себя оба этих случая (и многое другое), и которое основано на одной-единственной, кристально ясной идее. Идее, которая меняет взгляд на саму суть математики.

Эта статья — приглашение в мир Геометрической Алгебры. Мы собираемся переизобрести умножение.

В новом выпуске 7 способов найти логи и поймать баг на iOS, разбираем «Telega» по винтикам и делаем эффект глюка, очки на Android XR, что ждёт Kotlin Multiplatform разработчика на собесе, реверс обфускации Amazon Kindle Web, удаление Tea и TeaOnHer из App Store и многое другое. Заходите!

Все мы любим, когда интернет работает (и не виснет 🙂) — сайты открываются, видео грузятся, письма доходят. Но мало кто задумывается, как именно браузер узнаёт, куда вас отправить, когда вы вводите знакомое «habr.com». 

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

Всем привет! Меня зовут Ян, я старший специалист по пентестам в компании Xilant. Сегодня предлагаю вместе разобраться с довольно сложным CTF-заданием, посвящённому слепой LDAP-инъекции (Blind LDAP Injection).

Оно будет особенно интересным, ведь его смогли решить всего около 50 человек из примерно 500. Мне удалось получить флаг одним из первых десяти участников — за 2 часа, причём без глубокого опыта работы с LDAP протоколами.

Решение и код лежат также на моём Github (ни один чат-бот не пострадал).