Пикодата, in-memory data-grid.

Немного выпал и не писал, много проектов. Добрался, наконец, до видео доклада Кости Осипова о Пикодате. Кстати, где был доклад - тоже интересно само по себе. Это была первая встреча нового комьюнити разработчиков СУБД - Database Internals Meetup. Свежая история, дело было в офисе Яндекса, драйвером, как я понимаю, выступили ребята из YDB.

Доклад ретроспективный, несмотря на название. Пикодата - осносительно новый продукт поверх Тарантула. Грубо, для каждой отдельной ноды взяли Тарантул, но поверх натянули “кластерную” обёртку - и всё вместе получилось Пикодата. Про то, как выбирали подходы к работе со схемами данных, как обжигались о Lua, как в новом продукте стали использовать Rust, и какой подход к конфигурации и управлению кластером. Немного про логику “втянуть данные поближе к приложению”, “уволить С++ программистов”, бесперспективность GC-рантаймов для high performance задач.

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

https://www.youtube.com/watch?v=_UNok-uXql4

Как расти бекендеру и как подготовиться к интервью?

В следующий вторник, 9-го апреля (18:30 msk) у devhands.io открытый вебинар для бекендеров. На этот раз на животрепещущие карьерные темы: Как расти бекендеру и как подготовиться к интервью?

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

Ниже ссылка на календарь, добавляйте себе. В описании к календарю и в комментариях - ссылки на комнату в Zoom и трансляция Youtube.

Что обсудим? Сначала посмотрим на карту развития бекэнд-программиста, от мидла до эксперта. Её можно использовать как для составления плана на обучение, так и для быстрой проверки “зон роста” (в том числе тех зон, которые нужно подтянуть как для перехода на новый “уровень”, так и для прохождения интервью - а часто это разные зоны).

Затем обратимся к тем, кто собирется менять работу или находится уже в процессе поиска. Поговорим о следующем:
* Как вообще понять, менять работу или нет?
* Обсудим типовые ошибки, которые совершают программисты на разных этапах
- составление резюме: формат, фокус и почему (и когда) это до сих пор важно, нужны ли референсы и сопроводительные письма
- от общения с рекрутером до общения с будущим руководителем
- прохождение coding sessions
- прохождение architecture (system design) sessions
* Как можно было бы классифицировать компании, чтобы понять компания “нормальная” или нет
* Какие вопросы задать себе, чтобы понять, что вы хотите сами, и в зависимости от этого сформировать список вопросов для компании, чтобы понять, ваша это компания или нет
* Ну и если успеем, поучаствуем в спец-олимпиаде: какой трек выбрать, IC или EM?

Приходите сами и приводите друзей. Регистрация не нужна.

Если вам интересны какие-то ещё темы - напишите, пожалуйста, в комментариях.

Добавляйте себе в календари:

https://calendar.app.google/RpQVZqfgJyee7Rme6

О сроках

Есть 10 (два) типа людей.

Одни считают, что если для задачи нарушается 3W1H-принцип (известно what, how, who и самое главное when) - то задача почти гарантировано продолбается.

Вторые считают, что мир настолько изменчив, что попытка ответить на эти вопросы, поставить сроки, зафиксировать обязательства - это стресс. В стрессе невыносимо! Катастрофически падает работоспособность. Стресс приводит к несчастьям. И вообще, вот Гитлер так же сроки ставил и прессовал. Не продолбается! А если продолбается, ну чотакова? И вообще нужна внутренняя мотивация, а не внешняя. Поэтому спрашиваю вас: где моя внутренняя мотивация и что вы для неё делаете?

Работник умственного труда, помни: ультра-либерализм приводит не к высшей свободе, а к распиздяйству и деградации.

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

(Если что, последние слова пишу лёжа - ну, реально длинный текст, не в ресурсе уже).

Владимир Перепелица (ex-VK, Tarantool) + DevHands.io

Супер-важная новость для нашего образовательного проекта DevHands.io.

