گاهی وسط دیباگ سریع، کلی print می‌ریزیم تو کد و بعداً یادمان می‌رود پاکشان کنیم 😅 بهتر است از اول سراغ لاگ ساخت‌یافته (Structured Logging) برویم.

با لاگ، هم سطح اهمیت داریم (info, warning, error)، هم می‌توانیم به‌راحتی فیلتر و جستجو کنیم و هم در محیط‌های Production به‌درد می‌خورد.

مثال ساده در Python 👇

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s - %(message)s",
)

logger = logging.getLogger("payment-service")

user_id = 42
amount = 199_000

logger.info("starting payment", extra={"user_id": user_id, "amount": amount})

try:
    1 / 0
except ZeroDivisionError:
    logger.exception("payment failed")

✅ مزیت‌ها:
• لاگ‌ها قابل فیلتر بر اساس سطح هستند و می‌شود فقط warning/error دید.
• در سرویس‌های Microservice و ابزارهایی مثل ELK یا Grafana Loki خیلی تمیزتر تحلیل می‌شوند.

برای پروژه بعدی، از همان روز اول یک Logger درست و حسابی تنظیم شود تا Debug و Monitoring آینده خیلی راحت‌تر پیش برود 🚀

مرجع: Python logging (Official Docs)

🔖 #Programming #برنامه_نویسی #logging #debugging #best_practices #python #structured_logging

👤 Developix

💎 Channel: @DevelopixChannel

‏اصل Single Responsibility (SRP)؛ وقتی کلاس‌ همه‌کاره خستگی‌ات می‌کند 😅

یکی از مهم‌ترین اصول SOLID، اصل Single Responsibility است:

هر کلاس یا ماژول باید فقط یک دلیل برای تغییر داشته باشد.

یعنی چی؟ یعنی یک کلاس نباید هم منطق دامنه را نگه دارد، هم log بنویسد، هم با دیتابیس کار کند، هم ایمیل بفرستد. این کلاس‌ها هم سخت تست می‌شوند، هم کوچک‌ترین تغییر، نصف سیستم را می‌ترکاند 🔥


❌ مثال بد: کلاس خدا (God Class)

class OrderService:
    def create_order(self, data):
        # 1) اعتبارسنجی ورودی
        if not data.get("user_id"):
            raise Exception("user_id required")

        # 2) محاسبه قیمت
        total = 0
        for item in data["items"]:
            total += item["price"] * item["qty"]

        # 3) ذخیره در دیتابیس
        db.save({"user_id": data["user_id"], "total": total})

        # 4) ارسال ایمیل
        EmailClient().send(
            to=data["email"],
            subject="Order created",
            body=f"Total = {total}"
        )

        # 5) لاگ کردن
        Logger().info("Order created", extra={"total": total})

این کلاس حداقل ۵ مسئولیت دارد. هر تغییری در validation، ایمیل، لاگ یا ساختار دیتابیس، این کلاس را درگیر می‌کند. تست واحد هم کابوس می‌شود 🤯


✅ بازطراحی با SRP

ایده این است که هر ماژول روی یک چیز متمرکز شود:

class OrderValidator:
    def validate(self, data):
        if not data.get("user_id"):
            raise Exception("user_id required")

class PriceCalculator:
    def calculate(self, items):
        total = 0
        for item in items:
            total += item["price"] * item["qty"]
        return total

class OrderRepository:
    def save(self, user_id, total):
        db.save({"user_id": user_id, "total": total})

class OrderNotifier:
    def send_order_created(self, email, total):
        EmailClient().send(
            to=email,
            subject="Order created",
            body=f"Total = {total}"
        )

class OrderService:
    def __init__(self, validator, calculator, repo, notifier, logger):
        self.validator = validator
        self.calculator = calculator
        self.repo = repo
        self.notifier = notifier
        self.logger = logger

    def create_order(self, data):
        self.validator.validate(data)
        total = self.calculator.calculate(data["items"])
        self.repo.save(data["user_id"], total)
        self.notifier.send_order_created(data["email"], total)
        self.logger.info("Order created", extra={"total": total})

