ولی جدی بنظرم اینکارو با Rust انجام میدادن نتیجه خیلی بهتری میگرفتن :)

Architectural Decision Records (ADRs) are documents that capture important architectural decisions made during a project.

They provide a structured way to document the context, rationale, and implications of key decisions, ensuring that the reasoning behind those decisions is preserved and communicated to stakeholders, team members, and future maintainers.

An ADR typically includes the following sections:

1. Title: A concise and descriptive name for the decision.

2. Status: The current state of the decision (e.g., proposed, accepted, deprecated, superseded).

3. Context: The background or problem that necessitated the decision. This includes the circumstances, constraints, and requirements that influenced the decision.

4. Decision: A clear statement of the decision that was made.

5. Rationale: The reasoning behind the decision, including trade-offs, alternatives considered, and why this decision was chosen over others.

6. Consequences: The expected or observed outcomes of the decision, including benefits, drawbacks, and potential risks.

7. Alternatives: Other options that were considered and why they were rejected.

8. Related Decisions: Links to other ADRs or decisions that are relevant to this one.

9. References: Any supporting materials, such as documents, diagrams, or discussions.

When to Use ADRs?

1. Long-term projects where team members may change over time.

2. Complex systems where architectural decisions have significant implications.

3. Open-source projects where contributors need to understand the reasoning behind decisions.

4. Teams that value documentation and knowledge sharing.

ADR Tools you need to know

1. https://github.com/npryce/adr-tools

2. https://github.com/adr/madr

#software_architecture #architecture_design

What is Architecture Governance?

Architecture governance refers to the framework and processes that ensure an organization's IT architecture aligns with its business goals, complies with regulations, and maintains consistency, quality, and scalability. It involves:

- Defining and enforcing architectural principles, standards, and guidelines.

- Ensuring compliance with organizational and regulatory requirements.

- Managing risks associated with architectural decisions.

- Providing oversight and accountability for architectural changes.

Static vs Dynamic Coupling Concept in Software Architecture

🔹 Static Coupling:

Static coupling refers to the dependencies between modules or components that are evident at compile time or through the source code structure. It is determined by analyzing the code without executing it.

1. Visible in Code: Static coupling is visible in the source code, such as through class inheritance, method calls, or import statements.

2. Compile-Time Dependency: It represents dependencies that are resolved during compilation.

3. Impact: High static coupling can make the system rigid and harder to modify because changes in one module may require changes in dependent modules. Low static coupling promotes modularity and easier maintenance.

Example of static coupling:

// Class A is statically coupled to Class B
class A {
void method() {
B b = new B();
b.doSomething();
}
}

class B {
void doSomething() {
System.out.println("Doing something");
}
}

🔸 Dynamic Coupling

Dynamic coupling refers to the dependencies between modules or components that arise during runtime. It is not visible in the source code and depends on the execution flow of the program.

1. Runtime Dependency: Dynamic coupling is determined by how components interact during the execution of the program.

2. Not Visible in Code: It cannot be fully understood by just analyzing the source code; runtime behavior must be observed.

3. Impact: High dynamic coupling can make the system harder to debug and test because dependencies are not explicit in the code. Proper management of dynamic coupling (e.g., through design patterns like dependency injection) can improve flexibility and testability.

Example of dynamic coupling:

// Dynamic coupling through polymorphism
interface Service {
void execute();
}

class ServiceA implements Service {
public void execute() {
System.out.println("Service A");
}
}

class ServiceB implements Service {
public void execute() {
System.out.println("Service B");
}
}

class Client {
private Service service;

// Dependency injection (dynamic coupling)
public Client(Service service) {
this.service = service;
}

void performTask() {
service.execute();
}
}

// Runtime behavior determines which service is used
public class Main {
public static void main(String[] args) {
Service service = new ServiceA(); // Could be ServiceB at runtime
Client client = new Client(service);
client.performTask();
}
}

🔺 What is Architecture Quantum?

An architecture quantum is a self-contained, independently deployable unit of software that includes all the necessary components to deliver a specific functionality.

