Артем Воронов

Любой современный треккер позволяет настроить частоту передачи и отправлять данные в API.
По большему счету для обычных нужд подходит любой треккер и частота передачи раз в 1-10 минут.
Если нужно еще мониторить показания топливных датчиков и дополнительной телеметрии надо брать что-то подороже.
Ну если задача стоит трекать спортивные мероприятия, необходимо подбирать специфичные профессиональные датчики.

Звучит как задача для Elastic (хранение логов) + Kibana для визуализации.

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

Что попробовали, но работает не очень:
- собственный DSL. Слишком дорого в поддержке, онбоардинг разработчиков превращается в ад.
- Использование шаблонов и маппингов специфичных для каждого истончика с помощью специфичного софта типа Xceptor. Опять таки дорого в поддержке и недостаточно гибко.

Что работает хорошо:
- Разделение процесса на этапы, все по классике Data Science: очистка данных от мусора, стандартизация форматов и т.п. Это позволяет не дублировать одну и ту же логику в отдельном обработчике для каждого источника, а консолидировать правила в одном месте.
- Elastic для перевода, синонимов и обработки опечаток
- Кросс проверки с дополнительными источниками данных, где это возможно

Notion как алтернатива Obsidian. Ультра просто и удобно.

Я собрал 3 подобных сервиса, как для Glonass/GPS, так и для AIS. В текущем решении 180 000 единиц транспорта отслеживается. Вот несколько базовых моментов из опыта:
1. Приборы отправляют данные на сервер сами, а не наоборот. Твоя задача принимать и быстро сохранять данные в бд. В какой - не важно. У меня хорошо работает связка из реляционной бд для оперативных данных типа текущего положения, nosql для архива.
2. Протоколов у трекеров огромный зоопарк, у каждого производителя свой. Не привязывай свою реализацию к конкретному протоколу. Сделай общий API для сохранения данных в базу, а затем уже подключай протоколы по мере необходимости.
3. Если тебе нужен геофенсинг, сразу закладывай event-driven архитектуру. Опять таки не важно какой ты возможешь брокер сообщений.
Все остальное вторично. Для отображения данных хоть на любом low-code забирай данные напрямую из оперативной базы и отображай на карте.

решал подобные задачи связкой TeamCity + Jira + Confluence: При деплое на Prod TeamCity подтягивала список заплоенных stories из GIT. Далее небольшой скрипт формировал страницу в Confluence, подтягивая детали stories из Jira. Завершалось это все сообщение в Slack c ссылкой на полученную страницу.
Это требует договоренностей с командой разработки, например, user story Id должно присутствовать в описани коммита.

Для получения данных об ограничении скорости не нужно отдельное устройство.
Если уже подключены как-то к круиз контролю, почему бы не получать текущие координаты от бортой системой навигации? Полученные коордианты и надо испольовать для запроса скоростных ограничений. Не стоит также ничего конвертировать в текстовый формат. Вместо это надо дергать API специализированных сервесов, например Google Roads - Speed limits. Наверняка аналогичные API есть у Яндекса и 2ГИС.

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

В таких случаях хорошо сработает связка из NoSQL + GraphQL.
NoSQL даст возможность использовать одну и туже коллекцию для всех страховых, то есть сможете легко строить аналитику без 100500 join
GraphQL позволит гибко настраивать payload для внешних API

Наверняка вы уже трекаете активность пользователй в приложении. Если юзер не активен в течение N дней\месяцев, помечайте его как удаленный\замороженный\etc.
Заодно можно пуш кинуть ему от системы, чтобы попробовать активировать опять.

Это вам в Airtable надо, там есть контроль доступа на уровне таблицы, листа или view.

Боюсь что ты решаешь задачу с не того конца.
Курс ЦБРФ может быть один, но реальный курс зависит от банка и способа оплаты. Разница может доходить до 10%. Если включить случаи double-conversion, то ошибка может быть еще больше.

Приходилось решать подобные задачи, когда простейшим случаем была покупка контента за AED, оплата его кэшем в EUR, с полседующей перепродажей через AmericanExpress в USD. Сумма с точностью до цента получается только постфактум. И далеко не всегда платежная система дает тебе полную раскладку по комиссиям и курсам.

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

Давайте я вам тут немного помогу расписать потенциальные сегменты ЦА:
1. Новички фрилансеры, совсем начинающие стартапы до 5 человек. Выбирают Google docs, договариваются о структуре папок. И страдают после того как количество докумиентов переваливает за 50.
2. Опытные фрилансеры как минимум знают о существовании OneNote или EverNote, которые позволяют шарить свои блокноты с другими людьми. OneNote кстати полностью бесплатный. Теперь вопрос, как вы с ним собираетесь конкурировать?
3. Команды 2-10 человек. Начинают понимать, что текстовые документы плохо работают для шеринга знаний и постановки задач, открывают для себя Notion/Obsidian. Причем оба можно начать использовать бесплатно и только полностью вкатившись, покупать платную версию. А в Notion еще удобные темплейты для управления проектами и AI ассистент для написания текстов. Куча интеграций с Miro, Google Docs и Figma позволяют держать весь объем знаний в одном месте без необходимости синхронизировать все вручную. С поиском Notion уже справляет лучше Google Docs, но управления правами доступа и история изменений хромают.
4. Стартапы с десятком команд и большие компании. Тут уже все серьезно. Нужно управлять доступностью страниц, знать что и когда поменял в тексте, уметь в большее количество интеграций. Нужен нормальный полнотекстовый поиск по материал. Тут уже вступает в бой Confluence + плагины для Miro/ProductBoard/Slack/Teams/etc.

У ASP.Net есть scaffolding, еще лет 8 назад собирал на нем базовые админки. Валидации задаются через атрибуты моделей.
Сейчас админки собираю за минуты в Retool, без гемороев с деплоями и быстрыми изменениями. У Mendix и OutSystems базовая автогенерация кода из моделей тоже есть.

Есть рассылка Founder Finds от trends.vc, там тусовка солопринеров