Куки подразумевают хранение состояния между запросами. Это позволяет передавать меньше данных, но добавляет проблем в масштабировании. Клиенту мастабироваться и не за чем, а для бекендов это полезно. Поэтому там удобнее stateless протоколы.
Чтобы поставить куку, нужно знать как минимум домен. Если бекенд обслуживает сайты на разных доменах, то нужно как-то тащить эту информацию. Все конечно решается, но количество костылей будет чрезмерным, по сравнению с тем, если так не делать.
Покси нужен, чтобы положить токен (или его аналог) в куку - когда никто другой больше так не делает. Ведь бекенды, кидаясь друг в дружку запросами, обычно ожидают токен в заголовке Authorization: Bearer, - как настоятельно рекомендует делать OAuth2, - а не в куках.
Когда начинающему фронтендеру прилетает задача достать данные из API голого бекенда, то первое что приходит на ум - надо где-то сохранять Authorization токен, чтобы не ходить за ним на каждый запрос. Ну и в добавок менеджер давит: а можешь сделать сам, без бекендера, а то он и так перегружен? В ответ предлагаются чудесные варианты решения на голом JS в браузере: с local/session storage, или самому установить себе куку. Работы на 5 митут. Собственно так и начинается содомия, от которой предостерегает автор в своей статье.
Если злоумышленник может выполнить код на клиенте, то он с таким же успехом получит cookie
HttpOnly кука не доступна для чтения из JavaScript на клиенте - злоумышленник не сможет увести её наружу через XSS, чтобы воспользоваться где-то в другом месте.
Недавно были похожие новости про Гугл, Майкрософт и кого-то ещё с удивительно похожим количеством сокращаемых. Интересно, это они сговорились порезать по 10К голов каждый, или просто совпадение?
Мне неизвестны конкретные цифры их TCO, но обычно саппорт это 90% расходов, если смотреть в масштабе всего жизненного цикла сервиса. Ну и косты там зависят не от сложности что-то накодить, а от рисков чего-нибудь сломать в процессе изменения и затрат на недопущение сбоев или восстановление.
Менять в любом случае приходится, как минимум исправляя проблемы безопасности. Но обычно к этому добавляется разная косметика, дополнительно раскачивающая систему - просто для того, чтобы получать в реальных ощущениях, что вы все ещё способны этим управлять. Маркетинг может помочь раздобыть ещё денег для продолжения этой тусы, но сокращения затрат там нет - это работа для других.
Чтобы понять логику разработчиков, надо смотреть языки где есть поддержка функционального программирования - не такая ущербная как в JS, но и не такая упоротая как в Haskell. Например OCaml.
Насколько я понимаю, цель дать разработчикам инструмент, позволяющий описывать интерфейс декларативно, но используя для этого лишь стандартные языковые конструкции JS. Без компромисса в виде метаязыка JSX все равно не получилось, но на то есть причины. В остальном они сначала долго пытались приспособить под задачу синтаксис классов, но потом перешли на функции.
Не в последнюю очередь потому, что народ продолжал по привычке думать в стиле ООП и сохранять состояние в свойствах объекта. Переубедить полмира это невозможно, а функции создают естественные ограничения.
Вы опять перекладываете ваши психологические травмы
Не, вы так ни кого не убедите - нет одного технического аргумента. :) На самом деле, будет лучше, если покажите пример удачного использования css-in-js. Ссылу на git такого проекта, например.
Зависит от частного бизнеса. Бывает так, что бюджет планируются на год вперёд. А на следующий год ни кто не хочет признать, что деньги потрачены впустую и выделяется бюджет ещё на год - ну чтобы наверняка все доделали, или хотя бы что-то показали). В общем по-разному бывает.
Лучший способ разобраться для новой команды это повторить.
На доскональное изучение существующей реализации или переписывание команда потратит примерно одинаковое время. Но во втором случае давление со стороны бизнеса будет меньше (если получится продать конечно).
"Ребята уже третий месяц чего-то пишут" выглядит лучше, чем "ребята уже третий месяц разбираются".
Если 30-40+ устроить релокацию, то получается вообще комбо: тот кто не способен ускакать из компании в привычной обстановке, в чужой стране становится вообще супер осознанным лояльным на долгие годы вперёд.
Атришен это проблема не только замкадья. В крупных компаниях, "да везде одно и то же, что по зарплате, что по работе".
Джунов в самом деле удерживают деньгами - с их костами повышение зряплаты даже в 2 раза по сравнению с тем что было на старте, это на самом деле копейки. И это развращает, поскольку создаёт ощущение, что так будет и дальше. Поэтому через два года проще отпустить страдать на свободу, а там уже сами все поймут.
Условному лиду так повышать уже дорого, особенно если вы живёте в прогрессивной стране с прогрессивной шкалой налогов. На разницу можно взять 5-7 новичков, если они вам нужны. Оно того стоит? Тут реально выгодно в неденежную мотивацию, даже если для этого надо содержать целый отдел симпатичных people partners (лучше junior).
Люди закладывают в картины куда больше деталей и смысла, зачастую замаскированного.
Чтобы зритель мог считывать смыслы, заложенные художником, он должен быть с ним в общем культурном контексте. Вспомнить пресловутый "Черный квадрат", перед показом которого непосвящённым, нужна вводная лекция на тему супрематизма.
Можно представить, что нейросетка сгенерирует нечто удивительное. Во всяком случае я не вижу проблем с тем, чтобы сделать "больше деталей и смысла". Но смогу-ли это понять люди, или сочтут за тарабарщину? Проблема interpretability результатов в ML сейчас очень актуальна.
В искусстве важна не только картинка, но и семантика (смысл, заложенный автором или считываемых зрителем, вызывающий эмоциональный отклик). Именно тогда это искусство.
Раньше все это ещё помножалось на проблему с тиражированием и поэтому хотели только оригинал. Потом из этого сделали культ и бизнес модель. Сейчас технологии постепенно сводят ее на нет.
Была история как художник изображал вымышленного сказочного персонажа (вроде змея Горыныча или какой-то дракона), взяв детали от реальных животных - змей, крокодилов и т.п. Людям сложно вообразить то, что они не видели. Возможно мы можем придумывать только химер, а весь креатив это лишь переработка прошлого опыта.
Интересно, получится данные из этого perf вывести в Chrome DevTools, чтобы не мучаться с SVG?
Куки подразумевают хранение состояния между запросами. Это позволяет передавать меньше данных, но добавляет проблем в масштабировании. Клиенту мастабироваться и не за чем, а для бекендов это полезно. Поэтому там удобнее stateless протоколы.
Чтобы поставить куку, нужно знать как минимум домен. Если бекенд обслуживает сайты на разных доменах, то нужно как-то тащить эту информацию. Все конечно решается, но количество костылей будет чрезмерным, по сравнению с тем, если так не делать.
Покси нужен, чтобы положить токен (или его аналог) в куку - когда никто другой больше так не делает. Ведь бекенды, кидаясь друг в дружку запросами, обычно ожидают токен в заголовке Authorization: Bearer, - как настоятельно рекомендует делать OAuth2, - а не в куках.
Когда начинающему фронтендеру прилетает задача достать данные из API голого бекенда, то первое что приходит на ум - надо где-то сохранять Authorization токен, чтобы не ходить за ним на каждый запрос. Ну и в добавок менеджер давит: а можешь сделать сам, без бекендера, а то он и так перегружен? В ответ предлагаются чудесные варианты решения на голом JS в браузере: с local/session storage, или самому установить себе куку. Работы на 5 митут. Собственно так и начинается содомия, от которой предостерегает автор в своей статье.
HttpOnly кука не доступна для чтения из JavaScript на клиенте - злоумышленник не сможет увести её наружу через XSS, чтобы воспользоваться где-то в другом месте.
Недавно были похожие новости про Гугл, Майкрософт и кого-то ещё с удивительно похожим количеством сокращаемых. Интересно, это они сговорились порезать по 10К голов каждый, или просто совпадение?
Мне неизвестны конкретные цифры их TCO, но обычно саппорт это 90% расходов, если смотреть в масштабе всего жизненного цикла сервиса. Ну и косты там зависят не от сложности что-то накодить, а от рисков чего-нибудь сломать в процессе изменения и затрат на недопущение сбоев или восстановление.
Менять в любом случае приходится, как минимум исправляя проблемы безопасности. Но обычно к этому добавляется разная косметика, дополнительно раскачивающая систему - просто для того, чтобы получать в реальных ощущениях, что вы все ещё способны этим управлять. Маркетинг может помочь раздобыть ещё денег для продолжения этой тусы, но сокращения затрат там нет - это работа для других.
Интересне увидеть что-то более практическое, чем отсылку к авторитетам. Вы же инженер.
В компании где я работаю, используют кучу разных технологий. Но это же не значит, что все они нам продолжают нравиться.
Чтобы понять логику разработчиков, надо смотреть языки где есть поддержка функционального программирования - не такая ущербная как в JS, но и не такая упоротая как в Haskell. Например OCaml.
Насколько я понимаю, цель дать разработчикам инструмент, позволяющий описывать интерфейс декларативно, но используя для этого лишь стандартные языковые конструкции JS. Без компромисса в виде метаязыка JSX все равно не получилось, но на то есть причины. В остальном они сначала долго пытались приспособить под задачу синтаксис классов, но потом перешли на функции.
Не в последнюю очередь потому, что народ продолжал по привычке думать в стиле ООП и сохранять состояние в свойствах объекта. Переубедить полмира это невозможно, а функции создают естественные ограничения.
Не, вы так ни кого не убедите - нет одного технического аргумента. :) На самом деле, будет лучше, если покажите пример удачного использования css-in-js. Ссылу на git такого проекта, например.
Какой-то такой этап, реакт уже проходил года 4 или 5 тому назад, то есть где-то между эпохами классов и хуков.
Одна из проблем с ним это стек-трейсы при отладке - дерево вызовов перестаёт отражать иерархию вложенности компонентов, уводя в бесполезные врапперы.
Зависит от частного бизнеса. Бывает так, что бюджет планируются на год вперёд. А на следующий год ни кто не хочет признать, что деньги потрачены впустую и выделяется бюджет ещё на год - ну чтобы наверняка все доделали, или хотя бы что-то показали). В общем по-разному бывает.
Лучший способ разобраться для новой команды это повторить.
На доскональное изучение существующей реализации или переписывание команда потратит примерно одинаковое время. Но во втором случае давление со стороны бизнеса будет меньше (если получится продать конечно).
"Ребята уже третий месяц чего-то пишут" выглядит лучше, чем "ребята уже третий месяц разбираются".
Спасибо за классный обзор программ для десктопа. Планируете-ли сделать аналогичный для серверных решений encryption at rest?
Вы заметили, что в варианте с done тест выполняется быстрее (345 секунд против 419)?
for { await waitForExpect(..) } запускает проверки строго последовательно - следующая стратует когда дождались результата предыдущей.
for { waitForExpect(..) }; Promise.all() запускает все проверки практически одновременно, а потом ждет когда они все завершатся.
Мне кажется такое преобразование, как минимум не эквивалентным, а может и ошибочным.
Если 30-40+ устроить релокацию, то получается вообще комбо: тот кто не способен ускакать из компании в привычной обстановке, в чужой стране становится вообще супер
осознаннымлояльным на долгие годы вперёд.Атришен это проблема не только замкадья. В крупных компаниях, "да везде одно и то же, что по зарплате, что по работе".
Джунов в самом деле удерживают деньгами - с их костами повышение зряплаты даже в 2 раза по сравнению с тем что было на старте, это на самом деле копейки. И это развращает, поскольку создаёт ощущение, что так будет и дальше. Поэтому через два года проще отпустить страдать на свободу, а там уже сами все поймут.
Условному лиду так повышать уже дорого, особенно если вы живёте в прогрессивной стране с прогрессивной шкалой налогов. На разницу можно взять 5-7 новичков, если они вам нужны. Оно того стоит? Тут реально выгодно в неденежную мотивацию, даже если для этого надо содержать целый отдел симпатичных people partners (лучше junior).
Чтобы зритель мог считывать смыслы, заложенные художником, он должен быть с ним в общем культурном контексте. Вспомнить пресловутый "Черный квадрат", перед показом которого непосвящённым, нужна вводная лекция на тему супрематизма.
Можно представить, что нейросетка сгенерирует нечто удивительное. Во всяком случае я не вижу проблем с тем, чтобы сделать "больше деталей и смысла". Но смогу-ли это понять люди, или сочтут за тарабарщину? Проблема interpretability результатов в ML сейчас очень актуальна.
Это как назвать автором учителя рисования, который учил художника.
В искусстве важна не только картинка, но и семантика (смысл, заложенный автором или считываемых зрителем, вызывающий эмоциональный отклик). Именно тогда это искусство.
Раньше все это ещё помножалось на проблему с тиражированием и поэтому хотели только оригинал. Потом из этого сделали культ и бизнес модель. Сейчас технологии постепенно сводят ее на нет.
Была история как художник изображал вымышленного сказочного персонажа (вроде змея Горыныча или какой-то дракона), взяв детали от реальных животных - змей, крокодилов и т.п. Людям сложно вообразить то, что они не видели. Возможно мы можем придумывать только химер, а весь креатив это лишь переработка прошлого опыта.