Joyce A Bright

Programming Portfolio

All following applications were written solely by Joyce Bright unless otherwise noted.

Records Disposition Intranet Application

Technology used:

MS-Access, SQLServer, Informix, 4GL, ASP, CFML, HTML, UNIX shell scripting, DTS

Problem:

Client's off-site records warehouse was filling up and we needed a method for methodically identifying records that could be legally destroyed, marking them for destruction, destroying them, and finally updating the master records database regarding the destroyed disposition.

Solution:

This application was co-written with a team member. She designed it and I coded it. Using SQL, potential records documents were identified in the Informix database. Those records were extracted and loaded into an MS Access database. ASP code was written to allow users, via a web interface, to methodically go through the potential records and mark them to be destroyed or to be kept. Reports were written that could be ran on a regular basis to extract document information so physical files could be removed from the warehouse and destroyed. Periodically, data would be extracted from the MS Access database and a massive update written in 4GL would be executed on the Informix database updating the master records indicating the documents had been destroyed. This entire process was automated with the use of DTS and Unix shell scripting which allowed the user full control of when the Informix database updates would occur. Over time, the process became too large for MS Access to handle efficiently so the database was ported to SQLServer and the code was rewritten in CFML.

Property Management Online Reporting Application

Technology used:

MS Access, HTML, ASP

Problem:

Client (large property management firm) needed a way of making property information available to multiple remote team members.

Solution:

An MS Access database was designed to organize all property information and ASP code was written and placed on the client's internet web server allowing team members to access property information in a variety of different ways. User logins provided the needed security and usage reports were written to track user access. The MS Access database was kept current in the local office and periodically uploaded to the web server.

Online Shopping Cart

Technology used:

MS Access, HTML, ASP

Problem:

Client needed a customized online shopping cart and e-commerce implemented on their website.

Solution:

An MS Access database of their product line was designed and integrated on the website using ASP and HTML. E-commerce was implemented as well allowing for real-time credit card authorization. Administrative, secure logins were created to allow the client to view any new orders online and use that information to ship the products. Customers received dynamically generated order confirmation as well as email receipts of their order.

Project Status Reporting Application

Technology used:

MS Access

Problem:

The client (large law firm) I was assisting with another project, needed a way of tracking project issues and reporting on them. MS Project had been used but was not providing the desired ease-of-use or reports.

Solution:

A team member and I co-wrote an MS Access database that received, processed and reported on various issues regarding the project we were working on. Various reports were designed and written allowing the project manager to report on issues in a number of ways. This contributed greatly to the success of the overall project.

Client Data Synchronization Software

Technology used:

Informix, SQLServer, C, DTS, Unix shell scripting

Problem:

The client (large law firm) was keeping two separate databases current because one database's associated application was used for billing while the other database's associated application was used for billing reporting. The back and forth of data on a daily basis was inefficient, cumbersome, and prone to error.

Solution:

After investigating the problem further, it was discovered that the reason billing reports weren't being produced from the billing database was because key data that the clients were requiring on their reports was missing. Fields were added to the billing database and a monthly process was set up to carry this required information from the case management database to the billing database. Email notification was also set up to automatically inform the user the process had executed. This allowed all billing reports to be produced from the billing database and the back-and-forth of data between the two databases was no longer necessary. After this application was in use for sometime, the client migrated from Informix/Unix to SQLServer/Microsoft and the application was re-written to work on the new platform.

Client Data Updating Software

Technology used:

Informix, SQLServer, C, Unix shell scripting, cron

Problem:

The client (large law firm) needed to maintain two sets of matter (case) listings. One in the billing database and another in the case management database. They wanted to add the information to one database only and, in batches, have the information ported to the second database.

Solution:

A batch script was written using isql and installed on the user's workstation. Execution of this batch script pulled any new matter information from the case management and ftp'ed the results to the Informix server. The Informix server had a cron-job set up to check for this file at 5pm each business day. If the file existed, the data was parsed into a specific format and loaded into the database. Email notification was then sent to the users with details of the success of the upload. After this application was in use for sometime, the client migrated from Informix/Unix to SQLServer/Microsoft and the application was re-written to work on the new platform.

