A cookie associated with a cross-site resource at _your_domain_ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.

Почему так?

Что случилось? Авария, ужас-ужас

Статью я захотел написать после работы над одним конкретным багом, который со всех точек зрения напоминал классическую утечку памяти, но на практике оказался чем то совершенно другим. Я нигде не встречал описание такого поведения и поэтому решил этой информацией поделиться.

В один прекрасный день боевое сопровождение приходит с ужасной проблемой — память в контейнерах Node.js течёт, сервисы падают с OOM каждый день, все пропало!

Да, картинка действительно удручающая. Всё время, когда есть нагрузка, память в контейнере прирастает и почти не очищается при снятии нагрузки. Все остальные метрики, которые мы собирали были в норме: event loop lag, использование CPU, active request, open handles. Прирастала только используемая память и незначительно увеличивалось время отклика сервиса.

Что-ж, выглядит как классическая утечка, надо искать источник.

В разговорах людей, интересующихся доступностью, часто можно услышать слово «Роль». Так, что это такое? Это специальная форма представления элемента для скринридера. Устанавливается она с помощью атрибута role. Сегодня поговорим о нем.

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

Давайте начнём!

Приветствую, друзья! В прошлой статье я предлагал на обсуждение какой-то бред, за который теперь стыдно черновик нового протокола аутентификации на сайтах. И хотя сейчас я значительно его переработал (с учетом ваших замечаний) и готовлю новую версию, я решил что стоит предварительно опубликовать несколько статей, которые будут раскрывать мотивы технических решений, закладываемых в новый протокол. А эта статья посвящается проблемам и техникам безопасной передачи и хранения сайтами ваших паролей.

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

Теперь кратко о себе: Я опасно некомпетентен в криптографии. Это всё, что вы должны обо мне знать.

Аутентификация пользователей — базовый функционал подавляющего большинства web-приложений. Этот функционал имплементирован с помощью различных языков программирования и поддерживается различными репозиториями ("хардкод", файлы, базы данных, LDAP, ...).

В предыдущей своей публикации я высказал смелое заблуждение "Пока же создание очередного web-приложения зачастую начинается с проектирования собственной структуры данных для аутентификации пользователей", на что мне было скинуто несколько ссылок на некоторые имплементации аутентификации (в основном — на PHP). Под катом — сравнение структур User-моделей этих имплементаций.

И снова про управление вентиляцией. Сначала мы с вами собрали вентустановку с водяным нагревом воздуха. И подобрали электронику, необходимую для управления ею, из производимых Wiren Board устройств. Следующим шагом мы сделали то же самое для электрического нагрева воздуха.

Теперь пора перейти к самому вкусному — к разработке алгоритмов управления нашей вентустановкой и написанию скриптов. Дальше будет много текста не развлекательного характера, но если вы доберетесь до конца, то сможете писать скрипты управления для контроллера Wiren Board. Не обязательно для вентустановок.

Можно ли сделать хорошо знакомое и массовое устройство ещё лучше? Конечно!

Расскажем о недостатках существующих адаптеров USB-RS485, поиске идеального решения и про весь процесс: от идеи до запуска серийного производства.

В обычной жизни я не только тестирую оборудование умного дома, но и очень много путешествую. Любимое хобби в поездках – трекинг, особенно в холмистой местности. Ходил я и по лестницам Непала, и по левадам Мадейры, и по козьим тропам Азорских островов. К чему это я? Многим облака кажутся милыми, белыми и пушистыми. Но когда ты поднимаешься по тропе, и тебя после определенной высоты накрывает облако, мало не покажется. Сыро, мокро, противно, а потом еще и скользко. Приходится разворачиваться и спускаться обратно, по скользкой каменистой тропе подниматься нельзя.