حالا هر کلاس یک نقش نسبتاً واضح دارد. تغییر منطق قیمت، ایمیل یا دیتابیس، فقط همان بخش را تحت تاثیر قرار می‌دهد. تست واحد هم راحت‌تر است، چون می‌شود هر جزء را جداگانه mock و تست کرد ✅


چطور در عمل از SRP استفاده شود؟

• وقتی متدی خیلی طولانی می‌شود، معمولاً یعنی چند مسئولیت دارد.
• وقتی کلاس‌ مدام به خاطر انواع تغییرها ویرایش می‌شود، یعنی باید تفکیک شود.
• نام کلاس اگر شبیه "Manager"، "Helper"، "Util" باشد، اغلب بوی نقض SRP می‌دهد 😄

مرجع خوب برای مطالعه عمیق‌تر:
refactoring.guru/design-principles/srp

قدم‌های کوچک در جهت SRP، در طول زمان کد را تمیزتر، قابل‌تست‌تر و قابل‌تغییرتر می‌کند. از ریفکتور کردن کلاس‌های همه‌کاره امروز شروع شود ✨

🔖 #Programming #برنامه_نویسی #SRP #SOLID #Clean_Code #Refactoring #Design_Principles #Python

👤 Developix

💎 Channel: @DevelopixChannel

🏆آفرهای جام جهانی ۲۰۲۶ هاست‌ایران فعال شد!

با کمپین «ترکیب برنده سایتت»، زیرساخت سایتت رو برای روزهای پرترافیک آماده کن:

🔥 ۲۵٪ تخفیف روی پلن‌های ۳ ماهه هاست اشتراکی ایران
⚡ ۵۰٪ تخفیف روی پلن‌های یک‌ماهه سرویس ابری در دیتاسنترهای تهران، مشهد و اهواز

🧠 مشاوره رایگان زیرساخت توسط کارشناسان هاست‌ایران
فرصت استفاده از تخفیف‌ها و ثبت فرم مشاوره محدود است.

📌 برای کپی کدهای تخفیف و ثبت‌نام در فرم مشاوره، روی لینک زیر کلیک کنید:

📌صفحه فرم مشاوره
📌تلگرام هاست‌ایران
📌بله هاست‌ایران


#هاست_ایران #سرور_ابری_هاست_ایران #هاست_اشتراکی #دیتاسنتر #مشاوره_زیرساخت #جام_جهانی2026

ساخت یک REST API ساده با FastAPI 🚀

اگر دنبال راهی سریع و تمیز برای ساختن API هستی، FastAPI یکی از بهترین گزینه‌هاست. روی Python ۳ کار می‌کنه، تایپ‌هینت‌ها رو جدی می‌گیره و همزمان هم داکیومنت اتوماتیک می‌سازه، هم performance خیلی خوبی داره.

سناریو: یه سرویس خیلی ساده «مدیریت تسک‌ها» می‌خوایم، چیزی شبیه TODO، که بعداً راحت بشه روش frontend یا موبایل سوار کرد.

منبع اصلی این آموزش از داکیومنت رسمی FastAPI هست:
https://fastapi.tiangolo.com/tutorial/

✅ ایده کلی

FastAPI روی Starlette و Pydantic ساخته شده. یعنی:

• تعریف مدل داده با Pydantic (مثلاً مدل Task)
• تعریف endpointها با decoratorهای ساده مثل @app.get
• اجرا روی Uvicorn برای performance بالا

این مدل برای ساخت microservice، backend برای SPA، یا API موبایل خیلی practical و واقعی‌ست.

🔧 نصب و راه‌اندازی سریع

۱) ساخت venv (اختیاری ولی پیشنهاد می‌شه)

python -m venv venv
source venv/bin/activate  # روی ویندوز: venv\Scripts\activate

۲) نصب FastAPI و Uvicorn:

pip install "fastapi[all]" uvicorn

👨‍💻 پیاده‌سازی یک TODO API کوچک

فایل main.py رو بساز و کد زیر رو داخلش قرار بده:

from typing import List, Optional

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(title="Todo API")


