👋Привет! Меня зовут Дима Салахутдинов, я - staff-инженер и Ruby-разработчик. Занимаюсь развитием Ruby-платформы, а так же масштабированием монолитной системы через выделение из нее новых микро-сервисов.
Как разработчик, сделавший выбор в пользу развития компетенций в технической ветке (staff+ на изображении) в противовес управленческой, я столкнулся с тем, что классифицировать роль staff-инженера сложно: невозможно дать четкого и емкого определения (или оно займет целую книгу).
В этом блоге будем разбираться с темами, связанными с профессиональной деятельностью staff+:
- с какими задачами сталкивается staff-инженер и как их решает
- подходы, которые staff-инженеры используют в своей работе
- полезные материалы и книги (не только технические), которые я прочитал, спроецировал на свою профессиональную деятельность и счел полезными
Возможно будет интересно, присоединяйтесь! 🙂
Как разработчик, сделавший выбор в пользу развития компетенций в технической ветке (staff+ на изображении) в противовес управленческой, я столкнулся с тем, что классифицировать роль staff-инженера сложно: невозможно дать четкого и емкого определения (или оно займет целую книгу).
В этом блоге будем разбираться с темами, связанными с профессиональной деятельностью staff+:
- с какими задачами сталкивается staff-инженер и как их решает
- подходы, которые staff-инженеры используют в своей работе
- полезные материалы и книги (не только технические), которые я прочитал, спроецировал на свою профессиональную деятельность и счел полезными
Возможно будет интересно, присоединяйтесь! 🙂
👍5
Прочитал и рекомендую шикарную книгу А. Пиперски "Конструирование языков. От эсперанто до дотракийского" - лингвистический реверс-инжениринг!
Повествование строится вокруг гипотезы Сепира-Уорфа, о том, что мышление определяется языком, и когнитивные категории и ограничения мышления определяются лингвистическими факторами (язык влияет на мышление людей, говорящих на нем).
В книге приводится разбор ряда искусственных языков, разработанных для определенных целей. Мне запомнились несколько:
- Токипона - язык из 120 слов базовых слов, все остальные получаются декомпозицией смысла на простые составляющие. Само название языка "toki pona" состоит из слов toki ‘язык, говорить’ и pona ‘хороший. Назначение токипоны — научить людей разлагать мысли на базовые составные части и благодаря этому мыслить более философски и глубже понимать мир.
- Сольресоль - базирующийся на музыке универсальный язык, призванный снизить языковой барьер между носителями разных языков. Все слова в языке составлены из слогов — названий нот (до, ре, ми, фа, соль, ля, си). По замыслу создателя языка, словам можно передавать самыми разными способами: с помощью слогов, наигрывая ноты 🎼 или даже с помощью цветов.
- Ифкуиль - многогранный искусственный язык со сложной грамматикой (96 падежей) и фонетикой (7 тонов, изменение высоты голоса может изменять смысл), предполагающий - увеличение скорости мышления: выражения лаконичней, смысловая нагрузка в единицу речи - больше. Естественно при условии овладения языком в совершенстве (примеров не приводится). 😉 Если заинтригованы - читайте статью "Скорость мысли" из далекого 2004 в журнале "Компьютерра".
Так же автор выделяет и доступным языком рассказывает о различных классах языков: на основе символов, к примеру, язык дорожных знаков 🚫 ; или артленги (языки вымышленных миров в художественной литературе и кино).
❓Вы спросите, причем тут разработка и инженерия? Вот несколько разнонаправленных мыслей-проекций на проф. деятельность:
- как рубист, я под другим углом посмотрел на язык. Идеальный инструмент для прототипирования и быстрого написания бизнес логики. А раз так, требовать от "носителей" этого языка глубоких знаний виртуальной машины/аллокаций памяти, может быть не всегда уместно. Это как требовать от водителя - знания, как работает ДВС и как провести его капитальный ремонт. Если знаешь - ты крут! Но ездить можно и без этого.
- наш словарный запас во многом определяет наше сознание, представьте, если бы в лексиконе не было слова "монолит", которое имеет скрытый негативный окрас. Либо для его описания приходилось бы декомпозировать мысль: "большая-система-написанная-множеством-людей-плохо-поддающаяся-масштабированию"
- почему монолит в русском языке это он? (мужского рода), а "архитектура" - это она (женского рода). Может поэтому мы к нему суровы, а к архитектуре относимся бережно. А архитектура в монолите - это что-то непозволительное!
- дальше-больше, немного последив за собой задаешься вопросом: в чем разница между "задачей в Jira - задачкой в Jira", "сервисом - сервиском". Это уменьшительно ласково, или пренебрежительно ласково?
- насколько лично я владею русским языком, чтобы четко и ясно выражать коллегам свою мысль?
Помимо концентрированного эстетического удовольствия от чтения книги и лингвистических задач из нее, такого рода мысли вас ожидают после прочтения (ссылка на книгу).
И в заключение, цитата от автора: "В наши дни шанс стать общепринятым стандартом имеют эмодзи, но посмотрим, как сложится их судьба 🤔."
Повествование строится вокруг гипотезы Сепира-Уорфа, о том, что мышление определяется языком, и когнитивные категории и ограничения мышления определяются лингвистическими факторами (язык влияет на мышление людей, говорящих на нем).
В книге приводится разбор ряда искусственных языков, разработанных для определенных целей. Мне запомнились несколько:
- Токипона - язык из 120 слов базовых слов, все остальные получаются декомпозицией смысла на простые составляющие. Само название языка "toki pona" состоит из слов toki ‘язык, говорить’ и pona ‘хороший. Назначение токипоны — научить людей разлагать мысли на базовые составные части и благодаря этому мыслить более философски и глубже понимать мир.
- Сольресоль - базирующийся на музыке универсальный язык, призванный снизить языковой барьер между носителями разных языков. Все слова в языке составлены из слогов — названий нот (до, ре, ми, фа, соль, ля, си). По замыслу создателя языка, словам можно передавать самыми разными способами: с помощью слогов, наигрывая ноты 🎼 или даже с помощью цветов.
- Ифкуиль - многогранный искусственный язык со сложной грамматикой (96 падежей) и фонетикой (7 тонов, изменение высоты голоса может изменять смысл), предполагающий - увеличение скорости мышления: выражения лаконичней, смысловая нагрузка в единицу речи - больше. Естественно при условии овладения языком в совершенстве (примеров не приводится). 😉 Если заинтригованы - читайте статью "Скорость мысли" из далекого 2004 в журнале "Компьютерра".
Так же автор выделяет и доступным языком рассказывает о различных классах языков: на основе символов, к примеру, язык дорожных знаков 🚫 ; или артленги (языки вымышленных миров в художественной литературе и кино).
❓Вы спросите, причем тут разработка и инженерия? Вот несколько разнонаправленных мыслей-проекций на проф. деятельность:
- как рубист, я под другим углом посмотрел на язык. Идеальный инструмент для прототипирования и быстрого написания бизнес логики. А раз так, требовать от "носителей" этого языка глубоких знаний виртуальной машины/аллокаций памяти, может быть не всегда уместно. Это как требовать от водителя - знания, как работает ДВС и как провести его капитальный ремонт. Если знаешь - ты крут! Но ездить можно и без этого.
- наш словарный запас во многом определяет наше сознание, представьте, если бы в лексиконе не было слова "монолит", которое имеет скрытый негативный окрас. Либо для его описания приходилось бы декомпозировать мысль: "большая-система-написанная-множеством-людей-плохо-поддающаяся-масштабированию"
- почему монолит в русском языке это он? (мужского рода), а "архитектура" - это она (женского рода). Может поэтому мы к нему суровы, а к архитектуре относимся бережно. А архитектура в монолите - это что-то непозволительное!
- дальше-больше, немного последив за собой задаешься вопросом: в чем разница между "задачей в Jira - задачкой в Jira", "сервисом - сервиском". Это уменьшительно ласково, или пренебрежительно ласково?
- насколько лично я владею русским языком, чтобы четко и ясно выражать коллегам свою мысль?
Помимо концентрированного эстетического удовольствия от чтения книги и лингвистических задач из нее, такого рода мысли вас ожидают после прочтения (ссылка на книгу).
И в заключение, цитата от автора: "В наши дни шанс стать общепринятым стандартом имеют эмодзи, но посмотрим, как сложится их судьба 🤔."
Литрес
Конструирование языков: От эсперанто до дотракийского — Александр Пиперски | Литрес
Почему люди создают свои собственные новые языки – конланги, когда в мире насчитывается 7000 естественных языков? Какие бывают искусственные языки? Чем они похожи на естественные языки, а чем отличаю…
👍5🔥1
В книге "От монолита к микро-сервисам" Сэм Ньюман описывает несколько типовых целей перехода в микро-сервисную архитектуру:
- повышение автономности команд
- сокращение TTM (time-to-market)
- эффективное масштабирование
- повышение отказоустойчивости
- поддержка роста компании
- внедрение новой технологии
❗️Губительным же для проекта перехода автор считает как отсутствие цели, так и желание достичь множество целей одновременно. По этому поводу автор высказывается:
Продолжим пример: мы целимся в масштабирование. А оно достигается за счет перераспределения нагрузки на выделенные сервисы.
По заветам автора, держа в уме одну главную цель, составляем простой план:
- сначала выделяем сервис "как есть" с минимально необходимыми изменениями. Чтобы достичь результата (перераспределить нагрузку) - нужно срезать углы, а любой оверхед не допустим (поэтому никаких изменений)
- дальше в рамках автономного развития сервиса фокусно проводим оптимизации и другие улучшения.
Кажется все просто, но на деле появляется ряд второстепенных требований, которые, не будучи основным мотивом, кратно увеличивают сроки проекта из-за возрастающей когнитивной нагрузки:
- перейти на другой стек: к примеру декомпозируем Ruby-монолит в сервисы на Golang. Для выноса сервиса необходимо разобраться в текущей реализации, локализовать ее и перенести код. У рубистов дополнительная когнитивная нагрузка появится в последнем пункте, у голанг-разработчиков - сразу в первом.
- исправить в процессе переезда ошибки и уязвимости. Изменение в поведении системы ведут к невозможности сравнить обе реализации (монолитную, как эталон, и новую сервисную). Приходится держать в уме эту "разницу". А если фиксов много?
- улучшить перформанс или кардинально поменять бизнес-процесс, и как следствие обоих пунктов, - сделать новую систему, идеально заточенную под актуальные требования. Проблема проявится при интеграции "нового подхода" со старым, и прийдется временно адаптировать новое под старое.
В качестве тулинга по выстраиванию и удержанию приоритетов Ньюман предлагает систему "ползунков":
- выписать цели и расставить их приоритеты на текущий момент (это нормально, если позже приоритеты изменятся) в формате ползунков указывая вес (к примеру, от 0 до 10)
- выбрать главную цель, следовать ей
- постоянно использовать диаграмму для принятия и агрументации технических и организационных решений
Последний пункт не очевидный, но в разы ценней первого: регулярное обращение к приоритетам - помогает избежать расфокуса, не потерять понимание, и не упустить смысл в процессе.
- повышение автономности команд
- сокращение TTM (time-to-market)
- эффективное масштабирование
- повышение отказоустойчивости
- поддержка роста компании
- внедрение новой технологии
❗️Губительным же для проекта перехода автор считает как отсутствие цели, так и желание достичь множество целей одновременно. По этому поводу автор высказывается:
Однако в реальности люди часто пытаются изменить не одну вещь, а сразу много. Это приводит к путанице приоритетов, быстро увеличивается объем работ, задерживая получение каких-либо выгод.
К примеру, мы решаем, что изменение архитектуры приложения позволит справляться с ростом трафика: "Ну, если беремся за микро-сервисы, то одновременно с этим можем сделать команды автономнее! И это дает нам отличный шанс попробовать Kotlin в качестве языка программирования!"
Прежде чем вы придете в себя у вас уже будет масштабная инициатива внедрения множества новшеств, которые накинули к плану работ "для верности".
В такой ситуации микро-сервисы становятся запертыми как подход!
Важно отделить мотивирующий стержневой мотив от любых второстепенных выгод, которые вы также хотели бы получить. В описанном примере масштабирование системы - самый важный мотив. Остальные работы, не направленные на достижение главной цели, должны отойти на задний план.
Продолжим пример: мы целимся в масштабирование. А оно достигается за счет перераспределения нагрузки на выделенные сервисы.
По заветам автора, держа в уме одну главную цель, составляем простой план:
- сначала выделяем сервис "как есть" с минимально необходимыми изменениями. Чтобы достичь результата (перераспределить нагрузку) - нужно срезать углы, а любой оверхед не допустим (поэтому никаких изменений)
- дальше в рамках автономного развития сервиса фокусно проводим оптимизации и другие улучшения.
Кажется все просто, но на деле появляется ряд второстепенных требований, которые, не будучи основным мотивом, кратно увеличивают сроки проекта из-за возрастающей когнитивной нагрузки:
- перейти на другой стек: к примеру декомпозируем Ruby-монолит в сервисы на Golang. Для выноса сервиса необходимо разобраться в текущей реализации, локализовать ее и перенести код. У рубистов дополнительная когнитивная нагрузка появится в последнем пункте, у голанг-разработчиков - сразу в первом.
- исправить в процессе переезда ошибки и уязвимости. Изменение в поведении системы ведут к невозможности сравнить обе реализации (монолитную, как эталон, и новую сервисную). Приходится держать в уме эту "разницу". А если фиксов много?
- улучшить перформанс или кардинально поменять бизнес-процесс, и как следствие обоих пунктов, - сделать новую систему, идеально заточенную под актуальные требования. Проблема проявится при интеграции "нового подхода" со старым, и прийдется временно адаптировать новое под старое.
В качестве тулинга по выстраиванию и удержанию приоритетов Ньюман предлагает систему "ползунков":
- выписать цели и расставить их приоритеты на текущий момент (это нормально, если позже приоритеты изменятся) в формате ползунков указывая вес (к примеру, от 0 до 10)
- выбрать главную цель, следовать ей
- постоянно использовать диаграмму для принятия и агрументации технических и организационных решений
Последний пункт не очевидный, но в разы ценней первого: регулярное обращение к приоритетам - помогает избежать расфокуса, не потерять понимание, и не упустить смысл в процессе.
Литрес
От монолита к микросервисам — Сэм Ньюмен | Литрес
Новая книга Сэма Ньюмена подробно описывает проверенный метод перевода существующей монолитной системы на микросервисы, поддерживающий работу организации в обычном режиме. Она дополняет его бестселле…
👍14❤1
Намерения реализовать новую бизнес-логику автономно за рамками монолитной архитектуры часто разбиваются об отсутствие данных (назовем это явление 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.
👏2❤1👍1
Продолжая тему разберем теорию на вымышленном примере.
Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.
Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.
0️⃣ Монолитная реализация
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов
1️⃣ Идиоматичная реализация
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".
Но, одновременно с запуском лояльности - требуется вынос из монолита чекаута (трудоемко), зато тех. долга минимум.
2️⃣ Компромиссная реализация
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.
В этом случае необходимая история заказов под нужды лояльности ведется в сервисе. Схема имеет слабую связность, но остался незначительный техдолг, разобраться с которым нужно при выносе чекаута.
3️⃣ Синхронная реализация
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.
Сильная связность не позволяет назвать сервис автономным.
💡 Но даже такой вариант - это уже первый шаг к автономности. Но дальше нужно двигаться 3, 2, 1.
Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.
Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".
Но, одновременно с запуском лояльности - требуется вынос из монолита чекаута (трудоемко), зато тех. долга минимум.
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.
В этом случае необходимая история заказов под нужды лояльности ведется в сервисе. Схема имеет слабую связность, но остался незначительный техдолг, разобраться с которым нужно при выносе чекаута.
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.
Сильная связность не позволяет назвать сервис автономным.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
Лучший друг любого профессионала (и стафф-инженера в том числе) - бесценный опыт и обширные знания, накопленные за годы работы. Удержать все в голове - не получится, и тут на помощь приходит Obsidian - редактор и навигатор для ведения заметок или даже инструмент для оформления, структуризации и работы с вашей базой знаний (зависит от степени знакомства).
1️⃣ Это просто текстовый редактор (markdown) файлов на локальном компьютере. Парадоксально, что большая кривая развития сервисов заметок в итоге приводит нас обратно к файлам на локальной машине. А новизна и актуальность кроется в "принципе владения своими данными". Как пишут сами авторы:
Никто не сможет отлучить Вас от знаний, когда они на локальной машине (это вам не сервер отключить)! А Если хочется поделиться - просто выгружаем заметку в PDF (экспорт работает отменно).
Простота редактирования обеспечивается форматом Markdown, знакомого любому разработчику. Нет сложности начать, никакого порога входа и противоречий.
2️⃣ Заметки можно перелинковать между собой, делая отсылки к другим заметкам - киллер-фича 🔥 , позволяющая выстроить работы с базой знаний по системе Цеттелькастен.
3️⃣ Работа с данными не менее важна, чем формирование связной структуры. К примеру, Цеттелькастен предполагает регулярный просмотр всех заметок для освежения знаний. В реальности же чаще возникает внезапная необходимость найти определенную заметку. И тут Obsidian на высоте с быстрым и эффективным поиском и развитой навигацией.
Три пункта выше уже подкупают, хотя богатство возможностей Obsidian ими далеко не ограничивается. Если Вас заинтересовало - рекомендую цикл уроков на Youtube от "Теплицы Социальных Технологий".
Проецируя на профессиональную деятельность приведу несколько примеров использования заметок в моей базе знаний:
- 1:1 звонки с коллегами: на каждого собеседника отдельный файл, заголовками отмечаю дату звонка, фиксирую предмет обсуждения, новые для меня данные и достигнутые договоренности. Чтобы обсудить важную тему на предстоящем звонке - завожу заметку заранее.
- работа над проектами: артефакты по каждому проекту в отдельной папке. Тут складирую результаты встреч, обсуждений, ссылки на документацию, куски кода и архитектурных диаграмм. Помогает и как в случае ведения более одного проекта одновременно, так и в качестве архива знаний по завершенным проектам (к примеру, чтобы вспомнить и уточнить обоснование определенного технического решения).
- перформанс ревью: отдельные заметки, где я фиксирую успехи и достижения (свои и коллег) или просто логирую свою работу (о том, почему это важно рекомендую видео).
- подготовка к рабочим встречам: начинаю с формулирования тезисов, целей и задач, иногда доходит до написания полного текста всей речи и многократное вычитывание Если встреча важная а времени мало, нужно четко и емко формулировать мысль. После встречи документ можно переиспользовать как follow up.
- статьи/доклады на конференции: черновики, или уже оформленные. Обычно все идеи исходят из рабочих проектов. Удобно вести их рядом, снабжая ссылками на проектные активности. Даже если материал сырой - очень легко и быстро собрать все вместе, и на подготовку уходит меньше времени.
- план чтения: какие книги я планирую прочитать и в каком порядке. А так же заметки по уже прочитанным книгам, конспекты, собственные мысли или цитаты (как это делать правильно можно прочитать тут);
- план и идеи постов в этот телеграм-канал
❗️ Абсолютное могущество получаем, когда с помощью Obsidian осмысленно перелинковываем заметки в связный граф собственной базы знаний!
Подготовится к докладу, ко встрече и тд - не вопрос, фактически материал уже в готовом виде, в легком доступе и всегда в вашем распоряжении!
Как говорится: "просто добавь воды" 😂.
Your thoughts are yours.
Никто не сможет отлучить Вас от знаний, когда они на локальной машине (это вам не сервер отключить)! А Если хочется поделиться - просто выгружаем заметку в PDF (экспорт работает отменно).
Простота редактирования обеспечивается форматом Markdown, знакомого любому разработчику. Нет сложности начать, никакого порога входа и противоречий.
Три пункта выше уже подкупают, хотя богатство возможностей Obsidian ими далеко не ограничивается. Если Вас заинтересовало - рекомендую цикл уроков на Youtube от "Теплицы Социальных Технологий".
Проецируя на профессиональную деятельность приведу несколько примеров использования заметок в моей базе знаний:
- 1:1 звонки с коллегами: на каждого собеседника отдельный файл, заголовками отмечаю дату звонка, фиксирую предмет обсуждения, новые для меня данные и достигнутые договоренности. Чтобы обсудить важную тему на предстоящем звонке - завожу заметку заранее.
- работа над проектами: артефакты по каждому проекту в отдельной папке. Тут складирую результаты встреч, обсуждений, ссылки на документацию, куски кода и архитектурных диаграмм. Помогает и как в случае ведения более одного проекта одновременно, так и в качестве архива знаний по завершенным проектам (к примеру, чтобы вспомнить и уточнить обоснование определенного технического решения).
- перформанс ревью: отдельные заметки, где я фиксирую успехи и достижения (свои и коллег) или просто логирую свою работу (о том, почему это важно рекомендую видео).
- подготовка к рабочим встречам: начинаю с формулирования тезисов, целей и задач, иногда доходит до написания полного текста всей речи и многократное вычитывание Если встреча важная а времени мало, нужно четко и емко формулировать мысль. После встречи документ можно переиспользовать как follow up.
- статьи/доклады на конференции: черновики, или уже оформленные. Обычно все идеи исходят из рабочих проектов. Удобно вести их рядом, снабжая ссылками на проектные активности. Даже если материал сырой - очень легко и быстро собрать все вместе, и на подготовку уходит меньше времени.
- план чтения: какие книги я планирую прочитать и в каком порядке. А так же заметки по уже прочитанным книгам, конспекты, собственные мысли или цитаты (как это делать правильно можно прочитать тут);
- план и идеи постов в этот телеграм-канал
Подготовится к докладу, ко встрече и тд - не вопрос, фактически материал уже в готовом виде, в легком доступе и всегда в вашем распоряжении!
Как говорится: "просто добавь воды" 😂.
Please open Telegram to view this post
VIEW IN TELEGRAM
Obsidian
Obsidian - Sharpen your thinking
The free and flexible app for your private thoughts.
🔥6❤2👍2
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
🔥5
В книге "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
👍10🔥2
Всем привет!
✋В этом году выступаю на конференции Ruby Russia с докладом про Ruby-платформу в Купере.
🎟 У меня есть 1 билет на конференцию, которым я готов поделится c первым, кто оставит комментарий.
💸 Так же организаторы предлагают скидку 15% по промокоду dsalahutdinov.
✋В этом году выступаю на конференции Ruby Russia с докладом про Ruby-платформу в Купере.
💸 Так же организаторы предлагают скидку 15% по промокоду dsalahutdinov.
rubyrussia.club
Rubyrussia 2025 | RubyRussia
Долгожданная и единственная в России конференция o Ruby на целый день. Наконец-то, офлайн!
🔥16
Привет! Завтра пройдет Ruby-митап от Evrone, с тремя докладами.
Один из них мой, о способах принятия решений по оптимизации нагрузки на БД, гдя я попытался сформулировать поход (способ, систему или даже фреймворк :)) для измерения нагрузки и выявления максимально выгодных точек приложения усилий.
💡После каждого доклада дискуссия с экспертами, помогающая глубже и шире раскрыть мысль. На это новшество предлагаю обратить особое внимание. Меня дискуссия вывела на более четкие формулировки и полноценное раскрытие темы.
Приглашаю на огонек в 19:00 🔥
Один из них мой, о способах принятия решений по оптимизации нагрузки на БД, гдя я попытался сформулировать поход (способ, систему или даже фреймворк :)) для измерения нагрузки и выявления максимально выгодных точек приложения усилий.
💡После каждого доклада дискуссия с экспертами, помогающая глубже и шире раскрыть мысль. На это новшество предлагаю обратить особое внимание. Меня дискуссия вывела на более четкие формулировки и полноценное раскрытие темы.
Приглашаю на огонек в 19:00 🔥
meetups.evrone.ru
Ruby meetup | meetups.evrone.com
Подписывайтесь на наш канал в телеграмм https://t.me/meetups_evrone, чтобы быть в курсе будущих митапов и не пропускать полезные доклады!
🔥20
Привет! Рубисты, я прошу вашей помощи в небольшом исследовании Ruby-тулинга для GRPC.
Поставьте 👍, если у вас в продакшен используется GRPC-сервер
❓И ответьте, по возможности на пару вопросов (если есть):
- какими решениями пользуетесь (гуглувый gRPC, либо GRUF как надстройка над ним, либо что-то еще)
- какой в среднем RPS обслуживаете, и насколько утилизирован в плане капасити каждый инстанс/pod
- испытываете ли проблемы с его масштабированием/скейлингом (отсутствие беклога запросов как в пуме, невозможность форкать процесс как в пуме)
- как справляетесь с трудностями, если они есть?
Поставьте 👍, если у вас в продакшен используется GRPC-сервер
❓И ответьте, по возможности на пару вопросов (если есть):
- какими решениями пользуетесь (гуглувый gRPC, либо GRUF как надстройка над ним, либо что-то еще)
- какой в среднем RPS обслуживаете, и насколько утилизирован в плане капасити каждый инстанс/pod
- испытываете ли проблемы с его масштабированием/скейлингом (отсутствие беклога запросов как в пуме, невозможность форкать процесс как в пуме)
- как справляетесь с трудностями, если они есть?
GitHub
grpc/src/ruby at master · grpc/grpc
C++ based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) - grpc/grpc
👍13
🖐 У меня в детстве была игровая приставка, реплика 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
👍12🔥1
2 октября прошла долгожданная оффлайн конференция RubyRussia, на которой я рассказывал о разработке и стандартизации платформенных решений на Ruby в Купере. Платформенная разработка весьма специфична, в первую очередь потому, что пользователи конечного продукта - разработчики.
Запись доклада стала недавно ограниченно доступна на youtube, rutube, а так же прилагаю слайды.
По большей части доклад не технический, и не только про Ruby: принципы справедливы для языкоспецифичной части платформенной разработки на любом стеке.
В докладе обобщены и освещаются следующие темы:
- принципы разработки платформенного тулинга
- жизненный цикл платформенных разработок
- тестирование платформенного тулинга
- источники формирования беклога платформенной команды
Приятногно просмотра! Буду рад вопросам, предложениям и обратной связи в треде.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Ruby-платформа: стандартизация подходов на масштабе - Дмитрий Салахутдинов, Купер (ex. СберМаркет)
На больших масштабах неминуемо встает вопрос унификации подходов и инструментов для снижения времени на разработку. Стандартизация дает возможность развернуть типовой сервис из шаблона за несколько минут и сразу начать решать задачи продукта, не тратя время…
🔥17👍5❤2👏2
В основе статьи десяток интервью с моими коллегами - стафф/принципал инженерами Купера.
Из статьи вы узнаете:
Статья написана с фокусом на карьерный рост и будет полезна senior-разработчикам.
Забегая вперед, скажу, что на следующей неделе выйдет ее продолжение с практическими советами куда и как развиваться в эту роль.
Приглашаю погрузиться в контекст, и разобраться, кто он - стафф инженер по ссылке.
Жду ваших комментариев, отзывов и предложений тут или на Хабре!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Карьерный рост из senior: кто такой staff-инженер?
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер» . У нас в компании это один из грейдов технической ветки развития инженеров, которую мы обобщенно...
❤16👍11🔥10
Всем привет! Вышло продолжение статьи, о стафф-инженерах, из которой вы узнаете:
- о сложностях, с которыми сталкиваются коллеги при переходе на эту роль, и как с ними справляться
- что мотивирует стафф-инженеров
- что и как прокачивать, если вы поняли, что хотите двигаться в эту сторону
Приятного чтения!
Буду рад комментариям, предложениям и обратной связи
https://habr.com/ru/companies/kuper/articles/857482/
- о сложностях, с которыми сталкиваются коллеги при переходе на эту роль, и как с ними справляться
- что мотивирует стафф-инженеров
- что и как прокачивать, если вы поняли, что хотите двигаться в эту сторону
Приятного чтения!
Буду рад комментариям, предложениям и обратной связи
https://habr.com/ru/companies/kuper/articles/857482/
Хабр
Карьерный рост из senior: как вырасти в staff-инженера
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер» . В первой части статьи я уже рассказывал , какими задачами занимаются стаффы и какие компетенции...
❤13🔥11👍1
Наверняка вы бываете на конференциях или смотрите записи докладов.
Обычно, пройдя сложный путь, спикеры делятся опытом реализации успешных проектов, чтобы помочь нам (слушателям) пройти его легче.
Не часто встретишь доклад про неудачные кейсы, как все сломалось, ничего не случиловь и прочий "не успешный неуспех".
⁉️Но отрицательный опыт - тоже опыт, да еще и самый дорогой. 😂
Отрефлексировать его - круто, и сможет не каждый! А рассказать про свой факап - это высший пилотаж.
Приглашаю на встречу с такими героями:
5 декабря в 19:00 в офисе Купера пройдет "Факап-митап"
Обычно, пройдя сложный путь, спикеры делятся опытом реализации успешных проектов, чтобы помочь нам (слушателям) пройти его легче.
Не часто встретишь доклад про неудачные кейсы, как все сломалось, ничего не случиловь и прочий "не успешный неуспех".
⁉️Но отрицательный опыт - тоже опыт, да еще и самый дорогой. 😂
Отрефлексировать его - круто, и сможет не каждый! А рассказать про свой факап - это высший пилотаж.
Приглашаю на встречу с такими героями:
5 декабря в 19:00 в офисе Купера пройдет "Факап-митап"
🔥12👍4
Привет! 🤚
Месяц назад мы частью команды Ruby-платформы Купера собрались в Московском офисе, чтобы вместе поработать над изучением проблемы OSS реализации GRPC-сервера для Ruby, которую мы используем.
🎬 И сняли из этого реалити-шоу, в стиле "один день из жизни..."
За день получилось:
- обсудить разные варианты и подходы к решению
- собрать их "на коленке"
- провести нагрузочное тестирование
- сравнить результаты
- выложить исследования на Github
- и сходить на обед с коллегами 🙂
А еще договорились онлайн с руководителем отдела о выкатке в фикса в продакшен.
На мой взгляд получилось интересно и содержательно, приоткрывает завесу "тайны" вокруг платформенной разработки и процессов в компании.
Приглашаю к просмотру на Youtube🍿 и жду ваших преложений и комментариев!
Месяц назад мы частью команды Ruby-платформы Купера собрались в Московском офисе, чтобы вместе поработать над изучением проблемы OSS реализации GRPC-сервера для Ruby, которую мы используем.
🎬 И сняли из этого реалити-шоу, в стиле "один день из жизни..."
За день получилось:
- обсудить разные варианты и подходы к решению
- собрать их "на коленке"
- провести нагрузочное тестирование
- сравнить результаты
- выложить исследования на Github
- и сходить на обед с коллегами 🙂
А еще договорились онлайн с руководителем отдела о выкатке в фикса в продакшен.
На мой взгляд получилось интересно и содержательно, приоткрывает завесу "тайны" вокруг платформенной разработки и процессов в компании.
Приглашаю к просмотру на Youtube
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - Kuper-Tech/ruby-grpc-research: GRPC server implementation research for Ruby
GRPC server implementation research for Ruby. Contribute to Kuper-Tech/ruby-grpc-research development by creating an account on GitHub.
🔥15❤6
Неделю назад дочитал художественную книгу Нила Стивенсона "Криптономикон". И пребываю в полном восторге, отчего хочу порекомендовать подписчикам!
Представьте, если бы Квентин Тарантино написал фантастический визионерский экшен-роман на основе исторических событий второй мировой войны, фокусируя внимание на завинчивающейся спирали противостояния и развития криптографии (шифровальная машина "Энигма") и криптоанализа (дешифровка сообщений), проводя параллели с современностью (1999 год), в которой увлеченные криптографией потомки участников войны строят IT-стартап в духе "Цифровой рай". Технические моменты автор поясняет мастерски вплетенными в повествования графиками и схемами.
Повествование сдобрено тонким чувством юмора, некоторые идеи даже спустя 25 лет удивляют, а сюжет настолько закручен, что ни страницы не будет скучно!
Перед тем, как решится на ~1000-страничное чтиво, рекомендую статью-обзор книги на Хабре.
Меня, книга навела на банальную мысль, о том, что "Война - это двигатель прогресса", и IT-индустрия и развитие компьютеров - тому подтверждение; а еще погрузила в исторический контекст развития криптографии.
Теперь хочу сходить в музей-криптографии, как буду в Москве. Кто был в музее, или читал книгу - поделитесь, пжс, впечатлениями.
#Reading #NonTechnical
Please open Telegram to view this post
VIEW IN TELEGRAM
Литрес
Криптономикон — Нил Стивенсон | Литрес
В период Второй мировой войны молодой математический гений Лоуренс Уотерхаус участвует во взломе немецких шифровальных систем. В наше время его внук Рэнди, компьютерный хакер, помогает построить авто…
👍14🔥3