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

Основные способы коммуникаций внутри продуктовой команды

Давайте сравним основные способы коммуникации при гибридной работе, исходя из метода и формы передачи информации. 

Чаще всего речь идет о электронных письмах, чатах, видео/аудио-конференциях, реже — очных встречах.

Итак, по порядку. 

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

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

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

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

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

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

В мае я увидел объявление о наборе сотрудников call-центра в билайн. Решил идти и устраиваться, так как жил один, да еще и вдали от родственников и, конечно же, на самообеспечении. Пора было что-то менять. И я поменял.

Все говорят про webpack-module-federation - микрофронты тут, микрофронты там.
— "А мы уже внедрили", "а мы уже построили микрофронтовую-архитектуру", "мы релизим независимо".

Но начинаешь расспрашивать, "а что сделали", "а как связали" - выходит что за всеми этими броскими фасадами скрывалось добавление вызова ModuleFederationPlugin(...) на уровне рядового потребителя, в лучшем случае с подстройкой конфигурации под локальный и продуктовый стенды. А независимые релизы - обычный авто деплой trunk'а.

На этом фоне доклады, повествующие о динамическом развертывании k8s pod'ов с версиями микрофронтов, указанных в заголовках браузера (на базе argo-cd) производят вау-эффект. Но даже все эти истории имеют один общий недостаток.

На вопрос:
— А как вы реализовали SSR?

Следует ответ:
— Мы не стали этого делать, у нас админка / дэшборд / MVP / *.

Привет! Меня зовут Михаил Благов, я руководитель департамента «Чаптер инженеров данных и разработчиков» в beeline tech. В этом посте я хочу поделиться способом, с помощью которого можно выбрать подходящую архитектуру для конвейера данных в зависимости от требований к нему. В частности, обсудим паттерн CDC (change data capture, aka «захват изменений»), основная идея которого — быстрая репликация какого-то источника в аналитическое хранилище. 

Под катом мы:

- познакомимся с вариантами архитектуры конвейеров данных: из каких компонентов и как его можно собирать,

- рассмотрим и сравним четыре разные архитектуры конвейеров.

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

Начнем с матчасти