It’s a small post with an overview of the articles I wrote during this year.
A couple of days ago, a nice analogy came to mind which I thought would be an interesting one to share: early exit is essentially a tail call optimization of procedural languages. Let’s see how it is so.
Regions feature in C# is frowned upon by many. There are good reasons for that. In this post, I’d like to discuss why exactly you should avoid using them.
Do you need an ORM for your project given you use a relational database? And not just some lightweight like Dapper but a big one: NHibernate, Entity Framework, Hibernate? I’d like to address this question with this post.
In this post, I’d like to make a comparison of two approaches that prevail in the world of (mostly enterprise) software development: domain-centric and data-centric.
If you read my last post (or any other post, quite frankly), you might have noticed I personally gravitate towards the domain-centric approach. Although this article is intended to be an impartial one, keep in mind that my bias can leak out.
<TL;DR> No, it isn’t. While SQL is a Turing-complete language and we can use it to encode any business logic we want, placing business (domain) logic into SQL leads to a less maintainable solution comparing to one that uses an OO or functional language. Because of that, I advocate to limit the use of SQL to read-only queries (which can potentially contain business logic, that’s fine) and simple CRUD statements where possible.</TL;DR>
The dispute regarding whether or not one should place business logic in SQL takes place for as long as I can remember. It’s much less active these days, but still exists, so let’s elaborate on the details here.
The concept of NoSQL databases has been around for a while, but there still are quite a few misunderstandings regarding the topic of relational SQL vs NoSQL databases. In this post, I’d like to clarify the most common misconceptions and discuss the primary use cases for each of them.
Most of us agree that in many cases following best practices leads to better code. Namely, it decreases the complexity and allows us to reason about even large software systems easier.
But why is that so, exactly? Today, we’ll take two design principles – separation of concerns and immutability – and see how (and why!) they decrease the complexity of the code.
When you enter some field as a novice, there is a lot of stuff you must learn in order to become proficient in it. The learning path can usually be broken down into 4 stages of competence which you can traverse in 2 different ways.
I’d like to wrap up the “Most valuable software development principles” article series with this post.