Мы стартуем продвинутый образовательный трэк по очередям. Это направление возглавит эксперт по большим проектам, очередям и Tarantool, регулярный спикер и член ПК конференций Highload, создатель S3 в VK Cloud, Mons Anderson aka Владимир Перепелица (ex-VK, Tarantool).

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

В рамках этого архитектурного курса пройдет одна лекция и одна “встреча с экспертом” (вопросы-ответы, разборы кейсов участников трека). Тема: «Асинхронное взаимодействие с помощью очередей: подходы, свойства и гарантии». Чуть позже мы сделаем открытый митап с Владимиром, подробнее поговорим про подходы и тренды в очередях. Следите за анонсами.

Асинхронное взаимодействие и очереди - невероятно широкая тема, но абсолютно обязательная к изучению всем, кто интересуется архитектурой. Даже если сузить её до сравнения самых популярных продуктов - Kafka, Rabbit, NATS, Redis - то всё равно получится очень интересно, поскольку все решения чем-то отличаются, и разработчику важно понимать архитектурные особенности, сильные и слабые стороны компонент, на базе которых строится архитектура. Моя мечта, конечно, помимо просто хорошего экспертного образовательного трека сделать уникальный research cloud, где все популярные решения доступны из NoOps-коробки, но как скоро нам удастся к этому приблизиться - вопрос открытый.

Запись на апрельский поток “Системный дизайн” на странице курса. Приходите, будет супер-интересно.

Карьера в хайлоад-проекте: к чему готовиться - I?

Что такое “хайлоад-проект” для инженера, например, бекендера? Каждый раз, отвечая на подобный вопрос, вспоминаю расхожую фразу о том, что хайлоада не существует. Что за бред, как так? - спросите вы. Поясняю.

Во-первых, простите за занудство, в англоязычном мире просто не говорят “highload“, наиболее близкий термин – “large scale”. Термин “хайлоад” - русское изобретение, полагаю, это придумали Олег Бунин и Павел Рогожин, когда делали первую конференцию по разработке высоко-нагруженных систем, если не ошибаюсь, в 2007-м году. Сделали крутое дело, название отличное, прижилось, но для английского уха это звучит как нечто, простите, на наркоманском слэнге: high и loaded - это всё натурально “under the influence”, “под воздействием веществ”.

Во-вторых, хайлоад начинался с треда “как писать сервера” в RU.UNIX.PROG и веб-страницы “C10K (10000 connections) Problem” от Dan Kegel, посвященной проблеме обработки десяти тысяч одновременных соединений одним сервером. Поэтому один из моих приятелей любит говорить, что хайлоад начинается с 10K RPS (десять тысяч запросов в секунду на ноду). Но сейчас даже в очень многих крупных проектах одна нода держит тысячи или вовсе сотни RPS, и виной всему сложная, нещадно сжирающая процессор бизнес-логика, крайне редко позволяющая отдать больше сотни запросов в секунду с одного ядра. Масла в огонь подливает повальное использование скриптовых языков без JIT, но это отдельный разговор (мы их любим не только за это). А, ну и Постгрес до сих пор под каждое активное соединение использует процесс - полный хайлоад, конечно.

Наконец, в-третьих, нет какого-то отдельного “хайлоад-знания”: есть область знаний на стыке прикладного и системного программирования, системного администрирования, и всяких подобных тем - производительности, масштабирования, надежности. Все эти темы объединяет одно: это всё погружение под капот, в направлении, вообще говоря противоположном тому, куда обычно начинает развиваться программист, приобретая опыт (паттерны, фреймворки и тд).

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

(продолжение следует)

Карьера в хайлоад-проекте: к чему готовиться - II?

Это продолжение прошлого поста, вот - первая часть.

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

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

Есть ли какая-то специфика хайлоад-проектов для небекендеров? Конечно, в первую очередь для фронтендеров: ваш фронт будет доставляться и работать на огромном количестве устройств, он должен доставляться быстро, не тормозить на клиентской машине (особенно при старте), и быть оптимально спроектирован, чтобы не создавать “лишних” нагрузок на бэкенд. Это же касается и мобильных разработчиков, за тем исключением, что они не занимаются оптимизацией загрузки: весь “контент” уже упакован в приложение.

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

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