class Task(BaseModel):
    id: int
    title: str
    done: bool = False
    description: Optional[str] = None


fake_db: List[Task] = []


@app.get("/tasks", response_model=List[Task])
async def list_tasks():
    return fake_db


@app.post("/tasks", response_model=Task)
async def create_task(task: Task):
    for t in fake_db:
        if t.id == task.id:
            raise HTTPException(status_code=400, detail="Task id already exists")
    fake_db.append(task)
    return task


@app.get("/tasks/{task_id}", response_model=Task)
async def get_task(task_id: int):
    for t in fake_db:
        if t.id == task_id:
            return t
    raise HTTPException(status_code=404, detail="Task not found")


@app.patch("/tasks/{task_id}", response_model=Task)
async def toggle_done(task_id: int):
    for t in fake_db:
        if t.id == task_id:
            t.done = not t.done
            return t
    raise HTTPException(status_code=404, detail="Task not found")

▶️ اجرای سرور

روی ترمینال:

uvicorn main:app --reload

حالا API روی آدرس زیر در حال اجراست:

http://127.0.0.1:8000

و مستندات خودکار (Swagger UI) اینجاست:

http://127.0.0.1:8000/docs

اونجا می‌شه مستقیم request فرستاد، body داد، response دید و راحت API رو تست کرد. برای تست سریع هم می‌شه از curl یا Postman استفاده کرد.

💡 نکات کاربردی

• بهتره از همون اول type-hintها رو جدی بگیری؛ FastAPI ازشون برای validation و schema استفاده می‌کنه.
• در پروژه واقعی، به‌جای fake_db از دیتابیس (مثل PostgreSQL با SQLAlchemy) استفاده می‌شه، اما همین in-memory مدل فکری رو خوب جا می‌اندازه.
• @app.patch برای update جزئی خیلی به‌دردبخوره؛ مخصوصاً وقتی روی front با formهای تیک‌دار کار می‌کنی.

یک بار این API ساده رو بساز، چند تا درخواست POST و GET بزن و ببین چقدر سریع می‌شه یک backend تمیز بالا آورد. اگر مفید بود، برای بقیه تیم هم بفرست تا برای پروتوتایپ‌های بعدی از FastAPI استفاده کنند. 🚀

🔖 #Programming #برنامه_نویسی #FastAPI #Python #REST_API #Backend #Web #Programming #Tutorial

👤 Developix

💎 Channel: @DevelopixChannel

💠 نسخه جدید محیط توسعه ویژوال استودیو (Visual Studio) منتشر شده است

🔸 ارتقا از نسخه 18.6.3 به 18.7.1

🔖 #visual_studio, #chat, #csharp, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه VSCode منتشر شده است

🔸 ارتقا از نسخه 1.125.0 به 1.126.0

🔖 #vscode, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه Zed منتشر شده است

🔸 ارتقا از نسخه 1.7.2 به 1.8.2

🔖 #zed, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه VSCode منتشر شده است

🔸 ارتقا از نسخه 1.126.0 به 1.127.0

🔖 #vscode, #chat, #release

💎 @DevelopixChannel

