Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.

Что делает наша команда

Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.

Описание задачи

У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.

Ответы приходят в формате JSON. Документации достаточно для начала загрузки, но для полного понимания структуры и содержимого ответа — маловато. 

Мы решили просто загружать все подряд — на месте разберемся, что нам нужно и как мы это будем грузить, потом пойдем к источникам с конкретными вопросами. Так как каждый метод API отдает свой класс данных в виде JSON, в котором содержится массив объектов этого класса, нужно построить много таких пайплайнов с обработкой разного типа JSON’ов. Еще одна сложность — объекты внутри одного и того же класса могут отличаться по набору полей и их содержимому. Это зависит от того, как, например, сотрудники подбора заполнят информацию о вакансии на этом сервисе. Этот API работает без версий, поэтому в случае добавления новых полей информацию о них мы получим только либо из данных, либо в процессе коммуникации.

Привет! Меня зовут Олег Скирюк, я лидирую контент-разработку в одной из команд билайна. Сам я перешёл в мобильную разработку из веба три года назад, после чего собрал и обучил одну из первых Flutter-команд в компании. Вместе с этой командой мы постоянно экспериментируем и пробуем различные решения, чтобы совершенствовать наши приложения.

В этом посте я хочу рассказать про архитектуру Flutter-приложений, о том, как мы в билайне это делаем, чего мы достигли и как это у нас работает. Поговорим о создании архитектуры, организации управления состояниями и зависимостями, о привычных и не очень методах и концепциях, затронем Mobx, GetX и Flutter modular, а также разберём всё это на живом примере — на нашем мобильном приложении для дилеров.

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

В фильме «Без обид» с Дженнифер Лоуренс есть сцена, где её одежда загорается. Она держится на капоте автомобиля, который на скорости въезжает на переполненный пляж и врезается в барбекю, после чего из него вылетают горящие угли. Однако пламя выглядит совершенно непохоже на то, что мы видим в жизни. Оно кажется пластмассовым и неоново-жёлтым, направленным прямо вверх. Даже в подобной халтурной комедии этот эффект выглядит раздражающе неубедительным.

И это не единственный пример. Сгенерированный компьютером огонь можно часто увидеть в фильмах, и повсюду он выглядит ужасно. Пожары в домах из прошлогодних «Банши Инишерина» и «Достать ножи: Стеклянная луковица» выглядят так, как будто их вручную нарисовали поверх кадров фильма. То же самое справедливо для сериала «Медведь» и нескольких пожаров в «Стране пожаров». В «Игре престолов» дыхание драконов было реализовано при помощи настоящих огнемётов на подъёмных кранах; в спинофе этого сериала «Дом Дракона» магические существа извергали цифровой огонь. Из всех очевидных спецэффектов в последних фильмах франшиз «Тор» и «Стражи Галактики» сильнее всего выделялось пламя — плоское, пересыщенное и подвергнутое motion smoothing.

Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.

Сегодня я смотрю на мир веб-разработки, и меня поражает его безумие. Существует так много фреймворков для веба, и каждый день появляются новые. Для создания веб-приложения (в отличие от веб-сайта, например, моего сайта про искусство, который сгенерирован статически и содержит лишь немного Javascript), часто требуются кучи инструментов и технологий, часто меняющихся с большой частотой и содержащих бесконечные объёмы других технологий, о существовании которых мы и не подозреваем (о, смотрите-ка, в папке пакета две тысячи файлов).

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

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

Сегодня же обсудим, как именно мы помогаем этим директорам принимать решения. Потому что вопросов в их работе возникает множество — как они видят нашу ЦА, как мы можем её заинтересовать (и почему именно так), что полезного мы несём в нашу ЦА, как дела с нашей социальной ответственностью, что у нас в разрезе разных видов контента, сколько мы можем заработать и многое, многое другое.

В этом (спойлер — и не только в этом) нам сильно помогает единое хранилище данных, далее просто ЕХД.

