If this requirement was in place they would be a bit more careful about terminating accounts because the cost equation would incentivize it. Maybe they would be more careful in their automation or require more than one level of human review before cutting off access.

These companies are gatekeepers for their platform. It isn’t crazy to require them to act more responsibly.

Apple’s real differentiator is their silicon. M series chips are just incredibly good and you get a full workday out of them on battery.

The M1 Pro I still have at work is easily the best laptop I have ever used. For side projects I use an M4 air with maxed out RAM and it has no issues with anything I have thrown at it.

I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.

Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.

Maybe that love, or at least liking something, comes from inherent talent to some degree but all the talent in the world won’t help you if you don’t put in the time.

I think you might have a bad one. See if support will do anything for you this is not normal.

There have been lots of instances of knowledge being rediscovered even when it was previously published but sitting on some shelf forgotten. LLMs ability to digest large volumes of data will I think help with this issue.

We will still need to reproduce and verify conclusions but will be interesting to see what might come from this.

It isn’t an apples to apples comparison. But, you trade some additional operational overhead for a whole lot more hardware.

Between threatening, and some actual military intervention, with Iran, Venezuela, Greenland, Canada, Denmark, Mexico, and itself the US is spread pretty thin at the moment. I think Canada will slowly open up to China and boil the frog if you will.

If they are smart about it then it will probably work out really well for them. They will need a new market for their oil, timber, ..etc since the US is no longer a reliable partner. This will take years but as long as China doesn’t do something dumb like invade Taiwan they can just sit back and win while the US is busy self destructing.

I say this as an American, also a veteran, who loves his country but hates what is currently going on.

EDIT: I may have read more into GPs post but on teams that I have been on that used merge commits we did this flow as well where we merged from main before a PR. Resolving conflicts in the feature branch. So that workflow isn’t unique to using rebase.

But using rebase to do this lets you later more easily rewrite history to cleanup the commits for the feature development.

All the commits for your feature get popped on top the commits you brought in from main. When you are putting together your PR you can more easily squash your commits together and fix up your commit history before putting it out for review.

It is a preference thing for sure but I fall into the atomic, self contained, commits camp and rebase workflows make that much cleaner in my opinion. I have worked with both on large teams and I like rebase more but each have their own tradeoffs

When I am ready to make my PR I delete my remote feature branch and then squash the commits. I can use all my granular commit comments to write a nice verbose comment for that squashed commit. Rarely I will have more than one commit if a user story was bigger than it should be. Usually this happens when more necessary work is discovered. At this stage each larger squashed commit is a fully complete change.

The audience for these commits is everyone who comes after me to look at this code. They aren’t interested in seeing it took me 10 commits to fix a test that only fails in a GitHub action runner. They want the final change with a descriptive commit description. Also if they need to port this change to an earlier release as a hotfix they know there is a single commit to cherry pick to bring in that change. They don’t need to go through that dev commit history to track it all down.

Replication and backups really aren’t that difficult to setup properly with something like Postgres. You can also expose metrics around this to setup alerting if replication lag goes beyond a threshold you set or a backup didn’t complete. You do need to periodically test your backups but that is also good practice.

I am not saying something like RDS doesn’t have value but you are paying a huge premium for it. Once you get to more steady state owning your database totally makes sense. A cluster of $10-20 VPSes with NVMe drives can get really good performance and will take you a lot farther than you might expect.

So just a crappy move from them then. Going to look hard at other options for all future purchases. Hopefully we get a reversal on this customer hostile stuff.