(Some of these descriptions may be lengthy)

System to archive and distribute reports from our legacy system in to a searchable online index. Users receive daily report distribution through a web page and reports are converted on the fly to PDF format with indexes. Users may also search through old reports by specifying the program name used to run it, the queue name in the legacy system, or the title of the report. They may narrow searches through date ranges. Invoices are also archived and when requested they are automatically superimposed over images of the preprinted forms that they are usually printed on. The whole system is administered over web pages and users are granted permissions to which reports they receive and which they can search through. The archive runs on Apache/PHP and uses PostgreSQL as the backend database. The report conversion to PDF format is accomplished with a C program that utilizes the PDFLib library.

The fax server allows the legacy system to send confirmations in fax format for customer orders. The old system allows plain text faxes in a serial "first come first serve" format. The new server allows up to 4 simultaneous faxes to be sent and prioritizes each port for the types of faxes to be sent. These include confirmations and also purchase orders for sending to vendors and desktop faxing to send from any desktop. The new format supports emailing copies of documents as well as faxing to help reduce long distance charges. The new system also added fully customizable templates for the legacy system faxing utilizing the LaTeX typesetting language allowing graphical output including logos and multiple font sizes. Desktop faxing is integrated with the Jabber IM client to allow the fax server to send status message to end users and ask for input for things such as fax numbers or if to retry failed faxes. The server manager runs on Linux coded in Perl and C and uses Samba to integrate the desktop faxing. Ghost Script is used to convert postscript documents to G3 fax format and HylaFax is used as the server side faxing system.

The electronic catalog database is a web front end to storing catalog related item information including linking similar items with different attributes and generating export files based on a template language that can be modified for anything from generating PageMaker, FrameMaker, and even HTML output. Images are scoured off the network by a bot that links items to images. Export files can be selected by keying individual items or selecting by vendor, category and class, catalog section, or any combination. When creating export selected item prices can be overridden for special promotions. For mass promotions, selections entered in to the legacy system for special pricing can be exported for use in the database in batches creating many export files from pre existing data. Using the batch process also allows the expansion of "Displays", or multiple items grouped together for display purposes, i.e. a paint display for promoting house paints. The system runs on Apache/PHP and uses PostgreSQL as the backend database. Image bots are written in Perl. The batching system is also written in Perl.

Email runs through a patches (by me) imapd/pop3d to allow NT domain authentication for pseudo users. Pseudo users can not log in to regular Linux boxes, that includes boxes that are part of the NIS domain. This allows email only users to be administered through NT only so a Linux admin doesn’t always have to be involved. The patch is a new C module for the imap/pop3 package and a daemon module based on smbclient that authenticates for the module. This allows other services to be developed that can use the NT authentication code without having to actually contain any Samba code, they interact solely through a Unix domain socket. The server can be modified and upgraded without affecting the clients. The server also supports special authentication overrides for virtual domain hosting so that virtual domain email users can be kept separate from the NT domain and you don’t have to add every email user to the PDC. The client module is a C header and object that can be linked during the compilation of clients that may need to authenticate over SMB.

Installed CVS system to allow code to be monitored and maintained by multiple developers. Before the CVS was in place, code was scattered around the network on various machines and may be used in more than 1 place. After setting up CVS, rules were put in to place for all future projects to be funneled through the system, including documentation that had previously been in a multitude of word documents. Documentation is now kept in LaTeX source for converting to printable and hypertext format, and all source is kept in the repository. To help with upgrades and new code, all final systems actually run the CVS code, so changes in a production system will get put in to the repository with little effort and to keep multiple versions in production in sync without having to move around multiple files. This works because most code currently is server code and the source can reside with the executables. The archive also includes an extension program that creates an archive map for users so they can find what they need since traditional CVS has no searching support. The extension creates a PDF document including all modules in the archive along with descriptions of those modules. The extension program is written in Perl and that uses a recursive directory search to find the information it requires.

The system imaging software includes a boot disk/bootable CD that boots Linux and creates a tar archive of the machine it’s run on. That archive can be burned to CD with another root disk image that will unpack the image on the host system again. This was done because Windows has traditionally shown to run well initially, and through heavy use begins to break down. By making an image in this fashion after a system is first configured, the system can be restored to it’s initial state with little effort. If the system supports booting off CD, just put the image CD in and allow it to restore. If not, then put in the CD and use the special boot disk to bootstrap the system to allow the restoration of the disk. For this I compiled all requires programs by hand, including glibc ( 6 hrs on a P3 600!! ) and bash. Custom init scripts were written and a special program that could masquerade as many different shell applications based on the programs calling name, including mount and a few other system tools, because of limited system space on a bootable floppy. The bootup program had to search through the different partitions to find a windows system to allow as little user interaction as possible.

