I want to use categories to explore an area.
If I include a categoryId in a call to the explore endpoint, it seems to work! But, this isn’t documented (on an already-experimental API) so I’m not super comfortable using it.
Is there a reason categories aren’t officially supported on this endpoint?
Related, what differences should I see between an explore and a search in an area (with intent set to browse)?
The venues/explore endpoint is rapidly, so there will frequently be experimental, undocumented parameters showing up. This does also mean that the behavior of undocumented parameters could change at any time. While we try to avoid making changes that break existing users, please be aware that only documented behavior should be depended on.
Related
[React/NodeJS] I'm having a huge struggle in finding the appropriate documentation on this topic -- I am looking to implement PayPal on my website, with the constraint being that the customer is charged after our offline service is completed (has variable costs, but there is something of a solution in mind such that if I can 'authorize' an amount equal to our maximum cost that we will be a-okay). My initial research indicated to me that PayPal Orders fulfill this desire, to at least an effective extent, ie. the order is placed and funds are not placed on hold until we authorize the charge, ideally after the offline service is completed (source: https://developer.paypal.com/docs/integration/direct/payments/orders/#order-response). Upon further inspection, I have discovered that the integration path using PayPal smart buttons is being heavily advocated in implementation docs and appear to be compatible with the orders API (source: https://developer.paypal.com/docs/checkout/).
I began working to implement the software, following the smart buttons implementation linked just prior, and followed the instruction to use server side api calls to process the payment (source: https://developer.paypal.com/docs/checkout/integrate/ and https://developer.paypal.com/docs/checkout/reference/server-integration/set-up-transaction/). Continuing forward, I pursued order creation explicitly using the orders API (mistake perhaps?) and used the docs for the v2 orders api and the docs for the nodeJs sdk package referenced in the paypal docs (paypal/checkout-server-sdk using the github docs). I set up the integration and the sandbox accounts showed that charges were being placed however, and this was contradictory to my desire to not place charges on hold until an authorization is completed. The status returned on the backend is kept at "created", so I was initially optimistic, but the charge placement was unfortunate.
I am struggling to find the next step. As the checkout-server-sdk is utilizing both payments/v2 and orders/v2 (source: https://www.npmjs.com/package/#paypal/checkout-server-sdk), I am lead to believe I can utilize those API endpoints as well, but can't find explicit functions that call the payments api in question in the checkout-server-sdk, which I believe I would need to change order intent in order to create an order (source: https://developer.paypal.com/docs/integration/direct/payments/orders/), but also noticed these docs (linked as active directly from the docs page for paypal I believe -- https://developer.paypal.com/docs/ ) post to payments/v1 (source: https://developer.paypal.com/docs/integration/direct/payments/orders/) which has been deprecated. Long story short, I am now lost and would thoroughly appreciate some guidance on where I walked astray, what docs to refer to, if this implementation is still supported, and potentially what the next step is. If I used incorrect verbiage or have some noticeable jump in logic that was to my detriment, I would love to know as I am fairly new to developer work as a whole. Thank you in advance!
Your use-case of not placing a temporary hold up front requires intent:order, and only the v1/orders API has this available. The v2/* APIs do not.
An intent:authorize hold typically clears from a card after about ~3 days (even though it is capturable up til day 29), so I would recommend using the v2 APIs if that's workable. But if it's important to not do that, then v1/orders can be used. The API is not going to disappear, people are using it. Even-yet-older Classic APIs with similar PAYMENTACTION=ORDER functionality are still in heavy use, after all.
We've recently had to pause our in-depth development with Alexa Skills,due to their Dynamic entities not being completey ready for the use case it was intended for (had confirmation direct from an AWS architect).
Documentation of same:
https://developer.amazon.com/docs/custom-skills/use-dynamic-entities-for-customized-interactions.html
https://developer.amazon.com/blogs/alexa/post/db4c0ed5-5a05-4037-a3a7-3fe5c29dcb65/use-dynamic-entities-to-create-personalized-voice-experiences
Regardless, we've since been making a POC for Google Assistant, as have heard of their equivalent (Dialogflow dynamic enity).
The problem we having is that this too doesn't seem to be loading data dynamically.
Our expected result is to; load data (dynamically), into a new slot that would be used during the action.
i.e. load a list of specific names at runtime, that can then be used for lookup while using the app.
Creating a new static lookup slot (within the console) with ±5 set names (unique and not common) work fine and everytime, however, as soon as you load those names dynamically, they are not recognized when spoken.
We've seen similar issues that all seem to be resolved, using POST calls to DialogFlow, however, we are unable to replicate this in a runtime environment.
Dialogflow dynamic enity issue
Has anyone had similar issues with this and managed to get it working as expected?
If so, would you mind please sharing some additional documentation that could help with an example of same? I suspect we are really close but are missing something simple.
PS - I have not pasted example code here deliberately, as I am after documentation and examples of same, I'd rather not confuse the topic - unless required.
Dialogflow refers to these as session entities, since they are Entity Types that contain values that you set during a session, and that only maintain those values for that user during that session.
You can access them using a REST endpoint for the session entity types, or use one of the client libraries that can provide access.
However...
While this has worked fine in the past there seem to be some problems currently with Session Entities. (That SO question does provide some code and examples, so you may want to take a look at it anyway in case it does work for you.) This is opened as a bug in their issue tracker, but there has been no public acknowledgement from Google about it.
I thought I had found the holy grail when I stumbled over PouchDB, a while ago; it allowed me to simply write my code to a local (in-browser) database, and then replicate everything to and from a remote CouchDB without actually having to write a single line of code. (Not entirely true, it is actually a single line of code.)
However, if I use CouchDB as the backend, all users will actually get exactly the same view of the data. That's not all that desirable. I am making an application for different groups of people, and they shouldn't be able to see each others data. Never. Period.
In fact, I'd like to be able to make sure that
Some users only see a subset of the data available
Some users only see a subset of the attributes of the documents
I looked at some CouchDB questions related to this, and having a smart proxy seems to be the way to move forward. But is it really? Are there any implementations of smart proxies like those out there?
Just stumbled across this, the Sync Gateway. That might be exactly what I'm looking for. Would love to hear if there are other solutions though and how to implement one yourself.
I've recently switched to JIRA from another bug tracking system, and previously we were not using the "component" field. The project was pretty small, so it didn't seem to need it at the time. As the project is getting a little bigger, I'm finding that the component field may useful, but I'm not exactly sure of how to split the components.
For example, let's say I have a banking application and I am adding a feature to transfer money between accounts. That feature might be classified as an "Accounts" component, but it also would affect the user interface, as well as have some security issues associated with it. It seems like many issues will have this cross-cutting concern.
Is there a best practice for determining how to divide a project into components? Are things like "User Interface" and "Security" too broad?
I'm not sure this question has a single correct answer, so maybe it should be moved to a community wiki, but any insight people can provide would be helpful here.
Components are most useful if they have obvious default assignees for each one (component leads). Another approach is to wait for a while and use labels. See if there are common labels that your users like to use, and then create components in a few weeks for those labels.
A user creating a bug can add multiple components when reporting the issue. So they could select Account, transfers and security issue (or Loan, Payments, and security issue) as all components effected by a particular bug. Any combination of components can be put together so that the development team knows exactly where this bug is occurring.
We use the component field in our company mostly to cluster the issues in a meaningful way, so that reports to these components may give you feedback which part of your application development gets the most issues, or where the most changes (with the most resulting bugs) are happening. Sometimes, the components reflect the organization of a project, then the aspect of the default assignee is a valid one (as answered by #mdoar). But even then, the overview of the project is the most interesting aspect here.
I am investigating SCORM compliance as an option for a software project I am involved in. If this is too esoteric for SO, I am sorry - not sure where else to turn.
I am a little confused as to how the SCO (Sharable Content Object) reports a quiz score, for example, to the LMS. From what I can gather from the official documentation, this is to be done using using LMSSetValue function in the RTE API object, which is just a bunch of Javascript.
This seems wildly insecure to me, as it takes nothing to rewrite the values passed to the LMS this way.
My question is therefore, am I missing something? Are SCOs meant simply to not report such values to the LMS? It is my impression it is the only permitted mode of communication between SCOs and the LMS.
The JavaScript API is the way data is passed from the SCO to the LMS. Are there more secure ways to pass data? Sure. But the implementation is not brand-spanking new, remember. In addition, because of portability constraints, many of the most highly secure ways of passing data are not available to SCORM developers. Portability was the main priority of the standard, not security. There is a community of experts talking about what should replace SCORM. It's called Project Tin Can. And different ways of exchanging data, including cross-domain and server-side, are being discussed there.