برای حذف کامل ادیتور zed تو لینوکس اینکارو کنید:

~/.local/bin/zed zed --uninstall
rm -rf ~/.local/zed.app
rm ~/.local/bin/zed
rm ~/.local/share/applications/dev.zed.Zed.desktop
rm -rf ~/.local/share/zed
rm -rf ~/.config/zed
rm -rf ~/.cache/zed

هیچ اثری ازش باقی نمیمونه انگار که هیچوقت سمتش نرفتید

#fun

@Syntax_fa

آپدیت شد:

احراز هویت JWT
مدیریت خطای پیشرفته
داکرایز
پردازش غیرهم‌زمان با استفاده از celery و تسک های زمانبندی با استفاده از celery beat
مستندسازی API با استفاده از drf-spectacular
هوک‌های pre-commit از قبل تنظیم شدن؛ شامل pylint برای بررسی کیفیت کد و gitlint برای استاندارد کردن پیام‌های کامیت.
با GitHub Actions یه CI ساده راه افتاده که روی Pull Requestها تست‌ها و Lint‌ها رو اجرا می‌کنه

#django

@Syntax_fa

وضعیت برنامه نویسا چند وقت دیگه

#fun

@Syntax_fa

مامانم گفت کیس کامپیوترتو دادم به همسایه‌مون چون "فقط خاک می‌خورد". دارم می‌رم خونه اگه منظورش سرورم باشه... امیدوارم که اشتباه شده باشه.

#fun

@Syntax_fa

توضیح ساده مفهوم Anti-Corruption Layer (ACL):

فرض کن یه سیستم خیلی تمیز و مرتب ساختی، که از UILD برای IDها استفاده می‌کنه. حالا یه روز سرویس‌های دیگه‌ای میان که می‌خوان به سیستم تو وصل بشن. مثلاً یه اپلیکیشن که از INT برای user_id استفاده می‌کنه یا یکی دیگه که UUID استفاده می‌کنه.

حالا اگه تو مستقیماً اون INT یا UUID رو وارد سیستم خودت کنی، داری فساد رو وارد دنیای تمیزت می‌کنی، این میشه corruption.

Anti-Corruption Layer
یه لایه محافظه که جلوی این آلودگی رو می‌گیره. یعنی وقتی یه سرویس خارجی با مدل دیتا خودش با تو حرف می‌زنه، ACL میاد اون رو تبدیل می‌کنه به مدل خودت.

مثال از سرویس نوتیفیکیشن:
تو سرویس نوتیفیکیشن قراره از user_id توی بخش‌های مختلف استفاده شه. ولی به این دلیل که سرویس‌های خارجی ممکنه IDها با تایپ های مختلفی بفرستن (INT UUID و...)، نباید این تنوع رو بیاری داخل سرویست.

پس چی کار میشه کرد؟
1. اول چک می‌کنی که externalUserID ارسالی ULID هست یا نه.
2. اگه نیست، می‌ره تو کش cache یا دیتابیس دنبال اینکه آیا قبلا برای این external ID یه ULID تولید شده یا نه.
3. اگه نیست، خودش یه ULID جدید می‌سازه و نگه می‌داره.
4. از اون به بعد، هر بار external ID بیاد، همون ULID رو برمی‌گردونه و تو هر کجا که به user_id نیاز داریم ازش استفاده میکنیم.

یعنی:
* سیستم‌های خارجی می‌تونن هر جور ID بفرستن.
* سرویس نوتیفیکیشن همیشه با یک مدل استاندارد ULID کار می‌کنه.


مزایا:
* ساختار داخلی سیستم از تغییر و شلختگی سرویس‌های خارجی مصون می‌مونه.
* یکپارچگی و استاندارد بودن دیتای داخلی حفظ می‌شه.

#anti_corruption_layer #ACL

@Syntax_fa

رائفی‌پور:
رفتم چک کردم گیت‌هابشونو
دقیقا 1666 کامیت زده بود! حتما توطئه ای در جریانه و برنامه نویس فراسونر هاست

#fun

@Syntax_fa

الگوی Profile model

تا حالا به این مشکل برخوردید که توی پروژه‌تون دو نوع کاربر دارید؟ مثلاً «خریدار» و «فروشنده»؟
خریدار فقط نام و ایمیل داره، اما فروشنده کلی اطلاعات اضافه مثل «نام فروشگاه»، «آدرس» و «شماره صنفی» هم داره.

اینجا چند تا راه به ذهن میاد:
راه حل بد: همه‌ی فیلدها رو توی یک مدل User بریزیم (که برای خریدارها کلی فیلد NULL و خالی ایجاد می‌کنه و مدل رو شلوغ می‌کنه).
راه حل پیچیده: برای هر کدوم یک مدل User جدا بسازیم(که مدیریت احراز هویت و دسترسی‌هارو سختش می کنه)

