I know I can get the courses the user has, but I want to know where the user is at this moment - clicking the link to our external application. I'm building on the Getting Started example in PHP, from the valence/desire2learn.com website. We're using d2l for many of the course materials but want to produce some tracking and graphs for students to see. It would involve getting grade info (which I think I can do), having students enter hours of study (in our application), storing that information and returning a graph comparing course grade and study hours over the course. It would be much better to automatically pick the right course than to have the student pick the right course.
Can it be done (obtain which course the student's in at the time the link is clicked)? In addition to the annoyance of having to pick which course, it's possible that students are taking more than one course at a time where the teacher is using this tool.
Thanks in advance for your assistance.
If you use LTI v1.0 (Basic LTI) to build the link to launch from D2L to your external application, then the LTI context passed to your application will contain a context_id property: the value of this property will be the org unit ID that identifies the D2L organizational unit for the launch point's context (in this case, the ID of the course offering). Note that until LE v10.2.0 SP1, D2L won't send along the context_id for the top org level, but if the user launches an LTI link from a course offering context, you should get the org unit ID for the course offering.
Related
I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
i'm looking for some guidance on what the best approach is/ what software I need.
My bf owns a promotional company, books about 15 shows a month and spend a lot of time on his phone, creating event pages, linking up the bands facebook and bandcamp url to events, contacting bands with set times and backline info, etc. I thought I would help him out (and other music promoters that I've talked to) with automating some of these tasks. I know there might be other apps currently out there that have some of these capabilities, but I wanted to create something myself as it be a fun project that I could practice my programming skills(beginner-ish).
The app/bot will act as an assistant. It should be able to create an event, ask for the date and let the user input band names. Maybe there will be a series of check boxes that the user can select whether the band is from out of state(what state), touring, local, EP/album release, etc. Select co-host, location. Then depending on the # of bands and the location it will also generate a set time list, and backline info that the user can copy it and send to the bands(or maybe it will do this automatically, if it has access to the bands instagram or facebook?) Once the user presses done it will automatically create an event page, with date, and all the other info. Under the description of the event page, the app will automatically populate that with info depending on what the user selected. For example if its 2 out of state bands and 2 local bands, then it will write something like: "We welcome our 2 touring friends XX from FL? and xxx from NY? With local support from XX and xx" - something along those lines with a link to their pages.
Maybe in the future the app will also be able to go in and look at the bands facebook pages, go to their events and see what people pressed going/interest in their events, then invite those people to their upcoming show?
How do I get started. Should I use Appium and android studio to develop this app/bot assistant? Is Appium only used for testing? I have some basic programming experience from college and other courses i took, such as Selenium webdriver. More important is this doable or am I setting myself up for failure?
In addition to being a developer, I also am a part-time promoter and perform all of those same tasks that your boyfriend does. If there was some way to automate any of it, I would have done so a long time ago. Unfortunately there is, in my opinion, too much variability between different events, venues, and musical acts.
The biggest time sink for me is tracking down information about each act such as their web site URL, Facebook page URL, Soundcloud profile URL, logo, bio, and photo. (Some of the artists I deal with have a press kit but most don't.) Once the information is compiled, creating the Facebook pages is the easy part.
So, maybe a better use of time would be to create a web form that collects that information from each act and stores it in a folder in a structured way.
I'm working on a D2L add-on right now and trying to retrieve all the courses the current user is enrolled in. The only way I found so far is using the
GET /d2l/api/lp/(version)/enrollments/myenrollments/ call. This works perfectly for a small amount of courses and is extremely slow for more than approximately 50 courses. Is there any better way to retrieve all the enrollments?
Thanks in advance
For end-users, this call is indeed the one intended to address this need. Since a portion of the performance drop may come from having to process a series of data pages (requiring several calls), you can try several techniques to add a bit of performance here:
You can pre-filter the call based on org unit type: this likely requires you as the app developer to know the org unit type IDs for the org units of interest to your end users. For example, if your main use case here is "student wants to see all the course offerings she's enrolled in", then you can provide the appropriate org unit type ID for course offering org units to your API call. This becomes more difficult if your app must address several different back-end services, or you don't know the org unit type ID used by the back-end service for the relevant org unit types.
You can try using an HTTP library that can pool connections, and batch together the calls that fetch all the data pages you need to get the complete list of enrollments needed. This will provide you with some benefit to overhead on each call, but the performance benefit will likely only be marginal.
Currently, this API route does not allow the caller to request a particular data page size, and allowing that would improve the overall latency involved in this use case: for example, requesting a page size of 500 records could conceivably fetch back all the enrollments in a single call. I would judge page-size requesting to be a completely reasonable feature enhancement to request, and I would encourage you to request it on D2L's Product Idea Exchange; in fact, I'd be rather surprised if someone hasn't already done so.
I've been using /d2l/api/lp/1.4/enrollments/myenrollments/ to get a list of enrollments for the current user. Now, I want to just get the enrollments where the user is in an instructor role. So, I'm trying to use:
/d2l/api/lp/1.4/enrollments/users/{userId}/orgUnits/?roleId=105
When I use that, I get an empty list of Items back, with or without the roleId specified.
My expectation is that just calling it without the roleId would return the same list as /d2l/api/lp/1.4/enrollments/myenrollments/. But, I always get an empty list, except when I log in as a system administrator. Only in that case do I get anything back.
Does anyone have any suggestions on what I might be doing wrong?
The various my* API calls specifically exist to provide end users to fetch back details about the system that they should know, but segregated from information they shouldn't (that's available through the more general routes for a particular area). Enrollments is a good example of this. And end-user should be able to see their own enrollments, but they should not have generalized access to enrollment records. In particular, the D2L system treats the D2L user role belonging to an enrollment as fairly privileged information, and a side effect of this is that it's not generally visible to end users.
One way that applications and services can cope with achieving goals that the end-user cannot themselves perform is to have set up a "service account" that the app can use to make calls of an administrative nature, to fetch back data that they can use in the business logic around presenting information to end users. In this particular case, you could, for example use the service account to make calls about a user's enrollments, and then present the user with logic that could filter the list of their enrollments by "these are the student ones, and these are the ones where you're a teacher, and a tutor, and so forth".
But you'd also need to carefully consider the implications of this type of activity in balance against the intentions of the client LMS's policies and administration. Even this level of information may be giving away too much to end users, in the eyes of a client LMS administrator.
Using a service account to let an app make administrative level calls must always be done with great care around the issue of information/functional leakage to end users.
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.