I am using linkedin-j for fetching linkedin data
Set<NetworkUpdateType> set = new HashSet<NetworkUpdateType>();
set.add(NetworkUpdateType.SHARED_ITEM);
Network network = client.getNetworkUpdates(set);
and it returns only 10 my own network updates. How to get all the public updates (not necessarily my own network connections) using these linkedin apis?
Try like this,
Set<NetworkUpdateType> set = new HashSet<NetworkUpdateType>();
set.add(NetworkUpdateType.SHARED_ITEM);
Network network = client.getNetworkUpdates(set,1, 50);
Here First argument is START and second argument is END.
So you will get 50 results.
Total :102
Start :1
Count :50
You can iterate over Total. :)
You can get your updates and updates of your first degree connections using the LinkedIn APIs, but you cannot get all updates across all people.
Related
I've had an analytics reporting API running for a while now and unfiltered view results from the API match the web reporting. The issue I'm seeing is when adding a segment to the API report request. The web reporting is frequently returning different values than the API for a handful of the segment/view_id combinations. I'm looking for a recommended settings to review here to understand what is causing the discrepancy, as I'm not sure if this is an program code/API issue, web reporting issue or a configuration for segment/view_id issue.
Notes:
When incorrect, it appears that the web reporting numbers for sessions is averaging 10% higher than what the API returns
A single segment is applied to many view_ids we manage and a high percentage (~80%) are showing the discrepancy, the remainder match.
the modified and created dates for this segment are 5 months old per the web interface, meaning there is not a configuration change within the segment causing the discrepancy
we've compared 2018 YTD to eliminate a time lag data update as an issue.
segments appear to be link to our master account level and applied to the accounts we manage.
currently using v4 of the analytics API for .Net (C#)
Current Questions:
Could this be a setting in how a particular segment was created?
Why would some segment/view_ids match and others not?
Is there a account, property or view_id permission/configuration setting to review as it relates to applying segments?
Any help or insights on what to review here would be helpful.
Forgot the code snippet:
var segmentDimension = new Dimension { Name = "ga:segment" };
var DefaultReportRequest = new ReportRequest
{
DateRanges = new List<DateRange> { dateRange },
Dimensions = new List<Dimension> { date, SourceMedium, Campaign, AdContent, Keyword },
Metrics = new List<Metric> { sessions, Users, NewUsers, Bounces, pageViews, SessionDuration, Goal01Completion, Goal02Completion, Goal03Completion, Goal04Completion },
ViewId = v_id,
PageSize = 10000
};
if (!(segmentId == ""))
{
DefaultReportRequest.Dimensions.Add(segmentDimension);
Google.Apis.AnalyticsReporting.v4.Data.Segment segment = new Google.Apis.AnalyticsReporting.v4.Data.Segment() { SegmentId = segmentId };
DefaultReportRequest.Segments = new List<Google.Apis.AnalyticsReporting.v4.Data.Segment> { segment };
};
var getReportsRequest5 = new GetReportsRequest
{
ReportRequests = new List<ReportRequest> { DefaultReportRequest }
};
var batchRequest5 = reportingService.Reports.BatchGet(getReportsRequest5);
var response5 = batchRequest5.Execute();
Thanks in advance for your help,
Mike
Update 2:
After reviewing this further the API call is always pulling a single day of data "Yesterday". The web reporting when pulling that single specific day of data matches. If the web reporting pulls a time range of data around those specific dates (ex: +/- 3 days) the numbers no longer match. It seems like sampling could be in play here, but the web reports we are running indicate 100% of sessions in both pulls. I think the question is how to determine which is more accurate a single day or a time range of data. Has anyone investigate this, I've reproduced it on several of our view_ids.
Thanks,
Mike
Update 3 (rseolution):
Turns out the issue was with how the segment was created and being applied to web reporting. The segment was focused at the User level, meaning aggregated values would change based on the time frame selected. The desired state was having the filters apply to a single day, making session focus a better then user as it contained the segment to the session.
Thanks all,
Mike
Without knowing too much about the details of the segments and views, the first thing I'd like to confirm with you is that you're aware of sampling in GA.
Unless they're all 360 accounts, you'll be subjected to sampling depending on the sessions you're returning for 2018 YTD. Note, sampling is based on sessions on the property level, not view level.
Another thing you can do in your code is to check if the sampling of the % of data matches with the web version VIA the response from the API. On the web version, the sampling info is here:https://i.stack.imgur.com/hcPGD.png
I am able to successfully retrieve messages from a channel via channels.getMessages request, once I know their message IDs. I find channel id by contacts.search, by the way.
At the moment, mesage IDs are consequtive integers, so getting max_id would solve the issue.
I am sure it possible, since official clients do this (view a channel without joining it). I will try to find out how official desktop app does this by reading its sources, but any help will be much appreciated.
I need this because am writing a simple public telegram channel -> rss/web interface.
Please do not confuse Telegram Client API with Telegram Bot API. Bot API allows to receive 'push' messages on new messages, but no 'reading historical logs'.
Here are the steps you have to do in order to get messages from a channel you're not joined:
Resolve the username into ID and access_hash with contacts.resolveUsername
Invoke messages.getHistory to get your desired messages
Here is a short description of messages.getHistory parameters:
peer: The channel from whom to retrieve the message history
limit: Number of messages to be retrieved
offset_date: Offset date (messages *previous* to this date will be retrieved)
offset_id: Offset message ID (only messages *previous* to the given ID will be retrieved)
max_id: All the messages with a higher (newer) ID or equal to this will be excluded
min_id: All the messages with a lower (older) ID or equal to this will be excluded
add_offset: Additional message offset (all of the specified offsets + this offset = older messages)
It turns out messages.getHistory is just okay, gives you last N messages + total count.
Following are the steps
Create a Person and add Face
Like to register person details and ensure the Face Id is persisted
Step 1. faceServiceClient.CreatePersonGroupAsync(groupId, groupName);
Step 2. p.PersonId = _faceServiceClient.CreatePersonAsync(groupId, p.Name).Result.PersonId;
Step 3.
var persistPersonFaceID = _faceServiceClient.AddPersonFaceAsync(groupId, p.PersonId, fStream).Result.PersistedFaceId;
Step 4. _faceServiceClient.TrainPersonGroupAsync(groupID);
Now, like to authenticate a person using the Image provided
Step a
var DetectedFaceID = _faceServiceClient.DetectAsync(firstFilestream, true, true).Result.FaceId;
Step b..
var res = _faceServiceClient.VerifyAsync(persistPersonFaceID, DetectedFaceID).Result;
On the call to VerifyAsync, It throws and error like following
{"error":{"code":"FaceNotFound","message":"Face '7a89ace1-a4b7-4c08-b718-4fec0e9e89d5' is not found."}}
Please do let me know if any of the above needs to be corrected
Possible Issues:
A persistPersonFaceID belongs to a group and I am trying to compare the face id which was retrieved by using Detect. If this is a problem, can you please suggest a resolution
/verify only takes faceIds currently, not persistedFaceIds you're getting back after persisting to a person object.
If I've understood your scenario correctly, you can use either /findsimiliars or /identify since you're persisting the known face.
With /identify you'd pass in DetectedFaceID and specify the groupId (API reference for /identify)
Adding this support for verify is something being planned and if you wouldn't mind I'd encourage you to add some votes to it on uservoice: /verify should also take persistedFaceIds
Firefeed is a very nice example of what can be achieved with Firebase - a fully client side Twitter clone. So there is this page : https://firefeed.io/about.html where the logic behind the adopted data structure is explained. It helps a lot to understand Firebase security rules.
By the end of the demo, there is this snippet of code :
var userid = info.id; // info is from the login() call earlier.
var sparkRef = firebase.child("sparks").push();
var sparkRefId = sparkRef.name();
// Add spark to global list.
sparkRef.set(spark);
// Add spark ID to user's list of posted sparks.
var currentUser = firebase.child("users").child(userid);
currentUser.child("sparks").child(sparkRefId).set(true);
// Add spark ID to the feed of everyone following this user.
currentUser.child("followers").once("value", function(list) {
list.forEach(function(follower) {
var childRef = firebase.child("users").child(follower.name());
childRef.child("feed").child(sparkRefId).set(true);
});
});
It's showing how the writing is done in order to keep the read simple - as stated :
When we need to display the feed for a particular user, we only need to look in a single place
So I do understand that. But if we take a look at Twitter, we can see that some accounts has several millions followers (most followed is Katy Perry with over 61 millions !). What would happen with this structure and this approach ? Whenever Katy would post a new tweet, it would make 61 millions Write operations. Wouldn't this simply kill the app ? And even more, isn't it consuming a lot of unnecessary space ?
With denormalized data, the only way to connect data is to write to every location its read from. So yeah, to publish a tweet to 61 million followers would require 61 million writes.
You wouldn't do this in the browser. The server would listen for child_added events for new tweets, and then a cluster of workers would split up the load paginating a subset of followers at a time. You could potentially prioritize online users to get writes first.
With normalized data, you write the tweet once, but pay for the join on reads. If you cache the tweets in feeds to avoid hitting the database for each request, you're back to 61 million writes to redis for every Katy Perry tweet. To push the tweet in real time, you need to write the tweet to a socket for every online follower anyway.
I've run into a problem where a call to https://localhost:8080/alfresco/service/api/people is only returning the first 5000 users.
I can't figure out how to get the rest out of the system--that API doesn't appear to support a "skipCount" argument.
I thought that I might be able to get at least a list of the usernames by using the WebDAV URL (https://localhost:8080/alfresco/webdav/User%20Homes/) to get the list, but that also only returns the first 5000.
So, how do I get the list of users from 5001 onwards?
there is a maxResult param you can give.
for e.g. https://localhost:8080/alfresco/service/api/people?filter=*&maxResults=10000
If you look at this JIRA ticket, you'll see that when you supply a * in the query it will search through SOLR and when you don't it'll search the DB.
If you look at the JAVA code beneath:
public PagingResults<PersonInfo> getPeople(String pattern, List<QName> filterStringProps, List<Pair<QName, Boolean>> sortProps, PagingRequest pagingRequest)
{
ParameterCheck.mandatory("pagingRequest", pagingRequest);
There is a PagingRequest which you can supply, so you could page that you need the rows/results after 5000.
Still you'd need to make a Java-Backend Webscript which retrieves the result.
---UPDATE---
In the org.alfresco.repo.jscript.People there is a maxResult:
private int defaultListMaxResults = 5000;
If you look a bit further then this class is initiated in the script-service-context.xml.
So just override the bean peopleScript and set the defaultListMaxResults to a higher nr, restart Alfresco and it should work.