51–60 of 336 posts
Might obviate the update and pray nature of SemVer. You should still have comprehensive test though.
Mongoid docs[1] seem to be pretty cool about this change: "As of Mongoid 7.1, logical operators (and, or, nor and not) have been changed to have the the same semantics as those of ActiveRecord. To obtain the semantics of or as it behaved in Mongoid 7.0 and earlier, use any_of which is described below." Is it just me or is this one of the most terrible breaking changes in a popular, official library ever? [1] https://…
Of note -- their company services seem to be that you pay them to return you Google search results via API. Isn't that against the Google search Terms of Service??? If google wanted there to be a paid search api, I'm pretty sure they would just provide one. Also, I'm pretty sure I've seen these types of startups before, and then they vanish quickly thereafter....
Serpapi definitely did the right thing here. Shame on the maintainers for introducing such a breaking change in a minor version update. I guess the takeaways are: - review change logs for any gems that are updated - have extensive test cases for anything that charges customers Hindsight is always 20/20 of course.
> Our app for some reasons was creating new subscriptions from old accounts that was canceled or disabled a long time ago. If I cancel or disable my account for a service I don't expect them to be able to charge me money in the first place! Are they keeping card authorisations (or direct debit mandates, or whatever other mechanism) for customers that don't even have an account with them any more? That sounds like an.…
For the vast majority of cases all you need to charge a card is the 16 digit number on the front and an expiry date. Pretty much everything else is optional (CVV, Name, Address etc), but opens you up to stupid levels of liability in the disputes process if you didn’t include it in the original payment request.
Earlier quoted context omitted.
I can't explain for the other user but I'll tack on my own little horror story. I once got the task of porting something written for early nodejs that used MongoDB as a backend to Django. The app had been developed by a contractor and had many iterations of the data layer. I had to somehow make sense of how to make that all fit in a relational database. The changes made were not documented at all and I didn't have ti…
RDBMS are the solution to many of the problems that these 'modern' systems have, but it isn't cool. Someone joked that the wave of the future will be SQL, and that those start-ups that use it will believe that they have superpowers over the ones that don't. Transactional integrity, complex queries, constraints, what's not to like?
Earlier quoted context omitted.
They fixed the issue, reversed everything, wrote a detailed explanation of what happened and apologized to their users. I don't think you can expect much better than this to be honest?
I’m not blaming them: I’m saying that if I was in this position, I’d ban the Mongo library used.
> Our app for some reasons was creating new subscriptions from old accounts that was canceled or disabled a long time ago. If I cancel or disable my account for a service I don't expect them to be able to charge me money in the first place! Are they keeping card authorisations (or direct debit mandates, or whatever other mechanism) for customers that don't even have an account with them any more? That sounds like an.…
They don’t need to keep anything. The card details will be stored with Stripe, if they don’t actively tell Stripe to delete those details then they’ll be able to create a new subscription and charge the card. For the vast majority of cases all you need to charge a card is the 16 digit number on the front and an expiry date. Pretty much everything else is optional (CVV, Name, Address etc), but opens you up to stupid l…