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

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

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

Это моя первая статья, в ней я попытаюсь описать полученный мною практический опыт работы со Spring Repository под капотом фреймворка. Готовых статей про эту тему я в интернете не нашёл ни на русском, ни на английском, были только несколько репозиториев исходников на github, ну и исходники самого Spring. Поэтому и решил, почему бы не написать, вдруг тема написания своих типов репозиториев для Spring для кого-то ещё актуальна.

Программирование для Infinispan я не буду рассматривать подробно, детали реализации всегда можно посмотреть в исходниках, указанных в конце статьи. Основной упор сделан именно на сопряжение механизма Spring Boot Repository и нового типа репозитория.

Как мыслить и действовать адекватно ситуации, избавиться от инфантилизма и не наступать на одни и те же "грабли"? Эта статья может стать отправной точкой для получения навыков усвоения материала почти любой сложности.

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

Аристотель уникален тем, что его последователи поклонялись не только его лучшим качествам, но также и его недостаткам, чего он никогда не делал в отношении кого-либо, живого или мертвого; за что и был не раз он порицаем – за непоклонение. Огастес де Морган - "наука и здравомыслие" А. Коржибски.

В 1933 году польский математик по имени Альфред Коржибски издал книгу "наука и здравомыслие", а в 1938 году основал институт общей семантики в США. В основе его концепции лежит утверждение о том, что любое человеческое познание ограничивается структурой нервной системы и структурой языка. Это значит, что человек априори не может знать всё обо всём. Коржибски проанализировал структуру языков индоевропейской группы математическими методами и выявил фундаментальные основы логики языка, которым люди пользуются изо дня в день, скрытые в неопределяемых и многопорядковых терминах (принимающие значение только при наличии контекста). Через них показана метафизика лежащая в основе используемого нами языка, его несовершенство, некоторое несоответствие действительности (например, может использоваться одно слово для нескольких сущностей одновременно, что может способствовать неверной оценке и неэффективному поведению (об этом позже)). Для преодоления этого барьера Коржибски ввел в ОС (общая семантика) в обиход не-элементалистский (позже станет понятно что это значит) термин семантической реакции - психологическая реакция индивидуума на слова, язык и другие символы и события в связи с их смыслом, и психологические реакции, которые становятся смыслами и конфигурациями отношений в тот момент, когда индивидуум начинает анализировать их, или кто-то другой делает это за него. Так же разработал простое и наглядное средство для обучения новым, более адекватным семантическим реакциям - структурный дифференциал. Данный подход предлагаю начать с изложения о понятии механизма времясвязывания.

Попробуем снова объять необъятное одним постом? На этот раз рассказ будет про УЗО.

Открываем предзаказ продвинутого курса по Apache Kafka.

Видеокурс о том, как настроить и оптимизировать Apache Kafka — брокер сообщений для микросервисов. Вы последовательно узнаете, откуда взялась технология, как настраивать распределенный отказоустойчивый кластер, как отслеживать метрики, работать с балансировкой.

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

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

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

…

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

…

Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».

Всем неустрашимым на пути от отрицания до убеждения посвящается…

Введение

Во время работы над задачами машинного обучения с онлайн-данными есть необходимость собирать различные сущности в одну для дальнейшего анализа и оценки. Процесс сбора должен быть удобным и быстрым. А также часто должен предусматривать бесшовный переход от процесса разработки к промышленному использованию без дополнительных усилий и рутинной работы. Для решения этой проблемы можно воспользоваться подходом с использованием Feature Store. Этот подход со многими деталями описан вот здесь: Meet Michelangelo: Uber’s Machine Learning Platform. В этой статье описывается интерпретация указанного решения для управления признаками в виде прототипа.

Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о  трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!

Open Source DBMS vs Commercial DBMS

 Для начала приведён график с сайта, db-engines.com, по моим ощущениям, неплохо отслеживающим тренды БД. Именно этот график добавил желания написать статью о текущем положении дел.

В Domain-Driven Design выделяют стратегические и тактические паттерны. Например, первые — это Единый язык, а вторые — Агрегаты. Я много раз слышал от коллег, что со стратегией всё понятно, но когда дело доходит до перехода на тактический уровень (до кода) — всё в тумане. Это приводит к некорректным техническим решениям, которые не могут компенсировать даже правильный настрой и близость к бизнесу. Для успеха проекта крайне важно освоить тактические паттерны, особенно Агрегаты. Всё потому, что Агрегаты инкапсулируют в себя почти всю бизнес-логику, это основа вашего приложения. В этой статье я и расскажу про Агрегаты, как они могут помочь и почему важно их освоить. Но...

Открываю VS Code и начинаю набирать статью с самого начала. Но вот незадача — формат маркдауна не совсем совместим с имеющимся форматом Хабра. Получается выхода нет и придётся возвращаться к встроенному редактору Хабра;

Или не придется?

В голову пришла идея написать утилиту, которая конвертирует разные форматы маркдаунов друг в друга, например, из формата GitHub в формат Habr;

Такую программу я в итоге и разработал. Теперь не надо копировать статьи в редактор Хабра, чтобы посмотреть как она выглядит, можно продолжать писать в любимом VS Code;

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

Это дало бы немало новых возможностей, которыми пользуются программисты: версионирование, бекапы на локальные носители или веб-сервисы, правки от редакторов и пользователей. А еще можно внедрить CD/CI;

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

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

События (Events) предлагают подход в стиле принципа Златовласки, в котором API реального времени (real-time APIs) могут использоваться в качестве основы для приложений, которые являются гибкими, но в то же время высокопроизводительными; слабосвязанными, но эффективными.

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

CREATE TABLE task AS
SELECT
  id
, (random() * 100)::integer person -- всего 100 сотрудников
, least(trunc(-ln(random()) / ln(2)), 10)::integer priority -- каждый следующий приоритет в 2 раза менее вероятен
FROM
  generate_series(1, 1e5) id; -- 100K задач
CREATE INDEX ON task(person, priority);

SELECT
  *
FROM
  generate_series(0, 99) pid
WHERE
  EXISTS(
    SELECT
      NULL
    FROM
      task
    WHERE
      person = pid AND
      priority = 10
  );