Fixed! I grabbed that example from the bug tracker issue where the change was discussed and that wasn’t based on a version where the backtick change had been made.
Oh nice! I haven't used Sorbet yet, but this is the second time I've heard good things about it outside of Stripe (where it originated). I'll have to give it a proper look.
Honestly state machines are fantastic in Rails too. My last company built Statesman (https://github.com/gocardless/statesman/) and being able to lean on it to prevent you getting into invalid states is fantastic. You also get the bonus of tracking the history of states your resources went through (which is especially useful when you're dealing with payments).
At some point you'll have to think about query performance on the state transition table, but it'll go further than you think and is firmly in the realm of problems of success.
Doesn't coiling cables while passing increasing levels of power through them (which is exactly what's happening with new USB-C PD specs) start giving off more and more heat?
Thanks for the extra info, and the insight into how you're using Patroni. Always helpful to hear about someone using it for real, especially someone who's come from Pacemaker. :)
It's a little lost in another comment thread (https://news.ycombinator.com/item?id=15862584), but I'm definitely excited about solutions like Patroni and Stolon that have come along more recently.
My claim is that you need to hire some expensive people if you want that performance, not that there aren't reasons to run your own database instances!
A thing that scares me is anyone saying they're running their own HA cluster (not single instance) for cost reasons. Infra people are not cheaper than the hosted solutions (Amazon RDS, Google Cloud SQL, Heroku Postgres).
1. Unfortunately the logs don't give any detail there. Most likely something arrived down the replication connection that the process couldn't handle, and it crashed.
2. Our understanding now is that INF is the strongest preference, whereas -INF is a veto. It would be very cool to have this confirmed 100% by someone who works on Pacemaker!
To be honest we've not looked into Citus in any depth.
My early impression of it (can't speak for the rest of the team) was that it was mostly aimed at sharding analytics workloads, but parts of the docs (e.g. https://docs.citusdata.com/en/v7.1/admin_guide/cluster_manag...) make it sound like it handles OLTP workloads too.
Maybe I've been ignoring it for bad reasons!
EDIT: Managing Postgres clusters is something that a lot of people are working on. Thought I'd mention two projects that have me excited right now:
Stolon's client proxy approach in particular looks interesting, and reminds me of how people are using Envoy (https://github.com/envoyproxy/envoy), albeit as a TCP proxy rather than one that understands and can do fun stuff with the database's protocol. I wonder if we'll start to see more Envoy filters for different databases!
GoCardless (YC S11) | London | SRE, Data, Backend and Frontend Engineers | Onsite | Full-time | Visa
GoCardless is building a payments network for the internet. Since 2011 we've been focused on simplifying Direct Debit for small and medium companies (who previously had no access to it) and we're now expanding to serve the largest companies (think newspapers, utilities) and connect with existing payment systems in countries all over the world. We already support the UK and Europe and are aiming to expand to more countries over the next year.
As an engineering team at GoCardless we care most about stable, reliable, understandable code. We rely on testing and code review and a culture of frequent constructive feedback. We define and manage our own roadmap and run projects in whatever way works best for us.
Our stack: Rails, React, Postgres, Elasticsearch, Docker, Chef.
We also have a bit of Go and Python knocking around.
We love learning new things and contributing back to the community. We open source everything we can[1] and regularly host meetups and hackathons at our wheelchair-accessable office in Angel. We have a weekly bookclub within the team and give internal (and external) talks about things that interest us.
Interview process: an intro call, one technical video interview, then a couple of onsite interviews (coding exercise and some chats - no whiteboards!)
For more info and to apply: https://gocardless.com/jobs.
If you've got any questions, drop me an email (it's in my profile).
It's been a long time since I looked into this: is there now a way to configure a cluster of Redis instances such that you won't lose messages on node failure? If not, all the nice at-least-once delivery (or "effectively once" when you add message dedupe) you get with something like Kafka/Kinesis/GCP PubSub is gone.
If not, either people's messages don't matter /that/ much (which is fine, just not great for most of my usecases at the moment) or everyone's in for another round of "oh shit, where did the data go?"
At-least-once delivery requires neither CAP consistency (linearisability) nor CAP availability (any non-failed node must return a response in a non-infinite time), but is a very useful property!