China WBI

This release iteration saw some significant work done, and as feared, it took much longer than expected. Were I in a real-world “industry” scenario, the client would be pretty unhappy, so I would have been probably forced to scale back on features. Or work crazy hours.

Luckily, I am a patient, forgiving client as well as a bad-at-ASP-estimates programmer.

How could I improve the scope of the next iteration? Well, I tried breaking things down last time in the stories. Turns out that I need to go a step further with this, so that the stories are truly bite-sized.

The good news is that I only have one story that I couldn’t complete for 0.1.7, which will go into the next:

• Delete an existing study group. Students in that study group should automatically be moved to the Unassigned study group. The Unassigned study group should not be deleted.

I’m debating whether this should be split into two stories, but I will save that as an exercise for release 0.1.8 planning. For now, I’m putting the keyboard down and am off to get married!

I was thinking of pushing this story into the next iteration, but since I pretty much knew exactly how I wanted to do it, I felt that it would be better to finish it up before my wedding and honeymoon, since I’ll have forgotten a lot of the context after.

The story was long again, but very similar to adding a user to a course, so I had a pattern to follow which guided me pretty well. The results are below:

I also added a Change Members button to the View Study Group admin page, to complete the circle of references.

This was another longer-than-expected story. I thought I was detailed about my stories, but I think I need to go an extra step deeper on the detail. In this case, I underestimated just the basic setup for a change members page.

First it involves linking to the page from the existing View Class page. Then, on the new page, it needs to show the basic study group and course information, and then also needs to display the current enrollment. I also found that it’s not user-friendly since there’s no way to go back to the class view or the study group view from change members. You essentially hit a dead end, so I made the class name and study group name links that take you back to their respective view pages.

After all the setup, I was able to get the remove to occur. Since I had done a similar thing with removing a student from a course, it was easier the second time around. But I’m leaning heavily toward dropping the last two stories and closing up the iteration.

As you can see, there is a blank space for Members to Add, which I added in anticipation of the Add Student to Study Group story. Looking at the screenshot, I’m thinking right now that I should put the page title above the class and study group links.

Today’s story was to add support for adding a student to a course’s enrollment. This might seem pretty straightforward, except that we also need to add that user to the Unassigned study group.

What I wanted to do was to have the Course table entries also store the ID of its corresponding Unassigned study group, because otherwise I’d have to do a search query on the Study Group table with the appropriate course ID, and also search for the one that was named “Unassigned.” In addition, I would need to restrict users from naming another study group to Unassigned, since it would mess up this query.

A simpler solution would be to record the ID of the study group and put this in the course table when the course is created, since an Unassigned study group is also created at the same time. It took quite a long time to complete… I had to revisit my DB structure and how I was creating courses first, and also correct the previously added test courses so that they were assigned something appropriate.

The hardest part was probably modifying the course adding operation, since I needed to retrieve both the courseID and studyGroupID, both of which are auto-increment, and so have to be discovered after creation.

And all that was just to set things up for adding users to courses. The rest of the way was relatively complex as well. One of the hardest parts was coming up with a query that would give me all the users who were eligible to be added to a course. For example, you shouldn’t be able to add a user to a course twice. So, I basically had to get a list of all the students who were not enrolled in a class.

This is another example of where a lack of SQL experience hurts me — I’m pretty sure there is a query that I could write that would do this, but I ended up, after some frustration, retrieving all the users, then retrieving all the enrolled users, and finally comparing the lists to get the list of unenrolled users. It’s a performance no-no and bad practice, but under my time constraints, it’s good enough and it works!

The final step was hooking the unenrolled list to the ListBox that I had setup, and thankfully that wasn’t too painful. I did implement it such that you could add multiple users at one time, which is helpful for the user.

I spent about 4x the time on this story than previous stories, so I think this iteration is now overbudgeted. I’ll try the next story, but unless that and the following ones are super easy, I’ll probably close this iteration after that story is completed.

Again, I’m going out of order, and doing this primarily because it’s one of the more simpler stories and doesn’t require interaction with any of the other stories.

This was, thankfully, pretty straightforward. I set up a Create Study Group button off of the View Class Info page’s list of study groups. Right now, all that’s involved in setting up a study group is assigning it a name, so the create study group form is very simple:

After the study group is created, you can see it newly created in the study group list for the class, with no assigned students as of yet.