Мир не очень приветствует погружение под капот - это ж сложно. Современные облака хотят от скрыть от нас детали, предоставляя planet-scale решения с автоматическим масштабированием. В больших проектах развит внутренний тулинг – так что масса вопросов скрыта даже для опытных инженеров, которе выросли в таком проекте. Это не хорошо, и не плохо - это данность. Так что если хотите копать глубоко – просто попасть в крутой проект может оказаться недостаточно, нужно копать самостоятельно, читать чужой код, ресерчить, исследовать, применять новые подходы, пробовать компоненты. А эта область уже чисто исследовательская.

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

Кстати, о тулинге. Самая быстрая и легкая в мире “стрелялка”, wrk2, с 2016-го года особенно не поддерживается, поэтому отличные community-патчи, в том числе критичные, висят годами. Один из участников буткемпа – Даниил Дук - сделал титанический ресерч, в числе прочего найдя критичный патч, которые убирает проблему 100% нагрузки CPU при определенных условиях. Короче, я решил это исправить, и сделал вот такой реп: https://github.com/devhands-io/wrkx, “wrk2 с комьюнити-патчами”. Сделаем 14-го мая вечером митап про нагрузочное тестирование и про wrk и про автоматизацию - stay tuned, ещё напишу про это.

Нагрузочное тестирование с wrk2/wrkx. Онлайн-митап DevHands.io 14 мая 18:30 MSK

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

С тех пор мы сильно прокачались в этом инструменте, причем некоторые участники буткемпа, кажется, прокачались сильнее меня 🙂 Например, Даниил Дук придумал и разработал софт для автоматизации стрельб, а так же обнаружил ряд очень неприятных багов в wrk2 и нашел патчи, которые эти баги исправляют.

Основной репозиторий wrk2, к сожалению, активно не обновляется с 2016 года, поэтому все эти патчи там "висят” годами. Так появился github-репозиторий wrkx (https://github.com/devhands-io/wrkx), “wrk2 c community-патчами”, а ещё github-репозиторий Данила wrk-helper (https://github.com/neduck/wrk-helper), для автоматизации стрельб и визуализации результатов.

Во вторник 14 мая 18:30 MSK мы проведем открытый митап “Нагрузочное тестирование с wrk2/wrkx”, на котором расскажем:
* Что такое wrk2, как его использовать, и как автоматизировать нагрузочное тестировение с wrk
* Что такое Coordinated Omission, и как с ним бороться
* Что вошло в wrkx, как при запуске “прибить” к ядрам треды стрелялки, а также многое другое.

Как попасть на митап? Ща расскажу, но сначала поделюсь болью. Когда я проводит митап в прошлый раз, я опубликовал ссылку на событие Google Calendar и был очень раз такому простому способу регистрации без заполнения форм, СМС и всего прочего. Однако, как выяснилось, к этому эвенту тупо невозможно было присоединиться, посколько число участников почти мгновенно перевалило за 100, а у Гугла есть вот такое идиотское ограничение.

Поэтому теперь делаю всё по-модному. Встречайте бота: https://t.me/devhands_meetup_bot. Вы его добавляете в один клик, и он работает как напоминалка. Он ненавязчивый, напомнит о митапе утром и за час до мероприятия, выдаст все нужные ссылки, и даже (может быть) раздаст подарки. Enjoy.

Режешь правду на митапах? Дарю слайд-оберег

Развел тут некоторую активность – делюсь результатами. Вот ловите запись нашего митапа DevHands.io Open Sessions: “Нагрузочное тестирование с wrk2/wrkx”:

https://www.youtube.com/watch?v=nZMq3LzVWiA

Там два выступления: первое моё про wrk2 в целом, про Coordinated Omission и wrkx. Второе - Даниила, автора wrk-helper, про автоматизацию и построение отчетов. Можно смело ставить 1.5 скорость и посмотреть всё за час. А если совсем мало времени - посмотрите только про Coordinated Omission (картинка для привлечения внимания). Это очень важный для хайлоада и нагрузочного тестирования эффект, в русско-язычном сегменте про это мало информации, wrk это умеет “компенсировать”, и кажется больше никто.

