👩‍💻Инструменты разработчика

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

🛠Браузерные тулзы

Первое, на что стоит обратить внимание, это те средства, которые поставляют сами разработчики браузеров: в 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

📕Что почитать о доступности

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

Всем привет! Меня зовут Макс и следующую неделю я буду стараться заинтересовать вас постами на этом канале.
Если кратко — я тимлид, Java Dev, немного DevOps и совсем чуть-чуть архитектор в Red Collar. В своих постах буду касаться совершенно разных тем. Надеюсь, вам понравится =)

Ревью кода: кросс-ревью. Практики тим-лидов

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

На своем опыте встречал совершенно разное отношение к этой церемонии:
- кто-то считает, что код нужно поставлять быстро и на ревью нет времени;
- кто-то считает, что код нужно ревьюить, но не всегда;
- кто-то считает, что в команде есть ведущий сеньор или тим-лид, и только он имеет право ревьюить чужой код.

Однако, мое мнение, что все вышеперечисленное абсолютно неверно и на всех своих проектах стараюсь вводить такую практику как кросс-ревью.

🦀 Кросс-ревью — это проверка кода всеми членами команды.

А теперь как в Турецком сериале: «Самое интересное в следующей серии» 😉

#teamlead #rdclr_backend #rdclr_frontend

В чем же преимущество концепции кросс-ревью?

🐗 В первую очередь, минимизируется шанс ошибок в поставляемом коде. Даже опытный разработчик может допускать небольшие ошибки по невнимательности, и даже разработчик без продакшн опыта может такие ошибки заметить.

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

🐌 Также, каждый член команды разработки находится up to date с последними изменениями в коде (которого, возможно, он даже раньше не касался).

Ну и самое главное! Даже если вы не находите ошибок (что на самом деле хорошо) или у вас нет предложений по улучшению, в любом случае при просмотре чужого кода всегда можно научиться чему-нибудь новому. 🪱 Если вы встертили что-то неизвестное вам, вы всегда можете задать несколько вопросов и расширить свои знания.

#teamlead #rdclr_frontend

Вы подумали это все? А вот и нет =)
👍🏻 При кросс-ревью нет нагрузки на отдельного разработчика (тим-лида), который один должен пересмотреть все ревью.

👎🏻 Однако бывают случаи, когда разработчики, увидев, что более опытный разраб поставил аппрув, даже не уделяют внимания просмотру.

🚨 На такой случай есть суперский лайфхак: будучи тимлидом или ведущим разработчиком, вы можете специально допустить несколько ошибок в ревью, дабы проверить, кто добросовестно просматривает ваш код.

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

📮 В ходе повествования я упирался в слово «код», но такая практика может быть использована в команде абсолютно любого направления. И важно добавить, что под словом «команда» подразумевается отдельное направление (бэк, фронт, qa, дизайн и тд).

Правила всего 2:
1) желание развиваться и делать вашу работу все лучше и лучше;
2) команда от 3х человек и более (в случае 2х человек, само наличие ревью уже превращается в кросс-ревью).

Надеюсь, у всех вас на проектах существует кросс-ревью и вы ему рады. 😀
#teamlead #rdclr_frontend #rdclr_backend

Сегодня мы пойдем по стезе DevOps. 🍩
Уверен, многие в разные моменты своей жизни сталкивались с мыслью:
«Я сделал свою задачу, написал рабочий код. А потом высшие силы переместили его на сервер».

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

В последующих постах я не буду останавливаться на конкретных способах написания каких-либо CI/CD пайплайнов (это тема для целой статьи), но я хочу вас познакомить с одним из самых интересных и удобных подходов описания конечной инфраструктуры системы, чтобы приоткрыть немного завесу этой магии.
#rdclr_DevOps

Концепция: IaC

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

Для удобства ведения повествования представим, что мы пишем java-проект, на микросервисной архитектуре и хотим его положить в Kubernetes.

