i have created some Intent & Entities and would like to Train and Test the LUIS, but it is taking more time than usual, even sometimes it updates me with the error without completing the training. Is there any other alternative to train the Luis?
Thanks,
You can train and test (and do much more...) LUIS using the API. However, you cannot be sure that this will improve the performance. All if this is new and sometimes work not as good as the users expect.
Related
I've been testing Plaid's investments transactions endpoint (investments/transactions/get) in development.
I'm encountering issues with highly variable delays for data to be returned (following the product initialization with Link). Plaid states that it takes 1–2 minutes to return investment transaction data, but I've found that in practice, it can be up to several hours before the data is returned.
Anyone else using this endpoint and getting data returned within 1–2 minutes, or is it generally a longer wait?
If it is a longer wait, do you simply wait for the DEFAULT_UPDATE webhook before you retrieve the data?
So far, my experience with their investments/transactions/get has been problematic (missing transactions, product doesn't work as described in their docs, limited sandbox dataset, etc.) so I'm very interested in hearing from anyone with more experience with this endpoint.
Do you find this endpoint generally reliable, and the data provided to be usable, or have you had issues? I've not seen any issues with investments/holdings/get, so I'm hoping that my problems are unusual, and I just need to push through it.
I'm testing in development with my own brokerage accounts, so I know what the underlying transactions are compared to what Plaid is returning to me. My calls are set up correctly, and I can't get a helpful answer from Plaid support.
I took at look at the support issue and it does appear like the problem you're hitting is related to a bug (or two different bugs, in this case).
However, for posterity/anyone else reading this question, I looked it up and the general answer to the question is that the endpoint in the general case is pretty fast -- P95 latency for calling /investments/transactions/get is currently about 1 second (initial calls on an Item will be higher latency as they have more data to fetch and because they are blocked on Plaid's extracting the data for the Item for the first time -- hence the 1-2 minute guidance in the docs).
In addition, Investments updates at some major brokerages are scheduled to happen only overnight after market close, so there might be a delay of 12+ hours between making a trade and seeing that trade be returned by the API.
Capturing data in Keen.io is pretty straight-forward when it's driven by an event. (User-logged-in, Customer-bought-stuff, ...). That's very nicely explained in the docs.
But what is the best approach when I want insight on a state of my app at a given time in the past?
For instance: how many active licenses were there this time last year?
Our first thought is to run a cronjob every hour, to get those data from te DB, and store them in a custom collection. Is this the right approach, or are there better solutions?
I am very much new to the ZeroMQ library.
Hence I wanted to know the pattern ( REQ-REP, PUSH-PULL, PUB-SUB ) that will be the best for our application.
The application which we are using has two systems,
the one which the user interacts with
and
the second is the scheduler, which executes a job, scheduled by the user in the first system.
Now I want to make use of ZeroMQ to send messages in the below scenarios:
from userSystem to schedulerSystem that a job with particular job id is submitted for execution.
from schedulerSystem to userSystem that the job sent with a particular job id has been executed succesfully or the execution has failed
Can somebody please help with this,
stating the reason for using a particular pattern?
Thanks in advance.
Which is the best Formal Communication Pattern to use? None...
Dear Ann,with all due respect, nobody would try to seriously answer a question which of all the possible phone numbers is the best for any kind of use.
Why? There is simply no Swiss-Army-Knife for doing just anything.
That is surprisingly the good news.
As a system designer one may create The Right Solution on a green-field, using the just-enough design strategies for not doing more than necessary ( overhead-wise ) and have all the pluses on your design side ( scaleability-wise, low-latency-wise, memory-footprint-wise, etc. )
If no other requirements than (1) and (2) above appear,a light-weight schemelike this may work fine as an MVP "just-enough" design:
If userSystem does not process anything depending on a schedulerSystem output value, a PUSH-PULL might be an option for sending a job, with possible extensions.
For userSystem receiving independent, asynchronously organised state-reporting messages about respective jobID return code(s), again a receiver side poll-ed PUSH-PULL might work well.
Why? Otherwise natural unstructured behaviour-wise PAIR-PAIR disallows your processing from growing in scale once performance or architecture or both demand to move. PAIR-PAIR does not allow your communication framework to join more entities together, while others do and your processing power may go distributed until your IP-visibility and end-to-end latency permit.
The real world is typically much more complex
Just one picture, Fig.60 from the below-mentioned book:
The best next step?
To see a bigger picture on this subject >>> with more arguments, a simple signalling-plane picture and a direct link to a must-read book from Pieter HINTJENS.
We have an application that parses tweets and we want to see the activity in real time. We have tried several solution without success. Our main problems is that the graphing solution (example:graphite), needs a continious flow of metrics. When the db aggregates the metrics it's an average operation which is done, not a a sum.
We recently saw cube from square which would fit our requirement but it's too new.
Any alternatives?
I found the solution in the last version of graphite:
http://graphite.readthedocs.org/en/latest/config-carbon.html#storage-aggregation-conf
If I understood correctly, you cannot feed graphite in realtime, for instance as soon as you discover a new tweet?
If that's the case, it looks like you can specify a unix timestamp when updating graphite metric_path value timestamp\n so you could pass in the time of discovery/publication/whatever, regardless of when you process it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am only one person working on project - so I am developer without PM above me. I finished portal, hovewer client from time to time attacks me with request such as "make font bigger" or change margin in css or make button which makes "xxx and yyy".
There are simple task, sometimes only for few clicks, but it takes my time and I hate doing such tasks. On the other hand I understand those people, while sometimes small fix helps them a lot in work. What say them on communicators - it's hard to ignore them. Is disabling communicators best solution - but I need it to communicate with my co-workers.
What you do in such situations?
Create an established queue where your users can submit requests, in a manner that doesn't disrupt your day-to-day workflow.
From the sounds of this you are getting requests via a communication channel that you check regularly, you might try to move it off to the side.
Cutting off communication is NEVER a good solution. Also, I would formalize a process and time schedule for when you get to those types of requests. I've found great success with this simple approach.
If you're working for yourself, you clients are your single most important reason you're there. They are your business! Thus, it's always good practice to keep them happy.
That being said...
You should always always always have a clearly defined contract when working on any sort of software project for a client. You need to ensure that your deliverables are clearly expressed and defined both to you and to your customer. Once you've got that taken care of you need to also ensure that there is a section that covers "future maintenance requests" and you can then work with your client to ensure expectations are acceptable on both ends of the spectrum and your time spent on them is both accounted for and part of the original plan moving forward.
The fewer open ends, the better.
Afterwards, implementing a system to manage/handle customer requests for each of the projects/websites you've implemented can also be a great help. Tools like FogBugz from one of this sites founders do a great job in handling customer interaction and bug/feature requests. Check it out.
Although not a technical "bug", usability by the client is the most important bug to the user. If you want to continue business with the client, the small things need to be worked.
fixing small bugs == client happiness == more work == more $$
Deploy a system for tracking bugs and tracking change requests (at my office we use MKS, which is also used for source integrity). Then when a user has a request, they go into the tracking system and enter the request as the appropriate type. Ideally they should also be able to attach a severity/priority indicator to it so that the outstanding requests can be ranked. You can then go in and see all outstanding requests, and prioritize them. Since they are not being directly sent to you, you won't feel inundated with requests, and the users will find that they can track the status of their requests more easily than by calling you and asking "when will my fix be done?"
For yourself, you can check the list a few times a day and see if there are any high priority issues to work on. Then schedule some time on a regular basis (one day a week, or an hour day, whatever feels reasonable) to work on the lower priority issues.
I think you have to consider your ongoing relationship with your customer. If a customer spends a few minutes of your time occasionally you may consider that the cost to you is minimal and the benefits of the contact may outweigh the cost anyway.
If the requests are coming in thick and fast, you maybe need to talk to your customer about an hourly rate for changes or cover them in a chargeable support contract.
Do not change your path on each feature request that you get. Collect feature requests for a while, then prioritize the requests, then select the ones that make sense, and then work on the next release.
In my opinion it is good to follow some fixed release schedule: it makes the development process more controllable, improves software quality, and your customers know what to expect.