10 лет назад сотни серверов Яндекса работали на Apache Kafka®, но в этом продукте нам нравилось далеко не всё. Наши задачи требовали единой шины для передачи всех видов данных: от биллинговых до журналов приложений. Сегодня объёмы достигли уже десятков тысяч именованных наборов сообщений.

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

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

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

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

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

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

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

Если вы смогли зайти на систему под непривилегированным пользователем, то вы можете набрать команду, отображающую список запущенных процессов

$ ps -ef

и возможно и увидеть некоторые секреты, которых видеть не должны, например, у одного из процессов ниже открыт пароль basicAuth.password (пароль в тексте изменен).

$ strings /proc/1101/cmdline
/usr/local/bin/vmagent
--remoteWrite.url=http://vm-cluster.local:1234/api/v1/write
--remoteWrite.basicAuth.username=user-rw
--remoteWrite.basicAuth.password=123456
--promscrape.config=/usr/local/etc/vmagent-config.yml

Как же быть? Есть несколько способов этого избежать.

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

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

Вы тоже устали вручную заполнять Dockerfile и docker-compose.yaml под каждый новый проект?

Я всегда задумывался, применяю ли я известные best practices, когда пишу конфиг для Docker, и не занесу ли я случайно какие-нибудь уязвимости, вручную заполняя конфиг-файлы.

Что же, теперь мне больше не придется беспокоиться об этом, благодаря добрым людям из Docker, которые недавно реализовали инструмент для этого - docker init .

Интересно, как экономить время и быстро генерировать конфиги, даже если вы не профи в Docker? Прошу под кат.

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

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

В этой статье мы рассмотрим, как работает match в Rust. Вот основные элементы, которые match и его дополнение, enum, объединяют в единое целое:

• Структурное сопоставление с образцом: анализ вариантов и удобство использования гораздо лучше, чем при использовании switch в C или Java.
• Исчерпывающий анализ: match гарантирует, что ни один вариант не пропущен.
• match поддерживает и императивный, и функциональный стили: вы можете и дальше использовать оператор break, присваивания и прочее, и вам совершенно не нужно переучиваться на стиль, основанный на выражениях;
• match умеет как «заимствовать», так и «перемещать»: Rust поощряет программиста думать о владении и заимствовании данных. Выражение match спроектировано в том числе с возможностью только заимствования части структуры вместо её перемещения. Это нужно для того, чтобы не передать право владения какими-либо данными раньше, чем нужно.

Мы рассмотрим каждый из этих пунктов по отдельности ниже, но для начала нам следует заложить фундамент дальнейшего обсуждения — как match выглядит и работает?

В этой статье я хотел бы поговорить о том, почему вы могли бы предпочесть использование Arc<[T]> вместо Vec<T> в качестве варианта по умолчанию в вашем Rust-коде.

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

Rust имеет два основных типа макросов: декларативные и процедурные. Каждый из этих типов служит различным целям и предоставляет различные возможности манипуляции с кодом.

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

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

В этой статье мы как раз и рассмотрим то, как их пишут на Rust.

Начнем с декларативных!

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

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

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

Rust поддерживает рекурсию, хотя и без оптимизации хвостовых вызовов, что является отступлением от некоторых традиционных функциональных языков, таких как Haskell. Тем не менее, язык предоставляет мощные абстракции и паттерны, такие как владение и заимствование.

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

Кроме того, Rust имеет поддержку функций высшего порядка и замыканий.

TL;DR:
— в Rust намного больше достоинств, чем просто скорость и безопасность
— в Rust по умолчанию CDD (compiler-driven development, разработка через компилирование). Это как TDD, только CDD
— Rust — не сложный язык, особенно если не гнаться за максимальной производительностью

В этой статье я бы хотел рассказать:
— почему взгляд на Rust как на "memory safe C" очень сильно сужает область его возможного применения
— почему я смотрю на Rust как на очень удобный в разработке язык высокого уровня, которому просто случайно повезло оказаться невероятно быстрым
— почему разработка на Rust быстрее, чем многие думают
— почему Rust — это один из лучших языков общего назначения

pub enum Expr<'src> {
  Int(u32)
  Ident(&'src str),
  // ...
}

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