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

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

Оценку доступность провели для девяти игр (как российских, так и иностранных разработчиков), наиболее популярных среди незрячих детей и подростков по всему миру.

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

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

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

Я даже предположил, что Elm MVU — это тот путь, который данные потребности закроет.

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

Под словом «естественный» я подразумеваю нечто, что коррелирует с языком, который мы используем в повседневной жизни. Функциональное программирование не всегда можно описать таким языком (например, несмотря на то, что монады, включая Observable streams, являются относительно простым понятием, мы вряд ли сможем выразить это понятие на таком языке). Я убедился, что программирование, которое лучше коррелирует с естественным языком — это многопарадигменное программирование, где вещи не строго OOP и не строго функциональны, а то или другое в зависимости от ясности и удобства работы.

После тестирования NVME over TCP, описанной тут https://habr.com/ru/companies/beeline_tech/articles/770174/, решили проверить, насколько хорошо iScsi в L3-сети работает по сравнение со специализированным решение на FC.

Настройки iScsi

TL/DR

Машина в Bios переведена на профиль HPC (был пустой).

На уровне OS и iscsid сделаны такие изменения

Привет. Меня зовут Николай Шувалов, я занимаюсь коммерческим программированием около семи лет, владею Rust, JavaScript, PHP. Сейчас я работаю в отделе данных билайна. Наша платформа позволяет делиться с партнерами данными, не раскрывая их. Например, можно расширить данные с помощью фильтра Блума. 

Arrow в сравнении со строковыми форматами

Возьмём простую таблицу, которая состоит из трех столбцов: телефона, даты и имени. Рассмотрим, как она будет выглядеть в строковом и столбчатом форматах. Для строкового формата мы возьмем csv и json, для столбчатого формата структура будет одинаковой. Если же таблица состоит, например, из миллиона строк, а нужно получить имя на строке с номером 10 000, то придется бежать по всей строчке. В json то же самое. А в столбчатом формате ситуация иная — значения привязаны к столбцам. Когда мы хотим получить имя на строке 10 000, то сразу обращаемся к этому столбцу и получаем все его данные. 

Существуют RA (random access) файлы, в которых можно пропускать заданное количество строк, но все равно парсеру нужно читать и анализировать пройденные строчки.

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

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

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

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

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

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

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

Привет, Хабр!

Мы в билайне любим машинное обучение. В какой-то момент моделей машинного обучения стало так много, что это вынудило нас решать определенные задачи. Я Дмитрий Ермилов, руковожу ML в дирекции по искусственному интеллекту и цифровым продуктам. О решении одной такой задачи и будет этот рассказ.

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

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

Привет! Меня зовут Андрей Чучалов, я работаю в билайне, и в этом посте я расскажу про оптимизацию параметров запуска приложений в Spark, поиск проблем и повышение производительности. Разберем запуск приложений Spark в базовой и расширенной версиях, покажу методы расчёта основных параметров работы приложения для производительности и эффективности использования доступных ресурсов кластера. Бонусом — о том, как всё это привязано к деньгам, и где сэкономить можно, а где — не стоит.

Для чего это вообще нужно

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

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

Эта статья описывает, как из прогнозов ряда ML-моделей получить ценность клиента с горизонтом в 5 лет. Напомним, что показатель CLTV представляет из себя композицию прогнозов ее компонент (подробнее в статье). В нашей реализации максимальный период прогнозирования моделей - 24 месяца. Важно отметить, что чем выше горизонт прогнозирования, тем менее точный прогноз способна сделать модель. А показатель CLTV интересен бизнесу на более длинном горизонте, в нашем случае - пять лет. Как же из прогнозов на два года получить прогноз на пять лет? Ответ прост: экстраполировать прогнозы.

Основная идея продления (экстраполяции) прогнозов - это разбиение пользователей на несколько групп, а в каждой группе единообразно продлить ряд прогноза. 

Далее мы обсудим:

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

Всем привет! Меня зовут Владимир Земсков, я работаю в B2C билайна, в команде билайн Про, где пишу бэк-офис для нашей системы. Мы помогаем нашей рознице продавать лучше и больше. Для соблюдения нужного уровня качества кода в билайне мы используем и ESlint, и тесты, и ревью, и особый тип — внутренние договорённости. 

