Valence allows to do this, but I wondered if there's limitations to trying to automate user account setup and enrollment in this way. We're a relatively small institution with hundreds of enrollments perhaps in a given term scattered over several weeks, so I don't think there'd be a problem with realtime events. But I wondered what the implication might be for a larger university that might have thousands of enrollments updating all the time. There'd be spikes of activity certainly as a term reached official start.
The issue of performance is a complex one, with many inter-dependant factors. I can't comment on the impact of hardware hosting your back-end LMS, but obviously, higher-performance hardware and network deployment will result in higher performance interaction between clients and the LMS.
If your needs are "hundreds of creations scattered over several weeks", that is certainly within comfortable expected performance of a back-end service.
At the moment, each user-creation request must be done separately, and if you want to pre-provide a password for a user, then it takes two calls (you can, in one call, nudge the LMS to send a "password set" email to the new user, but if you want to manually set the password for the user, you have to do that in a separate call after the user record gets created). The individual calls are pretty light-weight, being a simple HTTP POST with response back to provide the created user record's details.
There are roadmapped plans to expand support for batch operations, and batched user-creation is certainly a logical possibility for improvement.
Related
In our company, we want to develop a simple feature flag system to work beside our API Gateway. Since we expect not more than 100 req/s on the system we decided that third-party solutions will probably be costly(as they require time and effort to understand) and also it would be a fun effort to do it on our own. Here are the requirements:
We have the list of users and the latest app version they are using. We want to apply three kinds of policies on their usage of the some application feature:
Everybody can use the feature
Only users with a version higher than a given version can use the feature
Some random percentage of users can use the feature( this is for A/B testing in our future plans)
These policies are dynamic and can change (maybe we want to remove the policy or edit it in the future)
So, the first problem is how to store the policies ?
I think We can describe each policy with at most three fields: feature , type , and specification . So for instance something like A 2 1.5 means that feature A is only active for users who use version 1.5 or above. A 3 10 means activate feature A for 10 percent of users at random and finally A 1 means that feature A should be active for all uses.
Although in this way we can describe a policy in a meaningful matter, I can't see how I can use these in a system. For instance, how can I write these policies in an RDBMS or in Redis for instance?
The second problem is how to apply these policies in the real world. In our architecture, we want each request to first visit this service, and then(if authorized) it can proceed to the core services. Ideally, we want to call an endpoint of this service and the service returns a simple yes/no response(boolean). For simplicity lets assume we get a user id and a feature like 146 A (users 146 wants to use feature A), we want to determine whether 146 is allowed to use it or not.
I thought of two approaches, first is real-time processing: as a request comes, we do a database call to fetch enough data to determine the result. The second approach is to precompute these conditions before hand, for instance when a new policy is added we can apply that policy on all user records and store the results somewhere, in this way, when a request comes, we can simply get the list of all features that the uses has access to and check if the requested feature is in the list.
The first approach requires a lot of DB calls and computation per each request, and the second one is probably much more complicated to implement and needs to query all users when a new policy is added.
These are our two main problems, I tried to simplify things so that it could become a more generic problem. I would appreciate if you could share your thoughts on each of one them.
I'm developing an iOS app that sends notifications to individual groups of users. Number of users per group will most likely be in the order of 1-7, but can exceed that and while the app generally doesn't set a limit, I hardly see it exceeding 20.
Currently I've set it up with the topics approach and it works like it should. I understand this approach is optimized for throughput rather than latency, as opposed to device groups.
Nearing completion of my app, I'm considering to change to device groups. However, I don't see many advantages, especially considering the substantial complexity that comes along with it.
Notifications at the moment is fast enough. As long as delivery time doesn't suddenly increase by a lot, it's perfectly fine at the moment.
How secure are topics compared with device groups?
The app does allow the user to use more than one device, but I don't see that happening often - realistically quite seldom. However if that were to happen, device groups would handle it better. Still, I think it's an acceptable compromise to stick with topics.
For device groups to work, I have to create a new collection server-side to manage device registration tokens and their updates, pairing with my existing data structure and implementing several http requests. I also need to query for the notification_key every time I want to send a notification, instead of sending it to the more obvious id I now use for topics.
I've read through other questions on SO, but wanted to get some fresh thoughts on this. My opinion is to stay with topics unless convinced otherwise
I'm using both of these delivery methods and yes, topics are far easier to manage but that comes at a cost of security. If your groups are public in nature then you should be fine with topics. If they're meant to handle more sensitive/private information you should probably go with device groups / individual tokens. Reason being, topics are more public facing and anyone can listen in on them, even devices not on your app.
I am trying to build an offline synchronization capability into my iOS App and would like to get some feedback/advice from the community on the strategy and best practice to be followed to do the same. The app details are as follows:
The app shows a digital catalog to users and allows them to perform actions like creating and placing orders, among others.
Currently the app only works when online, and we have APIs for all actions like viewing the catalog, creating/placing orders which return JSON data.
We would like to provide offline/synchronization capability to users, through which users can view the catalog and create/place orders while offline, and when they come online the order details will be synchronized and updated to our server.
We would also like to pull the latest data from the server, and have the app keep itself up to date in case of catalog changes or order changes that happened at the Server while the app was offline.
Can you guys help me to come with the best design and approach for handling this kind of functionality?
I have done something similar just in the beginning of this year. After I read about NSOperationQueue and NSOperation I did a straight forward approach:
Whenever an object is changed/added/... in my local database, I add a new "sync"-operation to the queue and I do not care about, if the app is online or offline (I added a reachability observer which either suspended the queue or takes it back working; of course, I do re-queueing if an error occurs (lost network during sync)). The operation itself reads/writes the database and does the networking stuff. My ViewController use a NSFetchedResultsController (with delegate=self) to get callbacks on changes. In some cases I needed some extra local data (it is about counting objects), where I have used NSManagedObjectContextObjectsDidChangeNotification.
Furthermore, I have used Multi-Context CoreData which sounded quite reasonable to use (I have only two contexts).
To get notified about changes from your server, I believe that iOS 7 has something new for you.
On the server side, you should read a little for the actual approach you want to go for: i.e. Data Synchronization by Dan Grover or Developing Android REST Client Applications (of course there are many more good articles out there).
Caution: you might be disappointed when you expect an easy solution. Your requirement is not unusual, but the solution might become more complex than you expect - depending on the "business rules" and other reasonable requirements. If you intelligently restrict your requirements you may find a solution which you can implement yourself, otherwise you may also consider to use a commercial product.
I could imagine, that if you design the business logic such that it takes an offline state into account and exposes this explicitly in the business logic, you may find a solution which you can implement yourself with moderate effort. What I mean by this is for example, when a user creates an order, it is initially in "not committed" stated. The order will only be committed when there is access to the server and if the server gives the "OK" that this order can actually be placed by this user. The server may also deny the order, sending corresponding messages to the user.
There are probably quite a few subtle issues that may arise due to the requirement of eventual consistency.
See also this question which contains pointers to solutions from commercial products, and if you visit their web sites give valuable information about the complexity of the problem and how this can be solved.
I am using Rails 3.1.0 with Devise 2.1.0. I would like to limit the number of times a user can perform an action in a day. The main purpose of this limitation is to prevent spam.
I see many questions similar to this one but was wondering if there is a specific way to accomplish what I am trying to do through Devise.
For the actions that create model instances, the number of times an action has been performed in a day is easy to keep track of. However, at least one action that I would like to restrict does not create a model instance, so I'm not sure what to do about it.
I was also wondering if this is a legitimate/effective way of preventing spam (in addition to requiring users to register and sign in to perform the actions).
Personally, I find these sorts of systems to be over-complications. Unless spam is an existing, provable problem I'm not sure adding in a system that's likely to be rather extensive is a good use of time and energy.
Alternatives to this would be requiring registration through a third-party service (say Facebook) and using either captchas or exciting and new negative captchas.
That said, if you want to do this, I think the best place to keep track of it would be in an ephemeral data store. Redis would be really good for this since you can use queues. In the actions that you want to restrict, add a timestamp to the queue, and before you allow the user to perform said action, check the number of elements in the queue, purging ones that are too old while you do so.
That's sort of pseudo-codey, but should at least help you get started.
I was wondering what the thinking is in regards to using User Stories to describe automated, scheduled, or reactive functionality. For example, what do you do when you have something like an order fulfillment process which involves pulling an order from a queue, preparing a "fill order form", sending the form to an order processing center, then waiting for some sort of confirmation from the processing center, such as "order fulfilled", or "order fulfillment error: reasons...", etc.. Keep in mind that the only user intervention during this entire process would be when the order was entered. One could always argue that the fulfillment process is something that can be implied from a order entry story, or that it is an implementation detail, but it seems to me that the fulfillment process is too large to simply take it as implied from an order entry user story or as an implementation detail. It feels like there should be a description of the fulfillment itself as a story as well.
Particularly, the aspects that interest me about writing a user story for automated, scheduled, or reactive functionality is from whose perspective should it be described? Given that we are using a story format like "As a [role], I want [functionality] so that [purpose]", what is the role in the "As a [role]" part of the story, and what is the purpose in the "so that [purpose]" part of the story? The functionality is usually clear enough but the role and the purpose seem a bit relative. For example, I could use the system as my point of reference and write something like "As the Order Fulfillment System/Agent, I want to be able to pull an order from the fulfillment queue, prepare a fill order form, and send it to the order processing center so that the order can be fulfilled". Or alternatively, I could look at things from the business's point of view and write something like "As an order taker, I want to be able to process the orders that are entered by customers so that I can fulfill my responsibility to my customers and give them what they want" (or something along those lines). However, I could also write this from the perspective of the customer and say something like "As a customer, I want to my order entry to be processed/fulfilled so that I can receive the things that I want".
I realize that there may not be one ultimate answer as to whose perspective is the valid one or more usefull one. I'm sure I will get a lot of "it depends" replies. Nonetheless, I would be very interested in hearing about what others have done in situations like these, or if anyone knows of any recommendations, guidance or practices specifically for these types of scenarios.
It might help to move away from the traditional user story template and towards the stakeholder-focused format of Feature Injection (BDD in the analysis space):
In order to <achieve a goal>
As <the stakeholder>
I want <someone to do something for me>.
You can work out who the stakeholder is by thinking about who would be willing to pay for the story to be delivered. For instance, CAPTCHA boxes - those annoying things users have to fill in - are done for a moderator's benefit, or to make the site more attractive to gain revenue, and not for the user's benefit at all! In fact, when you think of most sites, applications, etc., they're hardly ever done for a user. Most websites are about advertising revenue. Most enterprise applications involve one department entering data so that another department can use it, or so that money can be taken from customers.
When you do this, it becomes more obvious that there might be more than one user involved, and a user might be another system. In your case I'm guessing that some kind of sales head is the main stakeholder for this story.
In order to make sales
As the Sales Head
I want customers to be notified of any errors with their order.
In order to make sales
As the Sales Head
I want customers' orders to be fulfilled within 24 hours.
You can see from this that the goals become quite high-level, so if you have a piece of software which plays into those goals, you can break them down:
In order to fulfil customer's orders within 24 hours...
Now every story can be traced back to the project vision, and you can see all the systems in play. So your automated scenarios might read:
Given a valid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds successfully
Then the successful fulfillment should be logged
And the customer should be notified by email.
Given an invalid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds with an error
Then the error should be logged
And the customer should be notified of the problem by email.
For instance.
By the way, if you're thinking of moving to this format now, be aware that the transparency it creates can cause absolute havoc with people who are, say, developing because they've got the budget, and not a proper project vision. I think this is a good thing. Others find the politics less comfortable! Good luck, whatever you decide.