I have developed a website that uses Google Geocoding to show distance in miles between point A and point B.
I have performed a great deal of testing and all is working as it should be.
However, whenever my client tests it the destinations returned are not correct.
i.e, I enter postcode EH12 5DR, I correctly receive an address in Edinburgh. When the client tried the same postcode it returned E H Shoes at an address in Belfast. This is only one of a few instances.
This only appears to be an issue with my clients machine and I'm at a loss to explain what is wrong.
Any advice would be greatly appreciated.
Regards,
Richard
http://www.minibusedinburgh.com/
Has the client tried in more than one browser ?
Has the client ignored some sort of auto-suggestion - cos it looks suspicious at least, when you have a post code EH12 5DR and the client gets something back that starts with EH.
Related
I want a mobile web to send a specific message with following link "sms:number?body=text".
The best case scenario would be client inputting his ID once (either through registering or just by inputting the ID into form) and then he would be able to tap on the link with the additional output ("sms:number?body=text+ID".)
The reason for this is that the client should be able to ask about his account balance through predefined text message with as little effort as possible as the ID number is quite long and inputting the number every time would be quite tiring but I would be happy even with a simple form where you can input the ID.
The problem is, I have no idea where to start, what would be the best approach and so on. Any suggestions?
Thank you very much in advance.
My application joins about 50 rooms for one user on one connection all at once. After a couple rooms successfully join I start to get a server error return on some of the rooms.
There error is always the same, here it is:
Error: Server Error
at Object.i.build (https://cdn.goinstant.net/v1/platform.min.js:4:7501)
at Connection._onResponse (https://cdn.goinstant.net/v1/platform.min.js:7:25694)
at Connection._onMessage (https://cdn.goinstant.net/v1/platform.min.js:7:28812)
at Connection._onMessage (https://cdn.goinstant.net/v1/platform.min.js:3:4965)
at r.e (https://cdn.goinstant.net/v1/platform.min.js:1:4595)
at r.emit (https://cdn.goinstant.net/v1/platform.min.js:2:6668)
at r.e (https://cdn.goinstant.net/v1/platform.min.js:1:4595)
at r.emit (https://cdn.goinstant.net/v1/platform.min.js:3:7482)
at r.onPacket (https://cdn.goinstant.net/v1/platform.min.js:3:14652)
at r.<anonymous> (https://cdn.goinstant.net/v1/platform.min.js:3:12614)
It's not isolated to any particular rooms, sometimes half of them pass, sometimes nearly all pass, but there are almost always a couple that break.
What I have found is if it's less than 10 rooms it won't break.
Is there any rate limiting on joining rooms that could be causing this? I'd rather not put a delay between each room join but I can if I need to.
Update: It definitely has to do with how fast I'm connecting to the rooms. Spacing them out by 1s each makes it work every time. I need to connect faster though, is there a fix for this?
Even a 100ms deplay seems to work.
This isn't a case of rate-limiting or anything along those lines. It's a bug and we are working to fix it as soon as we can. We'll update you here once we have a solution deployed. If you'd like for us to email you a notification directly, drop us a message via our contact form (https://goinstant.com/contact). Just make reference to this issue and I'll make sure a note is added to email you directly as soon as the fix goes live.
Sorry for any inconvenience this may be causing you.
Regards,
Thomas
Developer, GoInstant
Based on the documentation it would appear that there is no way to have the phone numbers for a google place to be returned with the Place Search data ?
Which means that if I do a Place Search request I then need to make 20 more "Place Details" requests to get the phone number for each search result.
To mean this seems like a a fundamental piece of information I would expect back from the
"Place Search" request ?
Am I missing something or or is there no way or getting the phone numbers returned based on a search request ?
Any help would be much appreciated.
Thanks in advance
This is correct, there is no way to get the phone number of a business without issuing a Place Details request.
This is in place to encourage compliance with Google Maps APIs Terms of Service - Section 10.2 Restrictions on the Types of Applications that You are Permitted to Build with the Maps API(s): (b) No Business, Residential, or Telephone Listings Services.
You should only need to issue a Places Details request if a user action indicates that they would like more information about a Place.
An example:
Say, I have an AJAX chat on a page where people can talk to each other.
How is it possible to display (send) the message sent by person A to persons B, C and D while they have the chat opened?
I understand that technically it works a bit different: the chat(ajax) is reading from DB (or other source), say every second, to find out if there are new messages to display.
But I wonder if there is a method to send the new message to the rest of the people just when it is sent, and not to load the DB with 1000s of reads every second.
Please note that the AJAX chat example is just an example to explain what I want, and is not something I want to realize. I just need to know if there is a method to let all the opened browser at a specific page(ajax) that there is new content on the server that should be gathered.
{sorry for my English}
Since the server cannot respond to a client without a corresponding request, you need to keep state for each user's queued message. However, this is exactly what the database accomplishes. You cannot get around this by replacing the database with something that doesn't just accomplish the same thing in a different way. That said, there are surely optimizations you could do. Keep in mind, however, that you shouldn't prematurely optimize situations like this; databases are designed to handle extremely high traffic, and it's very possible (and in fact, likely), that the scenario described will be handled just fine by the database out of the box.
What you're describing is generally referred to as the 'Comet' concept. See the Wikipedia article for details, especially implementation options (long polling, etc.).
Another answer is to have the server push changes to connected clients, that way there is just one call to the database and then the server pushes the change to all the clients. This article indicates it is possible, however I have never tried this myself.
It's very basic, but if you want to stick with a standard AJAX solution, a simple means of reducing load on the server when polling would be to get the AJAX call to forward the last collected comment ID for that client - you then use that (with the appropriate escaping) in the lookup query on the server side to ensure you only return new comments.
I'm building a Twitter app that requires to check user data somewhat frequently, but I'm facing trouble with a cache that's oddly on Twitter's side, not mine.
Try the following user:
users/show in XML: http://twitter.com/users/show.xml?screen_name=technolocus
users/show in JSON: http://twitter.com/users/show.json?screen_name=technolocus
normal page: http://twitter.com/technolocus
All these methods of accessing data should return the same values, right? Check the statuses_count for each of them.
XML: 12548
JSON: 12513
normal: 12498
The normal method (i.e. just visiting the profile non-programatically) serves up the most correct value of 12498. If I post or delete tweets to this account, it gets updated on the profile page instantly, but the XML and JSON methods still return cached data.
At this point, the values of the XML and JSON methods are 12 to 18 hours old respectively.
I first tried to access these methods from my website (hosted on Dreamhost). I thought it was Dreamhost caching the responses. Then I tried to access the API directly from my browser. I did a cURL from the command line from my machine after that. It wasn't dreamhost. I thought it was probably my ISP (I think they use NetApp or something like that). Then I asked a friend in another corner of India to try it. He's getting the exact same cached responses as I am.
So it isn't Dreamhost's cache; it isn't my ISP or my country's cache. There's only one conclusion - Twitter is caching responses.
How in the heavens do I get around this?!?
Forgot to mention this: The script on the server is in PHP and is using cURL to retrieve the XML and JSON data from Twitter, while the local tests have been just using the browser. Both have the exact same result!
First, I think you should report this a a bug to Twitter. I see the same discrepancy as you, and no matter what that seems like a bug. Even if they're caching, I'd expect that a cache on their side would store an abstract form that would then be rendered into HTML, JSON, and XML. I wonder if what's actually going on is that these requests are performing similar but different queries.
Are you sure that the values are "old"? For example, did you actually delete about 50 updates recently (since you say the HTML one is newest but shows a lower count than the other two)? If you create another update do you see the HTML number increment while the other numbers stay the same, or do they all increment simultaneously?
If what you are saying is accurate, and it probably is, generally, you can't get around it. Twitter would want to be caching its responses since they are costly to reproduce every single time.
When you use Twitter's APIs, you end up being bound by its conventions, even if that includes caching.
Your best bet is to tweet to #twitterapi and get them to give you a response as to why the two representations are divergent.
Add ?blah=xxxx to all urls.
I don't develop anything against twitter and ocassionaly manually "follow" three tweets by going to them in my browser. They always lag behind by half a day. I add ?asdsadsadsad to the url (everytime something different) and it always updates. I don't know what Twitter is doing here and came here while searching for the problem. But I guess this trick of appending a random value to the url via GET will probably work for your api requests, too.