Когда я пришёл в компанию, то мне захотелось найти ESlint-плагин, который бы помог автоматизировать часть работы. Я поискал, не нашёл, и в итоге решил написать свой. Из всей этой истории и родился сегодняшний рассказ. В первой части мы обсудим договорённости и их важность для разработки. А во второй — поговорим про то, как эти договорённости переносить в ESLint, как это упростит жизнь и действительно ли это это так сложно, или можно что-то упростить по пути.

Целое поколение писало свои первые программы на 8-битных системах. Эти системы 1970-х и начала 1980-х годов впервые сделали компьютеры доступными практически всем. Это было время формирования людей, которые позже посвятили свою карьеру компьютерам, и многие из них сыграли ключевую роль в развитии компьютерных технологий.

Эта ностальгия во многом объясняет неувядающий энтузиазм в отношении 8-битных систем.

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

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

Мы работаем в большой компании, где требования к производимому ПО очень высоки. Наши сервисы без сомнения можно назвать высоконагруженными системами. 

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

Всем привет! Меня зовут Владлен Севернов. Я работаю ML-инженером в команде CLTV билайна. В этой статье я поделюсь с вами моим опытом решения задачи uplift-моделирования для оценки экономики продукта «Семья» с точки зрения CLTV.

Что мы подразумеваем под CLTV

Подробнее про CLTV в билайне вы можете почитать в наших предыдущих статьях:

- Что такое CLTV и как мы в билайне с ним работаем
- Использование ML для прогнозирования CLTV

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

Немного про продукт «Семья»

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

Почему для семейных тарифов необходимо считать именно CLTV?

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

На старте карьеры каждый испытывает все эти чувства. Давайте начнем немного менять ситуацию с последнего пункта — резюме!

Да, мы не сможем за 30 минут повысить ваш опыт работы на 3 года, но даже в банальном оформлении своего резюме многие делают (или не делают) достаточно странные вещи.

Перейдем к пункту 0...

Меня зовут Дмитрий Иванов, я старший аналитик данных компании билайн, и первое правило хорошего резюме — это простота. Пока мы не идём на позицию ТОПа или вице-президента, давайте оставим излишний формализм за пределами того PDF-файлика, который вы будете рассылать рекрутёрам.

0. Пишите просто и понятно

Не надо делать делать из мухи (3 месяца работы в универской лаборатории) слона (оформить каждый тезис вашего курсача как отдельный научный проект). 3 месяца в лаборатории = 3 месяца в лаборатории. 

Всем привет!

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

Сейчас в мои задачи входит анализ и управление требованиями к веб-приложению для настройки проверок параметров вызовов. Помимо описания взаимодействия между front- и back- слоями, я взаимодействую со смежной командой для проработки интеграции между нашим приложением и модулем принятия решений по результатам проверки параметров вызовов.

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

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

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

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

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

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

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

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

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

Набором этих правил я и хочу поделиться.

В предыдущих статьях мы пришли к выводу, что для того, чтобы UI‑код не превращался в легаси, нам нужно отделить представление от бизнес‑логики и немного иначе, чем это делают Redux и Elm, так как оба подхода не позволяют сделать это полностью.

В данной статье мы порассуждаем о том, как такое разделение сделать.

React view как чистая функция состояния

React изменил наш подход к пользовательскому интерфейсу — его философия основана на простых, но мощных концепциях использования компонентов и однонаправленного потока данных.

Ещё считается, что React внес реактивность в пользовательский интерфейс, но это не так, так как шаблоны MVVM и фреймворки, которые сильно полагаются на реактивность, были введены раньше React. (Knockout и Angular с двойным биндингом данных, Ember.js Observable)

Эти концепции делают UI разработку не только интуитивнее, но и объединяют дизайн и разработку в одном инфополе. Кстати, Elm тоже полагается на подобные концепции и использует чистые композируемые функции представления без состояния.

Привет, Хабр!

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

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

Разработка IT-решений

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

В первом случае предполагается, что образуются команды с одинаковым набором экспертиз: команда backend-разработчиков, команда frontend-разработчиков, команда data science и т. д. Во втором случае команды формируются из людей с различными компетенциями для достижения некоторой бизнес-цели. Бизнес-целью может являться как создание и развитие продукта, так и выполнение определенного проекта.

Легенды гласят, что кросс-функциональные команды появились в далеких 1950-х годах.