China WBI

This step wasn’t too difficult, because login and authentication are so central to the idea of a website, and ASP has a nice login control built into Visual Studio.

I created a test user, and then a login page, and a destination page (for now, the profile page). I then added a login control, and made some changes to the default settings:

1. I changed the Username label to Email Address, since that’s what we’ll be using as the username for this website.
2. I added a “Forgot Password” link, which goes nowhere for now, but will I figure will be necessary later. (actually that might be considered a bad thing in Agile philosophy, since you don’t want unimplemented features in there that aren’t specific requirements, in anticipation that they will be later — you never know)
3. There’s already a “Remember Me” checkbox that presumably sets a cookie on your browser so you don’t have to login each time. I left it in there… even though it was part of the requirements (again, bad for Agile)… but at least this time, it’s all implemented automatically by ASP. And plus, I’m the customer too, and I just decided to make “Remember Me” a requirement. So there!
4. I used the auto-format on the login control so that it wasn’t completely ugly. But no worries — I intend to come back later in a future release and revamp the UI.

Login Control

Login Failure

In the process of setting everything up and reading a little bit here and there about ASP’s authentication system, I got some early indications that using an email address as a username was actually not a trivial thing to do. ASP isn’t set up to do this, even though it’s something that many sites do.

I don’t recall the exact reasoning why I wanted to go with an email address as username, instead of another username… the thing is, if a user changes their email address, the username field is a readonly field, so I would have to essentially clone a new user and delete the old account.

This has significant implications, but there are some articles out there dealing with it, since it’s obviously something other people have had to deal with. So I’m not going to worry about for now, and we’ll see how this decision plays out later on.

Aside from college, I haven’t had much database experience, so this component of the project is the part I simultaneously dread the most, but also am excited about learning more about.

Things were pretty straightforward yesterday with the conceptual part, but implementing it today in ASP.NET 2.0 brought about some interesting detours.

First, a great deal of websites out there already need to implement some sort of user account system, and there are actually some built-in features that auto-generate database tables that store user information. I had already known this because of the books I’ve been reading.

What I didn’t know until today, though, is that ASP.NET 2.0 also has a Profile system built into it, which allows the programmer to forego having to setup the profile fields in the database manually and write code to store and retrieve it properly.

This means that I don’t have to try and stuff in the FirstName, LastName, Alias and AboutMe fields into the existing aspnet_Users table (I will use the existing Username field as the email address). Instead, I just define these in the web.config XML file in the root application directory like so:


<system.web>
<profile>
<properties>
<add name="FirstName" type="System.String"/>
<add name="LastName" type="System.String"/>
<add name="Alias" type="System.String"/>
<add name="AboutMe" type="System.String"/>
</properties>
</profile>
</system.web>


You can read more about the ASP.NET 2.0 Profile System here and here.

Second, the ASP.NET 2.0 also has a Roles table, integrated into its own Role system, and since I’m not interested in building my own custom role system or doing anything particularly weird with that, I thought better of adding my own table for Roles. The RoleID is hooked up to the UserID with an join table called aspnet_UsersInRoles, and the RoleID is the primary key for aspnet_Roles.

Visual Studio has a nice database diagramming feature, so I can show my new updated tables without making an ugly drawing, snapping a picture and posting:

Next post: Setup login and authentication.

I haven’t drawn any entity DB diagrams since college, so I had to brush up a little with a few articles.

I’ve drawn some simple diagrams for the DB design, which encompasses the feature set up to 0.1.0. I also threw in a few tables for the Study Group entity, even though that’s not slated to appear yet in 0.1.0. Doing the diagrams made me realize a few things that were missing from the user stories.

First, I realized that I hadn’t thought through carefully about the relationships between some of the entities… for example, the fact that a class could (and should have) several study groups that belong to it, and that the entity that a study group should actually belong to is the class (the course, that is). In the “real world”, the teacher would be creating a class, and then creating study groups for that class, and assigning students to them. Student are only in one study group for a particular class, but their study groups will likely be different in other classes.

Second, just a small thing, but it would be nice if the user had an alias, instead of showing their first name and last name, and/or their email as their username. This should be added into the My Account story.

Ah, feature creep.

