Ни для кого не секрет, что на вторичном автомобильном рынке продавцы нередко скрывают большую часть правды о продаваемом автомобиле, а объявления похожи одно на другое: «автомобиль не бит, не крашен».
Adaperio.ru — сервис проверки истории автомобилей с пробегом. По запросу пользователя выдает данные годе выпуска автомобиля, его пробеге, фактах ДТП из судебных решений, таможенном оформлении и отчет из системы CarFax. Проверяет на использование в качестве такси, угон, наличие регистрационных ограничений, нахождение в залоге у банка, участие в аукционах США. Концепция проекта — создать удобный инструмент для первичной фильтрации объявлений о продаже авто с пробегом.
# Мирная советская лопата
У микрофона “Chimp Technology Officer” компании Adaperio Антон Акентьев:
Говорят, что троллинг и любовь к холиварам — это психическое заболевание. Обычно проявляется в том, что человек любит мучать оппонента, насмехаться над ним, подводить его к логическому провалу. Я в это не верю. Поэтому сегодня я расскажу о том, как устроен наш небольшой, на 99,9% хипстерский сервис.
Основной задачей любого инженера является нахождение наилучшего для конкретной ситуации trade-off’а. Допустим, стоит перед вами задача “сделать лопату”. Если вы выберете в качестве материала дерево, то лопата получится очень дешевой, сложность разработки будет достаточно низкой, прочность никудышной, а конечная стоимость всего $10. Если же перед вами стоит задача лететь с лопатой в космос, а в контракте у вас четко прописано, что “аптайм лопаты должен быть равен 99,999%, а ее вес — минимально возможным”, — то ничего не останется, кроме выбора супер-навороченного станка с ЧПУ для обработки титановых заготовок. В результате — стоимость разработки вырастает в десятки раз, весить лопата будет всего 48 грамм, а конечная ее стоимость будет равняться неслабым $1000.
Анекдот:
```
Умирает известный программист, местная звезда. Собралась вся деревня. Спрашивают его: расскажи нам самое главное. Программист отвечает:
— Всё фигня, кроме trade-off’ов….Все вокруг шепчутся — смотри, дело говорит! А программист полежал-полежал, а затем говорит:
— Да и trade-off’ы — тоже фигня…
```
Одним из примеров удачного trade-off’а можно привести автомобили ВАЗ. Они являются самым популярным продуктом в этой нише у нас в стране. Да, их лидерство объясняется далеко не технологиями, а (к сожалению) другими причинами. Но факт есть факт. При выборе технологии нужно постараться представить многомерный гиперкуб у себя в голове с осями вроде “вес” (ось x), “конечная стоимость” (ось y), “надежность” (ось z), “сложность разработки” (куб меняется во времени), “быстродействие” (цвет куба), “доступность разработчиков” (запах куба) и так далее. Как только вы это сможете представить — тут уж будет очень легко найти оптимальное сечение. Ну вы поняли.
*Интересно, почему нет ни одного веб сервера, который бы работал напрямую в ядре в real-time’е? Я думаю подсказать Сысоеву такую идею для nginx 3.0. Никаких прерываний — жесткий real-time. СУПЕР-МЕГА-БЫСТРОДЕЙСТВИЕ!!! Oh, wait. Кажется, такое уже есть!*
# Какой trade-off выбрал ты?
Для текущего проекта я выбрал MEAN-стек: MongoDB, Express, Angular.JS, Node.JS.
Все узлы — обычные виртуальные машины в Amazon EC2.
1) Для развертывания используются AMI образы, никаких Docker или Vagrant.
trade-off: Меньше гибкости, больше скорость вывода первого релиза.
2) Deploy обновлений проходит в ручном режиме — на frontend я заливаю все через rsync (конечно же через сборочную систему, не руками). Для деплоя backend’а используется git, но тоже без всяких хуков и автоматических pull’ов. При этом для deploy не используется никакая отдельная ветка, все происходит строго в master’е.
trade-off: Меньше гибкости и больше вероятность ошибок, зато больше скорость вывода первого релиза.
3) Фронтенд — Apache для раздачи статики. Выбрал его вместо Nginx, так как я лучше знаком с его конфигурированием. Из плюсов Nginx я бы отметил лучшую безопасность по сравнению с Apache. Node.JS для раздачи статики брать не хотелось. Но вскоре мы переключимся на kHTTPd (шутка).
4) Backend — это RESTful сервис, который работает с запросами следующего вида:
HTTP GET api.adaperio.ru/v1/data_for_cars/%D0%BD002%D1%82%D1%81190
URL состоит только из существительных, никаких глаголов вроде “get_data_for_car” не используем; CRUD операции доступны, конечно же, не для всех существительных.
С точки зрения frontend’а можно воспринимать backend всего лишь как обычную БД, которая умеет отвечать на HTTP запросы. В идеальном случае это так и есть. Но не стоит забывать и про обширную бизнес-логику.
5) Между backend<->frontend ходят JSON объекты.
6) Для сборки используется Bower/Grunt.
Я просто пишу у себя в консоли grunt build, и происходит чудо!
Как видите — система примитивна и максимально проста. Правильный подход в любом Lean-начинании — итеративный. Это тоже trade-off: мы СРАЗУ получаем четкие маленькие работоспособные кусочки, но зато тратим ПОТОМ время на их перекомпоновку или удаление старых. Когда нагрузка возрастёт — лишь только тогда я задумаюсь об автоматическом развертывании. И это один из плюсов таких проектов, в то время как другие себе такую гибкость позволить не могут.
# Что это даёт нашему стопдауну?
1) Основным стержнем системы является JSON:
frontend <-> JSON <-> backend <-> JSON <-> DB
2) Код можно перемещать между frontend<->backend как вздумается, ведь везде используется JavaScript (даже сборочная система написана на JavaScript’е).
3) Frontend занимается только отрисовкой JSON в HTML, это модель MVC в полной красе (Angular.JS, как мы знаем, является MVVM, но я не про это сейчас).
# Вся наша жизнь trade-off!
Очень холиварная тема SQL/NoSQL вроде как уже давно разобрана, написаны тысячи текстов, всем “всё понятно”. Но многие за CAP-теоремой и ACID’ом забывают про одну из особенностей той же MongoDB — удобство работы. Оно тесно связанно с понятием “schemaless”: я могу добавить любое поле автоматически, а разные документы (записи) могут иметь совершенно различные поля. “Таблицы” БД могут меняться буквально каждый день. Если бы я делал проект, используя стандартную RDBMS типа MySQL — такой гибкости я бы не получил.
Поэтому можно просуммировать — я выбрал MongoDB потому, что:
1. Внутреннее представление (JSON/BSON) максимально удобно использовать в моем конкретном проекте.
2. Schemaless подход дает больше гибкости (но в будущем может заставить писать много ручного it-the-else кода).
3. “Запросы” реализуются непосредственно в коде. Нужен цикл? Пишешь цикл. Не нужно учить никаких языков запросов вроде SELECT * FROM. В качестве минуса — то что “у них” делается простым JOIN — “здесь” ты будешь делать вручную сам.
На ранних этапах развития проекта меня гораздо меньше волнует “быстродействие”, “пропускная способность” и репликация, чем удобство использования.
# А это BigData?
«Определение BigData понять могут не только лишь все, мало кто может это сделать»(с).
Если кратко, BigData — не всегда от огромного количества данных (хотя название и вводит в заблуждение). А от способа их хранения и обработки. Несколько тысяч записей — вполне себе BigData, если хранить их неструктурированно. Допустим, Мегафон может хранить сырые данные всех своих звонков. Когда им потребуется — они смогут написать код (я специально не говорю “запрос”) по разбору этих данных -«покажи мне всех абонентов, которые живут в Москве, но бывают летом в Египте». Или смогут «посчитать среднее кол-во секунд молчания всех звонков из Москвы в Петербург». Именно это и есть подход BigData. Используя обычную БД, такой гибкости достичь было бы невозможно, ибо данные перед хранением там обрабатываются и минимизируются (нормализуются). В BigData, как правило, хранится всё, в том числе и «шум».
Ну так что? Так как я храню сырые HTML документы прямо в базе, а затем по запросу их разбираю — да, такой подход можно назвать BigData! В какой консорциум/профсоюз мне вступить?
# Кто нам помогает?
Если просуммировать все сервисы, которые мы используем:
1) Amazon EC2 для виртуалок.
2) Amazon S3 для хранения миллионов документов.
3) Amazon CloudFront для отдачи данных — cdn.adaperio.ru.
4) Amazon Route53 для наведения ядерных ракет.
5) Compose.io (бывший MongoHQ) для MongoDB.
6) NewRelic для мониторинга.
7) GetSentry для учета событий.
8) В качестве почты пока не используем никаких выделенных сервисов.
8) BrowserStack для тестирования рендеринга на разных машинах/ОС/броузерах.
# Резюме
Не бывает “плохих” или “хороших” технологий. Правильно говорить так — “эта технология не подходит для этой конкретной ситуации”, а не просто “PHP — это отстой”. Факапом можно назвать только неправильный выбор технологии. Допустим, если для своего огорода человек заказывает себе лопату из титана за $1000. Или летит в космос с NodeJS в качестве серверного ПО. В индустрии практически нет “плохих” продуктов. Всё то, что мы видим на рынке, занимает какую-то нишу и пользуется спросом. Неудачные продукты просто покидают рынок.
Пробуйте разные технологии, получайте от этого удовольствие. Желаю вашим проектам только удачи!
# О том, что такое Adaperio для простого пользователя. Рассказывает СЕО Алексей Данилов.
Мы начали развивать проект в конце апреля 2014 года, решили идти по пути lean-стартапа и как можно чаще итерационно дорабатывать продукт, поэтому первая версия сервиса была представлена пользователям в мае. Проект помогает пользователям собрать информацию из различных, как общедоступных, так и закрытых источников в онлайне и офлайне.
Adaperio не является «волшебной таблеткой», которая способна решить любую проблему, а собирает и показывает информацию о конкретном автомобиле. Как ее использовать — решает уже сам клиент.
У нас уже были кейсы, когда люди проверяли автомобили, а они оказывались в угоне или с регистрационными ограничениями. Пару раз попадались машины с «перебитыми» VIN-кодами. Очень часто попадаются автомобили с информацией о ремонтных действиях вплоть до тотальных машин, которые отремонтировали и потом продали, а новые владельцы даже не знали об этом, и сами уже продавали их, как почти новые.
Вся эта информация, которую мы находим — это повод для размышлений для конкретного покупателя, инструмент оценки риска, который сопровождает покупку конкретного подержанного автомобиля. Причем степень риска не зависит от того, где вы покупаете этот автомобиль — с рук по объявлению, у перекупщика или в автосалоне. Перекупщику может достаться автомобиль в отличном состоянии, потому что продавцу нужны были срочно деньги, а в автосалоне может стоять «конструктор», который сдали в трэйд-ин. Именно поэтому покупатель должен понимать, что верить продавцу на слово нельзя, так как он больше всех заинтересован в сделке, а любую информацию желательно перепроверять.
Пользователи нас часто спрашивают об источниках информации, мы их никогда не скрывали и постоянно расширяем их количество. На данный момент структура данных складывается из следующих блоков:
Пробег — от сервисных станций и страховщиков;
Угон, ограничение действий — из базы данных ГИБДД;
Банковские залоги — от банков партнеров и общероссийского реестра залогов;
Таможенное оформление — таможня РФ;
Использование в качестве такси — реестры лицензий на таксомоторную деятельность, выданных органами исполнительной власти регионов РФ;
Carfax- CarFax;
Американские аукционы — собственное решение по мониторингу аукционов США;
ДТП — база решений арбитражных судов РФ по спорам между страховщиками;
Ремонты — информация от оценочных компаний;
Комплектация — различные специализированные сервисы.
Динамика развития проекта положительная и это радует. В начале июня состоялась первая продажа, с тех пор мы стабильно растем по все основным показателям. В декабре рассчитываем выйти на окупаемость (на самом деле уже вышли) – тратим мы немного, бюджеты же сжигаем)).
На данный момент в Adaperio из 1000 введенных госномеров в среднем находится информация о 640, еще около 100 находится по VIN-коду. Всего в России порядка 40 миллионов легковых автомобилей, поэтому такой показатель мы считаем неплохим. Плюс всегда сообщаем пользователю перечень информации, который он получит после оплаты, чтобы люди заранее понимали, нужна им такая информация или нет, и принимали осознанное решение о покупке отчета.
С конца ноября мы начали тестировать еще один продукт — собирать заявки и связывать клиентов с экспертами, способными провести качественную диагностику автомобиля с осмотром по всем важным параметрам.
Это услугу решили запустить, так как понимаем, что выбрать хорошую машину — это как найти крупинку золота в куче песка: надо сначала провести отбор из множества объявлений, а потом понравившиеся варианты осмотреть вживую, причем не самому, так как знаний обычного потребителя реально недостаточно, а с помощью опытного мастера, который знает куда и под каким углом смотреть. Это перспективное направление с рынком, имеющим примерно такой же объем, что и рынок онлайн проверок, а услуга очень востребована у людей, которые либо не разбираются в автомобилях, либо не имеют времени на осмотр всех вариантов.
В планах развития — реклама, так как о нас еще знают очень мало, плюс дальнейшая работа по увеличению информативности отчетов.
В идеале мы хотим создать сервис, способный комплексно решить проблему подбора и приобретения автомобиля с пробегом. Цель очень амбициозная, путь к ее достижению будет явно не из легких, но мы уже очень глубоко погрузились во всю эту кухню, поэтому сворачивать не намерены!
Отметим, что любой пользователь может стать соинвестором Adaperio (минимальный размер инвестиций — $30). В настоящее время стартап проводит краудфандинговую кампанию на платформе коллективных инвестиций: 
Автор: grrik13
