When someone cites "cloud" and "machine learning" and "infinitely scalable" in the contest of the task of taking reservations I have to think he's full of it. The entire task for all restaurants in the US can be easily handled by a single server.
Also I think there are now 25 restaurant reservation systems with significant footprint in Japan alone (and more over east asia, urp, etc.). Instead of trying to cover every need and suggesting assholistic concepts like demand based pricing, many cater to very specific needs, and have started convincing even traditional restaurants to come on board as they offer them the ability to manage availability on an individual basis and replace their well guarded paper books, offering assurances the data won't leak.
I’m looking at the app and seeing Winnipeg restaurants correctly listed as in Manitoba. If this is one individual restaurant maybe they completed their info wrong for some bizarre reason. Per Orik’s 2018 comment above, I think it’s more likely listings are based on submissions from the clients than AI web crawling millions of data records to figure out where places are.
I honestly have no idea what you are talking about re "AI web crawling millons of data records" ... I'm surely not talking about that and didn't mention anything close to that. I also have no idea of how Orik's above comment (if I'm referring to the correct comment) is at all relevant to what we are talking about. In advance I'll say whether or not a single server can handle the processing, it is immaterial to the discussion. We are talking about what code is or is not doing, independent of load.
I do agree with Orik's first sentence above but it's incomplete ... he needs to add "AI web crawling" to the list ... web crawling isn't AI and it's nothing remotely close to it ... web crawling is pretty simple stuff ... also note that people working on AI don't refer to it as AI among themselves ... it's just algorithms ... a whole bunch of algorithms ... cranking away on lots of data ... the more servers the better
4. It could be related to something as simple as an A vs M data error with province information in one of their data sources for a single resto. For example, there is INCORRECT province info (ie Alberta, instead of Manitoba) associated with a Winnipeg Red Lobster located at 1540 Portage Ave, even though the postal code is clearly a Manitoba postal code
Wilf, the bizarre reason (what I generically called a data error*) is, at its origin, most likely ie most assuredly what we in the business call a TYPO ... or indeed someone who doesn't know their provinces ... but that's a TYPO in my book.
*In fact, I started out by typing “typo” … but before I got to the “o” another thought popped into my head and I realized that some nabob may nag me about its technical inaccuracy so I expanded it to “typo / data error” … I continued with “with province information …” and then I made a mid-sentence simplification for the sake of brevity and just got rid of the “typo / ”. This is fact. This is the truth. I have a keystroke log to prove it and I just looked at it and confirmed that this entire paragraph is keystroke for keystroke accurate ** !
** That last sentence (and ONLY that last sentence) was added to show you what bullshit really looks like
Let's continue now ... “data sources” can be indeed by a user typing (and making errors as you have correctly noted) but it can also be from other electronic sources (and those other electronic sources’ sources can be other electronic sources and on and on … each of which may or may not have manual user entries … any and all of these could have poor (ie no) error-correcting … which is inexcusable … but it is semi-shocking to me so see province / postal code mismatches (or state / zip) on public-facing apps from leading vendors in this day and age.
I will note that when sweet little Chambo was an undergrad and was as busy as a Beaver and paying his way thru university thru lots of hard work (and plenty of play), he personally built and oversaw people building such systems that would automatically do this super simplistic stuff ie state / zip correction … and this is back in the Stone Age of Computing, okay. Trust me, this should NOT be happening today anywhere at anytime. This should not have been happening 10 or 15 or 20 years ago. And this wasn’t happening on Chambo’s ship on Chambo’s watch even further back in time than that.
Pras, my dear, how are you ?
Now that I see your screen shots and see exactly what you are referring to, I am confident to say that my above post was dead-on, on point and word-for-word accurate
Per point 3 above, when I say it “occurs with both the iPhone app and the website”, I am referring to the incorrect province being displayed for the Winnipeg Red Lobster. If you haven't yet, search for it and then click on it. Note that even though that AB address is displayed within a box with Google’s map just above on the website, I do NOT believe that incorrect address is from Google ! It’s from elsewhere ... Based upon my limited exploring, Google has it right across multiple of their services ... just do a Google search for "red lobster winnipeg" and notice the MB. TripAdvisor is good too ... blah blah blah
Based upon your app vs website screenshots, I will now SPECULATE … because only the developer ie the coder really know what’s going on ... (but a crafty tester / user could triangulate pretty well if motivated enough ... but Chambo's has minimal interest (for Chambo ... I understand that others may think I'm "invested" here ... but I'm not ... I'm way too busy with other stuff)
I now think that there’s a very good chance that the app and website are indeed “leveraging the same back-end infrastructure” and it’s how the app user interface developer incorrectly opts to access / process location lists when the developer is not expecting a city to have more than one province in the underlying data (maybe because the data was SUPPOSEDLY already massaged and cleaned up … but it's the app UI developer who foolishly opted to make that assumption to blindly trust the underlying data, relying on others to do their job correctly, and thereby putting his end users are great risk and confusion ... and it's app UI developer who is the last line of defense to hide / cover up correctable internal data problems ... they are at fault IMHO ). Obviously I have ZERO idea how they are being fed (ie asking for) this data, but I’ll note that AB is alphabetically before MB … and in total darkness, I'll make a wild guess and say that MAY be highly relevant … or not ... they're other possibilities rolling around in my mind
Note that the website developer dealt with the faulty data situation admirably.
Hence if Chambo were in charge, he'd be calling the app UI developer, along with the testing group, into his office immediately. Somebody may very well be looking for a new job ... if reasonable responses to my questions were not forthcoming ... we don't eff around with nor put our global client base in jeopardy at Chambo Global Services ...