В этой статье мы разберёмся, в чем сложность написания адаптивных компонентов, поговорим о code-splitting-е, рассмотрим несколько способов организации структуры кода, оценим их достоинства и недостатки и попытаемся выбрать лучший из них (но это не точно).

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

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

По мере развития и покорения новых вершин, Юле понадобилась новая система, которая позволила бы создавать деревья полей, с ручным вводом, выбором значений и даже получением новых полей в зависимости от ранее выбранных вариантов. И в качестве апофеоза требовалось создать простую систему управления всем этим через панель администратора.

В больших проектах, состоящих из десятков и сотен взаимодействующих сервисов, всё чаще становится обязательным подход к документации как к коду — docs as code.

Я покажу, как можно применять эту философию в реалиях classified-сервиса, а точнее, начну с первого этапа её внедрения: автоматизации обновления данных в документации.

Привет Хабр!

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

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

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

Сегодня мы вам расскажем про синергию между Юлой и Одноклассниками, которая помогает нам эффективно модерировать объявления в Юле.

Синергия вообще штука очень полезная, а в современном мире, когда технологии и тренды меняются очень быстро, она может превратиться в палочку-выручалочку. Зачем тратить дефицитные ресурсы и время на изобретение того, что до тебя уже изобрели и довели до ума?

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

Поэтому мы воспользовались уже готовой платформой модерации, которую к тому времени наши коллеги из Одноклассников допилили до состояния «почти совершенство».

Всем привет! Сегодня будем говорить о реализации машинного обучения на Scala. Начну с объяснения, как мы докатились до такой жизни. Итак, наша команда долгое время использовала все возможности машинного обучения на Python. Это удобно, есть много полезных библиотек для подготовки данных, хорошая инфраструктура для разработки, я имею в виду Jupyter Notebook. Всё бы ничего, но столкнулись с проблемой распараллеливания вычислений в production, и решили использовать в проде Scala. Почему бы и нет, подумали мы, там есть куча библиотек, даже Apache Spark написан на Scala! При этом, сегодня модели мы разрабатываем на Python, а затем повторяем обучение на Scala для дальнейшей сериализации и использования в production. Но, как говорится, дьявол кроется в деталях.

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