🤔 Как хранить в БД объекты с иерархией наследования?

Столкнулся в тралеботе с необходимостью хранить разные типы вопросов:
 
Есть вопросы с вариантами ответов, а есть вопросы, на которые нужно просто написать правильный ответ. У обоих классов есть базовые свойства и отличаются они одним полем. Значит удобно будет отнаследоваться от базового класса.
 
Как такое хранить в базе? Нашел статью, где рассказывается, что такое можно делать на вьюхах. Мне как-то вьюхи не особо нравятся. Даже не знаю почему. Просто не люблю, когда есть какая-то сущность, которая по сути не совсем настоящая. Появляется то, что Дерек Комартен называет indirection (типа непрямолинейность или хз, как это перевести).
 
Короче, погуглил еще, как такое делается. И в Entity Framework используется самый простой и прямой подход – на всю иерархию одна таблица Table Per Hierarchy. И еще используется Table Per Type  и Table Per Concrete Type (которая по сути тот же Table Per Type только с улучшенной производительностью).
 
Сидел читал про это дело и вот что вычитал. Судя по ответам на StackOverflow никто не юзает вьюхи для того чтобы работать с иерархиями наследования. Ну или точнее это не первая польза от них.
 
Так что как будто выбор идет между двумя подходами.
 
❓ Если работали с такой иерархией, то поделитесь, пжлст, какой подход выбрали, и к чему в итоге привело – было удобно или появились какие-то подводные камни?

🍩 Сходил и узнал, как работает благотворительный фонд.

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

То есть вот я хочу задонатить 100 рублей на лекарства, а вдруг выйдет, что из моих 100 рублей 90 пойдет на оплаты работы штаба, собирающего деньги, а только 10 на лекарства. Получается как-то обидно. А если они вообще не смогут собрать нужной суммы, то что произойдет? Все пойдет на оплату штаба, который работает вхолостую?

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

1️⃣ Штаб живет на средства, полученные от фонда развития,а не на средства от сборов. То есть все 100 рублей от моего доната пойдут на лекарства. Таким образом разрешается конфликт интересов.

2️⃣ Когда ты делаешь благотворительный проект, то ты по сути питчишь его как стратап на всяких встречах с этими фондами.

3️⃣ На питче ты коммитишься по определенным целям: сколько привлечешь донатов, сколько людей будет пользоваться помощью твоего проекта, уровень, ниже которого не будет падать текучка волонтеров.

4️⃣ Также ты показываешь свой опыт организации подобных проектов или же участия в них. Без этого тебе никто ничего не даст.

5️⃣ Вся эта схема с питчами работает для европейских благотворительных фондов. Есть российские фонды, там распределение средств идет по-другому.

6️⃣ Еще из интересного. Когда был в офисе ребят, то заметил, что они используют какой-то софт для распределения складских остатков. Я честно думал, что это будут просто гугл-таблицы. Но оказалось, что существует целая куча сервисов для благотворительных организаций, управления складами и волонтерами и так далее. К примеру вот такая CRMка для волонтеров. Это круто, потому что вы можете разрабатывать такой софт, получать при этом деньги, и одновременно понимать, что точно делаете что-то полезное.
 
Вообще в процессе разговора у меня сложилось приятное впечатление. Как будто я попал в Додошный офис, где тебе буквально каждый может провести экскурсию и в деталях рассказать, и как что разрабатывается, и как основная бизнес-модель устроена, и подсветит открыто недостатки, если такие имеются. В общем, сложилось ощущение прозрачности.

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

⚾ Специалист по PostgreSQL выдал базу.

Часть 3. Чек-лист оптимизаци запросов

Что вам нужно знать, чтобы понимать, как оптимизировать запросы:

1️⃣ Как читать статистику распрделения данных в БД. Как я понял имеется в виду представление pg_stats.

2️⃣ Есть планировщик и экзекьютор. Планировщик опирается на ту статистику, которая собрана по таблице в pg_stats. По умолчанию он анализирует 30000 строчек. Можно настроить для каждой таблички свой сэмпл. В MySQL есть аналоги.

3️⃣ pg_stats – важные колонки:
🟠n_distinct – количество уникальных значений в одной колонке. К прмеру для булеана понятно, что это значение будет 2.
🟠correlation – упорядоченность данных
🟠null_frac – количество нуллов
🟠most_common_vals – наиболее часто встречающиеся значения (ну типа если у вас таблица с транзакциями, то в этой графе первым значением будет "выполнено")
🟠most_common_freqs – частота их встреч (ну и тут соответственно будет что-то типа 0.99 это для значения "выполнено")