I’ve created a new project solution in Visual Studio and put this into my existing SVN source code tree, which I first started when I was working on the riverboat velocity problems. This was pretty straightforward, but I did spend a little time peeking through the different options on Visual Studio — I’ve used VS2005 for just C# and desktop applications (with Windows Forms), so the way the interface and menus are setup for ASP are slightly different. I’ve also set up some of the more administrative things, such as a directory for documentation and release notes in my project folder.

This user story is done now, and ended up taking much less than my pessimistic estimate, so I’ve already started setting up a few things for the site users and authentication. I’ve been using the ASP.NET website admin tool that is accessible through the VS2005 menu for the site. There is a section to create user roles, so for now, I’ve created an Administrator, Student, and Teacher role.

I can also create some test users, but I’ll hold off on that until I have more of a directory structure in place for the site. I’ll be brainstorming and sketching out DB diagrams in the next story.

My advisor has asked me to write a problem statement to help ground my project and define its scope, and especially since things have changed since I’ve started. Here it is…

Problem Statement

Education in China has seen a rapid proliferation of Web-Based Instruction (WBI) over the past decades. The government’s Ministry of Education has instituted far-reaching initiatives for primary, secondary, college, and adult learning, backed by tremendous amounts of capital, infrastructure improvements, and equipment. In many respects, China is following on the heels of a similar massive infusion of web-based tools in Western education.

A large body of research already exists which evaluates the effectiveness of various web-based instructional approaches and explored the successes and mistakes that the “pioneers” of WBI experienced. This has allowed Chinese educators and administrators to take an informed approach to integrating WBI in the Chinese classroom. However, a growing number of researchers are raising important issues about the validity of such research in the Chinese cultural context.

Although there has been significant and illuminating research done in WBI, the large majority of it has been performed in the Western classroom. Additionally, much of the literature surrounding WBI has adopted a constructivist approach. Unfortunately, many researchers have pointed to significant incompatibilities between Chinese and constructivist pedagogy, including the relationship between teacher and student, typical Chinese learning strategies, culturally-acceptable classroom behavior, and the motivation for learning. To date, there has been little research done on web-based instructional tools which are designed specifically to accommodate for pedagogical differences in non-Western cultures.

One of the strongest cultural traits ascribed to China is its collectivism; that is, a strong group focus, and an emphasis on collective, rather than individual achievement. This is in strong contrast to most Western nations, which are highly individualistic. This project is an attempt to create a web-based instructional tool for secondary Chinese students which facilitates their collectivist tendencies, while still fitting in the structure of individual assessment as necessitated by the Chinese educational system. The tool will supplement a modified version of Bloom’s mastery learning approach, by having students make two attempts to master an instructional unit. In Bloom’s model, students who achieve mastery in the first attempt typically are introduced to more difficult material in the second stage, while the others make another attempt.

The main differences for this project are that students are organized into study groups, and assessed not only on their individual achievement, but also their study group’s achievement; and that the students who achieve mastery in the first stage become peer-instructors in the second stage for their study group. Consequently, the web-based tool for this project requires a system which assesses mastery, as well as a way of tracking student and study group progress by both students and teachers.

The hope is not to find the best approach for using WBI in Chinese pedagogy, but merely a possible approach, which at least attempts to account for Chinese cultural and pedagogical differences. More than anything, it is clear that more research is needed which looks specifically at the dynamics between web-based instructional tools and their surrounding cultural context.

The exploration phase of the Planning Game involves the customer writing “stories” for the requirements of the proposed software release.

So what is the proposed software release? I’d like to try out a 2 week release iteration cycle, as that seems to be a common timeframe for other projects I’ve read about. Since this is not a fulltime job though (and far from it), the cycles are not going to be very feature heavy.

User Stories

Playing the role of the customer, I’d like software release 0.1.0 to essentially support student user accounts, and simple display of the student user’s classes. Here are my user stories (I’m technically supposed to write this on index cards, but those are a little hard to show onscreen without some effort):

1. Allow the user to login using their email address and a password. Logging in takes them their student main page. Failure of login credentials shows an error.
2. Create an admin page which allows me to create users by supplying first name, last name and email address. Also allow me to add them to up to 5 classes.
3. Create a user’s “My Account” page, which allows the user to view and edit email address, first name, last name, password (twice), and an “About Me” textarea.
4. Create an admin page which allows me to create and edit classes.