Зачастую DevOps пишет пайплайн, в котором сначала ваш код билдится в исполняемый файл, потом оборачивается в Docker image и сохраняется в registry. (Это классический пайплайн, но, естестественно, в зависимости от разных факторов он может выглядеть совершенно иначе)

Что же происходит после всего этого?

🧳 Есть разные решения этого способа поставки, но я хочу остановиться на концепции IaC (Infrastructure-as-Code).

Из названия понятно только то, что мы можем как-то кодом описать инфраструктуру. По факту это и есть самое большое преимущество данной концепции:
🧦 описывая инфраструктуру кодом, мы можем заливать этот код в репозитории и иметь версионирование всей инфраструктуры;
🧤 т.к. это код, мы можем выделить повторяющиеся участки кода и переиспользовать их, кастомизируя параметрами;
🧣 будучи разработчиком, научиться подобному языку не составит большого труда.

Следующим постом я хочу познакомить вас с одной из реализаций данного подхода — Terraform. А еще рассказать о самом большом преимуществе концепции IaC
#rdclr_DevOps

Реализация IaC: Terraform

Terraform — это детище компании Hashicorp для декларативного управления инфраструктурой проекта.
Он предоставляет нам полный контроль над каждым элементом инфраструктуры в одном проекте. Дает возможность параметризировать всю инфраструктуру.

Это значит, что если нам нужно поднять клон нашей инфраструктуры — мы это делаем всего лишь заменой пары параметров (в том числе их можно передать на уровне пайплайна).
Ознакомиться с данным чудом можно на сайте Terraform.

💥 Одно из преимуществ использования Terraform — его универсальность.
Для разворачивания инфры в разных системах используются сущности provider. Это своего рода API для работы с системой.
Подобная фича позволяет нам писать однотипный код для развретки приложения в разных системах: K8S, AWS, GCP и тд.

✨ Более того, у terrafrom есть провайдеры для настройки различных систем (keycloak, Grafana и тд).

В нотации Terrafrom все, что вы описываете называется ресурсом, и это могут быть пользователи в каком-нибудь keycloak'e или же микросервис в K8S. А может и DynamoDB в AWS.
Комьюнити активно живет и развивается. Каждый провайдер и ресурс тщательно документируются. 👬

Если вы начали интересоваться подобными активностями, либо занимаетесь этим прямо сейчас, рекомендую ознакомиться более предметно с этой технологией.
#rdclr_DevOps

#rdclr_DevOps #terraform

#code_review #meme #teamlead

Причина выгорания 1: нарушение графика дедлайнов —> объем, который не вывозится

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

В первую очередь хочу акцентировать внимание на том, как же работник доходит до такого состояния:
1) человек не успевает сделать запланированные задачи в срок;
2) по каким-либо причинам не говорит об этом команде или ПМу;
3) решает доработать вечером/ночью/на выходных;
4) и все это происходит больше 1го раза.

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

В какой-то момент вы просто уже не хотите что-либо делать и работа встает окончательно.
#teamlead

Причина выгорания 2: переусердствовали на старте

🐲 Бывает и другой случай:
1) на старте проекта (либо на вашем входе в проект) вы хотите показать, что вы можете очень круто и много работать, и выкладываетесь на 120%;
2) но работа в таком режиме долго работать не получается, и через пару спринтов вы возвращаетесь в свои 100%;
3) со стороны заказчика это выглядит как вы работали в нормальном режиме, но потом решили расслабиться, а он все еще хочет, чтоб вы работали как раньше;
4) ну и, наконец, в больше случаев мы приходим к первому циклу.

🍃 Прежде всего при выгорании наносится большой вред вашему здоровью, если вовремя этот цикл не прервать.
🍂 Но важно помнить еще и тот факт, что работая на проекте вы являетесь лицом компании перед заказчиком.
И такая остановка в работе или резкое снижение продуктивности может крайне негативно отразиться на отношениях с заказчиком, вплоть до отказа в сотрудничестве.
#teamlead

