So I got a task to prepare a simple analysis on how useful, from sociometrical point of view, are Slack API methods (https://api.slack.com/methods).
Yesterday I didn't even know that such thing as sociometry exists, and i still dont know how to evaluate any API using its methodology. Does anyone here ever got a similar task, or have any idea how to approach such analysis? What literature will be useful? I don't mean this analysis to be particularly long, but as for now I don't even know where to start.
Frankly, I am not an expert on sociometry , but here is how I would approach it:
I would assume the goal is to create a sociogramm depicting the relationships between all users on a Slack team using the API methods. So the question is how useful the API methods are to achieve that goal.
Slack does not have a "friends list", like Facebook, so you have to come up with your own approach on how to identify relationships on Slack. Slack is a messaging system, so it makes sense to define it based on who is communicating with whom.
Lets define users to have a relationships if they are
direct messaging each other (including groups)
talking to each other in a channel (using the #user
mention)
or just being part of the same channel and talking in the channel
Now to assess the effectiveness of the API methods. The basic approach would be to retrieve the messages of a public channel with channels.history (or im.history for direct messages, groups.history for for private channel and mpim.history for direct messaging channels with multiple participants) for a given time period. In addition you can retrieve the members of a channel with channels.info (or their pendants for the other channel types). Then you would parse all retrieved messages and the member list of a channel to identify the relationship and calculate the sociagram.
However, Slack will only allow users to access channels, that they are members of. That includes access through the API and that includes users with the role admin and owner.
So its not possible to see all direct messages, groups chats and private channel of a Slack team through the API and we would therefore need to limit the approach to public channels and some private channel. Depending on where most of the conversation is happening on a specific Slack team and which private channels our slack user is a member of this could significantly limit the ability to calculate a complete sociogram.
In summary you can use the API methods to calculate a sociogram for your Slack team based on which users users are communicating with each other. But that analysis will not be 100% complete, since its not possible to access all private communication on a Slack team though the API. The calculated sociogram might still be useful though, if the Slack user doing the calculation has access to all relevant private channels.
Related
I work in a large enterprise where multiple teams are developing Lex bots (on separate accounts). Each bot supports a different domain or application,. In some cases, it would be nice for a single user interface to ask a question without needing to know which bot to ask. Is there a way to federate bots, or to forward un-recognized intentions to 'backup' bots?
I feel like what I really want to do is treat each bot as a skill is treated in Alexa, except I'm in the position (through entitlements) to know which 'skills' would be appropriate for a given user.
The answer here is that you would need to develop a custom application that delivers a user's input to each of your company's array of bots.
You'd need to look at the NLU Confidence score from each Bot's response to decide which response is the most accurate to return to the user. Would also be worthwhile keeping some state in your app to remember which Bot the user is currently interacting with and defaulting to that Bot for successive user inputs. Should you reach a point where the confidence score is low, it might present a signal to you to test the user's input across the other Bots.
What you'll need to be aware of here is that your costs will increase with each additional Bot that you add. So, assuming you have 5 area-specific Bots, one inbound message from your user could result in 5 Lex calls. As you start moving into significant volumes of interactions, this could start proving to be an obstacle.
An alternative would be to use a custom fallback intent to invoke a Lambda function that calls your Bot orchestration function. Assuming that you're able to find the correct Bot to handle the user's query, you'd need to remember that so succesive messages now get routed to that Bot.
In the past I was reading a list of plans of current user with this REST call of the beta-API:
https://graph.microsoft.com/beta/me/plans
In July 2017 the planner API was released and there are also some minor changes to the endpoints, so the REST call in the V1.0-API now is:
https://graph.microsoft.com/v1.0/me/planner/plans
Unfortunately I do not receive all my plans with that endpoint. Apparently I only get plans that exist for a long time, but any newly created plans are not visible. I tried a lot of actions on my plans like subscribing to, assigning tasks to me, favorize the plan in planner hub, making a plan public or private, but nothing helps, new plans remain invisible in the API.
Can anybody explain what the new endpoint exactly does? The documentation for List plans is not very helpfull.
Can anybody explain how I can a list of all plans (title and id) that I am owner or member of?
The only work-around I have found so far is:
1) Read all unified groups
https://graph.microsoft.com/v1.0/me/memberOf/$/microsoft.graph.group?$filter=groupTypes/any(a:a eq 'unified')
2) for each group: read the planner plan for that group
https://graph.microsoft.com/v1.0/groups/<id>/planner/plans
But that would require one request per group, makeing performance horrible on tenants with dozens of groups.
This API returns plans that have been shared with the current user. Plans can be shared with a user by adding the user's id to sharedWith property of planDetails (Edit: currently users do not have permissions to add or remove others from this list). This is a separate set of users from group membership and does not allow access to data for shared users. Instead, the users will have access if they are group members, and lose access if they are removed from the group.
More information and a sample for updating plan details can be found here.
Additionally, you can submit feedback about the API (and other Planner functionality) here.
Can you explain some mechanisms of privacy in Hyperledger Fabric v1.0 - those already implemented and those planned to be implemented in the future?
I understand channels are like seperate blockchains. I also went through the document on https://jira.hyperledger.org/browse/FAB-1151, where I have found two more mechanisms: one is private data, and other is encryption. Can you explain what would be the beast approach to use in the following scenario.
Each car needs car insurance. Let's say the owner of the car wants to change his insurance company. He signs the contract with new insurance company. Let's say there is also a regulator. The new insurance company informs the regulator about the new contract. The regulator then informs the old insurance company that the car is no longer insured there, but does not inform them about the name of the new insurance company. So we have assets that are shared in the network, but also some private data which only some participants can see. I am guessing this is one chain, so the use of multiple channels makes no sense here.
I do not completely grasp the concept of private data. Is that data supposed to be private only for one peer / company, or can it be shared between multiple companies, but not all of them? Is this the way to go in the scenario? What would be different reasons / use cases to use encryption vs. private data? What mechanism should be used in the described scenario?
First of all, these two concepts of encryption and private data are not mutual exclusive, the intent is to being able to use them both.
The concept behind having private data is to keep certain data keys out, to prevent them to being sent to the orderering service and to distribute them separately across the peers via gossip.
Now, the encryption needed to divide private data into portions which will be encrypted according to the visibility rules, e.g. to allow to read and see the relevant portions of the data to only involved parties.
With all that said, please note that FAB-1151 is still under development/design process and to be added post v1.0 of Hyperledger Fabrics.
I am developing an ios app like Tinder. Users can chat only in private 1:1.
Should I have to open one channel for every single "match"? Is this the correct design pattern for this case study? What about performance if i have one channel per "match".
*Match" is when a user matches to another and can start a private chat.
If one person can have multiple matches, you can ask PubNub client to open separate channel for each nothing person. So, when you have two matching persons, you take some unique identifiers from both of them and using known algorithm create unique name of the channel for which both clients will subscribe to communicate.
One channel for whole application - really bad idea, because of possible massive flow of data, which for most of subscribers will be useless, because consumer is one of other subscribers.
Yes, the best approach is that every "match" should have it's own channel on which both participants publish/subscribe to communicate. PubNub has no limit on channels (nor does it charge based on channels), so this shouldn't create a performance or cost issue.
To add access control to the "match" channel (if you want to ensure no one else can access that channel), use PubNub Access Manager, documented here: http://www.pubnub.com/docs/javascript/tutorial/access-manager.html (use dropdown to change programming language)
If you want to provide chat history, so that the two participants can see messages from previous chat sessions, enable PubNub Storage & Playback, and use the PubNub.History() API, documented here: http://www.pubnub.com/docs/javascript/overview/storage-playback.html
If you want to see when those two participants are connected to the Match channel, use PubNub Presence, documented in the same place.
I've been looking at the APIs for UPS, FedEx, USPS, etc, and I can't seem to find any method of pulling all tracking info for a given user. I only see methods that pull info via a tracking number. Has anyone been able to find a way to get at this data? Seems silly to me that these huge carriers wouldn't supply this info in an easy method.
I'm trying to accomplish this in Rails.
We were able to integrate with UPS Quantum View and even with FedEx Insight. These services will give you a list of all inbound and outbound shipments that are billed to your UPS/FedEx account. You can get info on every piece of each shipment: tracking numbers, weight, shipper and recipient info (Company name, city, state, country).
To pull information from UPS Quantum View using their API you will need to obtain a so-called Access Key, and you'll need to create Subscriptions: one for inbound shipments, one for outbound ones. This can be done on ups.com if you already have a UPS shipping account. You don't have to wait, it's provided instantly. We have a video of how to get the key and set up the subscriptions. It's on easytag.net in the Help section. The video title is Obtaining a UPS Access Key.
When creating API requests to UPS, you'll need to include a key and a subscription name.
UPS has a Quantum View API. Quantum View is their service that allows tracking, etc by account, not just individual tracking number. I assume that will get you what you need. I don't have an account so I can't see their detailed API documentation, so I'm just guessing.