راز کندی کدهای مالتی‌ترد: کابوسی به نام False Sharing
تا حالا برات پیش اومده یه کد مالتی‌ترد بنویسی، هیچ Lockای هم استفاده نکنی، تردها کاملاً مستقل از هم کار کنن، ولی آخرش ببینی از نسخه‌ی تک‌ترد هم کندتره؟
اگر جواب مثبته، احتمالاً با یکی از عجیب‌ترین و پنهان‌ترین مشکلات دنیای سخت‌افزار روبه‌رو شدی: False Sharing.
پشت صحنه‌ی CPU چه خبره؟
پردازنده‌های امروزی داده‌ها رو دونه‌دونه از RAM نمی‌خونن. اون‌ها داده‌ها رو در بسته‌هایی به اسم Cache Line (معمولاً ۶۴ بایت) داخل حافظه‌ی کش (L1/L2/L3) نگه می‌دارن تا دسترسی بهشون خیلی سریع‌تر باشه.
حالا فرض کن این ساختار رو داریم:
type CoreData struct {
CounterA int64 // ۸ بایت
CounterB int64 // ۸ بایت
}
چون این دو متغیر کنار هم قرار گرفتن، احتمالاً هر دو داخل یک Cache Line قرار می‌گیرن.
مشکل از کجا شروع می‌شه؟
فرض کن:
ترد اول روی هسته‌ی اول CPU مدام CounterA رو تغییر می‌ده.
ترد دوم روی هسته‌ی دوم CPU هم مدام CounterB رو آپدیت می‌کنه.
از دید برنامه‌نویس، این دو متغیر هیچ ارتباطی با هم ندارن. اما از دید CPU داستان فرق می‌کنه.
هر بار که هسته‌ی اول CounterA رو تغییر می‌ده، کل اون Cache Line برای هسته‌ی دوم نامعتبر (Invalid) می‌شه. هسته‌ی دوم مجبور می‌شه دوباره داده رو از کش سطح بالاتر یا حتی RAM بخونه، مقدار خودش رو تغییر بده و دوباره باعث نامعتبر شدن کش هسته‌ی اول بشه.
این رفت‌وبرگشت دائمی بین هسته‌ها رو Cache Line Bouncing می‌گن.
نتیجه چیه؟ پردازنده به جای اینکه وقتش رو صرف اجرای کد تو کنه، مدام مشغول هماهنگ کردن حافظه‌ی کش بین هسته‌هاست!
راه‌حل؟ Padding
خوشبختانه راه‌حلش خیلی پیچیده نیست.
کافیه کاری کنیم این دو متغیر داخل یک Cache Line قرار نگیرن. یعنی بینشون کمی فاصله (Padding) ایجاد کنیم تا هر کدوم روی یک Cache Line جدا باشن.
مثلاً در Go می‌تونیم از cpu.CacheLinePad استفاده کنیم:
import "golang.org/x/sys/cpu"

type OptimizedData struct {
CounterA int64
_ cpu.CacheLinePad
CounterB int64
}
با همین فاصله‌ی ساده، هر متغیر روی یک Cache Line جدا قرار می‌گیره و دو هسته بدون اینکه مزاحم هم بشن، هم‌زمان کار می‌کنن.
جالب‌تر اینکه در بعضی بنچمارک‌های واقعی، همین تغییر کوچک تونسته عملکرد کدهای موازی رو چند برابر و حتی تا ۱۰ برابر بهتر کنه.
حرف آخر
خیلی وقت‌ها مشکل کند بودن کد، نه از الگوریتمه، نه از زبان برنامه‌نویسی و نه حتی از تعداد Threadها؛ بلکه از جزئیاتی میاد که داخل خود CPU اتفاق می‌افته.
هرچقدر درک بهتری از معماری سخت‌افزار داشته باشیم، راحت‌تر می‌تونیم کدهایی بنویسیم که علاوه بر درست بودن، واقعاً سریع هم باشن.

🔖 #Programming #برنامه_نویسی

👤 Ruhollah

💎 Channel: @DevelopixChannel

💠 نسخه جدید محیط توسعه Zed منتشر شده است

🔸 ارتقا از نسخه 1.8.2 به 1.9.0

🔖 #zed, #chat, #release

💎 @DevelopixChannel

‏قانون Demeter (Law of Demeter) چیه و چرا اینقدر مهمه؟ 🤐

یکی از اصول قدیمی ولی فوق‌العاده کاربردی در طراحی شی‌گرا، Law of Demeter یا همون "Talk only to your friends" ـه.

به زبان ساده: هر آبجکت فقط باید با "همسایه‌های نزدیکش" حرف بزنه، نه با نصف سیستم.

قاعدهٔ اصلی:
هر متد فقط باید با این‌ها تعامل داشته باشه:

• خودِ شی (this)

• پارامترهای ورودی متد

• فیلدهای خودش

• آبجکت‌هایی که خودش می‌سازه

هر چیزی غیر از این، بوی Coupling بالا و دردسر در ریفکتور می‌ده 😄