Без выстраивания хороших отношений со стейкхолдерами (или заинтересованными сторонами) на проекте далеко не уедешь. О том, как это делать like a boss, – годная статья автора Кэт Бугард в блоге Miro.

Все картинки – из Miro.

Всем привет! Мы (Никита Звонилкин и Дмитрий Ёжиков) работаем в отделе локализации в SM Lab. Мы провели презентацию по теме интеграции локализации в процесс тестирования ПО на конференции SQA Days. Для этой статьи мы адаптировали эту презентацию, чтобы показать, чем локализация отличается от перевода. А ещё расскажем про основные этапы локализации, поговорим о подборе команды для проведения тестирования и о полезном софте.

Немного цифр. Спортмастер — большая компания, торговые сети представлены в 6 разных странах, а в 11 есть дополнительные офисы, в которых работают более 45 000 сотрудников. SM Lab — отдельно IT-подразделение, которое занимается разработкой софта и, собственно, его локализацией для стран нашего присутствия.

Тонкости локализации

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

Например, белый цвет, который в принципе везде считается нейтральным, в Японии могут расценить как траурный, так что не всегда будет уместно его использовать. В разных странах по-разному могут воспринимать ещё и жесты с символами, которые вам кажутся привычными и стандартными. Скажем, значок мира, который у нас так и воспринимается, в Великобритании лучше не показывать, он считается оскорбительным жестом. Большой палец вверх тоже у нас считается вполне себе адекватным, а вот жестовое обозначение “ОК” в той же Бразилии расценивается совсем иначе.

Если кто-то смотрел фильм Квентина Тарантино «Бесславные ублюдки», то вы явно помните сцену, в которой офицер под прикрытием (персонаж Майкла Фассбендера) заказывает жестом три пива, чем и выдает себя. 

Привет! В начале октября мы писали пост о том, почему не стоит ходить на некоторые IT-конференции. Хотя мы пару раз в тексте отметили, что это не наезд и не претензии, никакого хейта, а, скорее, подборка фактов «на подумать», ряд человек всё равно успели пообижаться.

Но зато в качестве обратной связи мне потом написали сразу несколько организаторов конференций, и у нас получился вполне себе продуктивный диалог — обсудили, чего и где можно пофиксить, так уже следующие конфы (по крайней мере, от некоторых организаторов) будут таким «изданием дополненным и исправленным».

Сегодня же хотим рассказать о том, почему стоит посещать некоторые IT-конференции. Под катом — 10 причин продолжать это делать.

Чем бы вы ни занимались, звуковое сопровождение играет довольно важную роль. Для учёбы или вдумчивой работы люди часто выбирают одноимённые плейлисты, состоящие по большей части из спокойной музыки, эмбиента или классики. Для бега тоже есть своя музыка, которая обычно куда динамичнее — многим нравится подбирать её в зависимости от скорости и интенсивности бега. 

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

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

Бывает такое: смотришь кино, слышишь OST или просто какую-то хорошую песню, которую решили вставить в фильм, и думаешь — а неплохо бы её добавить к себе в плейлист. Способов сделать это было несколько. Можно было пойти и поискать или сам OST к фильму, или неофициальные саундтреки к нему. Можно было посмотреть, что по названию фильма выдаётся в поиске через музыкальные стриминговые сервисы, вдруг какая-то площадка уже позаботилась о вас и собрала тематический плейлист. Отдельные граждане прямо во время фильма включали на смартфоне Shazam и распознавали трек. В общем, кто во что горазд.

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

Меня зовут Алексей Царёв, я занимаюсь развитием технологий в развлекательных сервисах Яндекс. И моя задача в том, чтобы из какой-то отдельно взятой технологии создавать рабочие продукты для конечного пользователя. Именно об этом, на примере распознавания музыки в фильмах, и будет этот пост.

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

