Менеджер здорового человека? Да ладно! 😰

Они что, бывают такие? Бывают. Крутая статья про выгоревшую команду со сломанными процессами и менеджера здорового человека, который пришёл и всё исправил : https://habr.com/ru/companies/gazprombank/articles/699738/

Каждый его шаг откликается и болью и одобрением, потому что почти все такие сломанные вещи я уже видел в разных командах.

Приятно удивило в конце про анонимные опросники. Это так очевидно и ... эффективно. На самом деле... сложно написать анонимку так, чтобы не было понятно от кого она, но дело в другом - сама такая возможность очень важна как минимальный "контракт" доверия между менеджментом и гребцами.

В общем, рекомендасьон!

iPhone 14 Pro. Личный опыт перехода с Samsung 😎

Вы просили (нет). Я сделал.

- Клавиатура - эт бомбяо 🏖
- Интерфейс богов
- Внимание к мелочам
- Кроссплатформенность - работает?

Эт я об айфоне или таки о самсунге? Так кто лучше-то? Ответ в статье

Впечатления настолько яркие, что в рамках поста всё это поместить не получилось.

ps. Как всегда приветствую разорвавшиеся задницы с комментариями и слюной в комментариях.
ps2. Если у вас был похожий опыт - делитесь в комментариях о том как вы выжили, интересно будет почитать.

Налетай! ❤️

🏃‍♀️🏃‍♀️🏃‍♀️ ➡️ https://telegra.ph/Iphone-vs-Android-Kak-zhe-blolno-08-12

Нужно взять на вооружение 😊

Шагал тут на днях и подумалось - вот было бы окнорм, если бы аишечка определяла перфоманс отдельно взятого человека и его влияние на прибыль компании. Мммм? Звучит же! Столько народа сразу можно увольнять к ебенифени ))) Сразу станет понятно, кто компанию на разных уровнях тянет ко дну.

Правда в таком деле - миллион параметров (от внутренних, до внешних), это примерно как погоду предсказывать, но "по верхам" в целом можно же. Ведь любые действия имеют последствия, условный граф с миллионами ветвей и пересечений с другими такими же графами. Теоретически, возможно. Особенно если срезы делать по тайтлам. Чем выше тайтл, тем больше "эффект" от действий. Но наше дело маленькое в большинстве случаев - апишечки, формочки, архитектурки. Если иметь какой-то референс, основанный на других похожих бизнесах/решений... и это тоже теоретически возможно "оценить". Ну не рокет саенс же. Если можно нанять по человеку на каждый такой "экшон" = "коммит изменений", (где под коммитом принять всё - от строчек кода до имплементаций процессов и бизнес решений) и детерминировать до мелких шагов, где каждый шаг - условное "ребро" графа со своим "весом эффективности", то можно и картинку уже нарисовать. А если можно выяснить, значит и аишечка сможет.

А потом подумал ещё раз - если аишечка будет уметь понимать кто эффективен, значит сможет и обучаться на этой информации делать бизнес лучше сам. Там нам все и трындец как рабочей силе хД

В общем, я ещё раз подумал - я против всей этой АИ движухи! Все на улице окажутся, даже эффективные 😂😂😂

Но если кто хочет вложиться в такой стартап - высылайте мне деньги, я попробую на ноде написать. Кто знает, есть готовый NPM пакет? 😂😂😂

Шутки шутками, а я верю, что так и будет ⌨️

Ловите пару неплохих докладов про GraphQL

https://www.youtube.com/watch?v=YgRmgHPTXr4 - доклад 2017-ого, но по прежнему актуален, докладчик очень живой и сама презентация хороша с примерами на Java.

https://www.youtube.com/watch?v=3fHKySh07ow - доклад с HighLoad конфы (этого года), где пацаны рассказывают как переводили Яндекс.Афишу (+кинопоиск) на GraphQL - он уже чуть более сложный (но в рамках), скорее для мидлов/помидоров.

Оба примерно по часу 🍌

У меня сейчас проект на GraphQL. Что я могу сказать - интересная технология, но её нужно правильно готовить. Уже собрано прилично граблей и костылей.

Одни проблемы REST Api она решает :
- больше контроля над схемой
- "клиентам" проще создавать чуть более гибкие запросы при надобности
- уменьшает кол-во передаваемых данных по сети (клиентам-мобилкам зайдёт)

Но как по мне бОльше проблем создаёт :
- Проблема с N+1. Это когда у вас вместо батч запросов, двиг графа бегает в базу за каждой энтитей (тут есть решение, но он тоже компромиссное если у вас serverless - DataLoader)

- Кеширование. GraphQL строится ПОВЕРХ http и у вас все запросы бегут по одному урлу - невозможно использовать стандартные механизмы http кеширования (заголовки, прокси и тд)

- Отслеживание перфоманса запросов. Какие-то тулы уже умеют в парсинг запросов, но скорее всего вам нужно будет писать свои костыли

