Программирование *

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

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

В чем реальная уязвимость сигнальных серверов

Многие мессенджеры гордятся стойкостью шифрования - AES-ключи, обфускация трафика и борьба с DPI выглядят солидно. Но остается один критический нюанс: у них всё равно есть сервер.

Даже если его называют «сигнальным» и говорят, что он нужен только для установления связи, это всё равно точка сбора данных. Если данные где-то собираются, за ними рано или поздно придут. Будь то хакерская атака или официальный запрос - метаданные (кто, когда и с кем общался) могут рассказать о вас больше, чем само содержание сообщений.

Ну и наконец в серверную могут просто прийти уполномоченные люди которые потребуют предоставить доступ ко всему.

В предыдущей статье я разобрался с устройством формата файлов ECG кардиограммы цифрового портативного кардиографа «Кардиан-ПМ». Это было сделано с целью получения доступа к информации о кардиограмме с помощью какого-либо другого ПО. Идея пришла использовать формат EDF – популярный формат временных рядов с открытой спецификацией. Как оказалось, этот формат используют на практике также для хранения кардиограмм. Одна из популярных программ, где можно открыть этот формат, – EDFbrowser. Именно с этой программой я и предпочёл работать.

Apidog позиционирует себя как универсальная платформа для работы с API: проектирование, тестирование, mock-сервер, документация. Всё в одном флаконе. Звучит как маркетинг, но интерфейс выглядел приятно, в общем решил сам проверить на практике.

Пройдём полный цикл: от создания проекта до запуска тестов. Со скриншотами и личными впечатлениями.

В конце сентября Филипп Дельгядо, один из архитекторов карточного процессинга Lekton Sigma, выступил на Yandex Neuro Scale. На конференции он рассказал, как они с командой добавляли поддержку YDB к своему решению.

Под катом — интервью с Филиппом, где он поделился с нами ключевыми техническими моментами, которые видит интересными для широкой аудитории Хабра: зачем в принципе добавлять поддержку ещё одной базы данных, сколько разработчиков нужно, чтобы вкрутить лампочку всё запилить, и с какими сложностями они столкнутся при переходе от централизованной PostgreSQL к распределённой YDB.

Избавляемся от FFmpeg: конвертер аудио на чистом Go с FLAC-энкодером

Как убрать зависимость от FFmpeg в аудиоинструментах. Разбираю архитектуру, pure Go библиотеки и написание FLAC-энкодера с нуля. Результат: один бинарник для Linux, Windows, macOS.

Знакомо чувство, когда читаешь документацию, а через десяток страниц уже не помнишь, что именно успел изучить? Или когда возвращаешься к старой статье и не можешь понять – ты уже видел эту ссылку или нет?

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

Но что если заставить браузер самому отмечать ссылки, которые у вас уже сохранены? Чтобы слева от каждой знакомой ссылки возникала метка с названием папки из закладок – как тихий намёк: “Ты это уже сохранял, не потеряй”.

Сегодня мы не просто поговорим об идее – мы сгенерируем через нейросеть готовое расширение для Chrome, которое сделает это за нас. А заодно разберёмся, как такие инструменты создавать, тестировать и даже улучшать – шаг за шагом, от первого промпта до работающего прототипа.

Пристегнитесь, будет интересно!

Не бойтесь std::set, его легко приручить.

Эта небольшая статья для тех, кто имеет некоторое представление об ассоциативных контейнерах стандартной библиотеки C++ (std::map, std::set и т.д.), но пока не использовал «множество» (std::set) в повседневной жизни. Этот контейнер позволяет наиболее изящно организовать коллекцию «самоидентифицируемых» объектов, не трубующих внешнего «ключа» для поиска. Но работа с std::set имеет свои особенности, о них и пойдет речь. Каких-то принциапиальных открытий статья не содержит, я просто решил собрать в одном месте некий минимально необходимый набор приемов для работы со множествами и, таким образом, несколько сэкономить время читателя, впервые решившего использовать «множества» в реальных проектах. Сразу оговорюсь, я сознательно снизил планку стандарта C++ до минимально необходимой, чтобы код, приведенный здесь, мог использоваться максимально широко (так что просьба не удивляться громоздким «устаревшим» конструкциям вроде enable_if).

... Отлично, std::set — это то, что нужно! Зачем мне std::map, если ключ уже находится внутри моего объекта! Такова была моя первая восторженная реакция после знакомства с «множеством» (std::set) стандартной библиотеки шаблонов C++. Это было давно... очень давно.

Архитектура сложных форм. WEB-Frontend.
(VueJS, TypeScript, Compositions API, Pinia)

Архитектура форм, в которых:
- сложная бизнес логика
- множество полей
- валидация (frontend + backend)

GitHub

