This journal is in reverse-chronological order. Newest entries appear at the top of the page, and older entries are at the bottom. Journal - 5.2.2010 Thankfully a very uneventful week. Last week, there was a lot of time spent troubleshooting bugs after handing the system to Mr. Porior. I was in his office daily taking fixes to little bugs that had showed up, and fixing the formatting of reports to suit his needs/wants. This week has been much more relaxing. There hasn't been a single complaint - everything seems to be going well. I'll be visiting with him again next Thursday, hopefully, just to make sure. Code defense is tomorrow afternoon. I should probably (?) be nervous, but I'm actually looking forward to answering questions about my code to my professors here. This semester has been a good experience, on a lot of levels. I'm glad to see the system up and working; very glad to see that I survived, and that I made it to a reasonable sign-off point. I really do hope someone can pick this up next year and add improvements, it still has a long way to go before it's a fully-mature system, but I feel that I've made a good, stable start. Thank you for reading. =) Content Updates: - Final (commented) version of code is up - Sample report is up - converted picture links to in-line images Journal - 4.25.2010 Spent the week working out little bugs and formatting issues in the database, reports, and program itself. It's definitely been a learning experience seeing how much more thoroughly a user uses a system. Thankfully most of the issues have been small. Mr. Porior and I met every day this week, but things seem to be going quite smoothly now. My presentation is all put-together, now. I spent part of the day working on fake data for the presentation. Additionally, added a sort of "refresh" feature to the Grade tab's roster gridview. Previously, after editing a roster the names of students (which come from another table, and therefore must be removed prior to the edit...) would not be displayed again until the index in the listview of classes changed, as this was when they were populated. Now the "Update" button also repopulates the students' names. I'll get that update out to Mr. Porior this coming week - while not critical, it is nicer this way. I used the program, rather than the Access database to enter all of my "fake" data for the presentation, and it handled very well. Adding students, adding them to rosters, and editing the rosters all went smoothly. New Content - Updated resume - Source Code (mostly documented...) - Screenshots Update! - 4.19.2010 Changed the database's method of handling new student dates. My preferred method had been to assign new students a StartYear and StartSession. This was elegant, as it provided a layer of abstraction. Sessions remain the same, for the most part, but vary a few dates in either direction, depending on the calendar. Unfortunately, many students arrive mid-session, or between sessions. Additionally, StartSession provided major issues for handling reports that I didn't fully understand until this morning, going over my reports with Mr. Porior. Armed with a better understanding, the StartYear and StartSession have been replaced with the original database's StartDate. This allows a student to arrive at any time, and allows a start and end date to be given for "expected arrival" reports. I had been hoping to avoid input of two dates for the report, but it turns out to be a necessary evil. I also fixed a bug from my late-night data conversion marathon -- some of the student's ID number had been swapped... In the case of several students, their numbers had traded places 3 students down the list (when sorted by last name). Definitely an "uh-oh, that's not good" moment, when discovered. All other data with the students was correct, and the problem was easily remedied by rebuilding the student table from the original database. This took only a few minutes when not sleep-deprived. I should take this opportunity to remind myself to work when awake and coherent. Additionally, the ScholarshipNotes field of the student database has been populated. This field is used for Saudi students with SACM scholarships. I hadn't been able to FIND where this was stored in the original database... Mr. Porior was able to help find it this morning. It was actually implemented in the CampusSuiteNumber field of the original database (intended to hold a campus mail box number...) by changing a label on the MasterStudentRecord form. No wonder I hadn't found it, previously. Reports have been polished, data has been re-cleaned. The program now allows a user to search for a student by SID, something that had given me HUGE problems earlier in the semester. I'm really becomming familiar with the class objects I'm using in C#, and implementing new changes is MUCH smoother than it originally had been. Meeting with Mr. Porior again first thing tomorrow -- crossing my fingers that this version will be usable. As I'm awake this time, I'm much more confident in my "final?" project. In other news, Microsoft just released VisualStudio.NET 2010 Professional edition on their DreamSpark website for student developers. There are LOTS of good tools there, including the VisualStudio 2008 Pro edition that I've been using throughout this capstone. Best of all, these programs are provided FREE to student developers. The new version even contains Microsoft's new F#, a "functional" programming language -- it looks quite interesting. Journal - 4.18.2010 Data Conversion and Deployment! UPDATE!! ----> new version of resume posted! It's been a long, painful, and at times impossible-looking weekend. At first, converting the database went beautifully. The first few tables (mostly the key/lookup tables...) were as simple as copy/paste. I expected to be done converting hours ahead of schedule and start in on tweaking the reports a day ahead of plan. That couldn't have been further from the actual story. Oh, the pain. It was very naive of me to think that converting a database into a new system would be an easy task. Oh, I knew somewhere in the back of my head it would be "hard", even "tedious". I had no idea, let me tell you. Some of the data was corrupt, and easily fixable. Clear typos were corrected as I went through the data (I had to correct the ClassYear on one class, for instance). That wasn't so bad. And then I came across something mind-blowing - a student, enrolled in the same class, twice, in the same session. Upon further examination, that single instance of a class (and several others...) were each associated with multiple rosters, with repeating students. Note also, that the same student received disparate grades in the same class, in the same year, in the same session. What does that even MEAN?? Let me take a moment here to point out the PROBLEM that led to this feat in world-ending physics: incrimental primary keys on tables. With all due respect to whoever designed the original database (and they have my respect, for goodness sake, at least it WORKS!), the use of incrimental primary keys is bad. The intersection of ClassRosters (now StudentClass) and Students was keyed on an incrimental field. This was done to allow multiple students to be associated with a ClassCode, and multiple ClassCodes with a ClassRoster, so that multiple students could be associated with a class. In the updated version of the database this is entirely unnecessary: StudentClass is defined by a year/session/class/SID, and SessionClasses by a year/session/class. In this method, with composite primary keys, the ClassCode that identifies each instance of a class is not needed (as a year/session/class uniquely identifies the class). Additionally, no RosterCode is needed to uniquely identify the intersection. In principle, a student CANNOT take the same class multiple times in the same period, so this is reasonable. It PREVENTS a student from taking the same class multiple times in the same period (God help the database if that wasn't erroneous... The might be an earth-rending implosion.), and thus protects the Transcript report from having to calculate multiple grades for the same student in the same class. The only equivalent example that comes to mind is somehow being enrolled in my Senior Capstone class twice (or three times!) in the same semester. That would be... entertaining, would it not? Certainly at least as entertaining as converting a database by hand from 9pm-3am. I would, here, like to express my EXTREME gratitude to the Notepad++ team at Notepad++Team for their wonderful, free program. I would have been beating my head into the desk without an easy way to macro commands for cleaning bad/misformatted data. I've also been using notepad++ as my chief HTML editor over the course of the semester for maintaining my website. Nonetheless, the database was converted, and reports were converted. I spent the day wading through some very cryptic SQL statements, with nested INNER JOIN statements, trying to decipher the queries that were used to generate the reports. Eventually (and this may be heresy...) I gave up and let Access generate the SQL for me, using the default Query Design View. You reach a point where drop-down boxes become comforting. This also proved simpler since, apparently, the original queries were constructed in this manner. It was much preferrable to writing nested INNER JOIN statements. I'll be taking the program in to Mr. Porior first thing tomorrow morning. This last weekend of desparate work has been crazy, but very rewarding. Now I cross my fingers and pray. I've taken care of every bug I was able to produce over the course of the project. Can't wait to see how this goes. Journal - 4.11.2010 Layout of the UI is complete. The controls have been set to move with the form, so screen resolution is no longer an issue. The database has been re-designed and implemented in Access 2007. Getting the database put together took a bit longer than expected, so it hasn't been populated with test data yet - that will be first priority next week. Reports are the next priority. Database re-design took longer than anticipated due to some bugs in the MS Office 2010 beta that I was using... the program kept crashing when I made tables with composite keys unless I used "Save as" instead of saving the table. My intention at this point would be to finish ironing out wrinkles over this next week, to get copy of the CURRENT data in the ESL database, and convert it into the new system next weekend. If everything goes well, hopefully I can hand a completed program to Mr. Porior for testing a week from tomorrow. Journal - 4.5.2010 Easter break is over. One last week of coding and getting this program ready to go. I'll need to be around to help and correct bugs that turn up after deployment, so I want to get this program into Mr. Porior's hands and give him a chance to start using it ahead of schedule. With Mr. Porior's consent I've decided to keep his reports in Access rather than re-creating them with Crystal Reports, since I can't find a good way of calling Access reports programatically through C#. Additionally, converting to Crystal would take away the ability for a user to create new reports if needed, as they would be built into the Visual Studio project. Goals for this week: * finish coding and layout * re-implement the database in Access 2007 * Over next weekend: populate the new database with fake information for presentation and testing purposes * Convert reports to the new database * Meet with Mr. Porior: new/edited reports Journal - 3.28.2010 Spent a good portion of the weekend researching how to get to the bottom of a datagridview and highlight a particular cell programatically and found the DataGridView.PerformLayout() function. This alloys you to set the first displayed row of the datagridview (i.e. it allows you to scroll to a particular row). Additionally, DataGridView.rows[i].cells[j].selected=true selects a particular row/cell. I'd had problems with this because I was misreading the documentation, and didn't realize that the .rows/.cells part of the syntax was important... Must have been sleepy when I was looking at the documentation before. Fixed a bug where redundant lines were being added to a listview each time a particular tab was selected. The bug occurred because the LvFill routine I'd written was adding to the datatable with each pass. This was remedied by clearing the listview during the fill method's execution. Features added * Search an individual student's classes * Add student's without manually scrolling through the datagridview * Add/edit classes Journal - 3.21.2010 Fixed some minor cosmetic issues: font size, scroll bars, program starting maximized. Didn't accomplish nearly as much over the week as I would have liked, but Spring break was relaxing... Managed to do some writing that I'd been putting off. Mr. Porior is using a 1280x1024 monitor - I'll have to use one of the lab machines (same monitor setup) to do some final layout work for the program form, since my monitor is 1440x900 (I can't see the bottom of the window...). This raises some interesting issues - hard-coding the window size is probably a bad idea. I need to look into a way to change the size of objects in the form based upon the screen resolution. Sounds tricky... My project walkthrough is Tuesday, early in the morning. Really looking forward to presenting my project, but I wish I had a bit more work to show from Spring break. I feel like I wasted a lot of time that could have been very productive. Life's going to be busy these next couple of weeks. Journal - 3.14.2010 Demoed my project for Mr. Porior and Ms. Wanless (one of his associates) on Thursday last week and received a lot of good feedback. Home on Spring Break, so I decided to kick back and relax until Monday - the fun starts again tomorrow. Results of the Demo Features to be Added * Add Classes * Reports (code for this is already done by Vahn and Corey, and the reports are in Access) * An easy way to add students (adding is at the BOTTOM of the DataGridView...) * Filter/search students by Family/Given/English name * Trap tab/program exit in order to give the option of saving un-committed data to the DB GUI * Size 12 (max) font (needs to be easy to see...) * Fix a glitch with the program hiding scroll bars under other objects * maximized window on startup (Mr. Porior finds other windows on the screen distracting) * Sort the class list in descending order, to make current classes appear at the top * fix a setting where DataGridView headers are non-resizable Many of these issues are minor (or seem minor, at the moment), particularly the GUI issues that are simply settings in the DataGridView objects. Mr. Porior requested that I give another demo soon after I return from Spring Break, so I'll be working on the project throughout the week. Journal - 3.7.2010 DataGridView Last week was slow for the project. Work was busy - people were away, and various departments were moving into the newly refurbished Todd Wehr hall. It's not so much that I worked more hours, but I was carrying computers around instead of cleaning viruses. Lots of spare time spent catching up on sleep. More success with the DataGridView, however, and it now saves successfully to the database. It's actually much more elegant a solution than I had, at first, thought. Having a DataTable for every table you load from the database makes sense - the table is the in-memory copy of the database table. I didn't quite understand that to be the case, when I started. It makes sense to not use the same table, as that would restrict you to one table in memory, which might not always be feasible. Binding the DataTable to the DataGridView also makes more sense than I thought. This way the DataGridView simply displays the data from the DataTable, and changes in one are reflected in the other automatically. The DataTable has a getchanges() routine that returns only the changed rows in the table - excellent for updating the database, as in: dAdapter.update(dtStudent.getchanges()). Campus internet has been down practically all weekend - time has been spent sleeping, fighting with my computer (yes, it was the network that was down, but can you blame me?) and catching up on other homework. Plans for this week (no particular order): - Get a class roster/grades DataGridView up and working - remove old, unused parts of the interface (saved for reference, of course!) - trap tab/program exits and request to save changes to the DB -> DEMO the system to Mr. Porior! - modularize the routine that fills the DataGridView, so it's reusable - spring break starts next weekend! Journal - 2.28.2010 DataGridView UPDATED! Got the updates to the database working by adding an OleDbCommandBuilder object. This object creates the SQL statements necessary to insert the new changes to the database. The system also does error handling on the edits, and confirms successful edits. On a tip from a friend last week I decided to experiment with a DataGridView object rather than loading information from the database into a ListView. The DataGridView handles sorting on columns, rearranging columns and editing data much more easily - it allows a user to simply highlight a given cell and edit data directly, without the need for edit boxes. I have the Student table loading into the DataGridView object correctly, and have been able to edit/reorder/sort the data with no problems... I am, however, having problems writing the data back to the database. No doubt there is a very simple solution, but everything I can find so far points to making a global dataAdapter and dataTable specifically for the DataGridView, and binding the datagrid to the dataTable... not very elegant, to say the least. Journal - 2.21.2010 Back to Work Back at school from a weekend at home with my family, and ready to really dig into the project this week. Well rested, and after my meetings with Professor Blahnik and Mr. Porior last week I feel like I have much better direction. Van and Corey's version of the database management software is up and running - should have something to show Mr. Porior this week, and his thoughts/reactions should be a good guide for prototyping the User Interface. Also... it seems that part of the problem with the software may have been due to a botched install of the .NET framework on the lab computers. Reading I've done on the issue indicates that the .NET 3.5 framework installs the earlier versions (separately, so each can be installed/uninstalled/configured individually), and that some security patches for WinXP have been known to break the 2.0 framework that the software uses when connecting to the database (system.enterpriseservices.wrapper.dll). Might have to do a repair/install of the 2.0 framework on the lab computers... Hopefully Mr. Porior's computer won't have that issue, but I'll be taking along an installer just in case. Journal - 2.17.2010 New Content - Schedule Update Met with Dr. Pankratz this morning and refined the focus for my project. Updated Schedule is posted on the resources page. (changes listed below) - Moved prototyping up to begin next week (more time for coding) - Moved back database conversion (better to only do this ONCE) Issues with Current Database Versions Access 2000 Version - Requires extensive knowledge of the system - too much typing - unstable - unusable to anyone but Mr. Porior (overwhelming interface, necessary knowledge) The good thing about this system is that it works Access 2003 Version (Corey and Van) - Program bug - UI not much improved (nested tabs) This system will be useful to me. The database is mostly good and the UI in their system, while clumsy, contains all of the necessary content. As such, I will be able to use it as a reference and improve on the design. Main Goals - Easy Adding/Editing of Students - Easy input of grades - Easy retrieval of student/individual records - Improved User Interface - (New Database - ER) Database conversion will be a step of deployment. This makes sense. I'd also scheduled a week for deployment prior. Talked with Corey Vorland: the un-found bug was related to the UI not populating items when switching between tabs. Meeting with Professor Blahnik and Mr. Porior is scheduled for tomorrow morning: - What reports are used, and how often? - When is information entered into the database (grades/students)? - What database fields are non-necessary? Journal - 2.12.2010 New Content - Schedule Tentative Requirements and Schedule added to the Resources page. Very pleased with my meetings with both Dr. Pankratz and Mr. Porior this week. Having a schedule together is also much more relaxing than I would have assumed... there's something nice about having goals to meet/beat to give my weeks a little more structure. That will keep me on task and help guarantee effective progress. I've also adjusted my agenda for the meeting w/ Mr. Porior, in light of priority information (see the below journal). I need to talk to Corey Vorland about the bug in the CSCI 330 version of the ESL database... It would be good to know what to look for if I reproduce it. Journal - 2.10.2010 First Meeting Finished first meeting with Mr. Porior, and scheduled weekly meetings (Wednesdays @8am). This will help keep him in the loop of what's happening and give him a chance to provide valuable feedback for the project. It should also help me to stay focused, and to provide a product that will be useful to the end user. Additionally, I obtained a copy of the original MS2000 database that Mr. Porior has been (and is still) currently using for his work with the ESL program. He complained that the system has become unstable since his computer was updated to run MS Access 2007. Notes and Impressions 1. As previously stated, the record for students is the main feature in the database. 2. Several reports are used on a nearly daily basis. 3. The database contains several fields that were added to test new ideas, but that are non-important and non-useful to the way the system is currently used. The ability to edit students' grades from a class record (rather than searching each student's record individual) is important, and cannot be done with the current system. The ability for teachers to add grades to their classes is currently unavailable, but Mr. Porior would like to see it added in the future. This is a low-priority issue for this project: a working, usable system is priority. A separate program could be added later and run from instructor's machines in order to add/edit grades - security becomes a concern. As a partial solution to the above problem I recommended a sub-system to read instructor's grades from file. Mr. Porior supports this idea. If handled properly, there is no reason that this should be any less secure than instructors filling out paper forms and submitting them to the ESL office, as is done currently - it would, however, require instructors to submit grades in a specific format. As things stand right now, Mr. Porior needs to have a lot of information memorized in order to use the ESL database. He needs to know the name of sessions for classes, the year in which the occur (even though that's part of the session id) and must type them into a text box every time he wants to do anything. The frequent stopping and thinking "Now what was that called again?" is inefficient. Ideally these dialogs will be replaced with dropdowns, pre-loaded from a table in the database (as in Van and Corey's design). Next Week's Meeting with Mr. Porior (agenda) 1. Which Reports are used? What do they do? 2. Which database fields are non-useful/expendable? 3. Priorities of requirements. Journal - 2.7.2010 Tasks Study Phase -> Meet with Mr. Porior -> Develop system requirements documentation based upon user needs Convert Database to Access 2007 format -> Redesign the database -> remove unused fields/data -> simplify relationships if/where possible Redisign the program UI I want to use multiple forms rather than tabs within tabs for the GUI, but I need to discuss the design with Mr. Porior before I commit to anything. If the user interface is not useful to the user, he won't use it. Specifically, I want to know if he needs the ability to assign grades to whole classes from one screen, or whether grades should be assigned from the student. Grades are stored in the database in an intersection between a session of a class, and a student. Provided Mr. Porior is okay with a multiple-form wizard style input design, I need to know whether the grades should be inputted from the student, or from the class, or whether he would like the ability to do both. No doubt, other issues of similar nature regarding the philosophy of the system will continue to arise. Journal - 2.3.2010 Resume Resume has been added to the "About Me" page. Journal - 2.3.2010 GUI Design Thoughts The code for previous version of the ESL database system seems to be nicely laid-out. There are a lot of parts of it that will probably be very useful, depending on how Mr. Porior wants the system to function. One huge thing that I notice, though, is the design of the user interface. Everything is laid out logically in tabs. I think this could be better if, instead of putting everything in a huge window under a lot of tabs, a small windows with a few buttons was used. For example, having a huge tab with all of the Reports for the system leaves a lot of unused space... I'd like to simply have a "reports" button pop up another window. That window can walk the user through the report, wizard-style. The same approach can be taken to finding/adding students. I don't believe that "find student" and "add new student" should be on the same page - it seems dangerous to me. Currently in the process of updating my resume. It should be up in a nice PDF format tomorrow after class/work. Site notes: to-do - new (more professional) self-portrait - new (more professional...) buttons Journal - 2.2.2010 Spent a good portion of my evening digging through the old ESL database. Looks interesting, but it's super-complicated. I'm hoping that as I understand what it's doing - and even moreso as I find out what Mr. Porior wants the system to do - that I'll be able to remove a lot of stuff from this thing. The [STUDENT] table is the main part of the database: that's obvious. Everything else is related to everything through the student table. The thing that bothers me is that the STUDENT table is also full of fields that aren't being used, or are only used for a few records. There are a lot of comment fields, as well as flag/checkbox fields. Hoping there's a better way to do some of this - it's a little overwhelming to look at. Had work/club commitments for 9 hours straight today w/o a chance to even eat... Database system's C# code is my main agenda for tomorrow. Hoping to meet with Professor Blahnik to discuss the design of this database within the next two days. This thing needs, I think, a good deal of redesign. If I can get a more simple design hammered out, that still works well, programming a GUI to handle the database will be a lot easier. The other serious issue is going to be sanitizing the data. Journal - 2.1.2010 Met with Professor Blahnik on Friday (29th). I currently have access to the "g:\z\esl" folder where Corey and Van stored their ESL database project. I will be working from that folder for my project. I am in the process of studying the database and code from their system. It will probably take a couple of days to really understand what they were doing with the code, and the database is complicated. Once I'm familiar with the system I'll be in touch with Professor Blahnik again to discuss what I've found. Hopefully we can also get an idea of what doesn't need to be a part of the system. Once I've touched base with Professor Blahnik, we will be able to go to Mr. Porior (who will be using the system). I need to understand the system before talking to Mr. Porior so I'll be able to understand his wants/needs in a new system. Ideally, he will have good information about what the system should do: data, reports, interface. Whatever he doesn't know, it will be my job to fill in the blanks. Website is Up Statement of Philosophy can be found in the "about" section.