151–160 of 247 posts
Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.
I always get a kick out of the posts from the people in language communities who post "I'm new to , what framework should I use?" It's like asking "I'm new to driving, what brand of nitros should I be using" Nah dude, get your sea legs first
The first question I posed to the Erlang community was exactly that: what are the build tools, what are the unit testing frameworks and how is a project setup.
Not because I didn’t know what these tool/concepts did but because I wanted to know what is the state of the art in Erlang tooling.
I have my sea legs, including the wooden one, but just not yet in Erlang. Why Erlang? Because it’s completely different to everything else!
Earlier quoted context omitted.
Basically they’re saying implicitly to be principled about adopting frameworks and other dependencies, evaluating whether they’re needed for one’s project before adopting them. It’s a pretty thought provoking post, even if it may be too subtle for some folks.
No need for the random snark? I mean, again, we're in extremely obvious territory here. Just doesn't seem appropriate for hacker news front-page (to me).
Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.
table=db.table("table1")
table.insert({"col1": val1, "col2": val2})
ORMs and related toolkits have come a long way since they were called the "Vietnam of Computer Science". I am a big fan of JooQ in Java
and SQLAlchemy in Python
Note both of these support both an object SQL mapper (usually with generated objects) that covers the case of my code sample above, and a DSL for SQL inside the host language which is delightful if you want to do code generation to make query builders and stuff like that. I work on a very complex search interface which builds out joins, subqueries, recursive CTEs, you name it, and the code is pretty easy to maintain.
I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?
The more code, the more assumptions.
Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.
Turns out though my first assumption was wrong.
Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.
Earlier quoted context omitted.
Yes run updates of course. The question is how much of a headache you want. You can: Use Next.js (frequently changing lots of transitive deps, suffers from Node ecosystem churn too) Roll your own framework OR (FANFARE....) Use simpler arguably more professional tools. That 10 year old .NET MVC site. Guess what. Still works. Still secure.
10 year old .NET is running on a Windows server that, I hope, you've done some security updates on. Having worked on most web facing stacks out there that might have been the worst one you could have picked as a "future proof" deployment, unless you're comparing them all as something you release once and then never touch again.
Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.
Inspect the actual SQL query generated, and if needed modify ORM code or write a SQL query from scratch.
Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.
Object-relational mapping (ORM) is a key concept in the field of Database Management Systems (DBMS), addressing the bridge between the object-oriented programming approach and relational databases. ORM is critical in data interaction simplification, code optimization, and smooth blending of applications and databases. The purpose of this article is to explain ORM, covering its basic principles, benefits, and importance in modern software development.
Earlier quoted context omitted.
> Is self-control in coding just a lost art now? Yes; a lot of people don't code because they need to make something work, they code for the joy of it. When the software they need to write is boring or solved - like another CRUD app, front- or back-end - instead of picking the boring and easy to build and comprehend languages and frameworks, they will make it interesting for themselves. Learn a new language, framewor…
> they will make it interesting for themselves. Engineers love to solve problems. If there are no problems readily at hand, they will create some.