The company interactive website allows customers to view order status, place orders, look up previous order information, search for items by keyword and through category drill down. Customers can also maintain custom pricing online and manage their consumer website if they have one. The information is available in real time from the legacy system, which proved to be a challenge. The legacy system is a Win32 application coded in COBOL. The website runs on Perl/Apache, so every web request actually has to make a call to an IIS server that runs special versions of the COBOL programs to extract the necessary data.

The consumer interactive website is available for HDI customers to purchase in order to quickly create an online presence without having to invest a large amount of money and time. The site currently supports consumer registration and online purchasing. Promotion items are highlighted on every page and are context sensitive, meaning that if a consumer is looking through the Farm and Garden section they will see specially highlighted Farm and Garden items. The site is coded through a special template system that allows generic site information to be keyed through a PHP based website that stores the information in a database. When a consumer goes to a particular site, the webserver generates a page based on the called hostname an pulls the information out of the database. All generic pages can be overridden down to the individual site level as well as graphics. The template system uses special tags to allow inclusion of extra files, pulling fields from the database, and including inline server generated code. The template system is written in Perl and uses Apache mod_rewrite to transform page names dynamically so no actual files need to exist with the called names and the template processor can use the called name to create the requested page.

The computer project database tracks user problems and requested features. It allowed projects to be assigned for completion and allowed notes to be added to projects to advise of status. Projects were automatically time stamped when opened and completed, and notes included a similar feature. Projects were also assigned to departments to see which departments were having the most problems and also allowed reports to be generated breaking up the amount of time IT spent on any department. The project database used a Microsoft Access front end and uses MySQL as the database back end. The database allowed the IT department to visibly show where resources are being spent and allowed management to make better informed decisions before "giving the green light" on projects.

Previous to the Palm Pilot, the outside sales force used Symbol SPT1500 terminals for scanning items and placing orders through a DOE collector using acoustic modems. Symbol released a Palm Pilot with integrated scanner, and now the sales force uses them in place of the PDT3100's for ordering. The ordering application allows scanning product and pulls item information from the Palm Pilot database including description and pricing. The database of 30,000 SKU’s had to fit in 4 MB, so using a tree based file format with compressed item codes allowed the database to shrink to about 2 MB. The Palm Pilot also included an item book application for searching for items in the database. To submit orders the salemen use a standard Palm Pilot modem to dial in a establish a PPP connection to the local POP site, and the order is transmitted over TCP/IP to the server. The server is a Linux C application that supports the idea of mail boxes, so when an order is sent the server then pushes back information to the Palm Pilot. This may be reports, email, messages, or application updates. The reports are viewable through the HDI report application and replace many of the paper reports they were sent on a daily basis. There is also a real time data application that interacts with another server to query information from the legacy system, such as account status and product availability. All applications for the Palm Pilot were coded using Metrowerks Code Warrior in C. The server side uses standard Berkley sockets in C and supports plug ins for expansion. The real time server is also a C application that uses plug ins to generate content.

COBOL, Perl, C, C++, Visual C/C++, Python, Sh/Batch, PHP, LaTeX typesetting, VB, VBA, VB Script, Java, Java Script, HTML, 386 real mode assembly, and of course good ol’ BASIC.

Database interface using standard C libs, DAO in Windows, and DBD in Perl.

Win 9X, WinNT, Excel, MS Access, Word, Adobe Photoshop, Adobe PageMaker, Adobe FrameMaker, Macromedia FLASH/Director, Visual Studio, MicroFocus NetExpress, Metrowerk Code Warrior, Real Server, Adobe Illustrator

Star Office, AbiWord, Emacs, Vi, Apache, misc daemons (imap, pop, ssh, etc), Real Server, X, Sendmail, Samba, extensive lpd mangling, md (raid tools), cvs, pppd (dial up and dial in), PostgreSQL, MySQL, bind (named DNS), crond, nfsd, misc system configuration and maintenance

E3 Trim, OS/400 system maintenance/upgrades