Аутхентификация, мать его.
Все хотят микросервисы, пока не нужно решать проблемы аутентификации и авторизации между ними. Недавно приходилось начинать дизайнить систему и коннектить что угодно с чем угодно.
Что у нас есть из исходных данных
-- Система мониторинга
-- Свой бекенд с фронтендом, который может быть запущен где угодно, хоть в кубере, хоть на баре метале, но в любом случае -- это веб сервис
-- Саас платформа, на которой предыдущий сервис можно запустить и заэмбедить
Спасибо предыдущему работодателю за возможность разобраться в механизмах аутентификации и благо не нужно думать о MFA, passwordless authentication и подобных продвинутых техниках.
Во всех трех системах есть возможность использовать свои учетки, но скорее всего имеет смысл использовать СааС платформу как идентити провайдера(IdP)
В целом, систему мониторинга и наш сервис можно подключить к саас решению достаточно просто, автоматом сгенерить Oauth2 приложение, настроить его, сконфигурировать и чтобы пользователи коннектились по OIDC (Да, давайте напишем одну RFC, назовоем исплементации двумя разными словами, чтобы все сообщество запуталось нахер между OIDC и Oauth2. Разработчики в целом не разобрались в разнице между идентификацией, аутентификацией и авторизацией, а мы накинем еще).
Выглядит это достаточно просто и понятно. Даже пользователей можно будет без проблем перекидывать между разными поддоментами/системами просто либо шаря куки, либо шаря токен между ними и нужному сервису нужно будет просто валидировать этот токен и дальше уже по своим правилам пускать пользователя.
Но, когда дело доходит до RBAC или, скажем проще, до просто Access Control (они же обычные пермишны), то тут моск отключается у большиства людей, потому что разобраться как это имплементировать на нужном сервисе -- сложная задача, а еще нам нужно мапить роли, если упаси боже мы решили взять RBAC.
В чем проблема? Нашему сервису нужно использовать систему мониторинга. Чтобы использовать систему мониторинга -- нужно сгенерить пользователя и токен с нужными пермишнами. А чтобы сгенерить пользователя, нужно чтобы у запрашивающего актора были на это права.
А мы хотим просто создавать базы в кластере, кубер-шмубер-кококо и дать эту возможность всем пользователям. В итоге выходит проблема, что нужно систему мониторинга сконнектить с нашим бекендом так, чтобы у бекенда были всегда права сгенерить токены.
Какие тут есть у нас варианты?
-- Взять логин, пароль, урл до системы мониторинга и сохранить их куда-нибудь
-- Нахреначить SAML или что-нибудь подобное
-- Сконнектить их также по Oauth2, чтобы они ходили друг к другу не раскрывая креденшлы.
В любом случае, вне зависимости от того, что мы в итоге возьмем, нам нужно использовать сервис аккаунты, то есть типа не привязанные к человеку, потому что люди ненадежны. Они увольняются, спиваются, исчезают, умирают и если не будет нужных кредов -- то пиши пропало.
SAML и Oauth2 добавляют сложности, потому что нужно кодить и то и другое на тех двух системах и в итоге приходим к тому, что сохранить логин и пароль -- самое простое решение, верно?
Хрен там плавал. Если мы возьмем любую админскую учетку, то ее не надо сохранять к нам в сервис, просто потому что ее создал человек. Нужно сгенерить нового пользователя, который будет сервис аккаунтом и вот эти креды уже и сохранять.
А как сохранять? Ну явно не в плейн тексте, тут нужна либо зашифрованная база, либо тот же самый Vault.
Пароли -- самое вредное изобретение человечества. Очень жду когда придумают что-нибудь подобное FIDO2/WebAuthN но не привязанное к браузеру/вебу.
Все хотят микросервисы, пока не нужно решать проблемы аутентификации и авторизации между ними. Недавно приходилось начинать дизайнить систему и коннектить что угодно с чем угодно.
Что у нас есть из исходных данных
-- Система мониторинга
-- Свой бекенд с фронтендом, который может быть запущен где угодно, хоть в кубере, хоть на баре метале, но в любом случае -- это веб сервис
-- Саас платформа, на которой предыдущий сервис можно запустить и заэмбедить
Спасибо предыдущему работодателю за возможность разобраться в механизмах аутентификации и благо не нужно думать о MFA, passwordless authentication и подобных продвинутых техниках.
Во всех трех системах есть возможность использовать свои учетки, но скорее всего имеет смысл использовать СааС платформу как идентити провайдера(IdP)
В целом, систему мониторинга и наш сервис можно подключить к саас решению достаточно просто, автоматом сгенерить Oauth2 приложение, настроить его, сконфигурировать и чтобы пользователи коннектились по OIDC (Да, давайте напишем одну RFC, назовоем исплементации двумя разными словами, чтобы все сообщество запуталось нахер между OIDC и Oauth2. Разработчики в целом не разобрались в разнице между идентификацией, аутентификацией и авторизацией, а мы накинем еще).
Выглядит это достаточно просто и понятно. Даже пользователей можно будет без проблем перекидывать между разными поддоментами/системами просто либо шаря куки, либо шаря токен между ними и нужному сервису нужно будет просто валидировать этот токен и дальше уже по своим правилам пускать пользователя.
Но, когда дело доходит до RBAC или, скажем проще, до просто Access Control (они же обычные пермишны), то тут моск отключается у большиства людей, потому что разобраться как это имплементировать на нужном сервисе -- сложная задача, а еще нам нужно мапить роли, если упаси боже мы решили взять RBAC.
В чем проблема? Нашему сервису нужно использовать систему мониторинга. Чтобы использовать систему мониторинга -- нужно сгенерить пользователя и токен с нужными пермишнами. А чтобы сгенерить пользователя, нужно чтобы у запрашивающего актора были на это права.
А мы хотим просто создавать базы в кластере, кубер-шмубер-кококо и дать эту возможность всем пользователям. В итоге выходит проблема, что нужно систему мониторинга сконнектить с нашим бекендом так, чтобы у бекенда были всегда права сгенерить токены.
Какие тут есть у нас варианты?
-- Взять логин, пароль, урл до системы мониторинга и сохранить их куда-нибудь
-- Нахреначить SAML или что-нибудь подобное
-- Сконнектить их также по Oauth2, чтобы они ходили друг к другу не раскрывая креденшлы.
В любом случае, вне зависимости от того, что мы в итоге возьмем, нам нужно использовать сервис аккаунты, то есть типа не привязанные к человеку, потому что люди ненадежны. Они увольняются, спиваются, исчезают, умирают и если не будет нужных кредов -- то пиши пропало.
SAML и Oauth2 добавляют сложности, потому что нужно кодить и то и другое на тех двух системах и в итоге приходим к тому, что сохранить логин и пароль -- самое простое решение, верно?
Хрен там плавал. Если мы возьмем любую админскую учетку, то ее не надо сохранять к нам в сервис, просто потому что ее создал человек. Нужно сгенерить нового пользователя, который будет сервис аккаунтом и вот эти креды уже и сохранять.
А как сохранять? Ну явно не в плейн тексте, тут нужна либо зашифрованная база, либо тот же самый Vault.
Пароли -- самое вредное изобретение человечества. Очень жду когда придумают что-нибудь подобное FIDO2/WebAuthN но не привязанное к браузеру/вебу.
Что нам стоит запилить архитектуру?
Да, в общем-то, ничего. Подходы могут отличатся и вот примерно мои подходы к построению архитектуры, с течением карьеры.
1. О, вот тут прикольный подход. Давай попробуем. В итоге появился жирный монолит с кучей сервисов вокруг него, связанных редисом. Это была первая архитектура, которую построил сам, но ее можно было менять и мы даже разбивали монолит потихоньку, оставляя там только кор функционал
2. Стало понятно, что архитектуру нужно строить с нуля. Решили попробовать, в итоге получилось почти тоже самое, только чуть лучше
3. Зачем нам вообще что-то переизобретать? Давай брать как можно больше из опенсорса? Давай сначала будем описывать апиху, а потом уже интегрировать ее. В итоге, на интеграции было много интересных багов, дискуссий и нервов
4. Открылись Doc first, API first, API driven подходы, которые помогли решать проблемы, с которыми сталкивались пользуясь тремя пунктами выше
В итоге, спустя какое-то время потраченное на дизайн разных систем, выработались некоторые принципы
1. Начинать с требований. как функциональных, так и не функциональных.
2. Описывать худший сценарий и какие есть ограничения по комплаенсу или закону
3. Рисовать кучу разных диаграм, в зависимости от юзкейса и масштаба системы
4. Обсуждать это в группе, коллаборировать, выслушивать идеи. Будет идеально, если у вас в команде будет кто-то душный, который умеет хорошо челленджить архитектуру, уходя в очень глубокие детали
5. Ну и самое важное, делать небольшие и быстрые PoC, чтобы проверить идею.
Почему PoC важно? Это самая простая проверка реальностью. Потратить день или два, чтобы сделать простой PoC из говна и палок обычно экономит кучу времени, дает кучу инсайтов.
Ну и после того, как всё обсудили, все PoC сделали, то можно уже писать пропоузал и обсуждать его с большим количеством людей.
В целом, весь этот процесс занимает 1-2 месяца для более менее серьезного продукта. В процессе конечно можно бутстрапить проекты, собирать их вместе друг с другом, заниматься другим ресерчем.
Да, в общем-то, ничего. Подходы могут отличатся и вот примерно мои подходы к построению архитектуры, с течением карьеры.
1. О, вот тут прикольный подход. Давай попробуем. В итоге появился жирный монолит с кучей сервисов вокруг него, связанных редисом. Это была первая архитектура, которую построил сам, но ее можно было менять и мы даже разбивали монолит потихоньку, оставляя там только кор функционал
2. Стало понятно, что архитектуру нужно строить с нуля. Решили попробовать, в итоге получилось почти тоже самое, только чуть лучше
3. Зачем нам вообще что-то переизобретать? Давай брать как можно больше из опенсорса? Давай сначала будем описывать апиху, а потом уже интегрировать ее. В итоге, на интеграции было много интересных багов, дискуссий и нервов
4. Открылись Doc first, API first, API driven подходы, которые помогли решать проблемы, с которыми сталкивались пользуясь тремя пунктами выше
В итоге, спустя какое-то время потраченное на дизайн разных систем, выработались некоторые принципы
1. Начинать с требований. как функциональных, так и не функциональных.
2. Описывать худший сценарий и какие есть ограничения по комплаенсу или закону
3. Рисовать кучу разных диаграм, в зависимости от юзкейса и масштаба системы
4. Обсуждать это в группе, коллаборировать, выслушивать идеи. Будет идеально, если у вас в команде будет кто-то душный, который умеет хорошо челленджить архитектуру, уходя в очень глубокие детали
5. Ну и самое важное, делать небольшие и быстрые PoC, чтобы проверить идею.
Почему PoC важно? Это самая простая проверка реальностью. Потратить день или два, чтобы сделать простой PoC из говна и палок обычно экономит кучу времени, дает кучу инсайтов.
Ну и после того, как всё обсудили, все PoC сделали, то можно уже писать пропоузал и обсуждать его с большим количеством людей.
В целом, весь этот процесс занимает 1-2 месяца для более менее серьезного продукта. В процессе конечно можно бутстрапить проекты, собирать их вместе друг с другом, заниматься другим ресерчем.
Продолжая тему архитектур, хочу сказать, что мне очень нравится, как подходят к этому некоторые опенсорс компании/проекты. Глядя, как ведут дела Red Hat с их оператор фреймворком, или K8S, то там можно получить кучу материала для вдохновления.
К примеру, Operator Lifecycle Manager, который сам по себе удобный инструмент для установки и менежмента жизненного цикла оператора -- это большой монолит. Ребята начали проект RukPak, который станет частью ОЛМ в будущем, но туда перенесут все, что касается работы с бандлами, резолвом конфликтов и всем остальным. Для всяких аннонсов и более юзерфрендли документации, у них есть аккаунт на hackmd.io, где они всё описывают. Документация у них в папке docs внутри репо, что тоже удобно.
Neon -- это ребята, которые разбили простой монолит, который зовут Postgresql на два слоя compute и storage, все свои архитектурные решения описывали пользуясь RFC
А у кубера, есть отдельные SIG(Special Interest Group), и в них есть свои KEP(Kubernetes Enhacement Proposal). Все задокументировано.
Да, такие подходы отнимают кучу времени на то, чтобы всё это дело описать (один такой пропоузал я писал около пары недель, потратив еще шесть на ресерч и PoC), но из плюсов
1. Понятно, когда и почему были приняты решения
2. Все артефакты доступны для чтения любому интересующемуся человеку
3. Можно поучаствовать в дискуссиях вокруг архитектуры и на ранних этапах найти баги в ней
К примеру, Operator Lifecycle Manager, который сам по себе удобный инструмент для установки и менежмента жизненного цикла оператора -- это большой монолит. Ребята начали проект RukPak, который станет частью ОЛМ в будущем, но туда перенесут все, что касается работы с бандлами, резолвом конфликтов и всем остальным. Для всяких аннонсов и более юзерфрендли документации, у них есть аккаунт на hackmd.io, где они всё описывают. Документация у них в папке docs внутри репо, что тоже удобно.
Neon -- это ребята, которые разбили простой монолит, который зовут Postgresql на два слоя compute и storage, все свои архитектурные решения описывали пользуясь RFC
А у кубера, есть отдельные SIG(Special Interest Group), и в них есть свои KEP(Kubernetes Enhacement Proposal). Все задокументировано.
Да, такие подходы отнимают кучу времени на то, чтобы всё это дело описать (один такой пропоузал я писал около пары недель, потратив еще шесть на ресерч и PoC), но из плюсов
1. Понятно, когда и почему были приняты решения
2. Все артефакты доступны для чтения любому интересующемуся человеку
3. Можно поучаствовать в дискуссиях вокруг архитектуры и на ранних этапах найти баги в ней
Отвечу на вопросы, их скопилось немного.
Правда ли что когда начальнику не чего предложить сотруднику, он начинает втирать про "Мы одна семья"?
Да. Чаще всего неблагополучная.
Иногда руководители считают, что семеные отношения в рабочем коллективе — это окей. Но на самом деле, чаще всего это просто про экономию денег на оплате труда сотруднику.
У каждого может быть свой взгляд на печеньки и прочие плюшки в офисе, но проще просто это конвертировать в надбавку к зп и будет всем проще.
По опыту, когда все плюшки выражаются в виде какого-то бонуса к зп — это проще и понятнее, особенно когда видишь это в инвойсе разбивку, типа базовый оклад, wellness бонус, интернет и тому подобное.
Иной вариант — это чтобы просто оправдать не умение в рабочую этику и мирное общение.
В свободное время на работе открываю свои старые проекты и понимаю что полное говно и его надо переписать иначе не усну, и так каждые пол года. Нормально ли это?
Да. Нормально. Ты растёшь, понимаешь что хорошо и что плохо. Это будет тебя преследовать всю карьеру, особенно если ты поменяешь несколько стеков и парадигм программирования.
У меня также, особенно когда я работаю над одним и тем же проектом в течение долгого времени и открываю какие-то части спустя какое-то время.
Если открыть мои проекты, которым 5-7 лет, которые еще написаны на питоне, то там можно кучу разной дичи увидеть. Например вот, вот или вот
Но если ты понимаешь что это дичь и старешься исправить — это замечательно. Но еще более замечательно, когда ты поймешь, что в целом первая версия была вполне себе ок, а когда ты переписал ее, то ты сделал хуже
Правда ли что когда начальнику не чего предложить сотруднику, он начинает втирать про "Мы одна семья"?
Да. Чаще всего неблагополучная.
Иногда руководители считают, что семеные отношения в рабочем коллективе — это окей. Но на самом деле, чаще всего это просто про экономию денег на оплате труда сотруднику.
У каждого может быть свой взгляд на печеньки и прочие плюшки в офисе, но проще просто это конвертировать в надбавку к зп и будет всем проще.
По опыту, когда все плюшки выражаются в виде какого-то бонуса к зп — это проще и понятнее, особенно когда видишь это в инвойсе разбивку, типа базовый оклад, wellness бонус, интернет и тому подобное.
Иной вариант — это чтобы просто оправдать не умение в рабочую этику и мирное общение.
В свободное время на работе открываю свои старые проекты и понимаю что полное говно и его надо переписать иначе не усну, и так каждые пол года. Нормально ли это?
Да. Нормально. Ты растёшь, понимаешь что хорошо и что плохо. Это будет тебя преследовать всю карьеру, особенно если ты поменяешь несколько стеков и парадигм программирования.
У меня также, особенно когда я работаю над одним и тем же проектом в течение долгого времени и открываю какие-то части спустя какое-то время.
Если открыть мои проекты, которым 5-7 лет, которые еще написаны на питоне, то там можно кучу разной дичи увидеть. Например вот, вот или вот
Но если ты понимаешь что это дичь и старешься исправить — это замечательно. Но еще более замечательно, когда ты поймешь, что в целом первая версия была вполне себе ок, а когда ты переписал ее, то ты сделал хуже
Оффтопное, но не могу не написать.
Посмотрел тут я Черный Двор. Это фильм про Чёрный двор, который в квадрате Айни, Шота Руставели, Индустриальной (Джаманбаева), Орджоникидзе. В целом это про то, что происходило в Бишкеке, Кара Балте и других городах Кыргызстана и остальных городах пост совка во времена моего детства, юношества и где-то до 20 лет.
В 2002м году все пацаны смотрели Бригаду. В целом интересный сериал, который я часто пересматриваю, но меня как-то эта блатная романтика не зацепила, потому что я ее тупо не понял. Однако, когда Эркин Джаманбаев сказал или писал где-то, что проще относишься к жизни, когда стоишь один против толпы, то это как-то мне было понятно, когда читал это в 23+.
До 20 драк на районе было всё меньше и меньше, но у меня есть большая коллекция историй противостояния против ребят, пересмотревших бригаду.
В целом, для молодой аудитории я расскажу почему мне этот фильм зашел и просто голые факты за период 1998-2012 года:
1. Отец одного знакомого был убит на районе где-то в 2003м году, потому что его хотели просто грабануть
2. История, которая показана в сериале была на самом деле (Фильм на реальной истории, но не на событиях). Закончилась не так, как в сериале, но часть героев я знаю и я с ними рос на одном районе.
3. Когда мне было около 16 лет, то один школьник зарезал другого школьника, потому что второй грузит первого и буллил его. Первый лежал в РЦПЗ.
4. Несколько ребят повесились на фоне рекета и подобных штук
5. 61я школа постоянно дралась с 48й. Порта иногда дрались с джальскими. Вопрос ты с какого района означал желание попиздиться
6. Смотрящий района, с которым у меня был конфликт в итоге был убит. Отдельная история про два года веселой жизни на районе, где раз в неделю старались докапаться, а иногда приходилось и махать кулаками. Из всей той компашки часть сейчас сидит, часть умерла от передоза, часть была убита или покалечена и отдельная часть одумалась.
7. Сын маминой подруги был антигероем мема, потому что часто угонял тачки и у него не одна ходка и хз что у него с жизнью сейчас.
8. Найти труп где-то на районе и увидеть наряд милиции было чем-то плюс минус не вызывающем удивления в тот период времени.
Работа отличная. Хорошо что все жестокие сцены замазаны(Иногда там прям жесть-жесть и фильмы ужасов стоят в сторонке). Игра актёров отличная.
Радует отдельно, что фильм сразу начинается с жести. Там просто голая правда, без прикрас и романтизации. Как сказал герой Азиза Бейшеналиева: "У вас только один путь. Либо в морг, либо в тюрьму". В целом, спустя время, эта фраза подтверджается.
Сериал глянул на одном дыхании. Рася и все причастные молодцы. Надеюсь, что с оригинальными людьми, которые показаны в сериале сейчас всё хорошо и они живут честной и счастливой жизнью.
Актерский состав молодцы. Отыграли очень круто и погружение просто с первых секунд.
С черного двора я знаю 4х человек, которые вырвались и не пошли криминальной дорожкой. С портов (куда я переехал) еще человека три-пять.
Однозначно стоит смотреть олдам (30+), чтобы вспомнить как оно было и порадоваться, что это закончилось. Подросткам стоит глянуть чтобы не идти по этой дороге и благо, что в ту реальность прям не хочется погружаться, в отличие от Бригады.
Впечатлительным, душкам и зайкам смотреть не стоит, потому что там просто жесть, нищета, хреновые семьи, отсутствие любви, мат, жестокость и ничего святого :D
Посмотрели сериал? Что скажете? =)
ПС. Мы тут релиз сейчас закончим, и я начну опять писать про куберы и всё остальное)
Посмотрел тут я Черный Двор. Это фильм про Чёрный двор, который в квадрате Айни, Шота Руставели, Индустриальной (Джаманбаева), Орджоникидзе. В целом это про то, что происходило в Бишкеке, Кара Балте и других городах Кыргызстана и остальных городах пост совка во времена моего детства, юношества и где-то до 20 лет.
В 2002м году все пацаны смотрели Бригаду. В целом интересный сериал, который я часто пересматриваю, но меня как-то эта блатная романтика не зацепила, потому что я ее тупо не понял. Однако, когда Эркин Джаманбаев сказал или писал где-то, что проще относишься к жизни, когда стоишь один против толпы, то это как-то мне было понятно, когда читал это в 23+.
До 20 драк на районе было всё меньше и меньше, но у меня есть большая коллекция историй противостояния против ребят, пересмотревших бригаду.
В целом, для молодой аудитории я расскажу почему мне этот фильм зашел и просто голые факты за период 1998-2012 года:
1. Отец одного знакомого был убит на районе где-то в 2003м году, потому что его хотели просто грабануть
2. История, которая показана в сериале была на самом деле (Фильм на реальной истории, но не на событиях). Закончилась не так, как в сериале, но часть героев я знаю и я с ними рос на одном районе.
3. Когда мне было около 16 лет, то один школьник зарезал другого школьника, потому что второй грузит первого и буллил его. Первый лежал в РЦПЗ.
4. Несколько ребят повесились на фоне рекета и подобных штук
5. 61я школа постоянно дралась с 48й. Порта иногда дрались с джальскими. Вопрос ты с какого района означал желание попиздиться
6. Смотрящий района, с которым у меня был конфликт в итоге был убит. Отдельная история про два года веселой жизни на районе, где раз в неделю старались докапаться, а иногда приходилось и махать кулаками. Из всей той компашки часть сейчас сидит, часть умерла от передоза, часть была убита или покалечена и отдельная часть одумалась.
7. Сын маминой подруги был антигероем мема, потому что часто угонял тачки и у него не одна ходка и хз что у него с жизнью сейчас.
8. Найти труп где-то на районе и увидеть наряд милиции было чем-то плюс минус не вызывающем удивления в тот период времени.
Работа отличная. Хорошо что все жестокие сцены замазаны(Иногда там прям жесть-жесть и фильмы ужасов стоят в сторонке). Игра актёров отличная.
Радует отдельно, что фильм сразу начинается с жести. Там просто голая правда, без прикрас и романтизации. Как сказал герой Азиза Бейшеналиева: "У вас только один путь. Либо в морг, либо в тюрьму". В целом, спустя время, эта фраза подтверджается.
Сериал глянул на одном дыхании. Рася и все причастные молодцы. Надеюсь, что с оригинальными людьми, которые показаны в сериале сейчас всё хорошо и они живут честной и счастливой жизнью.
Актерский состав молодцы. Отыграли очень круто и погружение просто с первых секунд.
С черного двора я знаю 4х человек, которые вырвались и не пошли криминальной дорожкой. С портов (куда я переехал) еще человека три-пять.
Однозначно стоит смотреть олдам (30+), чтобы вспомнить как оно было и порадоваться, что это закончилось. Подросткам стоит глянуть чтобы не идти по этой дороге и благо, что в ту реальность прям не хочется погружаться, в отличие от Бригады.
Впечатлительным, душкам и зайкам смотреть не стоит, потому что там просто жесть, нищета, хреновые семьи, отсутствие любви, мат, жестокость и ничего святого :D
Посмотрели сериал? Что скажете? =)
ПС. Мы тут релиз сейчас закончим, и я начну опять писать про куберы и всё остальное)
Google Maps
Find local businesses, view maps and get driving directions in Google Maps.
Возвращаясь к айтишному.
Последние полгода были интенсивными и интересными. Так получилось, что тот продукт, который я делал решили вывести в отдельный продукт и вокруг этого всего было много разной работы.
Мы скоро релизнемся в паблик с закрытым полным циклом и всеми готовыми образами и даже какой-то документацией. Даже с тем, что можно будет пощупать, покрутить, поковырять, если у вас есть где-то какой-то кубер класстер.
Доки на архитектуру пока нет, потому что как обычно бывает, всегда есть куча мелких вещей и багов, которые надо починить перед релизом.
Так получилось, что у нас было два внутренних релиза, которые мы релизили в пятницу вечером и недавно у нас даже было разделение на два лагеря. Одни были за релизы в пятницу, другие были против.
Учитывая, что продукт всё равно не будут деплоить в пятницу то в нашем случае в пятницу релизить можно. Да и в целом, я любитель подеплоить в пятницу, потому что это показатель того, как хорошо у вас устроено качество, процессы разработки и в каком состоянии система.
За это время я даже смог прочитать несколько книг
-- Переиздание программиста прагматика спустя 20 лет
-- Staff Engineer. A leadership beyond management ladder.
-- Перечитал книги Жоко Виллинка (Discipline equals freedom & Extreme ownership)
Сейчас на очереди Non-violent communication.
Вообще о чем написать? Какие предложения? Как часто выкидывать посты и на какую тему?
Последние полгода были интенсивными и интересными. Так получилось, что тот продукт, который я делал решили вывести в отдельный продукт и вокруг этого всего было много разной работы.
Мы скоро релизнемся в паблик с закрытым полным циклом и всеми готовыми образами и даже какой-то документацией. Даже с тем, что можно будет пощупать, покрутить, поковырять, если у вас есть где-то какой-то кубер класстер.
Доки на архитектуру пока нет, потому что как обычно бывает, всегда есть куча мелких вещей и багов, которые надо починить перед релизом.
Так получилось, что у нас было два внутренних релиза, которые мы релизили в пятницу вечером и недавно у нас даже было разделение на два лагеря. Одни были за релизы в пятницу, другие были против.
Учитывая, что продукт всё равно не будут деплоить в пятницу то в нашем случае в пятницу релизить можно. Да и в целом, я любитель подеплоить в пятницу, потому что это показатель того, как хорошо у вас устроено качество, процессы разработки и в каком состоянии система.
За это время я даже смог прочитать несколько книг
-- Переиздание программиста прагматика спустя 20 лет
-- Staff Engineer. A leadership beyond management ladder.
-- Перечитал книги Жоко Виллинка (Discipline equals freedom & Extreme ownership)
Сейчас на очереди Non-violent communication.
Вообще о чем написать? Какие предложения? Как часто выкидывать посты и на какую тему?
Кто релизится в пятницу -- тот не лох 😂
Пятничные релизы часто почему-то не любят люди, потому что впереди выходные и если что-то сломается, то будут выходные на то, чтобы всё починить.
Однако, если команда может релизнуться в пятницу -- значит она не боится этого релиза и это значит, что всё хорошо с процессами разработки и тестирования.
Отвечая на комментарий под предыдущим постом мы релизнули Everest. Это система для того, чтобы сделать Private DBaaS поверх кубера. Доки доступны тут https://docs.percona.com/everest/
На следующей неделе будет контент в целом с описанием архитектуры, решений и прочих вещей, а пока можно потыкать и поиграть.
PS. Можно на локалхосте поковырять с посощью k3d и вот этой инструкцией. Немного мануальных шагов, но всё остальное будет автоматически установлено.
В следующих постах я распишу технические кишки чуть подробнее и думаю это займет пару больших постов как минимум. Может оказаться, что будет интересно
Пятничные релизы часто почему-то не любят люди, потому что впереди выходные и если что-то сломается, то будут выходные на то, чтобы всё починить.
Однако, если команда может релизнуться в пятницу -- значит она не боится этого релиза и это значит, что всё хорошо с процессами разработки и тестирования.
Отвечая на комментарий под предыдущим постом мы релизнули Everest. Это система для того, чтобы сделать Private DBaaS поверх кубера. Доки доступны тут https://docs.percona.com/everest/
На следующей неделе будет контент в целом с описанием архитектуры, решений и прочих вещей, а пока можно потыкать и поиграть.
PS. Можно на локалхосте поковырять с посощью k3d и вот этой инструкцией. Немного мануальных шагов, но всё остальное будет автоматически установлено.
В следующих постах я распишу технические кишки чуть подробнее и думаю это займет пару больших постов как минимум. Может оказаться, что будет интересно
Так получилось, что в мае у нас был пивот и мы решили поменять все планы и начать разработку нового продукта.
С одной стороны, когда Эверест был частью PMM (Percona Monitoring and Management) это было логично, что DBaaS фичи -- это часть менеджмента. Но было непонятно как поженить User Experience этих двух продуктов, учитывая что PMM всё таки заточен больше на мониторинг.
У нас было несколько проблем с PMM
-- Из-за того, что это было web based решение, а установка всех компонентов в худшем случае могла занять до 5-10 минут, то у нас были некоторые баги с этим. Да, мы делали процесс максимально повторяемым, но контроля таки было мало и в итоге кубер кластер мог зависнуть в Provisioning стейте
-- Помимо этого, для установки всех компонентов (а нам надо ставить OLM, устанавливать каталог, ставить все остальные операторы, конфигурить мониторинг), то нам требовалась очень большая кластер роль для кубера ради одноразовой операции
-- Бекапы и ресторы было сделать сложно, учитывая что в PMM есть часть функционала вокруг этого, которая реализована для bare-metal со своей логикой и хранением метаданных, то добавить кубер было прям задачей со звездочкой.
-- UX в целом страдал, потому что это было спрятано как фича в tech preview, которую еще и найти надо.
Благо, что в начале года мы делали мелкие шаги по выносу в отдельный продукт. Думали над архитектурой и UX, обсуждали как сделать те или иные вещи удобнее и понятнее.
Спустя пару Proof of Concept мы таки пришли к выводу, что нам нужен свой бекенд и CLI.
Основная CLI -- провижионить кубер класстер и ставить все нужные операторы и компоненты, которые нам нужны для нормальной работы продукта. В течение этого процесса создается сервис аккаунт в нужном неймспейсе с лимитированным списком пермишнов, которые как раз нужны для нормальной работы продукта.
CLI помог решить несколько проблем. Во-первых мы стали следовать least privilege принципу. Во-вторых, процесс установки можно сделать синхронным с понятным фидбеком пользователю что сейчас происходит с кубер класстером и процессом провижионинга.
CLI умеет доставлять отдельные операторы, включать или выключать мониторинг и для установки мы сделали быстрое решение -- это install скрипт.
Это не единственное принятое архитектурное решение и дальше расскажу про бекенд
С одной стороны, когда Эверест был частью PMM (Percona Monitoring and Management) это было логично, что DBaaS фичи -- это часть менеджмента. Но было непонятно как поженить User Experience этих двух продуктов, учитывая что PMM всё таки заточен больше на мониторинг.
У нас было несколько проблем с PMM
-- Из-за того, что это было web based решение, а установка всех компонентов в худшем случае могла занять до 5-10 минут, то у нас были некоторые баги с этим. Да, мы делали процесс максимально повторяемым, но контроля таки было мало и в итоге кубер кластер мог зависнуть в Provisioning стейте
-- Помимо этого, для установки всех компонентов (а нам надо ставить OLM, устанавливать каталог, ставить все остальные операторы, конфигурить мониторинг), то нам требовалась очень большая кластер роль для кубера ради одноразовой операции
-- Бекапы и ресторы было сделать сложно, учитывая что в PMM есть часть функционала вокруг этого, которая реализована для bare-metal со своей логикой и хранением метаданных, то добавить кубер было прям задачей со звездочкой.
-- UX в целом страдал, потому что это было спрятано как фича в tech preview, которую еще и найти надо.
Благо, что в начале года мы делали мелкие шаги по выносу в отдельный продукт. Думали над архитектурой и UX, обсуждали как сделать те или иные вещи удобнее и понятнее.
Спустя пару Proof of Concept мы таки пришли к выводу, что нам нужен свой бекенд и CLI.
Основная CLI -- провижионить кубер класстер и ставить все нужные операторы и компоненты, которые нам нужны для нормальной работы продукта. В течение этого процесса создается сервис аккаунт в нужном неймспейсе с лимитированным списком пермишнов, которые как раз нужны для нормальной работы продукта.
CLI помог решить несколько проблем. Во-первых мы стали следовать least privilege принципу. Во-вторых, процесс установки можно сделать синхронным с понятным фидбеком пользователю что сейчас происходит с кубер класстером и процессом провижионинга.
CLI умеет доставлять отдельные операторы, включать или выключать мониторинг и для установки мы сделали быстрое решение -- это install скрипт.
Это не единственное принятое архитектурное решение и дальше расскажу про бекенд
Бекенд.
Основная боль разработки была в перекладывании жсонов с места на место. Мы получили с фронта один жсон, покрутили и повалидировали его, собрали из этого жсона другой жсон, который закинули в кубер кластер и проверили статусы ответа.
В целом ничего нормального, кроме того, что в целом весь бекенд состоит из этой логики.
Появилась гипотеза проксировать специфичные запросы в кубер с фронта или как-то заэкспоузить кубер класстер на фронт.
Однако, нельзя так просто взять и заэкспоузить апиху кубера на фронт, потому как будут проблемы с CORS, но запроксировать ее можно и для этого в Go есть
Первый Proof of Concept был вокруг того, чтобы сделать эту проксю, попробовать подцепить фронтовое приложение и посмотреть как оно будет работать. В целом достаточно просто и в первой версии вся куберовская апиха была доступна для фронта.
Однако, когда мы начали дизайнить рестовые эндпоинты, дизайн собственных эндпоинтов отличался от куберовских и появилась идея для другого PoC. Суть в том, что по-сути нам нужно выдать на фронт апиху, которую регистрирует в кубере наш оператор.
Во время разработки оператора всегда генерируется openAPI спецификация для нужного CRD и появилась идея просто взять эту спецификацию и задизайнить свои эндпоинты используя сгенерированную спеку как пейлоад. А на хендлере можно и логику с проксированием запилить.
В итоге, получилась вполне понятная апиха с разным пейлоадом и доку можно потыкать тут.
Под капотом спека и пример DatabaseCluster, а реализация тут
Этот подход помог нам избавится от кучи ненужной работы и ненужного (пока что) уровня абстракции.
Плюс, мы можем спокойно повалидировать то, что пришло в пейлоаде и выдать осмысленную ошибку до отправки в кубер кластер.
Ну а в следующем посте соберу всю картину воедино.
Основная боль разработки была в перекладывании жсонов с места на место. Мы получили с фронта один жсон, покрутили и повалидировали его, собрали из этого жсона другой жсон, который закинули в кубер кластер и проверили статусы ответа.
В целом ничего нормального, кроме того, что в целом весь бекенд состоит из этой логики.
Появилась гипотеза проксировать специфичные запросы в кубер с фронта или как-то заэкспоузить кубер класстер на фронт.
Однако, нельзя так просто взять и заэкспоузить апиху кубера на фронт, потому как будут проблемы с CORS, но запроксировать ее можно и для этого в Go есть
httputil.SingleHostReverseProxy, с которыми вполне удобно работать.Первый Proof of Concept был вокруг того, чтобы сделать эту проксю, попробовать подцепить фронтовое приложение и посмотреть как оно будет работать. В целом достаточно просто и в первой версии вся куберовская апиха была доступна для фронта.
Однако, когда мы начали дизайнить рестовые эндпоинты, дизайн собственных эндпоинтов отличался от куберовских и появилась идея для другого PoC. Суть в том, что по-сути нам нужно выдать на фронт апиху, которую регистрирует в кубере наш оператор.
Во время разработки оператора всегда генерируется openAPI спецификация для нужного CRD и появилась идея просто взять эту спецификацию и задизайнить свои эндпоинты используя сгенерированную спеку как пейлоад. А на хендлере можно и логику с проксированием запилить.
В итоге, получилась вполне понятная апиха с разным пейлоадом и доку можно потыкать тут.
Под капотом спека и пример DatabaseCluster, а реализация тут
Этот подход помог нам избавится от кучи ненужной работы и ненужного (пока что) уровня абстракции.
Плюс, мы можем спокойно повалидировать то, что пришло в пейлоаде и выдать осмысленную ошибку до отправки в кубер кластер.
Ну а в следующем посте соберу всю картину воедино.
Ну и как вообще Эверест выглядит изнутри?
Пока пишется документация на сайт с объяснением всех компонентов, запощу сюда архитектуру текстом. Может быть даже будет полезно кому-то.
1. everest-operator. Основная логика вокруг day 1/day 2 операций реализована в операторе. Он предоставляет свою CR, в которой есть всё нужное и оно унифицировано для трех технологий: Postgres, MySQL, Mongo. Плюс всякие удобности для UX и дополнительная автоматизация лежит там. Некоторые правила валидации реализованы на стороне оператора, но пока большую часть приходится делать на бекенде, потому что ждём когда 1.24 таки умрёт везде, потому что в 1.25 появились validation rules
2. everest-backend. Это апиха для фронта, которая очень простая и особо не содержит никакой логики для day 1/ day2 операций. Правда он создает какие-то нужные ресурсы в кубер класстере. Например объекты для хранения конфигурации монитооринга или бекапов. Большая часть эндпоинтов -- это простая прокся до кубера, иногда с небольшой кастомной логикой перед проксированием
3. CLI, который занимается установкой Эвереста и всеми SREшными делами. В планах вроде есть достигнуть паритета с WebUI, чтобы можно было управлять кластерами баз данных и подобными вещами. Он ставит OLM, Everest Catalog, все нужные операторы, конфигурирует и доставляет мониторинг кубер кластера.
4. OLM (Operator Lifecycle Manager). Оператор, который устанавливает другие операторы. Ставит дополниительно кучу дополнительных удобных вещей. Информацию об операторах забирает из Каталога
5. Everest-Catalog. Это просто хранилище метаданных о доступных операторов для установки.
Версионирование.
Хоть мы пока не поддерживаем автообновление, но мы можем без проблем сделать его в следующих релизах. Какие были приняты решения
1. Мы версионируем CLI, Backend, Frontend, Operator и Каталог релизным тегом и пушим всё на докерхаб
2. Во время апгрейда эвереста нужно поменять каталогсорс в кубере и обновить версию. Это позволяет нам шипить поддерживаемые операторы и быть уверенным, что в 0.3 люди не получат операторы с 0.4. Из всего версионирования именно эта задача была самой сложной, потому как со всеми остальными компонентами всё более менее понятно.
Процесс апгрейда
Если мы релизнули новую версию Эвереста, то пользователю нужно выкачать последнюю версию
1. Спросить и обновить OLM в кубер класстере
2. Обновить каталог сорс и подождать когда будет доступна новая версия каталога в кластере
3. Предложить обновить все операторы и если пользователь согласен, то обновить их. Сам процесс обновления операторов простой и его можно сделать без каких-либо проблем, потому как нет никаких сайд эффектов
4. Обновить версии в композе или в кубер манифесте и выкачать новые образы
5. Обновить конфигурацию мониторинга
В целом, хоть продукт пока еще в альфе, но это вполне себе хороший старт. Правда пока не понятно как запилить IAM, RBAC фичи, но мы точно в следующем квартале что-то придумаем.
Пока пишется документация на сайт с объяснением всех компонентов, запощу сюда архитектуру текстом. Может быть даже будет полезно кому-то.
1. everest-operator. Основная логика вокруг day 1/day 2 операций реализована в операторе. Он предоставляет свою CR, в которой есть всё нужное и оно унифицировано для трех технологий: Postgres, MySQL, Mongo. Плюс всякие удобности для UX и дополнительная автоматизация лежит там. Некоторые правила валидации реализованы на стороне оператора, но пока большую часть приходится делать на бекенде, потому что ждём когда 1.24 таки умрёт везде, потому что в 1.25 появились validation rules
2. everest-backend. Это апиха для фронта, которая очень простая и особо не содержит никакой логики для day 1/ day2 операций. Правда он создает какие-то нужные ресурсы в кубер класстере. Например объекты для хранения конфигурации монитооринга или бекапов. Большая часть эндпоинтов -- это простая прокся до кубера, иногда с небольшой кастомной логикой перед проксированием
3. CLI, который занимается установкой Эвереста и всеми SREшными делами. В планах вроде есть достигнуть паритета с WebUI, чтобы можно было управлять кластерами баз данных и подобными вещами. Он ставит OLM, Everest Catalog, все нужные операторы, конфигурирует и доставляет мониторинг кубер кластера.
4. OLM (Operator Lifecycle Manager). Оператор, который устанавливает другие операторы. Ставит дополниительно кучу дополнительных удобных вещей. Информацию об операторах забирает из Каталога
5. Everest-Catalog. Это просто хранилище метаданных о доступных операторов для установки.
Версионирование.
Хоть мы пока не поддерживаем автообновление, но мы можем без проблем сделать его в следующих релизах. Какие были приняты решения
1. Мы версионируем CLI, Backend, Frontend, Operator и Каталог релизным тегом и пушим всё на докерхаб
2. Во время апгрейда эвереста нужно поменять каталогсорс в кубере и обновить версию. Это позволяет нам шипить поддерживаемые операторы и быть уверенным, что в 0.3 люди не получат операторы с 0.4. Из всего версионирования именно эта задача была самой сложной, потому как со всеми остальными компонентами всё более менее понятно.
Процесс апгрейда
Если мы релизнули новую версию Эвереста, то пользователю нужно выкачать последнюю версию
everestctl и в идеале запустить что-то типа everestctl upgrade. Эта команда должна через интерактивный процесс сделать следующее1. Спросить и обновить OLM в кубер класстере
2. Обновить каталог сорс и подождать когда будет доступна новая версия каталога в кластере
3. Предложить обновить все операторы и если пользователь согласен, то обновить их. Сам процесс обновления операторов простой и его можно сделать без каких-либо проблем, потому как нет никаких сайд эффектов
4. Обновить версии в композе или в кубер манифесте и выкачать новые образы
5. Обновить конфигурацию мониторинга
В целом, хоть продукт пока еще в альфе, но это вполне себе хороший старт. Правда пока не понятно как запилить IAM, RBAC фичи, но мы точно в следующем квартале что-то придумаем.
Staff Engineer: Leadership beyond the management track
Небольшие заметки про книгу.
Обычно, когда опыта у разработчика 5, 7 или больше 10 лет и при этом он сеньер как по выслуге лет, так и по подходам, майндсету и подобным вещам. Становится непонятно куда вообще расти дальше и где больше денег можно взять за свои скиллы.
Естьдва стула три карьерных трека:
1. Уход в пипл менеджеры
2. Уход в архитекторы
3. Уход в принципалы
Менеджерский трек не всем зайдёт по разным причинам. Мне не зашло, потому что я люблю что-то программировать, решать задачи и подобное. А люди... Люди они сложные, непонятные и вообще непредсказуемые в отличие от кода/железок/систем.
Архитектурный трек это чаще всего про то, чтобы думать долго, описать всё это на бумаге и диаграмах (очень утрировано) и мыслить как всё это барахло, которое пишется погромистами будет работать в масштабах организации
Принципалы. Это вообще хрен пойми что за люди.
Книжка оказалась полезной и наверное будет настольной в ближайшее время. Staff+ инженер включает в себя следующие роли: Staff, Architect, Principal. Разница только в области, которую нужно грести.
В книге рассказывается что эти роли разные в разных компаниях (да неужели) и что от места к месту тайтл может быть разным.
В отличие от сеньера, staff это где-то плюс 20% к зп но если кратко посмотреть и попробовать описать -- это что-то вроде техлида (а у техлида есть ток техническое лидерство и нет пипл менежмента). Только техлидить нужно несколько проектов/комманд
Книга полезная как для общего развития, так и хорошая настольная для людей, которые решили идти по этому пути.
А я пока хз стоит ли идти в эту ветку или нет. В целом техлидить/сеньорить нормально
Небольшие заметки про книгу.
Обычно, когда опыта у разработчика 5, 7 или больше 10 лет и при этом он сеньер как по выслуге лет, так и по подходам, майндсету и подобным вещам. Становится непонятно куда вообще расти дальше и где больше денег можно взять за свои скиллы.
Есть
1. Уход в пипл менеджеры
2. Уход в архитекторы
3. Уход в принципалы
Менеджерский трек не всем зайдёт по разным причинам. Мне не зашло, потому что я люблю что-то программировать, решать задачи и подобное. А люди... Люди они сложные, непонятные и вообще непредсказуемые в отличие от кода/железок/систем.
Архитектурный трек это чаще всего про то, чтобы думать долго, описать всё это на бумаге и диаграмах (очень утрировано) и мыслить как всё это барахло, которое пишется погромистами будет работать в масштабах организации
Принципалы. Это вообще хрен пойми что за люди.
Книжка оказалась полезной и наверное будет настольной в ближайшее время. Staff+ инженер включает в себя следующие роли: Staff, Architect, Principal. Разница только в области, которую нужно грести.
В книге рассказывается что эти роли разные в разных компаниях (да неужели) и что от места к месту тайтл может быть разным.
В отличие от сеньера, staff это где-то плюс 20% к зп но если кратко посмотреть и попробовать описать -- это что-то вроде техлида (а у техлида есть ток техническое лидерство и нет пипл менежмента). Только техлидить нужно несколько проектов/комманд
Книга полезная как для общего развития, так и хорошая настольная для людей, которые решили идти по этому пути.
А я пока хз стоит ли идти в эту ветку или нет. В целом техлидить/сеньорить нормально
Non-violent communication.
Наконец дошли руки начать читать Non-violent communication. Книга хороша и понравилась вот эта мысль в самом начале книги
As NVC replaces our old patterns of defending, withdrawing, or attacking in the face of jugment and criticism, we come to perceive ourselves and others, as well as our intentions and relationships, in a new light.
Вообще с темой миролюбивой (ненасильственной) коммуникации впервые я столкнулся, когда учился менеджменту в Стратоплане. Правда, там было больше про безоценочное общение, чем про сами практики NVC, но всё же, этот курс прокачал коммуникацию достаточно хорошо.
Если кратко про безоценочность, то там есть несколько вариантов
Идти в сторону фактов и уходить от оценок и обобщений.
Хорошая штука, которая в целом поможет сделать коммуникацию с вашей стороны более удобной для слушателя. Два примера:
-- Использование этого подхода является общей практикой и используется многими компаниями
-- Мы не сможем заделиверить этот скоуп в этом релизе, потому что эта проблема займет неделю на починку, плюс еще какое-то время на QA, но мы можем урезать скоуп и попробовать решить другую проблему и оно в целом не идеально, но решает проблемы пользователей (Да, надо заменить слова курсивом на факты и всё будет вполне себе лучше для понимания)
Вообще, предлагать опции заранее, чтобы было из чего выбрать -- это лучшее, что можно сделать в коммуникации с менеджером (проектным, продуктовым, инжиниринг) и это делает коммуникацию с вами в разы лучше и короче. Ведь не нужно задавать кучу уточняющих вопросов в первом случае.
Фокус на проблеме, а не на человеке
Хорошая вещь, которая помогает как раз таки выключить механизмы защиты и сфокусироваться на обсуждении проблемы с которой столкнулся человек, а не на обсуждении самого человека, что как раз таки включит эти все механизмы.
В любом случае, читать книгу я начал и поделюсь в следующих постах чем-то интересным
Наконец дошли руки начать читать Non-violent communication. Книга хороша и понравилась вот эта мысль в самом начале книги
As NVC replaces our old patterns of defending, withdrawing, or attacking in the face of jugment and criticism, we come to perceive ourselves and others, as well as our intentions and relationships, in a new light.
Вообще с темой миролюбивой (ненасильственной) коммуникации впервые я столкнулся, когда учился менеджменту в Стратоплане. Правда, там было больше про безоценочное общение, чем про сами практики NVC, но всё же, этот курс прокачал коммуникацию достаточно хорошо.
Если кратко про безоценочность, то там есть несколько вариантов
Идти в сторону фактов и уходить от оценок и обобщений.
Хорошая штука, которая в целом поможет сделать коммуникацию с вашей стороны более удобной для слушателя. Два примера:
-- Использование этого подхода является общей практикой и используется многими компаниями
-- Мы не сможем заделиверить этот скоуп в этом релизе, потому что эта проблема займет неделю на починку, плюс еще какое-то время на QA, но мы можем урезать скоуп и попробовать решить другую проблему и оно в целом не идеально, но решает проблемы пользователей (Да, надо заменить слова курсивом на факты и всё будет вполне себе лучше для понимания)
Вообще, предлагать опции заранее, чтобы было из чего выбрать -- это лучшее, что можно сделать в коммуникации с менеджером (проектным, продуктовым, инжиниринг) и это делает коммуникацию с вами в разы лучше и короче. Ведь не нужно задавать кучу уточняющих вопросов в первом случае.
Фокус на проблеме, а не на человеке
Хорошая вещь, которая помогает как раз таки выключить механизмы защиты и сфокусироваться на обсуждении проблемы с которой столкнулся человек, а не на обсуждении самого человека, что как раз таки включит эти все механизмы.
В любом случае, читать книгу я начал и поделюсь в следующих постах чем-то интересным
Страданий псто.
Решил я тут попробовать сбилдить на своем маке с arm процом парочку C++ проектов, почитать их код и вообще посмотреть на внутряковые реализации парочки баз данных: Postgres и Mongo.
Последний раз я компиляцией и подобными вещами занимался в году 2009м, когда ковырял TrinityCore или сидел на Gentoo.
Кажется, что мало что поменялось за это время по экосистеме C++. Ниже просто вопросы от человека, который хочет вкатиться в C++ в 2023.
1. Почему нет никакого менеджера зависимостей, чтобы можно было добавить их как-то автоматом и не складировать это в third_party. В Go от этого избавились с помощью модулей. В Python был pip с кучей оберток вокруг него. В php есть композер.
2. Выбрать редактор текста, который может поддерживать основные три инструмента вокруг автоматизации -- боль. Clion не поддерживает Scons, VSCode не может найти инклуды в includePath, пока качаю XCode
3. Линкеров туева хуча. Gold, lld, bfd, clang, clang++ и попробуй найти тот, который заработает на маке для его Mach-O. Gold, lld только для ELF. После перебора вроде как стало понятно, что можно использовать clang и оно даже будет работать. Bfd жрет кучу памяти и тормозит.
4. Но не особо долго, потому что оказывается нужен еще llvm, добавив который появились ошибки компиляции, которые решаются даунгрейдом SDK с 14 на 13. А как это сделать в Scons я пока не нашел, но решил скачать XCode
5. Для Cmake это было сделать просто через
Кажется зря я забросил C++ лет цать назад. Сейчас вообще фиг разберешься в экосистеме.
Решил я тут попробовать сбилдить на своем маке с arm процом парочку C++ проектов, почитать их код и вообще посмотреть на внутряковые реализации парочки баз данных: Postgres и Mongo.
Последний раз я компиляцией и подобными вещами занимался в году 2009м, когда ковырял TrinityCore или сидел на Gentoo.
Кажется, что мало что поменялось за это время по экосистеме C++. Ниже просто вопросы от человека, который хочет вкатиться в C++ в 2023.
1. Почему нет никакого менеджера зависимостей, чтобы можно было добавить их как-то автоматом и не складировать это в third_party. В Go от этого избавились с помощью модулей. В Python был pip с кучей оберток вокруг него. В php есть композер.
2. Выбрать редактор текста, который может поддерживать основные три инструмента вокруг автоматизации -- боль. Clion не поддерживает Scons, VSCode не может найти инклуды в includePath, пока качаю XCode
3. Линкеров туева хуча. Gold, lld, bfd, clang, clang++ и попробуй найти тот, который заработает на маке для его Mach-O. Gold, lld только для ELF. После перебора вроде как стало понятно, что можно использовать clang и оно даже будет работать. Bfd жрет кучу памяти и тормозит.
4. Но не особо долго, потому что оказывается нужен еще llvm, добавив который появились ошибки компиляции, которые решаются даунгрейдом SDK с 14 на 13. А как это сделать в Scons я пока не нашел, но решил скачать XCode
5. Для Cmake это было сделать просто через
set(CMAKE_OSX_SYSROOT "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk") Кажется зря я забросил C++ лет цать назад. Сейчас вообще фиг разберешься в экосистеме.
Вайлдберрис — контора пидорасов.
Нет, не хочу тут оскорбить геев и ЛГБТ сообщество. Пидорасы они по майндсету и по подходам к жизни.
Приложение у них написано людьми, которые ненавидят людей и до поддержки хрен достучишься.
Решил заказать себе робот пылесос, регнулся в приложении и долго чесал репу что значит itn и еще какое-то слово, которое означает отчество.
Вроде прошел этот квест и решил пойти дальше и наконец оформить покупку. Добавил карту жму оплатить и мне говорит что банк неизвестен, но деньги списывают.
В итоге, списали два раза деньги, хрен отменишь заказы, в доставках нет ничего и хрен найдешь поддержку.
А на пункте выдачи особо ничего не подскажут, потому что они выдают товар.
Штош, буду ждать возврата денег, если вернут их конечно.
Нет, не хочу тут оскорбить геев и ЛГБТ сообщество. Пидорасы они по майндсету и по подходам к жизни.
Приложение у них написано людьми, которые ненавидят людей и до поддержки хрен достучишься.
Решил заказать себе робот пылесос, регнулся в приложении и долго чесал репу что значит itn и еще какое-то слово, которое означает отчество.
Вроде прошел этот квест и решил пойти дальше и наконец оформить покупку. Добавил карту жму оплатить и мне говорит что банк неизвестен, но деньги списывают.
В итоге, списали два раза деньги, хрен отменишь заказы, в доставках нет ничего и хрен найдешь поддержку.
А на пункте выдачи особо ничего не подскажут, потому что они выдают товар.
Штош, буду ждать возврата денег, если вернут их конечно.
Вайлдберрис — контора пидорасов. Неделю спустя.
Оставайтесь на линии, ваш звонок очень важен для нас. Примерное время ожидания два года.
Поддержка у ребят работает прям очень быстро, в целом можно сделать вывод что во всей конторе работают некомпетентные люди.
-- В Бишкеке говорят чтобы писал в приложение и задавал вопрос
-- Спустя пару суток после ожидания сказали писать в чат, а в чате вон по скрину выше можно понять как быстро отвечают люди.
-- Отписал в чат и учитывая что писал в пятницу и были выходные, но результата так и нет.
Самое забавное, что ВБ говорит что транзакций нет и доставок не видят, хотя пять покупок у меня в кабинете висят себе как доставленные.
На сайте написано что по всем вопросам можно писать на [email protected] или [email protected], но там тоже не отвечают.
В итоге, в прошлый четверг написал антимонопольщикам, потому что ситуация сама по себе хреновая и учитывая быстрые ответы поддержки это может затянуться на полгода.
В целом, 16к в итоге жалко, они могут их и не вернуть учитывая вообще что происходит у них, но они будут в черном списке у меня вечно, как маркетплейс, как возможный работодатель и как вообще хоть какая-то компания
Оставайтесь на линии, ваш звонок очень важен для нас. Примерное время ожидания два года.
Поддержка у ребят работает прям очень быстро, в целом можно сделать вывод что во всей конторе работают некомпетентные люди.
-- В Бишкеке говорят чтобы писал в приложение и задавал вопрос
-- Спустя пару суток после ожидания сказали писать в чат, а в чате вон по скрину выше можно понять как быстро отвечают люди.
-- Отписал в чат и учитывая что писал в пятницу и были выходные, но результата так и нет.
Самое забавное, что ВБ говорит что транзакций нет и доставок не видят, хотя пять покупок у меня в кабинете висят себе как доставленные.
На сайте написано что по всем вопросам можно писать на [email protected] или [email protected], но там тоже не отвечают.
В итоге, в прошлый четверг написал антимонопольщикам, потому что ситуация сама по себе хреновая и учитывая быстрые ответы поддержки это может затянуться на полгода.
В целом, 16к в итоге жалко, они могут их и не вернуть учитывая вообще что происходит у них, но они будут в черном списке у меня вечно, как маркетплейс, как возможный работодатель и как вообще хоть какая-то компания
Непоправимых улучшений пост.
Don't marry your code. Наверное это лучшее что я слышал за последние полтора года и я полностью согласен с этим утверждением. И расскажу о последних изменениях, которые таки получилось вмержить в main, но они убивают больше половины кода, написанного в проекте.
Так вот, когда мы начинали делать Эверест, мы думали о том, чтобы Эверест работал как вне кубер кластера, так и внутри кубер кластера. Учитывая, что команда была еще достаточно новая и не у всех было понимание как работает кубер, то в итоге была взята связка в виде композа для запуска небольшого бекенда, который хранил данные в постресе.
С течением времени мы запилили чуть больше фичей в нашем операторе и получилось так, что почти бОльшую часть вещей, что мы храним в постресе мы храним и внутри кубер кластера. В итоге становится использование постреса для хранения куберовских объектов сомнительным, потому что:
1. Это достаточно большая и сложная зависимость для проекта и нужен код для работы с ним
2. Нужно думать, как сделать использование постреса для HA, а это значит нужно либо использовать оператор, либо пилить самим что-то чтобы запустить три реплики постреса, чтобы они работали между собой
3. Его нужно бекапить и думать об этом.
4. В кубере есть либо кеши контроллера, либо кеши клиента, которые лучше подходят для кеширования объектов, чем пострес.
Однако, была поддержка нескольких кубер кластеров и это был прям биг дил.
Но! Обсудив с продактом весь этот движ мы приняли два важных решения
1. Задепрекейтить композ и деплоить Эверест внутрь кубера и сделать его Kubernetes Native приложением
2. Убрать поддержку мультикуберов, потому что пока не понятно что на самом деле нам будет нужно и если убрать всё прямо сейчас, то продукт станет проще.
А дальше, потратив пару дней чтобы выпилить весь код, а потом написать его без использования постреса попивая чай между созвонами и закинув это на ревью, а после подождав около двух недель на всякие обсуждения, типа а давайте оставим пострес, я таки убил пострес.
Что дало? Кодобаза похудела на 5к строк, продукт стал проще, пространства для сетевых и человеческих ошибок стало меньше по ряду причин. Самый важный для меня пункт -- это теперь у бекенда нет никакого стейта и его можно как угодно масштабировать.
Такие дела
Don't marry your code. Наверное это лучшее что я слышал за последние полтора года и я полностью согласен с этим утверждением. И расскажу о последних изменениях, которые таки получилось вмержить в main, но они убивают больше половины кода, написанного в проекте.
Так вот, когда мы начинали делать Эверест, мы думали о том, чтобы Эверест работал как вне кубер кластера, так и внутри кубер кластера. Учитывая, что команда была еще достаточно новая и не у всех было понимание как работает кубер, то в итоге была взята связка в виде композа для запуска небольшого бекенда, который хранил данные в постресе.
С течением времени мы запилили чуть больше фичей в нашем операторе и получилось так, что почти бОльшую часть вещей, что мы храним в постресе мы храним и внутри кубер кластера. В итоге становится использование постреса для хранения куберовских объектов сомнительным, потому что:
1. Это достаточно большая и сложная зависимость для проекта и нужен код для работы с ним
2. Нужно думать, как сделать использование постреса для HA, а это значит нужно либо использовать оператор, либо пилить самим что-то чтобы запустить три реплики постреса, чтобы они работали между собой
3. Его нужно бекапить и думать об этом.
4. В кубере есть либо кеши контроллера, либо кеши клиента, которые лучше подходят для кеширования объектов, чем пострес.
Однако, была поддержка нескольких кубер кластеров и это был прям биг дил.
Но! Обсудив с продактом весь этот движ мы приняли два важных решения
1. Задепрекейтить композ и деплоить Эверест внутрь кубера и сделать его Kubernetes Native приложением
2. Убрать поддержку мультикуберов, потому что пока не понятно что на самом деле нам будет нужно и если убрать всё прямо сейчас, то продукт станет проще.
А дальше, потратив пару дней чтобы выпилить весь код, а потом написать его без использования постреса попивая чай между созвонами и закинув это на ревью, а после подождав около двух недель на всякие обсуждения, типа а давайте оставим пострес, я таки убил пострес.
Что дало? Кодобаза похудела на 5к строк, продукт стал проще, пространства для сетевых и человеческих ошибок стало меньше по ряду причин. Самый важный для меня пункт -- это теперь у бекенда нет никакого стейта и его можно как угодно масштабировать.
Такие дела
Не трогай, оно и так работает.
Жаль, что сечас можно эту фразу услышать не только от админов, но и от разработчиков.
Продолжая тему Don't marry your code с течением жизни проекта и изменений требований проекта, части системы придется выкидывать. Как по мне лучше всего это делать без сожалений и не думая о том, что завтра эта вещь может понадобиться. Это равносильно комментированию кода при коммитах.
Видеть закоментированный код в коммитах печально, потому что единственный вывод который можно сделать -- люди не умеют пользоваться гитом. Его можно спокойно удалить, а потом если что достать из истории либо пользуясь консолью, либо в современных IDE есть куча инструментов для этого.
Если вдруг пострес и понадобится в будущем, то это будет куда меньше кода и куда более простая интеграция, чем была до этого. Соответственно меньше техдолга и чище код.
И Мартин и Фаулер согласны с тем, что система хороша тогда, когда ее можно менять, если систему можно менять радикально за короткое время -- это либо хорошо написанная система, либо проект в начальной стадии. Но если упустить этот момент, то система обрастет техдолгом и дополнительной сложностью.
Поэтому, я люблю непоправимо улучшать систему, когда одно продуктовое решение может упрастить поддержку кода и работу с ним в разы.
Убитая ненужная зависимость снижает
1. Когнитивную нагрузку
2. Косты на хостинг для пользователей
3. Поддержку решения разработчиками
4. Количество корнеркейсов и обращений от пользователей, что не работает тот или иной функционал
5. Тестирование
Жаль, что сечас можно эту фразу услышать не только от админов, но и от разработчиков.
Продолжая тему Don't marry your code с течением жизни проекта и изменений требований проекта, части системы придется выкидывать. Как по мне лучше всего это делать без сожалений и не думая о том, что завтра эта вещь может понадобиться. Это равносильно комментированию кода при коммитах.
Видеть закоментированный код в коммитах печально, потому что единственный вывод который можно сделать -- люди не умеют пользоваться гитом. Его можно спокойно удалить, а потом если что достать из истории либо пользуясь консолью, либо в современных IDE есть куча инструментов для этого.
Если вдруг пострес и понадобится в будущем, то это будет куда меньше кода и куда более простая интеграция, чем была до этого. Соответственно меньше техдолга и чище код.
И Мартин и Фаулер согласны с тем, что система хороша тогда, когда ее можно менять, если систему можно менять радикально за короткое время -- это либо хорошо написанная система, либо проект в начальной стадии. Но если упустить этот момент, то система обрастет техдолгом и дополнительной сложностью.
Поэтому, я люблю непоправимо улучшать систему, когда одно продуктовое решение может упрастить поддержку кода и работу с ним в разы.
Убитая ненужная зависимость снижает
1. Когнитивную нагрузку
2. Косты на хостинг для пользователей
3. Поддержку решения разработчиками
4. Количество корнеркейсов и обращений от пользователей, что не работает тот или иной функционал
5. Тестирование
NFS: Unbound, Resident Evil 4 и God Of War: Ragnarok Valhalla
Последние пару недель я устроил себе что-то типа отпуска и восстанавливаю потихоньку менталку. Вытерая пыль с консоли и контроллера, я вспомнил что были планы на прохождение резидента и вальхаллы.
Resident Evil 4 — это любимая игра из прошлого, но проходил я ее впервые на компе. Я тильтанул после первой попытки и когда пришел в деревню дох очень часто, плюс на компе я проходил ее с читами, нарисовав себе кучу денег с помощью артмани. В целом — это тот же самый резидент, с тем же сюжетом, теми же косяками, только с новым и классным графонием. На контроллере в нее играть сначала непривычно, но потом как-то втягиваешься. Было прикольно пройти ее сначала, а потом еще раз и в итоге забив, что я таки не куплю бесконечную базуку я забил на нее спустя 2 с половиной прохождения. Плюс до платины ее если добивать, то пройти надо будет не один раз, а на это тратить 5-10 часов не очень хочется
DLC для God Of War получился достаточно интересным и хорошим. Кто играл в Варкрафт и знает что такое Торгаст или Башня Мага, то это примерно тоже самое, только с дополнительной историей и всем подобным. Кратко — нужно просто проходить через несколько миров и дверей поднимаясь наверх, драться с Тиром и получать какой-то кусок истории. В целом пройдя DLC на 100% остались вполне себе хорошие впечатления.
Unbound. Вообще я не собирался покупать игру и как-то гамать в нее. Я вообще думал поставить NFS: Most Wanted 2005 года и пройти ее еще раз, но посмотрев пару обзоров я решил дать шанс, к тому же она шла со скидкой и обошлась мне в 11 баксов. Я не любитель серии после того, что выходило после 2005 года, пробовал Heat, пробовал переиздание Most Wanted и оно не заходило. Тут же есть прикольные эффекты в стиле комиксов. По геймплею есть вайб тех самых андерграундов и мост вонтед, саундтрек в игре отстой, AI хорош и на пару кругов не накатать их уже, плюс количество рестартов ограничено. Также можно не париться и не всегда приезжать первым, кроме некоторых ивентов. В общем, можно попробовать поиграть в нее. Правда онлайн доступен только при подписке на Playstation+.
А пока сейчас межсезонье в World Of Warcraft, то приходится играть либо в какие-то игры на плойке, либо смотреть видосики с конф.
Так что, буду возвращать привычку что-то писать и в планах написать про выгорание и еще пару тем
Последние пару недель я устроил себе что-то типа отпуска и восстанавливаю потихоньку менталку. Вытерая пыль с консоли и контроллера, я вспомнил что были планы на прохождение резидента и вальхаллы.
Resident Evil 4 — это любимая игра из прошлого, но проходил я ее впервые на компе. Я тильтанул после первой попытки и когда пришел в деревню дох очень часто, плюс на компе я проходил ее с читами, нарисовав себе кучу денег с помощью артмани. В целом — это тот же самый резидент, с тем же сюжетом, теми же косяками, только с новым и классным графонием. На контроллере в нее играть сначала непривычно, но потом как-то втягиваешься. Было прикольно пройти ее сначала, а потом еще раз и в итоге забив, что я таки не куплю бесконечную базуку я забил на нее спустя 2 с половиной прохождения. Плюс до платины ее если добивать, то пройти надо будет не один раз, а на это тратить 5-10 часов не очень хочется
DLC для God Of War получился достаточно интересным и хорошим. Кто играл в Варкрафт и знает что такое Торгаст или Башня Мага, то это примерно тоже самое, только с дополнительной историей и всем подобным. Кратко — нужно просто проходить через несколько миров и дверей поднимаясь наверх, драться с Тиром и получать какой-то кусок истории. В целом пройдя DLC на 100% остались вполне себе хорошие впечатления.
Unbound. Вообще я не собирался покупать игру и как-то гамать в нее. Я вообще думал поставить NFS: Most Wanted 2005 года и пройти ее еще раз, но посмотрев пару обзоров я решил дать шанс, к тому же она шла со скидкой и обошлась мне в 11 баксов. Я не любитель серии после того, что выходило после 2005 года, пробовал Heat, пробовал переиздание Most Wanted и оно не заходило. Тут же есть прикольные эффекты в стиле комиксов. По геймплею есть вайб тех самых андерграундов и мост вонтед, саундтрек в игре отстой, AI хорош и на пару кругов не накатать их уже, плюс количество рестартов ограничено. Также можно не париться и не всегда приезжать первым, кроме некоторых ивентов. В общем, можно попробовать поиграть в нее. Правда онлайн доступен только при подписке на Playstation+.
А пока сейчас межсезонье в World Of Warcraft, то приходится играть либо в какие-то игры на плойке, либо смотреть видосики с конф.
Так что, буду возвращать привычку что-то писать и в планах написать про выгорание и еще пару тем
В качестве дисклеймера скажу что пост про выгорание пишу только из своего опыта и изучения вопроса. Я ненастоящий психолог и во многих вещах могу ошибаться.
Обычно из каждого утюга говорят про ворк-лайф баланс. Однако если в вашей лайф только ворк и лайф, то у меня плохие новости. Жизнь не делиться на лайф и ворк и обычно для поиска баланса есть колесо баланса и другие инструменты. Также говорят, что переработки ведут к выгоранию, однако это в большинстве случаев не так. Я сколько перерабатывал и не выгорал (Да-да типичное у нас психологов не было и ниче, нормальные. С вас пять тыщ :D). По опыту и наблюдениям переработки ведут к усталости, истощению и даже если разорвать бесконечный цикл, то восстановление займет достаточно быстрое время до пары недель. Однако, если переработки бесмыссленные, то вот в этом случае оно может привести к выгоранию.
В чем же тут дело? Почему в одном случае у нас есть выгорание, а в другом нет? Дело в том, что выгорание – это всегда про бесмыссленность. Если это расширить, то выгорания не приходят к нам из-за переработок. Они приходят к нам из-за того, что мы долго не можем добиться результата, либо мы не согласны с видением, либо у нас нет этого видения. Вот эту цитату я прочитал как-то в одной рассылке и мне стало понятнее почему я выгорал и что с этим делать.
Рецепт выгорания. Если взять некомпетентного менеджера, который еще отлично умеет в психологическое насилие и постоянно ставит сжатые сроки по поставке фичей, то любой выгорит достаточно быстро. Зависит от стрессоустойчивости человека.
Более менее список причин, которые могут привести к выгоранию
1. Некомпетентный менеджмент. К сожалению его найти в отрасли достаточно легко. Сюда входят классические примеры, что мы используем agile poker для получения эстимейтов, менеджер принимает решение когда должна быть готова та или иная фича в 100% случаев и так далее
2. Насилие на рабочем месте. Сюда входит обесценивание труда, выданное под соусом “Я выдаю фидбек”, не умение в конструктивную обратную связь, обвинения всякие, газлайтинг, абьюз и подобное
3. Непонятна картина куда вообще идет проект ни по технической, ни по продуктовой стороне. Если нет ответа “А зачем мы делаем этот проект”, то в конечном счете человек не будет видеть смысла в своей работе
4. Бесмыссленные переработки. Есть переработки, которые вполне легко переносятся. Например, когда катите какую-то фичу и хотите успеть. Тут всё понятно зачем и почему перерабатываете. Но если переработки не по вашему желанию а из-за некомпетентности менеджмента или неумения говорить нет, то тут они и ведут к тому, что можно выгореть.
Завтра напишу как распознать и что с этим делать также со своего опыта
Обычно из каждого утюга говорят про ворк-лайф баланс. Однако если в вашей лайф только ворк и лайф, то у меня плохие новости. Жизнь не делиться на лайф и ворк и обычно для поиска баланса есть колесо баланса и другие инструменты. Также говорят, что переработки ведут к выгоранию, однако это в большинстве случаев не так. Я сколько перерабатывал и не выгорал (Да-да типичное у нас психологов не было и ниче, нормальные. С вас пять тыщ :D). По опыту и наблюдениям переработки ведут к усталости, истощению и даже если разорвать бесконечный цикл, то восстановление займет достаточно быстрое время до пары недель. Однако, если переработки бесмыссленные, то вот в этом случае оно может привести к выгоранию.
В чем же тут дело? Почему в одном случае у нас есть выгорание, а в другом нет? Дело в том, что выгорание – это всегда про бесмыссленность. Если это расширить, то выгорания не приходят к нам из-за переработок. Они приходят к нам из-за того, что мы долго не можем добиться результата, либо мы не согласны с видением, либо у нас нет этого видения. Вот эту цитату я прочитал как-то в одной рассылке и мне стало понятнее почему я выгорал и что с этим делать.
Рецепт выгорания. Если взять некомпетентного менеджера, который еще отлично умеет в психологическое насилие и постоянно ставит сжатые сроки по поставке фичей, то любой выгорит достаточно быстро. Зависит от стрессоустойчивости человека.
Более менее список причин, которые могут привести к выгоранию
1. Некомпетентный менеджмент. К сожалению его найти в отрасли достаточно легко. Сюда входят классические примеры, что мы используем agile poker для получения эстимейтов, менеджер принимает решение когда должна быть готова та или иная фича в 100% случаев и так далее
2. Насилие на рабочем месте. Сюда входит обесценивание труда, выданное под соусом “Я выдаю фидбек”, не умение в конструктивную обратную связь, обвинения всякие, газлайтинг, абьюз и подобное
3. Непонятна картина куда вообще идет проект ни по технической, ни по продуктовой стороне. Если нет ответа “А зачем мы делаем этот проект”, то в конечном счете человек не будет видеть смысла в своей работе
4. Бесмыссленные переработки. Есть переработки, которые вполне легко переносятся. Например, когда катите какую-то фичу и хотите успеть. Тут всё понятно зачем и почему перерабатываете. Но если переработки не по вашему желанию а из-за некомпетентности менеджмента или неумения говорить нет, то тут они и ведут к тому, что можно выгореть.
Завтра напишу как распознать и что с этим делать также со своего опыта