Timecard Load Program

Technology used:

Informix, SQLServer, 4GL, Unix shell scripting, cron

Problem:

The client (large law firm) used one application/database for billing and a second application/database for entering time reports. The timecards produced from the second database needed to be moved and loaded into the billing database so invoices could be generated.

Solution:

The time entry application was set up to create and deliver timecard files three times each day. A balancing file was also delivered indicating the number of timecards delivered, the hours represented, and a total dollar amount. Three UNIX cron jobs were setup to run at specific times during each day – 10 minutes after the time entry software was to deliver the data. At each of these three times, the program checked for the existence of the file, parsed the file into a specific format, stripped out any harmful characters and then loaded into the billing database. Resulting statistics were then extracted from the billing software and balanced against the data sent from the time entry application. Acknowledgement emails were then sent to all interested parties. After this application was in use for sometime, the client migrated from Informix/Unix to SQLServer/Microsoft and the application was re-written to work on the new platform.

Designated Nationals Conflict of Interest Search

Technology used:

SQLServer, SQL, C, Unix shell scripting

Problem:

The client (large law firm) needed to integrate the government's Designated Nationals list into their existing conflict of interest database and into their fulcrum search engine on a regular basis.

Solution:

Since, at the time this program was written, the government did not produce an incremental listing of names but rather republished the entire list, the first goal was to write a script and SQL to remove any previous occurrence of these names in the current database. After that was accomplished, scripts were then written to parse the government's name list into something usable and the names were then automatically loaded into the conflict of interest database. Records then needed to be created for each of the names that would allow these names to be indexed into the fulcrum searching database as well. The software polled the database for status and emailed the interested parties when the process was complete. Flag files were set up which allowed the user to "trigger" this process at any time. A cron job was set up to look for this trigger each weekend since this was a process that could not run during normal business activity. If the polling script found the flag file to be set, the process continued.

Designated Nationals Existing Client Search

Technology used:

SQL Server, SQL, MyEureka! Report Writer

Problem:

The client (large law firm) needed to periodically check their existing client list against the government's published Designated Nationals list.

Solution:

Assuming the client already had the Designated Nationals Conflict of Interest Search in place and running, additional scripts were written to use a personally written algorithm to look for patterns that might produce significant name matches. Each designated national name was compared to the existing client list and results were generated and loaded into another SQL table. An easily readable MyEureka! (similar to Crystal) and/or MS Access report was then written to group the results, why they might be a likely match, and why they should be concerned.

Online Public Records Search Billing Software

Technology used:

Informix, SQLServer, 4GL, C, UNIX shell scripting, nroff

Problem:

The client (large law firm) would receive a cryptic invoice from an online public records searching database. From this cryptic data, I needed to extract information that would be used to bill back to the firm's clients. Any charge that could not be identified with an authorized biller or with a valid case had to be reported on and sent to the billing department so these charges could manually be entered into the system (exception reports).

Solution:

This solution required a several step process. C was used to parse the cryptic billing information into something usable by the other scripts. 4GL was used to extract valid users and valid case numbers from the billing database. A program was then written to weed out any costs that would be rejected by the billing software because of either an invalid user or an invalid case number. These "exceptions" were then categorized by user and exception reports were formatted using Unix's nroff language and printed on the billing department's printer. These reports would be distributed to the various users asking them for valid case numbers, etc so the costs could be manually loaded into the billing database. The valid records were then loaded directly into the billing database. Acknowledgement emails were then sent to all interested parties. After this application was in use for sometime, the client migrated from Informix/Unix to SQLServer/Microsoft and the application was re-written to work on the new platform.

Modem Usage Monitor

Technology used:

UNIX shell scripting

Problem:

The client (large law firm) often had 3rd party vendors dialing into the billing database server. They wanted to be able to track who was logged in, when, and for how long.

Solution:

