Привет, Хабр! На связи KozhinDev и ml-разработчик Приходько Александр. Это четвертая часть цикла о борьбе с дисбалансом классов. Предыдущие статьи:
- В первой статье мы рассказали про суть проблемы дисбаланса классов и стандартные методы борьбы с ним;
- Во второй статье обсуждались методы undersampling - удаление данных из распространенного класса;
- В третьей статье рассматривались методы oversampling - генерация примеров редкого класса.

В данной части мы рассмотрим комбинированные и ансамблевые методы библиотеки Imbalanced Learn.

Привет, Хабр! На связи KozhinDev и ml-разработчик Приходько Александр. Это третья статья в цикле публикаций по теме борьбы с проблемой дисбаланса классов в машинном обучении. В первой статье мы обсудили актуальность данной проблемы в машинном обучении, а также сравнили методы борьбы с ним, без внесения изменений в сами данные: изменение весов классов и порога принятия решения моделью. Во второй статье мы сравнивали undersampling-методы, которые удаляли представителей частого класса.

В данной части мы протестируем методы балансировки данных методом oversampling из библиотеки imblearn. Суть данного метода заключается в том, что мы пытаемся бороться с дисбалансом классов генерируя данные для редкого класса. Мы рассмотрим разные способы генерации таких данных и протестируем их на синтетических данных.

Привет, Хабр! На связи KozhinDev и ml-разработчик Приходько Александр. Это вторая статья в цикле публикаций по теме борьбы с дисбалансом классов в машинном обучении. В предыдущей статье мы рассмотрели актуальность данной проблемы и сравнили методы борьбы без внесения изменений в данные: балансировка весов классов и изменение порога принятия решения моделью. В данной части будем тестировать балансировку данных методом undersampling из библиотеки imblearn.

Привет, Хабр! На связи KozhinDev, а именно ml-разработчик Приходько Александр. Этой статьей я начну цикл публикаций по теме борьбы с дисбалансом классов. В первую очередь этот гайд предназначен для ml-разработчиков уровня junior/middle. Мы ознакомимся с различными подходами к решению проблемы дисбаланса классов и проведем их сравнительный анализ на сгенерированной выборке: коснемся метрик качества, встроенных в классификаторы методы борьбы с дисбалансом классов, методы модификации выборки, а также комбинированные техники. В последней части мы расскажем про наш опыт применения кастомных метрик точности, как еще один метод борьбы с дисбалансом.

Это третья статья из цикла про наш фреймворк Steroids: в ней мы рассказываем о том, как пришли к созданию собственного движка форм для React. Если вы ещё не читали предыдущие материалы, рекомендуем с ними ознакомиться:

Всем привет!

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

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

Рынок IT меняется с такой скоростью, что за ним иногда трудно угнаться: новые технологии, методологии, роли — всё постоянно меняется. Из-за этого границы между профессиями часто становятся размазанными. Если разработчики чётко знают свой стек, задачи и техдолг, то у дизайнеров и аналитиков всё гораздо более гибко, потому что их работа опирается на коммуникацию, логику и потребности людей. Часто дизайнеры и аналитики начинают работать вместе еще на самых ранних стадиях проекта — именно там, где чаще всего царит хаос.

И вот здесь начинается путаница. Часто не совсем ясно, кто за что отвечает. В одной команде UX-дизайнер делает всё: от сбора требований до создания прототипов, а в другой — он ждет четкого ТЗ от аналитика. И тогда возникает вопрос: где заканчивается аналитика и начинается дизайн? Давайте разберемся.

Это вторая статья из цикла про наш фреймворк Steroids, в которой мы расскажем об архитектурном подходе к построению UI-компонентов. Если вы ещё не читали первую статью — начните с неё. В ней мы объясняем, что такое Steroids и какие задачи он решает.

Сегодня веб-приложения стали сложными интерактивными системами, напоминающими полноценные десктоп приложения. Однако за красивыми интерфейсами и богатым функционалом часто скрывается важный аспект, которому уделяется недостаточно внимания — доступность (accessibility). Для миллионов пользователей с ограниченными возможностями это означает, что они не могут полноценно взаимодействовать с сайтом, выполнить базовые действия или получить информацию.

Проблема особенно ярко выражена в современных одностраничных приложениях (SPA), кастомных компонентах, модальных окнах и прочих динамических UI-решениях, которые не учитывают, как с ними будут работать вспомогательные технологии. Например:

На старте проекта обычно встает вопрос о выборе готовой ui-библиотеки для решения шаблонных задач, таких как создание форм, инпутов, кнопок и других компонентов. Количество готовых ui-библиотек для React так стремительно растет, что уже сложно остановить свой выбор на какой либо из них. Зато в таком разнообразии каждый может найти библиотеку, подходящую под его задачи. В этой статье хочется рассказать о фреймворке Steroids, который разработан и поддерживается в нашей компании.

Изначально мы не планировали создавать фреймворк, а просто собирали удачные решения рутинных задач. Получился набор полезных утилит и мини-библиотек, который позволял нам работать быстрее. Мы постепенно добавляли в него новые элементы, он рос и видоизменялся, и в итоге вырос в полноценный фреймворк Steroids.