4️⃣ Для анализа запроса желательно вручную собрать сэмпл на 30000 записей, как это делает планировщик.

🫡Интересный факт: Иногда статистика планировщика может быть собрана по неудачному сэмплу, и это просадит запросы. Событие редкое, встречается раз в год, один раз на сто баз.

#postgresql #андрейсальников

⚾ Специалист по PostgreSQL выдал базу.

Часть 4. Типы индексов в постгрессе

🌳 b_tree - самый типичный, работает в 90% случаев.

#️⃣ hash – сейчас по сути бесполезен. Потому что работает медленнее B-tree и нужен был когда-то потому что попросту занимал меньше места.

📐 gist - это индекс для геоданных и геометрии. Раширения: pg_trgm – поиск по регекспам и по лайкам. Btree_gist – сложные constrains с интервалами.

📐 sp_gist – нет практических применений. Это научный индекс. Более гибкий

🪄 gin - может сильно просадить диск, хорош для текстового поиска,

💬 jsonb – jsonb_ops – операция для поиска по большому джсону, json_pat_ops

◾ brin — (индекс сил Альяна, если вы понимаете о чем я) крайне компактный индекс, если данные упорядочены, то мы можем из блока который читаем проиндексировать наименьшее и наибольшее значение. Это как части в фильмах по сути. Мы не знаем, в какой конкретно минуте хоббиты будут бросать кольцо в лаву, но знаем, что не в первой и не во второй частях, так что там можно не искать (это мой ебанутый пример, не автора). Хороший трейдоф между размерами и производительностью.

#postgresql #андрейсальников

⚾ Специалист по PostgreSQL выдал базу.

Часть 5. Indexes Null or Not Null

Про нулловые индексы:

1️⃣ Если у вас есть нуллабельные поля и вы делаете по ним индексы, то делайте индексы с условием is not null. Особенно это пригодится, если вы делаете индекс по Foreign Key

2️⃣ Не забывать создавать ForeignKey это даст ускорение в 2055 раз и уменьшение размера в 14 раз. По умолчанию не создается. И я тут для себя подметил, что пожалуй это единственный индекс, который можно создать прям до того, как в таблицу польются данные.
 
Indexes Partial
1️⃣ Параллелить нагрузки в OLTP базах нельзя. То есть делать так, чтобы несколько потоков выполняли один запрос – это подходит для Аналитических баз, но не для процессинга транзакций – целиться нужно в то чтобы одна транзакция выполнялась как можно быстрее.
 
2️⃣Нужно быть с индексамы аккуратнее.

❌ Вот такой индекс не очень.

create index strange on sometable ((state == 'ожидание'));

Этот индекс будет идти по булевскому значению данного выражения, то есть по трем возможным значениям true false и null (если данных в поле нет). То есть по сути такой индекс будет мало фильтровать данных.
 
✅ Вместо этого стоит создавать индекс по нескольким полям:

create index strange on sometable (created_at) where state != 'обработано'

Это partial index. Офигенная фича так-то, то есть индекс строится не для всех строк таблицы, а только для тех, что указаны в условии. Это компактизирует индекс. К сожалению MySQL не поддерживает эту фичу, но я StackOverflow'ил вот такой обход этой проблемы.
 
3️⃣ Забавно, что вот такой вариант:

create index strange on sometable (created_at, state)

занимает чуть меньше места чем вот такой:

create index strange on sometable (state, created_at)

все дело в том, что такой вариант размажет данные по b-дереву чуть лучше. А разница в выполнении не существенная.

🚴 🔛 🗺 Помощь зала. Курьер на карте.

Помните я писал про то, как устроен курьер на карте? Так вот выяснилось ожидаемое, но то, во что не хотелось верить: Курьер на карте перемещается рывками.

Причины рывков разные: где-то телефон заглючивает, где-то частоты обновлений не хватает, где-то спутник не ловит. Почти уверен, что мы еще словим внезапные перемещения на другую часть земного шара в зоне, где GPS глушится. Но пока не словили.

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

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

❓ Запрос на помощь зала: Подозреваю, что без простройки пути и привязывания пришедших точек к этому пути не обойтись, но вдруг есть какой-то выход попроще? Вдруг вы где-то видели статьи в интернете о том, как работатет стриминг движения объектов объектов по координатам? И какие подводные камни несет, и как все это можно обойти? Запрашиваю в общем помощь зала, а то я что-то не нагуглил ничего вменяемого 🐈️️️️️️

🐈‍⬛ Да что такое этот ваш Aspire?!

