Целое поколение писало свои первые программы на 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 месяца в лаборатории. 

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

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

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

Технология NVMe через различные фабрики (далее NVMeOF) оформлена в качестве стандарта летом 2016 года, она была встроена в пятую ветку ядра Linux.

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

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

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

Задача: подключить много дисков с нескольких серверов

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

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

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

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

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

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

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

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

Идея проекта

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

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

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

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

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

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

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

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

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

В посте я расскажу, как разбирался для решения этой задачи с методом JTBD (Jobs To Be Done), когда его стоит применять, что можно из этого выжать и причем тут вообще дизайн.

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

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

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

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

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

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

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

С 2015 по 2021 годы я работала в дирекции по продажам конвергентных продуктов Билайн аналитиком, можно сказать, «на все руки» – аналитиком продаж, продуктовым, финансовым. В мою зону ответственности входили операционная и ежемесячная отчетность, расчет планов продаж на квартал, бюджетирование расходов на продажи, расчеты кейсов по инициативам – для всего этого требовалось моделирование основных KPI развития бизнеса. 

Меня зовут Нина Фещенко, с 2022 года в департаменте аналитики розничного бизнеса (B2C) я в большей степени занимаюсь работой с данными и BI-аналитикой, но без моделирования тоже не обходится. В этом посте я опишу свой опыт построения модели прогнозирования продаж конвергентных продуктов (2019-2021), а также прогнозирования оттока мобильных абонентов в 2022 году. Расскажу, как работала модель в относительно стабильный период до 2020-го года, и какие корректировки пришлось внести впоследствии. 

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

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

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

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

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

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

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

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

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

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

В одном из предыдущих постов мой коллега Юрий рассказывал об устройстве нашего мониторинга.

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

Для ленивых или занятых — переходите сразу на последний раздел: там краткая выжимка.