Скоро также опубликую: доклад про системный дизайн на конференции Systems Design, доклады про разные “рисковые” аспекты микросервисной архитектуры на МТС True Tech и закрытом митапе Тинькофф.

Hаve a lot of fun!

Удержать нельзя отпустить

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

Почему считается, что удерживать не нужно? Почти все рассуждения примерно такие: дескать, человек, получивший оффер, уже мысленно уволился, “изменил”, “укусил”, поэтому остается только пристрелить. Даже если удержишь - все равно ненадолго, человек все равно уйдет.

Ребят, да, есть такой шанс, но вообще это ерунда. Любой мало-мальски талантливый сотрудник, особенно в начале карьеры, постоянно в сомнениях и соблазнах, и нет вообще ничего страшного, если вдруг на него “накатило”, и он собрался увольняться. Есть миллион ситуаций, в которых люди не нашли в себе сил поговорить о карьере до момента, когда на руках уже оффер. Либо не было создано для этого условий. Короче, вины “компании” в этой ситуации может быть не меньше, чем сотрудника. Это я не говорю о таких случаях, когда принести оффер в другую контору - это вообще единственный вариант заявить о своих целях и получить повышение (таких компаний становится меньше, но их до сир пор полно, уверен, что каждый из вас уж одну-две такие компании точно вспомнит).

Думаю, что большинство причин, по которым люди думают уволиться - эмоциональные, от усталости, от ограниченного видения плюсов и перспектив, от отсутсвия диалога - короче, эти причины сегодня есть, завтра нет. Надо это учитывать.

Лично знаю очень много примеров, когда бизнес рос очень быстро, у всех была куча дел, и люди просто в какой-то момент банально “задалбывались”, были готовы уйти в никуда из-за усталости, переработок, несовершенства процессов. Их удерживали и старались что-то изменить, и если получалось, то они ещё долго-долго успешно работали. Если бы их всех марали “предателями” - ещё неизвестно, насколько успешно бы развивалась компания. В крутых успешных компаниях люди работают долго. И почти каждый такой “долгожитель” - скорее всего когда-то хотел уволиться, но был удержан.

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

Удержать нельзя отпустить (часть II)

Прошлый пост про вредность правила “уходит - не удерживай”, кажется, вызвал интерес. Продолжим тему, только теперь со стороны сотрудника, но менеджерам тоже будет интересно. Как понять, пора уходить или нет?

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

Причин может быть миллион. Ничего не успеваю. Меня не ценят. Мне мало платят. Мой руководитель – козёл (а ещё он - собственник). Я занимаюсь каким-то тупым говном и не расту. Мы все занимаемся каким-то тупым говном и не растем (а вам всем ваще пофигу). “Фашисткие суки, я гибну за вашу мечту”. Где мой ассистент по движению прямоугольничков в календаре? Почему в обед прекратили подавать фуа-гра? Очень много вопросов.

По сути у вас вот такая развилка принятия решения:
* если причина не фундаментальна, или вы слишком много ей придаете значение: можно “перетерпеть” либо изменить свое отношение к причине
* если причина фундаментальная - всегда сначала подумать/обсудить. Это вы не справляетесь, потому что взвалили на себя или не умеете делегировать, или обьективно бардак вокруг? Если есть понятное решение - остаёмся, делаем план, проверка в конце контрольного периода “поменялось или нет”. Если причина - “блокер”, или её никак не получается решить - тут уж без вариантов.

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

Больше чем в 50% случаев ответ на один из этих вопросов “да” - и тогда задача сильно упрощается. А если нет, она, конечно, посложнее, но всё равно может быть решаемой без увольнения. Тогда надо запустить другой алгоритм, но я про это потом напишу, а пока про первые два пункта.

Первое: иногда это вариант перетерпеть, сжать булки. В моем поколении – дефолтное поведение. И люди загоняют себя. В долгую - не надо так. Кто помоложе впадают в другую крайность: даже намек на “сжать булки” – да ты Гитлер штоле. Не бойтесь сжать булки! Ненадолго. И запланировать какую-то разрядку, из самых простых дешевых способов как ни странно спорт: пройти/пробежать 5+ км или выложиться в спортзале.

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

