Хабр - российский ресурс, потому разговор о РФ(внезапно, да?). Интелы, майкрософты и прочие приплетать не надо. Они из США, к РФ это никак относится. РФ участвует в вооруженном конфликте, влияние которого глупо отрицать. Количество проектов в работе снижается, бизнес старается экономить, сокращать расходы на зарплаты или сокращает персонал. Или этого нет?
Не стоит ждать справедливости там, где сотни человек ломятся на одну вакансию. Нанимающим просто надо закрыть вакансию подходящим кандидатом. Кто там лучший из всей выборки - не важно, проблемы кандидатов с их понятием справедливости никому не интересны. Пока был дефицит рекрутеры носились за кандидатами, теперь всё поменялось. Пока экономика страны не придёт в состояние роста, улучшений ждать не стоит.
В нормальной ситуации молодцов-профиков работа должна искать сама. В реальности же приходится ходить унижаться, проходить по 3-5 этапов и доказывать что ты не осёл. Причём работа довольно посредственная, обычная инженерка. Чтобы нанять кодообезьяну тратится по 5 человеко-часов. Самое печальное, что никто не выступает против данных схем. Одни готовы и дальше собеседовать подобным образом, другие это проходить.
Я бы сказал по-другому. Слишком много требований к квалификации за достаточно посредственное вознаграждение. Года четыре назад это можно было понять. Сейчас уровень оплаты скатился и не сильно отличается от тех, кто просто перекладывает бумажки или сидит за баранкой и развозит доставки. Предпринимательством я бы не стал называть.
Опять фокус не на том. Экономика страны загибается из-за войны, проекты прикрываются, люди сокращаются. На забугор, как раньше, работать не получится. Куча народа после курсов не знает куда себя деть и как себя применить. Пока конкурс по 1000 человек на место, будет происходить неконтролируемая дичь. Предпосылок для улучшений нет и не предвидится.
Рекрутеры бьются за разработчиков? Что то новое. Про софт скилы хотелось бы более практического ответа. Выступления - лишь редкий специфический случай их использования, к каждодневной деятельности он не относится.
У меня как раз две тренировки в неделю. Одна - жим лежа, вторая присед. Бывает, сделаю тягу, пару тройку подходов, подтягивания, не больше 3, рывок или толчок по настроению. Обычно тренировка не более часа. С этим можно жить и этого хватает, чтобы загрузить почти все.
При этом интервьюер копался в этой системе годами, а кандидат должен за час не зная ничего все успеть, не нарушить тайминг, не упустить нужные детали и прочее. Это действо кроме как порнографией не назовешь.
У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
Нанимать человека за активность где то вне рабочей обстановки, а уж тем более хантить - очень недальновидно и рискованно. Это могло быть актуально лет пять назад, когда был расцвет отрасли и спецов не хватало, с текущим рынком точно нет. Отбор закручен по полной, претендентов навалом на любой грейд.
А кто дает публичный ключ микросервисам, чтобы проверить токен? Публичный ключ либо грузится по ресту, а затем кэшируется, либо присылается в хидере вместе с токеном, что небезопасно, т.к. можно слать любые токены от любого рандомного издателя и одабривать любые операции. Я веду к тому, что знать о сервисе аутентификации все таки придется. Или есть какая то другая схема?
На самом деле даже подпись проверить можно прямо на сервисах. Достаточно из сервиса аутентификации забрать публичный ключ от ключевой пары, подписывающей jwt. Если сервис распарсил токен, значит его подпись верна и сроки тоже(если писать на java). А роли и пермиссии обычно храним прямо в токене. То есть, выходит, в сервис аутентификации каждый раз ходить не надо. Только проверяющий сервис раз ходит за публичным ключом и его кэширует.
Может немного не по теме, встречался с интересной системой аутентификации в PlatformV IAM. Там фронт хранит только идентификатор сессии в куке, доступов к jwt у него нет. Все запросы с фронта идут через IAM (он же proxy). Тот проверяет сессию и обогащает запрос токеном из keycloak. Если сессии нет, то перенаправляет пользователя на страницу аутентификации. Если токен протух, сам обновляет. На целевые сервисы запрос приходит с access токеном в хидере(Bearer), проверка происходит на месте при помощи публичного ключа. Есть ли у кого мнения или опыт по использованию такой гибридной схемы?
JWT был придуман для легковесной stateless аутентификации по месту требования. Если поставщик верифицирован (по публичному ключу) и сроки валидны, то мы доверяем поставщику токена и разрешаем операцию. Если же проверять токен где-то отдельно на основе сессий, то вся легковесность и stateless исчезает вместе со смыслом самого JWT.
Не ясно до конца, где находится страница логина, на клиенте или спринг ее отдает? Кто ответственен за обновление jwt? Фронтенд?
Тема с корсом не должна настраиваться, она разрешается относительными урлами и маршрутизацией на уровне инфраструктуры.
Как вижу, этот сервер и генерирует jwt и сам же их проверяет, что, по мне, не очень хорошо, если архитектура сервисная. Там генерация идет в keycloak, к примеру, а проверять токен может любой сервис, имеющий публичный ключ. К примеру api gateway.
Тема с двухфазной аутентификацией(сессия в куке + пара jwt очень интересна, имел дело с подобной схемой в сберовском iam proxy. Там также своя страница аутентификации, настройки маршрутизации. Любой запрос проходит через iam до сервисов доходит уже с jwt. В статье все роли обьединены в одном сервисе, как это грамотно растащить и натянуть на оркестратор контейнеров - отдельная задача.
Попробую себе утащить алгоритмы генерации и обновления jwt. Очень хорошая замена относительно тяжеловесному кейклоку.
Тут то же самое. Брошенная учеба в вышке, потом в работе тоже все по наклонной. Скатилось до работы грузчиком, комп не освоен даже до уровня включить выключить. Но, при этом, куча рассказов, как будет сделано, но по факту ничего. Наследственность у меня такая. И у отца есть и у сына проявилось.
Хабр - российский ресурс, потому разговор о РФ(внезапно, да?). Интелы, майкрософты и прочие приплетать не надо. Они из США, к РФ это никак относится. РФ участвует в вооруженном конфликте, влияние которого глупо отрицать. Количество проектов в работе снижается, бизнес старается экономить, сокращать расходы на зарплаты или сокращает персонал. Или этого нет?
Не стоит ждать справедливости там, где сотни человек ломятся на одну вакансию. Нанимающим просто надо закрыть вакансию подходящим кандидатом. Кто там лучший из всей выборки - не важно, проблемы кандидатов с их понятием справедливости никому не интересны. Пока был дефицит рекрутеры носились за кандидатами, теперь всё поменялось. Пока экономика страны не придёт в состояние роста, улучшений ждать не стоит.
В нормальной ситуации молодцов-профиков работа должна искать сама. В реальности же приходится ходить унижаться, проходить по 3-5 этапов и доказывать что ты не осёл. Причём работа довольно посредственная, обычная инженерка. Чтобы нанять кодообезьяну тратится по 5 человеко-часов. Самое печальное, что никто не выступает против данных схем. Одни готовы и дальше собеседовать подобным образом, другие это проходить.
Я бы сказал по-другому. Слишком много требований к квалификации за достаточно посредственное вознаграждение. Года четыре назад это можно было понять. Сейчас уровень оплаты скатился и не сильно отличается от тех, кто просто перекладывает бумажки или сидит за баранкой и развозит доставки. Предпринимательством я бы не стал называть.
Опять фокус не на том. Экономика страны загибается из-за войны, проекты прикрываются, люди сокращаются. На забугор, как раньше, работать не получится. Куча народа после курсов не знает куда себя деть и как себя применить. Пока конкурс по 1000 человек на место, будет происходить неконтролируемая дичь. Предпосылок для улучшений нет и не предвидится.
Что то про реальные причины ничего не пишут. Опять сказки про овернайм в ковид и ИИ, который всех вытесняет.
Так может проблема не в менеджере, а в исполнителе? Ключевой совет в стиле нормально делай и контроль ослабнет - как раз про то.
Рекрутеры бьются за разработчиков? Что то новое. Про софт скилы хотелось бы более практического ответа. Выступления - лишь редкий специфический случай их использования, к каждодневной деятельности он не относится.
У меня как раз две тренировки в неделю. Одна - жим лежа, вторая присед. Бывает, сделаю тягу, пару тройку подходов, подтягивания, не больше 3, рывок или толчок по настроению. Обычно тренировка не более часа. С этим можно жить и этого хватает, чтобы загрузить почти все.
Если оставляют прозябать, значит так им и надо. Не просто же так это происходит.
При этом интервьюер копался в этой системе годами, а кандидат должен за час не зная ничего все успеть, не нарушить тайминг, не упустить нужные детали и прочее. Это действо кроме как порнографией не назовешь.
У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
Скорее всего не сильно больше чем у тех, кто развозит еду и товары по Москве.
Нанимать человека за активность где то вне рабочей обстановки, а уж тем более хантить - очень недальновидно и рискованно. Это могло быть актуально лет пять назад, когда был расцвет отрасли и спецов не хватало, с текущим рынком точно нет. Отбор закручен по полной, претендентов навалом на любой грейд.
А кто дает публичный ключ микросервисам, чтобы проверить токен? Публичный ключ либо грузится по ресту, а затем кэшируется, либо присылается в хидере вместе с токеном, что небезопасно, т.к. можно слать любые токены от любого рандомного издателя и одабривать любые операции. Я веду к тому, что знать о сервисе аутентификации все таки придется. Или есть какая то другая схема?
На самом деле даже подпись проверить можно прямо на сервисах. Достаточно из сервиса аутентификации забрать публичный ключ от ключевой пары, подписывающей jwt. Если сервис распарсил токен, значит его подпись верна и сроки тоже(если писать на java). А роли и пермиссии обычно храним прямо в токене. То есть, выходит, в сервис аутентификации каждый раз ходить не надо. Только проверяющий сервис раз ходит за публичным ключом и его кэширует.
Может немного не по теме, встречался с интересной системой аутентификации в PlatformV IAM. Там фронт хранит только идентификатор сессии в куке, доступов к jwt у него нет. Все запросы с фронта идут через IAM (он же proxy). Тот проверяет сессию и обогащает запрос токеном из keycloak. Если сессии нет, то перенаправляет пользователя на страницу аутентификации. Если токен протух, сам обновляет. На целевые сервисы запрос приходит с access токеном в хидере(Bearer), проверка происходит на месте при помощи публичного ключа. Есть ли у кого мнения или опыт по использованию такой гибридной схемы?
JWT был придуман для легковесной stateless аутентификации по месту требования. Если поставщик верифицирован (по публичному ключу) и сроки валидны, то мы доверяем поставщику токена и разрешаем операцию. Если же проверять токен где-то отдельно на основе сессий, то вся легковесность и stateless исчезает вместе со смыслом самого JWT.
Не ясно до конца, где находится страница логина, на клиенте или спринг ее отдает? Кто ответственен за обновление jwt? Фронтенд?
Тема с корсом не должна настраиваться, она разрешается относительными урлами и маршрутизацией на уровне инфраструктуры.
Как вижу, этот сервер и генерирует jwt и сам же их проверяет, что, по мне, не очень хорошо, если архитектура сервисная. Там генерация идет в keycloak, к примеру, а проверять токен может любой сервис, имеющий публичный ключ. К примеру api gateway.
Тема с двухфазной аутентификацией(сессия в куке + пара jwt очень интересна, имел дело с подобной схемой в сберовском iam proxy. Там также своя страница аутентификации, настройки маршрутизации. Любой запрос проходит через iam до сервисов доходит уже с jwt. В статье все роли обьединены в одном сервисе, как это грамотно растащить и натянуть на оркестратор контейнеров - отдельная задача.
Попробую себе утащить алгоритмы генерации и обновления jwt. Очень хорошая замена относительно тяжеловесному кейклоку.
Спасибо за статью!
Тут то же самое. Брошенная учеба в вышке, потом в работе тоже все по наклонной. Скатилось до работы грузчиком, комп не освоен даже до уровня включить выключить. Но, при этом, куча рассказов, как будет сделано, но по факту ничего. Наследственность у меня такая. И у отца есть и у сына проявилось.