- Версионирование. Довольно большая проблема с back-compatibility изменениями моделей - эт боль. GraphQL придерживается "эволюционного" подхода с помечанием полей как deprecated, но если связи/изменения обширны - это превращается в ад. Ну и если вы изначально плохо спроектировали АПИ - вам пиздец. Но это и к restApi относится.

- Security. Природа GraphQL подразумевает provisioning = клиент знает и может посмотреть все доступные методы/модели. С одной стороны плюс (тот же сваггер можно пользовать для реста), но выставлять весь апи, простите - ГОЛОЙ ЖОПОЙ во внешку... ну так себе идея. Вот ребята во втором докладе костыли впилили, посмотрите - интересно. Если у вас открытй API, будьте готовы, что злоумышленники изнасилуют вас всеми возможными способами и с большой вероятностью найдут граф, который вызовет отказ в обслуживании, чем ёбнут вам весь сервер. Ну т.е. за этим реально следить нужно.

- Опытность команды. Нужно понимание ВСЕМИ в командах/стримах как это работает и вообще идеологию GraphQL, иначе у вас там ТАКАЯ КАША будет, что все профиты от технологии быстро нивелируются.

Но фейсбук живёт с этим как-то, как и нетфликсы всякие, но где мы все и где эти все фаанги.

В общем, шансов стрельнуть себе в ногу с GraphQL реально много, но инструмент, безусловно, интересный. Если у вас есть опыт работы с ним - пишите в комментах, интересно почитать.

Всем хороших выходных! ⌨️

Давайте поговорим про JWT 😕

Нахера вам эти access_token и refresh_token и как это всё работает?

Залетел мне тут от друга вопрос - зачем нужен refresh_token в JWT? И что вообще такое это ваше ДЖЭВЭТЭ, блэт???

О JWT чуть ниже, а ответ на первый вопрос казалось бы лежит на поверхности - "Ну эээээ, чтобы забрать новый access_token". Ответ верный, да только ясности не добавляет зачем хромому костыль, ведь можно просто ... скажем хранить access_token с каким-то там expiration и проверять каждый раз. Да?

Нет.

Я пятнадцать лет гребу, а пришлось три часа убить чтобы раскопать этот вопрос. Стыд и срам, конечно, но что поделать. Реально очень смешно, что какую статью не начни читать - там 100500 мнений зачем КОНЦЕПТУАЛЬНО нужен refresh_token. Разбираемся 😊

И так, JWT (Читается кстати не ДЖИВИТИ и не ДЖЕЙ ДАБЛВИ ТИ, а ДЖОТ!) - Json Web Tokens стандарт бла бла бла. В википедии сходите почитайте!

Если короче - это такой хитрый джсончик, который состоит из хедера, body и подписи. И нужен для того чтобы гонять его с сервера в браузер и обратно. Для аутентификации запроса пользователя.


Как это работает. На пальцах.

Смотрите, вот логинится пользователь на сайте. Вводит логин и пароль. Мы бежим в базу, проверяем что да, такой пользователь и правда валяется, а ... что дальше? Ведь чтобы получить доступ к личному кабинету и API личного кабинета на сайте ... нужны эти логин и пароль. Мы же не можем просто сделать редирект и дальше не проверять запросы, ведь нам важно понять в КАЖДОМ запросе - а этот ли пользователь его шлёт? Или другой? А какой конкретно?

Поэтому. Мы можем сохранить логин и пароль пользователя и передавать его при каждом запросе к API. Звучит хорошо, не правда ли? Но нет. Это чревато тем, что очень не хотелось бы гонять такие важные данные как пароль и логин каждые пару секунд пользования сайтом. Так не носят. И браузер ваш взломать могут и трафик перехватить и чё только не могут.

Поэтому2. Мы на сервере генерируем JWT токен, засовываем в него айди пользователя и ... подписываем получившийся JSON'чик секретным ключом, предварительно сгенерировав его и положив в какой-нибудь конфиг на сервере. В итоге, наш JWT состоит из Header'а с деталями алгоритма, из "тела" с айдишкой пользователя и каким-то хэшем на конце (подпись). Вот тут можно поиграться и посмотреть на структуру : https://jwt.io/

Важно понимать, что сам токен может быть прочитан КЕМ УГОДНО, т.к. все эти данные - открытые, не шифрованные (именно поэтому в JWT никогда нельзя засовывать sensitive data без предварительной шифровки). Но я же могу подменить тот самый ID и тем самым подменить пользователя - скажете вы. Но нет. Не можете. Для этого вы поменяете Body, а вот ХЭШ, который находится в конце - не сможете, т.к. не знаете секретного ключа сервера. В отличии от самого сервера, который может получить такой токен и проверить, что Body подписан правильно (применив свой секретный ключ и сравнив с "хвостом" токена).

