121–130 of 214 posts
Cool list! For Django developers I've compiled a list of Django guidelines that also contains a lot of yagni exceptions especially for Django: https://www.spapas.net/2022/09/28/django-guidelines/
One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes.
For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning as well. This can be a problem with hard deletes and with soft deletes. With soft deletes, well, it's hard to figure out how to actually delete things if you've been growing a data model with soft deletes for a couple of years. With hard deletes, well, after you apply some hacks to prevent cascading deletes from killing your performance, now you're in the same place. Maybe worse if your foreign keys are no longer an exhaustive guide to relationships. "Right to be forgotten" will be a nightmare if it hasn't been designed in from the start. Obviously not every kind of business will have to worry about this, but I think the ones that do should consider putting some effort into making sure their design supports it.
Cool list! For Django developers I've compiled a list of Django guidelines that also contains a lot of yagni exceptions especially for Django: https://www.spapas.net/2022/09/28/django-guidelines/
Clicked on the link expecting to see the usual beginners advices, but I'm plaisantly surprised that I would give most of the same recommendations to my team.
Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…
In some other stack, setting up good logging can be annoying and I understand you wanna take the shortcut.
Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…
While for some fact tables (time series) it is easy to implement the soft deletes, for other dynamic workloads (e.g. when both fact tables and dimension tables are updated) it can become a messy nightmare to keep the referential integrity up-to-date with the dangling soft-deleted records.
Sometimes it will be difficult to decide if the long-ago soft-deleted record should be maintained, if the dimension is maintained.
Earlier quoted context omitted.
>I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice. We do it all the time as the industry. We do web dev in langs like c# java instead of c cpp Even despite the fact that cpp is capable of returning html text just fine. >Working with a schemaless 'nosql' database is only faster if you're skipping the part where you think…
How about the using nosql by default to enable rapid development and sql when theres a need for it? My point is that the development speed for nosql should be roughly the same as for relational databases, because you should be spending the same amount of time thinking about your data. The database you use is almost incidental. Whether you choose to create a users table in Postgres and make sure the data is valid ther…
If other app touches my database in write mode and modifies the structure by mistake, then it is relatively good scenerio because the problem is easy to notice In compare to messing with data e.g account balance += 200
And relational db without some hardcore constrains / triggers do not check it
I'd still rather have that code in app
>My point is that the development speed for nosql should be roughly the same as for relational databases, because you should be spending the same amount of time thinking about your data. The database you use is almost incidental. Whether you choose to create a users table in Postgres and make sure the data is valid there or whether you choose to create a JSON object in MongoDB and make sure the data is valid in the application logic doesn't matter - the hard, and the bit you should be spending time thinking about what does 'correct' mean for this set of data.
Thats in theory
In practice it always took me more time to setup postgre mssql and initial system model
Than when using mongo
Ive always used relational dbs but Ive started wondering whether I should start using nosqls in real world scenerios
YAGNI is about avoiding premature optimisation. A lot of these make sense. But they always do. And the road to shipping hell is paved in good architectural practices. To ship a first version of a product, we always need to cut corners. Deep, horrible, painful, cuts. Because if we spent the time to make the perfect product, we'd launch too late. A lot of these YAGNI things are not "you're never going to need it", but…
If adding these things really slows your ability to ship the first version of your product, you need to fire your team and start with a new one. These PAGNIs are: 1. log.info() calls 2. apt-get install postgresql 3. Using timestamp and datetime.now() instead of boolean fields 4. Adding a /v1/ into your API endpoints I'm being serious. If your team says "this will add a week onto the release date" then your team is ei…
Adding Postgres is a no-brainer. Totally agree. But should you architect the database properly? It's going to be tricky to normalise data later, maybe we should start with properly normalised tables now, instead of jamming everything into a jsonb field?
Versioning, sure, but does every API need a version? If so, shouldn't we write some standard code for versioning all the things? Should the CICD process version the system automatically? Talking of which, we should set up the CICD. There's a rabbit hole.
These things are all good, definitely worthwhile, but where do you draw the line? If we spend a couple of days doing X, then it becomes worthwhile spending a couple of days doing X+1, and so on. The author drew the line here. But that's not the only place you can draw the line. You can draw it a few paces back too.
There's always a temptation as a techie to add a couple of days now to save a couple of weeks or months later. That may not be the right commercial decision.