Интересная статья, спасибо
Тоже шел подобными путями пару раз, лично у нас было еще +30 всяких разных интересных проблем. Понимаю что они просто не вместились в презентацию.
Хочу пару моментов уточнить
1. Удалось ли при такой поэтапной миграции полностью отказаться отказаться от старого кода в монолите? И была ли такая цель вообще?
2. В целом по моему опыту сложность продукта, доменной области в монолите приводила к вышеуказанным проблемам, и при миграции на микросервисы вы эту сложность перекладываете на плечи девопсов. На сколько больше у вас стало девопсов в итоге? Или как оценить примерно сколько людей девопсов понадобится например через год-два после миграции 30% функционала на микросервисы? Мс и монолит у вас on-premise?
Так действующие лица не изменились
Но в целом отрасль взрослеет, собеседований от которых остались нормальные впечатления вместо 1/10 становится 4/10.
А на вопросы которые мне не нравятся, например слишком странные или слишком простые можно ответить, только честно, что знаешь или пофантазировать как сам бы сделал ту или иную фичу.
А потом спросить как часто им это нужно на проекте?
Такой вопрос часто возвращает в рамки. Если человек адекватный, то скажет честно мы не используем просто у меня список вопросов которые нужно спросить или перестанет эту ерунду спрашивать. Или поведет себя неадекватно, вроде станет говорить что ему виднее что спрашивать и что он тут самый главный архитектор и никому ничего объяснять не обязан, то тут просто можно попрщаться и не тратить больше время самого главного архитектора
JSON Web Token is just an standard (RFC 7519) for creating access tokens to be URI/header safe and have possibiliity to contain some additional information.
JWT quite often used as access tokens but you cannot replace whole schema based 2 (or 3 in case of auth_token, refresh and access token) with just one single token.
It doesn't metter if single token is generated with JWT standart or just unique Guid. Single token concept is vulnerable by the reasons i tried to explain in article: To renew single token you need to use password. Than shorter time-to-live than more frequently you need to send passwords
Я как-то хотел сделать на ML оценки историй и задач, мне кажется в этом есть смысл.
Например по описанию и старым оценкам и реальному времени. Еще можно коммиты вкрутить по старым историям. В той компании еще и видно было какие кейсы QA проверяют и сколько времени уходит
Правда ушел из той компании и там Rally была
Я правильно понял что прокси может auth-пакеты запоминать и не блочить пакеты или адреса, а отправлять такие пакеты несколько раз чтобы заблочить пользователя на сервере телеграмма как будто его аккаунт кто-то пытается взломать? или к примеру увидеть успешно авторизовавшегося юзера и попытаться поменять ему сразу же пароль? Т.е. блочить не сам телеграм а вызывать отказ в обслуживании для конкртеных юзеров?
Был у меня в студенчестве такой опыт. Дали задачу — я сделал
На следующий день два этажа в крупном банке часов 5 не работали и не понимали почему (~100 человек). Зато похвалили что нашел уязвимость в их системе )).
У всех таких заявлений и подходов одна общая проблема, люди излишне пытаются упростить сложную проблему.
К — конкуренция. :))
А вы не демали продукт лучше сделать?
Или процесс оптимизировать?
Или ускорить изготовление? Или хотя бы маркетинг провести почему другой сайт лучше вашего?
Мне кажется в долгосрочной перспективе можно достичь лучших результатов и не потерять «лицо» перед клиентами
Дело не в системе или процессе, а в общем незрелом бизнесе и его винтиках. Когда вместо того чтобы достичь общей цели — постротить камаз и продать его за деньги — люди придираются к опечаткам и смазанным печатям
Я думаю что треть сайтов можно и не на вордпресе положить, просто дергая самые долгие запросы в параллель.
К примеру домашнюю страницу с рандомной частью в урле.
И еще какой-то процент сайтов будет больше денег списывать за хостинг
На одном из проектов делали нагрузочное тестирование в 500 потоков с одной виртулаки
Время ответов вырастало с секунд до десятков секунд. А ждать 20-30 секунд ответа от сайта будет на порядок меньше людей
Причем на 5хх может быть нотификация у админа
А на падении аудитории с дневных 1000 человек на ночные 100 в середине рабочего дня далеко не у всех админов
Да и отдел продаж, к примеру, инет магазина далеко не сразу начнет волноваться
Общее положение с безопасностью очень грустное
Лет 10 назад, тоже автомотизировал работу отдела продаж, у них 20 позиций в заявке в среднем 25минут оформляли
После автомотизации некоторые личности за 8 секунд стали такую заявку оформлять (на конкурентные товары им получалась больше премия)
И уволили они потом в сумме человек 20 из отдела в 24 человека
А потом все равно новых наняли, правда уже на каждого продажника было не по 15клиентов, а по 100-120
Я думал уже эти вопросы давно решены, если не компанией то конкурентами
А факт что нет, показатель видимо недостатка конкуренции в отрасли.
Автор мог бы свою компанию открыть и заработал бы больше
Такой подход в целом и общем делает код медленнее и часто может приводить к неожиданным последствиям в будущем
Избегая такого код разработка станет дешевле в долгосрочной перспективе
Главное, чтобы он стремился быть хорошим работником
Хочется добавить что часто бывает и другая ситуация. Хороший сотрудник приходит в компанию с горящими глазами и год-два работает и постепенно угасает, теряет запал. По разным причинам.
Мне даже кажется это хуже чем кто-то не станет «хоршим работником» (Чтобы это словосочетание не значило)
booking.com PCI compliant
но еще это не совсем так с его партнерами www.pci-proxy.com/tag/pci-booking-com
тем не менее это временные номера карт которые уничтожаются
более интересная информация есть о безопасности в области заказа билетов на самолеты через GDS
Тоже шел подобными путями пару раз, лично у нас было еще +30 всяких разных интересных проблем. Понимаю что они просто не вместились в презентацию.
Хочу пару моментов уточнить
1. Удалось ли при такой поэтапной миграции полностью отказаться отказаться от старого кода в монолите? И была ли такая цель вообще?
2. В целом по моему опыту сложность продукта, доменной области в монолите приводила к вышеуказанным проблемам, и при миграции на микросервисы вы эту сложность перекладываете на плечи девопсов. На сколько больше у вас стало девопсов в итоге? Или как оценить примерно сколько людей девопсов понадобится например через год-два после миграции 30% функционала на микросервисы? Мс и монолит у вас on-premise?
Но в целом отрасль взрослеет, собеседований от которых остались нормальные впечатления вместо 1/10 становится 4/10.
А на вопросы которые мне не нравятся, например слишком странные или слишком простые можно ответить, только честно, что знаешь или пофантазировать как сам бы сделал ту или иную фичу.
А потом спросить как часто им это нужно на проекте?
Такой вопрос часто возвращает в рамки. Если человек адекватный, то скажет честно мы не используем просто у меня список вопросов которые нужно спросить или перестанет эту ерунду спрашивать. Или поведет себя неадекватно, вроде станет говорить что ему виднее что спрашивать и что он тут самый главный архитектор и никому ничего объяснять не обязан, то тут просто можно попрщаться и не тратить больше время самого главного архитектора
JWT quite often used as access tokens but you cannot replace whole schema based 2 (or 3 in case of auth_token, refresh and access token) with just one single token.
It doesn't metter if single token is generated with JWT standart or just unique Guid. Single token concept is vulnerable by the reasons i tried to explain in article: To renew single token you need to use password. Than shorter time-to-live than more frequently you need to send passwords
Например по описанию и старым оценкам и реальному времени. Еще можно коммиты вкрутить по старым историям. В той компании еще и видно было какие кейсы QA проверяют и сколько времени уходит
Правда ушел из той компании и там Rally была
На следующий день два этажа в крупном банке часов 5 не работали и не понимали почему (~100 человек). Зато похвалили что нашел уязвимость в их системе )).
У всех таких заявлений и подходов одна общая проблема, люди излишне пытаются упростить сложную проблему.
А вы не демали продукт лучше сделать?
Или процесс оптимизировать?
Или ускорить изготовление? Или хотя бы маркетинг провести почему другой сайт лучше вашего?
Мне кажется в долгосрочной перспективе можно достичь лучших результатов и не потерять «лицо» перед клиентами
К примеру домашнюю страницу с рандомной частью в урле.
И еще какой-то процент сайтов будет больше денег списывать за хостинг
На одном из проектов делали нагрузочное тестирование в 500 потоков с одной виртулаки
Время ответов вырастало с секунд до десятков секунд. А ждать 20-30 секунд ответа от сайта будет на порядок меньше людей
Причем на 5хх может быть нотификация у админа
А на падении аудитории с дневных 1000 человек на ночные 100 в середине рабочего дня далеко не у всех админов
Да и отдел продаж, к примеру, инет магазина далеко не сразу начнет волноваться
Общее положение с безопасностью очень грустное
После автомотизации некоторые личности за 8 секунд стали такую заявку оформлять (на конкурентные товары им получалась больше премия)
И уволили они потом в сумме человек 20 из отдела в 24 человека
А потом все равно новых наняли, правда уже на каждого продажника было не по 15клиентов, а по 100-120
Я думал уже эти вопросы давно решены, если не компанией то конкурентами
А факт что нет, показатель видимо недостатка конкуренции в отрасли.
Автор мог бы свою компанию открыть и заработал бы больше
Такой подход в целом и общем делает код медленнее и часто может приводить к неожиданным последствиям в будущем
Избегая такого код разработка станет дешевле в долгосрочной перспективе
Хочется добавить что часто бывает и другая ситуация. Хороший сотрудник приходит в компанию с горящими глазами и год-два работает и постепенно угасает, теряет запал. По разным причинам.
Мне даже кажется это хуже чем кто-то не станет «хоршим работником» (Чтобы это словосочетание не значило)
но еще это не совсем так с его партнерами
www.pci-proxy.com/tag/pci-booking-com
тем не менее это временные номера карт которые уничтожаются
более интересная информация есть о безопасности в области заказа билетов на самолеты через GDS