Привет, Хабр! Первая запись в корпоративном блоге не претендует на некую энциклопедическую значимость, поэтому просим не судить строго, это всего лишь знакомство с компанией и разрабатываемым продуктом.
И эта история о том, как мы разрабатывали систему автоматизации для ресторанов.
![](https://habrastorage.org/r/w780q1/files/a47/6cb/552/a476cb5529c749648904894d5c5e1748.jpg)
Наша небольшая компания-разработчик, все выходцы из большой компании-разработчика ПО для банков и процессинговых центров, получает заказ на мобильное приложение для службы доставки. Одним из пунктов ТЗ была интеграция этого приложения с системой автоматизации, которую использовало заведение-заказчик. Выполняя работу, мы всерьёз заинтересовались сначала системой, с которой пришлось взаимодействовать, потом автоматизацией подобного бизнеса вообще. Возмущения на темы «Почему они все делают так? Это же неудобно!», «Они все используют сенсорные моноблоки, почему не планшеты?», «Кто учил их проектировать интерфейсы» не стихали часами. А потом кто-то сказал «А давайте сделаем своё, с блэкджеком планшетами и красивое (удобное), мы же можем». Шёл чудесный 2013й год, март месяц…
Итак, мы определились с концепцией, ключевой особенностью новой системы должны стать лёгкость развёртывания, управления, возможность начать работу с минимальными вложениями сил и средств и продолжать получать отдачу от данной системы по мере расширения бизнеса. Было бы просто замечательно, если бы владелец ресторанного бизнеса мог позволить себе автоматизацию «в несколько кликов». Но как этого добиться? Каковы должны быть архитектурные решения, обеспечивающие подобный уровень простоты развёртывания и эксплуатации?
Окей гугл, у нас есть айпэд, из которого вышел бы компактный и удобный терминал. Нарисовали первый прототип интерфейса, собрали приложение:
![](https://habrastorage.org/r/w1560/files/37b/162/e4d/37b162e4df974028861051c197d6c8cc.png)
И понеслось…
Мы, несомненно, живём в великой стране. В стране, где госорганы используют технологии позавчерашнего дня, и с этим приходится считаться. Не будем сейчас углубляться в требования налоговой службы к малому бизнесу, но если кто вдруг не в курсе, технически это выглядит так: вы должны использовать девайс, который ведёт учёт всех ваших продаж и хранит их на своём носителе, который вы обязаны ежегодно сдавать в ФНС. И всё бы ничего, но девайс этот работает преимущественно по COM-порту, а инновации в виде ВТ-подключения увеличивают время ответа в разы. Так как заставить iPad работать с особым видом термопринтеров, который в России гордо называют Фискальными Регистраторами?
Мы опять вернулись к идее, что если бы в нашем распоряжении был обычный компьютер, можно было бы подключить периферийные устройства к нему. При необходимости мы могли бы даже разрабатывать драйверы для неподдерживаемых устройств и таким образом обеспечить их работоспособность. Но отдельного компьютера нет, а подключить что-либо к iPad через lightning-порт — практически невозможно, как минимум из-за сертификации Apple. Идеальным решением была бы некая «коробка», не требующая обслуживания и обеспечивающая нам интерфейс к периферийным устройствам. Конечно, можно было бы разработать собственное устройство на базе какого-нибудь микроконтроллера, но в нашей компании не было специалиста-электронщика, который взялся бы за эту задачу. К тому же разработка такого устройства собственными силами существенно увеличила бы сроки готовности всей системы. Мы отправились на поиски готового решения, на базе которого мы могли бы строить свою систему.
И такое решение было найдено в виде всеми любимого Raspberry Pi. «Малина» недорога, компактна, потребляет мало энергии, позволяет подключить устройства через USB-порты (которые малой кровью могут быть преобразованы в COM) Таким образом проблема подключения периферии на уровне «железа» отпадает. Также весомым преимуществом оказалось то, что «малина» работает под управлением Linux, то есть разрабатывать программную начинку под эту платформу значительно проще, чем, например, для микроконтроллеров. Процедура обновления программного обеспечения для Raspberry проста и понятна – вытащил SD-карту со старой версией, вставил носитель с новой версией. При необходимости, выполнить её может даже неспециалист, а значит, это более чем отвечает нашей исходной идее о системе, которая не требует специального обслуживания и отдельного специалиста, который будет отвечать за это.
Это ли не счастье для службы техподдержки? Технически, при необходимости к такому устройству можно получить доступ удалённо, например, через SSH, чтобы исправить какую-либо проблему. Что также требует от персонала ресторана действий на уровне «подключите устройство к сети, нажмите определенные кнопки и подождите, пока наши специалисты разберутся с проблемой».
Проанализировав всё это, мы добавили к нашей системе QRBox – такое название получил Raspberry Pi в виде конечного продукта. Он взаимодействует с остальными терминалами в пиринговой сети посредством CouchDB, получая и передавая информацию для и от периферийных устройств. Попробовали даже напечатать свой корпус, результат пока далек от совершенства:
![](https://habrastorage.org/r/w780q1/files/d50/d0b/e85/d50d0be850f54ce5a00fdc3237f9935a.jpg)
Например, чтобы напечатать чек, терминал помещает в CouchDB документ, описывающий чек. QRBox получает этот документ, формирует пакет данных для фискального регистратора, убеждается, что чек напечатан, делает соответствующую отметку в CouchDB для терминала.
Итог: есть решение, которое можно назвать прототипом. Терминал печатает чеки, и отправляет/получает данные по wi-fi на локальную машину. Переходим к back-office.
Безусловно, одним из самых затратных для развёртывания и сопровождения компонентов системы автоматизации является сервер, обеспечивающий управление всеми остальными устройствами. Сервер нужно приобрести, нужно установить на него ОС, необходимые сервисы, настроить сеть, обеспечить бесперебойное электропитание, охлаждение, резервное копирование; нужно следить, чтобы не закончилось место на жёстком диске, чтобы сами жёсткие диски были вовремя заменены при угрозе поломки или при собственно поломке – и ещё многое и многое другое. Это требует не только финансовых вложений, но и человеческих ресурсов. Нужен системный администратор, который возьмёт на себя эту работу, системному администратору нужно платить, он может заболеть в самый неподходящий момент, может уволиться, может…
А что, если обойтись без сервера? Конечно, полностью обойтись без него невозможно, но что если наличие собственного сервера в каждой ресторанной сети или даже в каждом ресторане станет необязательным? Что, если сервер будет расположен где-то далеко, в хорошо оборудованной серверной, под неусыпным присмотром квалифицированных специалистов? Что, если сервер будет, по последней моде, в «облаке», дорога в облака становится всё шире и доступней, почему нет?
Сначала эта идея показалась странной. Ведь всем понятно, что работа облачных сервисов полностью зависит от качества связи с ними. Пропадет интернет-соединение на любом из возможных участков от «облака» до конечного пользователя – и ресторан «встанет». Требовать от наших клиентов обеспечивать резервирование интернет-канала? Не всегда и не везде это возможно, а уж тем более возможно за относительно небольшие средства. А если обеспечение интернет-канала требует значительных вложений – теряется вся экономия от устранения локального сервера.
Но далее мысль получила развитие. Так ли необходима постоянная связь с сервером? Разве терминалы не могут иметь собственную память, в которой будут храниться данные о совершённых за последние несколько часов или даже сутки операциях, периодически выгружая данные на центральный сервер? И тут мы поняли, что находимся в шаге от решения – одноранговая пиринговая сеть между терминалами! Действительно, зачем нужен центральный сервер, если все необходимые данные есть на самих терминалах, которые могут обмениваться ими между собой?
По результатам анализа стало ясно, что решение возможно и вполне работоспособно. В качестве системы хранения данных была выбрана та же CouchDB, которая поддерживает репликацию между нодами в режиме мастер-мастер «из коробки». Реализации этой базы данных существуют под множество платформ, включая Linux, iOS, Android и даже Windows, что открыло для нас возможность портирования терминального приложения на любую из этих платформ. Итогом стало решение, позволяющее обойтись без выделенного сервера, а возложить все задачи на терминалы и облачный сервис.
![](https://habrastorage.org/r/w1560/files/be6/ab2/68a/be6ab268a02f4665b3f3b3348cef3c16.png)
Общую схему получившегося решения вы можете видеть на схеме. Основным хранилищем данных выступает база данных PostgreSQL, в которую данные попадают через серверное приложение. Необходимую для бесперебойной работы точек продаж часть данных серверное приложение выгружает в CouchDB, откуда они реплицируются в базы данных терминалов конкретных точек продаж. Если в работе механизма репликации произойдёт сбой, например, в результате нарушения связи, это не приведёт к фатальным последствиям – репликация будет восстановлена после устранения причин сбоя, то есть восстановления связи между базами данных. При этом терминалы в своей работе даже не замечают отсутствия связи с центральным сервером – локальная база функционирует и даже может пополняться новыми данными, поступающими с других терминалов, образующих пиринговую сеть.
Но, разумеется, администратору системы требуется собственное рабочее место, с помощью которого он мог бы манипулировать данными всей системы в целом. Просматривать статистические данные, менять глобальные настройки, регистрировать новые терминалы, менять цены и многое, многое другое. Такое рабочее место реализовано в виде веб-приложения, которое взаимодействует с главным серверным приложением через REST API.
При разработке веб-приложения использовались последние достижения индустрии в построении отзывчивых веб-приложений, в частности за основу были выбраны компоненты kendo UI и фреймворк AngularJS. Использование готовых компонентов сильно сократило время на разработку пользовательского интерфейса, позволив сосредоточиться на предоставлении понятных, удобных и универсальных способов управления данными. В результате администратор имеет возможность как получить детальные данные об отдельных объектах системы, так и наблюдать общую картину с помощью отчетов и предоставления агрегированных данных.
Продукт зарелизен, набирает обороты, и вроде даже нравится не только нам :)
![](https://habrastorage.org/r/w1560/files/151/12b/ff4/15112bff43914cf98a877f75fe5b2b25.png)
![](https://habrastorage.org/r/w1560/files/3a1/e74/609/3a1e746096f14aa696a8250bcf852262.png)
Понемногу наращиваем функционал и правим всплывающие баги. Наблюдаем за появлением конкурентов. Будни стартапа, словом. Но на сегодня, пожалуй, всё – более подробно про наш продукт и его разработку расскажем в следующих постах. А пока были рады знакомству и с удовольствием ответим на ваши вопросы в комментариях.
P.S. Для желающих посмотреть бэк-офис без регистрациии смс, есть заполненный демо-слой: test.quickresto.ru (логин: test пароль: test)
И эта история о том, как мы разрабатывали систему автоматизации для ресторанов.
![](https://habrastorage.org/files/a47/6cb/552/a476cb5529c749648904894d5c5e1748.jpg)
Как всё началось?
Наша небольшая компания-разработчик, все выходцы из большой компании-разработчика ПО для банков и процессинговых центров, получает заказ на мобильное приложение для службы доставки. Одним из пунктов ТЗ была интеграция этого приложения с системой автоматизации, которую использовало заведение-заказчик. Выполняя работу, мы всерьёз заинтересовались сначала системой, с которой пришлось взаимодействовать, потом автоматизацией подобного бизнеса вообще. Возмущения на темы «Почему они все делают так? Это же неудобно!», «Они все используют сенсорные моноблоки, почему не планшеты?», «Кто учил их проектировать интерфейсы» не стихали часами. А потом кто-то сказал «А давайте сделаем своё, с блэкджеком планшетами и красивое (удобное), мы же можем». Шёл чудесный 2013й год, март месяц…
Итак, мы определились с концепцией, ключевой особенностью новой системы должны стать лёгкость развёртывания, управления, возможность начать работу с минимальными вложениями сил и средств и продолжать получать отдачу от данной системы по мере расширения бизнеса. Было бы просто замечательно, если бы владелец ресторанного бизнеса мог позволить себе автоматизацию «в несколько кликов». Но как этого добиться? Каковы должны быть архитектурные решения, обеспечивающие подобный уровень простоты развёртывания и эксплуатации?
Окей гугл, у нас есть айпэд, из которого вышел бы компактный и удобный терминал. Нарисовали первый прототип интерфейса, собрали приложение:
![](https://habrastorage.org/files/37b/162/e4d/37b162e4df974028861051c197d6c8cc.png)
И понеслось…
Где у iPad COM-порт?
Мы, несомненно, живём в великой стране. В стране, где госорганы используют технологии позавчерашнего дня, и с этим приходится считаться. Не будем сейчас углубляться в требования налоговой службы к малому бизнесу, но если кто вдруг не в курсе, технически это выглядит так: вы должны использовать девайс, который ведёт учёт всех ваших продаж и хранит их на своём носителе, который вы обязаны ежегодно сдавать в ФНС. И всё бы ничего, но девайс этот работает преимущественно по COM-порту, а инновации в виде ВТ-подключения увеличивают время ответа в разы. Так как заставить iPad работать с особым видом термопринтеров, который в России гордо называют Фискальными Регистраторами?
Мы опять вернулись к идее, что если бы в нашем распоряжении был обычный компьютер, можно было бы подключить периферийные устройства к нему. При необходимости мы могли бы даже разрабатывать драйверы для неподдерживаемых устройств и таким образом обеспечить их работоспособность. Но отдельного компьютера нет, а подключить что-либо к iPad через lightning-порт — практически невозможно, как минимум из-за сертификации Apple. Идеальным решением была бы некая «коробка», не требующая обслуживания и обеспечивающая нам интерфейс к периферийным устройствам. Конечно, можно было бы разработать собственное устройство на базе какого-нибудь микроконтроллера, но в нашей компании не было специалиста-электронщика, который взялся бы за эту задачу. К тому же разработка такого устройства собственными силами существенно увеличила бы сроки готовности всей системы. Мы отправились на поиски готового решения, на базе которого мы могли бы строить свою систему.
И такое решение было найдено в виде всеми любимого Raspberry Pi. «Малина» недорога, компактна, потребляет мало энергии, позволяет подключить устройства через USB-порты (которые малой кровью могут быть преобразованы в COM) Таким образом проблема подключения периферии на уровне «железа» отпадает. Также весомым преимуществом оказалось то, что «малина» работает под управлением Linux, то есть разрабатывать программную начинку под эту платформу значительно проще, чем, например, для микроконтроллеров. Процедура обновления программного обеспечения для Raspberry проста и понятна – вытащил SD-карту со старой версией, вставил носитель с новой версией. При необходимости, выполнить её может даже неспециалист, а значит, это более чем отвечает нашей исходной идее о системе, которая не требует специального обслуживания и отдельного специалиста, который будет отвечать за это.
Это ли не счастье для службы техподдержки? Технически, при необходимости к такому устройству можно получить доступ удалённо, например, через SSH, чтобы исправить какую-либо проблему. Что также требует от персонала ресторана действий на уровне «подключите устройство к сети, нажмите определенные кнопки и подождите, пока наши специалисты разберутся с проблемой».
Проанализировав всё это, мы добавили к нашей системе QRBox – такое название получил Raspberry Pi в виде конечного продукта. Он взаимодействует с остальными терминалами в пиринговой сети посредством CouchDB, получая и передавая информацию для и от периферийных устройств. Попробовали даже напечатать свой корпус, результат пока далек от совершенства:
![](https://habrastorage.org/files/d50/d0b/e85/d50d0be850f54ce5a00fdc3237f9935a.jpg)
Например, чтобы напечатать чек, терминал помещает в CouchDB документ, описывающий чек. QRBox получает этот документ, формирует пакет данных для фискального регистратора, убеждается, что чек напечатан, делает соответствующую отметку в CouchDB для терминала.
Итог: есть решение, которое можно назвать прототипом. Терминал печатает чеки, и отправляет/получает данные по wi-fi на локальную машину. Переходим к back-office.
Вам нужен сервер?
Безусловно, одним из самых затратных для развёртывания и сопровождения компонентов системы автоматизации является сервер, обеспечивающий управление всеми остальными устройствами. Сервер нужно приобрести, нужно установить на него ОС, необходимые сервисы, настроить сеть, обеспечить бесперебойное электропитание, охлаждение, резервное копирование; нужно следить, чтобы не закончилось место на жёстком диске, чтобы сами жёсткие диски были вовремя заменены при угрозе поломки или при собственно поломке – и ещё многое и многое другое. Это требует не только финансовых вложений, но и человеческих ресурсов. Нужен системный администратор, который возьмёт на себя эту работу, системному администратору нужно платить, он может заболеть в самый неподходящий момент, может уволиться, может…
А что, если обойтись без сервера? Конечно, полностью обойтись без него невозможно, но что если наличие собственного сервера в каждой ресторанной сети или даже в каждом ресторане станет необязательным? Что, если сервер будет расположен где-то далеко, в хорошо оборудованной серверной, под неусыпным присмотром квалифицированных специалистов? Что, если сервер будет, по последней моде, в «облаке», дорога в облака становится всё шире и доступней, почему нет?
Сначала эта идея показалась странной. Ведь всем понятно, что работа облачных сервисов полностью зависит от качества связи с ними. Пропадет интернет-соединение на любом из возможных участков от «облака» до конечного пользователя – и ресторан «встанет». Требовать от наших клиентов обеспечивать резервирование интернет-канала? Не всегда и не везде это возможно, а уж тем более возможно за относительно небольшие средства. А если обеспечение интернет-канала требует значительных вложений – теряется вся экономия от устранения локального сервера.
Но далее мысль получила развитие. Так ли необходима постоянная связь с сервером? Разве терминалы не могут иметь собственную память, в которой будут храниться данные о совершённых за последние несколько часов или даже сутки операциях, периодически выгружая данные на центральный сервер? И тут мы поняли, что находимся в шаге от решения – одноранговая пиринговая сеть между терминалами! Действительно, зачем нужен центральный сервер, если все необходимые данные есть на самих терминалах, которые могут обмениваться ими между собой?
По результатам анализа стало ясно, что решение возможно и вполне работоспособно. В качестве системы хранения данных была выбрана та же CouchDB, которая поддерживает репликацию между нодами в режиме мастер-мастер «из коробки». Реализации этой базы данных существуют под множество платформ, включая Linux, iOS, Android и даже Windows, что открыло для нас возможность портирования терминального приложения на любую из этих платформ. Итогом стало решение, позволяющее обойтись без выделенного сервера, а возложить все задачи на терминалы и облачный сервис.
![](https://habrastorage.org/files/be6/ab2/68a/be6ab268a02f4665b3f3b3348cef3c16.png)
Общую схему получившегося решения вы можете видеть на схеме. Основным хранилищем данных выступает база данных PostgreSQL, в которую данные попадают через серверное приложение. Необходимую для бесперебойной работы точек продаж часть данных серверное приложение выгружает в CouchDB, откуда они реплицируются в базы данных терминалов конкретных точек продаж. Если в работе механизма репликации произойдёт сбой, например, в результате нарушения связи, это не приведёт к фатальным последствиям – репликация будет восстановлена после устранения причин сбоя, то есть восстановления связи между базами данных. При этом терминалы в своей работе даже не замечают отсутствия связи с центральным сервером – локальная база функционирует и даже может пополняться новыми данными, поступающими с других терминалов, образующих пиринговую сеть.
Но, разумеется, администратору системы требуется собственное рабочее место, с помощью которого он мог бы манипулировать данными всей системы в целом. Просматривать статистические данные, менять глобальные настройки, регистрировать новые терминалы, менять цены и многое, многое другое. Такое рабочее место реализовано в виде веб-приложения, которое взаимодействует с главным серверным приложением через REST API.
При разработке веб-приложения использовались последние достижения индустрии в построении отзывчивых веб-приложений, в частности за основу были выбраны компоненты kendo UI и фреймворк AngularJS. Использование готовых компонентов сильно сократило время на разработку пользовательского интерфейса, позволив сосредоточиться на предоставлении понятных, удобных и универсальных способов управления данными. В результате администратор имеет возможность как получить детальные данные об отдельных объектах системы, так и наблюдать общую картину с помощью отчетов и предоставления агрегированных данных.
Что дальше?
Продукт зарелизен, набирает обороты, и вроде даже нравится не только нам :)
![](https://habrastorage.org/files/151/12b/ff4/15112bff43914cf98a877f75fe5b2b25.png)
![](https://habrastorage.org/files/3a1/e74/609/3a1e746096f14aa696a8250bcf852262.png)
Понемногу наращиваем функционал и правим всплывающие баги. Наблюдаем за появлением конкурентов. Будни стартапа, словом. Но на сегодня, пожалуй, всё – более подробно про наш продукт и его разработку расскажем в следующих постах. А пока были рады знакомству и с удовольствием ответим на ваши вопросы в комментариях.
P.S. Для желающих посмотреть бэк-офис без регистрации