After looking at the various stories that are involved for this release, I decided that I would do them a little out of order — starting with removing a student from a course. The story also required ensuring that the student was also removed from the study group they were in for that course.

This was harder than expected, simply because I am passing in my own DataSource to the GridView, instead of embedding the SQL statement into the ASP control. However, when generating Remove buttons for each GridView entry, I couldn’t use the built-in Delete command button (or at least in a way that I could find), and used a generic Command button instead. The problem, though, is that I wanted to attach the ID of the student that I was removing, which is not the same as the index number of the entry.

I ended up having to find the GridView first, then request its DataSource, and then access the index to find the primary key that I was looking for. It was a lot of trouble for what seemed like a pretty easy thing, so I wasn’t happy with how ugly the code got, but at least we got there. I’m sure there must be a better way, but I couldn’t find it today.

Here are the stories for release 0.1.7. As I mentioned in the previous retrospective, I’m aiming to be more specific in my stories this time.

• Add a student to a class. The student should automatically be added into the Unassigned study group.
• Add a student to a study group. The student can only be added to a study group if he/she is enrolled, therefore the list of possible students to add to a study group are the students who are in the Unassigned study group.
• Remove a student from a study group. When removed, the student should automatically be added to the Unassigned study group. Students should not be able to removed from the Unassigned study group.
• Remove a student from a class. The student should also be removed from the study group he/she is in.
• Create a new study group for the class.
• Delete an existing study group. Students in that study group should automatically be moved to the Unassigned study group. The Unassigned study group should not be deleted.

It’s a good thing I’m being more specific in this iteration, because it’s turning out to be quite a significant amount of work to be done. The last story or two may slip to the next iteration, but for now, I’ll be optimistic and go for it.

This iteration turned out to be much bigger than when I originally planned. Although that’s pretty much the trend in software estimation, I think I am falling into the trap of defining stories for each iteration that are too broad in scope. Rather, I need to break the feature set down into more estimate-able chunks.

One of the reasons this happened was because my overall schedule had me finishing up the course data model by the 15th. It would have been better to either scope requirements so that an acceptable data model was finished by the 15th, or to not be driven too much by that deadline. I am trying to balance making a reasonable implementation, taking time to learn things that would be valuable to learn, and finishing up my project some time in the foreseeable future. I think it’s probably safe to say that I wouldn’t be able to finish up the entire project this semester with my wedding looming near, so I’d rather continue to trudge along and get done as much as I can, but still maintain some minimum level of quality and features for the project.

In the next iteration, I hope to be a little more specific in story planning.

MVP continues to work out very well. Again, my lack of experience in SQL is hurting me a little as I continue on, but I’m surviving so far.

I’m now fully on schedule, though, at least in terms of my release schedule, with 0.1.6 due before the 15th.

I put another story in this iteration for cleanup of the Admin directory, mostly for things that are relics of the previous implementation that needed to be fixed.

One of the major things that needed to be changed was that the ability to delete classes was originally on another form (EditClassInfo.aspx), which needed to be moved to the Admin home page, and also implemented using MVP instead of through the ASP control.

The delete itself, while not totally straightforward, wasn’t that bad to deal with. I realized that actually when a course is deleted, all corresponding user and study group information should also be deleted with it. So this operation actually results now in 3 delete SQL commands.

Finally, I wanted to touch up the UI by including a warning prompt, “Are you sure you want to delete?”, mainly to be nice to the user. This was a lot harder than expected… because somehow ASP doesn’t like javascript calls for its hyperlinkfields. This turned out to be a major, major pain to change, so since I didn’t want to implement a custom control, I am just deleting if the user decides to click on the link without warning. Sorry, user… but under the project constraints, we’ll have to leave it at that.

I just hope this apology doesn’t end up being to myself in the near future!

This story was a little similar to the last — in that I realized I needed an extra view page for the admin section… but in this case it wasn’t as big a deal.

One thing that really helped was that since I already have a View Study Group page implemented with MVP, I was able to reuse 90% of the code — all I really had to do was write another ASP page to fit on top of the existing IView and Presenter. If I hadn’t implemented with MVP, I would’ve had to actually recode the entire page to make another similar one. Another plus for MVP.

I structured the edit class info and edit study group pages in very similar ways. Here is Edit Class Info:

and here is Edit Study Group:

As you can see, there’s not much we can edit on either of these entities yet, but these pages set up the starting point once the models get more complicated.