В индустрии информационных технологий в 2006 году появились свои облака, которые позволяют не тратиться на собственную инфраструктуру, а буквально в один клик использовать доступные сервисы, расположенные у облачного провайдера. Все очень просто: покупаешь «железку», ставишь приложение на смартфон, указываешь нужные сценарии – и все работает. Но нет ли здесь подвоха? Не станут ли облака препятствием, из-за которого придется разворачиваться и все менять? В этом мне как раз хочется разобраться вместе с читателями.

В первой статье цикла я рассмотрю полезные свойства облаков, расскажу о возможных рисках и приведу примеры. Можно ли пользоваться облаками, не подвергая риску автоматизацию умного дома? И как лучше всего это сделать?

Привет, Хабр! Меня зовут Станислав Игнатьев, я начальник отдела дизайна продуктов сервисов X5 Group. Мы проектируем интерфейсы для внешних и внутренних сервисов, например: подписка «Пакет», приложение «Пятёрочка», цифровая платформа для поставщиков Dialog.X5, приложения для работы сотрудников.

Сегодня я хотел бы рассказать, как и зачем мы создавали собственный шрифт.

Кризисное время всегда способствует переменам, в том числе в поиске новой профессии или приобретении опыта. Вот почему мы решили запустить рубрику Next Step о сотрудниках Х5 Tech, которые смогли поменять профессию внутри компании. Михаил Неверов, директор по анализу данных Х5 Tech, специально для нашего блога на Хабре рассказал о кардинальной смене профессии – как он решился на переход из продакта в Big Data, какие сложности пришлось преодолеть, как он справился с синдромом самозванца и каково это – возглавлять и успешно управлять департаментом по анализу данных из 130+ человек.

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

Патрик Завадски, старший разработчик ПО в компании Northwestern Mutual, подчеркивает, что практики и привычки могут различаться от разработчика к разработчику, от команды к команде и от компании к компании. В любом случае, важно знать разные подходы к написанию кода в React — это хорошее подспорье для программиста в поисках оптимального для него решения.

Под катом — наш перевод статьи*, в которой Патрик сосредоточился на отрицательных примерах: некоторых из худших React-практик, которые он когда-либо видел (а возможно даже использовал сам). Материал призван помочь вам избежать подобных ошибок в будущем.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Размытое зрение, стук по клавиатуре и одно глобальное правило продуктивности.

Я был там. Слишком долго работаю над проектом. Я начинаю ошибаться. Я теряю детали. Ошибки продолжают появляться, а качество падает.

Делаю что-нибудь творческое в течение нескольких часов, и это утомительно.

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

Великие умы всех времен имеют нечто общее:

1. Воспалительные процессы в полости рта.
2. Что бывает, когда бактерии оказались злобными анаэробами.
3. Что делать, если на картинках в посте вы узнали себя.

Проверка кода (code review) — отличный инструмент для повышения качества кода, но он не учитывает один факт: отправляют и просматривают код люди, а они устают, теряют сосредоточенность, ленятся, да и просто испытывают эмоции в самые неожиданные моменты.

Поэтому хочу представить свое видение хороших и плохих практик код ревью с учётом человеческих особенностей.

• IIFE модуль: шаблон JS модуля
• Открытый модуль: шаблон открытого JS модуля
• CJS модуль: CommonJS модуль или Node.js модуль
• AMD модуль: асинхронное определение модуля или RequireJS модуль
• UMD модуль: универсальное определение модуля или UmdJS модуль
• ES модуль: ECMAScript2015 или ES6 модуль
• ES динамический модуль: ECMAScript2020 или ES11 динамический модуль
• Системный модуль: SystemJS модуль
• Webpack модуль: транспиляция и сборка CJS, AMD и ES модулей
• Babel модуль: транспиляция ES модуля
• TypeScript модуль: транспиляция CJS, AMD, ES и SystemJS модулей

Рассмотрим следующее

1. JSS и немного о синтаксисе;
2. Стилизация классовых react, material компонентов;
3. Стилизация функциональных с использованием хуков react, material компонентов;
4. Стилизация посредством styledComponent react, material компонентов;
5. Провайдер theme;
6. Переопределение material компонентов;

GO под кат!