Как только вышел новый .NET я сразу обратил внимание на этот самый Aspire. Как и положено наивному неофиту, я по первости полайкал – можно быстро засетапить проект, не обращая внимания на инфру, и все будет просто работать. Причем со всеми метриками, дашбордами и прочим.

Но ливером я почувствовал что-то неладное 🍑 .

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

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

1️⃣ Если у вас мультиязыковой проект (к примеру Go у вас и Kotlin и C#) и вы хотите наладить в нем Observabilty так, чтобы можно было потрейсать все сервисы, то Apire вам по понятным причинам не подойдет.

2️⃣ Если вы делаете стартап, то, да, эта фиговина позволит вам быстро засетапить все подряд и понять, почему ваш супер-стартап лег на повышенных нагрузках при запуске (это если вам еще повезет такой стратап запустить. Скорее всего вы будете разбираться в причинах того, почему вообще никто не пришел). При этом, если стартапу повезет и он разрастется, то остается опасность того, что Microsoft рано или поздно просто забросят поддержку этого туллинга и вам рано или поздно придется переезжать на графану, ягер и прочие такие штуки. Ну и не факт, что это не будет больно.

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

Пока что я вижу только один реально более-менее подходящий сценарий – это сценарий номер 2️⃣. И то выглядит рисковым на долгосрочном интервале.

Короче, пока что выглядит как та самая штука, которую ты будешь выпиливать, когда придешь новичком на проект через пять лет. И в целом попахивает WCF'ом от этой штуки. Но все же хайпуют? Объясните, что я там не так увидел?

P.S.: А для крутого дашборда по всем вашим сервисам, есть к примеру coroot с охуенной лайв-демкой 🥹

🏭 Fun Fuckt: сколько версий меню нужно для счастья?

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

1️⃣ Посмотрть, кто еще запрашивает старую версию,

2️⃣ Сколько денег все эти запрашивающие приносят,

3️⃣ У кого из запрашивающих все работает корректно, а кто лезет в старую версию, потому что что-то сломалось.

4️⃣ Поглядеть в код андроида, как там реагируют на новую версию менб, поглядеть код iOS, а там как?

5️⃣ Обсудить со всеми до какой версии можно хардапдейтнуть оба приложения, и, когда это можно сделать.

6️⃣ Скрестить пальцы и молиться, чтобы в хардапдейтнутой версии проблем со старой версией меню не было. Реально молиться, потому что этот хардапдейт делается только раз в год в ночь на Ивана Купалу. Если все плохо, то тогда старая версия меню с нами останеться еще на несколько сезонов.

А еще, когда смортю на разницы в версиях, то по ощущениям, будто смотрю на спил дерева – по истории изменений можно просмотреть на то, как менялось наше отношение к продуктам (да и хрен ли там – во многом рынок доставки): вот тут были просто пиццули без заморочек, а тут уже какие-то метапродукты – продукты, которые состоят из каких-то других продуктов. Фракталы, получается.

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

🎤 OneOf библиотечка vs обычный record

Помните я рассказывал, что есть библиотчка OneOf для симуляции Discriminated Unions и, что она, довольно таки первоклассной качества. Ну, короче, перевожу разряд качества оной во второй.

В комментах к тому посту Саша Журавлев aka @sagos95, поделился тем, что он всю эту дискриминационную петрушку делает на наследовании рекордов. И пару недель назад тут на работе тоже поделились этим лайфхаком, как все то же самое можно сделать на рекордах (пояснительный дикпик выше).

Я на выходных сел и посравнивал. Прибросил прям нос к носу оба метода на живом коде. Взвесил все плюсы и минусы и понял, что на рекордах получается круче!
 
🟢 В случае, если вы расширите сет выдаваемых результатов, то вам не нужно будет во всех методах бегать и прописывать дополнительный тип, как в случае с библиотечкой OneOf
🟢 Это дает чуть больше строгости в типизации возвращаемого типа: вы прямо говорите, что результат перевода вот такой и может быть одним их этих трех вариантов. То есть любой метод, возвращающий такой результат будет обяхан поддержать все три концепции. В случае с OneOf вы по сути для каждого метода создаете свой набор возвращаемых типов.
🟢 Есть только один для меня плюс у OneOf  – я явно вижу все варианты, которые может вернуть метод. Но, по факту, мне это нужно редко и я бы не стал жертвовать предыдущими пунктами ради этого.
 
🅰️ Итого: делать вариативный возвращаемый тип на рекордах будет попервоклассней. Ну и библиотечку никакую не нужно ставить – минус одна левая зависимость. Короче, к черту этот OneOf.

🎙 Ежегодный подкаст.

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

Народ статью посмотрел, поразбирал по закладкам, лениво полайкал, но комментов оставил немного.

Короче, прошла статья, как мне показалось, незамеченной. И вот, внезапно выстрелила! Её добавила себе в закладки Оля, ведущая подкаста "Помогите, я джун". Ну и предложила записать совместный подкаст про самообразование. Так сказать поговорить о полезном для молодых умов.

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

Да, а подкаст ежегодный, потому что год назад, примерно в это же время мы с Пашей Притчиным тоже записали выпуск для его подкаста "Разговоры CTO".

Так что получается уже почти традиция. Надо в следующем году тоже куда-то вписаться будет, чтобы не выглядело, как простое совпадение.

🧜‍♀️Топовая русалочка

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

Показали вчера на работе, и я чет с этого дела прям проперся. Называется mermaid.

Суть в чем. Пишете вот такое в ридмихе, а при рендере получаете то что показано в пояснительном дикпике 🍆.

stateDiagram
    [*] --> Still
    Still --> [*]

    Still --> Moving
    Moving --> Still
    Moving --> Crash
    Crash --> [*]

🌝 Чем полезно
Мое скромное мнение 🌚 в том, что дока должна лежать как можно ближе к коду. Но есть нюанс. Когда рисуешь диаграмы в миро, к примеру, и прикрепляешь фотку к доке, это работает плохо.

То в миро поправят, а фотку не обновят, то доску грохнут. Короче, может разъехаться что-то.

А тут все в одном месте.

🅰️Итого: Хотите нарисовать схему в вашей доке – используйте mermaid.

PS. Когда я сегодня бегал и размахивал mermaid'ом, говоря, какая это охуенная штука, ко мне подошли и объяснили, что оказывается есть еще одна похожая штука, называется PlantUML. Она примерно про то же, так что у нас теперь есть выбор!

💻 Почему код на хакатоне пишется быстро, а на работе медленно.

Недавно увидел вот такой мем. И понял, что не могу оставить без ответа.

В Додо ребята из бизнеса тоже удивляются, такой разнице в сокрости.

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

Как быстро вы выполните эту задачу? Да, продажа яблок для вас что-то новое, но вы видели, как это делают бабушки на рынке, и примерно понимаете, что делать и за день справитесь.
 
Теперь усложним: "Продайте 100 кг яблок". Согласитесь, что уже придется немного заморочиться с логистикой. Но думаю, вы и это осилите.
 
Ещё усложним: "Продайте 1 000 000 кг яблок." Как быстро вы справитесь? Чувствуете, что этого слона так просто по частям не сожрать?

1 000 000 кг яблок сложно просто куда-то доставить. И нужно попотеть, чтобы продать – вы должны значть, как и где нанимать грузоперевозчика, какой из них готов выполнить эту задачу правильно, чтобы весь лям килограмм яблок не протух по пути к покупателям. 😖
 
Но даже знание всех тонкостей не гарантирует, что вы продадите 1 000 000 кг так же быстро, как и 10 кг.
 
Во всех задачах у нас яблоки. И казалось бы, ты же продал 100 килограмм, ну продай так же быстро миллион!
 
То же самое и с фичами. Сделать фичу для 10 человек – это, как продать 10 килограмм яблок. Но сделать фичу для миллиона человек – тяжело без знания инструментов, и даже с инструментами, это не получится сделать так же быстро как для 10 человек.

🅰️ Итого: Короче, если аналогия понравилась, то можете пользоваться ей, чтобы вас чуть лучше понимали. Это не снимает с нас, как с инженеров, ответственность за ускорение разработки, но по крайней мере помогает понять ребятам, принимающим решения, что скорость поставки сильно зависит от количества пользователей. А понимать друг друга – это практически синоним слова "доверять".

От мира дотнетчиков, как мне кажется это лучшее поздраление! К нему я и присоединяюсь 🎄

🧐 Практика попизже всяких KISS, DRY и прочей аббревиатурной хуиты: Dependency pruning

Общались недавно со Степой Гранкиным (автором одного из самых популярных навыков для Алисы), и я ему как всегда ныл, про то что мир меняется слишком быстро и непонятно, кто все эти люди, которые знают, какие апдейты, в каких библиотеках происходят?
 
И тут Степа сознался, что он теперь один из них…

Оказалось, что у него в команде принята практика Dependency pruning. В общем, её задача в том, чтобы регулярно удалять неиспользуемые/обновлять используемые в проекте библиотеки. И ты не просто плашечку вверх двигаешь, а читаешь доку. Что там поменялось, что крутого дает и так далее. И делать это раз в неделю или раз в две. Тут как сами решите, но желательно почаще.
 
Выходит регулярно и по чуть-чуть – не так больно, как все везде и сразу и по вдохновению.
 
Я использую эту связку вот в таком для себя сценарии – попробовал интересные мне библиотеки в свои пет-проекты и регулярно их обновляю. Раз в две недели. Плюс пет-проектов в том, что можно добавлять еще незрелые штуки и следить за ними. Это не очень оказывается запарно, но дает хороший триггер для нестрессового обновления знаний.
 
Пишу “нестрессового”, потому что для меня пиздец какой стресс, когда заходишь, а там – ебать-читать. 🤬

🅰️ Итого: Попробуйте завести в пет-проектах или на работе практику регулярного обновления зависимостей – и код в чистоте и голова в порядке. 👨‍⚕️

🎧 Вот вам и пример применения практики (может не самый лучший, но все же)

Недавно (9-го января) заехал новый релиз testcontainers-dotnet. Из него я узнал, что там обновился какой-то Ryuk. Заодно узнал, что это за хрень такая.
 
Оказывается это resource reaper! Это ничем не примечательно, кроме того, что я сейчас играю в Mass Effect 3 и уничтожаю сраных жнецов(reapers)

🏭 А resource reaper – это штука, которая уничтожает контейнеры в докере, после того как они перестают быть нужными.

В любом случае, для общего кругозора интересно. Потому что я, если честно думал, что всем этим сама библиотечка TestContainers занимается, и типа если быстро хлопнуть 🍔 бургер за Собянина запущенные тесты, то получится контейнеры не сдохнут. А оно вон оно как.
 
P.S.: получается в докере постоянно происходит та же херня что и в mass effect! Наверняка контейнеры тоже строят горн и пытаются победить жнецов!

PPS: А еще эта штука названа в честь персонажа из “Тетради смерти”. Придется еще и ониме теперь смотреть. Видите какая практика полезная!

🛵 Курьер на карте – продолжение.

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

Но и по-своему неприятно – значит что-то не работает. Ибо вряд ли кто-то пришлет скриншот с подписью "Глянь как заебись работает!" Если это не дикпик, разумеется.

🔥 Решили в общем бороться с проблемой. Для этого приступили к сбору информации. Решили придумать дашборд, который вмещает в себя всю необходимую информацию о том, как там с нашей точностью.
 
Получился дашборд, который скорее показывает, как там обстоят дела с нашей неточностью. Он собственно на пояснительном дикпике. Ну и по нему видно, что поездок с достаточным количеством точек – меньше половины. Грустненько.
 
В общем наша фича содержала фатальный недостаток и не один, а целых четыре:

👌 Поставили интервал обновления в 1 минуту. Это оказалось катастрофически мало. Так было специально – не хотели перегрузить МАПИ в новогодние пики. Но мы еще и не дали возможность получать этот интервал с бэка, а значит изменить его так просто не получится.

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

👌 Не учли, что координаты могут приходить с отвратительной точностью – типа километров в 200. В наше-то время и такой просчет. И не стали отсеивать такие точки, а просто отдаем их как есть. Мне почему-то стыднее всего за этот пункт, ведь в принципе я с этим лет пять назад уже сталкивался.

👌Еще есть недостаток, про который мы знали, но пока решили забить – когда курьер доставляет два заказа, как это отображать? получается сейчас временами курьер как бы съебывается от вашего дома, причем все время глядя на вас. Но на самом деле сделать как-то адекватно эту фичу сейчас нереально сложно, поэтому решили отложить.

🅰️ Итого
Сейчас выходит, что только ~30% пользователей видят фичу на уровне "сносно", у остальных она не работает. (на дикпике красным показан процент не от общего числа поездок,а от тех, на которых вообще курьер показывается, поэтому я указываю прям реальный процент).

Но руки не опускаем. 🛐 Сначала исправим частоту обновления, потом сделаем так, чтобы как можно больше курьеров по возможности использовали приложение для старта поездки. Ну и напоследок доведем до ума саму отправку координат, прикрутим фильтры для отлова точек с низким accuracy, посмотрим, как сделать так, чтобы сами точки чаще отправлялись (кстати уже процент ползет вверх понемногу).
 
Ну и, конечно, молю всех богов, чтобы все это успеть сделать до конца января. Ибо, ну не круто ваще, когда такая фича, и такое говнище.
 
Короче, вот такие дела. Может вам будет полезно, если будете делать что-то с картами. Ну и делитесь опытом, если тоже нарывались на подобное дерьмо.