Остальные пункты и дальнейший алгоритм - в следующих постах. Лайк, если нравится про такое.

Трудовые будни разработки: как выстроить эффективный и безопасный процесс 
Онлайн-дискуссия, 4 июня в 17:00 MSK.

На следующей неделе 4 июня участвую в онлайн-дискуссии серии «Откровенно об ИТ-инфраструктуре», которую ведет Сергей Зинкевич (КРОК). Тема выпуска – насущные задачи разработки новых продуктов. 
Подробности и регистрация по ссылке: https://cloud.croc.ru/blog/events/04062024/?utm_source=tg-rybakalexey&utm_medium=messenger

Вместе с Димой Симоновым (https://t.me/ctorecords) поищем ответы на такие вопросы: 
• Как правильно выстроить CI/CD, чтобы ускорить тестирование гипотез
• Как измерить эффективность выпуска релизов, какие окружения нужны для качественной и быстрой доставки приложений
• Как облегчить бремя «налога на безопасность» для команды разработки 
• Почему разработчикам важно знать о способах защиты от кибератак и в чем преимущества облачных инструментов anti-DDoS, WAF и др.  

Присоединяйтесь, будет интересно.

Риски микросервисной архитектуры

Я бы очень хотел прочитать книгу “мы выбрали микросервисы: что может пойти не так?” - но её нет. По опыту компаний, где я работал, компаний моих клиентов и знакомых, микро-сервисный архитектурный стиль имеет ряд рисков, которые могут материализоваться, а могут и нет: зависит от размера компании, продукта и тд.

Я уже лет пять такие риски собираю, особенно в контексте “хайлоада“ и “больших проектов”, и недавно на МТС True Tech сделал на эту тему доклад - линк на презентацию прилагаю ниже. В презентации попытка
- формализовать все фундаментальные проблемы, из которых риски проистекают
- обозначить хотя бы схематично все известные риски
- разобрать подробно три, один из которых, возможно, покажется вам неожиданным, но я прям реально вижу такой тренд в около-корпоративном секторе.

Это лишь часть работы. Замечания, предложения - крайне приветствуются, особенно от компаний, которые почувствовали “боли” от использования микро-сервисного стиля и нашли (либо не нашли) воркераунды.

Update: кто дислайкает - давай поясняй, в споре рождается истина :) риски != блокеры FYI (IYKWIM)

https://devhands.io/rybak-microservices-mtt-2024-v0.5.pdf

Выложили все лекции из нашего продвинутого курса по СУБД из ШАД:

1. Современные и графовые СУБД (13.02.2024)
Лекция: https://disk.yandex.ru/i/O5ioXU6b_8YXtA
Семинар: https://disk.yandex.ru/i/TXHXRhEkevSEXg

2. Транзакция в распределенных СУБД & Обзор домашнего задания. Протокол паксос (27.02.2024)
Лекция: https://disk.yandex.ru/i/LasmL4lpMFYbYg
Семинар: https://disk.yandex.ru/i/Zja_e4cxD6_gIg

3. Query Compilers. JIT (05.03.2024)
Лекция: https://disk.yandex.ru/i/QN33G7JowTSOaw
Семинар: https://disk.yandex.ru/i/ynfMwbzez36G5g

5. Протокол tapir. Поколонночные базы данных (12.03.2024)
Лекция: https://disk.yandex.ru/i/vXHtsMfMfyqPFQ

6. Оптимизация SQL-запросов (19.03.2024)
Лекция: https://disk.yandex.ru/i/6L21N7aVisKkrA

7. Оптимизация SQL запросов, часть 2 (26.03.2024)
Лекция: https://disk.yandex.ru/i/dHyuQ-sVRio3Aw

8. Многопоточные операторы SQL (02.04.2024)
Лекция: https://disk.yandex.ru/i/zk0BRG-OqibCNg
Семинар (запись прошлого года): https://disk.yandex.ru/i/sTyzNvNdzRm8-Q

