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

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

Обе библиотеки представляют из себя дополнительный слой, который отображается поверх любой карты, такой как Open Street Map (OSM), Google Maps, Яндекс.Карты и многие другие популярные платформы. По сути, библиотека предоставляет инструменты для визуализации, манипулирования и взаимодействия с картографическими данными непосредственно внутри вашего приложения, не ограничиваясь каким-либо одним провайдером карт.

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

Уважаемые читатели, меня зовут Ольга Чикова и я бизнес-аналитик компании «МегаФон». Долгие годы я работала в сфере закупок и проектов оптимизации стока, а в 2025 году перешла в аналитику, чтобы помогать другим представителям бизнеса лучше доносить свои требования до it команды. 

Самым большим проектом в 2025 году для меня стало внедрение системы маркировки «Честный знак». Я хотела бы поделиться своим опытом подготовки к вступлению в систему маркировки, рассказать, каких ошибок можно избежать, на что сделать упор в подготовке и как не потратить зря время и деньги.

Кратко о том, что необходимо знать при знакомстве с «Честным знаком»:

Обязательная система маркировки «Честный знак» запущена в России в 2018 году. В октябре 2025 года система маркировки действовала уже в 33 товарных категориях, и еще 13 сейчас являются пилотными. Кто в РФ решает, какую категорию товаров включать в систему «Честный знак»? Решение принимает Правительство РФ по представлению Минпромторга. Это длительный процесс, который состоит из нескольких этапов: сначала проходит эксперимент, после его завершения выпускается постановление правительства, затем наступает этап обязательной маркировки для всех участников рынка.  

Товарные категории разделены по направлениям: шины и покрышки, лекарства, товары легкой промышленности и т.д. У каждой товарной категории свои правила, где-то они совпадают, а где-то различаются, причем достаточно сильно. Если ваш товар относится к экспериментальной группе, то настоятельно рекомендуем вам вступить в эксперимент как участник (как вступить в эксперимент описано на сайте «Честный знак»). Во-первых, вы будете в курсе всех изменений, во-вторых, вы сможете задавать вопросы по товарной категории не только по электронной почте, но и онлайн на общих встречах с организаторами.

В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.

Здравствуйте! Я Дина Лакеева, в разработке я с 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.

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