В чем именно не совпадает ? Исправлю.
Допиленным и текущий e-commerce проект не будет нуждаться в сторонней CRM, разумеется.
Интересно, в первую очередь, как это решается в продуктах типа SalesForce МойСклад, Мегаплан, Битрикс и т.д.. Или нет решения из коробки наиболее удовлетворяющего такому простому требования? Никто не ориентирован на работу с клиентами с милионными каталогами? И нужно раз в час грузить XML файл размером в пару гигабайт? Тогда вопрос, как на это будут реагировать соответствующие сервисы.
Если речь о self-hosted решениях, то конкретный вопрос о том, где это сделать проще всего (как в заголовке), например, где есть простое и работающее API и, желательно, документация?
Туралъ: это как с фокусами - куда вы тщательнее всего смотрите, там вас и обманывают. А логические задачки в книжках - это синтетические примеры. Отлично, когда раз в год вы пролистываете одну из таких специализированных книг, но ставить на них акцент не стоит. Просто занимайтесь разносторонними делами в жизни
Pianista: рельс приложение не может занимать 80 мб. Куда-то не туда смотрите. Поставьте HTOP, там нагляднее. И когда происходит затык в 20 секунд -включайте его и анализируйте.
Денис: вам в любом случае нужно забыть про "хостинги" для руби. Возьмите любой VPS и сделайте там точно такое же окружение, как у вас локально.
Если этого для решения вашей задачи хватит - хорошо. Если нет - то прочитайте про очереди задач.
В вашем алгоритме, зачастую, руби решает только задачу №3. 1,2,4 обычно занимается веб-сервер, например. nginx
Во-первых, очень непонятно, как вы эмулировали 2 сервера на локальной машине. И на каком таком "хостинге" уже не работает. Для начала у вас везде должны быть *nix системы - локально, "на хостинге". В крайнем случае - виртуалки.
Во-вторых, совсем неясно, что именно нужно делать и для чего
В-третьих, такие архитектурные решения в общем случае не имеют отношения к языкам и называются очередями. Например, распространенным вариантом выступает Redis
Ну а по факту вопроса "интересно на будущее" - резюмируем:
1. Такие случаи крайне редки
2. Факторов, различающие "такие случаи" - огромное множество, которое постоянно новое и схожа будет только поверхность задачи
3. Как следствие - универсального алгоритма нет, т.к. куда проще\дешевле\надежнее решать эту задачу в конкретном случае уже на месте.
Илья Босенок: а вы погуглите достоинства и недостатики гибких методологий и каскада, прикиньте, сколько десятков (сотен, тысяч...) вещей нужно сделать "на будущее, по хорошему раскладу, когда бизнес взлетит", поймите что как ни крути, выставлять приоритеты придется - а на интернет-магазин вам никто не даст бюджет в пару миллиардов долларов и сроки в десяток лет :)
Так же, почитайте, что Макконел думает о дебаге и профайлинге. И как часто, по его словам, программисты ищут "узкое место" совсем не там, где оно на самом деле есть.
Евгений Ткаченко: просто нужно запомнить, что есть #present? (и как следстсвтие #presence) для начала - можно даже без #blaml?, #empty? и т.д.
Ваш пример делает частично то, что делает #present? но делает это плохо (не на всех случаи) и еще и упадет на nil, array и т.д.
OnYourLips: В идеальном мире, в принципе, так оно есть
В реальном - есть внутрикорпоративные проекты (да и любые другие автоматизации предназначенные "для своих"), где важна не теоретическая секьюрность, а удобство пользования. Например, что б с мобильника нельзя было отправить неверные результат, который приведет к перезагрузке страницы без сохранения.
Вадим Егоров: логично, потому что по js обращается пользователь, а не сервер
а через сервер очень быстро упретесь в лимиты.
если у вас до 100 запросов в день, можете хоть беслпатное API использовать, хоть парсить гугл вручную. Думаю, адрес для "вручную" найти не проблема
Допиленным и текущий e-commerce проект не будет нуждаться в сторонней CRM, разумеется.
Интересно, в первую очередь, как это решается в продуктах типа SalesForce МойСклад, Мегаплан, Битрикс и т.д.. Или нет решения из коробки наиболее удовлетворяющего такому простому требования? Никто не ориентирован на работу с клиентами с милионными каталогами? И нужно раз в час грузить XML файл размером в пару гигабайт? Тогда вопрос, как на это будут реагировать соответствующие сервисы.
Если речь о self-hosted решениях, то конкретный вопрос о том, где это сделать проще всего (как в заголовке), например, где есть простое и работающее API и, желательно, документация?