Заранее вопрос, планируется ли какая-то мобильная версия (по крайней мере сходу не нашел ее)? Я сейчас пользуюсь телеграм ботами, просто потому, что всегда под рукой, без отрыва от чатов. Часто задачи рождаются при общении с другими людьми, а большая часть общения в чатах.
Как вариант, бот, через который можно загонять задачи, чтобы потом разгрести с компьютера.
Спасибо большое за статью, очень не хватало чего-то такого в момент, когда впервые за них садился.
Было бы здорово, если собственный код был в виде текста, чтобы можно было проще копировать и запускать локально. Или в виде ссылки на репозиторий с исходниками.
В попытке ответить за ДП, возможно, факт того, что задача разбивается на более мелкие задачи того же класса (а не просто набор задач попроще), что и сама задача, стоит отдельного названия)
Возможно я что-то не понимаю, но как эта таблица отвечает на вопрос, нужно ли менять стек?
К примеру, если бы там было 90% процентов компаний использовали реакт или ангуляр, нужно было бы при этом переходить?
Если бы у вас был вопрос найма людей, то можно было бы смотреть, сколько есть специалистов по конкретному фреймворку (косвенно сколько вакансий, ибо легче проверить)
Если вам нужно делать что-то сложнее формочек (условно видеозвонки, визуализацию снимков рентгенапаратов, чтолибоеще), то смотреть где есть (и насколько развиты) подходящие библиотеки.
Если план на долгое легаси, то смотреть кто как сохраняет обратную совместимость и какие лицензии (лицензии скорей всего примерно одинаковые, но тем не менее)
Также вызывает вопрос релевантности выборки, выглядит как "мы знаем 60 компаний, у которых Vue, осталось найти 120 без, но не меньше, а то палевно будет". Вопрос, а сколько вообще есть компаний с сайтами на vue/react/angular, насколько большая кодовая база у каждой и т.п.
Есть компании, которые мы не смогли определить – в основном это застройщики, старые интернет-магазины и заправки.
Если я неожиданно создам 120 юрлиц и подниму для каждого лендинг на react/angular, вы убавите свой процент вдвое? =) и самое главное, смените стек? =)
Ничего не имею против каждого из фреймворков (так или иначе больше или меньше коснуться пришлось каждого), но блин, даже на лабах по физике мы не настолько жестко подгоняли данные >_<
Первая мысль — это может сделать Antichamber еще большим Antichamber. Если данная игра обошла вас стороной, советую попробовать посмотреть, мне кажется она может дать новых идей.
В описанном мной примере хранить не нужно, так как мы можем сходить к серверу авторизации за новыми токенами при перезагрузки страницы. Для того, чтобы это сделать нам нужна сессия на сервере авторизации, это скорее всего будет что-то в httpOnly куках, но это не будут те же токены, которые мы будем использовать на других сервисах.
Мне на самом деле интересны проблемы, которые тут можно огрести, и которые я пока не вижу,… но я их пока не вижу =)
Статья не то чтобы не раскрывает тему, она больше вводит в заблуждение...
Существуют сценарии, при реализации которых вы не можете передавать куки своему API-серверу.
А потом складываем refresh token в куки… выходит от недостатка не избавились...
Из моего опыта хранить токены нужно только в оперативной памяти и отправлять в хедерах.
Для меня тоже долгое время было большой загадкой, а где таки хранить токены. После некоторого погружения в бекенд моя картина мира складывается в вариант, когда мы выносим сервис авторизации в отдельный сервис (на отдельном домене), с которым у нас есть нормальная куки сессия, хранящаяся на бекенде в базе и т.д. и т.п., от этого сервиса мы получаем токены, храним их в оперативной памяти и уже с ними ходим в остальные сервисы.
Причем нигде не должно быть возни с CORS, клиент всегда шлет на родной домен запросы, которые проверяются одним api gateway'ем, а потом раскидываются по сервисам.
Еще одной замечательной особенностью токенов является их независимость от браузерных особенностей работы с куками, что позволяет использовать их между серверами и с мобильных устройств, что также упущено в этой статье.
Я верю, что мой коммент будет полезен тем, кто начинает читать статьи с комментариев =)
Про двух из разобранных исполнителей я слышу впервые (и беглый гугл говорит, что я об этом не сильно пожалею), но возможно, если отсечь творчество всех исполнителей одним возрастом (например самым молодым из предложенных), то разница по критерию ненормативной лексики несколько сгладится =)
Я конечно понимаю, что тут вирусы обсуждают и все такое, но мне дико интересно, по какой метрике Вульсфбург и Ингольштадт — самые богатые города Германии?
Я просто живу относительно недалеко от Ингольштадт, там конечно Ауди, торговые центры на весь район (юг Германии), но… Да и первая ссылка в выдаче гугла говорит об обратно..
Thank you for the comment, that's true, I forgot even to mention this problem in the article.
The problem is that you may not always have own backend. And if the domains of the app and server differ you will not be able to use cookies.
Even in this case, it will be better not to store token in the local storage, but in the memory. It is much safer if you ask the user to log in again after closing the app.
But it is so annoying to ask people to input login/password every time, isn't it?)) And people are lazy… and what if we protected by VPN for example… is it enough to allow saving tokens in local storage? What your sales and information security department think about it? ^_^
I think the documentation of oauth0 might be useful in this question. They give recommendations about how to store tokens: Store Tokens (Auth0 Docs)
Еще один caps lock никогда не будет лишним
Там вроде щетка работала чисто дисплеем, нет?
Идея для стартапа - релайбл флоппи в том же форм факторе и интерфейсом, но с условно обычной флешкой внутри =)
Выглядит интересно, зарегестрировался,
Заранее вопрос, планируется ли какая-то мобильная версия (по крайней мере сходу не нашел ее)? Я сейчас пользуюсь телеграм ботами, просто потому, что всегда под рукой, без отрыва от чатов. Часто задачи рождаются при общении с другими людьми, а большая часть общения в чатах.
Как вариант, бот, через который можно загонять задачи, чтобы потом разгрести с компьютера.
#!sarcasm
Но эти же люди пойдут после этих же курсов делать софт для этих же самолетов!
Спасибо большое за статью, очень не хватало чего-то такого в момент, когда впервые за них садился.
Было бы здорово, если собственный код был в виде текста, чтобы можно было проще копировать и запускать локально. Или в виде ссылки на репозиторий с исходниками.
В попытке ответить за ДП, возможно, факт того, что задача разбивается на более мелкие задачи того же класса (а не просто набор задач попроще), что и сама задача, стоит отдельного названия)
Есть еще следствие, что люди с IQ больше 95 (по крайней мере в среднем) не тратят время на странные исследования =)
Нельзя называть библиотеку компонентов библиотекой компонентов, если ты хочешь продать библиотеку компонентов...
Возможно я что-то не понимаю, но как эта таблица отвечает на вопрос, нужно ли менять стек?
К примеру, если бы там было 90% процентов компаний использовали реакт или ангуляр, нужно было бы при этом переходить?
Если бы у вас был вопрос найма людей, то можно было бы смотреть, сколько есть специалистов по конкретному фреймворку (косвенно сколько вакансий, ибо легче проверить)
Если вам нужно делать что-то сложнее формочек (условно видеозвонки, визуализацию снимков рентгенапаратов, чтолибоеще), то смотреть где есть (и насколько развиты) подходящие библиотеки.
Если план на долгое легаси, то смотреть кто как сохраняет обратную совместимость и какие лицензии (лицензии скорей всего примерно одинаковые, но тем не менее)
Также вызывает вопрос релевантности выборки, выглядит как "мы знаем 60 компаний, у которых Vue, осталось найти 120 без, но не меньше, а то палевно будет". Вопрос, а сколько вообще есть компаний с сайтами на vue/react/angular, насколько большая кодовая база у каждой и т.п.
Если я неожиданно создам 120 юрлиц и подниму для каждого лендинг на react/angular, вы убавите свой процент вдвое? =) и самое главное, смените стек? =)
Ничего не имею против каждого из фреймворков (так или иначе больше или меньше коснуться пришлось каждого), но блин, даже на лабах по физике мы не настолько жестко подгоняли данные >_<
Первая мысль — это может сделать Antichamber еще большим Antichamber. Если данная игра обошла вас стороной, советую попробовать посмотреть, мне кажется она может дать новых идей.
В описанном мной примере хранить не нужно, так как мы можем сходить к серверу авторизации за новыми токенами при перезагрузки страницы. Для того, чтобы это сделать нам нужна сессия на сервере авторизации, это скорее всего будет что-то в httpOnly куках, но это не будут те же токены, которые мы будем использовать на других сервисах.
Мне на самом деле интересны проблемы, которые тут можно огрести, и которые я пока не вижу,… но я их пока не вижу =)
Статья не то чтобы не раскрывает тему, она больше вводит в заблуждение...
А потом складываем refresh token в куки… выходит от недостатка не избавились...
Из моего опыта хранить токены нужно только в оперативной памяти и отправлять в хедерах.
Для меня тоже долгое время было большой загадкой, а где таки хранить токены. После некоторого погружения в бекенд моя картина мира складывается в вариант, когда мы выносим сервис авторизации в отдельный сервис (на отдельном домене), с которым у нас есть нормальная куки сессия, хранящаяся на бекенде в базе и т.д. и т.п., от этого сервиса мы получаем токены, храним их в оперативной памяти и уже с ними ходим в остальные сервисы.
Причем нигде не должно быть возни с CORS, клиент всегда шлет на родной домен запросы, которые проверяются одним api gateway'ем, а потом раскидываются по сервисам.
Еще одной замечательной особенностью токенов является их независимость от браузерных особенностей работы с куками, что позволяет использовать их между серверами и с мобильных устройств, что также упущено в этой статье.
Я верю, что мой коммент будет полезен тем, кто начинает читать статьи с комментариев =)
Про двух из разобранных исполнителей я слышу впервые (и беглый гугл говорит, что я об этом не сильно пожалею), но возможно, если отсечь творчество всех исполнителей одним возрастом (например самым молодым из предложенных), то разница по критерию
ненормативной лексикинесколько сгладится =)Спасибо,
Я понял, это ввп на душу населения, а не общий,
Я бы сказал, что тогда это два города с самыми богатыми людьми, но попахивает занудством ^_^
Я конечно понимаю, что тут вирусы обсуждают и все такое, но мне дико интересно, по какой метрике Вульсфбург и Ингольштадт — самые богатые города Германии?
Я просто живу относительно недалеко от Ингольштадт, там конечно Ауди, торговые центры на весь район (юг Германии), но… Да и первая ссылка в выдаче гугла говорит об обратно..
Хорошая игра для практики лисенинга — firewatch. Проходится часа за 2-3, но в течение этих часов почти непрерывные диалоги на хорошем английском.
В предыдущем ответе нумерация должна была начинаться с двойки… сорри, если ввел в заблуждение
Правильно я понимаю, что для этого вам приходится в каждом запросе отправлять refresh token?
Thank you for the comment, that's true, I forgot even to mention this problem in the article.
The problem is that you may not always have own backend. And if the domains of the app and server differ you will not be able to use cookies.
Even in this case, it will be better not to store token in the local storage, but in the memory. It is much safer if you ask the user to log in again after closing the app.
But it is so annoying to ask people to input login/password every time, isn't it?)) And people are lazy… and what if we protected by VPN for example… is it enough to allow saving tokens in local storage? What your sales and information security department think about it? ^_^
I think the documentation of oauth0 might be useful in this question. They give recommendations about how to store tokens: Store Tokens (Auth0 Docs)