الگوی پروفایل (Profile Model Pattern)

یک مدل User مرکزی داشته باشید: این مدل فقط مسئول اطلاعات مشترک و احراز هویته (نام کاربری، ایمیل، پسورد و ...)

یک مدل Profile جدا بسازید: برای اطلاعات اضافی، یک مدل جدید (مثلا SellerProfile) بسازید و تمام فیلدهای مخصوص فروشنده رو داخل اون قرار بدید.

با OneToOneField وصلشون کنید: این دو مدل رو با یک رابطه یک-به-یک به هم متصل کنید.

#profile_model_pattern

@Syntax_fa

یه کانال برنامه نویسیه شخصی درست می کنم میذارم تو پروفایلم تا بقیه با استایل خاصم آشنا بشن

#fun

@Syntax_fa

🌟 چیت‌ها یا همون ابزار تقلب در بازیهای آنلاین چطور کار می‌کنند؟

به طور کلی در بازی‌های آنلاین دو عامل وجود دارد که با همکاری یکدیگر می‌شه به طور آنلاین با بازیکنان دیگه یه بازی آنلاین بازی کرد.

🧑‍💻 کلاینت (Client): سیستم بازیکن که رندر گرافیک، ورودی کاربر و ارسال اطلاعات رو انجام می‌ده.

💡 مثال: اگر بازی شوتر باشه اطلاعاتی مثل
مکان دقیق بازیکن، شلیک تیر، نارنجک و ...

☁️ سرور (Server): هماهنگ‌کننده اصلی که داده‌های همه بازیکنان رو دریافت و تحلیل می‌کنه و تصمیم می‌گیره چه اتفاقی‌هایی باید بیفته.

💡 مثال: بازی اگر بازی شوتر باشه اطلاعات شلیک گلوله رو از کلاینت اول میگیره
و اطلاعات مکان بازیکن رو از کلاینت دوم میگیره. هر‌موقع که این دو مختصات روی‌هم منطبق شدند به پلیر ۲ دمیج وارد می‌شه.

– 🧩 خب کسایی که ابزار تقلب یا همون چیت میسازن دقیقا چه‌کاری انجام می‌دن؟ 🤔

معمولا با دستکاری فایل‌های بازی، حافظه‌ی اجرایی یا ساختار داده‌های سمت کلاینت، رفتار بازی رو عوض می‌کنن. این کار می‌تونه با روش‌هایی مثل مهندسی معکوس، تزریق کد یا ویرایش موقتی حافظه انجام بشه.


– 🧩 آیا چیت‌سازها از سرور بازی هم میتونن استفاده کنند؟ 👀

چون این کار نیازمند نفوذ غیرمجاز به سرور است و ریسک قانونی و امنیتی بالایی داره، معمولا مورد استفاده قرار نمی‌گیره. البته برای اینکار نیاز به مهارت‌های هک و نفوذ هم نیاز دارن.


– 🤖 چی باعث میشه که یک بازیکن از ابزار تقلبی استفاده کرده شناسایی بشه؟

آنتی‌چیت‌ها معمولا به دو نوع اصلی تقسیم می‌شن:

— نوع اول: یه سری که روی سیستم بازیکن اجرا می‌شن، مثل Easy Anti-Cheat یا BattleEye، که حافظه، فایل‌های DLL و فعالیت‌های مشکوک سیستم رو زیر نظر دارن.

— نوع دوم: یه نوع دیگه‌هم هست که سمت سروره و رفتار بازیکنان رو بررسی می‌کنه؛ مثلا اگر پلیری خیلی سریع‌تر از حد معمول حرکت کنه یا با دقت غیرطبیعی تیر بزنه، به‌عنوان مشکوک شناسایی می‌شه.

👈 مثالی از نحوه شناسایی:
– اگر حداکثر سرعت مجاز یک بازیکن 5 واحد بر ثانیه باشد، اما داده‌های ارسالی از کلاینت نشون بده که در یک فریم از مختصات (0,0) به (0,10) رسیده، سرور یا آنتی‌چیت می‌تونه این مورد رو به عنوان حرکت غیرمجاز ثبت کنه.

⚠️ البته بررسی کامل این رفتارها منابع زیادی مصرف می‌کنه، برای همین بعضی بازی‌ها فقط موارد خاص رو بررسی می‌کنن یا از سیستم‌های گزارش‌دهی بازیکنان استفاده می‌کنند.

– 🎖 چیت‌های پراستفاده و نحوه کارکردشان: خب حالا بیایید بررسی کنیم که چیت های پر استفاده چطوری کار میکنن.

*⃣ اِیم‌بات [Aimbot]:

