How are we supposed to paginate through the venuehistory (https://developer.foursquare.com/docs/users/venuehistory) endpoint? In the docs, it mentions two parameters, beforeTimestamp and afterTimestamp, but the result set contains no reference timestamp points to paginate from. Am I missing something?
Background
I'm testing currently testing on an account with 22 items, so perhaps the pagination hasn't kicked in yet, but it would still be nice to cover this scenario. Thanks!
/users/venuehistory returns the user's whole venuehistory, so typically you do not need to paginate it. The beforeTimestamp and afterTimestamp are used if you want to only show history from a certain time period (such as only showing check-ins in January, for a calendar view of check-ins).
Related
I see that there is no pagination in most of the Circuit API.
One example is: GET/conversations/{convId}/messages/flag
Does that mean that I will always get all the messages at once? Is there any plans to add pagination to the UPIs?
Some of the endpoints do offer pagination but in the way that you have to specify a timestamp and a number of items to retrieve. For example GET /conversations or GET /conversations/{convId}/items can be paged in that way.
For the flagged items pagination support is currently not available due to the fact that the backend offers all available flagged items at once. We know that this is not very optimal atm and we are planning to fix such issue in a new version 3 in the future, but that may take some time until the release.
I'm selling shirts on my website, and I want to add a countdown timer to the page to show how long left customers have to pre-order the shirts (only taking orders until a specified date when I'll manually shut off ordering from the Shopify backend).
I'd like to know if there is a way to accomplish outputting just the correct days/hours remaining to markup via some math operation (or other built-in function) in liquid? I'd prefer not to use a javascript based solution because I want a load of this operation to be on the server, not the front-end.
My end goal is to end up with something rendered that looks like this:
<p>You have <strong>14 days</strong> left to pre-order.</p>
...where the content inside the <strong> tags is generated by the function and shows days only until the last 24 hours when it would show hours remaining.
Is this possible with liquid? Would accomplishing with javascript actually be a better choice?
Site for reference: http://devtees.com/
It’s not that it isn’t possible in liquid due to syntax reasons, but I don’t believe that the variables you’re looking for exist in Shopify.
You’d probably need to create a custom variable (a 'metafield') for the deadline date, in which case you wouldn’t be able to filter it using liquid’s date filters (because the liquid doesn’t know it’s a date — it just sees it as a string). So you wouldn’t be able to affect the formatting, count down, etc.
Learn more about metafilters: http://docs.shopify.com/themes/liquid-documentation/objects/metafield
An alternative approach might be to leverage some combination of a metafield specifying the “last day to order” and toggling of the product’s availability. With that method, you could achieve something similar to the way Cotton Bureau shows the pre-orderability of their t-shirts.
Learn more about product availability: http://docs.shopify.com/themes/liquid-documentation/objects/product#product-available
I'm trying to query Picasa Web Albums to pull album/photo data (obviously!) however initially I only need to pull the first 4 photos. Is there any way to limit a particular field or specify the items per page?
I've already accomplished something similar with Facebook's Graph API however I'm unable to find anything similar for Picasa. The only items I can find related to limiting the response is specifying which fields, but nothing related to the number of rows.
Use max-results argument. See doc here.
https://developers.google.com/picasa-web/docs/2.0/reference#Parameters
I'm trying to aggregate some information about the kanban states of my user stories. If query a PifTeam item, I get a summarized collection of UserStories associated with it.
Example query:
https://rally1.rallydev.com/slm/webservice/1.40/portfolioitem/pifteam/99999999999.js
However I then have to run a loop on the UserStories collection, individually querying each one to get at the information I need. This potentially results in a lot of web service calls.
Is there a way to return the full hierarchical requirement information in the original pifteam query so that there is only one webservice call which returns all sub-objects? I read the webservice api and was trying to play with the fetch parameter but had no success.
This functionality will be disabled in WSAPI 2.0 but will continue to be available in the 1.x versions. That said, you should be able to use a fetch the fields on story that you need like this:
/pifteam/9999.js?fetch=UserStories,FormattedID,Name,PlanEstimate,KanbanState
Fetch will hydrate the fields specified on sub objects even if the root object type doesn't have those fields. So by fetching UserStories the returned collection will populated with stories, each having the FormattedID, Name, PlanEstimate and KanbanState fields included.
There is no way to do it from Rally's standard Web Services API (WSAPI) but you can from the new Lookback API (LBAPI). The query would look something like this:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/<ObjectID_for_Workspace>/artifact/snapshot/query.js?find={__At:"current",_TypeHierarchy:"HierarchicalRequirement",Children:null,_ItemHierarchy:<ObjectID_for_PortfolioItem>}&fields=["Name"]
Fill in the ObjectIDs for your Workspace and PortfolioItem. The _ItemHierarchy field will cross work item type boundaries and goes all the way from PortfolioItems down through the Story hierarchy down to Defects and even Tasks, so I added _TypeHierarchy:"HierarchicalRequirement" to limit it to Stories. I have specified Children:null which means you'll only get back leaf Stories. The __At:"current" clause get's the current tree and values. Remember, it's the "Lookback" API, so you can retrieve the state of the object at any moment in history. __At:"current" says to get the current values and tree.
Note, the LBAPI is delayed from current values in the system by anywhere from seconds to minutes. Typically it's about 30 seconds behind. You can see how far behind it is by checking the ETLDate field in the response.
Details about the LBAPI can be found here. Note, that the LBAPI is available in preview now for almost all Rally customers. There are still a number of customers where it is not yet turned on. The best way to tell if it's working for your subscription is to try the query.
Let's say user A follows user B, and B follows A. I want to know the exact date A started following B and viceversa.
Is this information stored on twitter? Can I retrieve it using the API?
To clear out: The point of this question is finding a way to know who followed who first.
(I'm assuming both A and B deleted the notification e-mails)
No Ignacio, you can't. You just can know who follows who but not the date the follow started.
Looking at the API, there's is no way, there are two calls to get the followers:
User Methods/statuses/followers
and
Social Graph Methods/followers/ids
Neither of them returns dates or even a serial that would let you see who started following first. Really, there's no indication that twitter is internally storing this information, neither in the API nor Twitter's web interface.
This is a very old question, but perhaps some might be interested to know that while you cannot get the date at which someone started following, you can at least infer an "earliest possible following date" from the fact that the list of followers is ordered according to date, and the fact that follower objects come with a created_at timestamp.
Here's a Python function for calculating an "earliest possible following date": https://github.com/BernhardClemm/twitter-follow-dates
Of course Twitter stores it, because Twitter sorts followers and following lists by the date ;)
It is possible to do this, but impractical. When you call the followers API you can page the results. Each returned object contains next_cursor and prev_cursor items. These refer to the first and last records in the next and previous pages. These values are time based and can be used to calculate the time that the respective users followed you.
It follows that, if you set the page size to 1, you can walk through the list of follower IDs one at a time and the next_cursor value will allow you to derive the follow time for the next record.
This is reasonably simple to implement, however, in practice, you'll very quickly hit Twitter's API rate limit.