Category: Programming

A major assignment might look something like this with its components in place:

The individual assignments themselves are barely different from a stand-alone assignment (as they should be), except that they point to the larger assignment. For now the reference to the major assignment is by number, but I intend to use a database query to retrieve the assignment name in the future.

This morning I decided that today is the day to begin working in GITI again, primarily adding functionality that I feel will be crucial to the structure of graduate school work. The feature I intend to add is assignment dependency, which essentially means that major assignments could be broken down into smaller assignments that could have independent due dates and assignment information. 

The first thing I decided was that for initial UI I would use only existing GITI pages, and not create a new workflow of any type, given the impending implementation of v3’s framework. The existing pages in GITI that would be used are the basic assignment edit and assignment view pages. The pages would simply receive new queries to handle the change. Starting this process I discovered something I had forgotten… the edit page is absolute crap. The edit page received no major help after being moved to v2, it still retains a lot of v1’s style, especially the gross overuse of the plain text field…. even though those fields now get translated before going to the database. One of the least sensible things about the form itself is the way that files are handled. The field implies it takes multiple files… it doesn’t, but the overall file record system does, so its one of those things where the user interface is awful for a feature that isn’t so bad (it tracks filenames for assignments, increasing the efficiency of organization).

Surprisingly, that complicated input comes with a pretty clean-looking output:

In this particular example, the fields that aren’t used are simply not displayed, but for the edit form, that simplistic approach doesn’t work, since GITI isn’t psychic and does not know what the user needs.

I am going to have to clean things up if they are going to make any sense to the overall workflow of an assignment in GITI.

Ever since I met Sarah Scott at UNC-Charlotte, I have had to consider the option of a situation where an assignment entered into GITI might not work out exactly as planned, and then the “Instructor Hold” status was born. Internally the status was originally called “scott” (valid codes were “yes”, “no”, “drop”, “inc” and “scott”). Originally the code had to be implemented in short order, due to the time constraints of being in the middle of the semester when realizing that sometimes assignments would end up in an unknown state because of instructor error or oversight. Most often the hold occurs when an assignment comes to its due date and either a rubric has not been issued or there is some other limitation to completing the assignment. In these cases the instructor is the only one who can really provide a resolution (either by giving a new date, or my dropping the assignment). The way that statuses are implemented is a really bad hold-over from GITI v1. First of all, the field is really called “complete”. I suppose originally it was a binary field that expected to know if the assignment had been finished. Over time it grew to have other meanings, including to accept the idea of dropping assignments from grade calculation. The second issue is simply the fact that “hold” and “drop” do not effectively relate the status of the assignment, they are supplemental information not related to the completeness of the assignment. Also, GITI does not presently recognize the idea of an assignment in-progress (something as a grad student I will likely appreciate).

I am considering reworking the entire assignment-control system and making it better at handling a student’s needs. I will correct the issues stated above, including adding the ability to enter an assignment, have it marked as “complete”, but also allow it to be dropped from the grade matrix. I will also implement the “Instructor Hold” properly, including prompting the student for the reason for the hold. Finally, the system was NEVER designed for the types of assignments thrown at it. It was originally designed for “homework” (as its table name in the database proclaims), so short-term assignments. The idea was to enter assignments from school and have the electronic record at home. To greater support other assignment types I intend to add the ability to set up time requirements on the items. Assignments that might not be due for another week, but have a greater time requirement (papers, projects, study for tests), would appear before assignments that are due on the same day, or perhaps even earlier, in the list. This would allow for the budgeting of time for the assignments until such time as a GITI’s schedule utility can be fully integrated to with other modules to assist in scheduling discreet blocks of time to work on the assignments.

As I approach the end of GITI’s useful life for me (for education anyway), I am seeing a lot of things that need to be done to make it useful for other people who may use it in the future. I used to spend my summers and breaks working on code for GITI, making it better for the future semester, but that hasn’t happened in the last year and I fear that the overall success of GITI is in jeopardy because of it (for GITI, success = being able to be used by someone other than the creator). 

I have never been one for much security when it comes to my technology. I like to keep my network secure, but I’m not one to necessarily have a lot of different passwords or use things like virus scanners or firewalls (outside of a firewall router). This makes me a not very good person for doing things like figuring out how the access rights side of GITI will operate when considering external uses of data via the SecretKey system. At this time there is exactly one SecretKey application, and it isn’t even really part of GITI, it is an adjacent application under the pcfire.net domain that just happens to have the same users as GITI, and therefore can use the SecretKey system without using the whole GITI login routine. In addition, I wanted the application to be something that could be accessed without having to be greeted with a credentials prompt every time it is accessed. I’m told that allowing a page to be accessed with a plain text password is bad, as it compromises everything, so I’m using the keys.

My concern now turns to the aspect of key security. Is one key good enough? Basically the way things work now is that each user is issued a key and with that key they can theoretically access limited GITI resources. The key is supposed to be used in a condition where the data is not sensitive and where things are read-only. For the current implantation there is a non-sensitive use where the data is pretty much one-way. There is only an input, not a modify, and thus no records to corrupt. Of course I log the IP addresses used for access so in the event of a problem it is possible to drop rows from the database made from any IP address not owned by the owner of the account. This being said, if the key is compromised, it is easy enough to have GITI to reset (“roll”) the key, but then all other services that use the key must be updated. I find myself wondering if each service should be able to be assigned a GITI key independently. Currently Google assigns a unique API key to each service that it “authorizes”, but it is a standard OpenID implementation, so I’m not sure how much stock I put in that process. It does seem rational though, to be able to use multiple keys and cancel them at will. I have considered using a different key for each service, allowing the user to issue however many keys they want or just leaving it as is, with each user having one key.  Oh so much to consider.

I have been thinking about my “status” architecture for GITI. At present I can tell GITI my status directly, through the UI, or by sending it an email (must be done from my phone at this time, as it only accepts 1 address). GITI will in turn post to Twitter, which Facebook picks up on. I was just thinking the other day that it seems that this practice may have become quickly outdated. While being totally out of contact I post status updates by emailing GITI, what about when I don’t have my phone close, but I am near somewhere with WiFi and have the iPod with me? It would make most sense to open the Twitter app on the device and post my status there, and let it be disseminated out, but what about GITI? What happens to GITI’s records? They are forgotten and so is any web app that uses my status from GITI. Perhaps the key here is to let GITI check Twitter and sync my statuses for me.