Ok, time to switch roles. As the developer, I need to look at the user stories, and split them if necessary so that they can be expressed as estimate-able chunks.

I came up with this:

1. Setup project and commit to SVN. (1 hour)
2. Create initial DB diagrams. (1 hour)
   
3. Create SQL tables and input test data. (1 hour)
4. Support student login via a home page, using email address and password. Failure of login credentials shows an error. (1.5 hours)
5. Create an admin page to create classes (for now, just a class name and ID). The class name should be editable. (1 hour)
6. Create an admin page to create test users by supplying first name, last name, email address. (1 hour)
7. On the admin test user creation page, allow users to be assigned up to 5 classes. (1 hour)
8. Create a My Account page which allows the user to view and edit email address, first name, last name, password (twice), and an “About Me” textarea. (1.5 hours, not committed)

So basically, pretty much the same requirements, but added some technical setup details. Also, I’m going to give myself about 8 hours per release, so I can’t commit to having user story #8 in this current release. Instead, it’ll be a “nice to have” if things are going extra smoothly.

There’s a commitment phase which involves scheduling these items according to risk and business value, and then setting development velocity and scope. This is more of the formal process I should have gone under to decide on deferring story #8, but since this is my first go at XP, I’m going to skip this step for this iteration and just use my gut. The items I listed pretty much have to be implemented in the order I presented them anyway, so I’ll just do them linearly.

I’ve tried to give myself a little cushion on the estimates, but since I haven’t done much ASP.NET, I may need the full time. Hopefully my velocity will become a little more respectable further along in the project.

In eXtreme Programming, the gathering, formulation, and assignment of software requirements is accomplished through the “planning game.”

What is the planning game? As someone who is fairly new to XP, I’m not ready to give a play-by-play breakdown of what it entails. (Maybe something I can describe more eloquently and accurately after trying it and refining how I do it). The big picture, however, is that there is a responsibility on the customer’s part, and a responsibility on the software developer’s or developers’ part.

The customer (that is, the intended user of the system who is working with the software team) must first write user stories to describe how he or she conceives of what the software needs to or should do. For the purposes of this project, although less than ideal, the customer is none other than me! Incidentally, the software team also happens to be… me.

Anyway, back to user stories. I’m sure there is a story (sorry bad pun) behind why these came to be called user stories. To me, the term makes them sound really long-winded, rambling, and touchy-feely. What user stories really are, though, are succinct (usually 1 or 2 sentences) and specific requirements in the language of the user on how the software should work.

For example:

User forgot password
- When the user forgets their password, they navigate to the forgot password page. After supplying their email address, their password is emailed to them.

The customer writes all the user stories they can think of on index cards. Any user story which is too ambiguous, too vague, too complex, etc. must be rewritten. User stories are not written in stone — in fact, part of the whole point in XP methodology is to accommodate frequent and rapid change. However, when user stories are written, they should be specific and exact, even if they turn out later on to be specifically and exactly wrong. Nothing is worse than building something that the customer never wanted in the first place because the requirements were misunderstood.

One other important requirement for user stories is that the software team feels they can make an estimate on the story. If the team can’t give an estimate, it’s usually a sign that the story needs to be split into several stories.

Once the user stories are satisfactory to both the customer and the software team, we move to the commitment phase. (Sorry, I neglected to mention the first phase is the exploration phase).

In the commitment phase, the customer  assesses the business value of each of the user story cards. One approach is to divide user stories into 3 categories — critical, valuable but not critical, and nice to have. In parallel, the software team assesses the risk level of each user story. Risk is defined by the degree of complexity, uncertainty, and volatility of that business requirement. The degree of risk and the business value help determine the order in which requirements are fulfilled.

The final phase is called the steering phase, which allows changes and adjustments to be made.

The process I’ve just described is probably a weak description of the planning game; and in fact, I’m already pretty sure of this as there are actually two different parts to the planning game, each with an exploration, commitment and steering phase. What I’ve described above is known as release planning. The other part is iteration planning, but I think we’re fine with just starting with release planning since this is the first step.

So… in our next episode… I’ll pay the role of customer and come up with my user stories for my first planned release.

I want to expand a little on the explanation of Agile methodology that I started in the previous post.