یک مثال بد 👎 (Law of Demeter نقض شده)

order.customer.address.city

توی کد واقعی (مثال Python):

class OrderService:
    def get_customer_city(self, order):
        return order.customer.address.city

اینجا OrderService داره نصف مدل دامنه رو می‌گرده:

• اگر ساختار Customer عوض بشه، اینجا هم می‌ترکه.

• اگر Address حذف بشه یا تغییر کنه، باز این کلاس می‌شکنه.

نسخهٔ بهتر ✅ (رعایت Law of Demeter)

مسیر طولانی رو "کپسوله" می‌کنیم:

class Customer:
    def get_city(self):
        return self.address.city

class Order:
    def get_customer_city(self):
        return self.customer.get_city()

class OrderService:
    def get_customer_city(self, order):
        return order.get_customer_city()

حالا OrderService فقط با Order حرف می‌زنه. بقیه‌اش پشت متدها مخفیه. اگر فردا مدل آدرس عوض بشه، فقط داخل Customer و حداکثر Order رو آپدیت می‌کنی.

چرا این قانون در عمل خیلی کمک می‌کنه؟ 💡

• کاهش Coupling: کلاس‌ها کمتر از ساختار داخلی هم خبر دارن.

• انعطاف در ریفکتور: راحت می‌تونی مدل داده رو عوض کنی بدون اینکه نصف سرویس‌ها رو دست بزنی.

• بهبود تست‌پذیری: با Mock کردن چند آبجکت محدود می‌تونی یونیت‌تست بنویسی، بدون زنجیره‌های عجیب.

بوی بد معروف: "Train Wreck" 🚂

هر وقت این الگو رو دیدی:

a.b().c.d().e

تقریباً مطمئنی که Law of Demeter نقض شده. این همون Train Wreck ـه؛ قطار نقطه‌ها.

چند نکتهٔ عملی برای کدنویسی روزمره

• اگر . زیاد پشت سر هم می‌بینی، معمولاً یعنی لازمه چندتا متد کوچک "واسط" اضافه کنی.

• به جای expose کردن کل آبجکت‌های داخلی، متدهای سطح بالاتر ارائه کن (مثل getCustomerCity()).

• توی Serviceها از Facade-های کوچک استفاده کن تا از جزئیات Domain دور نگه‌شون داری.

منابع بیشتر 📚

• Martin Fowler — Law of Demeter
• Refactoring Guru — Message Chains

از همین امروز، هر جا "قطار نقطه‌ها" دیدی، یک مکث کوتاه و یک ریفکتور کوچک می‌تونه معماری کدت رو حسابی تمیزتر کنه 🌱

🔖 #Programming #برنامه_نویسی #Law_of_Demeter #Clean_Code #Coupling #Design_Principles #OOP #Refactoring #Architecture

👤 Developix

💎 Channel: @DevelopixChannel

💠 نسخه جدید محیط توسعه VSCode منتشر شده است

🔸 ارتقا از نسخه 1.127.0 به 1.128.0

🔖 #vscode, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه Zed منتشر شده است

🔸 ارتقا از نسخه 1.9.0 به 1.10.0

🔖 #zed, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه VSCode منتشر شده است

🔸 ارتقا از نسخه 1.128.1 به 1.129.0

🔖 #vscode, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه ویژوال استودیو (Visual Studio) منتشر شده است

🔸 ارتقا از نسخه 18.7.4 به 18.8.0

🔖 #visual_studio, #chat, #csharp, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه Zed منتشر شده است

🔸 ارتقا از نسخه 1.10.3 به 1.11.3

🔖 #zed, #chat, #release

💎 @DevelopixChannel

نام‌گذاری تمیز؛ اولین خط دفاع در Clean Code 🧹

یکی از عملی‌ترین ایده‌های کتاب Clean Code این است که «اسم خوب، نصف راه خوانایی کد است». خیلی از بدهی‌های فنی فقط با نام‌گذاری درست اصلاً به‌وجود نمی‌آیند.

👀 نشانه‌های نام‌گذاری بد

