Like all sequels, this may or may not appeal to you.

Three, almost four, years ago, I announced the release of “familiar,” my Ruby on Rails-based self-hosted genealogy web application.

Familiar was started on a roommate’s couch in Minneapolis in 2015, as a replacement for the Mediawiki setup I had once used a personal genealogical log. Back then, having little web development experience except what I had taught myself, I wanted to implement everything from the ground-up since I thought that would lead to a cohesive, uncomplicated experience. I spent several long nights getting a proof of concept up and running and even used it as my senior year computer science honors project.

Unfortunately, the result was not maintainable. Like most of my side projects, I worked on it in bursts, as the mood struck. This resulted in a hodgepodge of features that were barely strung together and constantly broke. There are some features that I am particularly proud of – the ability to import data from multiple different formats comes to mind – but the longer I went without updating things, the higher the cost for even a small addition. Thus, last year, I decided to scrap the whole thing.

I still wanted to work on a genealogy application that was simple to setup and use. I wanted to learn from my mistakes, use the latest Rails technology, and practice my web development skills. Most importantly, I wanted it to have a dumb name.1

Thus, Geneac was born.

Geneac is guided by these principles:

  1. DRY (Don’t Repeat Yourself)
    This is a very Rails-y philosophy, and simply put, it means that where possible I am going to seek to reuse an existing library over making my own feature, if an acceptable library exists. Case in point: I am using Thoughtbot’s Administrate instead of making my own editor interfaces. So much easier!
  2. Testing and Continuous Integration Matter
    One thing I did not learn a lot about in school is the joy of automated software testing. No! I mean it! I like it! In the README, you can see two badges at the top that indicate that I am using Travis CI and Code Climate to display the relative health of my codebase. For every critical part of the business logic I write, my goal is to have a comprehensive set of tests to back it up.
  3. Maximize Developer Happiness
    I tried to make Familiar accessible for non-coders, to some extent. The truth is that I am my first customer, so I am primarily focused on making sure the features I make are usable for me.

It has already reached (mostly) feature-parity with Familiar, and in my opinion, it is about 100 times easier to use and deploy. I have a demo website set up with randomly-generated data:

> LINK TO THE DEMO! <

And here are some screenshots!

If you want to contribute, even if you’re not interested in genealogy and just want to learn more about web development with Ruby on Rails, send me an email! I’d be happy to point you in the right direction for features to implement.

  1. At UMD, I had a really… ineffective… technical writing professor who had a number of methods and opinions I took issue with. One memorable day he was talking about product names and specifically called out “Mozilla Firefox” as a dumb name and to “not even get him started.” Being classically trained in an open-source ethos, I strongly support the right of all software developers to choose silly, harmless, nonsensical names.