В статье упомянут Uber. Водители там используют свои устройства для работы и обеспечения заработка + им удобно работать именно со своими гаджетами. Вообще сегодня существует целое течение BYOD (bring your own device), когда люди в корпорациях имеют право работать на своих устройствах. Здесь логика схожая. Чат-бот, это удобный инструмент организации работы. Тем более, если твоя ЗП сдельная. Получил заказ, отработал, сделал план продаж.
Сожалеем о вашем неудачном опыте. Надеемся оправдать ожидания при следующем визите. Кстати, у нас приятное мобильное приложение и сайт. Да и доставку можно до квартиры заказать.
Есть примеры, когда несколько талантливых разрабов самостоятельно на коленке делали различных ботов. Денег и инвесторов на начальном этапе по их словам не было. Вот пример.
На самом деле масса людей приходят в магазин посмотреть и потрогать товар, особенно крупную бытовую технику (холодильники, стиральные машины и тд). Очень часто люди хотят поговорить с живым человеком.
Расчет был вынесен не просто в отдельный модуль внутри монолита, но в отдельный контейнер со своими настройками взаимодействия с окружающей средой и гибкой настройкой джобов запуска, т.е. в отдельный сервис.
Нет, другие языки мы не рассматривали, т.к. не было особой надобности, т.е. нас и бизнес полностью устроило время выполнения алгоритма даже с учетом растущих объемов, а так же Java — это основной язык нашей платформы и его функционал и мощности нас устраивают.
У нас на МСП уже есть микросервисный подход, т.е. каждая область бизнес-функционала выделена в свой сервис и имеет свои точки входа и отдачи данных. Мы добавили к общему скоупу еще один сервис, который получал от своего окружения нужные ему данные и делал свою работу далее автономно.
У нас было коробочное решение SAP ЕРП, которое и описано в статье и доработка которого требует и больших денег и ресурсов и не факт, что будет оптимальной, т.к. тут надо затрагивать глубинные алгоритмы SAP, а это уже совсем другие деньги. Поэтому было принято решение ухода от программирования на уровне pl/sql процедур СУБД Oracle и переход на более быстрый и масштабируемый функционал java и микросервисов. Т.е. тут речь вообще не о костылях, а о функциональном переносе бизнес-логики на другие рельсы. Так что следующий в этой ветке комментатор Verion прав — мы отказались от операций на уровне бд перейдя на уровень java
Никакой особой магии, использовали jdbc запросы для извлечения данных из памяти и java-коллекции для компактного размещения данных в памяти. Выбор пал в основном на структуры Map, т.к. они позволяли уйти от плоского вида данных, т.е. экономить память и иметь быстрый доступ к данным в ОЗУ.
Нет, другие языки мы не рассматривали, т.к. не было особой надобности, т.е. нас и бизнес полностью устроило время выполнения алгоритма даже с учетом растущих объемов, а так же Java — это основной язык нашей платформы и его функционал и мощности нас устраивают.