First, Agile could be classified as an iterative approach; where some form of running software is produced at the end of each iteration, and is gradually improved in each iterative cycle. But iterative development, at least as its commonly understood in software development, usually plans iterations on the order of months, whereas iterations in Agile methodology are in weeks. In fact, I think the more “purist” Agile calls for an iteration in one single week. I’ve heard of many teams, however, that do 2 week iterations, feeling that the 1 week iteration was a little too much “pedal to the metal.”

Taking a step back, having short, tight iterations makes practical sense when there are many unknowns in a project. A big part of the rationale behind the origin of Agile methodology was the reality that in many environments, business directions change frequently and drastically. As someone working in a startup environment, I can attest to this. I often inwardly laugh to myself when asked for a software plan for the next year at work, because I know that even the items we’ve charted out for the current quarter will change a lot by the time the quarter is over.

Another big benefit of Agile methodology is getting feedback very quickly from the customer. Since the focus is on frequent iterations from the very start, and on working software, no matter how trivial, the customer will get to see something early on, and have the chance to divert the direction of the project if there is a misunderstanding of the requirements, or if plans have changed.

In Agile methodology, the customer is basically the stakeholder most readily accessible who is committed to giving frequent feedback and is part of the requirements planning and verification of working software. For that reason, the “customer” may be an actual customer in a business setting, but more often than not the customer is actually a project manager, someone else internally, or even the programmer. In my case and under my time constraints, the best person to play the role of the customer is none other than me!

There are actually many flavors of Agile methodology. Probably the two of the best known flavors are XP (eXtreme Programming) and Scrum. I’m much more familiar with XP than Scrum, so I’ll use XP as a starting point, and if I have time, evaluate and/or try out Scrum somewhere along in the process.

Next post: More on XP…

So, here are the facts…

It’s been a month since I’ve updated this blog. Although I have been doing a few things with the project (including finishing up on the ASP book and working out a few draft database schemas), for all intents and purposes, work pretty much screeched to a halt. The short story is that an extra busy work schedule put me behind, and I was inclined to only blog when I actually had accomplished a big chunk and more or less caught up to the schedule. Ironically, this desire actually contributed to falling even more behind.

So, it’s time for a fresh start, along with the realization that sometimes in solo projects, you need to manage yourself. And in fact, this might be a great opportunity to try something I’ve wanted to do for awhile, which is called “Agile programming.” Agile methodology is a different way to do software than the traditional project management oriented approach. In the traditional approach, there usually is an end goal with significant milestones. Typically, requirements and specifications are designed in detail upfront, and the final product is not usually available until the end part of the project.

Agile, on the other hand, calls for less specification upfront, an emphasis on getting something working and runnable, no matter how trivial, right away; and then incrementally improving the product with frequent, tight interaction with the customer. Agile is designed to deal effectively with change to product requirements, and also to keep a project moving forward and on track.

Some programmers and project managers swear by Agile. Others feel it is a faddish waste of time. But I think Agile has established itself enough in the consciousness of the software development industry that it’s an accepted practice, although some may disagree with it, and I’d love the opportunity to try it after reading a bit here and there on it. Doing it on a school project also might be a good opportunity as well, since I won’t get fired if I miserably fail. (Although I might further delay the prospect of graduation… but that’s another story).

Anyhow, I will write more on Agile as the process continues. This is the first time trying this as well, so there will be some adjustment and learning period at first.

Ok, so in keeping with my new “Agile” framework, and also because I want to graduate someday, I’m making a goal of writing 40 posts in the next 60 days. Why 60 days? On July 12, I’ll be heading off to China for 3 weeks, where I’ve been doing a yearly trip teaching English as a volunteer  at a secondary school. (I’m not Chinese, by the way.) I’ll have roughly 60 days before I go, so I’d like to make some real progress on the project before then.

My intent is that each post would correspond to one or more small steps on this project, so about 3 or 4 a week for about 8 1/2 weeks. This may not amount to much for each post, but if I follow through, I’ll at least be somewhere better off than where I am currently.

By the end of this week, I’d like to have posted at least 2 more times, and by the end of the week, I want to start Agile and get refocused on where I am in the project. I also want something running, no matter how trivial or non-functional.

Now that I’ve called myself out on this, it’s time to either execute successfully or fall flat on my face. Here we go…