I am trying to use the LUIS container and am getting conflicting information. I have a test application that uses the LUIS cloud service, using the Speech SDK. The Speech SDK assists in sending the audio stream to the cloud and getting the LUIS intents. And detecting intents is actually stated functionality of the Speech SDK. See the docs at this link.
https://learn.microsoft.com/en-us/azure/cognitive-services/speech-service/quickstarts/intent-recognition?pivots=programming-language-csharp
Currently, I am trying to move to the LUIS container using the same code base with the Speech SDK. However, when I try to connect to the to local LUIS container, (using SpeechConfig.FromEndpoint instead of SpeechConfig.FromSubscription) I get a connection error.
The conflicting information I am getting is whether the Speech SDK can support the LUIS container calls, or if I have to run the Speech-to-text container locally as well and broker the inputs and outputs of those containers in my code.
There is not much documentation on this scenario. Has anyone done this? Can you point me to any docs that describe this?
Sorry for the delayed response. The issue is that the Speech SDK (IntentRecognizer) does not work with the LUIS container, it only works with the LUIS cloud service. When using containers, you have to use both the LUIS and Speech-to-text (in my case) containers and both of the SDKs. And actually, the LUIS prediction requests from the LUIS SDK to the container do not work either. So, you have to build the HTTP requests manually and use the REST API in the LUIS container. I have it basically working at this point. So, this issue can be closed.
Related
I was surfing on internet for solutions and tools related to the API Layer and I find a company (maybe a startup) that is developing an ecosystem that allow to "virtualize the API Layer" (at the moment only in .net Core). It seems they allow to don't code the Api layer, don't write documentation of endpoints, don't writeE2E test (automatically inferred), change behaviour of endpoints at runtime and reuse the entire stack in another project. Do you think is it really possible something like this and useful in the world of API development? thanks
If I understand the question, your wondering about setting up an API layer with just the endpoints, but the endpoints have empty logic in them, right?
If so, then yes its possible to do this with a variety of tools. One tool I use is Postman, which allows you to setup a "skeleton" API you can call for design/testing purposes.
It allows standing up a mock server that hosts your skeleton API, in which any consumer can hook into.
We're using Corda Enterprise version 4.2 and we want use these endpoints mentioned in Corda docs:
https://docs.corda.net/docs/corda-os/4.6/network-map.html
We've tried to access these REST endpoints directly using NetworkMap-NLB through PostMan, but couldn't.
Like #wawrzek said in the docs it's totally possible to make requests at the CENM API.
link here: https://docs.corda.net/docs/cenm/1.4/network-map-overview.html
Good luck!
Is it possible to deploy Azure Face API trained model to IoT Edge like Custom Vision?
If it is, please answer me how to do that?
Updating this topic...
Now you can download a Docker Image with the Face API for running it on-premises.
Here you can find the documentation for testing this feature, that currently is in public preview.
Here you can see the list of all the Azure Cognitive Services that are available as Docker Containers.
This new feature basically is targeting enterprises that:
Are not willing or able to load all their data into the cloud for processing or storage;
Are subject to regulatory requirements on handling customer data;
Have data that they aren’t comfortable sharing and processing in a cloud, regardless of security;
Have weak bandwidth or disconnected environments with high latency and TPS issues.
Model export is not a feature supported by the Face API.
So it seems that in the spirit of having documentation all over the place, docs.microsoft has once again taken the cake.
Looking into sending push notifications, I came across these two pages:
https://learn.microsoft.com/en-us/appcenter/sdk/push/uwp
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-windows-store-dotnet-get-started-push
Notice how there's no reference from either page to the other.
So I tried searching Google, doing similar searches to the title of this question, only to find little more than the above two pages.
Which brings me here, with the following question:
What is the relationship (and/or difference) between App Center Push and Azure Notification Hub?
They don't have a reference from either to the other because they are two completely unrelated solutions (except for the fact they solve the same problem).
Both allow you to setup a cross-platform push notification infrastructure for your mobile app, but App Center is free, specifically built for iOS, Android and Windows notifications and requires less setup, but gives you a bit less control over how the notifications look. However it makes it easier to segment notifications based on analytics data. Notifications Hub is a Azure service, so you need a Azure subscription and you need to build a backend to make it work. It takes a more work but you have more complete control over the notifications.
The awesome James Montemagno made a nice summary article comparing the two options.
I think its important to add the fact that App Center Push, Auth and Data are now being retired, despite Push being a fantastic offering IMO:
https://visualstudiomagazine.com/articles/2020/02/14/app-center-mbaas.aspx
"We are discontinuing efforts in the Auth, Data, and Push services and
working to retire these preview services in App Center," said John
Wargo, principal program manager for Visual Studio App Center. "With
this change, we will focus App Center on delivering a world-class
mobile and desktop DevOps experience. We will also work together with
Azure teams to help migrate developers to the native Azure services,
and ensure that Azure continues to be a great platform for your mobile
apps."
There seems to be no full migration path at time of writing, but there is the hint this will be handled mostly for existing users -
https://learn.microsoft.com/en-us/appcenter/migration/push/
We don’t expect customers to manually migrate from App Center Push to
Azure Notification Hubs; so before the service shutdown, we’ll provide
detailed instructions for how to streamline your app’s migration from
App Center Push to Azure Notification Hubs.
In other words, what part of Google Cloud Endpoints is not in the SDK?
I've seen several people saying that simply running their application elsewhere doesn't work. For exaple, see: https://groups.google.com/forum/#!searchin/appscale_community/endpoints/appscale_community/BFagV00RUcU/taaAoV5mxNEJ
What part of Google Cloud Endpoints is not in the SDK? Are there any initiatives going to try to implement that?
Endpoints has two components. The first is the SDK, and the second is the API proxy. In theory, both could work on other platforms, but the reality is that you would need to really understand the finer details of the interaction between the two to execute it. You could also in theory try to use the dev server servlets to run on other platforms. I make no guarantees about the robustness of either solution.