9. Протокол Raft & MPP аналитика (09.04.2024)
Лекция (Протокол Raft): https://disk.yandex.ru/i/3YTiavRj2IcDoA
Лекция (MPP аналитика): https://disk.yandex.ru/i/kkB_ck0emWbCjQ

10. Main memory базы данных (16.04.2024)
Лекция: https://disk.yandex.ru/i/SvBqT8_ZTjvHXA

11. Разработка Postgres (23.04.2024)
Лекция: https://disk.yandex.ru/i/tERU5moyX7j7gQ

12. Обзор индустриальных СУБД: Cassandra, ScyllaDB, Tarantool, Picodata (Часть 1). Обзор ClickHouse. (14.05.2024)
Лекция (Обзор индустриальных СУБД): https://disk.yandex.ru/i/pv_Ks-QrICtIkg
Лекция (Обзор ClickHouse): https://disk.yandex.ru/i/h4PDp5QhfRGVXg

13. YDB. Распределённая масштабируемая отказоустойчивая СУБД с открытым исходным кодом от Яндекс & Динамические таблицы YTsaurus (21.05.2024)
Лекция (YDB): https://disk.yandex.ru/i/5-Ej1jknvEb1OA
Лекция (Динамические таблицы YTsaurus): https://disk.yandex.ru/i/cM7g4Day0U2Gcw

14. Обзор индустриальных СУБД: Cassandra, ScyllaDB, Tarantool, Picodata (Часть 2) (28.05.2024)
Лекция: https://disk.yandex.ru/i/gkK8JvUiiAe8Hw

Видео с митапа в Тинькове (Engineering Architecture Meetup)

Выступал позавчера в Тинькове - видео ниже. Архитектурный митап, тема - “монолит или микросервисы”. За монолит никто не топил, скорее говорили об “особенностях” МСА (микросервисной архитектуры).

Мой доклад последний, про особенности МСА применительно к большим проектам: https://www.youtube.com/watch?v=WtEdxvwivbY&t=5353s.

Ещё выступал Тимур Баюров (Тиньков) “Определение границ сервисов” и Фил Дельгядо (Lekton.io) с докладом “Пойди туда, не знаю куда. Особенности взаимодействия в распределенных системах”.

