Хорошая попытка, но нет. У этой штуки нет своего ассебмлера, линкера, есть баги с тайп-чекингом и возможность скомпилировать программу с синтаксическими ошибками. По мне, это стоило бы назвать "вероятностным компилятором" со всеми вытекающими.
И авторы из Антропика сами пишут, что починить это агентами тяжело, потому что исправления одних вещей ломают те, что работали раньше. Так что в сложные системы агенты не умеют.
Кажется, автор книги по программированию вправе рассчитывать, что его читатели сумеют в абстракцию - то есть, сумеют отделить важное в учебном примере в книге от неважного. И, например, увидят, что целью той главы не является обсуждение локализации, цикла жизни программы и прочего.
А иначе мы так и до задачников по физике докопаемся: где это вы видели, чтобы автомобиль двигался прямолинейно и равномерно? И что это за машина такая, которую можно описать материальной точкой?
> дороговато выходит, дешевле всё-таки code review. Обычно так говорят, когда не считают: - стоимость задержек и ожиданий - стоимость переделок (чем позже, тем дороже) - стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Сделайте лендинг, прикиньтесь центром сертификации SOSAL, глядишь, кто-нибудь с ликендина и зацепится. Может, даже спросят, как сертифицироваться. С govno.works так и случилось :)
Вы правы, автор тут не слишком формален. Под обычной сессией он подразумевает действительно идентификатор, по которому на сервере можно будет найти эти данные.
От stateful jwt это действительно мало чем отличается (что автор в тексте отметил), кроме того, что фреймворк (или библиотеки) зачастую дают эту цепочку как готовую ("получить идентификатор - подписать его - оформить в виде куки") либо делают за вас часть этой цепочки в виде подписи. И тогда вопрос целесообразности. Если уже есть готовый способ получить идентификатор сессии и подписать его через HMAC, то зачем тогда JWT? При этом верно и обратное, если библиотека оперирует jwt изначально (как jjwt, например), то можно и его использовать, это ничему не противоречит.
Основной поинт в том, чтобы не превращать этот токен в хранилище.
В целом - да, удачное резюме. Тем не менее, до сих с какой-то периодичностью я слышу эти же самые аргументы в пользу отказа от серверных сессий в пользу вшивания данных в JWT, и даже такой уровень рассмотрения помогает людям прийти в себя и посмотреть на альтернативы. Ну а раз это уже кому-то помогло, может, и еще кому поможет? :)
Хорошая попытка, но нет.
У этой штуки нет своего ассебмлера, линкера, есть баги с тайп-чекингом и возможность скомпилировать программу с синтаксическими ошибками.
По мне, это стоило бы назвать "вероятностным компилятором" со всеми вытекающими.
И авторы из Антропика сами пишут, что починить это агентами тяжело, потому что исправления одних вещей ломают те, что работали раньше. Так что в сложные системы агенты не умеют.
Человек опустил слово "уголовно", полагаю
Кажется, автор книги по программированию вправе рассчитывать, что его читатели сумеют в абстракцию - то есть, сумеют отделить важное в учебном примере в книге от неважного. И, например, увидят, что целью той главы не является обсуждение локализации, цикла жизни программы и прочего.
А иначе мы так и до задачников по физике докопаемся: где это вы видели, чтобы автомобиль двигался прямолинейно и равномерно? И что это за машина такая, которую можно описать материальной точкой?
Автор специально для вас проводит целое рассуждение, а вы споткнулись о первую фразу. Поднимитесь, отряхнитесь и дочитайте комментарий.
> дороговато выходит, дешевле всё-таки code review.
Обычно так говорят, когда не считают:
- стоимость задержек и ожиданий
- стоимость переделок (чем позже, тем дороже)
- стоимость хорошего код-ревью (не просто поскроллить дифф, а пойти узнать, что за задача, и разобраться, почему она была решена именно так).
И когда не разбираются в том, как устроено обучение, и почему code reivew в большинстве случаев - не оно :)
Сделайте лендинг, прикиньтесь центром сертификации SOSAL, глядишь, кто-нибудь с ликендина и зацепится. Может, даже спросят, как сертифицироваться. С govno.works так и случилось :)
Вы правы, автор тут не слишком формален. Под обычной сессией он подразумевает действительно идентификатор, по которому на сервере можно будет найти эти данные.
От stateful jwt это действительно мало чем отличается (что автор в тексте отметил), кроме того, что фреймворк (или библиотеки) зачастую дают эту цепочку как готовую ("получить идентификатор - подписать его - оформить в виде куки") либо делают за вас часть этой цепочки в виде подписи.
И тогда вопрос целесообразности. Если уже есть готовый способ получить идентификатор сессии и подписать его через HMAC, то зачем тогда JWT?
При этом верно и обратное, если библиотека оперирует jwt изначально (как
jjwt, например), то можно и его использовать, это ничему не противоречит.Основной поинт в том, чтобы не превращать этот токен в хранилище.
В целом - да, удачное резюме.
Тем не менее, до сих с какой-то периодичностью я слышу эти же самые аргументы в пользу отказа от серверных сессий в пользу вшивания данных в JWT, и даже такой уровень рассмотрения помогает людям прийти в себя и посмотреть на альтернативы.
Ну а раз это уже кому-то помогло, может, и еще кому поможет? :)