👋Привет! Меня зовут Дима Салахутдинов, я - 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