Google Places API rules define that we need to show third party attributions.
The problem is, I have no idea which address or Place will have a third party attribution, so I can test if my UI is behaving as it should. Of course I can mock this kind of data, but I wanted to test with real data also once.
Does anyone knows which address/Place has a third party attribution?
Related
I have a ruby pact mock service provider that captures my request. I would like to extract the exact value provided in the request (which was matched by a Pact.term / Pact.like), to do further processing with that value once the request has been answered by the pact service provider.
An example: a password reset functionality. Code makes an API call to a mailing service, providing the password reset link as parameter. Pact captures the request and mocks it successfully, validating the data. I pass the reset_link as one of the parameters (a Json body). This gets match in a Pact.term. All good. But I also want to recover the exact value that was used in the request (say reset_link: 'http://sample.com/reset-password?key=12345'), so I can make a subsequent request and check that exact link does indeed allow a successful password reset.
Now, if I was sending email directly, it is easy to do, I can just parse Mail::TestMailer.deliveries.last
How can I do this?
I've gone through the code, even creating a Pact::SomethingLike subclass wouldn't work, as the comparison method is a lovely functional programming module, not a method in the class.
Is there a before / after hook, or a way to grab the whole web request?
PS: I'm aware this is typically tested by the underlying library I use. The library sanctioned way of adjusting functionality is to override certain methods, I need to re-test the whole functionality.
PPS: this is not rails but roda.
Thanks
André
I'm not sure if Pact Ruby supports this exact requirement, however digging into why you're doing this, I'd suggest it's a bad idea.
This is a functional test, something that Pact consciously makes difficult to support. See https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html for more details as to why. There are better tools for the job for these sorts of tests, and they don't belong in the consumer code base (they absolutely do belong in the Providers' test suite).
Pact is a contract testing tool, and as such is only interested in isolated request/response contracts, not chained ones as per functional tests.
I have a bot that uses .NET, MS Bot Framework and LUIS.ai for its smarts.
All's fine, except that I need to provide a way for non-technical users to train the bot and teach it new things, i.e. new intents in LUIS.ai.
In other words, suppose that right now the bot can answer messages like "hey bot where can i get coffee" and "where can I buy some clothes" with simple phrases containing directions. Non-technical users need to be able to train it to answer "where can I get some food" too.
Here's what I have considered:
Continuing to use LUIS.ai. Doesn't work because LUIS.ai doesn't have an API. The best it has is the GUI to refine existing intents, and the upload app/phrase list feature. The process can be semi-automated if the JSON file with the app can be generated by some application that I write; however, there still needs to be backend code that handles the new intents, and that has to be implemented by a C# coder.
Could it work if I switch from C# to Node.js? Then theoretically I would be able to auto-generate code files / intent handlers.
Azure Bot Service. Seems it doesn't have a non-technical interface and is just a browser-based IDE.
Ditching Bot Framework entirely and using third-party tools such as motion.ai. Doesn't work because there's no "intellect" as the one provided by LUIS.ai.
Using Form Flow that's part of Bot Framework. If my GUI bot builder application can generate JSON files, these files can be used by Bot Framework to build a bot automatically. Doesn't work because there's no intellect as in LUIS.ai.
Keep using Bot Framework, but ditch LUIS and build a separate web service based on a node.js language processing library for determining intents. May or may not work, may be less smart than LUIS, and could be an overkill.
Override the method in LuisDialog that selects the intent from the LuisResponse, in order to use the my own way to decide the intent (but how?).
At this point I'm out of ideas and any pointers will be greatly appreciated.
First of all, LUIS.ai provides an API that you can use to automatize the training. Moreover, here is Luis Trainer written entirely in Python against the API that just does that.
The easiest one, probably is the one you are describing in #1: you can automatize the training (as explaining above) but you will still have to deploy a new version of the bot if new intents are being provided. One thing is letting users to train an existing model with new utteraces and another completely and different thing is to let them create the model :)
It might be hard to skip having to write the backend code (I wouldn't automatize that at all)
Here is a potential idea (not sure if it will work though). You would need 2 Luis models.
One with your current model, that users will be able to train with new utterances.
The second model, is one exclusively intended to be "expanded" with new intents by users.
If you separate this in that way, you might be able to look into a "plugin" architecture for the second LUIS model. So, your app, somehow, loads dinamically an assembly where the second model lives.
Once you you have that in place, you can focus on writing the backend code for your second Luis Model without having to worry about the bot/first model. You should be able to replace the assembly with the second Luis Model and be able in the bot to detect if there is new version of that assembly and replace the current one in the app domain.
As I said, is just an idea as I'm brainstorming with you. Sounds a bit complex, and it's not addressing all your concerns; as you still will need to write code (which in any case, you will eventually have to do)
I am working through a challenge project (training) to automate the creation of Chat Bots specifically targeted against a Luis.ai model using plain old javascript and web services to Luis.
I looked at the Bot Framework and it's just too cumbersome to automate (I want X number of customers to create a Chat Bot without coding). I also want to add my own type of 'Cards' (html widgets) that do more and can be easily configured by someone with zero coding skills.
Calls to the Luis.ai/Cognitive Services API are made in my code behind and the json response returned to my own rules engine. On the following URL click the LUIS API link on the page to open the Luis API Console where you can test, and train your Model. All the endpoints you will need are here...
https://dev.projectoxford.ai/docs/services/
Based on the various endpoints on that page, you can use WebClient in asp.net to pull back the response. So in my testing I have buttons on a page to push utterances up to the model, pull back entities, create hierarchical entities and so on. Have a look at http://onlinebotbuilder.com to see how an intent of product dynamically inserted a shopping cart.
When your tool is built and utterances start to arrive, Luis.ai will store them and via the Suggest tab (at Luis.ai) it will ask you for guidance...Unfortunately I don't think you could give that control over to your customers, unless they are experts in your domain (they understand which utterance belongs to which intent). You don't need to take your app down, just train it periodically to improve the Model based on your customers input...soon enough you will have your model working well based on your intents.
Hope that helps.
Around a year ago I made an iOS application that finds restaurants near your location of any type and displays information about them. I made a web service call using the FourSquare api to get all the data which was returned in json format and then I parsed it and displayed the information on the UI of the app. Now I want to make an android application using Xamarin.Android since I am learning working with Xamarin studios and C#. When I make a Xamarin.Android application and go to packages then add packages I see there is a Foursquare api package that has a .NET wrapper around it. Here is the website url:
https://www.nuget.org/packages/Foursquare.Api/
So my question is how does this work? Does adding this package mean I don't have to make a web serivce call anymore, instead all the data is stored inside this package and I just have to get all the data the same way I get information from a local database? What are the advantages of using this package instead of just making a web service call to Foursquare?
Think of it this way:
This Foursquare API is simply a .NET wrapper of the web service that you want to use. Thus, somebody has gone ahead and done all of the hard work for you so you can simply consume the returned data in your applications.
What does this mean for you?
Well it means that you don't have to write any REST consumption code and you can focus more on the actual application and any business logic that you need to implement based on the Foursquare objects.
To not confuse any further, this data would come the same way as if you wrote your own web service to access the data from the Foursquare API endpoint.
Advantages:
Already written for you
You don't need to know your way around their REST API
Usually follows best practices per language so it's easy to consume (Objects created, methods, etc)
Disadvantages:
REST endpoint might be updated and not reflect in the package until it's updated
Any bugs/issues in the framework can be hard to workaround if the project is not open source
Could be a lack of documentation on how to use the wrapper
As stated. I am using ruby to perform my task. I am to create a webpage that takes in user input and makes calls using the API back and forth. However, I am yet to understand how to deal with these APIs...
When you consume the API you are essentially making use of the service. So you are sending data and are, potentially, getting something back.
When you write a rest client, you are essentially writing an entity which will consume the API. The rest client could also provide some functionality to ease the consumption of the API, for instance if your API requires a time stamp, the rest client could automatically provide the current time stamp, or else provide the user with a nice UI control to do so easily, rather than type something like this: 22-10-2002 12:10:11 GMT.
The client itself can take different forms. It could be a simple page on a web page, or a more complex desktop or mobile application.
I am creating a web service which uses REST web services. The client side code is written in HTML/JavaScript. My dilemma is whether I
should use the REST resource directly using AJAX calls?
or
should I create Servlets/JSPs (where REST calls will be made and data will be sent to client(AJAX/JAVSCRIPT)).
I have seen many web apps which follow the 2nd procedure but seems to me that it's doing the same thing as 1st in an indirect way.
Is there any advantage of using 2nd procedure over first?
What is the standard way to use REST services by HTML/javaScript client?
Please let me know if I am even thinking in the right direction and if not please give your valuable insight.
You can use either approach but note that browsers will enforce the same-origin policy on scripts, so if the REST service lives on a different domain than the script you will need to use a servlet/script on the same domain as the script to proxy the call to the other domain. I suspect this is why you are seeing the second approach used.
A proxy/middle-man servlet may also be useful if not all of the response is needed; you could use the servlet to strip out information that is not needed by the JavaScript to reduce the amount of data sent to the browser.
Directly accessing the resource(s) via AJAX has the obvious benefit of less overhead and is IMHO the more elegant solution, however it is also important to note that not all browsers support PUT and DELETE requests natively.
To get around this, you'll likely want to support the common "_method" hack. This stackoverflow question mentions this approach.