آینده توسعه وب یا چی؟
نظر خودمو بخواید میگم کمونیتیش به اندازه کافی بزرگ هست که بشه باهاش چیزی توسعه داد. سینتکسی که هم ارائه میده کار با جاوا اسکریپت و تایپ اسکریپت و اچ تی ام ال و سی اس اس رو همزمان آسون میکنه. integration فوق العاده ای داره.

https://rescript-lang.org

فایل منیجر بر پایه ترمینال. قابلیت ترکیب با neovim هم داره.

https://youtu.be/RgV47l59NYs?si=AFg3Cr1MHQ_tLw8V

ویدیو راجب integration test و unit test و mocking توی Rust هست.

https://youtu.be/8XaVlL3lObQ?si=9k_J2NAasdwwcwKn

لیستی از بهترین کتاب های Rust Programming Language:

https://github.com/sger/RustBooks

پ.ن: دانلود نداره*

بلخره اساس builtin func ها تموم شدن =)))
فعلا len و sizeof به خوبی داره کار میکنه.

و البته که از وقتی پارسر رو ریفکتور کردم کلی از مشکلاتش کمتر شده. هنوز یه چیزای کوچیکی باگ میخوره ولی خیلی کمتر شده. و هرچی پارسره درست درمون باشه بیشتر میوفتیم رو سرازیری فیچر دادن. چند ساعت پیش یه باگی خوردم... فکر میکردم از کامپایلره ولی بعد دیدم پارسر اصلا درست پارس نمیکنه که tree مناسب رو ارائه بده.

همینطور در نظر دارم اروم اروم داکیومنت هارو بنویسیم.
نوشتنش با منه.
ولی برای دولوپ وبسایت دنبال دولوپر فرانت میگردم (Tailwindcss).

Project Repo:
https://github.com/cyrus-lang/Cyrus-Lang

یه پروژه عالی که source-to-source transpiler هست و کد C رو تبدیل به کد unsafe Rust میکنه. فعلا زیاد استیبل نیست ولی ایده خفنی پشتشه.

Website:
https://c2rust.com

Repo:
https://github.com/immunant/c2rust

Minimal CMake: Learn the best bits of CMake to create and share your own libraries and applications (2025)

منتورم بلخره تو چنلم جوین داد. از بس ذوق زده شدم زدم ریمو شد. حالا بیا و جمش کن🥺😭🤦

📚 Kafka in Action.
#book

📚 The art of immutable architecture.
#book

📚 Software Architecture: The hard parts
#book

پ.ن: خوندن این کتاب از اوجب واجبات است برای دولوپرای بک اند

مایکروسافت داره Typescript رو از نو با Go پیاده سازی میکنه و بهبود چشمگیری در پرفرمنس کامپایلر دیده میشه که :
۱. مدت بیلد پروژه ها
۲. استارتاپ ادیتور
۳. مصرف مموری
کاهش یافته! و این حدود 8x و بیشتر هست :]

بنابر تخمینی که میزنند در انتهای 2025 ریلیز این پروژه رو بعنوان Artifact توی گیت هاب خواهیم داشت.

https://github.com/microsoft/typescript-go

مایکروسافت میتونست همینکارو با خود dotnet هم انجام بده. مثلا با #C یا حتی #F. آیا میکروسافت واقعا قبول کرده bullshit زیاد ساخته و Google ازش بهتره؟ :)

#meme

ولی جدی بنظرم اینکارو با 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();
}
}