Wai Rum, Jordan I am in the process of reactivating the long dormant blog. I need a new post to help finalize the new theme, and this is that post. More soon.

Updated 5/16/19: Added a note to the Incremental Conversion section about using specific revs of a repository instead of replace directives. Go modules is the new dependency management system for Go language based projects. I just spent the last three days converting the Groups.io codebase to use Go modules. It’s a large code base, and we had vendored ~75 dependencies over the past five years of development. The code base pre-dates any of the pre-existing dependency management systems, so we were flying a bit blind when it came to which version of each dependency we were using.

Groups.io is based on a series of Postgres databases, which has worked very well for us. There are some scenarios, however, where it would be advantageous to have our data in a streaming log-based system, like Apache Kafka. One specific scenario involves ElasticSearch, which we use to provide full text search over group archives. Right now, when a message is added or updated, we send the update to Postgres, then we send the update to the ElasticSearch cluster.

I recently got a Sony A7R II camera, to replace my Panasonic GH2. I also got the 55mm prime and the 24-70mm zoom lenses. It’s a great camera, and I’m still learning the ins and outs of it. One really nice feature of the camera is EYE AF, the ability to focus automatically on someone’s eyes. It works surprisingly well, and is a great feature especially if you have young children (who aren’t so keen on staying in one spot for very long).

I just changed large parts of our family backup strategy, and looking back, it’s been 2 years since I last detailed what we use, so I thought it’d be a good time to revisit the topic. In our family, for computers, we have several Macs. For data, we have about 20 GB of personal and financial documents, and a little more than 200 GB of photos. I believe in having at least two backups, one of which must be offsite/in the cloud.

It’s been almost six months since I launched Groups.io and four months since I’ve talked about it here on the blog, so I figured it was time for an update. I’ve been heads down working on new features and bug fixes. Here’s a short list of the major features added during that time: Slack Member Sync Mailing lists and chat, like peanut butter and chocolate, go great together. Do you have a Slack Team?

Continuing to talk about the design of Groups.io, today I’ll talk about our database design. Database Design Groups.io is built on top of Postgresql. We use GORP to handle marshaling our database objects. We split our data over several separate databases. The databases are all currently running in one Postgresql instance, but this will allow us to easily split data over several physical databases as we scale up. A downside to this is that we end up having to manage more database connections now, and the code is more complicated, but we won’t have to change any code in the future when we split the databases over multiple machines (sharding is a whole other thing).

I always appreciate when people talk about how they’ve built a particular piece of software or a web service, so I thought I’d talk about some of the architecture choices I made when building Groups.io, my recently launched email groups service. This will be a multi-part series. Go One of the goals I had when I first started working on Groups.io was to use it as an opportunity to learn the new language Go.

I’m not one to live in the past (well, except maybe for A-Team re-runs), but for many years now, I’ve felt like I’ve had unfinished business. I started the service ONElist in 1998. ONElist made it easy for people to create, manage, run and find email groups. As it grew over the next two and a half years, we expanded, changed our name to eGroups, and, in the summer of 2000, were acquired by Yahoo.

For some web sites, I have multiple accounts, and need to be able to switch between those accounts easily. I created a set of site specific browsers for each web site and account using Fluid. A site specific browser looks like a normal app, but is actually a self contained browser set to open a specific web page. These site specific browsers don’t share resources, so you can set multiple ones up targeting the same web page, but using different logins.