From the Redux docs on Basic State Shape:
Most applications deal with multiple types of data, which can be broadly divided into three categories:
Domain data: data that the application needs to show, use, or modify (such as "all of the Todos retrieved from the server")
App state: data that is specific to the application's behavior (such as "Todo #5 is currently selected", or "there is a request in progress to fetch Todos")
UI state: data that represents how the UI is currently displayed (such as "The EditTodo modal dialog is currently open")
The Domain data part is clear to me, but I can still vaguely distinguish between the App state and UI state. The examples given for the App state part: "Todo #5 is currently selected", or "there is a request in progress to fetch Todos", sound pretty much UI state-ish. How are they classified as App state, but not UI state?
I wrote that Redux docs page. (4 years ago! wow. time flies!)
I was trying to give some broad examples as a way to illustrate the concepts, not make strict categorizations. You could probably make a legit argument that "which todo is selected" is more "UI"-ish than "App"-ish. On the other hand, I'd say that "current selected todo" is more likely to relate to something else that the app can do, like "delete this todo", "mark this todo as completed", etc, while "the modal is open" is strictly about how the UI is being displayed.
Related
I have two queries related to SCRUM. They are as follows:
I have read that the format of SCRUM story is "As a < type of user >, I want < some goal > so that < some reason >". I have to write a story for an API. This API will send an email with a link to validate the email address of the user. What will be the type of user here? Will it be the user logged in?
Do subtasks have story format similar to a story or it can be a normal description?
The trouble you are encountering is likely that you are starting from a determined implementation and then trying to work backwards to the need (unless your product is an API that your users leverage, in which case I think that answers your questions).
When we approach it from a user need, we'll usually end up with more of a problem statement, like
"As a vacationer, I'd like the site to calculate the best route across
all types of transportation for me so that I don't have to run many
searches to figure it out myself."
One of the pieces of delivering on this need will be creating the API calls if your application architecture calls for that. Then "add API method for aggregated call" may be a task under that user story.
You will have cases where all a particular story needs is API work, and that's fine, but it won't come out in the user story. For example, let's say we did the about user story but limited it to planes and trains for the first start, then we created another story that reads:
"As a vacationer in the US, I want my trip planner to factor in buses
so that I can make use of bus tours in my vacation."
Now, maybe the only task in there is to create a some API changes to include the bus routes in the search, but that doesn't cause a problem with your user stories because we started back at the user's problem statement in the beginning instead of starting at the desired implementation and working backward.
Let's start clarifying some concepts first.
Scrum is not an acronym so is written as Scrum (proper name). Then, there is nothing called "Scrum Stories". What you are referring to is called: user story. User stories were wide used in the Chrysler C3 project were eXtreme Programming was developed. Furthermore, you are referring to a particular template which was popularized by Mike Cohn known as canonical form. So it's ok to express your Product Backlog Item as user stories for an API. But take into account that you can use this template, you can use user stories or you can write the Product Backlog Item the way has more sense and value to you. In your case, which is the persona, machine or service which will be used the API?
About your second question. The Scrum Guide just says you should decompose your Sprint Planning in unit of work of 1 day or less. Normally, the implementation is to create this unit of work and call them task which are the work necessary to carry out the user story. The way the are written is open too but is not quite common to write them in the canonical form. So you can write it as an ID, title and a description.
I am developing a simple, custom skill for Alexa. I have it up and running, and hosting the handler on AWS Lambda. It's working fine except...
In the test UI, if I enter a valid utterance, e.g., help, cancel, swim, run (two custom utterances), everything works well; however, if I enter a nonsense utterance, e.g., dsfhfdsjhf, the Alexa service always maps the nonsense to the first valid intent in the intents schema.
In my lambda code, I have a handler for handling unknown intents; however, the intent is never unknown. Is this an artifact of the test interface? Something else happening?
Thanks,
John
Based on the inclusion of an unhandled intent in your approach, it sounds like you are using the Alexa Skills Kit SDK for Node.js. Your issue is not an artifact of the test interface. Yes, something else is happening.
While not yet acknowledged by amazon, this is a recognized issue in the SDK by a number of folks. See this open issue. Speaking from personal experience to the suggestion above, it doesn't matter if you use real words or gibberish, the unhandled intent is never called. Until this is fixed, my suggestion would be to build a handler that is a high level prompt for your skill, and reiterates for the user the valid options they have. Position it to be the catch-all. Hopefully we will see better maintenance of this SDK moving forward.
Instead of typing dsfhfdsjhf (which is not pronounceable in any language Alexa knows), what happens if your utterance is boogie or shake?
In a real-world scenario, I don't think Alexa would ever pass dsfhfdsjhf, so it may be difficult to plan exactly what the behavior would be.
So you'd like to pipe all garbage inputs to a single intent. You're in luck. Here's a few things you should know before proceeding.
In Node.js the unhandled handler is fired within a MODE if the intent returned by the Alexa voice service is not available within the given MODE.
An example MODE would be confirmation mode. Of the many intents that are available yes and no are the only intents that are accepted.
var ConfirmationHandlers = Alexa.CreateStateHandler(states.CONFIRMATIONMODE, {
'YesIntent': function () {
this.handler.state = states.CLOSINGCOSTSMODE;
message = ` So you will be buying this house. Great! `;
reprompt = `Please carry on with the other intents found in the house buyer skill. `;
this.emit(':ask', message, reprompt);
},
'NoIntent': function () {
this.handler.state = states.GENERALSEARCHMODE;
message = ` So you won't be buying this house. That's Ok, Continue searching for your dream house in the House buyer skill. !`;
reprompt = `Continue searching for your dream house in the House buyer skill.`;
this.emit(':ask', message, reprompt);
},
'Unhandled': function() {
console.log("UNHANDLED");
var reprompt = ` All other intents are disabled at this moment. Would you like to buy this house Yes or No? `;
this.emit(':ask', reprompt, reprompt);
}
});
However, before reaching the lambda function the Alexa Voice Service must interpret your utterance and map it to one of the available intents. If your utterance is garbage and does not map to any specific intent it is currently being mapped to the first intent.
Solution: If you would like to add a garbage intent this is something that should be handled by the intent schema not by the unhandled intent. To add a garbage intent you can follow the instructions in this amazon article.
https://developer.amazon.com/blogs/post/Tx3IHSFQSUF3RQP/Why-a-Custom-Slot-is-the-Literal-Solution
Scenario 3: I just want everything. Using custom slot types for
grammar as described above typically fulfills this desire and enables
you to improve accuracy through NLP training. If you still just want
everything, you can create a custom slot called something like
“CatchAll” and a corresponding intent and utterance: CatchAllIntent
{CatchAll}. If you use the same training data that you would have used
for LITERAL, you’ll get the same results. People typically find that
adding a little more scenario specific training data improves
accuracy.
If you’re still not getting the results, trying setting the CatchAll
values to around twenty 2 to 8 word random phrases (from a random word
generator – be really random). When the user says something that
matches your other utterances, those intents will still be sent. When
it doesn’t match any of those, it will fall to the CatchAll slot. If
you go this route, you’re going to lose accuracy because you’re not
taking full advantage of Alexa’s NLP so you’ll need to test heavily.
Any input that is not mapped to one of your more specific intents, like YES or NO, will very likely map to this CatchAll intent.
My question is very specific and not for all, I want people to help me with my train of thought.
What I want to build : for example I have service where all people (not logined) can create they post with some data like news and publish it for money.
How I think it should be built (in 2 steps):
Man click on the link to page with form that create posts and router go to this page
He fills data and click submit
Server checked form and if all OK, session.set this data that he fills and route to the next step (pay money
to publish they post)
(I want to build this with stripe so) He clicked on stripe checkout button and pay some $$, if he paid then show message, all ok, we session.get data that he fills from previous step, and on server we insert his post and go it, if not show message that something wrong
Technical Plan session.set session.get, it is right ?
And if someone slip through form with fills and go to payment page, how to check it ? If session.get === undefind or something like this, reroute to previous step ?
As you can see I have a lot of questions, and I cant find answers in google or some documentation tutorials and etc. maybe some have answers to it
Your question is very wide. Consider narrowing it.
Your 2 first points make sense. It's ok. The third and forth are wrong.
Technical Plan session.set session.get, it is right ?
No it is not. You plan to use the information you hold in a Session variable to publish data validated on client side. It does not ensure the validity of your data. This is a bad idea because anyone can open the console and edit the data to make it different/invalid regarding your rules of validation. All it takes is a Session.set ("yourData", "YouHaveBeenHacked");
What you need is to call a Meteor method on server side to add an entry to a dedicated collection. You add another field (e.g; status) to keep track of the post payment and publication and return the data entry _id that you store in a Session variable.
This way, your method can return an error if the data does not fit into your requirements.
Side note: you also need to add a CRON job serverside to get rid of all the old post tentatives that have not been paid for (user left his browser, he closed tab, etc.).
I have a Tridion implementation that is, in essence, multi-tennent. Different interest groups use the same environment. Security takes care that users cannot see publications/content from groups they are not permitted to see. However, in the publishing queue, all users can see the title of items that are in the queue; they cannot open the item but they can see the title (e.g. "Our company releases sky high profits!")
For sensitivity reasons I would like hide the title of the item when the queue list is loaded according to the scoped publications of the user viewing the queue. So, for example, If I am only able to work in publications b & c but not in a & d when the queue loads, I can see the titles of content coming from b & c but not a & d. I will see something like "Item from publication D".
Is this straight-forward to do with an extension and does any one have some examples of how to do this?
The logic is the most complicated thing about it. You need to work out what the user can see or not.
This is a good candidate for a Data Extender to the CME. Filter out the items on the server before the response is returned. There is a section of the online documentation dedicated to the topic, so that is hopefully enough to get you started.
A crafty person would still be able to access the information by directly querying the API / Core Service, but I imagine that is not a high priority in this case.
Recently, I looked at spring 2.3 webflow booking-faces demo, I found it strange that a different flow execution key is assigned every time I click to "browse" hotel detail.
When I search the hotels and page to the 5th page of the search result, I get an URL with execution=e1s2. Then I click to browse a hotel detail, I get an URL with execution=e1s3. But when I click the "back to search" button, I found the page is directed to the first page of the search list with an execution=e1s4 URL, and the paging state is missed. However, browsing step is defined in the same flow definition with hotel search act and paging var is defined within flow scope.
My question is whether a new execution key parameter means a new flow execution? What's the semantics? If so, How can I configure to stick into an identical flow execution when I click "back to search" button.
Thanks
To be precise: the flow execution key (eg. "e1s2") indeed consists of two parts:
"e1": This part identifies the flow execution. Each time you start a new flow, a new flow execution is created. A flow execution essentially holds all state associated with the executing flow (i.e. the conversation you're having with the web application). When a flow hits an end-state, the flow execution (and all associated snapshots) will be destroyed.
"s2": This part identifies a snapshot within the flow execution. Webflow uses so-called continuation snapshots to be able to support the browser back and refresh buttons. On every request into a flow execution, webflow creates a new snapshot that allows you to continue from that point onward if needed, for instance when you use the browser back button.
See also:
https://docs.spring.io/spring-webflow/docs/current/api/org/springframework/webflow/execution/repository/support/CompositeFlowExecutionKey.html
Keep in mind that the flow execution key is not intended to be human readable or be interpreted by other software. This is essentially an internal webflow artifact.