Надо отметить — на самих устройствах мы не имели права собирать какие-либо данные, которые могли бы быть связаны с пользователем. Это касается персонификации, местоположения, итд.
Все операции были эфир транзакциями и по определению были публичны, другое дело, что шифровать их нужды не было, так как там не было данных, которые могли нарушать закон. Мы довольно долго проводили аудит этой темы и GDPR с legal отделом, так что в этом проблем не было.
Логи с устройств мы тоже не собирали, по тем же причинам — для нас телефоны были только устройствами которые могли запрашивать у скутера информацию напрямую и отправлять в эфир сеть какие-то транзакции.
Наоборот. Благодаря тому, что данные были действительно анонимизированы, мы смогли собирать со скутеров всю информацию в рамках закона. В эфире пользователи не имели никакой персонализации кроме совершенно случайных публичных ключей.
Ничего вы не ожидали, если хотите конструктив — то будьте добры и сами писать по делу.
На самом деле, то что проект оверинженирен само по себе чистая правда, только вот кроется это вовсе не в масштабировании или доставке обновлений.
Без регулярных удаленных обновлений софта было бы крайне некомфортно проходить даже пилотную фазу. Конкретно пакеты именно через apt и доставлялись, только делалось это не по крону, а по событию от анзибла. Ничего сверх-сложного тут нет, оно работает и стабильно.
А про мониторинг — я пытался описать максимально подробно свой опыт использования стека — авось кому понадобится, а может быть кто-то захочет и скалировать его для своих задач (и не сможет этого сделать). Специально обрисовал видимые нами недостатки, альтернативы, чтобы кто-то мог спроецировать свои требования в будущем.
Тот же эластик, как мне кажется, уже морально устарел и описанные в статье альтернативы его прекрасно заменяют. Отмечу, кстати, что скалирование эластика — весьма себе непростая задача, даже для вполне прокачанных девопсов.
С ВПНом можно было бы поступить гораздо проще (отказаться от WireGuard), имей мы доступ к симкам для которых были бы доступны готовые профили OpenVPN aka 1nce — но на тот момент у нас их просто не было.
В чем действительно была проблема данного проекта — так в изначальной идее децентрализованного проката, но вы ведь об этом даже не подумали. А тут и кроется основной недостаток любой подобной платформы — что бы ни было внутри, эфир, DIDы итд — все это должно одновременно быть анонимным и децентрализованным (как условные криптовалюты), но при этом отвечать нормам и правилам того или иного государства.
Как сделать децентрализованный анонимный прокат, который можно будет при этом проводить по немецким законам? Как не следить за пользователями, за которым по закону нельзя следить, но при этом не потерять возможности контроля над скутерами?
Опять вы со своим эластиком и масштабированием. Мы не занимались масштабированием и нам не нужен был эластик, просто потому что он значительно сложнее, тяжелее и медленнее TICK.
Комментировать возможности обновления скутеров в виде крон джобы я даже не буду. И да, мы обновляли и систему в том числе.
Но вы бы, конечно, сделали все то же самое с эластиком на питоне и за неделю. Что же, успехов вам. Только не забывайте вовремя сообщать о подобных своих достижениях в твиттере.
Сказал бы, что с вами не согласен, но вижу что вы даже не прочитали статью:
Мы не делали кластер с HA, потому что для пилота и нашего небольшого количества скутеров нам вполне хватило одного инстанса InfluxDB, именно об этом и написано в разделе про Influx.
Обновления были совершенно необходимы, чтобы банально не бегать каждый раз по всему городу за скутерами, дабы установить на них последнюю версию софта/агента/драйверов которые, даже за время пилота, обновлялись многократно
Что значит "зачем промышленные решения"? TICK промышленный? Тогда почему вы предлагаете еще более монструозный эластик как решение? (и ведь про него тоже есть в статье)
Говоря об MVP — мне кажется, то что "делаем на перспективу" очевидным. В этом вся его суть — нет смысла делать пилот, если изначально нет надежд на развитие продукта.
И конечно, делать их нужно быстро и "чтобы работало". Но если качественная реализация, которую после MVP переделывать не придется, реализуется быстро — почему бы не сделать сразу?
Короткий ответ: отчасти и то и другое, но основное, как я и написал выше — отсутствие альтернатив.
Длинный ответ:
Проблемы, с которым мы столкнулись, также описаны в первом посте о проекте, ссылка на который есть в статье.
Основная идея была в децентрализации, и несмотря на то, что далеко не все компоненты системы сразу удалось сделать децентрализованными, мы к этому стремились, по крайней мере в части ядра платформы.
Самую ключевую роль в ней играли смарт контракты, DID, Verifiable Credentials и, собственно, сам Ethereum.
Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов.
Для всей этой логики, помимо нашего собственного функционала, необходимо было иметь массу "обвязки", вроде децентрализованной аутентификации, подписи транзакций Ethereum и валидации сигнатур Verifiable Credential'ов, которые были выписаны тем или иным DID (которые тоже нужно было верифицировать). Для всего этого также необходимо много криптографии. Мы выбрали партнера — компанию Jolocom, с которым успешно работали ранее, и у которых есть готовая библиотека для большинства вышеописанного. К сожалению, им не удалось в срок завершить имплементацию подобной библиотеки на каком-либо низкоуровневом языке, а подобных решений "на рынке" на тот момент не существовало вовсе.
Писать подобную библиотеку самим (например на Go) означало бы в несколько раз увеличить сроки разработки пилота, что было попросту невозможно (банально скутеры востребованы только пока на улице еще не слишком холодно, запуск и так был сдвинут с лета на осень, но зимой мы запускаться не могли).
В итоге, мы были вынуждены использовать то что есть — Node.js
Я надеюсь, что после этого пояснения, вопросов о том почему мы его все-таки использовали больше не возникнет. Это была критически важная для сути пилота функциональность, и у нас не было альтернативных вариантов.
Медленный — не заметил. Возможно, у нас образы были не особо большие, но прошивались они достаточно быстро. Про тяжеловесность — 100-метровый экзешник, это конечно, не супер, но учитывая что скачан он был когда-то один раз на старте проекта, про это и вовсе никто не вспоминал.
В общем, Etcher мне кажется максимально «тупым» и удобным инструментом для своей задачи, поиск альтернатив нам не требовался, так как он всем устраивал.
Что за «готовый модуль» и где об этом была речь? Про то, что проект пилотный написано в первой строке поста.
Прочитав который вы бы поняли, что у нас не возникало каких-либо проблем с MicroSD, и стореджем вообще. Причем тут emmc и какую проблему он бы для нас решил, не ясно.
Концепция MVP предполагает, что сначала вам нужно проверить саму идею продукта, обкатать ее, и даже, возможно, полностью от не отказаться. Такие проекты никогда не делаются в Enterprise режиме с планированием на годы вперед. Нужно сделать что-то быстро, оценить результаты, и позже уже делать на их основе полноценное решение.
Я все еще считаю, что Raspberry для подобного прототипирования — почти идеальная платформа — в случае чего нужную плату можно купить в любом электронном ларьке Берлина вроде Conrad. Она позволяет сэкономить массу времени именно на этапе начальной разработки. Конечно, никто не предполагает использовать Raspberry для реального продакшен решения, которое будет на дорогах всей страны. Но пока, к сожалению, об этом и речь не идет.
В целом вы правы, хотя я бы не был так категоричен, с учетом сроков. Методичка существовала и для саппорт команды, и даже для потенциальных пользователей.
Вообще, для этого не нужна была какая-то поддержка в системе мониторинга, у нас просто был Slack канал, где саппорт мог отписаться в случае необходимости ремонта скутера. Коллега, забравший скутер, не смог этого сделать из-за разрядки мобильного (и забрал скутер не подумав о последствиях). Мне кажется, предусмотреть этот сценарий было непросто. Для нас был однократным — больше не повторялось.
Мы проверяли это только один раз, когда включали Slack оповещения. Оно пришло, когда мы выключили Raspberry. С тех пор работало и больше мы туда не лезли. Я понимаю, что у капаситора есть некие недостатки, но мы с ними не сталкивались.
Спасибо, почитаю — но у нас не было необходимости в поиске альтернатив, так как мы, видимо, использовали его для относительно простых вещей. Фактически, мы его и не конфигурировали почти никак. Slack оповещения легко настроили и забыли, так что заменять его не планировали.
Да никто и не спорит, что микроконтроллер справился бы лучше. Но он не осуществлял бы и половины логики которую необходимо было реализовать, а разработка полноценного контроллера под наши задачи отняла бы массу времени, у нас его просто не было.
Помимо прочего, там было довольно много криптографии и работы с ETH сетью. Вся идея решения была в подготовке базы для того, чтобы использовать ее в будущем полностью децентрализовано. К сожалению не для всего есть децентрализованные решения, но мы старались использовать их по минимуму.
Кажется, я недостаточно хорошо раскрыл это в статье — но Node.js использовали не мы, а наши партнеры. Использовался он для функционала по децентрализованной аутентификации на основе DID en.wikipedia.org/wiki/Decentralized_identifiers в качестве библиотеки.
Мы не могли отказаться от ее использования или переписать самостоятельно, а альтернатив ей на тот момент не существовало.
Не совсем понимаю ваш поинт. Для ардуины, в нашем случае, пришлось бы писать довольно много обвязок и кода. Я не углублялся в детали, но вообще наш Go «агент» на Raspberry делал очень много всего, а как на ардуине могла работать библиотека на Node.js мне вообще не ясно.
Обновления мы доставляли именно deb пакетами, просто вместо APT использовали Ansible, что было удобно. А в качестве репозитория мы использовали уже развернутый ранее Nexus. На мой взгляд, в данном контексте выбор тулы для доставки пакетов мало что меняет.
Был опыт работы с Zabbix в более стандартных сценариях, но это было относительно давно (может быть и неправильно было принимать решение на основе давней информации, но времени тестировать свежие версии не было).
В целом, никаких особых проблем с ним не возникало, разве что его настройка и интерфейс далеко не всегда просты для понимания. Да и изначально рассматривались более современные решения, а в частности про Агент 2 даже и не знал. Посмотрю что там свежего появилось, спасибо.
Про миксины больше спорить смысла нет — это скорее персональные предпочтения.
Однако, лично мне, плагины и штуки вида this.$v, this.$t итд — нравятся. Даже очень.
Более того, в случае с TS это отлично поддерживается, и использование плагина без тайпингов сразу приведет к ошибке.
Касательно качества тайпингов — да, такая проблема сущетсвует, но на нее влиять проще всего, конкретно для Vuelidate они еще не финализированы и мы используем кастомизированную версию.
А уж добавить доки в тайпинги Vuex — дело одного очень простого и короткого PR'а.
Это опенсорс, и на некоторые вещи можно влиять самостоятельно.
У нас много проектов на Vue. Самый длительный — около года, благодаря тому, что строгое код ревью, линтер и TS были с первого дня — проблем никаких. Уверен что в части миксинов их и не возникнет, т.к. создаются они только для тех случаев когда действительно нужны.
Впрочем, я допускаю, что еще через год какие-то неявные вещи могут всплыть, но пока предпосылок к этому нет. Появятся — обязательно напишу новый пост, как есть.
Касательно миксинов не соглашусь — да их нужно грамотно использовать, но в реальности мне этот подход гораздо больше нравится, нежели в Angular (никак). С точки зрения поддержки — мы для себя пока проблем не видим, но если это столь необходимо — class component позволяет делать миксин классом от которого компонент наследуется = рефакторинг и все остальное будет работать.
По поводу магии хотелось бы увидеть конкретный пример. Не сталкивался. Навигация работает в вебшторме отлично с TypeScript.
Со статическими методами классов работать гораздо приятнее с точки зрения TypeScript.
По основным претензиям вижу что TS вам не очень близок и пытаться вас к его использованию склонять не собираюсь, но Ctrl+Q ним особо не нужен, а качество тайпингов зависит от библиотек и тех кто эти тайпинги поддерживает — то есть не все ваши аргументы валидны.
Мы рассматривали только наиболее популярные фреймворки — т.к. размер комьюнити очень сильно влияет на качество экосистемы. Больше народу — большу пулл реквестов.
Само собой, мы собирали только те данные, которые могли собирать по закону — потому телефоны мы никак и не мониторили.
Надо отметить — на самих устройствах мы не имели права собирать какие-либо данные, которые могли бы быть связаны с пользователем. Это касается персонификации, местоположения, итд.
Все операции были эфир транзакциями и по определению были публичны, другое дело, что шифровать их нужды не было, так как там не было данных, которые могли нарушать закон. Мы довольно долго проводили аудит этой темы и GDPR с legal отделом, так что в этом проблем не было.
Логи с устройств мы тоже не собирали, по тем же причинам — для нас телефоны были только устройствами которые могли запрашивать у скутера информацию напрямую и отправлять в эфир сеть какие-то транзакции.
Наоборот. Благодаря тому, что данные были действительно анонимизированы, мы смогли собирать со скутеров всю информацию в рамках закона. В эфире пользователи не имели никакой персонализации кроме совершенно случайных публичных ключей.
Ничего вы не ожидали, если хотите конструктив — то будьте добры и сами писать по делу.
На самом деле, то что проект оверинженирен само по себе чистая правда, только вот кроется это вовсе не в масштабировании или доставке обновлений.
Без регулярных удаленных обновлений софта было бы крайне некомфортно проходить даже пилотную фазу. Конкретно пакеты именно через apt и доставлялись, только делалось это не по крону, а по событию от анзибла. Ничего сверх-сложного тут нет, оно работает и стабильно.
А про мониторинг — я пытался описать максимально подробно свой опыт использования стека — авось кому понадобится, а может быть кто-то захочет и скалировать его для своих задач (и не сможет этого сделать). Специально обрисовал видимые нами недостатки, альтернативы, чтобы кто-то мог спроецировать свои требования в будущем.
Тот же эластик, как мне кажется, уже морально устарел и описанные в статье альтернативы его прекрасно заменяют. Отмечу, кстати, что скалирование эластика — весьма себе непростая задача, даже для вполне прокачанных девопсов.
С ВПНом можно было бы поступить гораздо проще (отказаться от WireGuard), имей мы доступ к симкам для которых были бы доступны готовые профили OpenVPN aka 1nce — но на тот момент у нас их просто не было.
В чем действительно была проблема данного проекта — так в изначальной идее децентрализованного проката, но вы ведь об этом даже не подумали. А тут и кроется основной недостаток любой подобной платформы — что бы ни было внутри, эфир, DIDы итд — все это должно одновременно быть анонимным и децентрализованным (как условные криптовалюты), но при этом отвечать нормам и правилам того или иного государства.
Как сделать децентрализованный анонимный прокат, который можно будет при этом проводить по немецким законам? Как не следить за пользователями, за которым по закону нельзя следить, но при этом не потерять возможности контроля над скутерами?
Такие вопросы я вижу конструктивными.
Опять вы со своим эластиком и масштабированием. Мы не занимались масштабированием и нам не нужен был эластик, просто потому что он значительно сложнее, тяжелее и медленнее TICK.
Комментировать возможности обновления скутеров в виде крон джобы я даже не буду. И да, мы обновляли и систему в том числе.
Но вы бы, конечно, сделали все то же самое с эластиком на питоне и за неделю. Что же, успехов вам. Только не забывайте вовремя сообщать о подобных своих достижениях в твиттере.
Сказал бы, что с вами не согласен, но вижу что вы даже не прочитали статью:
Говоря об MVP — мне кажется, то что "делаем на перспективу" очевидным. В этом вся его суть — нет смысла делать пилот, если изначально нет надежд на развитие продукта.
И конечно, делать их нужно быстро и "чтобы работало". Но если качественная реализация, которую после MVP переделывать не придется, реализуется быстро — почему бы не сделать сразу?
Короткий ответ: отчасти и то и другое, но основное, как я и написал выше — отсутствие альтернатив.
Длинный ответ:
Проблемы, с которым мы столкнулись, также описаны в первом посте о проекте, ссылка на который есть в статье.
Основная идея была в децентрализации, и несмотря на то, что далеко не все компоненты системы сразу удалось сделать децентрализованными, мы к этому стремились, по крайней мере в части ядра платформы.
Самую ключевую роль в ней играли смарт контракты, DID, Verifiable Credentials и, собственно, сам Ethereum.
Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов.
Для всей этой логики, помимо нашего собственного функционала, необходимо было иметь массу "обвязки", вроде децентрализованной аутентификации, подписи транзакций Ethereum и валидации сигнатур Verifiable Credential'ов, которые были выписаны тем или иным DID (которые тоже нужно было верифицировать). Для всего этого также необходимо много криптографии. Мы выбрали партнера — компанию Jolocom, с которым успешно работали ранее, и у которых есть готовая библиотека для большинства вышеописанного. К сожалению, им не удалось в срок завершить имплементацию подобной библиотеки на каком-либо низкоуровневом языке, а подобных решений "на рынке" на тот момент не существовало вовсе.
Писать подобную библиотеку самим (например на Go) означало бы в несколько раз увеличить сроки разработки пилота, что было попросту невозможно (банально скутеры востребованы только пока на улице еще не слишком холодно, запуск и так был сдвинут с лета на осень, но зимой мы запускаться не могли).
В итоге, мы были вынуждены использовать то что есть — Node.js
Я надеюсь, что после этого пояснения, вопросов о том почему мы его все-таки использовали больше не возникнет. Это была критически важная для сути пилота функциональность, и у нас не было альтернативных вариантов.
В общем, Etcher мне кажется максимально «тупым» и удобным инструментом для своей задачи, поиск альтернатив нам не требовался, так как он всем устраивал.
Прочитав который вы бы поняли, что у нас не возникало каких-либо проблем с MicroSD, и стореджем вообще. Причем тут emmc и какую проблему он бы для нас решил, не ясно.
Концепция MVP предполагает, что сначала вам нужно проверить саму идею продукта, обкатать ее, и даже, возможно, полностью от не отказаться. Такие проекты никогда не делаются в Enterprise режиме с планированием на годы вперед. Нужно сделать что-то быстро, оценить результаты, и позже уже делать на их основе полноценное решение.
Я все еще считаю, что Raspberry для подобного прототипирования — почти идеальная платформа — в случае чего нужную плату можно купить в любом электронном ларьке Берлина вроде Conrad. Она позволяет сэкономить массу времени именно на этапе начальной разработки. Конечно, никто не предполагает использовать Raspberry для реального продакшен решения, которое будет на дорогах всей страны. Но пока, к сожалению, об этом и речь не идет.
Вообще, для этого не нужна была какая-то поддержка в системе мониторинга, у нас просто был Slack канал, где саппорт мог отписаться в случае необходимости ремонта скутера. Коллега, забравший скутер, не смог этого сделать из-за разрядки мобильного (и забрал скутер не подумав о последствиях). Мне кажется, предусмотреть этот сценарий было непросто. Для нас был однократным — больше не повторялось.
Помимо прочего, там было довольно много криптографии и работы с ETH сетью. Вся идея решения была в подготовке базы для того, чтобы использовать ее в будущем полностью децентрализовано. К сожалению не для всего есть децентрализованные решения, но мы старались использовать их по минимуму.
Мы не могли отказаться от ее использования или переписать самостоятельно, а альтернатив ей на тот момент не существовало.
Обновления мы доставляли именно deb пакетами, просто вместо APT использовали Ansible, что было удобно. А в качестве репозитория мы использовали уже развернутый ранее Nexus. На мой взгляд, в данном контексте выбор тулы для доставки пакетов мало что меняет.
В целом, никаких особых проблем с ним не возникало, разве что его настройка и интерфейс далеко не всегда просты для понимания. Да и изначально рассматривались более современные решения, а в частности про Агент 2 даже и не знал. Посмотрю что там свежего появилось, спасибо.
Про миксины больше спорить смысла нет — это скорее персональные предпочтения.
Однако, лично мне, плагины и штуки вида this.$v, this.$t итд — нравятся. Даже очень.
Более того, в случае с TS это отлично поддерживается, и использование плагина без тайпингов сразу приведет к ошибке.
Касательно качества тайпингов — да, такая проблема сущетсвует, но на нее влиять проще всего, конкретно для Vuelidate они еще не финализированы и мы используем кастомизированную версию.
А уж добавить доки в тайпинги Vuex — дело одного очень простого и короткого PR'а.
Это опенсорс, и на некоторые вещи можно влиять самостоятельно.
Впрочем, я допускаю, что еще через год какие-то неявные вещи могут всплыть, но пока предпосылок к этому нет. Появятся — обязательно напишу новый пост, как есть.
Касательно миксинов не соглашусь — да их нужно грамотно использовать, но в реальности мне этот подход гораздо больше нравится, нежели в Angular (никак). С точки зрения поддержки — мы для себя пока проблем не видим, но если это столь необходимо — class component позволяет делать миксин классом от которого компонент наследуется = рефакторинг и все остальное будет работать.
По поводу магии хотелось бы увидеть конкретный пример. Не сталкивался. Навигация работает в вебшторме отлично с TypeScript.
Со статическими методами классов работать гораздо приятнее с точки зрения TypeScript.
По основным претензиям вижу что TS вам не очень близок и пытаться вас к его использованию склонять не собираюсь, но Ctrl+Q ним особо не нужен, а качество тайпингов зависит от библиотек и тех кто эти тайпинги поддерживает — то есть не все ваши аргументы валидны.