It is the smallest unit of architecture that can stand alone and operate independently. Key characteristics of an architecture quantum include:

1. Independently Deployable: It can be deployed without requiring changes to other parts of the system.

2. Self-Contained: It includes all the necessary components (e.g., code, data, configuration) to function.

3. Autonomous: It operates independently and does not rely on other quanta for its core functionality.

4. Scalable: It can be scaled independently of other quanta.

5. Aligned to Business Capabilities: It typically corresponds to a specific business capability or domain.

پروفسور دانشگاه استنفورد John Ousterhout راجب فلسفه معماری نرم افزار و اهمیت آن صحبت میکند. همینطور راجب کتابی که در همین موضوع نوشته است. جان بر این باور هست که برنامه نویس های خوب میتونن تعلیم داده بشن.

یکی از کار های مهم و بزرگ ایشون برگذار کردن کورس هایی در دانشگاه است که دانشجویان به نوشتن پروژه مختلف های مختلف با domain های مختلف میپردازند. و در نهایت جان به خواندن و تحلیل آن کد ها از منظر معماری نرم افزار میپردازد :)

https://youtu.be/bmSAYlu0NcY?si=Nusz7U8mLId_D4gG

این کتاب واقعا العاده ست! clue هایی که میده رو واقعا useful یافتم.

تو این ویدیو هم نویسنده ش Mark Richards راجب :

Difference between Atomic vs Eventual Transactions

حرف میزنه.

https://www.youtube.com/watch?v=trmwHdumBrs

پ.ن: این کتاب بشدت پیشنهادیه :)

Orchestration vs Choreography Coordination

▫️Orchestration:

1. Centralized Control: Orchestration involves a central component (the "orchestrator") that dictates the flow of interactions between services. This orchestrator is responsible for telling each service what to do and when to do it.

2. Command-Driven: The orchestrator issues commands to the services, instructing them to perform specific actions.  

3. Characteristics:

3.1: Provides clear visibility into the workflow.

3.2: Simplifies error handling, as the orchestrator can manage retries and compensations.  

3.3: Can introduce a single point of failure if the orchestrator fails.  

3.4: Can lead to tighter coupling between the orchestrator and the services.

4. Analogy: A conductor leading an orchestra, telling each musician when to play.

▫️Choreography:

1. Decentralized Control: Choreography relies on services communicating with each other through events. Each service is responsible for knowing when to act based on the events it receives.
There is no central coordinator.

2. Event-Driven: Services publish events when they complete a task, and other services subscribe to those events.

3. Characteristics:

3.1: Promotes loose coupling between services.  

3.2: Increases system resilience, as there is no single point of failure.  

3.3: Can make it more difficult to track the overall workflow.

3.4: Can make debugging and troubleshooting more challenging.

4. Analogy: A group of dancers who know their parts and perform together without a leader, responding to each other's movements.

◾️Choosing Between Them:

The choice between orchestration and choreography depends on the specific needs of the application.

- Orchestration is often preferred for complex workflows that require strict control and visibility.

- Choreography is often preferred for highly scalable and resilient systems where loose coupling is essential.  

It is also possible to use a hybrid approach, combining elements of both orchestration and choreography.

این ها پارامتر هایی ست که Software Architect موقع دیزاین معماری یک نرم افزار در نظر میگیرد که راجب ارتباط میان سرویس ها (Communication) و استحکام سرویس ها از نظر ساختاری (Consistency) و هم پایگی (Coordination) آن ها است.

انتخاب هر کدام ازین ها یک trade-off است و اینطور نیست که انتخاب یکی از ان ها بهترین سولوشن ممکن باشد.

یک کورس آموزشی Go از طرف شرکت محبوب RedHat. از دستش ندید‌ :)

https://github.com/RedHatOfficial/GoCourse

برا ویندوز هم tiling window manager ساختن :)

https://github.com/LGUG2Z/komorebi

شایدم میدونستید من نمیدونستم.
ولی خیلی باحاله :>

پ.ن: عیدتونم مبارک❤️🤌🏿

یه HttpRouter خیلی ساده با C ساختم🙂🤌🏿

