Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона.  Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день.

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

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

Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу?

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

Как мы сделали лёгкий игровой тест по мотивам соционики. Задача — дать короткую, но содержательную обратную связь о вероятной командной роли (мыслитель, душа компании, хранитель или лидер) и предложить, как применить свои сильные стороны в работе и учёбе. Это не «ярлык», а удобный язык для разговора о взаимодействии: разнообразие ролей помогает точнее проверять гипотезы и принимать более устойчивые решения.

Эту статью хотел бы посвятить некоторым технологиям распределения/балансировки трафика по разрозненным радиолинкам в пределах одной РРЛ.

В предыдущей статье  «РРЛ для самых маленьких» https://habr.com/ru/companies/megafon/articles/925514/ я рассказывал о некоторых технологиях и решениях, позволяющих увеличить пропускную способность РРЛ (радиорелейных линий):

-          XPIC (Cross-Polarization Interference Cancellation)

-          CA (Carrier Aggregation)

-          SDB (Super Dual Band)

-          или строительство параллельных линков на разных частотах

  Использование этих решений позволяет получить РРЛ в конфигурации N+0 (2+0, 4+0, 8+0 или 16+0), где N – это количество независимых радиолинков. Почему независимых? А потому, что эти технологии не занимаются распределением трафика между линками, у них другая задача – организация дополнительных радиолиний ("стволов").

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

В этой статье хочу поделиться нашим опытом интеграции с Kafka.

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

В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.

При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.

Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.

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

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

Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).

Всем привет!

Всем, кто когда‑либо реализовывал ИТ‑проекты, наверняка знаком термин HLD (High Level Design) и тот факт, что без него достаточно сложно спланировать любой комплексный проект. Более того, в проектах всегда очень хочется пропустить кажущуюся ненужной трату времени на сбор и описание требований и сразу приступить к обсуждению решения, тем более, когда оно кажется очевидным.

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

Итак, нужна архитектура решения (HLD) или она уже есть и надо убедиться в ее правильности.

Для кого эта статья

Эта статья будет полезна разработчикам, которые только начинают писать WPF. Здесь будет рассмотрена механика динамических ресурсов - опытные WPF-разработчики вряд ли найдут что-то полезное для себя.

В современном мире отсутствие возможности выбора темы в приложении считается моветоном. Пользователи любят выбирать удобную для себя цветовую схему, особенно при работе по ночам. В WPF такое поведение не организовано “из коробки”, поэтому мы создаём свою реализацию: задаём ресурсы (цвета и стили), даём пользователю переключать их на лету. О реализации этого механизма мы и поговорим в этой статье.

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

В таких случаях ключом к эффективности становится прямое взаимодействие с метаданными ODI через SQL‑запросы к его репозиториям. Эта статья посвящена именно этому — практической работе со структурой репозиториев ODI и детальному разбору SQL‑запроса для построения потоков данных.

Почему стоит использовать Tagged Unions при разработке на TypeScript

👋 Привет! Меня зовут Александр, я работаю фронтенд-разработчиком в компании «МегаФон». Сегодня я хочу поговорить на тему Tagged Unions (размеченных объединений) и объяснить, почему они ваш секретный инструмент для написания надежного TypeScript-кода.

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

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

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

Речь пойдёт как раз о перенастройке УСПД.

Современные РРС – это уже не просто альтернатива ВОЛС, это уже полноценная, хорошо масштабируемая транспортная сеть.

Всё о современных радиорелейных системах для самых маленьких.

Привет! Меня зовут Геннадий Хараев, я Service Delivery Manager в интернет‑магазине МегаФона. Ниже мой откровенный рассказ о том, как за последний год мы полностью перезагрузили процессы, команды и технологическую платформу. Я сознательно избегаю точныхцифр — важнее настроение, идеи и принципы, которые стоят за нашими изменениями.

Почему мы вообще взялись за трансформацию

Когда я пришёл в проект, интернет‑магазин напоминал большой океанский лайнер: впечатляет, но поворачивает медленно. У нас было всё, что свойственно зрелому, но слегка уставшему продукту: длинные релизные циклы, хрупкий монолит, разрозненные команды, ручные тесты, пул запросов от бизнеса, который рос быстрее, чем мы успевали реагировать. Cкладируя задачи в бесконечную «коробку бэклога», мы рисковали не заметить по‑настоящему ценные возможности. 

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

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

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

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

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

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

Legacy проекты на С++ зачастую являются многокомпонентными, когда продукт использует несколько библиотек, которые имеют различную архитектуру для работы с ними.
Обычно это:

библиотеки, поставляемые как ООП решение (Некоторые модули boost, SOCI как пример)

библиотеки, реализованные в функциональном стиле (OpenGL через С API, POSIX как пример)

Из-за этого в итоговом проекте появляются сущности, которые внутри реализованы через классы, но внутри методов класса идет обращение к обычным функциям. Некоторые библиотеки имеют специфичные функции, которые для своей работы требуют первоначальную инициализацию. Как пример: поиск подключенных устройств и получение на них ссылок для дальнейшей работы или функции, которые требуют инициализации большого количества памяти.
Вследствие этого возникает вопрос - как лучше реализовать покрытие юнит-тестами специфичных объектов, которые внутри себя имеют функции, требующие специальных условий для своей работы?

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor).

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

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

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor). Мы строим скоринговые (credit scoring), лидогенерационные (lead generation) и антифрод (anti-fraud) модели на телеком данных, а также делаем гео-аналитику (geo-analytics).

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

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

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor).

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

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

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor).

В предыдущей статье я поделился материалами для подготовки к одному из самых волнительных (для многих) этапов - Live Coding.

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

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor).

В данной статье разберемся что такое live coding интервью и как к нему готовиться.

Материал в первую очередь будет полезен Data Scientist'ам и ML инженерам, при этом некоторые разделы, например, Алгоритмы и структуры данных подойдут всем IT специалистам, которым предстоит пройти секцию live coding.

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

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

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