https://www.youtube.com/watch?v=U6s2pdxebSo&ab_channel=OfferZenOrigins

YouTube

TypeScript Origins: The Documentary

TypeScript Origins: The Documentary features core contributors like Anders Hejlsberg, Daniel Rosenwasser, Ryan Cavanaugh, Luke Hoban, Amanda Silver, Matt Pocock, Josh Goldberg & many more! It also covers adoption stories and insights from JetBrains, Xata…

Hi there!There have not been published posts for more than a month. I want to tell you why I haven't written any article at that period and what I am planning right now. During this period, I made several decisions for my present and future years. I have stopped researching topics related to software architecture. I think I am a bit bored with those topics. I have been studying topics related to system architecture. Before I started it, I had acquired knowledge related to software architecture, including DDD, EDD, Clean Architecture, Hexagonal Architecture etc. But right now I reckon these are good enough for me to move my career on towards a software architect position in the future. There are plenty of reasons why I came to that decision. But I don't think it's time to write about these things here. Overall, I am feeling good about learning system architecture, and learning what I am interested in.

This channel will directed to system architecture topics. I want to start from scratch about system architecture/design. I hope to publish posts related to this topic often. Also, a month ago, I conducted a poll to identify language that is comfortable for my audience. But I forgot there are foreign people on my channel. That is why, channel language won't be changed.

Upcoming topics:- Single-Tier Applications
- Two-Tier Applications
- Three-Tier Applications
- N-Tier Applications

@usmonmasudjonov

GRASPGRASP stands for General Responsibility Assignment Software Patterns / Principles. This article is dedicated to covering this topic. Today, most new developers talk about S.O.L.I.D principles blindly. I think they just learn this principle to pass interviews successfully. Before the S.O.L.I.D principle, there was a really popular perception called GRASP. It was dominant at the very time. Most developers today don't know about the principle and even they have never heard of it.

So what is GRASP? This principle includes several patterns including Creator, Information Expert, Low coupling, Controller, High Cohesion, Indirection, Polymorphism, Protected Variations, and Pure Fabrication. In this article, I will try to cover some of those which are mostly used. It is a suite of guidelines and principles used to design OO software and assign responsibilities to different classes and objects. These principles help developers build maintainable, flexible and understandable software systems by specifying clear roles and responsibilities to objects.

Creator Pattern. This principle states that classes should be responsible for creating other instances of another class if they have the necessary information to do that. This helps you remove unnecessary dependencies between classes. One example of this pattern is the factory pattern. Because this pattern will have any information to instantiate the instances of the class. Another example is order and line items. Line items should be created by order. Because none of the other classes would have information about the line item. (You might have noticed that the aggregate principle in DDD follows that principle).

Information Expert. You have to assign a responsibility to the class that has the most information required to satisfy that responsibility. It helps you decide where should put the responsibility. Above example suite for this one. For example, the total count of line items can be gathered through order instead of line item. This principle makes finding a place where is the best to do things easier.

Controller. This principle states that you have to assign the responsibility of managing and coordinating user actions to a dedicated controller class. It is all about the coupling and separation of concerns. I would say that correctly implemented layered and component-based architecture is an example of this pattern. Because domain objects shouldn't be dependent on some kind of layers. For example, you should be able to migrate from one database to another without worrying about other layers. Just you have to change only the persistence layer.

Low Coupling, High Cohesion. I don't want to write about those principles again, because if you scroll up, you can see two separate articles that cover those principles.

Protected Variations. Protect variations in the system by encapsulating the parts that are likely to change. This principle helps isolate changes and their impact on the rest of the system. Before I learned this principle, I had learned a kind of thing called "Encapsulate what varies". This helps to isolate things and reduce the impact of one thing on another one. This kind of thing is accomplished by using abstractions. You can think of this principle as the Single Responsibility principle of the S.O.L.I.D.

Indirection. Introduce indirection or intermediate classes to decouple two classes that should not directly depend on each other. This principle helps avoid direct dependencies, making the system more flexible. This is also done by putting abstractions. This principle provides you with low coupling.

Pure fabrications. It states that if you cannot find a place to put objects, it is a good idea to follow this principle. Create artificial or "pure fabrication" classes to centralize complex behavior not fitting into other classes. If you cannot find the place where your objects can stay, just create a separate component, module or something which has enough information to accomplish the result.

@usmonmasudjonov

I have been asked for a long time what channels I watch to be aware of cutting-edge technologies.

There are plenty of channels I can recommend actually. But mostly I favor reading articles, watching podcasts, and conferences. Here are the channels that are known as conferences I can share:

youtube.com/@GOTO-
youtube.com/@ICCQru
youtube.com/@HighLoadChannel
youtube.com/@cncf
youtube.com/@ieeeComputerSociety
youtube.com/@NDC
youtube.com/@cityjsconf

