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

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

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

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

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

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

Привет! Меня зовут Александр Поляков, я руководитель команды i18n-разработки в Фантехе Яндекса. Мы помогаем сервисам компании выходить на международные рынки, а именно решаем задачи, связанные с интернационализацией и локализацией интерфейсов.

В этом посте расскажу:

• какие именно решения для интернационализации фронтенда мы разрабатываем;

• какие есть правила форматирования данных для разных локалей и как определять эти локали;

• о проблемах переводов в современных реалиях.

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

Всем привет! Меня зовут Николай Безносов, я отвечаю за применение и развитие машинного обучения и продвинутой аналитики в билайне. В одной из прошлых статей мои коллеги рассказывали о месте Seldon в ML-инфраструктуре компании, а сегодня мы поднимемся на уровень выше и поговорим о том, что из себя представляет MLOps в билайне в целом - как с точки зрения инфраструктуры, так и с точки зрения процессов.

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

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

Из прошлой статьи мы узнали, что CLTV (customer lifetime value) — метрика, используемая для оценки прибыли, которую компания может получить от своего клиента за время его пользования продуктами и сервисами компании.

Разберем, что означает каждая буква в определении CLTV (customer lifetime value). Кто такой клиент, что мы понимаем под lifetime и ценностью, которую приносит нам клиент. 

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

Под lifetime мы понимаем не полный жизненный цикл клиента от момента заключения договора до момента его закрытия, а пятилетний горизонт, который мы отсчитываем от текущего момента времени. То есть, если мы строим прогноз от января 2023 года, то прогноз будет построен помесячно до декабря 2027 года. Почему 5 лет? Этот срок был определен опытным путем — при нем достигается баланс между качеством предсказаний и потребностью в бизнес-процессах.

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

Привет всем! Полное содержание первого сезона можно прочитать тут и тут, а краткое содержание такое: 

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

• Мониторинг был разным (Patrol, Zabbix. NetCool), про Elastic. Про Prometheus, трейсинг и Grafana не слышали.

• У всех команд эксплуатации были свои мониторинги, которые "что-то" показывали, но это все было разрознено и никак не связано.

Привести все это «богатство» в адекватное рабочее русло, как-то структурировать и реструктуризировать было поручено команде супергероев, которые в перерывах между паниками (страшно было) взялись за дело

ВАЖНО: Тут не будет скриптов развертывания. Не будет рецептов и настроек систем (что-то есть в интернете, к чему-то пришли через пот и слезы). Это взгляд людей, которые развивают системы мониторинга и философию, которой они придерживается. Что еще важно – среди нас до момента развертывания не было людей, которые слышали про эти системы. 

Наш первый сезон мы закончили с таким багажом и знаниями:

Содержание статьи:

1.  Простыми словами: Геном и физиология человека в исторической перспективе

2.  Работа за офисным столом может стать вашим тихим убийцей

Преимущества, которые дают регулярные тренировки:

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

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

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

В этом посте как раз о подобных сложностях я и хочу поговорить, а именно — о проблеме в коммуникациях между разработчиками и дизайнерами. Я очень люблю делать личные кабинеты, поэтому и в качестве примера буду говорить именно о разработке ЛК в билайне за последние три года. О том, какие именно трудности возникали и как мы упростили работу на UI-китом, под катом.

Представьте ситуацию.

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

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

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

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

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

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

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

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

В этой статье затронем тему организации процессов Machine Learning Operations (MLops) в beeline business, особое внимание акцентируем на тестировании моделей машинного обучения. Тестирование мы построили с использованием Gitlab (CI/CD), Mlflow и open-source фреймворка Seldon Core для деплоя REST API или gRPC сервисов с моделями в среде Kubernetes. А пока… 

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

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

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

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

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

Привет! Меня зовут Филипп Кондрашов, я руковожу разработкой DS-решений в бигдата билайн. Как-нибудь расскажу вам, как наша команда строит лучшие модели скоринга. 

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

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

С чем поможет материал из статьи:

• Освободиться от вертикальных взаимоотношений

• Найти общий язык с менеджментом

• Управлять командой во времена хаоса и гармонии

• Не сойти с ума

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

Так как же объяснить концепцию «плохого кода» обывателю?

Привет! В рамках своей работы в beeline tech мы часто взаимодействуем с геоданными. Для решения проблем, связанных с хранением, обработкой и анализом большого объема распределенных пространственных данных, мы используем Apache Sedona (бывший Geospark). Мы — Денис Афанасьев, аналитик больших данных, и Женя Рыбалкин, инженер больших данных, под катом расскажем, почему выбрали именно этот инструмент и что он умеет. А чтобы показать, зачем вообще работать с геоданными, давайте возьмем пример расчета посещаемости хоккейных матчей в Москве, как-никак плей-офф в разгаре.

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

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

Зачем вообще кому-то нужны геоданные?

Привет!

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

Привет! В рамках нашего цикла постов про дашборды в СИБУРе и их практическую пользу для компании не смогли обойти стороной M2F – это обслуживание и ремонты, туда входит множество метрик из различных направлений бизнеса. Это могут быть метрики, которые показывают загруженность ремонтного персонала на предприятии или метрики затрат, например, «Поддержание основных фондов», а также имеется большой блок «Надежность».

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

Чуть не забыл представиться! Меня зовут Миша Делендик, и я как раз отвечаю в СИБУРе за разработку дашбордов по сквозным процессам M2F. В этом материале подробнее расскажу о том, как мы анализируем различные части процесса, чтобы оборудование работало без, кхм, нештатных ситуаций.