A simple polling script was written to watch the tty device designated as the external modem. This polling script was scripted into the Unix server's boot sequence so it would be executed on start up. When a user would log in to the server a message would appear on the server's console indicating the time and who the user was. When the user would log out, another message would appear indicating the user was gone and the total minutes they had been connected.

Unix External Modem Security Check

Technology used:

UNIX shell scripting

Problem:

The client (large law firm) often had 3rd party vendors dialing into the billing database server. They wanted to know who was logged in, why, and how they could be reached during their session. They also wanted to have the ability to tighten security with a randomly generated security code if necessary

Solution:

The key to this script was to alter the user's .profiles in such a way that disallowed them from using any escape sequences to break out of the script. Once this was accomplished, the script was written to ask the users a series of questions and the answers to those questions were logged in a local log file. If the added security was needed, a flag would be set and the local administrator could use the script to randomly create a security id. This security id was then only usable one time. If another login session was desired, another security id needed to be generated.

Informix User Load Monitor

Technology used:

UNIX shell scripting

Problem:

The client (large law firm) wanted to track Informix usage.

Solution:

A script was written to run specific Informix admin commands that would report how many concurrent users were active in Informix at that time. The script was written to take these stats once each hour during business hours, record the numbers in a log file, and report on the usage in a easily readable report. This script was build into Unix's boot sequence so it would be executed upon start up.

Unix Disk Usage Monitor

Technology used:

UNIX shell scripting

Problem:

The client (large law firm) needed a way of keeping track of Unix filesystem usage.

Solution:

A script was written to collect and parse out df statistics once daily. These numbers were recorded as well as compared against the previous day's numbers so the administrators could track any abnormal filesystem growth or any dangerously full filesystems.

Blog Software

Technology used:

MySQL, PERL, CGI, CSS, HTML

Problem:

The client needed blogging software and was unhappy with the functionality of the available online blogging sites

Solution:

A lot of the design was taken from other blog software that had been tested but all of the code was written from scratch (with the exception of some CSS settings). MySQL is used to store all data and all pages are dynamically generated based on parameters passed to the scripts via the URL. Features such as entry edit, entry delete, profile edit, visitor comments, comment delete, guestbook and an included MySQL driven slideshow feature were coded.

Online Registration Forms Compatible with Microsoft Excel

Technology used:

PERL, CGI, HTML

Problem:

The client (non-profit organization) wanted to accept online registrations and have the data automatically downloaded into a Microsoft Excel spreadsheet.

Solution:

A typical online form was designed and coded. When a visitor would submit a form a number of things would happen. Preliminary information would be sent to the client alerting them that someone had registered. The visitor would receive a dynamically generated confirmation page as well as an email receipt. Finally, the data would be logged and stored in a data file until the client downloaded the data. At that time, they would receive a comma-delimited file that would quickly upload into Excel. The client would also have the option of clearing the download file or letting it continue to accumulate more responses.

Product Database and Schedule Updating

Technology used:

PERL, CGI, HTML, MySQL

Problem:

The client (bakery) wanted to keep a database of their products online and have the ability to change their dialy baking schedule on-line.

Solution:

A MySQL database was designed to manage the product listing. Forms were designed allowing the client to add, edit, or delete products to the database. Forms were also designed allowing them to dynamically change the on-line listing of the baking schedule.

On-Line Skills Assessment

Technology used:

PERL, CGI, HTML

Problem:

The client currently had a skills assessment they used regularly and wanted an on-line version to be able to calculate the results in real-time.

Solution:

Forms were generated to present the assessment questions and the results of the questions were sent to a Perl program that used an algorithm to calculate the real-time results.

Majordomo Mailing List Manager

Technology used:

MySQL, PERL, CGI, HTML

Problem:

The client had the ability to provide mailing lists via Majordomo software but had no way of allowing their clients to manage their own lists.

Solution:

List management software was written in Perl that allowed for: secure logins, list creation, list management, email distribution, and more. Perl code was written to allow the user to interact with their Majordomo configuration files and list files.