از حافظه‌ی RAM بازی موقعیت دقیق دشمن‌ها رو استخراج می‌کنه. با استفاده از توابع حرکتی موس یا تزریق DLL، موس رو به‌صورت مصنوعی به مختصات دشمن می‌بره. معمولا با FPS بازی هماهنگ میشه تا طبیعی‌تر به‌نظر برسه (و آنتی‌چیت سخت‌تر متوجه بشه).

*⃣ وال‌هک [Wallhack]:

بازی معمولا اطلاعات بقیه بازیکنان رو به دلیل سینک [Synchronizing] بهتر برای کلاینت ها میفرسته. از حافظه یا GPU این اطلاعات رو استخراج میکنن و به صورت باکس یا اسکلت بهم نمایش میدن.

*⃣ اسپید هک [Speed hack]:

در برخی بازی‌ها سرعت حرکت در RAM نگهداری میشه. چیت با تغییر اون مقدار، سرعت بازیکن رو بالا میبره. بعضی وقتا هم با دست‌کاری Time Scale این کار انجام میشه (مثل فریم‌ریت فیک).

⚠️ این نوع چیت معمولا راحت شناسایی می‌شه چون داده‌های غیرعادی برای سرور میفرسته.

*⃣ تریگر بات [Triggerbot]:

از توابع DirectX یا OpenGL برای بررسی پیکسل‌های مرکز صفحه استفاده می‌کنه. وقتی رنگ مشخصی (مثل قرمز دشمن) در وسط صفحه دیده بشه، کلیک موس اجرا میشه.


– 🔥 در آخر یادم نره بگم که به طور خلاصه  چیت‌ها از روش‌های زیر ساخته میشن:

🟡 Memory Editing:
داده‌های در حال اجرا در RAM رو تغییر میده.

🟡 DLL Injection:
کد جدیدی وارد فرآیند بازی میکنه.

🟡 Hooking APIs :
توابع گرافیکی یا کنترلی بازی رو تغییر میده.

🟡 Packet Editing:
غیر رایجه؛ بسته‌های شبکه رو تغییر میده (معمولا قابل شناسایی توسط سرور)

🟡 External Programs:
بدون دخالت مستقیم، با گرفتن اسکرین، مکان دشمن رو تشخیص میده.


*⃣ #Game #Article
💎 Channel: @ZhinoDev

حرف هوش مصنوعی شد.
من هوش مصنوعیمو به تلگرام وصل کردم.
الان توی گروه سینتکس‌فا هستش.

تو گروه پیام بدید و سعی کنید باهاش ارتباط برقرار کنید تا با یه هوش مصنوعی خیلی متفاوت روبرو بشید


فعلا خاموشه

PgBouncer
ابزاری برای مدیریت کانکشن های پستگرس

چه زمانی میشه ازش استفاده کرد؟

اپلیکیشن‌های وب با ترافیک بالا:
این اصلی‌ترین کاربرد PgBouncer است. در اپلیکیشن‌هایی مثل جنگو، هر درخواست (request) کاربر ممکنه نیاز به یک کانکشن به دیتابیس داشته باشه. ساختن و از بین بردن کانکشن در PostgreSQL یک عملیات سنگین و پرهزینه‌ست (چون به ازای هر کانکشن یک پروسس جدید در سیستم‌عامل ایجاد می‌کنه). PgBouncer با نگه داشتن یک استخر (pool) از کانکشن‌های آماده، این هزینه رو به صفر نزدیک می‌کنه.

محیط‌های Serverless یا Function-as-a-Service (FaaS):
در پلتفرم‌هایی مثل AWS Lambda، هر اجرای تابع یک محیط ایزوله و کوتاه‌مدته. شما نمی‌تونید یک کانکشن دائمی به دیتابیس داشته باشید. بدون یک connection pooler مثل PgBouncer، دیتابیس شما با هزاران درخواست اتصال و قطعی بمباران می‌شه.

معماری میکروسرویس:
وقتی تعداد زیادی سرویس کوچک دارید که همگی به یک دیتابیس متصل می‌شن، مدیریت کانکشن‌ها می‌تونه از کنترل خارج بشه. PgBouncer به عنوان یک دروازه (gateway) عمل می‌کنه و این هرج و مرج رو مدیریت می‌کنه.

اپلیکیشن‌هایی با کانکشن‌های کوتاه‌مدت و زیاد:
هر نرم‌افزاری که در بازه‌های زمانی کوتاه تعداد زیادی کانکشن به دیتابیس باز و بسته می‌کنه، کاندیدای اصلی استفاده از PgBouncer است.

فایل docker compose که از PgBouncer استفاده شده تو یک پروژه جنگویی:
https://github.com/syntaxfa/django-structure/blob/main/compose.yml

