Model Context Protocol (MCP) - это просто API, разработанный для LLM. Конечно, LLM могут использовать традиционные API, но это как просить повара готовить в кладовке.

Алгоритмы для работы с большими данными

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

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

Помните то блаженное время, когда для доступа к любому ресурсу хватало простого WireGuard до сервера в Германии? Я тоже помню. Но эта эпоха закончилась. Недавно я заметил, что мой верный VPN стал лагать, рвать соединение и вести себя так, будто его кто‑то целенаправленно «душит». Это был тот самый момент, когда я понял: игра изменилась. Системы глубокого анализа трафика (DPI) стали умнее, и мой трафик для них был как на ладони.

Это стало моим личным вызовом. Я отправился в путешествие по миру современных средств обхода блокировок, наступил на множество граблей (чего только стоит осознание, что «двойное шифрование» — это миф!), но в итоге нашел свое сокровище — рабочую и относительно устойчивую схему на базе VLESS+Reality и Multi‑hop.

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

Приветствую всех, кто заглянул на огонек! Меня зовут Роман, и я занимаюсь исследованием безопасности Linux (и всякого другого, связанного с ним) в экспертном центре безопасности в Positive Technologies.

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

При проектировании систем, обязательным этапом является расчет нагрузки и стоимости на вашу IT-Систему. Давайте разберемся что это за этап и почему он так важен. А также вместе посчитаем основные показатели нагрузки и договоримся о стоимости решения.

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

Что это значит? Это значит, что у меня есть прогнозируемый план развития проектов.

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

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

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

Всем привет! Меня зовут Алина, и ранее я вам рассказывала про то, как можно спроектировать Feature Platform. Сегодня я хочу рассказать про очень важный компонент ML-платформы — развёртывание ML-моделей, и затрону связанные с ним компоненты.

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

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

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

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

Сегодня расскажу про то что нашел для и себя и как это похостить.

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

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

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

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

Если вы архитектор, которому надоело рисовать схемы ради схем — этот список тоже для вас.

А если вы просто строите что-то серьёзное — сохранить, перечитать, внедрить. Это основа.

C++ уже десятки лет является краеугольным камнем, на котором строятся программы, ориентированные на высокую производительность. Он лежит в основе самых разных проектов, относящихся практически ко всем аспектам человеческой деятельности — от встроенных систем до платформ высокочастотной торговли. Его возможности по совмещению низкоуровневых средств управления вычислительными ресурсами с высокоуровневыми абстракциями превращают его в уникальный инструмент, подходящий для создания программ, при выполнении которых значение имеет каждая микросекунда. По мере того, как язык развивается, новые стандарты, вроде C++23 и ожидаемого C++26, вводят в него функционал, который улучшает и его возможности по созданию высокопроизводительных программ, и продуктивность пользующихся им программистов. Особенно это касается разработки высокопроизводительных служб — систем, которым требуются низкие задержки и высокие значения пропускной способности, которые нуждаются в эффективном использовании ресурсов. Среди них — аналитические системы, работающие в режиме реального времени, игровые серверы и распределённые системы управления базами данных.

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

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"

Каждому C++-разработчику приходится решать задачи асинхронности — от сетевых запросов до фоновых вычислений. В этой статье вы увидите, как P2300-модель Senders/Receivers в C++26 расширяет возможности std::async/std::future и позволяет строить ясные, декларативные конвейеры (then, when_all, upon_error и др.).

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.