هدف یادگیری بود که با موفقیت انجام شد.
اگه خواستید میتونید ریپو شو چک کنید :

https://github.com/tahadostifam/HttpRouter-C

یه کد ادیتوری هست به اسم Helix که واقعا منو شگفت زده کرده :)

این ادیتور با Rust نوشته شده و شباهت زیادی به neovim داره. فقط خوبی ش اینه که کانفیگ دیفالتش خیلی خوبه. اونقد خوبه که نیاز نیست انگولکش بکنید... همینطوری اوکیه.

از اکثر LSP های زبونا ساپورت میکنه. از امتحان کردنش پشیمون نمیشید :)

منم یه تم شخصی ساختم که توی تصویر میبینید. اینجا میتونید سورس ش رو پیدا کنید :

https://github.com/tahadostifam/TahaOS/tree/main/home-manager/modules/helix

پ.ن: بنظر خودم هلیکس اندازه GNU Emacs و Neovim باحاله :) ❤️🤌🏿

Helix Official Website:
https://helix-editor.com

این همون کتاب که راجبش میگفتم،
متاسفانه من قبلا خوندمش :)

و اما بلاخره! PR ای که برای c3 lang باز کرده بودم مرج شد :)
هدف این بود که مشارکت رسمی م رو روی این زبان اغاز کنم و از لحاض معنوی انگیزه ای باشه برای بیشتر کار کردن رو این پروژه فوق العاده.

امروز مرج شد :]

https://github.com/c3lang/c3c/pull/2055

چطور شد اینطور شد؟😜
یه مدت داکیومنت ش رو داشتم میخوندم و حتی یادتون باشه یه lz4 هم بایند کردیم براش و اونم مرج شد توی vendor ش. موقع خوندن سورس کد کامپایلرش به لطف comment anchors توی vscode این تودو رو دیدم. که میگفت موقع vendor-fetch یا همون دریافت پکیج های third party به یه progress bar نیاز داریم.

خب.. خداروشکر که تسک آسونی بود😂🤌🏿
دم عیدی اتفاق خوشحال کننده ای بود برام.

در آینده امیدوارم مشارکت های عمیق تری روی این پروژه انجام بدم.
به امید مشارکت های عمیق😋🍻

#c3 #programming_languages

Super cool $_$

https://www.youtube.com/watch?v=HcuDmSb-JBU

ما سنمون قد نمیده ولی یه زمونی یک زبان برنامه نویسی وجود داشت به نام D که با عنوان DasBetterC شناخته میشد.

این زبان تو سال 2001 توسط Walter Bright ساخته شد که یک زبان high level و system programming همانند C و ++C است. این زبان ساخته شده بود تا پرفرمنس بالا و کنترل روی low level ارائه بده. و در عین حال productivity و safety ای که python و java داشتن رو هم ارائه کنه.
چون D پرفرمنس خوبی ارائه میده برای اپلیکیشن های performance-critical مثل game engines و real-time systems و high-frequency trading مناسبه. و جالبه بدونید که D از GC و scope based memory management استفاده میکنه :)

همچنین فیچر هایی داره که به detect کردن buffer overflow و memory leak کمک میکنه. باید بگم با اینکه D در واقع ۲۴ سالشه (تقریبا همسن #C) سینتکس مدرن و خوانایی رو ارائه میده. از Concurrency ساپورت میکنه بوسیله Fiber ها و همینطور از مکانیزم های message passing و immutable data structure ساپورت میکنه.

این زبان فوق العاده interoperability فوق العاده ای با C و ++C و Objective-C و Python داره. و همینطور cross-platform هست. درکل هدفش productive and safe systems programming language بوده و همچنان کامیونیتی ش زنده ست.

چیزای جالب و بامزه ای هم راجبش وجود داره :)
مثلا اینکه دوتا stdlib داره😂🤷 با نام های Phobos و Tango.

این هم یک program ساده با زبان جذاب D :

import std.stdio;

void main() {
string name = "D Programming Language";
writeln("Hello, ", name);

// Type inference with 'auto'
auto number = 42;
writeln("The answer is: ", number);
}

#programming_languages