-
First principles methodology in AI by Aristotle – 5 step framework
First principles methodology is the practice of breaking a problem down to its most fundamental truths. What we know to be the absolute truth(s). Then we try reasoning upward to build new solutions with what we know to be the fundament. Instead of copying what’s been done before ( haha, said no developer ever). This methodology goes back to Aristotle, the ancient Greek philosopher who first articulated the idea of reasoning from “first principles.” What Is a First Principle? A first principle is a basic, foundational truth that cannot be deduced from anything else. It’s the bedrock of a problem: In AI, first principles might be: Anything else like framework…
-
Why bother with Vue composables – 6 reasons to do
Why bother with Vue composables ? So it will make our lifes easier, more straightforward coding and simplified testing to say the least. Composables in Vue.js are functions that encapsulate business logic and allow it to be reused across different components. Your regular dependency inversion, composition or what ever You want to call it. Designed to make it all simple and pleasurable. Why Use Composables? Reusability Composables encapsulate logic that can be reused in multiple components. One ring to rule them all. One place to change them and in a component bind them. Something like pinia store. For example, if geospatial filtering logic is needed in more than one place,…
-
When to use Value Objects in database
Question when to use value objects in database is usually discussed during storing a new set of data. Usage of value objects should be considered while modeling abstractions that are constant / immutable and do not require unique identity. Examples can be: geospatial data, estate addresses or any categories that belong to an entity. VO also encapsulates validation logic and business rules. Helps to avoid raw strings or magic numbers. When to use it and its benefits How to map a value object in db Scenario Mapping Benefit Embed Columns in parent table (Street, City in Address) Fast reads, no joins Complex nesting JSONB/PostgreSQL or owned entities Flexible schema, validation…
-
Law of Demeter in programming
Law of Demeter in programming You could in short paraphrase as “Don’t talk to strangers!” or “Keep Your hands in your pockets”. A class needing data from a deep chain of objects like – user.getAddress().getStreet().getNumber().It is visible very often in OOP, less in functional approachess ! The Law of Demeter states that method only knows its closest dependencies: itself, passed parameters, created objects, and own fields. Should not be used with dot chains ( they were so fancy when we started Java 8 back in the day). What to Remember? Where Law of Demeter comes from ? Why Demeter ? The Law of Demeter in progamming takes its name from…
-
How to delete code – the story of interface
How to Delete Code: The Interface Story How to delete code, safely of course, is usually a major problem. Difficult and You always second guess every decision because You don’t know what You don’t know. It is not just hitting the “delete” button. You need to make a smart decision and second guess your solution. How to remove unnecessary code with a focus ? Refactor the code, use interfaces and then test it twice remembering about user experience. TL; DR 😉 Define one interface. Create two implementations – legacy, modern and any other. Unify! Use it in already existing services or create such services by refactoring code. Switch between them…
-
Lauers Law – why less code is better
Lauers Law – why less code is better as a very solid idea. Just remind Yourself about all those DTOs that could be a simpler one with a mapper or a dedicated if-else-tree somewhere around data transformation. It challenges developers to prioritize efficiency and elegance in their coding practices, ultimately leading to cleaner, easier to understand and more maintainable systems. The Essence of Lauer’s Law At its core, Lauer’s Law emphasizes that reducing the amount of code can lead to better outcomes. The principle suggests that if developers had twice as much time, they could create a system with half the code while maintaining or improving its quality. The idea…
-
The philosophy of unix – 9 commandments
The philosophy of unix is a guideline of standards and software design & philosophy approaches : Elaboration : The philosophy of unix is a universal approach to any development, not only software 😉
-
Premature optimization is the root of all evil and the lesson from Duke Nukem Forever
“Premature optimization is the root of all evil.” as famously stated by Donald Knuth. This principle highlights the dangers of focusing on performance improvements too early in the development process. While optimization is essential in software engineering, prioritizing it before establishing a clear and functional design often leads to unnecessary complexity, inefficiency, and even failure. The story of Duke Nukem Forever, a sequel to a great game that was to be even better spent over 15 years in development hell. Did it make it ? Serves now as a tale of how premature optimization and feature obsession can derail a project. Someone was here obviously “Out of touch”. Knuth’s Rule:…
-
Chestertone`s Fence in coding and not only
The Chestertone`s Fence in coding is the principle named after the writer G.K. Chesterton. Serves as a critical reminder in programming and software development: before removing or altering existing code, one must understand why it was implemented in the first place. This principle is universal for life. Emphasizes the importance of historical context and the potential consequences of change, especially a quick and fast one. Urging developers to approach modifications with caution and respect for prior decisions. Even if they are unknown or seem meaningless. Understanding the Chesterton`s Fence Chesterton`s Fence principle, at its core, suggests that every piece of code, no matter how outdated or unnecessary it may seem,…
-
A Philosophy of Software Design by John Ousterhout – review
A Philosophy of Software Design by John Ousterhout is a great book. Period. I would say that it is a great additional to reading Clean Code. Clean code in my opinion is dry and very… strict ? Not much room to fiddle around with rules set by Uncle Bob the Guardian of the Clean Code. John Ousterhout provides us with a more kind and flexible approach without strict, dry rules to follow. Since the book was wrote by a professor at Stanford that had classes it might get a bit technical when John goes through the different code sets but it does print a better picture of the whole problem.…
