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.

This past summer we vacationed in Scandinavia, visiting Norway, Sweden and Russia. This photo was taken as we travelled by ferry from Oslo to Balestrand, Norway.

The hard drive on my iMac is making a funny noise, which is a good excuse to review my current backup strategy. It’s fairly simple these days. All of my data is on a 3TB iMac fusion drive. That gets backed up 3 ways. It’s backed up to an Apple Time Capsule, which also serves as my main WiFi router. I also use CrashPlan to back up to their cloud service, CrashPlan Central.