Круто, разобрались немного. Так вот, вы логинитесь. И отдаёте в браузер такой вот JWT токен, который сможете чуть позже проверить. Круто? Круто. Теперь у вас между браузером и сервером постоянно бегает cookie с этим токеном, вы каждый раз проверяете её и всё отлично. Но ... если эту куку перехватит злоумышленник - он ведь сможет воспользоваться ей чтобы выдать себя за пользователя, верно? Верно. Злоумышленник не узнает логин и пароль, но сможет "прикинуться вами". Чё делать?

На сцену выходят access и refresh токены!
Смысл их в том, что при помощи них мы сможем понять - а не пора ли нам снова закинуть пользователя на логин страничку?А так же не позволить злоумышленнику выдать себя за нас. Но зачем оба?

(Вообще, я тут конечно немного помиксал Oauth и JWT, т.к. первый как раз и использует токены, а второй самодостаточный, однако вместе они друг друга дополняют... не забивайте голову).

⬇️Продолжение чуть ниже⬇️

⬆️Начало выше⬆️

access_token - это такой токен, который мы можем проверить, что он был подписан секретным ключом сервера (см. Асимметричное шифрование, я делал пост о том как оно работает). Вообще.. это ровно то, что делает JWT токен сам по себе, так что наш JWT и будет сам по себе являться уже Access_token'ом. Но просто знайте, что в мире Oauth вы можете и сами "скрафтить" всё то же самое, просто JWT это стандарт. Обычно, "живучесть" этого токена небольшая. Именно это свойство позволяет гарантировать, что даже если злоумышленник украдёт его - "доступа к апи" у него останется на n минут, если он вообще сможет вовремя им воспользоваться. +у него не будет ни пароля ни логина. Идеально! Вне мира JWT, это вполне может быть "Bearer {access_token}", что часто и бывает.

refresh_token - а этот токен нужен для того чтобы когда истёк access_token, мы сбегали на сервер и взяли новую пару "access+refresh". Срок протухания этого токена уже может быть и день и десять и месяц - зависит от бизнеса.

В чём соль-то?
Трюк тут в том, что получив при логине эту пару токенов вы

а) Сохраняете refresh_token на сервере и привязываете к пользователю.
б) Зашиваете refresh_token в ПАМЯТЬ (если у вас SPA приложение), или в Local Storage (он не передаётся на сервер с каждым запросом) или как вариант - ставите куку с ограничением, что слаться она может только по урлу запроса новой пары токенов. Суть в том, что этот токен НЕ БЕГАЕТ в разные API, он ждёт своего часа, а именно - когда протухнет access_token.
в) Все запросы из браузера теперь бегают с access_token (в нашем случае с JWT). В JWT "зашиваем" expiration_date. Как только мы понимаем, что JWT "протух", сразу же кидаем 403 (Forbidden) и клиент бежит за новой парой токенов. А этот уже становится невалидным.
г) Как только клиент (браузер) получает 403, он сразу же копается у себя в памяти/куке, достаёт сохранённый refresh_token, бежит на какой-нибудь /authenticate_token, где сервер валидирует JWT токен, достаёт оттуд юзера, смотрит в базу (или кэш), сопоставляет с присланным refresh_token (а так же проверяем не стух ли refresh) и если всё совпадает - прекрасно! Выдаём клиенту обновлённый. Если рефреш стух или мы отозвали все токены из базы (просто удалив), то кидаем клиенту допустим ошибку 401 (Not Authorized) и клиент уже понимает - всё, тут уже без странички логина не обойтись.

Фух. Объяснил на пальцах, так объяснил. Ну... как есть, ребят 🙃

В общем, JWT нужен для "подписи" данных, чтобы быть уверенным, что браузер не подменил инфу, которую мы "вшиваем" в json и гоняем между сервером и клиентом, а токены - для того чтобы злой дядя не воспользовался этим JWT и не представился вами. Всё просто 😊

Спасибо за внимание и лайк не забудь 😁

⭐️ [экшон рекваред]

Пашка Дуров запилил сторисы для каналов. Зачем - вопрос хороший, конечно, но пусть на него другие отвечают. Мне интересно другое. Чтобы включить у себя такую возможность - канал нужно "забустить". А делать это могут только подписчики с прем аккаунтами. Я вам тут по пальцам своей руки пересчитал, всего 28/310 с премом (ну.. если считать тех, у кого в никнейме в конце эмоджи есть).

Забавно, что чуть больше года назад я считал и среди вас было всего 1.9% с премом, а сейчас аж 9! (хороший рост у канала кстати, всего минус 7 человек за год 😁. Считаю это успехом. Спасибо ❤️!)

Так вот это. Давайте вы мне буст (я просто ачивки люблю, так-то и даром не нужно), а я вам смешную сторис из своего опыта вспомню.

Вам нужно обновить телегу до последней версии и жмякнуть "Boost" под этим постом. Ну или перейти по этой ссылке : https://news.1rj.ru/str/ITrower?boost

Upd : первого уровня достигли ❤️ сторис запилен 🤡
Upd2 : и второго!
Upd3: до 4-ого бустанули. Аще вы люди-коты, конечно. Пасямбр!

Диди Мадлоба, Генацвале! 🥰