Проблема 2000 пришла на 22 года позже
В новогоднюю ночь сломались все онпремиз сервера Microsoft Exchange 2016/2019 из-за того, что антиспам фильтр там хранит дату yyMMddhhmm в инте, а 2201010000 в него не влазит. В итоге компании по всему миру массово отрубают антиспам, чтобы корпоративная почта хоть как-то работала
yyMMddhhmm в целочисленном типе. Сколько ещё мы не знаем о продуктах, которые используем
#news
В новогоднюю ночь сломались все онпремиз сервера Microsoft Exchange 2016/2019 из-за того, что антиспам фильтр там хранит дату yyMMddhhmm в инте, а 2201010000 в него не влазит. В итоге компании по всему миру массово отрубают антиспам, чтобы корпоративная почта хоть как-то работала
yyMMddhhmm в целочисленном типе. Сколько ещё мы не знаем о продуктах, которые используем
#news
😱6💩2
Сколько нужно стендов/энвайроментов в Trunk Based Development подходе
Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?
🦄 Если у вас возник вопрос, при чем здесь единороги, смотрите предыдущий пост.
В зависимости от вашей философии разработки и готовности экспериментировать, правильным ответом может быть 2️⃣, 3️⃣ или 4️⃣.
Давайте рассмотрим каждый из них.
Но начнем с 1️⃣. Single Environment — вполне себе жизнеспособный подход. В Trunk Based Development основная ветка считается стабильной, новый функционал скрыт фича тогглами, поэтому ничего не мешает жить с одним окружением. При условии, если архитектура вашей системы позволяет гарантировать стабильность транк-веток репозиториев всех компонентов без интеграционных тестов между этими компонентами и без инструментов типа Terraform или Helm для управления инфраструктурой. Ну или у вас огромное количество времени и вычислительных можностей и внутри CI/CD пайплайна вы каждый раз поднимаете мини-энв. Поэтому от сферических единорожков перейдем к реальным. 🌈
2️⃣ окружения. Итак, нам нужно иметь возможность проверять изменения кода до того, как они попали в основную ветку. Очень простой рецепт — вешаем CI триггер на пуллреквесты.
Алгоритм следующий: разработчик создает свою короткоживущую веточку, делает изменения, тестирует их локально. Потом пушит и делает пуллреквест в основную. CI собирает компонент, делает статический анализ (линтер или SonarQube), прогоняет юнит тесты, упаковывает в докер и разворачивает на отдельном стенде (обычно мы называем этот стенд dev или sandbox, давайте и будем называть его песочницей). Тут же в пайплайне запускаются автотесты (для бэкенда достаточно API тестов, для фронтенда тестов в headless браузере). При этом на любом шаге, если что-то сломалось, пайплайн не завершится и песочнца будет сломана. Но откатиться до предыдущего состояния можно, просто сделав реверс пуллреквест.
Если все прошло успешно, это означает, что новые изменения не ломают предыдущей логики, зафиксированной тестами. Разработчик может протестировать новый функционал на стенде, и после этого отправить пуллреквест на ревью.
То есть на ревью попадает пуллреквест, который заведомо ничего не сломает. Поэтому ревьюеры могут сконцентрироваться на проверке бизнес-функционала, а не на отлове возможных несовместимостей. После ревью изменения мерджатся в основную ветку и проходят все те же шаги сборки и регрессии, но уже на втором, боевом стенде. С каждым изменением единорожек эволюционирует.
У предыдущего подхода есть минус. Он защищает нас от того, что сломается автоматизация инфраструктуры и бизнес логика. Но не защитит от некорректных данных в БД, а это иногда становится большой проблемой. В варианте с двумя окружениями второй, стабильный энв содержит и тестовые и продакшн данные. Чтобы физически изолировать их, можно добавить третий стенд. 3️⃣
Итак, первый стенд — sandbox, разработчики могут его ломать и экспериментировать еще до ревью
Второй — test, он содержит код, собранный из основных веток, но он предназначен только для тестирования нового функционала. Теоретически на нем можно сломать данные, тестируя какие-нибудь негативные сценарии (А что будет, если напоить единорога самогоном вместо утренней росы? 🤮)
Третий — prod, и там разворачиваются те же самые артефакты, что были собраны на предыдущем шаге. При этом хорошей практикой считается раскатывать сюда новую версию сервиса, как только она прошла авторегрессию на тесте. Мы все еще находимся в парадигме Continuous Deployment и Shift Right (см предыдущий пост), но тестовое окружение физически отделено от продакшена.
Какой подход вам нравится больше всего?
#rdclr_backend #rdclr_frontend #product
Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?
🦄 Если у вас возник вопрос, при чем здесь единороги, смотрите предыдущий пост.
В зависимости от вашей философии разработки и готовности экспериментировать, правильным ответом может быть 2️⃣, 3️⃣ или 4️⃣.
Давайте рассмотрим каждый из них.
Но начнем с 1️⃣. Single Environment — вполне себе жизнеспособный подход. В Trunk Based Development основная ветка считается стабильной, новый функционал скрыт фича тогглами, поэтому ничего не мешает жить с одним окружением. При условии, если архитектура вашей системы позволяет гарантировать стабильность транк-веток репозиториев всех компонентов без интеграционных тестов между этими компонентами и без инструментов типа Terraform или Helm для управления инфраструктурой. Ну или у вас огромное количество времени и вычислительных можностей и внутри CI/CD пайплайна вы каждый раз поднимаете мини-энв. Поэтому от сферических единорожков перейдем к реальным. 🌈
2️⃣ окружения. Итак, нам нужно иметь возможность проверять изменения кода до того, как они попали в основную ветку. Очень простой рецепт — вешаем CI триггер на пуллреквесты.
Алгоритм следующий: разработчик создает свою короткоживущую веточку, делает изменения, тестирует их локально. Потом пушит и делает пуллреквест в основную. CI собирает компонент, делает статический анализ (линтер или SonarQube), прогоняет юнит тесты, упаковывает в докер и разворачивает на отдельном стенде (обычно мы называем этот стенд dev или sandbox, давайте и будем называть его песочницей). Тут же в пайплайне запускаются автотесты (для бэкенда достаточно API тестов, для фронтенда тестов в headless браузере). При этом на любом шаге, если что-то сломалось, пайплайн не завершится и песочнца будет сломана. Но откатиться до предыдущего состояния можно, просто сделав реверс пуллреквест.
Если все прошло успешно, это означает, что новые изменения не ломают предыдущей логики, зафиксированной тестами. Разработчик может протестировать новый функционал на стенде, и после этого отправить пуллреквест на ревью.
То есть на ревью попадает пуллреквест, который заведомо ничего не сломает. Поэтому ревьюеры могут сконцентрироваться на проверке бизнес-функционала, а не на отлове возможных несовместимостей. После ревью изменения мерджатся в основную ветку и проходят все те же шаги сборки и регрессии, но уже на втором, боевом стенде. С каждым изменением единорожек эволюционирует.
У предыдущего подхода есть минус. Он защищает нас от того, что сломается автоматизация инфраструктуры и бизнес логика. Но не защитит от некорректных данных в БД, а это иногда становится большой проблемой. В варианте с двумя окружениями второй, стабильный энв содержит и тестовые и продакшн данные. Чтобы физически изолировать их, можно добавить третий стенд. 3️⃣
Итак, первый стенд — sandbox, разработчики могут его ломать и экспериментировать еще до ревью
Второй — test, он содержит код, собранный из основных веток, но он предназначен только для тестирования нового функционала. Теоретически на нем можно сломать данные, тестируя какие-нибудь негативные сценарии (А что будет, если напоить единорога самогоном вместо утренней росы? 🤮)
Третий — prod, и там разворачиваются те же самые артефакты, что были собраны на предыдущем шаге. При этом хорошей практикой считается раскатывать сюда новую версию сервиса, как только она прошла авторегрессию на тесте. Мы все еще находимся в парадигме Continuous Deployment и Shift Right (см предыдущий пост), но тестовое окружение физически отделено от продакшена.
Какой подход вам нравится больше всего?
#rdclr_backend #rdclr_frontend #product
Telegram
RDCLR.DEV
Trunk Based Development: техники и определения
Давайте разберем термины из предыдущего поста
Branch By Abstraction — пожалуй, краеугольный камень TBD. Попробуем объяснить эту технику на единорожках. У нас есть обычная лошадка 🐴, но мы понимаем, что вообще…
Давайте разберем термины из предыдущего поста
Branch By Abstraction — пожалуй, краеугольный камень TBD. Попробуем объяснить эту технику на единорожках. У нас есть обычная лошадка 🐴, но мы понимаем, что вообще…
🔥4
Отдельно рассмотрим вариант с 4️⃣ стендами.
Он может применяться, когда по внутренним регламентам или соображениям безопастности мы сознательно отказываемся от Continuous Deployment на прод. Мы изобрели этот гибридный подход, чтобы оставить нашему единорожку возможность бесшовно эволюционировать
🐴🔜🦄 и, в то же время, иметь возможность выпускать его на волю дискретными релизами.
Какая проблема возникает при отказе от Continuous Deployment? То, что нам приходится где-то замораживать версию продукта для стабилизации, но при этом мы не хотим останавливать разработку нового функционала. Поэтому можно использовать следующий поход:
sandbox и test остаются как и в предыдущем варианте — это инкубатор, где единорог постепенно эволюционирует.
Как только мы понимаем, что он достаточно хорош, нам приходится его клонировать, отсаживая в отдельный загончик — релизную ветку. Оттуда собираются артефакты на третий промежуточный стенд — stage. На нем происходит стабилизация, после чего единорожка выпускается на волю (на prod), а релизная ветка со всеми багфиксами тэгается, мерджится обратно в транк и закрывается. При этом основную ветку ничто не останавливает и она уходит вперед.
🐛 Если находится критический баг на продакшене, мы можем выпустить патч-релиз. Для этого мы просто восстанавливаем релизную ветку нужного сервиса из тэга и используем stage для новых изменений в нашем загончике, после чего он снова попадает на prod, а изменения тэгаются, мержатся в основную ветку, а патч-ветка закрывается.
При таком подходе мы все еще остаемся в парадигме Trunk Based Development, т.к. у нас
- одна основная ветка (trunk), 🦋
- короткоживущие фича ветки для эволюции (slfb),
- релизные ветки, которые живут только в период стабилизации,
- стабилизационные багфикс ветки, которые живут еще меньше, чем релизная
#rdclr_backend #rdclr_frontend #product
Он может применяться, когда по внутренним регламентам или соображениям безопастности мы сознательно отказываемся от Continuous Deployment на прод. Мы изобрели этот гибридный подход, чтобы оставить нашему единорожку возможность бесшовно эволюционировать
🐴🔜🦄 и, в то же время, иметь возможность выпускать его на волю дискретными релизами.
Какая проблема возникает при отказе от Continuous Deployment? То, что нам приходится где-то замораживать версию продукта для стабилизации, но при этом мы не хотим останавливать разработку нового функционала. Поэтому можно использовать следующий поход:
sandbox и test остаются как и в предыдущем варианте — это инкубатор, где единорог постепенно эволюционирует.
Как только мы понимаем, что он достаточно хорош, нам приходится его клонировать, отсаживая в отдельный загончик — релизную ветку. Оттуда собираются артефакты на третий промежуточный стенд — stage. На нем происходит стабилизация, после чего единорожка выпускается на волю (на prod), а релизная ветка со всеми багфиксами тэгается, мерджится обратно в транк и закрывается. При этом основную ветку ничто не останавливает и она уходит вперед.
🐛 Если находится критический баг на продакшене, мы можем выпустить патч-релиз. Для этого мы просто восстанавливаем релизную ветку нужного сервиса из тэга и используем stage для новых изменений в нашем загончике, после чего он снова попадает на prod, а изменения тэгаются, мержатся в основную ветку, а патч-ветка закрывается.
При таком подходе мы все еще остаемся в парадигме Trunk Based Development, т.к. у нас
- одна основная ветка (trunk), 🦋
- короткоживущие фича ветки для эволюции (slfb),
- релизные ветки, которые живут только в период стабилизации,
- стабилизационные багфикс ветки, которые живут еще меньше, чем релизная
#rdclr_backend #rdclr_frontend #product
Telegram
RDCLR.DEV
Сколько нужно стендов/энвайроментов в Trunk Based Development подходе
Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?
🦄 Если у вас возник вопрос…
Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?
🦄 Если у вас возник вопрос…
👍3
Всем привет! На этой неделе продолжим разговор о доступности и поговорим о спецификации, позволяющей вам быстро и просто повысить доступность интерфейса не только для нового кода, но и в текущих проектах в рамках поддержки. С вами буду я, Артём, frontend-разработчик.
👌Повышаем доступность: WAI-ARIA
Спецификация ARIA или Accessible Rich Internet Applications - это простой и понятный разработчику инструмент. ARIA можно разделить на две основных секции: это role-атрибуты и собственно aria-атрибуты.
🦹♀️🦸♀️Роли
Ранее мы обсуждали необходимость применения семантической разметки в html. Самое простое, что могут предоставить role-атрибуты - это определить семантику для «чистых» элементов вроде div или span. Важный момент: речь идет только о семантике, но не о поведении или стилизации.
Например, вы можете передать элементу атрибут role="main", role="navigation" и т. д., и он станет семантически эквивалентным тегу main или nav.
Или в вашем приложении есть форма, которая работает по ajax, но по той или иной причине она не является элементом form, при помощи ARIA вы можете снабдить форму атрибутом role="form".
🗿Это так называемые landmark roles. Но задачи role-атрибутов не ограничиваются композицией и семантикой.
🚨Например, атрибуты role="alert", role="alertdialog", role="dialog" могут маркировать динамические элементы, появляющиеся на странице как реакция на действия пользователя. Первый предусмотрен для всплывающих уведомлений (об ошибке или об успешном действии), второй и третий – для обработки диалогового или модального окна, то есть для случаев, когда нужно не только максимально быстро уведомить пользователя о чем-то, но еще и получить от него фидбэк. Браузер будет обрабатывать содержимое таких элементов только тогда, когда они видимы, и игнорировать, если для них установлен display: none или visibility: hidden.
🖲Также не забудем о любимом многими role="button", который позволит сделать из любого div’а кнопку. Не совсем полноценную, а потому частичную обработку состояний вам нужно будет взять на себя. Например, состояние disabled на role="button" не реализуется браузером нативно, но такой элемент уже может получать фокус, что уже лучше, чем ничего.
#rdclr_frontend
👌Повышаем доступность: WAI-ARIA
Спецификация ARIA или Accessible Rich Internet Applications - это простой и понятный разработчику инструмент. ARIA можно разделить на две основных секции: это role-атрибуты и собственно aria-атрибуты.
🦹♀️🦸♀️Роли
Ранее мы обсуждали необходимость применения семантической разметки в html. Самое простое, что могут предоставить role-атрибуты - это определить семантику для «чистых» элементов вроде div или span. Важный момент: речь идет только о семантике, но не о поведении или стилизации.
Например, вы можете передать элементу атрибут role="main", role="navigation" и т. д., и он станет семантически эквивалентным тегу main или nav.
Или в вашем приложении есть форма, которая работает по ajax, но по той или иной причине она не является элементом form, при помощи ARIA вы можете снабдить форму атрибутом role="form".
🗿Это так называемые landmark roles. Но задачи role-атрибутов не ограничиваются композицией и семантикой.
🚨Например, атрибуты role="alert", role="alertdialog", role="dialog" могут маркировать динамические элементы, появляющиеся на странице как реакция на действия пользователя. Первый предусмотрен для всплывающих уведомлений (об ошибке или об успешном действии), второй и третий – для обработки диалогового или модального окна, то есть для случаев, когда нужно не только максимально быстро уведомить пользователя о чем-то, но еще и получить от него фидбэк. Браузер будет обрабатывать содержимое таких элементов только тогда, когда они видимы, и игнорировать, если для них установлен display: none или visibility: hidden.
🖲Также не забудем о любимом многими role="button", который позволит сделать из любого div’а кнопку. Не совсем полноценную, а потому частичную обработку состояний вам нужно будет взять на себя. Например, состояние disabled на role="button" не реализуется браузером нативно, но такой элемент уже может получать фокус, что уже лучше, чем ничего.
#rdclr_frontend
👍5
ARIA-атрибуты можно условно разделить на описательные атрибуты и атрибуты состояния.
✍️Описательные атрибуты
Пожалуй, самым часто используемым на практике атрибутом является aria-label, он позволяет привязать к элементу текстовое описание, если он сам не может (или не хочет) иметь свой текст.
🏷А вот aria-labelledby позволяет не указывать отдельный текст, а привязать к элементу текст из другого элемента по его id (что-то вроде атрибута for у label’а, только наоборот). Это бывает очень удобно для того, чтобы описать группу элементов, например, группу радиокнопок.
⚠️Атрибут aria-errormessage хоть и работает только в паре с атрибутом состояния aria-invalid, все же выполняет функцию описания: он как и aria-labelledby ссылается на элемент, который содержит текст ошибки. Его можно присваивать элементам формы, но браузер будет его игнорировать до тех пор, пока атрибут aria-invalid этого элемента не получит true.
🚦Атрибуты состояний
К этой категории относятся, например, такие атрибуты, как aria-checked, aria-selected, aria-disabled, aria-hidden, aria-invalid, aria-expanded и многие другие. Они используются для маркирования состояний динамических блоков: пометка активного таба или выбранной опции в списке, пометка развернутого аккордеона, скрытого контента и т. д. Так как речь идет о состояниях, то управлять ими приходится динамически при помощи javascript.
🚀С помощью атрибутов мы также можем управлять тем, как скринридер будет реагировать на динамические изменения. За это отвечают aria-live, aria-atomic, aria-relevant и aria-busy.
#rdclr_frontend
✍️Описательные атрибуты
Пожалуй, самым часто используемым на практике атрибутом является aria-label, он позволяет привязать к элементу текстовое описание, если он сам не может (или не хочет) иметь свой текст.
🏷А вот aria-labelledby позволяет не указывать отдельный текст, а привязать к элементу текст из другого элемента по его id (что-то вроде атрибута for у label’а, только наоборот). Это бывает очень удобно для того, чтобы описать группу элементов, например, группу радиокнопок.
⚠️Атрибут aria-errormessage хоть и работает только в паре с атрибутом состояния aria-invalid, все же выполняет функцию описания: он как и aria-labelledby ссылается на элемент, который содержит текст ошибки. Его можно присваивать элементам формы, но браузер будет его игнорировать до тех пор, пока атрибут aria-invalid этого элемента не получит true.
🚦Атрибуты состояний
К этой категории относятся, например, такие атрибуты, как aria-checked, aria-selected, aria-disabled, aria-hidden, aria-invalid, aria-expanded и многие другие. Они используются для маркирования состояний динамических блоков: пометка активного таба или выбранной опции в списке, пометка развернутого аккордеона, скрытого контента и т. д. Так как речь идет о состояниях, то управлять ими приходится динамически при помощи javascript.
🚀С помощью атрибутов мы также можем управлять тем, как скринридер будет реагировать на динамические изменения. За это отвечают aria-live, aria-atomic, aria-relevant и aria-busy.
#rdclr_frontend
🔥5👍3
👨💻Сегодня немного практических примеров👩💻
1️⃣Дизайнер нарисовал поп-ап с каким-то контентом и классическим крестиком в углу, чтобы его можно было закрыть. См. первый пример — в листинге реализация кнопки с крестиком, которая не нарушает принципы доступности.
2️⃣В одном из прошлых постов я показывал пример формы с нативными элементами. Теперь представим ситуацию, когда мы точно знаем, что по тем или иным причинам мы не можем использовать нативные элементы, поэтому все контролы мы будем кастомить. При помощи aria-атрибутов мы можем это реализовать, не ухудшая их доступность. Однако следует помнить, что теперь абсолютно всё поведение элементов вам нужно будет реализовывать при помощи javascript.
3️⃣Такая структура, как табы, не имеет нативного семантического представления. Кроме того было бы логично представить табы как набор секций со своей структурой контента внутри, переключаемых кнопками. При помощи role-атрибутов мы можем добавить им семантики и повысить доступность.
#rdclr_frontend
1️⃣Дизайнер нарисовал поп-ап с каким-то контентом и классическим крестиком в углу, чтобы его можно было закрыть. См. первый пример — в листинге реализация кнопки с крестиком, которая не нарушает принципы доступности.
2️⃣В одном из прошлых постов я показывал пример формы с нативными элементами. Теперь представим ситуацию, когда мы точно знаем, что по тем или иным причинам мы не можем использовать нативные элементы, поэтому все контролы мы будем кастомить. При помощи aria-атрибутов мы можем это реализовать, не ухудшая их доступность. Однако следует помнить, что теперь абсолютно всё поведение элементов вам нужно будет реализовывать при помощи javascript.
3️⃣Такая структура, как табы, не имеет нативного семантического представления. Кроме того было бы логично представить табы как набор секций со своей структурой контента внутри, переключаемых кнопками. При помощи role-атрибутов мы можем добавить им семантики и повысить доступность.
#rdclr_frontend
🔥2
👩💻Инструменты разработчика
Сегодня расскажу немного об инструментах, которые позволят вам легче разрабатывать и тестировать интерфейсы с точки зрения их доступности.
🛠Браузерные тулзы
Первое, на что стоит обратить внимание, это те средства, которые поставляют сами разработчики браузеров: в Chrome и FireFox есть неплохие «Инспекторы доступности», которые позволяют исследовать дерево и такие вещи как контрастность цветов по отношению к фону. Кроме того, в Google Chrome встроен мощный инструмент Lighthouse, который может проводить аудит не только по производительности и Web Vitals, но и по доступности.
🌐Браузерные расширения
Инструменты аудита доступности чаще всего поставляются в виде браузерного расширения. Сюда относятся такие штуки, как Axe DevTools, Accessibility Insights и Wave от организации WebAIM. Попробуйте что-нибудь из этого списка и проведите для примера аудиты нескольких страниц в своих проектах, чтобы выбрать удобный для себя инструмент.
📺Скринридеры
В предыдущих постах я часто упоминал скринридеры, и для разработчика это тоже инструмент. С его помощью вы можете сами услышать, как подобные приложения «озвучивают» дерево доступности вашего интерфейса. В первую очередь обратите внимание на средства от разработчиков ОС: в состав системы macOS включен VoiceOver, а для Windows есть диктор Windows Narrator. Также существуют скрин-ридеры в виде браузерных расширений, например, Chrome Vox или Screen Reader от Google или Read Aloud, встроенный в Microsoft Edge.
⌨Ну, и самый основной инструмент, как это ни странно, – это ваша клавиатура 😊Если вы можете беспрепятственно взаимодействовать с вашим интерфейсом при помощи клавиатуры – это уже большая победа.
#rdclr_frontend
Сегодня расскажу немного об инструментах, которые позволят вам легче разрабатывать и тестировать интерфейсы с точки зрения их доступности.
🛠Браузерные тулзы
Первое, на что стоит обратить внимание, это те средства, которые поставляют сами разработчики браузеров: в Chrome и FireFox есть неплохие «Инспекторы доступности», которые позволяют исследовать дерево и такие вещи как контрастность цветов по отношению к фону. Кроме того, в Google Chrome встроен мощный инструмент Lighthouse, который может проводить аудит не только по производительности и Web Vitals, но и по доступности.
🌐Браузерные расширения
Инструменты аудита доступности чаще всего поставляются в виде браузерного расширения. Сюда относятся такие штуки, как Axe DevTools, Accessibility Insights и Wave от организации WebAIM. Попробуйте что-нибудь из этого списка и проведите для примера аудиты нескольких страниц в своих проектах, чтобы выбрать удобный для себя инструмент.
📺Скринридеры
В предыдущих постах я часто упоминал скринридеры, и для разработчика это тоже инструмент. С его помощью вы можете сами услышать, как подобные приложения «озвучивают» дерево доступности вашего интерфейса. В первую очередь обратите внимание на средства от разработчиков ОС: в состав системы macOS включен VoiceOver, а для Windows есть диктор Windows Narrator. Также существуют скрин-ридеры в виде браузерных расширений, например, Chrome Vox или Screen Reader от Google или Read Aloud, встроенный в Microsoft Edge.
⌨Ну, и самый основной инструмент, как это ни странно, – это ваша клавиатура 😊Если вы можете беспрепятственно взаимодействовать с вашим интерфейсом при помощи клавиатуры – это уже большая победа.
#rdclr_frontend
👍9
📕Что почитать о доступности
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
1️⃣Интерактивные примеры по конкретным атрибутам ARIA на сайте w3c. Переходим в интересующий раздел, открываем devtools и изучаем структуру страницы.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/
2️⃣Достаточно полный справочник MDN по role- и aria-атрибутам.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
3️⃣Пример реализации focus trapping на сайте w3c.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
4️⃣Но не забываем про inert-polyfill, с ним это реализовать гораздо проще, плюс в будущем он может быть реализован нативно.
https://github.com/WICG/inert
5️⃣Хорошие примеры нативных элементов форм. Если вам нужны стилизованные формы с полными нативными возможностями без js-а.
http://wtfforms.com/
6️⃣В продолжение темы — опенсорсная либа паттернов, реализующих доступность, с примерами и демками.
https://a11y-style-guide.com/style-guide/
#rdclr_frontend #read
👍5
Всем привет! Меня зовут Макс и следующую неделю я буду стараться заинтересовать вас постами на этом канале.
Если кратко — я тимлид, Java Dev, немного DevOps и совсем чуть-чуть архитектор в Red Collar. В своих постах буду касаться совершенно разных тем. Надеюсь, вам понравится =)
Если кратко — я тимлид, Java Dev, немного DevOps и совсем чуть-чуть архитектор в Red Collar. В своих постах буду касаться совершенно разных тем. Надеюсь, вам понравится =)
👍17❤6🔥1
Ревью кода: кросс-ревью. Практики тим-лидов
Итак. Сегодня я хочу коснуться направления тимлидерства, а в частности этапа разработки называемого Ревью кода.
На своем опыте встречал совершенно разное отношение к этой церемонии:
- кто-то считает, что код нужно поставлять быстро и на ревью нет времени;
- кто-то считает, что код нужно ревьюить, но не всегда;
- кто-то считает, что в команде есть ведущий сеньор или тим-лид, и только он имеет право ревьюить чужой код.
Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.
🦀 Кросс-ревью — это проверка кода всеми членами команды.
А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉
#teamlead #rdclr_backend #rdclr_frontend
Итак. Сегодня я хочу коснуться направления тимлидерства, а в частности этапа разработки называемого Ревью кода.
На своем опыте встречал совершенно разное отношение к этой церемонии:
- кто-то считает, что код нужно поставлять быстро и на ревью нет времени;
- кто-то считает, что код нужно ревьюить, но не всегда;
- кто-то считает, что в команде есть ведущий сеньор или тим-лид, и только он имеет право ревьюить чужой код.
Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.
🦀 Кросс-ревью — это проверка кода всеми членами команды.
А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉
#teamlead #rdclr_backend #rdclr_frontend
👍8❤2
В чем же преимущество концепции кросс-ревью?
🐗 В первую очередь, минимизируется шанс ошибок в поставляемом коде. Даже опытный разработчик может допускать небольшие ошибки по невнимательности, и даже разработчик без продакшн опыта может такие ошибки заметить.
🐧 Более того, при таком подходе к разработке происходят постоянные дискуссии между разработчиками на счет того какой подход лучше, а все мы знаем, что в спорах рождается истина.
🐌 Также, каждый член команды разработки находится up to date с последними изменениями в коде (которого, возможно, он даже раньше не касался).
Ну и самое главное! Даже если вы не находите ошибок (что на самом деле хорошо) или у вас нет предложений по улучшению, в любом случае при просмотре чужого кода всегда можно научиться чему-нибудь новому. 🪱 Если вы встертили что-то неизвестное вам, вы всегда можете задать несколько вопросов и расширить свои знания.
#teamlead #rdclr_frontend
🐗 В первую очередь, минимизируется шанс ошибок в поставляемом коде. Даже опытный разработчик может допускать небольшие ошибки по невнимательности, и даже разработчик без продакшн опыта может такие ошибки заметить.
🐧 Более того, при таком подходе к разработке происходят постоянные дискуссии между разработчиками на счет того какой подход лучше, а все мы знаем, что в спорах рождается истина.
🐌 Также, каждый член команды разработки находится up to date с последними изменениями в коде (которого, возможно, он даже раньше не касался).
Ну и самое главное! Даже если вы не находите ошибок (что на самом деле хорошо) или у вас нет предложений по улучшению, в любом случае при просмотре чужого кода всегда можно научиться чему-нибудь новому. 🪱 Если вы встертили что-то неизвестное вам, вы всегда можете задать несколько вопросов и расширить свои знания.
#teamlead #rdclr_frontend
👍6❤2
Вы подумали это все? А вот и нет =)
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.
👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.
🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.
Всем тем, кто поставил аппрув не глядя, следует в доступной форме объяснить важность данной церемонии и попросить больше так не делать. Пара повторных подобных проверок (можно подговорить еще кого-нибудь из команды) — и ваш код будет просматриваться детальнее, чем сумка на таможне.
📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).
Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).
Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.
👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.
🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.
Всем тем, кто поставил аппрув не глядя, следует в доступной форме объяснить важность данной церемонии и попросить больше так не делать. Пара повторных подобных проверок (можно подговорить еще кого-нибудь из команды) — и ваш код будет просматриваться детальнее, чем сумка на таможне.
📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).
Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).
Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend
👍10❤2
Сегодня мы пойдем по стезе DevOps. 🍩
Уверен, многие в разные моменты своей жизни сталкивались с мыслью:
«Я сделал свою задачу, написал рабочий код. А потом высшие силы переместили его на сервер».
Зачастую этой проблемой занимается DevOps в вашей команде, а вы не имеете возможности (или просто не хотите) погрузиться в эту магию.
В последующих постах я не буду останавливаться на конкретных способах написания каких-либо CI/CD пайплайнов (это тема для целой статьи), но я хочу вас познакомить с одним из самых интересных и удобных подходов описания конечной инфраструктуры системы, чтобы приоткрыть немного завесу этой магии.
#rdclr_DevOps
Уверен, многие в разные моменты своей жизни сталкивались с мыслью:
«Я сделал свою задачу, написал рабочий код. А потом высшие силы переместили его на сервер».
Зачастую этой проблемой занимается DevOps в вашей команде, а вы не имеете возможности (или просто не хотите) погрузиться в эту магию.
В последующих постах я не буду останавливаться на конкретных способах написания каких-либо CI/CD пайплайнов (это тема для целой статьи), но я хочу вас познакомить с одним из самых интересных и удобных подходов описания конечной инфраструктуры системы, чтобы приоткрыть немного завесу этой магии.
#rdclr_DevOps
👍8❤3
Концепция: IaC
Для начала, дабы не оставлять пробелов в теме поставки решений на сервер, одним предложением скажу, что происходит.
Для удобства ведения повествования представим, что мы пишем java-проект, на микросервисной архитектуре и хотим его положить в Kubernetes.
Зачастую DevOps пишет пайплайн, в котором сначала ваш код билдится в исполняемый файл, потом оборачивается в Docker image и сохраняется в registry. (Это классический пайплайн, но, естестественно, в зависимости от разных факторов он может выглядеть совершенно иначе)
Что же происходит после всего этого?
🧳 Есть разные решения этого способа поставки, но я хочу остановиться на концепции IaC (Infrastructure-as-Code).
Из названия понятно только то, что мы можем как-то кодом описать инфраструктуру. По факту это и есть самое большое преимущество данной концепции:
🧦 описывая инфраструктуру кодом, мы можем заливать этот код в репозитории и иметь версионирование всей инфраструктуры;
🧤 т.к. это код, мы можем выделить повторяющиеся участки кода и переиспользовать их, кастомизируя параметрами;
🧣 будучи разработчиком, научиться подобному языку не составит большого труда.
Следующим постом я хочу познакомить вас с одной из реализаций данного подхода — Terraform. А еще рассказать о самом большом преимуществе концепции IaC
#rdclr_DevOps
Для начала, дабы не оставлять пробелов в теме поставки решений на сервер, одним предложением скажу, что происходит.
Для удобства ведения повествования представим, что мы пишем java-проект, на микросервисной архитектуре и хотим его положить в Kubernetes.
Зачастую DevOps пишет пайплайн, в котором сначала ваш код билдится в исполняемый файл, потом оборачивается в Docker image и сохраняется в registry. (Это классический пайплайн, но, естестественно, в зависимости от разных факторов он может выглядеть совершенно иначе)
Что же происходит после всего этого?
🧳 Есть разные решения этого способа поставки, но я хочу остановиться на концепции IaC (Infrastructure-as-Code).
Из названия понятно только то, что мы можем как-то кодом описать инфраструктуру. По факту это и есть самое большое преимущество данной концепции:
🧦 описывая инфраструктуру кодом, мы можем заливать этот код в репозитории и иметь версионирование всей инфраструктуры;
🧤 т.к. это код, мы можем выделить повторяющиеся участки кода и переиспользовать их, кастомизируя параметрами;
🧣 будучи разработчиком, научиться подобному языку не составит большого труда.
Следующим постом я хочу познакомить вас с одной из реализаций данного подхода — Terraform. А еще рассказать о самом большом преимуществе концепции IaC
#rdclr_DevOps
👍6❤1
Реализация IaC: Terraform
Terraform — это детище компании Hashicorp для декларативного управления инфраструктурой проекта.
Он предоставляет нам полный контроль над каждым элементом инфраструктуры в одном проекте. Дает возможность параметризировать всю инфраструктуру.
Это значит, что если нам нужно поднять клон нашей инфраструктуры — мы это делаем всего лишь заменой пары параметров (в том числе их можно передать на уровне пайплайна).
Ознакомиться с данным чудом можно на сайте Terraform.
💥 Одно из преимуществ использования Terraform — его универсальность.
Для разворачивания инфры в разных системах используются сущности provider. Это своего рода API для работы с системой.
Подобная фича позволяет нам писать однотипный код для развретки приложения в разных системах: K8S, AWS, GCP и тд.
✨ Более того, у terrafrom есть провайдеры для настройки различных систем (keycloak, Grafana и тд).
В нотации Terrafrom все, что вы описываете называется ресурсом, и это могут быть пользователи в каком-нибудь keycloak'e или же микросервис в K8S. А может и DynamoDB в AWS.
Комьюнити активно живет и развивается. Каждый провайдер и ресурс тщательно документируются. 👬
Если вы начали интересоваться подобными активностями, либо занимаетесь этим прямо сейчас, рекомендую ознакомиться более предметно с этой технологией.
#rdclr_DevOps
Terraform — это детище компании Hashicorp для декларативного управления инфраструктурой проекта.
Он предоставляет нам полный контроль над каждым элементом инфраструктуры в одном проекте. Дает возможность параметризировать всю инфраструктуру.
Это значит, что если нам нужно поднять клон нашей инфраструктуры — мы это делаем всего лишь заменой пары параметров (в том числе их можно передать на уровне пайплайна).
Ознакомиться с данным чудом можно на сайте Terraform.
💥 Одно из преимуществ использования Terraform — его универсальность.
Для разворачивания инфры в разных системах используются сущности provider. Это своего рода API для работы с системой.
Подобная фича позволяет нам писать однотипный код для развретки приложения в разных системах: K8S, AWS, GCP и тд.
✨ Более того, у terrafrom есть провайдеры для настройки различных систем (keycloak, Grafana и тд).
В нотации Terrafrom все, что вы описываете называется ресурсом, и это могут быть пользователи в каком-нибудь keycloak'e или же микросервис в K8S. А может и DynamoDB в AWS.
Комьюнити активно живет и развивается. Каждый провайдер и ресурс тщательно документируются. 👬
Если вы начали интересоваться подобными активностями, либо занимаетесь этим прямо сейчас, рекомендую ознакомиться более предметно с этой технологией.
#rdclr_DevOps
👍5❤2
Причина выгорания 1: нарушение графика дедлайнов —> объем, который не вывозится
Сегодня хочу обратить внимание на наше физическое и моральное состояние. Как многие поняли, речь пойдет о выгорании.
В первую очередь хочу акцентировать внимание на том, как же работник доходит до такого состояния:
1) человек не успевает сделать запланированные задачи в срок;
2) по каким-либо причинам не говорит об этом команде или ПМу;
3) решает доработать вечером/ночью/на выходных;
4) и все это происходит больше 1го раза.
😿 В таком режиме вы не успеваете отдохнуть/отвлечься от работы и каждый рабочий день вы уже начинаете уставшим, от этого цикл откладывания только наращивается и задержки по задачам только растут.
В какой-то момент вы просто уже не хотите что-либо делать и работа встает окончательно.
#teamlead
Сегодня хочу обратить внимание на наше физическое и моральное состояние. Как многие поняли, речь пойдет о выгорании.
В первую очередь хочу акцентировать внимание на том, как же работник доходит до такого состояния:
1) человек не успевает сделать запланированные задачи в срок;
2) по каким-либо причинам не говорит об этом команде или ПМу;
3) решает доработать вечером/ночью/на выходных;
4) и все это происходит больше 1го раза.
😿 В таком режиме вы не успеваете отдохнуть/отвлечься от работы и каждый рабочий день вы уже начинаете уставшим, от этого цикл откладывания только наращивается и задержки по задачам только растут.
В какой-то момент вы просто уже не хотите что-либо делать и работа встает окончательно.
#teamlead
👍7😢1