Они поживут сначала 3 месяца на минимальном окладе в компании и прочувствуют это.
можно ли мне уточнить? как часто вы живете по 3 месяца на зарплату дворника, что подметает улицу возле вашего дома? или зарплату кассира в макдональдс?
Если у вас есть родители пенсионеры - как часто вы живете по 3 месяца на их пенсию?
Если у вас есть дети - как часто вы живете по 3 месяца, располагая только их карманными деньгами?
И главное - что именно даст это "прочувствование" жизни на минимальном окладе?
Сначала установят себе оклады в размере медианного размера оклада по компании, а потом займутся окладами других.
А чтобы что? Это должно повлиять на решение о том, что зарплата в валюте слишком дорога для бюджета компании?
Вопрос разрыва зарплаты топ-менеджмента крупной компании и рядового специалиста - это конечно важная социальная проблема, да.
Соглашусь - что такой тип проблем более свойственен api-gateway чем сервисам.
Просто есть composition сервисы, к примеру, сервисы не имеющие стейта, занимающиеся формированием ответа конечному пользователю и опрашивая другие сервисы.
Есть вообще graphQL - и там еще больше запросов может случится
Если я верно прочитал - на там напоролись с Nginx - это не только пулы соединений, но и не сбалансированная нагрузка по ядрам в зависимости от тяжести запроса. а в сервисах такое тоже вполне может случится.
приложение выступает тут тем самым клиентом. для которого скрыты все те абстракции что лежат под reverse proxy, включая балансировку, ретраи и прочее. Что в целом соответствует понятию reverse proxy
если вместо reverse proxy использовать просто proxy - люди будут путаться еще сильнее - проверено на тестовой группе
"Как вам вообще пришло в голову" - грубовато звучит, чет-)
Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
ОЧЕНЬ плохо расписан git flow.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Забавно, что это статья от, якобы, профсоюз, который, якобы, представляет чьи-то интересы.
А на самом деле статья основывается на новости, с другого ресурса. И не добавляет к новости вообще ничего (скорее даже более однобоко все рисует)
Роль профсоюза, я так понимаю, исключительно созерцательная во всей этой истории
можно ли мне уточнить? как часто вы живете по 3 месяца на зарплату дворника, что подметает улицу возле вашего дома? или зарплату кассира в макдональдс?
Если у вас есть родители пенсионеры - как часто вы живете по 3 месяца на их пенсию?
Если у вас есть дети - как часто вы живете по 3 месяца, располагая только их карманными деньгами?
И главное - что именно даст это "прочувствование" жизни на минимальном окладе?
А чтобы что? Это должно повлиять на решение о том, что зарплата в валюте слишком дорога для бюджета компании?
Вопрос разрыва зарплаты топ-менеджмента крупной компании и рядового специалиста - это конечно важная социальная проблема, да.
Но это никак не относится сути проблемы.
В этой статье манипуляции потоньше чем в прошлой.
и позиция выглядит чуть более взвешенной, чем в прошлой.
Видно что авторы учатся на своих ошибках!
беглый список манипуляций:
ООО «РРВ», владеющее ООО «КЕХ ЕКОММЕРЦ», – 71,4 млрд руб.Ога, типо "компания зарабатывает, так-что плотите и не гундите".
на собственной интерпретации Трудового кодекса, и в ней есть изъяны, которые мы не раскрываемТут вообще красиво. "собственная интерпретация", "изъян" про который не скажут...
Оппонент не прав, но почему мы не скажем =)
Соглашусь - что такой тип проблем более свойственен api-gateway чем сервисам.
Просто есть composition сервисы, к примеру, сервисы не имеющие стейта, занимающиеся формированием ответа конечному пользователю и опрашивая другие сервисы.
Есть вообще graphQL - и там еще больше запросов может случится
Если я верно прочитал - на там напоролись с Nginx - это не только пулы соединений, но и не сбалансированная нагрузка по ядрам в зависимости от тяжести запроса. а в сервисах такое тоже вполне может случится.
приложение выступает тут тем самым клиентом. для которого скрыты все те абстракции что лежат под reverse proxy, включая балансировку, ретраи и прочее. Что в целом соответствует понятию reverse proxy
если вместо reverse proxy использовать просто proxy - люди будут путаться еще сильнее - проверено на тестовой группе
"Как вам вообще пришло в голову" - грубовато звучит, чет-)
к слову - а почему "просто к сервисам" проблемы быть не может?
Если сможете организовать коннекшн-пул в swoole, c возможностью переиспользования открытых соединений - то конечно-)
У нас более 1000 инженеров. Справились. Проблем огребли кучу.
Мини-советы
сделать копию репы и тренироваться на ней
Проверить как будет вести себя локальные инсталляции.
Проверить ci/cd и его кеш
Проверит вообще все, что работает с репами, включая всякие зеркала реп
Работать в выходные чтобы не ломать рабочие процессы
Не успела на самом деле: к моменту выхода в php почти не осталось сложного кода что обходит много сервисов. Все растащили по сервисам
Посмотри на утилиту bfg для гита
Мы не столь давно удаляли такие артефакты. Сократили размер репы почти в 5 раз.
Чекауты стали быстрее, ci/cd ускорился.
Но сломался ci/cd, ибо он кешировал репы и комиты.
понимаю вашу боль.
Это очень частая проблема с тогглами.
И важно начинать работать над их актуализацией как можно раньше.
Мы решили проблему кардинально.
Растащили из по сервисам и в процессе освежили, убрав не актуальные.
Сейчас домен сервиса достаточно небольшой и нужды у отдельной утилите для этого нет.
Вы правы. Оптимизацией фронт-части, уменьшение TTFB и прочие метрики - это важная составляющая оптимизации.
И этим нужно заниматься (мы сейчас именно этому способу оптимизации уделяем меньше времени чем хотелось бы)
Но статья вовсе не про это. Картинки, подготовка рекомендаций - это отдельная задача, важная для того, чтобы скрол главной был гладеньким.
Статья о том, что даже решение уровня "закидаем железом" перестало быть достаточно эффективным.
Все верно. спасибо!
Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Жаль ни разу не находил, было бы здорово!
Ну и тут понятно - что есть пачка трейдоф.
К примеру TBD не очень подходит под классический релизный цикл: c отгрузкой инкремента раз в пол года
Или к примеру TBD не очень удобен для опенсорс продуктов (не без исключений. лишь большая или меньшая степень удобства с подходом)
ничего не понял.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Вопрос достаточно сложный, на самом деле.
Я исхожу из предпосылок - что все сервисы имеют свои НЕ СВЯЗАННЫЕ друг с другом тогглы.
Такой подход заставляет каждый раз внутри сервиса думать - что делать если фича включена и выключена.
Так как микросервисы не большие по своей природе - тогглов там не бывает много.
Ну а дальше отталкиваемя от того - что за тоггл. Тоггл новой фичи, нужно включить в dev-середе, и прогнать цикл тестирования
Я наверное не до конца понимаю проблему.
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Немного подушню за математику: не 200 интераций по 50 строк а 20 итераций по 50 строк.
эти итерации делаешь быстро. Учитывая современные команды и гибкие методологии разработки - это только в плюс.
Каждый выбирает фломастер на свой вкус, как говорится. Главное что красный вкуснее=)
Не было задачи показать что git flow - сакс. Но он действительно хуже подходит по современные процессы с ci\cd и гибкими методологиям.
Но при этом git flow хорошо ложится на более медленные циклы разработки, вида классической отгрузки продукта по версиям