Genealogy - Fifteen Years Later

Readers of this blog know that I have a variety of interests. One interest that hasn't come up yet in this blog is genealogy, the systematic study of our ancestors. I started tracing my lineage back in 1992. I pored over microfilms at the local LDS Family History Center. After a few years, amassed four binders full of data. But my paced slowed down, and other interests started to demand my attention. In 1997, a trip to Germany resulted in some good information about my Boldt line. But after that, I did little more, leaving lots of unfollowed leads and unanswered questions.

A few months ago, Sylvana by chance met someone who claimed to be a direct descendant of millionaire George Boldt, the guy who built Boldt Castle in the Thousand Islands. I contacted him and asked him for details. (Later, I realized his claim was dubious since George's only son had only daughters.) This prompted me to return to my research and continue where I left off. I haven't gotten back to the LDS yet, though. I'm still going through my old data, looking up new data on the internet, and updating my files. This process has given me a new appreciation for the importance of documenting sources. Going through the data on my computer, I often question where a piece of information came from. So that's one of my first prirotities, one that will take some time to complete.

For the most part, source information is recorded in my written notes. But in one case, I have a document full of good information about my Laseur ancesters, but unfortunately, I have no idea where it came from. I sent an e-mail to one possible person. However, his e-mail address is 13 years old, and predictably, the e-mail bounced. So if anyone knows any information about the descendants of Jan Laseur, born about 1610 in the Amersfoort area, please let me know so I can properly attribute the source of that data.

So what has changed in the past 15 years? First, the technology has progressed. Back then, I was using a DOS-based shareware program called GIM. Today, I use an open-source program, Gramps. This program strongly reflects the design of GEDCOM version 5.5, the most current GEDCOM standard. Compared to the older versions, 5.5 has much better support for sources, and a wider choice of events. It is now much easier to paint a more comprehensive picture of a person's life. However, the GEDCOM 5.5 standard was released in 1995-1996. While there have been some proposals to move beyond 5.5, it still remains the current standard.

Second, use of the internet has, of course, increased. There are a number of commercial web sites that offer information for a price. For me, though, I can't quite justify the cost. Fortunately, there are still a lot of free sites where you can find information. This is especially true for Netherlands research. By searching the web, I was able to add significantly to the Dutch side of my pedigree. One good example of this is the site Jan Wies over de familie Mol(l). This contains everything published in the 1930's and 40's by the Genealogische Vereeniging "Mol(l)". If you have Moll's in your ancestry, this is the first place you should look. You can download complete lists of descendants of three different lines of Moll's. (I'm a descendant of the Moll's from Velp.)

But while Dutch genealogists have made good use of the internet, the same can't be said for the other half of my pedigree, from Mecklenburg-Schwerin. On that side, there's not much more information than there was 15 years ago.

So what are my next steps? First, there's the old question: Is my Boldt family related to the millionaire George Boldt? This is a question I wouldn't bother with if it weren't for an old family story about a weatlhy American relative visiting the Boldt home in Hindenberg. Second, I have significant unexplored areas in my Mecklenburg pedigree, specifically the ancestors of Carl Ludwigs (died 1909 in Rostock) and Emma Elise Katharine Wulff (died 1916 in Hamburg). Finally, a lot of additional little details need to be filled in, as well as expanding the list of relations.

Cheers! Hans

Operation Red-Nose Project

About 13 months ago, I started working on a project to replace the software used by the local Operation Red-Nose (ORN) organization. Up until then, they had been using an old DOS-based system that was long past its best-before date. In fact, they were only using part of the system, and even that had major usability issues. The project was suggested by my supervisor at the MCF Practice Firm, a volunteer at ORN. The purpose of the project was for me to pick up some specific programming skills. At the time, I couldn't complete the project since I got a job offer five weeks into the program. But that job didn't last, and I was able to return to the ORN project. (During the summer, federal funding for the practice firms was withdrawn, and so MCF was forced to close.)

For the ORN project, I decided on CakePHP and MySQL. I chose PHP and MySQL since they are pretty much ubiquitous in the I.T. realm. For the framework, I quickly narrowed down the choices to CodeIgniter and CakePHP. I chose the latter since it strongly encouraged the use of an MVC design. The ORM also impressed me, with its ability to get all the data associated with a transaction in one operation (typically). That is, all the SQL joins were taken care of automatically.

In a nutshell, the ORN application manages many aspects of the operation, in particular, the event nights during the annual campaign. The system keeps track of volunteers. During an event night, volunteers are checked in to the system and assigned to teams. Operators take calls from clients and enter their ride requests into the system. The dispatcher assigns the requests to the available teams, and tracks the progress of the requests. And at the end of the evening, the treasurer tracks the donations.

An essential part of the development process was demonstrating the system to the ORN volunteers and getting feedback. After each weekly meeting, I'd normally have several pages of suggested improvements. The main issue was understanding how he volunteers would learn the capabilities of the system, which wasn't always easy for a programmer geek like me. As the programmer, I knew how to get things done. But for others, especially those with little computer experience, it wasn't always clear.

Add to that some language issues. ORN Kingston is managed through La Route du Savoir, an organization that provides training and services to French speaking people in the Kingston area. Although everyone at ORN speaks English, one person had a bit of trouble with some of the more technical language I used. Often, someone had to translate my technical language into a form that that person could understand, and her requirements into language I could understand. But we managed, and the result was a system that everyone was happy with, even if it took a few weeks after the start of the 2012 campaign to get all the required features in place and the defects fixed.

Is there more work to do on the new Kingston ORN system? Sure. The data entry form for the telephone operators can be improved. I took a few phone calls myself, and readily saw one problem with the layout of the entry fields. For the 2013 campaign, I'll rearrange the entry fields to reflect the order that questions are asked of the callers. That is, if the first question is "Where are you?", the pickup location should be the first item on the form. In general, that form should have a list of questions for the operators to ask to ensure that nothing is missed.

How did CakePHP work out? In retrospect, I think it was a perfectly reasonable choice. At no time was there anything that CakePHP couldn't handle. There was one annoying issue with session timeout. However, upgrading to version 2.2 addressed that problem. The upgrade didn't go without some effort, though. When I started the project, I didn't always follow the preferred naming convention. For version 2.2, I had to rename my controller classes.

What about MySQL? The application currently uses 16 tables, which is puny compared to other production systems. Although I prefer more robust DBMS's, I could clearly see how MySQL has matured over the past few decades. The InnoDB engine (now the default) is sufficiently robust for this type of application, supporting foreign keys and transactions, vital features in even the smallest of databases. In contrast, today in the year 2013, there are still production MySQL databases that use the old MyISAM engine. In my opinion, any database administrator who entrusts vital company data to a MyISAM database should be fired immediately.

If I were to start the project today from scratch, would I do things differently? Styles of programming for web applications are always changing. For the ORN project, I designed it as a fairly traditional server-based web application, with just a bit of client-side programming. But the trend is to move more processing to the client, with the view and controller components on the client and the model on the server. But for this type of application, I don't think I'd do things any differently.