Chase Maier
Technical Lead & Senior Software Engineer
Project Details
Project Tags
The following tags have been assigned:
Media Gallery
Related Projects
The following projects are related:
DCOHome v2
This project was done while I was a Resident Technology Assistant (RTA) with Student Affairs IT at the University of Montana, Missoula. DCOHome v2, the second major iteration of the home-grown intranet portal used internally by SAIT, was created mostly due to a need to transition the front-end of the DCOHome system from using ColdFusion to PHP. This decision was made due to the unnecessarily expensive cost of renewing our ColdFusion licenses to keep the existing ColdFusion instance of DCOHome running. Therefore, we began porting each individual module and feature from ColdFusion to PHP while keeping the same backend Microsoft SQL database as a shared data source between the two front-ends during the migration period. This meant that feature additions and significant architecture changes were not generally made because the existing ColdFusion front-end needed to remain fully functional until it was retired.
This particular project was incredibly valuable to me as a learning experience. The individual projects making up DCOHome v2 served as "real-world firsts" in many categories for me including working on a large-scale project with a team of very capable programmers, working with several new programming languages, working with a version control system used by more than just myself, and efficiently making use of large relational databases.
Each of the major modules will be described briefly below. I have attempted to organize them from most significant (top) to least significant (bottom) based on my personal involvement in the development of that module and the importance of that module to the system's everyday use. The media gallery on this page follows the same general ordering. Each module below has also been tagged as being a migration of an existing module from the existing ColdFusion application or as an entirely new module that had not previously existed.
Note: The media gallery on this page contains screen shots taken from a development server using a test database several years after development on this project had already stopped. As a result of this, some pages don't contain real-world data representative of the system's actual use and some pages are missing data entirely. Nevertheless, I think you should be able to get a general sense for the functionality of the systems involved by observing these images in additions to the descriptions of each module below.
General
For this new application a small new PHP framework was created that would make the development of the system as a whole easier for future modules. This included features such as user authentication, basic access control on an "admin" or "not admin" basis, individualized user settings, a built-in wiki-like system that allowed programmers to document for other programmers the features and elements of shared libraries they had developed or implemented, a built-in tool allowing authenticated users to leave notes on any page within the system, and a universal templating system allowing pages to incorporate common elements and widgets as well as be themed individually for each user.
After the initial build of the critical modules was complete I was also responsible for enhancing the user permission options to be more granular, making it possible to grant permissions to a user for specific actions rather than simply making the user a full system-wide administrator.
Timecard
The timecard application is probably one of the most important components of the DCOHome system for a number of reasons. Student Affairs IT is responsible for providing technical support and related services to dozens of different departments, organizations, and individuals including all students of the University of Montana as well as all staff members within all of the individual departments within the university's Division of Student Affairs. Because of this need to serve so many disparate entities and justify the funding of the SAIT annual budget from each of these entities it is necessary to very accurately record how SAIT employees spend their time and allocate it among these entities. Additionally, since most SAIT employees are hourly employees on a contract stipulating a required minimum number of hours to be worked, it is necessary for documentation to exist to ensure that contract requirements are successfully fulfilled by each employee.
The timecard system allows each individual employee to document each block of time that they work. Information is recorded about the date and time of the work, the department who is benefiting from the work being done, and a description of the work that was done. This information can then be used in a number of ways. First, reports can be generated to use to justify the need for each individual department to fund the SAIT annual budget based on their previous usage of SAIT's services. Additionally, these records can be reviewed by the employee's supervisor to track the employee's progress toward the completion of their contracted requirements in addition to allowing the supervisors to review what an employee was working on during a specific time and hold them accountable for how they spent their time. This system was used constantly on a daily basis throughout the life of DCOHome v2 by every employee of SAIT during this time.
Talos (Network Switch Management Tool)
The Talos module, which I named after the giant man of bronze from Greek mythology responsible for protecting the ports of Crete from pirates and invades, was responsible for allowing the SAIT staff to manage the state of the interfaces on the Cisco network switches making up the university's DirectConnect network. This was a new project - not the migration of an existing module - I completed independently with the goal of automating routine time consuming tasks performed by RTAs. In this case, at the point in time when I developed this system, SAIT partially controlled access to the DirectConnect network by disabling switch interfaces that led to network jacks that students had not paid to have activated. This was a routine task assigned to RTAs. They would be asked to review the roster for them assigned residence hall, compile a list of students that had paid to have their network jacks activated, enable these interfaces, and disable the interfaces of all other students through an entirely separate system that, due to its design, made this process tedious, slow, and unreliable if more than one person was trying to use it at the same time. Since we were already tracking the residency status of students within the DCOHome database I decided to integrate the control and documentation of the network switches throughout the residence halls into DCOHome as well. With this integration it was then possible to easily automate and expedite this process, reducing the man hours required to repeatedly perform the task and increasing the accuracy and reliability of the process by eliminating or minimizing human error.
In particular, Talos allows - via manual or automated instruction - granular control over enabling a switch interface, disabling a switch interface, locking an interface so those without sufficient permissions cannot alter the state of that interface, checking the current state of an interface, adding and associating textual comments with each individual interface, and performing batch enables, disables, and refreshes on numerous interfaces on an individual switch simultaneously. Additionally, using these features it was possible to generate reports and visual representations from the available data. Each interface on each switch was also associated with the building, room number, and jack identifier associated with the location of the network jack to which it is wired. Since students housing records in the DCOHome database included these same details it was also possible, via these housing records, to associate a switch interface with each individual student on the DirectConnect network.
Remote Support (A Component Of Chase's Tool)
The remote support module is a component I developed independently as part of Chase's Tool, a tool used by SAIT to provide remote VNC support to customers who were not in the same physical location as our staff members. Remote support was primarily used to supplement telephone support by allowing our staff to see and interact with a customer's computer desktop without needing to be in the same physical location. A detailed overview of how the components of Chase's Tool interact and what purpose each serves can be seen on that project's page.
Appointments
The RTA (Resident Technology Assistant) staff at SAIT is responsible for providing in-room technical support for all residents living in university housing. Each RTA is responsible for being on-call in their assigned building for a minimum number of hours each week where they will be available to either assist students who have made scheduled appointments in advanced or assist students who show up during this time without a scheduled appointment. The appointments system facilitates the tracking of this obligation and make the signup and notification process easier for all parties involved.
This first phase of this module was to migrate the features of an existing system from the ColdFusion application. The usability of this version of the system was somewhat limited due to architecture from the ColdFusion version that needed to be preserved. For example, each appointment had to be created individually each week and there were limitations on when the start time of the appointments could be.
After we completed the migration process I began to develop a brand new system with an alternate architecture that allowed for much more flexibility and integration with other systems. This new system is the one shown in the media gallery on this page. First, I created a way for RTAs to create a recurring schedule of appointments that would be used as their master appointment schedule. This made it so individual appointments didn't have to be created each week. Instead, only individual modifications from the master schedule needed to be made as necessary by canceling an individual occurrence of an appointment and created a new one-time appointment. Second, I created a new type of appointment called "timeless appointments" that allowed students to sign up for an appointment without a specifically assigned time. This worked much better during times of heavy demand because RTAs could visit each student on the list and often complete more appointments in a night than would be possible with individually scheduled half-hour appointments. Additionally, I added functionality that tied the appointments system into the timecard so work done during appointments could be automatically clocked to the RTAs timecard. Finally, I created the ability to track the status of individual appointments and, at the end of each night, generate a dynamic PDF that the RTA could print that they could use to attach individualized notes to the doors of students who had not been present for their appointment.
A private system used by the RTAs was integrated into DCOHome. A public interface was made available to students signing up for help. This multi-step process would guide the student through the process of providing the necessary personal information as well as giving them the option of the different times the RTA for their specific building would be available to assist them.
Tickets And Work Orders
The tickets and work orders modules were used by SAIT to interface with other university departments and track the progress of work being done on individual support tickets submitted by these departments. Having a dedicated centralized system to track this information made it significantly easier for our support staff to quickly get up to date with the status of a project and for the staff in the department receiving support to receive automatic notifications as progress on the ticket is made. Tools were integrated into the system to allow supervisors to assign each ticket to any number of employees, add private comments only visible to SAIT staff, and approve or deny attempt to close tickets marked as completed by employees to ensure high quality customer service was being provided and the client's problem had been successfully resolved.
Work orders contained similar functionality to support tickets but were used to track work performed on university property within the rooms of students living in university housing. For example, RTAs were responsible for repairing any physical damage to network, phone, and cable jacks available in student rooms within twenty-four hours of the problem being reported. The work orders system allowed the Residence Life staff working the front desk of each residence hall to, via a public interface, submit new work orders after damage was reported where it could be tracked to ensure it was handled in a timely manner. The work orders system was also used to indicate when students should be charged for time and materials used during the repair, such as when the damage was intentional rather than normal wear and tear.
DirectConnect Internet Modules
Several modules were included in the DCOHome v2 system in order to facilitate the DirectConnect Internet connection process. This included systems for storing and managing personal information about student living in university housing, housing assignment records for these students, and records about devices connected to the DirectConnect network and their associated DHCP leases.
These systems formed the foundation for data storage used to create the home-grown network access control system that protected the DirectConnect network. These systems included many special functionality such as allowing our employees to register devices such as game consoles as well as process disconnects for students who had violated the terms of service associated with using the DirectConnect network.
Forums
The forums module was integrated into the DCOHome v2 system in order to allow persistent stored communications between SAIT employees which was more appropriate in many situations than email. This was used in production to arrange meetings between employees, take polls, and serve as a location for documentation about long-term problems to be placed.
After the initial migration of the forum system I added additional features to allow forums to act as polls where employees could vote on different options as well as adding tracking so that each individual forum thread was able to determine if the currently logged in user had already viewed that thread since the last change or not. This made it much easier for users to be alerted of new postings made in the forum system.
Install Logger
The install logger module was built to track details about the hardware and software of the computers used by SAIT staff. This system would allow us to track the physical location and hardware specifications of each machine. It also allows the installation and removal of software applications to be tracked in a centralized location where other staff members can check how critical the presence of each software package on each machine is and use that information to determine if it could be safely removed. It was also possible to track identifiers such as hardware service tags and software serial numbers or installation keys and associate those with specific computers.
Inventory Tracking
The inventory tracking system was created as a new module in DCOHome v2 rather than a migration of any existing features from the ColdFusion application. The purpose of the inventory tracking module was to track the inventory levels of different physical products sold by SAIT in a variety of locations. Users of the system were able to setup a number of locations where inventory could be stored, setup a number of items and item components, and track the buying, selling, and movement of these items between locations. One of the big advantages of this system was the ability to assemble sellable items from their individual components. For example, a twenty-foot coaxial cable would be composed of two coaxial terminating ends and twenty one-foot coaxial cable increments. Once these items were assembled a new sellable product would be added to the inventory and the individual components would be deducted from the inventory. Notifications were also put in place to alert the proper individuals when inventory for specific products in specific locations fell below a given threshold. This system was primarily developed by Kaiser Leib.
Project Management
The project management module was designed to track the progression of larger or longer-lasting projects within SAIT. This system incorporated several features common to many project management applications such as tracking milestones, deadlines, project tasks, and user comments within a hierarchical system allowing the nesting of projects. This system was primarily developed by Dave Short.