نکته:
از نسخه bitnami بجای edoburu استفاده شده چون:
میشه با متغیر های محیطی پیکربندی کرد. خودم شخصا بیشتر دوست دارم بجای mount کردن فایل داخل خود فایل docker compose بتونم کانفیگ هارو اضافه کنم.
امنیت ایمیج bitnami خوبه و توسط شرکت غولی پشتیبانی میشه.

#PgBouncer

@Syntax_fa

Programming in iran

#fun

@Syntax_fa

فایل آپلود شده رو فقط با پسوندش چک می‌کنی؟ بیخیال!

تاحالا شده کاربر فایلی رو آپلود کنه و شما فقط پسوندش ( jpg یا pdf) رو چک کنید و با خوشحالی بگید کار تمومه؟ اگه اینطوره، باید بگم که یه جای کار حسابی می‌لنگه!

کاربر به راحتی می‌تونه یک فایل مخرب (مثلاً یه اسکریپت) رو به virus.png تغییر نام بده و سیستم شما رو دور بزنه.

راه حل چیه؟ کتابخونه python-magic

این پکیج یک رابط (Wrapper) برای کتابخونه قدرتمند libmagic در زبان C هست. کار اصلیش اینه که بیخیال اسم و پسوند فایل بشه و بره سراغ اصل مطلب محتوای خود فایل.

مجیک چند بایت اول یک فایل (که بهش هدر یا Magic Numbers می‌گن) رو می‌خونه و از روی اون امضای دیجیتالی، نوع واقعی فایل رو تشخیص می‌ده.

مثال:

import magic
from django.core.files.uploadedfile import InMemoryUploadedFile

def get_mime_type_from_content(file: InMemoryUploadedFile) -> str:
    """Reads the initial bytes of a file to determine its actual MIME type."""
    try:
        initial_bytes = file.read(2048)
        file.seek(0)
        return magic.from_buffer(initial_bytes, mime=True)
    except Exception as err:
        raise Exception(f"Failed to detect MIME type: {err}")

def check_file_is_image(file: InMemoryUploadedFile) -> bool:
    """Check if the uploaded file is an image based on its MIME type."""
    try:
        mime_type = get_mime_type_from_content(file)
        return mime_type.startswith("image/")
    except Exception as err:
        print(f"[ERROR] check_file_is_image: {err}")
        return False

#libmagic #python_magic

@Syntax_fa

مفهوم Trade-off در توسعه نرم‌افزار
(تعادل میان مزایا و معایب در تصمیم‌های فنی)

در توسعه نرم‌افزار، هیچ تصمیمی رایگان نیست. هر انتخابی، در کنار مزایا، هزینه‌ها و محدودیت‌هایی هم دارد. Trade-off یعنی برقراری تعادل میان این مزایا و معایب، و انتخاب بهترین گزینه متناسب با شرایط واقعی پروژه.

مثال ساده از دنیای خارج:
وقتی می‌خواهید خودرویی بخرید، معمولاً باید بین مصرف سوخت پایین و قدرت موتور بالا یکی را قربانی کنید. به ندرت خودرویی پیدا می‌شود که هر دو ویژگی را به بهترین شکل داشته باشد.

و در دنیای نرم‌افزار:

- اگر بخواهید سرعت توسعه بالاتر برود، احتمالاً باید کمی از بهینه‌بودن یا کارایی چشم‌پوشی کنید.
- اگر انعطاف‌پذیری کامل بخواهید، باید پیچیدگی بیشتری را بپذیرید.
- اگر سراغ فریم‌ورک‌های جدید بروید، نوآوری بیشتری به دست می‌آورید، اما منابع آموزشی و نیروی متخصص کمتری پیدا می‌کنید.

تفاوت در معیارهای سنجش
نکته مهم دیگر این است که معیارهای سنجش در هر پروژه متفاوت است:

- یک استارتاپ ممکن است سرعت رسیدن به بازار را مهم‌تر بداند.
- یک سیستم بانکی احتمالاً امنیت و پایداری بلندمدت را در اولویت قرار می‌دهد.
- یک پروژه تحقیقاتی شاید بیشتر به انعطاف‌پذیری و نوآوری اهمیت دهد.

بنابراین حتی اگر دو تیم روی یک زبان یا فریم‌ورک واحد بحث کنند، ممکن است از زاویه‌های متفاوتی آن را ارزیابی کنند و به نتایج متفاوتی برسند.


به همین دلیل، انتخاب زبان، ابزار یا فریم‌ورک هیچ‌وقت یک پاسخ مطلق «بهترین» ندارد.
سؤال درست این نیست که کدام بهترین است؟
بلکه این است که کدام گزینه با توجه به نیازهای فعلی پروژه و توان تیم، بهترین تعادل (Trade-off) را فراهم می‌کند؟

Source

#trade_off

@Syntax_fa