По мотивам Adidas Running (ex. Runtastic)

Как я бы проектировал это интересное, но малоизвестное у нас приложение в роли архитектора.

Предыстория

Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.

Адидас имеет объем продаж 20–30 млрд долл. в год.

Основной рынок – США, остальные страны – второстепенные рынки.

D3.js (или просто D3) это JavaScript-библиотека для обработки и визуализации данных. Она предоставляет удобные утилиты для обработки и загрузки массивов данных и создания DOM-элементов. Эта заметка описывает работу с основными методами библиотеки, она подойдёт для изучения основ библиотеки и погружения в её логику и возможности.

Для понимания статьи пригодятся знания JS, HTML и CSS.

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

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

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

«Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях».

Из книги «Эволюционная архитектура. Поддержка непрерывных изменений»

Привет Хабр! Сегодня публикуем вторую часть материала об архетипах программных архитекторов. Если пропустили, то вот первая часть.

Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.

В статье мы рассмотрим следующие типы баз данных:

Улучшаем читаемость схем и повышаем производительность

Всем нам (ну хорошо, большинству!) приходится иметь дело с Apache NiFi в качестве ETL-инструмента. У нас он используется для управления потоками данных в платформе ZIIoT (кому интересно, что это за зверь, можно почитать здесь). Apache NiFi — инструмент хороший, местами удобный, позволяет быстро решать задачи, в том числе и достаточно высокой сложности, не формируя для этого отдельную группу разработчиков. Однако, как правило, по ходу проекта условия этих задач меняются несколько раз, и нередко их решением на разных этапах занимаются разные люди в режиме аврала. И вот в результате мы видим НЕЧТО

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

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

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

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

Банковская карта — вещь такая же привычная, как смартфон: есть у большинства, и ей пользуются ежедневно миллионы людей. Впрочем, именно «карта» постепенно становится пережитком прошлого, уступая место тем же смартфонам в качестве платёжного средства. Но и пластиковыми кредитки были далеко не всегда. А какими были? Вернёмся в 1888-й — к самому началу.

Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.

Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.

Рекомендуемый минимум

Ниже приведены основные элементы для любого веб-документа (веб-сайта/приложения):

meta charset — определяет кодировку веб-сайта, стандартом является utf-8.

meta name="viewport" — настройки viewport, связанные с мобильной отзывчивостью

width=device-width — физическая ширина устройства (отлично подходит для мобильных устройств!)

initial-scale=1 — начальный масштаб, 1 означает отсутствие масштабирования

Элементы

Допустимые элементы <head> включают meta, link, title, style, script, noscript и base.

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

RPA (Robotic Process Automation) сейчас в некотором смысле напоминает старую добрую миниатюру Реввы: “Киииборги. Они заполонили всю планету!”. Про RPA говорят все чаще и чаще, появляются статьи и видео, рассказывающие о небывалом росте этого сегмента и многомиллионных экономиях тех, кто уже внедрил у себя RPA. Не то, чтобы и раньше этого не было, но сейчас стало уж совсем много.

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

Некоторое время назад, столкнувшись с определенными задачами, я выбирал средство для их решения и обратил внимание именно на RPA. Прорвавшись через миллион рекламных статей и восторженных видео от реселлеров, протестировав практически все, что доступно в trial / free версиях, я остановился на Automation Anywhere, который неплохо подходил под требования. Позже, к слову, я обнаружил что в нашей компании существует целый отдел, который занимается автоматизацией с помощью Blue Prism. Обратная, так сказать, сторона крупных корпораций - не всегда знаешь, что у нас уже есть…

Ну да речь не об этом. Не сразу, но через какое-то время я обнаружил, что самая сложная задача в RPA, это вовсе не написание роботов и не процесс их имплементации и сопровождения. Самое сложное - это управление ожиданиями на стороне менеджмента. Понимаете - они не инженеры, они управленцы. Они не понимают и не знают как, а главное почему, многие вещи работают так или иначе. Они читают такие же рекламные статьи и смотрят такие же рекламные видео как я в самом начале - и делают вывод: “Это же то, что нам нужно! Это решит все проблемы!”. И начинают интенсивно форсировать процесс внедрения. И хорошо, если есть  внутренний инженерный ресурс, который этим вопросом будет заниматься и подскажет, что где и как. А вот если задача попадет к интеграторам - это может быть большой проблемой. Может быть не сразу, может быть в перспективе, но я думаю что обязательно будет, и вот почему:

Pulsar или Kafka — что лучше? Здесь мы обсудим плюсы и минусы, распространенные мифы и нетехнические критерии, чтобы найти лучший инструмент для ваших задач.

Обычно я рассказываю об Apache Kafka и ее экосистеме. О Pulsar за последние годы меня спрашивали только коммитеры и авторы Pulsar. Они задавали сложные технические вопросы, чтобы показать, что Kafka не идет ни в какое сравнение с Pulsar. На Reddit и подобных платформах разгораются яростные и очень субъективные споры на эту тему. Я поделюсь своей точкой зрения, основанной на многолетнем опыте работы со стриминговыми опенсорс-платформами.

В детстве практически каждый из нас ходил в кружки моделирования и пытался строить свои радиоуправляемые модели. Скажу сразу, ни одну управляемую модель я так и не собрал, хотя ракеты мои летали исправно и даже приземлялись на парашюте ("Илон, трепещи!"). Довольно много прочитал про это, но нелёгкая увела в сторону ИТ и моделирование забросил.

Лет 5 назад мне подарили дрон, ноунейм дрон. Это была очень простая копия DJI Phantom 1, которая не умела держать высоту, летать против ветра и снимать лучше кнопочного телефона 2002 года. В общем, один раз запустили, у него сели батарейки, да и больше не было желания к нему прикасаться. Зато вновь появился интерес к радиоуправляемым моделям (дронам).

Дальше мне подарили DJI Spark - мой первый нормальный дрон, который умел снимать вот так