За несколько лет Whoosh в несколько раз вырос по числу самокатов, пользователей и локаций, а данных по ним накопилось на 30 терабайт. Прежней архитектуры уже не хватало для работы. К тому же платить за I/O (input/output)-операции на Aurora (PostgreSQL) выходило дорого (тогда еще не было I/O‑optimized версии, однако с ее появлением, актуальность не исчезла). Другое дело — Redshift: расходы постоянны (n$/час), а работает он быстрее, благодаря колоночному формату хранения данных. В этом году мы переехали с одного хранилища на базе PostgreSQL — того, где вся отчётность для бизнеса и модели dbt — на рельсы Data Lake в AWS.

Меня зовут Никита Зеленский, я главный по данным в Whoosh. Эту статью я написал вместе с другими участниками переезда — Пашей Сивохиным, ГИС-аналитиком, и Костей Малыхиным, руководителем группы анализа данных. Надеюсь, наш опыт будет полезен всем, кому предстоит миграция данных, особенно если вы работаете с геоаналитикой.

Всем привет! В первой части статьи мы рассказали о том, как на наших IoT модулях реализована схема управления пьезоэлектрическим излучателем (баззером) с регулировкой частоты и амплитуды; как эта схема управляется микроконтроллером программно, воспроизводя простые звуки и мелодии. Такая реализация показала себя надежной в эксплуатации, нетребовательной к ресурсам и на начальном этапе решала задачу базовой озвучки самоката. Шло время, появлялись новые сценарии взаимодействия с пользователями и нам самим хотелось чего-то большего — например, хорошо было бы сделать звучание самоката более “фирменным”, узнаваемым и приятным на слух. Так мы и задумались о “звуковом рефакторинге” — об этом и расскажем вам в этой статье.

Многим сервисам критически важно иметь информацию о местонахождении подключенных устройств. Кикшеринг — не исключение. Нам в Whoosh нужно отслеживать каждый отдельно взятый самокат в каждый отдельно взятый момент времени. Поэтому все наши самокаты оснащены навигационным приемником, или как его еще называют, GNSS модулем. Однако, технология спутниковой навигации, несмотря на свою чрезвычайную популярность обладает и рядом недостатков. Например, навигационный приемник относительно легко сбить с толку, то есть заглушить или исказить принимаемый им сигнал. В результате, получаемое пользователем местоположение не будет иметь ничего общего с действительностью. И бороться с этим достаточно сложно. Поэтому на помощь спутниковой навигации приходят другие, альтернативные способы определения местоположения, такие как инерциальные навигационные системы (ИНС), определение местоположения по базовым станциям и WiFi точкам и т.д.

И сегодня мы поговорим об ИНС, а точнее об одном из необходимых элементов подобных систем — магнитометре, а еще точнее о том, как его калибровать.

В Софт, хард и два колеса: как мы строили IT-инфраструктуру в Whoosh упоминалось, что первые версии IoT мы ставили под непрозрачную крышку, замещая стандартный модуль управления от самоката Xiaomi M365. То есть, после установки и проклеивания крышки, связь с модулем была только через облако. В идеальном мире этого было бы достаточно, но реальность диктовала условия, в которых нужна была индикация процессов — как в режиме обслуживания, так и в городе, у пользователей. Прием управляющих команд, отправка телеметрии, подключение к сети и выход устройств в онлайн — разные этапы нужно было различать сервисной команде для быстрой диагностики, а пользователя — предупреждать об изменениях в базовых сценариях использования — командах, ошибках, ограничениях и т.д.

Нужны звуки — решили ставить buzzer (или зуммер). Это такая электромеханическая штуковина, которая под воздействием внешнего переменного напряжения умеет деформироваться и издавать звуки.

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

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

Привет, я, Петер Ибрагимов, и в Whoosh я занимаюсь бекенд разработкой на Python. В этой статье расскажу, как мы делаем наши микросервисы на лямбдах. 

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

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

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

Меня зовут Никита Зеленский, я руковожу отделом по работе с данными в Whoosh, разработчике технологических решений и операторе микромобильности. Эту статью мы написали вместе с Иваном Маричевым, дата‑сайнтистом Whoosh. Он же и автор алгоритма, о котором пойдет речь.

Здесь мы расскажем, как мы реализовывали модель прогнозирования спроса на самокаты, с чем сталкивались при прототипировании, какие модели были протестированы, чем наш случай отличается от прогнозирования спроса в каршеринге, спроса для пополнения запасов в дарксторе и т. п. (Самокат, самокаты Whoosh передают привет!)

История получилась про наши подходы и грабли, которые мы в итоге собрали. Чуть‑чуть про технику, чуть‑чуть про бизнес — нескучно и с ветерком (как на самокате).

Whoosh!

Всем привет, на связи Фарук, инженер-разработчик электроники и встроенного ПО в Whoosh (читается как ВУШ, ощущается как вжууух). Работаю я в embedded отделе (хардкорные программисты, что пишут прошивку на C для различных железок и проектируют эти самые железки), но в основном занимаюсь анализом различных данных от нашего IoT модуля и разработкой алгоритмов для работы с этими данными.

Наша компания — сервис аренды электросамокатов (а местами еще и электровелосипедов) или, иными словами, кикшеринг. О том, как мы к этому пришли и что из себя представляем можно почитать здесь.

Одно из отличий использования шерингового самоката от личного — наличие определенных правил. Например, вы видели когда-нибудь парочку влюбленных, вдвоем на самокате, исчезающих в закате? Или может наблюдали троих парней, которые в обнимку, преодолев смущенье, едут навстречу новым приключеньям? А может быть вы видели как чей-то отец, словно швец, жнец и на самокате ездец, с одним ребенком подмышкой а с другим на шее смело едет по парковой аллее?
Вызывают ли у вас эти картины гнев и праведное негодование? А может быть вы и сами не прочь прокатиться с другом/подругой на одном самокате? У нас для вас есть две новости.

Во-первых, так нельзя. А во-вторых, добро пожаловать под кат.

Привет, Хабр!

На связи команда Whoosh — лидера в разработке и интеграции технологий микромобильности в стране. Если вы живете в России или СНГ (мы уже присутствуем в некоторых городах Казахстана и Беларуси), то наверняка видели наши электросамокаты или пользовались ими. Вероятность этого большая: за 9 месяцев 2022 года года уже совершено 46 млн поездок, парк вырос до 82 тысяч устройств и размещены они в 40+ городах трех стран.

За четыре года мы прошли путь от стартапа до зрелой IT-компании. То, какими мы были в начале и сейчас — два разных проекта. Поэтому, в первой статье мы решили поделиться воспоминаниями о том, как все начиналось несколько лет назад, к чему мы пришли и какие у нас планы на будущее.

Меня зовут Сергей Шилин, я руководитель отдела разработки электроники и встроенного ПО. Вместе с CIO и со-основателем Whoosh Егором Баяндиным мы вспомним, как все начиналось несколько лет назад, как все устроено сейчас с точки зрения IT и какие у нас планы на будущее.