Onyx — язык программирования, нацеленный на базовую безопасность памяти, приятный синтаксис и опыт использования. Onyx написан на C++ с компиляцией на базе LLVM. На момент написания статьи язык поддерживает:

Есть несколько практик в разработке ПО, которые, с одной стороны, являются практически неотъемлемой частью пейзажа, а с другой - довольно уродливы, если вдуматься, и сильно вредят всем (некоторые вредят AI Code-ассистентам). В этом посте я хочу поныть про автоматические тесты - священную корову разработки ПО последних как минимум 10 лет. И особенно поныть про unit-тесты.

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

Всем доброго времени суток, Хабровчане!

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

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

Возможно, Вы вспомнили об экспериментах на просторах интернета с тем, когда давали список генов существам и также симулировали эволюцию, это были очень полезные исследования, но это не то - они симулировали начальную стадию эволюции. Существа не имели "разума", как такого, это был больше алгоритм на if-ах с настройкой голода, скорости... Подобие первых РНК и ДНК. Но мы - это в первую очередь наш мозг, а это полноценная нейросеть, которая намного более сложная и куда ближе к Deep Learning, чем к обычным алгоритмам из классического IT. Наиболее близкий по идее проект - Bibites. Это реально интересно, однако там не было реализовано цельного механизма памяти и обучения - то, что и является основополагающим фактором развития.

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

В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).

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

Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:

Привет, Хабр!

В конце прошлого года Сбер выложил GigaChat 3 в open source под MIT. Две модели: Ultra Preview на 702 миллиарда параметров и Lightning на 10 миллиардов. Взял Lightning, развернул на бесплатном Colab, погонял тесты. Плюс разобрался в документации.

В статье разберём архитектуру, сравним бенчмарки с Qwen и покажем, как запустить модель без затрат на железо. Спойлер: для задач на русском языке и работы с длинными контекстами Lightning — одна из лучших открытых моделей в своём классе. При этом порог входа минимальный,  base-версия запускается на бесплатном Colab с 4-bit квантизацией, а MIT-лицензия позволяет использовать модель в коммерческих проектах без ограничений. 

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

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

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

Всем привет!

Мы гордимся тем, с каким успехом и рвением выпускаем на русском языке крутую литературу по языку Rust. Мы занялись этим, когда Rust ещё далеко не был мейнкуном мейнстримом - и нашим первым (и сразу же очень успешным) заходом в тему была ныне легендарная книга Тима Макнамары "Rust in Action". Она вышла в издательстве "Manning" в 2021 году, а на русском языке мы выпустили первый тираж "Rust в действии" в ноябре 2022 года. Очередная допечатка закончилась к новому 2026 году, и мы решили разместить здесь переводную статью о книге для привлечения внимания к свежей допечатке (тираж ограничен!)

С тех пор эта книга стала базовым введением в Rust и пропуском в отрасль, но мы на ней, конечно, не остановились. Далее мы выпустили:

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

Короткий ответ — да. Но с важными нюансами, о которых редко пишут в мотивационных статьях.

Привет, Хабр, меня зовут Иван Костин и я старший рекрутер в SENSE. В статье «без глянца» рассказываю какие компании есть на рынке, какие специалисты там востребованы, с какими навыками туда реально заходят и что стоит учитывать, если вы рассматриваете этот рынок для развития карьеры.

Привет, меня зовут Саша, и я разрабатываю на JavaScript. В прошлый раз мы разбирались с методами объектов и идентификатором this, научившись делать объекты по-настоящему живыми и независимыми.

Сегодня двинемся дальше. Покажу, как создавать множество однотипных объектов, не копируя код раз за разом. Мы разберемся с функциями-конструкторами и оператором new — тем самым фундаментом, на котором строятся современные классы в JavaScript. Как всегда, расскажу все доступно и просто, поехали!

Крылатый гений сидит среди инструментов. Циркуль, весы, молоток, рубанок. Всё под рукой. Но он бездействует, подперев голову. Не от лени. Он видит проблему и понимает: имеющиеся инструменты не дают ответа.

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

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

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

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

Как компилятор выбирает лучшую перегрузку, если подходящих вариантов несколько? Интуитивно мы ожидаем, что более «точная» функция должна иметь приоритет над более общей и часто это ожидание мы переносим в правила для компилятора при написании шаблонов и ограничений. Общая идея здесь следующая: перегрузки можно не просто перечислять, а выстраивать в иерархию по степени специфичности, тогда одни функции будут описывать широкий класс типов, другие его подмножество, и, когда тип аргумента известен, компилятор должен выбрать ту функцию, чьи требования наиболее точно соответствуют этому типу. Эта логика заложена прямо в стандарте C++ и называется partial ordering, то есть частичный порядок, потому что не все перегрузки обязательно сравнимы между собой.