Мне понравились мысли из доклада Тимура про вредность приставки “микро”, транзакционные границы и бизнес-вертикали. По этому поводу не могу не процитировать один из каментов в треде YCombinator: If the thing can encapsulate an entire transaction, then it's taking care of an entire business vertical. What I do agree, it's one of the best ways to partition your services (just after not doing it). But calling this a "microservice" only serves to confuse people (https://news.ycombinator.com/item?id=37219513).

Трудовые будни разработки: как выстроить эффективный и безопасный процесс.

https://youtu.be/aHXqTHOSbco

Недавно записали подкаст у Сергея Зинкевича вместе с Дмитрием Симоновым (@ctorecords).

Поговорили про CI/CD, релизные боли и фейлы, и даже немного поговорили про безопасность.

Рассказал, как я спал под столом во время одного из первых релизов Badoo, и как я люблю иб-консультантов (это правда, любовь с безопасностью на расстоянии - что может быть лучше в бизнесе без вывода денег ;)

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

“Темные Паттерны” Игоря Кузнецова

Не реклама - дружеская рекомендация. Если вы интересуетесь продуктовой разработкой, маркетингом, growth-хакингом, то хочу вам порекомендовать канал “Темные паттерны” (@brainshare). Его ведет Игорь Кузнецов, мы вместе работали в Badoo. Сейчас Игорь - CPO в VK.Знакомства. Из последнего у Игоря - отличный пост про книгу Ю-Кай Чоу “Actionable Gamification: Beyond Points, Badges, and Leaderboards”.

Темные паттерны - это “провоцирующие паттерны”. Они могут нравится, могут не нравится, но это стандарт индустрии, и почти весь growth hacking и тюнинг конверсий - про это самое. В широком смысле это любые приёмы, которые заставляют юзера совершить действие, нужное бизнесу. В канале у Игоря - сотни примеров разной степени эффективности и “темноты”. Must read, если вы в продуктовой разработке.

Менеджер, 7 лет

Разбавлю ленту постом из жизни.

Участники: дошкольник Данила и его папа, перешедший на еду с жестким лимитом по калориям (доставляют готовые небольшие порции, поэтому еда измеряется коробками, каждая коробка – маленькая, одна порция).

- Папа, даю тебе десять минут, чтобы ты сьел свою коробку
- Отлично, я сьем её за пять минут
- Тогда я даю тебе 4 минуты
- Данила!… Похоже, ты – прирожденный менеджер.

Очередной онлайн-митап по очередям

Техдиры, архитекторы, эксперты, синьоры и та молодая шпана, готовая их стереть с лица земли!

В следующую среду, 19-го июня в 18:00 MSK в рамках проекта DevHands.io Open Sessions состоится очередной митап с Владимиром Перепелицей (ex-VK, Trantool) с рабочим названием “В очередь!”, посвященная, как вы возможно догадались, очередям.

Владимир - эксперт по большим проектам, очередям и Tarantool, регулярный спикер и член ПК конференций Highload, создатель S3 в VK Cloud, главный по обучению очередям в рамках образовательной платформы DevHands.io.

Абсолютное большинство высоконагруженных проектов использует какую-то систему очередей. Межсервисное взаимодействие через системы очередей - невероятно широкая тема, и абсолютно обязательная к изучению всем, кто интересуется архитектурой. Популярных продуктов - таких как Kafka, Rabbit, NATS, и даже, извините, Redis - много, все решения чем-то отличаются, и разработчику важно понимать архитектурные особенности, сильные и слабые стороны компонент, на базе которых строится архитектура.

Я пригласил Владимира на онлайн-встречу, чтобы в формате беседы расспросить его о следующем:
* Можно ли говорить о существовании универсального подхода к выбору системы очередей? Как принимаются решения о выборе систем очередей?
* Какие архитектурные паттерны используются разработчиками систем очередей? Какие «ручки» нужно искать в первую очередь для настроек производительности? Как масштабируются эти системы?
* Насколько остро у разработчиков и потребителей персистентных очередей стоят вопросы удаления устаревающих данных, и как они решаются?
* Чем плохи (и чем хороши) системы очередей, построенные поверх традиционных MVCC СУБД? Есть ли специализированные «движки очередей» в соответствующих эко-системах?
* Что это за задача двух (византийских?) генералов, и какое отношение она имеет к разработке систем очередей?

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

Чтобы зарегистрироваться и не пропустить встречу, просто добавьте к себе нашего бота @devhands_meetup_bot и нажмите кнопку “Start” либо отправьте ему сообщение “/start”. Если бот у вас уже добавлен - надо так же его стартовать, чтобы он стартовал по новому расписанию.

До встречи 19-го июня!

Выложили запись стрима с В. Перепелицей про очереди

Отличный был стрим, за что большое спасибо Владимиру и всем, кто пришел! Обсудили:
* как выбирать систему очередей
* как масштабируются очереди
* типичные сценарии выхода из строя системы очередей, и что нужно делать, чтобы этого не произошло
* плюсы и минусы очередей, построенных поверх традиционных MVCC СУБД
* почему всё-таки “единая шина сообщений” это не SPOF
и многое другое

Смотрите запись стрима: https://www.youtube.com/watch?v=vx4G0vVlnJk&t=265s

И напоминаю, что мы с Владимиром запустили новый курс на платформе DevHands.io – “Ведение в очереди”, уникальный курс, где участники смогут познакомиться сразу со всеми наиболее популярными системами очередей: Kafka, Rabbit, NATS, Redis, а также облачные SQS-like решения и решения поверх СУБД. Курс стартует уже в самом начале июля, и пока на него действует 20% скидка по промокоду ARE_YOU_NATS. Подробнее о курсе – тут: https://devhands.io/ru/queues.html. А ещё у нас есть “флагманские” курсы: хайлоад-буткемп и курс по системному дизайну высоко-нагруженных проектов.