zomgwat

TimescaleDB looks great. I'm interested in using it but I'm concerned about the upgrade path across major PostgreSQL versions. Logical replication is a big help when upgrading PostgreSQL across major versions while minimizing downtime. As far as I understand it, TimescaleDB doesn't support logical replication yet. Major version upgrades with TimescaleDB is obviously a solvable problem but it probably means we'll have a more complicated upgrade path. Upgrading via logical replication is just so nice.

I have young kids and WFH. They go to childcare/preschool during the day. For me, a flexible WFH schedule has been extremely helpful while starting a family. That said, I understand not everyone’s WFH environment is the same.

Thanks for mentioning your podcast. I enjoyed the latest episode.

Chapter support is a nice feature when it's available. There are some podcasts that I listen to straight through. I skip around others.

All good points. I didn’t articulate it well but I mostly meant why do I need the watch to use Fitness+. If i do ever get one it’ll be for running.

I get it. I see why people including my wife likes the Apple Watch. I just don't want one. I guess I've reached device capacity for now.

That's especially true when it comes to working out. I have a small slice in the day to workout and I don't want to fiddle with stuff.

It could be that I'm feeling residual frustration from attempting to try Fitness+ on an iPad which I never figured out. I just don't understand why I need a watch to view workout videos. I guess that means I'm not the target market. Thankfully there are good alternatives.

I tried Apple Fitness+ and I'm not a fan. I don't understand why I need an Apple Watch. I have MacBooks, Apple TVs, iPhones and iPads. I don't want a watch.

Also, Fitness+ doesn't offer programs (yet?). Programs work great for busy lives because there's no thinking about what you're going to do each day. I just follow the schedule, do the workout and move on with my day.

Cool. Like you said, having everything under one umbrella is very nice. It's a big reason why I stuck with it for so long. Ultimately, it just didn't fit well enough for my use cases.

Are you happy with Cloud Monitoring?

I ended up moving away from it.

I find the UI to be too slow for the purpose it serves. I'm fine with a slow-ish app sometimes but not when I have to use it often and during incidents.

I also had a few instances over the course of several years where policies seemed to have transparently broke because a system metric name changed. It's possible the issues were of my doing but I don't think they were.

Lastly Monitoring, Tracing and Error Reporting are too disjointed. I wanted a solution that created a more holistic view of what's going on.

One alternative to keeping the bastion off is to restrict access to the bastion by IP address. Ideally, the list of IP addresses that need access to the bastion should be relatively small.

In cloud environments, it's straightforward to update network firewall rules as IP addresses change. Residential and office IP addresses don't change much so it's not much of a hassle in my experience. That said, it can get annoying if you find your self working on a network that rotates your IP address frequently (e.g., a hotspot).

Avoiding environment variables reduces the risk but doesn't eliminate it. The secrets still live in memory in some form, correct? However, it does help to eliminate generic attempts to exfiltrate environment variables.

Tight control of egress network traffic is better but more difficult to implement.

I was ready to hate systemd after reading all the negative reactions over the years. Then it came to upgrade servers. Now, I appreciate that I never have to write an init script or cron job again.

Not a complete answer (by any means) but keeping tight control over egress network access helps (I wish it was easier to limit egress access over port 443).

Systemd has some capability to restrict access to system resources. I haven't experimented with the capabilities yet so not sure what's all there.

Possible integrations with tools like Alfred (macOS app) is a good reason to have a CLI (IMO). I use Watson [1] to track time and mostly interact with it through Alfred.

[1] https://tailordev.github.io/Watson/

They're similar in concept but Turbo uses WebSockets and htmx is more about AJAX.

Why does a piece of software exist if it's not to implement business logic?

I've been using emacs for 15+ years too. I try vscode and other editors/IDEs periodically but I usually give up pretty quick. The tool that always has me running back to emacs is Magit. I find the git integration of the other editors/IDEs tedious compared to it.

Dash is pretty essential to my development workflow. I’ve found using Dash through the Alfred integration combined with multiple monitors to be very productive.

The slow UI is one (of many) reasons why I moved away from Google Cloud Monitoring.

Doing your own thing while supporting your family is awesome. It's a difficult thing to do.

The SaaS I run isn't mine. Back when you were starting your SaaS, I was probably spending all of my time chasing the latest shinny tech :) Some of that was worthwhile but some not. The experience taught me to slow down a bit. Sometimes I wonder if I've slowed down too much. We'll see.

> Just build in what you know.

Yup, I agree.

The apparent difference in our situations is that you know React and everything that comes with it. It seems like that'd be a good choice for you.

I'm not proficient in any of the currently popular frontend architectures. Gaining that proficiency and moving a 10+ year old product to a SPA type architecture would be a massive investment. I enjoy learning new things and pushing things forward but I can't justify that investment when it comes to the frontend. Instead, I invest in other areas to move forward in.

Thanks!

Best done as an employee is spot on.

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team.

The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future.

I began doing Ruby and Ruby on Rails (RoR) development in 2006. Ruby had been around for awhile but the growing popularity of RoR was driving a lot of changes in the ecosystem in those years. It was a fun time but I was working for a large company that allowed me the time to keep up with everything. I see today’s frontend and container ecosystems in the light of that experience. I’m now more content to wait it out and let the dust settle as much as I enjoy learning new technology.

I've recently started using GitHub Actions and I was very disappointed to learn how few "native" actions there are. I don't want to introduce yet another avenue of third-party code via the GitHub Actions marketplace.

I've been very satisfied with Barman. I considered a variety of backup options including replication. Barman is a good alternative to replication if you can tolerate a small mount of downtime while you restore. For us, it takes less than 15 minutes to provision a new VM and restore from Barman. I’m ok with that downtime because it simplifies operations by eliminating the need to operate a secondary database sever and manage replication.

Also, Barman offers point-in time recovery (PITR).

Lastly, we do a nightly logical dump which gets uploaded to a bucket (located at another cloud service).

We do the same. We use a #news channel. We also include feeds for Rubygem releases, product blogs, security related mailing lists and so on. It’s a nice way to create a shared view of a dev supply chain.

My experience is similar to yours.

We also have a monolithic MS OneNote notebook. The notebook is shared by 30+ people and we haven't experienced scaling issues at that level either.

To add to your list of features, the macOS and iOS apps work well which is nice since we have a mix of Windows and macOS users.