وقتی متغیر و تابع این‌طوری هستند:

def p(u):
    if len(u) > 0:
        for x in u:
            if x[3] == 1:
                send(x)

از روی اسم‌ها تقریباً هیچ چیز قابل‌فهم نیست. برای فهمیدن کد، مجبور می‌شویم پیاده‌سازی داخلی را خط‌به‌خط بخوانیم.

✅ چطور بهترش کنیم؟

۱️⃣ اسم باید «بگوید» چه‌کار می‌کند

def send_active_users(users):
    if len(users) == 0:
        return

    for user in users:
        if user.is_active():
            send(user)

نام تابع، ورودی و شرط‌ها واضح شده‌اند. نیاز کمتری به کامنت داریم، چون خود کد توضیح‌دهنده است.

۲️⃣ از اسم‌های عمومی مثل data, info, tmp دوری کن

# بد
result = process(data)

# بهتر
normalized_orders = normalize_orders(raw_orders)

هرجا اسم مبهم می‌شود، خواننده باید در ذهنش حدس بزند؛ همین حدس‌ها منبع اصلی سوتفاهم در کد هستند.

۳️⃣ اسم تابع را فعل، اسم متغیر را اسم بگذار

# تابع با اسم اسمی (بدفهم)
user_status = user()

# واضح‌تر
status = get_user_status()

این الگوی ساده کمک می‌کند بدون نگاه به بدنه، از روی اسم‌ها بفهمیم هر چیزی «چیز است» یا «کار».

۴️⃣ از abbreviation بی‌معنی خودداری کن

# بد
cfg = read_cfg(pth)

# بهتر
config = read_config_file(path)

خودمان امروز معنای cfg را می‌فهمیم، ۶ ماه بعد یا برای همکار جدید، این تبدیل می‌شود به رمز.

۵️⃣ اسم‌ها را بر اساس domain انتخاب کن

استفاده از واژه‌های همان دامنه (Order, Invoice, Payment, Discount) کد را به زبان بیزینس نزدیک می‌کند و فهم سیستم را برای همه‌ی تیم آسان‌تر می‌کند.

📚 برای مطالعه بیشتر:
Clean Code, Chapter 2: Meaningful Names
Refactoring Guru - Code Smells

در هر refactor کوچک، فقط با بهتر کردن اسم‌ها می‌شود کیفیت طراحی را بالا برد؛ بدون تغییر رفتار کد. از همین commit بعدی، روی هر اسم چند ثانیه بیشتر فکر شود، بازدهش در بلندمدت شگفت‌انگیز است ✨

🔖 #Programming #برنامه_نویسی #clean_code #naming #meaningful_names #refactoring #readability #architecture

👤 Developix

💎 Channel: @DevelopixChannel

با Migration Boost هاست‌ایران، برای مهاجرت به سرور ابری دوباره هزینه ترافیک نده! 🚀

با خرید اولین سرور ابری غیرساعتی از **هاست‌ایران**، بسته ترافیک هدیه مهاجرت به‌صورت خودکار برای سرویس شما فعال می‌شود:

✅ حداقل ۱۰۰ گیگابایت ترافیک هدیه مهاجرت
✅ افزایش حجم هدیه متناسب با ظرفیت دیسک اولیه
✅ ترافیک آپلود رایگان
✅ بدون محدودیت زمانی

سرور ابری هاست‌ایران را راه‌اندازی کنید و بکاپ‌ها، فایل‌ها و پایگاه داده خود را بدون دغدغه هزینه‌های پنهان ترافیک منتقل کنید.

👇 مشاهده پلن‌های سرور ابری هاست‌ایران
hostiran.club/Migration
hostiran.club/Migration

💠 نسخه جدید محیط توسعه VSCode منتشر شده است

🔸 ارتقا از نسخه 1.130.0 به 1.131.0

🔖 #vscode, #chat, #release

💎 @DevelopixChannel

💠 نسخه جدید محیط توسعه Zed منتشر شده است

🔸 ارتقا از نسخه 1.12.1 به 1.13.1

🔖 #zed, #chat, #release

💎 @DevelopixChannel