Jim’s Development Blog

I’m interested in doing some other projects using the same multi-phase scenario as the museum software project. Topics I hope to tackle include:

• Food preparation, recipes, and dietary statistics;
• Human resource software including a pre-processor for the typical payroll service bureau; and
• other business related applications.

The web portion of all of these projects will be implemented (for testing purposes) on my web server, which is a Linux-based machine with MySQL as the database. This will be a real learning experience for me, as I have never written anything that uses SQL for the back-end. I’ve played around with SQL in the past, but I never got into creating views and multi-level select statements (if that is the correct term for the complex queries I’ve seen other developers put together). Therefore I am studying and playing and developing all at once. It’s interesting, but progress is slow.

I want this museum software to be usable by organizations of all sizes. The software will maintain a database with a complete record of every item in the archive: what it is, where it came from, its location, what it looks like… with a tracking history of movement - when it was displayed, when someone checked it out for study, when it was loaned out to another organization. I’ll incorporate links to image files, to text files, and to other documents. One of the goals is to have a distributable “read-only” version of the software. Another goal is to automatically generate static web pages from the software.

The phase one package will run on the Windows platform (XP or Vista).

I’m going to handle both the archive (collection) information as well as information about the membership with this software. It seems logical to do both, because there will be some interaction:

• Members will be interested in hearing about significant additions to the collection;
• Members will sometimes be a source of additions to the collection; and
• Members will be a primary source of funding to support the collection.

The member information should include the following items:

• Name (First, Last, Initials, Suffix, Title)
• Home address (Street, Apt or Floor, City, State, Zip)
• Work Address (see home address)
• Phone numbers (Home, Work, Cell, Fax)
• Email address
• Second home address with likely periods of occupancy
• Business information (Company name, industry, position, web address)

Additional tables should capture information about family members, pledges, donations, volunteer service, and so on. For more sophisticated organizations, a section on planned giving would come in handy.

The software should coordinate and keep a log of all communications with the member: visits, mailings, phone calls, and so on. I’ll design the member section of the database and post the design here before I tackle the collection section.

I developed a job cost accounting package back in 1981 through 1983. It was written in Basic for a multi-user operating system called Oasis (now Theos), and it originally ran on a Radio Shack TRS80 Model II. If I remember correctly, the nucleus of the operating system was loaded into the lowest 16KB (not MB!) of RAM, and then each user had his or her own 8KB of memory partition to hold the software and data. Attach a dumb terminal or two to the serial ports of the computer, and you had a two or three user system. It worked. It worked surprisingly well. The Basic language had built-in statements to access keyed and indexed data files, which meant that you could write a record to a file like this:

Write #1, Key$: ID$, Name$, Address$, GrossPay

Compared to the primitive features in GW-Basic, this was almost magical. It took care of record contention issues, although the earliest version of the OS used sector locking instead of true record locking. It was very solid, very reliable, and it was a cheap way for my clients to get into computers.

The software that I wrote was originally developed for the construction industry, but over the years it was adapted for many other industries. Job costing can be applied in many situations. The software worked; if you looked at the code, you might wonder how. I wrote it without having any solid background in software development, so the resulting code wasn’t pretty. Some spaghetti, a lot of obscure variable names…

All of these years later, I still have three companies which continue to rely on that old code. Oasis long ago changed its name to Theos, but the software continues to plug along. For many reasons, I would prefer that the remaining three companies move on to another product, but until they do, I continue to provide support.

One of these clients has decided to offer their employees a 401(k) plan. I now need to reacquaint myself with this 25 year old source code and add the wage deferral option to their payroll system.

One project that has interested me for some time is Museum Software. This is a database program used to record, document, and track items in a Museum’s collection (or archive). There are several well-known packages available, but many smaller organizations aren’t able to afford them - nonprofit organizations always have trouble raising funds, and local history groups (for example) will generally have a harder time because there is not any wide-spread interest in the mission. I thought that a well-designed software package would be a useful tool for many nonprofit organizations.

My plan is to develop the software in three phases:

• A Windows desktop application to run on a single PC or on a local are network (LAN);
• A module to export the archive’s details to a series of static web pages;
• A version of the desktop app to run on the web.

Phase two is important to many smaller organizations with web sites on one of the low-cost hosting plans. The ability to maintain the database over the web is less important than telling the world exactly what is in the collection. A series of static web pages will do that easily and inexpensively.

How I implement phase three will depend on the feature set that I choose, as well as which web server and database engine will ultimately power the thing. Since I have access to a linux server, PHP and mySQL might be the way to go, although I’ve played around with Ruby on Rails and found it to be very interesting. IronSpeed is another product that looks promising.

I’ll be developing the first phase using SoftVelocity’s Clarion language. I’ve been programming in Clarion for more than a decade, and it saves me so much time with the routine parts of writing a Windows app that I won’t give it up (despite the fact that it is what the rest of the world is using). Fortunately, none of my clients have cared if I used something other than VB… in fact, we have all benefited from the time savings. I’ll be talking more about Clarion as I develop the software.

The next step is to come up with a list of features.

The images in the header section of this blog are from locations in Alaska and in Glacier National Park. The scenery in those places (and in the other national parks, particularly Crater Lake, Bryce Canyon, and Zion) is too beautiful to be adequately captured by our digital camera; you have to see it in person. Go! Take a walk on the wild side.

I’ve decided to write a blog as I develop new software applications. I figure that by recording my progress (or lack thereof), I’ll be more likely to focus on the small details - doing things in the correct sequence, documenting my work as I go along, and providing the logic behind the software. Once the application is ready to be released, I hope to use this blog as the basis for a book about the app. The book will include the design decisions, the database schema, the source code, a discussion about how I created the final software product, the user’s manual, and a working copy of the application - all delivered electronically. Depending on the circumstances, I might also decide to publish the book in paperback format.