👋Привет! Меня зовут Дима Салахутдинов, я - staff-инженер и Ruby-разработчик. Занимаюсь развитием Ruby-платформы, а так же масштабированием монолитной системы через выделение из нее новых микро-сервисов.
Как разработчик, сделавший выбор в пользу развития компетенций в технической ветке (staff+ на изображении) в противовес управленческой, я столкнулся с тем, что классифицировать роль staff-инженера сложно: невозможно дать четкого и емкого определения (или оно займет целую книгу).
В этом блоге будем разбираться с темами, связанными с профессиональной деятельностью staff+:
- с какими задачами сталкивается staff-инженер и как их решает
- подходы, которые staff-инженеры используют в своей работе
- полезные материалы и книги (не только технические), которые я прочитал, спроецировал на свою профессиональную деятельность и счел полезными
Возможно будет интересно, присоединяйтесь! 🙂
Как разработчик, сделавший выбор в пользу развития компетенций в технической ветке (staff+ на изображении) в противовес управленческой, я столкнулся с тем, что классифицировать роль staff-инженера сложно: невозможно дать четкого и емкого определения (или оно займет целую книгу).
В этом блоге будем разбираться с темами, связанными с профессиональной деятельностью staff+:
- с какими задачами сталкивается staff-инженер и как их решает
- подходы, которые staff-инженеры используют в своей работе
- полезные материалы и книги (не только технические), которые я прочитал, спроецировал на свою профессиональную деятельность и счел полезными
Возможно будет интересно, присоединяйтесь! 🙂
Прочитал и рекомендую шикарную книгу А. Пиперски "Конструирование языков. От эсперанто до дотракийского" - лингвистический реверс-инжениринг!
Повествование строится вокруг гипотезы Сепира-Уорфа, о том, что мышление определяется языком, и когнитивные категории и ограничения мышления определяются лингвистическими факторами (язык влияет на мышление людей, говорящих на нем).
В книге приводится разбор ряда искусственных языков, разработанных для определенных целей. Мне запомнились несколько:
- Токипона - язык из 120 слов базовых слов, все остальные получаются декомпозицией смысла на простые составляющие. Само название языка "toki pona" состоит из слов toki ‘язык, говорить’ и pona ‘хороший. Назначение токипоны — научить людей разлагать мысли на базовые составные части и благодаря этому мыслить более философски и глубже понимать мир.
- Сольресоль - базирующийся на музыке универсальный язык, призванный снизить языковой барьер между носителями разных языков. Все слова в языке составлены из слогов — названий нот (до, ре, ми, фа, соль, ля, си). По замыслу создателя языка, словам можно передавать самыми разными способами: с помощью слогов, наигрывая ноты 🎼 или даже с помощью цветов.
- Ифкуиль - многогранный искусственный язык со сложной грамматикой (96 падежей) и фонетикой (7 тонов, изменение высоты голоса может изменять смысл), предполагающий - увеличение скорости мышления: выражения лаконичней, смысловая нагрузка в единицу речи - больше. Естественно при условии овладения языком в совершенстве (примеров не приводится). 😉 Если заинтригованы - читайте статью "Скорость мысли" из далекого 2004 в журнале "Компьютерра".
Так же автор выделяет и доступным языком рассказывает о различных классах языков: на основе символов, к примеру, язык дорожных знаков 🚫 ; или артленги (языки вымышленных миров в художественной литературе и кино).
❓Вы спросите, причем тут разработка и инженерия? Вот несколько разнонаправленных мыслей-проекций на проф. деятельность:
- как рубист, я под другим углом посмотрел на язык. Идеальный инструмент для прототипирования и быстрого написания бизнес логики. А раз так, требовать от "носителей" этого языка глубоких знаний виртуальной машины/аллокаций памяти, может быть не всегда уместно. Это как требовать от водителя - знания, как работает ДВС и как провести его капитальный ремонт. Если знаешь - ты крут! Но ездить можно и без этого.
- наш словарный запас во многом определяет наше сознание, представьте, если бы в лексиконе не было слова "монолит", которое имеет скрытый негативный окрас. Либо для его описания приходилось бы декомпозировать мысль: "большая-система-написанная-множеством-людей-плохо-поддающаяся-масштабированию"
- почему монолит в русском языке это он? (мужского рода), а "архитектура" - это она (женского рода). Может поэтому мы к нему суровы, а к архитектуре относимся бережно. А архитектура в монолите - это что-то непозволительное!
- дальше-больше, немного последив за собой задаешься вопросом: в чем разница между "задачей в Jira - задачкой в Jira", "сервисом - сервиском". Это уменьшительно ласково, или пренебрежительно ласково?
- насколько лично я владею русским языком, чтобы четко и ясно выражать коллегам свою мысль?
Помимо концентрированного эстетического удовольствия от чтения книги и лингвистических задач из нее, такого рода мысли вас ожидают после прочтения (ссылка на книгу).
И в заключение, цитата от автора: "В наши дни шанс стать общепринятым стандартом имеют эмодзи, но посмотрим, как сложится их судьба 🤔."
Повествование строится вокруг гипотезы Сепира-Уорфа, о том, что мышление определяется языком, и когнитивные категории и ограничения мышления определяются лингвистическими факторами (язык влияет на мышление людей, говорящих на нем).
В книге приводится разбор ряда искусственных языков, разработанных для определенных целей. Мне запомнились несколько:
- Токипона - язык из 120 слов базовых слов, все остальные получаются декомпозицией смысла на простые составляющие. Само название языка "toki pona" состоит из слов toki ‘язык, говорить’ и pona ‘хороший. Назначение токипоны — научить людей разлагать мысли на базовые составные части и благодаря этому мыслить более философски и глубже понимать мир.
- Сольресоль - базирующийся на музыке универсальный язык, призванный снизить языковой барьер между носителями разных языков. Все слова в языке составлены из слогов — названий нот (до, ре, ми, фа, соль, ля, си). По замыслу создателя языка, словам можно передавать самыми разными способами: с помощью слогов, наигрывая ноты 🎼 или даже с помощью цветов.
- Ифкуиль - многогранный искусственный язык со сложной грамматикой (96 падежей) и фонетикой (7 тонов, изменение высоты голоса может изменять смысл), предполагающий - увеличение скорости мышления: выражения лаконичней, смысловая нагрузка в единицу речи - больше. Естественно при условии овладения языком в совершенстве (примеров не приводится). 😉 Если заинтригованы - читайте статью "Скорость мысли" из далекого 2004 в журнале "Компьютерра".
Так же автор выделяет и доступным языком рассказывает о различных классах языков: на основе символов, к примеру, язык дорожных знаков 🚫 ; или артленги (языки вымышленных миров в художественной литературе и кино).
❓Вы спросите, причем тут разработка и инженерия? Вот несколько разнонаправленных мыслей-проекций на проф. деятельность:
- как рубист, я под другим углом посмотрел на язык. Идеальный инструмент для прототипирования и быстрого написания бизнес логики. А раз так, требовать от "носителей" этого языка глубоких знаний виртуальной машины/аллокаций памяти, может быть не всегда уместно. Это как требовать от водителя - знания, как работает ДВС и как провести его капитальный ремонт. Если знаешь - ты крут! Но ездить можно и без этого.
- наш словарный запас во многом определяет наше сознание, представьте, если бы в лексиконе не было слова "монолит", которое имеет скрытый негативный окрас. Либо для его описания приходилось бы декомпозировать мысль: "большая-система-написанная-множеством-людей-плохо-поддающаяся-масштабированию"
- почему монолит в русском языке это он? (мужского рода), а "архитектура" - это она (женского рода). Может поэтому мы к нему суровы, а к архитектуре относимся бережно. А архитектура в монолите - это что-то непозволительное!
- дальше-больше, немного последив за собой задаешься вопросом: в чем разница между "задачей в Jira - задачкой в Jira", "сервисом - сервиском". Это уменьшительно ласково, или пренебрежительно ласково?
- насколько лично я владею русским языком, чтобы четко и ясно выражать коллегам свою мысль?
Помимо концентрированного эстетического удовольствия от чтения книги и лингвистических задач из нее, такого рода мысли вас ожидают после прочтения (ссылка на книгу).
И в заключение, цитата от автора: "В наши дни шанс стать общепринятым стандартом имеют эмодзи, но посмотрим, как сложится их судьба 🤔."
Литрес
«Конструирование языков: От эсперанто до дотракийского» – Александр Пиперски | ЛитРес
Почему люди создают свои собственные новые языки – конланги, когда в мире насчитывается 7000 естественных языков? Какие бывают искусственные языки? Чем они похожи на естественные языки, а чем отличаю…
Намерения реализовать новую бизнес-логику автономно за рамками монолитной архитектуры часто разбиваются об отсутствие данных (назовем это явление missing data source или сокр. MDS).
Missing Data Source - это необходимый и отсутствующий на момент выноса/реализации нового сервиса (зависимый сервис) источник данных (пр. kafka-топик, эндпойнт в монолите/сервисе, подключение к БД). В целевой архитектуре источником выступает отдельный (со-зависимый) сервис, может отсутствовать на момент реализации (не вынесен из монолита).
В такой патовой ситуации важно обозначить у обоих будущих сервисов owner-команду (на основании составленной карты bounded-контекстов).
💡 Исходя из ситуации есть 3 стандартных подхода решения MDS (отсортированы от правильно-долгого к ужасно-быстрому):
1️⃣ Идиоматичный
Необходимые данные передаются асинхронно в со-зависимый сервис, отвечающий за локализованную предметную область.
Плюсы: продуманная сервисная реализация, надежно, стабильно, автономно.
Минусы: долго, чтобы сделать сервис, нужно вынести сначала со-зависимый сервис.
2️⃣ Компромисный (отложенный перенос)
Сделать "временный топик" на базе монолита, сделав его контракт максимально совместимым с первым вариантом. В перспективе, при выносе зависимого сервиса продюсер данных переедет в него. Вполне идиоматичный вариант, если представить монолит - как большой сервис.
Минусы: полной совместимости с будущим решением может не получится, формат данных в топике может иметь "монолитный характер". Помимо декомпозиции контракта жирного топика и потребуются изменения всех потребителей (которых на этот момент может быть много).
3️⃣ Синхронный
Реализуем временный API-на базе монолита (или ходим напрямую в его БД).
Минусы: получаем синхронную интеграцию и сильную связность, со всеми вытекающими
Из-за зависимости одного несуществующего сервиса от другого, на практике сделать сразу идиоматично может быть сложно.
⁉️ А выбор способа отвязки сводится к решению owner-команды со-зависимого сервиса (источника данных) о степени своего участия в проекте, обратно пропорциональной объёму совокупного тех. долга:
- готова вложится во избежание тех. долга - делаем красиво (1)
- готова удилить внимание и согласовать контракт - идем на компромисс (2)
- не готова помогать - используется синхронный вариант (3)
Но поскольку тех. долг распространяется на обе команды, важно заблаговременно выявить взаимозависимости, обсудить вопрос участия команды и сторговаться на приемлемый для всех вариант.
Missing Data Source - это необходимый и отсутствующий на момент выноса/реализации нового сервиса (зависимый сервис) источник данных (пр. kafka-топик, эндпойнт в монолите/сервисе, подключение к БД). В целевой архитектуре источником выступает отдельный (со-зависимый) сервис, может отсутствовать на момент реализации (не вынесен из монолита).
В такой патовой ситуации важно обозначить у обоих будущих сервисов owner-команду (на основании составленной карты bounded-контекстов).
Необходимые данные передаются асинхронно в со-зависимый сервис, отвечающий за локализованную предметную область.
Плюсы: продуманная сервисная реализация, надежно, стабильно, автономно.
Минусы: долго, чтобы сделать сервис, нужно вынести сначала со-зависимый сервис.
Сделать "временный топик" на базе монолита, сделав его контракт максимально совместимым с первым вариантом. В перспективе, при выносе зависимого сервиса продюсер данных переедет в него. Вполне идиоматичный вариант, если представить монолит - как большой сервис.
Минусы: полной совместимости с будущим решением может не получится, формат данных в топике может иметь "монолитный характер". Помимо декомпозиции контракта жирного топика и потребуются изменения всех потребителей (которых на этот момент может быть много).
Реализуем временный API-на базе монолита (или ходим напрямую в его БД).
Минусы: получаем синхронную интеграцию и сильную связность, со всеми вытекающими
Из-за зависимости одного несуществующего сервиса от другого, на практике сделать сразу идиоматично может быть сложно.
- готова вложится во избежание тех. долга - делаем красиво (1)
- готова удилить внимание и согласовать контракт - идем на компромисс (2)
- не готова помогать - используется синхронный вариант (3)
Но поскольку тех. долг распространяется на обе команды, важно заблаговременно выявить взаимозависимости, обсудить вопрос участия команды и сторговаться на приемлемый для всех вариант.
Please open Telegram to view this post
VIEW IN TELEGRAM
martinfowler.com
bliki: Bounded Context
Don't try to build a single, unified model for a large domain. Instead DDD advises us to divide such a domain into many bounded contexts with explicit relationships between them.
Продолжая тему разберем теорию на вымышленном примере.
Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.
Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.
0️⃣ Монолитная реализация
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов
1️⃣ Идиоматичная реализация
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".
Но, одновременно с запуском лояльности - требуется вынос из монолита чекаута (трудоемко), зато тех. долга минимум.
2️⃣ Компромиссная реализация
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.
В этом случае необходимая история заказов под нужды лояльности ведется в сервисе. Схема имеет слабую связность, но остался незначительный техдолг, разобраться с которым нужно при выносе чекаута.
3️⃣ Синхронная реализация
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.
Сильная связность не позволяет назвать сервис автономным.
💡 Но даже такой вариант - это уже первый шаг к автономности. Но дальше нужно двигаться 3, 2, 1.
Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.
Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".
Но, одновременно с запуском лояльности - требуется вынос из монолита чекаута (трудоемко), зато тех. долга минимум.
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.
В этом случае необходимая история заказов под нужды лояльности ведется в сервисе. Схема имеет слабую связность, но остался незначительный техдолг, разобраться с которым нужно при выносе чекаута.
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.
Сильная связность не позволяет назвать сервис автономным.
Please open Telegram to view this post
VIEW IN TELEGRAM
29 февраля в гостеприимном Санкт-Петербурге на Saint P Ruby Meetup Winter 2024 рассказал про запущенный проект "Аутентификации об монолит" (слайды и видео-запись)
💡 Идея в том, чтобы дать возможность новым микро-сервисам обслуживать аутентифицированный трафик, и разблокировав реализацию новых фичей в обособленном сервисе (а не в монолите).
1️⃣ Входящий трафик аутентифицируем "об монолит" отдельным запросом
2️⃣ Заменяем оригинальные аутентификационный заголовки - внутренним X-Auth-Identity, в котором содержится результат аутентицикации
3️⃣ Оригинальный запрос снабжаем аутентификационными данными (UUID пользователя)
На первый взгляд решение костыльное: поскольку изначально вся логика аутентификации находится в Rails-монолите, то и предлагаемое решение завязано на монолит. В этом смысле как будто ничего не меняется!
Но нет же! Можно еще хуже: пустить трафик в новый сервис через монолит, делегировав ему предварительную аутентификацию и роль API-гейтевея!
С такой перспективы все неплохо, тем более что предложенное решение:
- позволяет быстро абстрагироваться от монолита (как будто его вовсе нет)
- за счет унификации API на базе кастомных HTTP-заголовков не противоречит дальнейшему переходу к обстоятельному системному решению (чем обычно грешат временные схемы)
Более того, на личном опыт подтверждаю, что схема рабочая, как для запуска, так и для дальшейшего расширения в системное решение!
А сам подход универсальный, и может быть применен для монолитной архитектуры любого стека. Хотя в докладе добрая половина времени уделена специфике Rails-монолита.
Ссылку на слайды и видео-запись прилагаю.
На первый взгляд решение костыльное: поскольку изначально вся логика аутентификации находится в Rails-монолите, то и предлагаемое решение завязано на монолит. В этом смысле как будто ничего не меняется!
Но нет же! Можно еще хуже: пустить трафик в новый сервис через монолит, делегировав ему предварительную аутентификацию и роль API-гейтевея!
С такой перспективы все неплохо, тем более что предложенное решение:
- позволяет быстро абстрагироваться от монолита (как будто его вовсе нет)
- за счет унификации API на базе кастомных HTTP-заголовков не противоречит дальнейшему переходу к обстоятельному системному решению (чем обычно грешат временные схемы)
Более того, на личном опыт подтверждаю, что схема рабочая, как для запуска, так и для дальшейшего расширения в системное решение!
А сам подход универсальный, и может быть применен для монолитной архитектуры любого стека. Хотя в докладе добрая половина времени уделена специфике Rails-монолита.
Ссылку на слайды и видео-запись прилагаю.
Please open Telegram to view this post
VIEW IN TELEGRAM
В книге "Staff Engineer: Leadership beyond the management track" Уилл Ларсон классифицирует роли стаффов по выполняемым задачам (в зависимости от особенностей и потребностей компании), выделяя 4 базовых архетипа:
1️⃣ Tech Lead (технический эксперт): ведет проекты и команды, обеспечивая техническое руководство, сотрудничая как с командами так и с их менеджментом.
Может заниматься:
- принятием ключевых архитектурных решений и помощью в выборе технологического стека.
- развитием навыков других инженеров через наставничество и обучение
- обеспечением высокого стандарта разработки и его оптимизацией
2️⃣ Architect (архитектор): отвечает за направление и качество архитектурных подходов к критически важной области системы. Имея глубокую техническую экспертизу и учитывая запросы бизнеса и пользователей, проектирует гибкую, масштабируемую и устойчивую архитектуру.
Может заниматься:
- созданием, поддержкой и актуализацией технической документации систем
- анализом и управлением техническими рисками при проектировании системы
- умелым балансированием между скоростью продуктового развития и тяжестью техдолга
- помощью разработчикам в понимании и внедрении архитектурных решений
3️⃣ Solver (спецназ): глубоко погружается в сложную проблему и находит подходящий путь ее решения. Некоторые сосредотачиваются на определенной области в течение длительного времени (например выделяют сервисы из монолита 😉 ). Другие перемещаются из одной горячей точки в другую, руководствуясь приоритетами компании.
Может заниматься:
- исследованием узких мест в архитектуре, интеграции, коде систем с целью выявить слабые места
- выработкой возможных вариантов решения и их практической валидацией
- глубокой проработкой плана и его реализацией
4️⃣ Right Hand (правая рука): оказываем помощь и поддержку руководителю команды в управлении, а так же консультирование по ключевым решениям.
Может заниматься: практически всем
🤔 На мой взгляд стафф/принципал - роль очень гибкая, а решаемые задачи в первую очередь обусловлены потребностью компании.
На практике, ярко-выраженный стабильный архетип из списка для конкретного инженера выявить не получится, скорее это будет смешение разных вариантов, причем в разных пропорциях в зависимости от компании/отдела, ситуации и даже времени. Себя эпизодически вижу в каждой из категорий.
💡Дополнительно кратко отмечу ряд отличительных моментов работы стаффа/принципала, которые, по моему мнению, являются общими вне зависимости от архетипа:
- менторство: помощь коллегам в развитии, обучение (лекции, доклады, семинары), а так же поддержка команд в решении сложных задач
- исследования: прототипирование и отчетность, data-driven подход
- пропоганда: решений, технологий, участие в сообществе, формирование мнений
Может заниматься:
- принятием ключевых архитектурных решений и помощью в выборе технологического стека.
- развитием навыков других инженеров через наставничество и обучение
- обеспечением высокого стандарта разработки и его оптимизацией
Может заниматься:
- созданием, поддержкой и актуализацией технической документации систем
- анализом и управлением техническими рисками при проектировании системы
- умелым балансированием между скоростью продуктового развития и тяжестью техдолга
- помощью разработчикам в понимании и внедрении архитектурных решений
Может заниматься:
- исследованием узких мест в архитектуре, интеграции, коде систем с целью выявить слабые места
- выработкой возможных вариантов решения и их практической валидацией
- глубокой проработкой плана и его реализацией
Может заниматься: практически всем
На практике, ярко-выраженный стабильный архетип из списка для конкретного инженера выявить не получится, скорее это будет смешение разных вариантов, причем в разных пропорциях в зависимости от компании/отдела, ситуации и даже времени. Себя эпизодически вижу в каждой из категорий.
💡Дополнительно кратко отмечу ряд отличительных моментов работы стаффа/принципала, которые, по моему мнению, являются общими вне зависимости от архетипа:
- менторство: помощь коллегам в развитии, обучение (лекции, доклады, семинары), а так же поддержка команд в решении сложных задач
- исследования: прототипирование и отчетность, data-driven подход
- пропоганда: решений, технологий, участие в сообществе, формирование мнений
Please open Telegram to view this post
VIEW IN TELEGRAM
Staffeng
Staff Engineer: Leadership beyond the management track
Buy Staff Engineer: Leadership beyond the management track
Всем привет!
✋В этом году выступаю на конференции Ruby Russia с докладом про Ruby-платформу в Купере.
🎟 У меня есть 1 билет на конференцию, которым я готов поделится c первым, кто оставит комментарий.
💸 Так же организаторы предлагают скидку 15% по промокоду dsalahutdinov.
✋В этом году выступаю на конференции Ruby Russia с докладом про Ruby-платформу в Купере.
💸 Так же организаторы предлагают скидку 15% по промокоду dsalahutdinov.
rubyrussia.club
Rubyrussia 2024
Долгожданная и единственная в России конференция o Ruby на целый день. Наконец-то, офлайн!
Привет! Завтра пройдет Ruby-митап от Evrone, с тремя докладами.
Один из них мой, о способах принятия решений по оптимизации нагрузки на БД, гдя я попытался сформулировать поход (способ, систему или даже фреймворк :)) для измерения нагрузки и выявления максимально выгодных точек приложения усилий.
💡После каждого доклада дискуссия с экспертами, помогающая глубже и шире раскрыть мысль. На это новшество предлагаю обратить особое внимание. Меня дискуссия вывела на более четкие формулировки и полноценное раскрытие темы.
Приглашаю на огонек в 19:00 🔥
Один из них мой, о способах принятия решений по оптимизации нагрузки на БД, гдя я попытался сформулировать поход (способ, систему или даже фреймворк :)) для измерения нагрузки и выявления максимально выгодных точек приложения усилий.
💡После каждого доклада дискуссия с экспертами, помогающая глубже и шире раскрыть мысль. На это новшество предлагаю обратить особое внимание. Меня дискуссия вывела на более четкие формулировки и полноценное раскрытие темы.
Приглашаю на огонек в 19:00 🔥
meetups.evrone.ru
Ruby meetup | meetups.evrone.com
Подписывайтесь на наш канал в телеграмм https://t.me/meetups_evrone, чтобы быть в курсе будущих митапов и не пропускать полезные доклады!
Привет! Рубисты, я прошу вашей помощи в небольшом исследовании Ruby-тулинга для GRPC.
Поставьте 👍, если у вас в продакшен используется GRPC-сервер
❓И ответьте, по возможности на пару вопросов (если есть):
- какими решениями пользуетесь (гуглувый gRPC, либо GRUF как надстройка над ним, либо что-то еще)
- какой в среднем RPS обслуживаете, и насколько утилизирован в плане капасити каждый инстанс/pod
- испытываете ли проблемы с его масштабированием/скейлингом (отсутствие беклога запросов как в пуме, невозможность форкать процесс как в пуме)
- как справляетесь с трудностями, если они есть?
Поставьте 👍, если у вас в продакшен используется GRPC-сервер
❓И ответьте, по возможности на пару вопросов (если есть):
- какими решениями пользуетесь (гуглувый gRPC, либо GRUF как надстройка над ним, либо что-то еще)
- какой в среднем RPS обслуживаете, и насколько утилизирован в плане капасити каждый инстанс/pod
- испытываете ли проблемы с его масштабированием/скейлингом (отсутствие беклога запросов как в пуме, невозможность форкать процесс как в пуме)
- как справляетесь с трудностями, если они есть?
GitHub
grpc/src/ruby at master · grpc/grpc
The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) - grpc/grpc
🖐 У меня в детстве была игровая приставка, реплика Dendy (хотя Dendy сама по себе тоже реплика приставки Nintendo), с которой начался опыт гейминга. Дальше немного видеоигр, которые удавалось запустить на тормозном Пентиуме. Когда появились свои деньги и возможность купить мощное железо - интереса уже не было.
Такой скудный опыт не позволил своевременно погрузиться в игровую культуру, и до недавнего времени я об этом совсем не думал, пока случайно не включил в машине аудиокнигу "Игродром: что нужно знать о видеоиграх и игровой культуре" Александра Вертушинского.
❓ Автор с академической точки зрения подошел к вопросу изучения игр, систематизировал исторические этапы развития и их ключевые особенности. А дальше в социально-культурном, антропологическом и философском контексте исследовал развитие игр в динамике.
💣 Это разрыв шаблона (у не играющего человека)! Книга о взаимном влиянии техники и технологий на множество аспектов жизни (культура, психология, экономика, социальные взаимоотношения, образование и этика) и в другую сторону. Книга не техничекая, но технарям зайдет!
Только из первой главы вы узнаете множество интересного:
- кто такой Марио (Super Mario) и как появился Pac-Man
- почему в футболе расположение поля горизонтальное, а в хоккее - вертикальное
- как в России появилась Dendy (грустно)
- как фантазия геймеров дополняла геймплей в стародавние времена
🔥️️️️️️ Горячо рекомендую всем инженерам! Если желаете отдохнуть от технического чтива, или послушать аудио в дороге.
#Games #Reading #NonTechnical
Такой скудный опыт не позволил своевременно погрузиться в игровую культуру, и до недавнего времени я об этом совсем не думал, пока случайно не включил в машине аудиокнигу "Игродром: что нужно знать о видеоиграх и игровой культуре" Александра Вертушинского.
Только из первой главы вы узнаете множество интересного:
- кто такой Марио (Super Mario) и как появился Pac-Man
- почему в футболе расположение поля горизонтальное, а в хоккее - вертикальное
- как в России появилась Dendy (грустно)
- как фантазия геймеров дополняла геймплей в стародавние времена
#Games #Reading #NonTechnical
Please open Telegram to view this post
VIEW IN TELEGRAM
2 октября прошла долгожданная оффлайн конференция RubyRussia, на которой я рассказывал о разработке и стандартизации платформенных решений на Ruby в Купере. Платформенная разработка весьма специфична, в первую очередь потому, что пользователи конечного продукта - разработчики.
Запись доклада стала недавно ограниченно доступна на youtube, rutube, а так же прилагаю слайды.
По большей части доклад не технический, и не только про Ruby: принципы справедливы для языкоспецифичной части платформенной разработки на любом стеке.
В докладе обобщены и освещаются следующие темы:
- принципы разработки платформенного тулинга
- жизненный цикл платформенных разработок
- тестирование платформенного тулинга
- источники формирования беклога платформенной команды
Приятногно просмотра! Буду рад вопросам, предложениям и обратной связи в треде.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Ruby-платформа: стандартизация подходов на масштабе - Дмитрий Салахутдинов, Купер (ex. СберМаркет)
На больших масштабах неминуемо встает вопрос унификации подходов и инструментов для снижения времени на разработку. Стандартизация дает возможность развернуть типовой сервис из шаблона за несколько минут и сразу начать решать задачи продукта, не тратя время…