Как обезопасить себя от выгорания
Что же нужно сделать чтобы не допустить такого?

🍹1. Уметь переключаться с работы на отдых вечерами и особенно на выходных.
📞 2. Если вы видите ситуацию, которая может привести к переработкам, необходимо обязательно связаться с менеджером или тим-лидом и обсудить эту ситуацию (решение есть всегда).
🏮 3. Если на проекте есть возможность и необходимость выходить в овертайм, лимитируйте такие переработки и делайте перерывы.

Берегите себя!) 💆🏼‍♂️
#teamlead

Всем привет! Меня зовут Никита, в компании Red Collar я занимаю должность Java backend-разработчика. Так сложилось, что во время учебы и как хобби мне часто приходилось изучать и разбираться в нейронных сетях. Именно эту тему я бы хотел затронуть на этой неделе. Я постараюсь не использовать сложные термины и математику, а так же буду разбавлять скучные рабочие будни смешными картинками.
#meme

Что такое нейронные сети

Хотелось бы начать с краткого экскурса в нейронные сети. Открыв любой интернет источник, можно очень часто увидеть такую формулировку: «Искусственные нейронные сети — это вычислительные модели, вдохновленные человеческим мозгом».

🧠 Нейронные сети действительно напоминают мозг человека (животного), как минимум следующими признаками:
1) нейронная сеть получает знания посредством обучения;
2) знания нейронной сети — это хранилище сил межнейронных связей, также известных, как веса нейронной сети.

Любые алгоритмы разрабатываются с целью решения каких-то задач, нейронные сети не стали исключением. Они позволяют выполнять задачи по осмыслению данных, сохраняя при этом свои другие свойства.
Сейчас мы их разберем.
#rdclr_backend #NN

Нейронные сети и их задачи. 1 — Классификация
Разберем подробнее каждый из типов задач.

Классификация
Все задачи классификации сводятся к обучению нейронной сети относить входные данные к определенному набору заранее известных классов.

Одна из самых первых задач, с которой сталкивается человек, который только начал изучать нейронные сети — это определение того, что представлено на изображении: кошка или собака.🐕🐈‍⬛
Это накладывает определенные ограничения на обучающую выборку, так как каждый набор данных должен быть помечен. Пример задачи с кошками и собаками говорит, что абсолютно к каждому изображению должно быть пояснение. А именно, к какому классу относится данное изображение (кошка или собака).

Подход, когда заранее известны выходные данные нейронной сети, называется «контролируемое обучение», или «обучение с учителем».
#rdclr_backend #NN

Нейронные сети и их задачи. 2 и 3 — Кластеризация и Предиктивный анализ

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

🧐 Например, это может быть сравнение изображений или звуков, а также обнаружение аномалий. Для кластеризации крайне необходимо иметь большую выборку, ибо чем больше данных «прогонит» через себя нейронная сеть, тем точнее она будет.

💎 Предиктивный анализ
Предиктивный анализ по-другому часто называют задачей регрессии.

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

🧐 Например, это может быть предсказание поломки оборудования, или проблем со здоровьем.

Дальше мы разберем популярные библиотеки и инструменты работы с нейтронными сетями. А пока — хорошего вечера! 🥟
#rdclr_backend #NN

Инструменты под python для разработки нейронных сетей
Сегодня хотелось бы поговорить об инструментах и библиотеках, которые помогут в разработке и описании нейронных сетей.

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

🌪 jupyter notebook — это мощный инструмент для разработки и представления data science проектов. Он способен хранить код, графики, изображения и формулы в одном месте.

💨 google colab — бесплатная облачная среда от компании Google, позволяющая работать с jupiter блокнотами. Данный сервис предоставляет 12 ГБ ОЗУ и сессии до 12 часов. Так же, как и у остальных продуктов данной компании, реализована возможность совместного использования.

#rdclr_backend #NN