But as I mentioned, those are a few of the channels I watch. If I find enough time, I will share all websites and podcasts I can recommend.

@usmonmasudjonov

Fail-FastThis is a well-known principle widely applied in the software systems you use, distributed systems, microservices and so on. The main idea behind the fail-fast is to detect failures as soon as possible to reduce the impact of failure that leads to unexpected problems. This principle aims to limit the problems by responding or taking proper action. That helps you to avoid overheads.

Let's assume you use a database that accepts corrupted data regardless of predefined constraints. In that case, your overall data might be corrupted because of inserted data. That case is the opposite of the fail-fast principle. As soon as the corruption is detected, you have to take appropriate action or ignore requests in accordance with fail fast. That prevents the system from being fallen.

This principle consists of several key aspects, including early detection, immediate response, error reporting and etc. In order to prevent your system from failing, you should carefully follow those features.

Overall, the fail-fast principle promotes a proactive approach to dealing with failures. It is one of the critical principles to go down downtime, the possibility of data corruption and so on. You can see a lot of systems that follow this principle to leverage unexpected failures that might occur.

@usmonmasudjonov

I had been thinking about writing a post about KISS and YAGNI principles before deciding not to write a post about them. But I have found two great explained articles written in the Uzbek language.

Articles I have mentioned above:

- KISS
- YAGNI

An upcoming post will be related to the fail-fast principle.

@usmonmasudjonov

Don't repeat yourself

This principle is critical to building maintainable, scaleable, reusable software applications. This principle encourages you not to duplicate code that already exists. Repeating your functions might make your software application condition worse in case of reusability, and so on. Let's say you have an X function that does something. You are assigned to make Y function the same as X. If you do not use the existing X function or extend it, you are going the opposite of this principle. By eliminating redundant code, you can achieve high-quality code that other developers do not come across problems while they are updating it. Otherwise, changing minor functions might cause difficulties because of repetition. In my experience, I have seen a lot of junior developers who do not consider this principle important. As a result, they blame technologies or libraries. But in that case, the culprits are themselves. To sum up, every developer should follow this principle to build a software application that is easy to maintain, scale, and reuse.

@usmonmasudjonov

What is Dependency Inversion?As most of you know D.I. (Dependency Inversion) is one of the five S.O.L.I.D principles. It is a principle that promotes loose coupling between your classes, components and modules. It refines flexibility, reusability, etc. There are two main things that you have to follow:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

By following these concepts you can avoid tightly coupled code. It increases the flexibility, testability, and reusability of your classes, modules and components. Let's assume we have high-level modules that depend on low-level modules in our system. In this case, when we change low-level modules, there might be a demand to change high-level modules. This means it might prompt unexpected problems while you are changing your high-level modules. This reduces the flexibility of the system and your system becomes more difficult to maintain.

Applying dependency inversion in your code, you might avoid this kind of problem. You have to make sure that your high-level modules depended on abstractions (interfaces, abstract classes). Low-level modules should use these abstractions. It means that both of these should depend on abstraction that removes the coupling between them. While writing this kind of code is difficult and time-consuming, this makes your system quality better and provides you with better flexibility, reusability, modularity and so on.

This principle might not be easy to follow immediately as you learn. But I can explain one situation I have solved a problem by using D.I. There was a demand to send a notification, and developers implemented this cross-cutting concern in several parts of the system. It prompted several problems as a result of lying in some parts of the application. Such as duplication, tightly coupled and so on. I tried to solve this problem through a notification module. It was not a complete solution. Because we had undefined gateways that might be used as a notification provider. So I tried to solve this problem by implementing a strategy pattern. For example, I created an abstract class that defines some attributes of strategy. Also, I have created concrete strategies such as TelegramNotificationStrategy, and FireBaseNotificationStrategy. The notification module was the low-level module in our case. And the strategies were high-level modules. By doing this we have achieved flexibility. For example, we can use any notification service that we want without having problems. And changing one of these strategies doesn't affect others.

I think that would be a good example to understand this principle well. Please don't confuse D.I with Dependency Injection. (Dependency Inversion != Dependency Injection)@usmonmasudjonov

Why aren't the posts being published?

Because of some reasons (study & career), these days I am not able to write articles. And also I have started a new position in my career. That's why these days I am having trouble writing articles. But I promise this period does not continue for so long. There are lots of topics about Software Engineering and Computer Science I wanted to write about.

Note: I decided not to write posts in Uzbek further because of some problems. To express my opinions and technical topics better, I will start writing posts in English.

@usmonmasudjonov

Architectural Design Principles Yuqorida cohesion, coupling mavzulari tanishtirib o'tildi. Ular Architectural Design Principlelar hisoblanadi. Architectural design principles o'zi nima va nega kerak? Architectural Design Principle bu software developmentdagi…