В этом посте мы поговорим о том, как формат сообществ (чаптеров) помогает нам в работе. Для этого мы подробно побеседовали с Михаилом Благовым, лидером чаптера инженеров данных. Еще нам помогали Николай Безносов (чаптер Data Science) и Артём Смирнов (Data Analytics).

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

Привет! 

Меня зовут Александр Маркачев, я 3,5 года работаю на позиции Data Engineer в билайне и люблю открывать для себя что-то новое и интересное в работе. Так случилось и с темой, которой я сегодня хочу с вами поделиться — со spill-ами.

Под катом мы поговорим о том, что такое Spill-ы в контексте Spark, и почему именно для Spark это не такая уж сильно плохая штука. Рассмотрим, из-за чего Spill-ы в принципе возникают, разберем несколько видов Spill-ов (и даже вызовем их намеренно), а затем будем решать эту проблему.

Что такое spill-ы в Spark

Вообще, Spill — это термин для обозначения процесса перемещения данных из памяти на диск, а затем снова обратно в память. По крайней мере, именно так гласит официальная трактовка. Если проще, то дело вот в чем — когда у Spark не хватает ресурсов для обработки, он перемещает данные на диск.

В процессе обработки существуют разные участки — есть Executor Memory, есть Storage Memory, и когда эти участки оба целиком заполнены, то они начинают переполняться и вызывать утечку данных. Причем в отличие от утечки в C, Java или еще где-то, в Spark это преднамеренное действие для того, чтобы ваша задача не падала. Собственно, именно поэтому при нехватке ресурсов данные и «проливаются».

Можно ещё сильнее упростить аналогию.

Привет! Мы сделали приложение «Кубокот» для детей дошкольного возраста. Главная идея — подготовка ребенка к школе, поэтому образовательный контент у нас разделен на категории в зависимости от возраста. 

Кубокот — это персонаж-проводник, который всегда сопровождает ребенка на всех игровых экранах и голосом дает задания. Кот реагирует на правильные или неправильные действия: хвалит ребенка, если он совершает правильные действия, и корректирует, направляет его, говоря: «Попробуй по-другому, попробуй еще», если ребенок ошибся. Ещё он реагирует, когда ребенок возвращается в приложение в тот же день — говорит: «Как здорово что ты снова здесь!». Вишенкой для ребенка — на главном экране приложения кота можно гладить! 

В приложении работает автозапуск игр в зависимости от прогрессии. То есть мы запустили, допустим, букву «А», и пока ребенок не пройдет все игры на эту букву, его не вернет куда-то обратно в меню. Также между играми есть небольшая развлекательная составляющая — летят шарики, которые можно лопать. Если их лопать, то их будет лететь больше. За каждые десять лопнутых шариков Кубокот будет хвалить ребенка. 

Под катом о том, что ещё умеет приложение.

Привет! Меня зовут Сергей Грибков, я тимлид команды FM&RA в билайне, и в этом посте я хочу рассказать об одной фирменной особенности Scala под названием implicits. Это неявные параметры, неявные преобразования, неявные классы.

Почему неявные — потому что они не требуют прямого вызова, если мы говорим о методах, не требуют прямой передачи в метод, если мы говорим о параметрах, и так далее.

В Scala implicits широко распространены. Скорее всего, вы уже сталкивались с ними в различных библиотеках и фреймворках, например, Apache Spark. 

Чтобы успешно использовать implicits в собственном коде и работать со сторонними библиотеками, требуется понимание принципов их работы. Поэтому давайте разберем, как всё устроено.

Итак, существует три основных категории implicits:

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

Привет, Хабр! В предыдущей статье мы рассказали об используемых подходах и технологиях в разработке внутри Учи.ру.  На основе этих проверенных решений за уходящий учебный год мы разработали новые вспомогательные инструменты, продукты и сервисы. Сегодня расскажем, как создавались некоторыми из них.