pgr0ss

My idea for for this to add metadata to the transfers, likely with a jsonb column. But I agree that the ledger won't encompass everything. You would still have other database tables and then you'd store domain identifiers in the ledger and/or ledger identifiers in your other tables.

I updated the README and added an example test: https://github.com/pgr0ss/pgledger?tab=readme-ov-file#histor...

The idea is that the ledger implementation itself is generic and shared, and then how you use the ledger is the novel part.

> how do we efficiently get the balance of a certain account at a certain date time?

This depends on how you implement the ledger. For pgledger, I store the balance in every entry, so to find a historical balance, you just need to find the most recent entry before that time:

https://github.com/pgr0ss/pgledger/blob/df5541dcf25f416a6a24...

I have a mental TODO to add a query function to make this simpler.

I think that's a fair point. Unnesting arrays in SQL can be annoying. Here is your first example with duckdb:

  duckdb -c \
    "select * from ( \
      select unnest(assets)->>'browser_download_url' as url \
      from read_json('https://api.github.com/repos/go-gitea/gitea/releases/latest') \
    ) \
    where url like '%linux-amd64'"

Hi, I’m the author of the blog post.

> And it is bizarre to me that you could run a payments system without high-availability or immutability at its core.

I’m not sure what you’re referring to here as my post didn’t really go into these topics.

> Also putting logs in a database alongside your core data is such a bad idea.

I’m not suggesting putting all logs into the database. I’m suggesting that for a certain type of info (that is often logged), I find it more useful to put it in the database instead.

It was also covered in: https://www.braintreepayments.com/blog/switching-datacenters...

You can link your bank account with Venmo, and then use Venmo Payouts: https://venmo.com/payouts

Have you tried Braintree in the UK?

Slides available here: http://www.pgrs.net/wp-content/uploads/2013/02/rubyconf_aust...

The broxy also adds more functionality, such as intelligent rate limiting by merchant (no one merchant can consume all of our backend app processes).

(Disclosure - I also work at Braintree)

They have one: https://www.namecheap.com/other/affiliates.aspx

HL7 v3 is xml: https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3

We have a few different types of auditing information. At that point in the timeline, it was all in PostgreSQL. Today, we keep only the critical auditing information in the main database.

For the first few years, we scaled vertically rather than horizontally. We still went through many rounds of scaling our single server, changing both hardware and software configs.

We were reluctant to do automatic failover as well, since we all hear horror stories about automatic failover causing more problems than it solves. However, we changed our minds this summer for a couple of reasons. One, our traffic continues to grow and people rely on us for payments. If our database server crashes in the middle of the night, we don't want our customers to have to wait for us to do manual failover. Two, we felt a lot more comfortable with Pacemaker and PostgreSQL streaming replication failover than we used to with DRBD. We did extensive testing and tweaking, and we believe we understand the failure scenarios.

One of the best metrics is the log of slow queries. We set our threshold at 250 milliseconds, and we investigate queries that take longer. Sometimes, we'll see INSERT or COMMIT statements show up, which is usually an indication that our write performance isn't what it needs to be. We generate graphs from these logs (using graphite) and track them over time. We also use Munin (including the PostgreSQL plugins) to monitor disk IO and various PostgreSQL stats.

To be safe, we always rebuild the old master after we fail over to a synchronous standby server. We have capistrano tasks to automate it, so it's not too bad. The async servers merely follow the new server after the IP moves, so we don't need to do anything there.

Edit: We also don't increment the timeline on failover. Instead, we stop PostgreSQL, remove the recovery.conf, and restart.

Besides client side (javascript) encryption, Braintree supports Transparent Redirect (https://www.braintreepayments.com/developers/api-overview) which lets you post data directly to Braintree.

The nice part of sending the data to your servers with client side encryption is that you can do validation before sending to the payment gateway. For example, if you want to ensure everyone enters a cardholder name, you can validate the non-encrypted fields before eating the cost of calling a payment gateway.

You can do some of these validations in javascript, but javascript is error-prone (firebug) and not as flexible (have access to a lot more data server side).

We do use the sandbox and production git branches for those environments. If you want to puppet sandbox, you start with a git checkout sandbox. If you try to puppet sandbox from the production or master branch, you get a big warning and a prompt asking if you are really sure.

You should read the Dynamo paper: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.h...

The ring is first explained in Section 4.2 Partitioning Algorithm.

"I was released from federal prison on January 21, 2000, just 6 weeks ago."

Is the replica set failover really zero-downtime for you? In our usage, it seems like it takes a few seconds to elect a new primary during which time no writes can occur.

Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.

I actually just wrote up a blog post as well about why I don't like feature branches: http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branc...

My main reasons are that git history gets messy, builds don't run on feature branches (although github seems to have a work around here), and refactoring is harder.

My opinions are largely based on working on larger projects (more than 10 devs working in the same codebase).

Fastdev makes the Android Emulator usable: http://developer.appcelerator.com/blog/2011/05/titanium-mobi...

After you suffer the initial emulator load, changes appear in the app by simply bouncing the app. It's one big win for Titanium.

If you don't version, you can only add to an API. You cannot change anything meaningful (or as simple as renaming a field). You wind up with APIs with multiple ways of getting the same or similar data in order to avoid breaking backwards compatibility, which leads to bloated, confusing APIs.

Nice pun!

Here are a few extra tips:

- "select relname, indexrelname, idx_scan from pg_stat_user_indexes" will show how many times an index is used, so you can remove unused indexes

- you can create indexes without locking tables (ie, while your site is up) by using "create index concurrently"

- you should use the autovaccuum daemon instead of manually running vacuum analyze in most cases

If you are sharing with other people, something like encfs would be better:

http://www.arg0.net/encfsintro

Encfs encrypts file by file, so you do not have to worry about multiple people editing (and possibly corrupting) one giant file.