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

О простых и продвинутых способах запуска PostgreSQL в Docker: добавляем healthcheck, ставим на мониторинг, настраиваем параметры.

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

3 июля в ТАСС состоялась пресс-конференция, посвященная открытию исходных кодов некоторой части системного ПО для микропроцессоров Эльбрус. Само по себе событие сложно не воспринимать положительно, вне зависимости от цели и полезности того, что было выложено на публику. Но вот выступления некоторых участников пресс-конференции, носили, не побоюсь этого слова, инопланетный характер. И если представитель Минпромторга и исполнительный директор ассоциации разработчиков программных продуктов «Отечественный софт» не выходили за рамки присущего такого рода мероприятиям дежурных заявлений в духе «за всё хорошее, против всего плохого, углубить и расширить», то люди, очень похожие на представителя МЦСТ Константина Трушкина и главу ассоциации АРПЭ Ивана Покровского, безусловно, заинтересовали бы агентов K и J. Но т.к. в эпоху санкций и ограничений люди в чёрном не смогут прилететь в Москву, придётся разоблачать пришельцев самостоятельно.

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

Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.

Это история из цикла «как войти в IT», написанная старпером, ветераном броуновского движения, который помнит динозавров. Поэтому его опыт вхождения в ИТ никому не пригодится, но представляет интерес с точки зрения истории.  

Также поделюсь своим мыслями об интерфейсе инженерного ПО. Участвуя в разработках различного ПО, предназначенного для ускорения разработки сложных систем, периодически приходится выслушивать жалобы от новых пользователей на «кривой и устаревший» интерфейс ПО. Однако инженеры, погруженные в проблемы проектирования реальных железок, вообще не задают нам таких вопросов, либо потому, что уже искривили свои руки о кривой интерфейс, либо им это вообще неважно. Более того, есть два примера, когда реальные высокопрофессиональные инженеры в своей области предъявляли претензии обратного свойства, и первая версия кривая версия GUI была удобнее, а вот улучшения делали какие-то полупокеры. 

К написанию данного текста меня подтолкнула беседа с одним из крутых разрабов из «жирной» конторы, с которым мы пересеклись на яхте в Средиземном море. Узнав, что я тоже из Бауманки, и у меня свой бизнес, он заинтересовался и выспрашивал. Как я смог начать бизнес на софте, почему не пошел в большую контору, типа Yandex, Сбер и прочие. У него тоже знакомство с софтом началось как создание собственной разработки по анализу результатов металлургических испытаний в лаборатории, но закончилось работой прогером по найму. Попивая вино на яхте где-то между Турцией и Грецией в 2023 году, он предположил, что, возможно, если бы он продолжал писать софт для металлургических исследований, то, наверное, сейчас мог плавать на своей яхте, а не арендованной, и не около Турции, а на Карибах (но это не точно). А поскольку фарш невозможно провернуть назад, я решил описать свою историю успеха, так как она забавна и поучительна.

4 июня СДЭК предварительно подтвердил, что сбой в его работе связан с внешним воздействием. 6 июня совет директоров компании соберется, чтобы обсудить данные внутреннего расследования. 

Желаем ИТ-команде СДЭК скорейшего восстановления работы в полном объеме. 

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

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

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

Я немного занервничал, потому что покупал машину с рук, и внезапно задался вопросом, действительно ли всё так, как я думал. Неужели я непреднамеренно купил краденную машину?

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

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

«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

Исходная проблема

class Car(private val engine: Engine) {

    fun start() {
        engine.start()
    }
}

interface Engine {
    fun start()
}

class CarEngine(): Engine {
    override fun start() = ...
}

class TestEngine(): Engine {
    override fun start() = ...
}

val car = Car(CarEngine())

val dummy = Car(TestEngine())

Приветствую, читатели хабра! Вы когда-нибудь задумывались над тем, что скрывается за красотой и динамичностью вашего рабочего стола? Какие компоненты реализовывают анимации и различные графические эффекты: блюр, тень, скругления, прозрачность? В X11 есть одна очень интересная программная единица - композитор. В этой статье мы получим общее понимание того, что это такое, как реализовано и для чего используется. Также, немного поговорим о том, как Xorg хранит информацию для отрисовки, затронем front/back буферы и узнаем, как компоненты рабочего стола обмениваются информацией между собой.

Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.

Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.

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

Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".

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

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

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

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