HN user

aeinbu

29 karma
Posts3
Comments10
View on HN

That is not the only other alternative.

You can do A/B testing splitting up your audience in groups, having some audience use A, and others use B - all the time.

I think the article’s author is frustrated over sometimes getting A and at other times B, and not knowing when he is on either.

I always use VS Code for this step. Its merge conflict UI is the clearest I’ve found: it shows “Accept Current Change,” “Accept Incoming Change,” “Accept Both Changes,” and “Compare Changes” buttons right above each conflict.

I still get confused by vscode’s changing the terms used by Git. «Current» vs «incoming» are not clear, and can be understood to mean two different things.

- Is “current” what is on the branch I am rebasing on? Or is it my code? (It’s my code)

- Is “incoming” the code I’m adding to the repo? Or is it what i am rebasing on to? (Again, the latter is correct)

I find that many tools are trying to make Git easier to understand, but changing the terms is not so helpful. Since different tools seldom change to the same words, it just clutters any attempts to search for coherent information.

Progressive JSON 1 year ago

I was asking the same questions.

- FE is short for the Front End (UI)

- BFF is short for Backend For Frontend

As implemented, you’ll now need to implement a ton of custom logic for the necessary data transforms. With Postgres, there’s a really good chance you could do all of that by manipulating the backups with a few lines of SQL.

Isn’t writing «a few Lines of SQL» also custom logic? The difference is just the language.

It is also possible that the custom data store is more easily manipulated with other languages than SQL.

SQL really is great for manipulating data, but not all relational databases are easy to work with.