خب فصل اول که کلا مقدمه بود تموم شد و از فردا شروع میکنیم مباحث اصلی رو برای طراحی اصولی یک API یاد بگیریم

از این به بعد فقط مباحث مهم رو پست میکنم و اضافاتش رو حذف میکنم

منتظر فصل دوم باشید 😁🌹

💎 خب Nginx چیه و به چه درد میخوره؟ 💎

امروز میخوام در مورد یه ابزار خیلی کاربردی به اسم Nginx صحبت کنم که شاید خیلیاتون اسمشو شنیده باشین ولی دقیق ندونید چیه و چیکار می‌کنه.

اول از همه بگم که Nginx یه وب سرور هست، ولی فقط همین نیست 😎 این ابزار قدرتمند میتونه به عنوان پراکسی معکوس (Reverse Proxy)، لود بالانسر (Load Balancer) و حتی کَش (Cache) هم استفاده بشه.
یعنی چی؟ یعنی اگه شما یه وبسایت پر بازدید دارید، با Nginx می‌تونید ترافیک ورودی رو مدیریت کنید که سایتتون دچار کندی یا قطعی نشه.

چرا Nginx؟
- سرعت بالا 🚀:
یکی از دلایلی که Nginx محبوبه، سرعت بالاشه. مخصوصاً توی هندل کردن تعداد زیادی درخواست همزمان.

- مصرف کم منابع 💾:
برخلاف بعضی از وب سرورهای دیگه، Nginx منابع کمتری مصرف میکنه و این یعنی صرفه‌جویی توی هزینه‌ها

- پایداری 🔄:
خب Nginx به خاطر معماری خاصش میتونه ترافیک سنگین رو بدون مشکل مدیریت کنه و همین باعث میشه سایتتون همیشه در دسترس باشه.

- ماژولار بودن ⚙️:
شما می‌تونید قابلیت‌های مختلفی رو با اضافه کردن ماژول‌ها به Nginx اضافه کنید. مثل SSL، فشرده‌سازی محتوا و...

حالا Nginx چجوری کار می‌کنه؟
خیلی ساده بگم، وقتی کاربری یه درخواست (مثل باز کردن یه صفحه وب) میفرسته، Nginx میاد و این درخواست رو می‌گیره و به بهترین شکل ممکن به سرور اصلی میرسونه. اگه سرور اصلی مشغوله یا مشکل داره، Nginx میتونه درخواست رو به یه سرور دیگه بفرسته یا حتی یه نسخه کَش شده از صفحه رو به کاربر نشون بده.

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

sudo apt-get install nginx

در نهایت، اگه دنبال یه وب سرور سریع، پایدار و کم‌ مصرف هستید، حتماً یه نگاهی به Nginx بندازید. با این ابزار میتونید وبسایتتون رو خیلی بهتر کنید و تجربه بهتری برای کاربرانتون رقم بزنید. 🌐

امید وارم براتون مفید بوده باشه:)❤️

#nginx #web #وب #web_server

@ninja_learn_ir

دوتا قسمت دیگه هم اپلود شد 💃

قسمت ۱۴:
https://youtu.be/hwL-g1RR8x4?si=qZwgWCOqP678csK6

قسمت ۱۵:
https://youtu.be/JnwepWlagxU?si=UfsaRJKPR_UaDSqp

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: اول

#کتاب

‏💎 URIs 💎

توی وب API‌ های REST از شناسه‌های منبع یکنواخت (URIs) برای آدرس‌دهی منابع استفاده می‌کنند.
امروزه، طراحی‌های URI می‌تونن از شاهکارهایی باشن که مدل منبع API رو به وضوح نشون می‌دن،
مثل:

https://api.example.restapi.org/france/paris/louvre/leonardo-da-vinci/mona-lisa

تا اون‌هایی که خیلی سخت‌تر برای مردم قابل فهم هستن، مثل:

https://api.example.restapi.org/68dd0-a9d3-11e0-9f1c-0800200c9a66

تیم برنرز-لی یه نکته‌ای درباره شفافیت URIs توی لیست "اصول معماری وب"ش ذکر کرده:

تنها چیزی که می‌تونید از یه شناسه استفاده کنید اینه که به یه شیء ارجاع بدید. وقتی که نمی‌خواید ارجاع بدید، نباید به محتوای رشته URI نگاه کنید تا اطلاعات دیگه‌ای به دست بیارید.

همونطور که توی فصل ۵ بحث شد، مشتری‌ها باید از الگوی لینک‌دهی وب پیروی کنن و URIs رو به عنوان شناسه‌های غیرشفاف در نظر بگیرن. با این حال، طراحان API‌های REST باید URIsی طراحی کنن که مدل منبع API رو به وضوح به توسعه‌دهندگان احتمالی نشون بده.

این فصل یه سری قوانین طراحی برای URIs در API‌های REST رو معرفی می‌کنه.


‏💎 URI Format 💎
قوانینی که در این بخش ارائه شده‌اند مربوط به فرمت یک URI هستند. استاندارد RFC 3986* سینتکس کلی URI رو به این شکل تعریف می‌کنه:

URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]

‏scheme: پروتکل یا روشی که برای دسترسی به منبع استفاده می‌شه، مثل http یا https.
‏authority: شامل اطلاعاتی مثل دامنه (domain) یا آدرس IP، و پورت سرور.
‌‏path: مسیر یا آدرسی که منبع خاصی رو در سرور مشخص می‌کنه.
‏query: پارامترهای اضافی که برای جستجو یا فیلتر کردن داده‌ها به URI اضافه می‌شن.
‏fragment: قسمتی از URI که به بخش خاصی از منبع اشاره می‌کنه، مثل یک بخش خاص از یک صفحه وب.

این قالب کلی به ما کمک می‌کنه تا ساختار URIها رو بهتر درک کنیم و بر اساس اون‌ها، URIهایی طراحی کنیم که هم برای انسان‌ها قابل فهم باشن و هم با استانداردهای وب سازگار باشن.


⭕️ از جداکننده‌ی اسلش (/) برای نشان دادن رابطه‌ی سلسله‌مراتبی استفاده کنید.
کاراکتر اسلش (/) در بخش مسیر (path) یک URI برای نشان دادن رابطه‌ی سلسله‌مراتبی بین منابع استفاده می‌شه. به عنوان مثال:
فرض کنید یک سایت دارید که شامل کشورها و شهرهاست. در این حالت، URI شما می‌تونه به این شکل باشه:

https://api.example.com/countries/iran/tehran

در این مثال، "iran" زیرمجموعه‌ای از "countries" و "tehran" زیرمجموعه‌ای از "iran" هست، که با استفاده از اسلش (/) این ساختار سلسله‌مراتبی نشون داده شده.

این کار کمک می‌کنه تا URIها به شکلی ساختاریافته و قابل درک برای کاربران و توسعه‌دهندگان باشند.


⭕️ نباید از اسلش (/) درآخر URI ها استفاده کنید

وقتی اسلش (/) به عنوان آخرین کاراکتر در مسیر (path) یک URI قرار می‌گیره، هیچ ارزش معنایی اضافه‌ای نداره و ممکنه باعث سردرگمی بشه. بنابراین، REST APIها نباید انتظار داشته باشند که URIها با یک اسلش انتهایی تموم بشند و نباید این نوع لینک‌ها رو به کاربران ارائه بدهند.

بسیاری از اجزای وب و فریمورک‌ها، این دو URI رو به طور یکسان در نظر می‌گیرند:

https://api.canvas.restapi.org/shapes/

https://api.canvas.restapi.org/shapes

اما واقعیت اینه که هر کاراکتر در یک URI به شناسایی منحصر به فرد اون منبع کمک می‌کنه. دو URI متفاوت به دو منبع متفاوت اشاره می‌کنند. بنابراین، یک REST API باید URIهای تمیز و دقیق تولید کنه و نباید تلاش‌های کاربران برای شناسایی منابع به شکل نادرست رو بپذیره.

البته، APIهای منعطف‌تر ممکنه کاربران رو به URIهایی بدون اسلش انتهایی هدایت کنند (همون‌طور که در قانون مربوط به استفاده از کد وضعیت 301 "Moved Permanently" برای جابجایی منابع توضیح داده شده).


⭕️ برای بهبود خوانایی URIها از خط تیره (-) استفاده کنید

برای اینکه URIهاتون رو برای افراد قابل فهم و قابل اسکن کنید، از کاراکتر خط تیره (-) استفاده کنید تا خوانایی نام‌ها در بخش‌های طولانی مسیر (path) بهتر بشه. هر جایی که در زبان انگلیسی از فاصله یا خط تیره استفاده می‌کنید، در URI هم باید از خط تیره استفاده کنید. به عنوان مثال:

https://api.example.restapi.org/blogs/mark-masse/entries/this-is-my-first-post

این کار باعث میشه که URIها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحت‌تر بشند.

#کتاب

⭕️ در URIها از زیرخط (_) استفاده نکنید
برنامه‌های نمایش متن (مثل مرورگرها، ویرایشگرها و غیره) معمولاً برای نشان دادن اینکه URIها قابل کلیک هستند، زیر آن‌ها خط می‌کشند. بسته به فونت استفاده‌شده در برنامه، کاراکتر زیرخط (_) ممکنه که به‌صورت جزئی یا کامل زیر این خط زیرین مخفی بشه. برای جلوگیری از این سردرگمی، به جای زیرخط از خط تیره (-) استفاده کنید.
این کار باعث میشه URIها بهتر دیده بشن و مشکلی در خواندن یا کلیک کردن روی اون‌ها پیش نیاد.

⭕️ از حروف کوچک در مسیرهای URI استفاده کنید
تا حد امکان در مسیرهای URI از حروف کوچک استفاده کنید، چون حروف بزرگ ممکنه گاهی اوقات مشکلاتی ایجاد کنن. بر اساس استاندارد RFC 3986، URI ها به غیر از بخش‌های مربوط به scheme و host نسبت به حروف بزرگ و کوچک حساس هستند.

مثال:

https://api.example.restapi.org/my-folder/my-doc

https://API.EXAMPLE.RESTAPI.ORG/my-folder/my-doc

https://api.example.restapi.org/My-Folder/my-doc

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

⭕️ پسوندهای فایل نباید در URI‌ها قرار بگیرند

در وب، کاراکتر نقطه (.) معمولاً برای جدا کردن نام فایل و پسوند اون در URI‌ها استفاده میشه. اما یک REST API نباید پسوندهای مصنوعی فایل رو توی URI‌ها بذاره تا فرمت محتوای پیام رو نشون بده. به جای این کار، باید از نوع رسانه (media type) که از طریق هدر Content-Type منتقل میشه، برای تعیین نحوه پردازش محتوای پیام استفاده بشه.

مثال:

نادرست: https://api.college.restapi.org/students/3248234/transcripts/2005/fall.json

درست: https://api.college.restapi.org/students/3248234/transcripts/2005/fall

به جای استفاده از پسوند فایل‌ها برای تعیین فرمت، بهتره که کلاینت‌های REST API از مکانیزم انتخاب فرمت ارائه‌شده توسط HTTP، یعنی هدر Accept در درخواست‌ها، استفاده کنن.

@ninja_leanr_ir

دوستانی که جدید اومدن پستای قبلی کانال رو بخونید خیلی چیزا میتونید ازشون یاد بگیرید

بچه‌ها سلام 👋

امروز می‌خوام یه‌ سری تجربیات و نکات رو باهاتون به اشتراک بذارم. 😊

تو این مسیر بک‌اند دولوپری، چیزایی هست که شاید اولش به نظر مهم نیاد ولی واقعاً اهمیت داره. بیاید با هم مرور کنیم:

1⃣ دیتابیس‌ها رو جدی بگیرید 
از همون اول کار دیتابیس رو دست‌کم نگیرید. خیلی وقتا دولوپرها دیتابیس رو فقط یه محل ذخیره داده می‌بینن ولی واقعیت اینه که نحوه طراحی و مدیریت دیتابیس تاثیر زیادی روی عملکرد کلی سیستم داره. ساختار درست دیتابیس، ایندکس‌ها، نرمال‌سازی و حتی دِنورمال‌سازی وقتی لازمه، همه اینا چیزایی هست که باید بلد باشی.

2⃣ فریم‌ورک مهمه، ولی تسلط به مفاهیم مهم‌تره 
ببینید، همه ما از یه جایی شروع کردیم و احتمالا با یه فریم‌ورک خاص، مثل Django یا Laravel، کار رو شروع کردیم. ولی اگه به مفاهیم پایه‌ای مثل HTTP، RESTful APIs، و اصول SOLID مسلط باشی، راحت‌تر می‌تونی با فریم‌ورک‌های مختلف کار کنی. یادگیری یه فریم‌ورک جدید نباید برات چالشی باشه اگه مفاهیم اساسی رو بلدی.

3⃣ کد خوانا بنویس، نه فقط برای کامپایلر، برای بقیه هم! 
این نکته شاید تکراری باشه ولی هنوزم خیلیا رعایت نمی‌کنن. کد رو جوری بنویس که خودت یا هر کس دیگه‌ای که قراره بعداً باهاش کار کنه، راحت بفهمه. کامنت‌های بیجا هم ننویس ولی اگه جایی پیچیده‌ست، کامنت بذار. یادت باشه: «کد برای کامپیوتر نوشته نمیشه، برای آدم‌ها نوشته میشه.»

4⃣ تست نویسی از نون شب واجب‌تره 
این یکی از اون چیزاییه که خود منم اولش ازش فراری بودم، ولی وقتی میری تو پروژه‌های بزرگ، می‌فهمی که بدون تست درست و حسابی، خیلی راحت ممکنه همه چی به هم بریزه. یونیت تست‌ها، اینتگریشن تست‌ها، و حتی تست‌های خودکار (Automated Tests) رو حتماً تو برنامه‌هات بزار.

5⃣ همیشه در حال یادگیری باش 
دنیای برنامه‌نویسی خیلی سریع تغییر می‌کنه. امروز یه تکنولوژی خیلی خفنه، فردا یه چیز جدید میاد و همه ازش حرف می‌زنن. خودت رو محدود به یه زبان یا تکنولوژی نکن. دائماً در حال یادگیری باش، حتی اگه شده یه ساعتی در هفته رو به یادگیری اختصاص بده.

6⃣ همکار خوب بودن رو یاد بگیر 
آخرش همونطور که همه می‌دونیم، بک‌اند دولوپری فقط کد زدن نیست. باید با بقیه اعضای تیم هماهنگ باشی، با فرانت‌اندی‌ها، دیزاینرها، و حتی مشتریا ارتباط خوبی داشته باشی. همکار خوب بودن و داشتن مهارت‌های نرم (soft skills) هم بخشی از این شغل هست.

خب بچه‌ها، این‌ها تجربیات و نکاتی بود که دوست داشتم باهاتون به اشتراک بذارم.

امیدوارم براتون مفید بوده باشه. 🌹

اگه سوالی دارید یا می‌خواید در مورد موضوع خاصی بیشتر بدونید، کامنت بذارید یا دایرکت بدید.

به امید موفقیت‌های بیشتر برای همتون! ✌🏻

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: دوم

#کتاب

‏💎 URI Authority Design 💎
این بخش به نام‌گذاری‌هایی که باید برای قسمت "authority" (یا همان بخش اصلی آدرس) یک REST API استفاده شود، می‌پردازد.

⭕️ برای API هاتون باید از نام‌های زیردامنه‌ای منظم و یکسان استفاده کنید.
دامنه اصلی و اولین زیردامنه (مثلاً soccer.restapi.org) باید مشخص‌کننده مالک سرویس باشه. کل نام دامنه یک API باید یک زیردامنه به نام api اضافه کنه. برای مثال:

https://api.soccer.restapi.org

⭕️ برای پرتال توسعه‌ دهندگان API هاتون باید از نام‌های زیردامنه‌ای منظم و یکسان استفاده کنید. خیلی از REST API ها یک وب‌سایت دارند که به عنوان پرتال توسعه‌دهندگان شناخته می‌شه و به کمک مستندات، انجمن‌ها و ارائه کلیدهای دسترسی امن به API، کاربران جدید رو راهنمایی می‌کنه. اگر API شما یک پرتال توسعه‌دهنده داره، طبق عرف باید زیردامنه‌ای به نام developer داشته باشه. برای مثال:

https://developer.soccer.restapi.org

‏💎 Resource Modeling 💎

مسیر URI مدل منابع یک REST API رو نشون می‌ده، به این صورت که هر بخش از مسیر که با اسلش جدا شده، به یک منبع منحصر به فرد در سلسله مراتب مدل اشاره می‌کنه. برای مثال، این طراحی URI:

https://api.soccer.restapi.org/leagues/seattle/teams/trebuchet

نشون می‌ده که هر کدوم از این URI‌ها هم باید به یک منبع آدرس‌پذیر اشاره کنند:

https://api.soccer.restapi.org/leagues/seattle/teams
https://api.soccer.restapi.org/leagues/seattle
https://api.soccer.restapi.org/leagues
https://api.soccer.restapi.org

مدل‌سازی منابع فرآیندیه که مفاهیم کلیدی API شما رو مشخص می‌کنه. این فرآیند شبیه مدل‌سازی داده برای یک پایگاه داده رابطه‌ای یا مدل‌سازی کلاسیک در سیستم‌های شی‌گرا است.

قبل از اینکه مستقیم وارد طراحی مسیرهای URI بشید، شاید بهتر باشه اول به مدل منابع REST API فکر کنید.



‏💎 Resource Archetypes 💎

هنگام مدل‌سازی منابع یک API، می‌تونیم با چند الگوی پایه‌ای منابع شروع کنیم. مثل الگوهای طراحی، این الگوها به ما کمک می‌کنن که ساختارها و رفتارهای رایجی که در طراحی REST API‌ها وجود دارن رو به صورت منسجم بیان کنیم. یک REST API از چهار الگوی منبع مجزا تشکیل شده: سند (document)، مجموعه (collection)، فروشگاه (store)، و کنترلر (controller).

برای اینکه یک مدل منابع شفاف و ساده به مشتریان API منتقل بشه، یک REST API باید هر منبع رو فقط با یکی از این الگوها تطبیق بده. برای حفظ یکنواختی، وسوسه طراحی منابعی که ترکیبی از چند الگو هستن رو کنار بذارید. به جای این کار، بهتره منابع جداگانه‌ای طراحی کنید که به صورت سلسله‌مراتبی و/یا از طریق لینک‌ها به هم مرتبط هستن، همونطور که در فصل ۵ توضیح داده شده.

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

@ninja_learn_ir

هوراااااا

💎 شورت کات ها درجنگو 💎
توی این پست میخوام درمورد یکسری شورتکات هایی که کمتر کسی بهشون توجه میکنه رو معرفی کنم

1⃣ render_to_string 🧩
این شورتکات یه پله بالا تر از render هست. اگه می‌خوای تمپلیت رو به یه رشته (string) تبدیل کنی، مثلا برای ارسال ایمیل یا ساختن پیام خاص، render_to_string کارت رو راه میندازه. خیلی شیک و مجلسی می‌تونی تمپلیت رو رندر کنی و به جای HTML کامل، فقط رشته رو داشته باشی:

from django.template.loader import render_to_string

def send_email():
    message = render_to_string('email_template.html', {'key': 'value'})
    # حالا می‌تونی message رو به عنوان متن ایمیل بفرستی

2⃣ resolve_url 🔗
اگه تا حالا از reverse استفاده کردی، این یکی هم خیلی شبیه به اونه ولی یه خورده هوشمندتر. resolve_url می‌تونه هم نام ویو رو به URL تبدیل کنه و هم خودش چک می‌کنه که اگه ورودی URL باشه، مستقیم همون رو برگردونه. پس دیگه نیاز نیست نگران باشی چی بهش می‌دی:

from django.shortcuts import resolve_url

def my_view(request):
    url = resolve_url('some-view-name-or-url')
    # ادامه کارا

3⃣  HttpResponsePermanentRedirect 🚦
شاید با HttpResponseRedirect آشنا باشی، ولی این یکی یه Redirect دائمی (کد 301) برمی‌گردونه. این وقتی خوبه که می‌خوای URL جدید رو دائمی کنی و به موتورهای جستجو بگی که این مسیر دیگه همیشه اینجاست:

from django.http import HttpResponsePermanentRedirect

def my_view(request):
    return HttpResponsePermanentRedirect('/new-url/')

4⃣ Http404 🚫
اگه دوست داری یه ارور 404 رو مستقیم دستی بندازی، Http404 بهترین گزینه‌ست. این طوری می‌تونی خودت خیلی شیک کنترل کنی که کجاها ارور 404 داده بشه:

from django.shortcuts import Http404

def my_view(request):
    if not some_condition:
        raise Http404("این صفحه وجود نداره!")
    # ادامه کارا

5⃣ get_current_site 🌍
اگه تو پروژه‌های پیچیده‌تر می‌خوای بدونی که کاربر الان تو کدوم سایت یا دامنه قرار داره (مثلا تو پروژه‌هایی که از multi-site استفاده می‌کنن)، get_current_site خیلی کاربردیه:

from django.contrib.sites.shortcuts import get_current_site

def my_view(request):
    current_site = get_current_site(request)
    # حالا می‌تونی با current_site هر کاری کنی

این شورتکات‌ها می‌تونن واقعاً تو پروژه‌های پیچیده‌تر جنگویی به کارت بیان و کارت رو راحت تر کنن.

امیدوارم این لیست براتون مفید باشه ✌️

#Django #Python #کدنویسی #شورتکات #توسعه_وب #برنامه_نویسی

@ninja_learn_ir

دوتا قسمت دیگه هم اپلود شد 😁

قسمت ۱۶

قسمت ۱۷

یه مشکلی که همیشه باهاش سروکله می‌زنیم، اینه که دقیقاً چه فایل‌ها و پوشه‌هایی رو باید توی .gitignore بذاریم؟ 🤔

خب، من یه راه‌حل توپ برات دارم! برو به سایت gitignore.io و اونجا اسم تکنولوژی‌ای که باهاش کار می‌کنی، مثلاً Django، رو وارد کن. این سایت خودش یه لیست از فایل‌هایی که باید توی .gitignore بذاری بهت میده.

با این کار، دیگه لازم نیست نگران باشی که چه فایل‌هایی به گیتت اضافه شدن! راحت و بی‌دردسر.

#gitignore #ترفند

@ninja_learn_ir

این دو قسمت یه مشکلی داشت که الان درستش کردم 😅

#fun

برای اونایی که میگفتن api چیه 😂😂😂

@ninja_learn_ir

💎 مشکل همزمانی یا همون Concurrency Problem  💎

امروز می‌خوایم یه موضوع خیلی مهم و جذاب رو با هم موشکافی کنیم:
مشکل همزمانی یا همون Concurrency Problem 🤓 شاید اسمش به گوشتون خورده باشه، ولی اگه دقیق‌تر بشناسیدش، می‌فهمید که چرا این موضوع این‌قدر تو دنیای برنامه‌نویسی مهمه.

همزمانی یعنی چی؟ 🤔
اول از همه، بگم که وقتی از همزمانی حرف می‌زنیم، داریم در مورد اجرای چند تا کار به‌صورت همزمان تو یه برنامه صحبت می‌کنیم. مثلاً فرض کنید یه برنامه دارید که داره همزمان چند تا درخواست کاربر رو مدیریت می‌کنه، یا داره یه سری عملیات‌های محاسباتی سنگین رو انجام می‌ده. اینجاست که مفهوم همزمانی مطرح میشه. هدف همزمانی اینه که بتونیم از منابع سیستم بهینه‌تر استفاده کنیم و سرعت اجرای برنامه رو بالا ببریم 🚀


مشکل از کجا شروع میشه؟ 😬
مشکل وقتی پیش میاد که چند تا ترد (Thread) یا پردازش (Process) به یه منبع مشترک دسترسی پیدا می‌کنن. مثلاً فرض کنید دو تا ترد همزمان دارن یه متغیر رو آپدیت می‌کنن. اینجاست که ممکنه مقدار نهایی اون متغیر چیزی که انتظار داشتیم نباشه و این یعنی Race Condition 🏁


مثال عملی Race Condition 🛠️
فرض کنید یه اپلیکیشن بانکی دارید که باید موجودی حساب کاربر رو مدیریت کنه. حالا دو تا ترد مختلف می‌خوان همزمان این موجودی رو آپدیت کنن. مثلاً یه ترد داره پول به حساب اضافه می‌کنه و ترد دیگه داره از حساب برداشت می‌کنه. اگه این دو تا ترد همزمان و بدون هماهنگی دقیق اجرا بشن، ممکنه موجودی حساب به‌طور نادرست محاسبه بشه 😱 این اتفاق دقیقاً مثالی از Race Condition هست.

راه‌حل‌ها چی هستن؟ 🔧
خب حالا که مشکل رو فهمیدیم، بیایید ببینیم چجوری می‌تونیم جلوی این مشکلات رو بگیریم:

1️⃣  Locks (قفل‌ها) 🛡️:
یه راه‌حل معمول استفاده از قفل‌هاست. وقتی یه ترد می‌خواد به یه منبع مشترک دسترسی پیدا کنه، اول اون رو قفل می‌کنه. اینجوری بقیه تردها باید صبر کنن تا اون ترد کارش رو تموم کنه و قفل رو آزاد کنه. این کار می‌تونه از به‌هم‌ریختگی جلوگیری کنه، ولی خودش یه چالش دیگه به نام Deadlock ایجاد می‌کنه، جایی که دو یا چند ترد منتظر قفل‌های همدیگه هستن و هیچ‌کدوم نمی‌تونن کارشون رو پیش ببرن 😩

2️⃣  Atomic Operations (عملیات اتمی) 💥:
این عملیات‌ها طوری طراحی شدن که یا کامل انجام می‌شن یا اصلاً انجام نمی‌شن. یعنی وسطشون هیچ ترد دیگه‌ای نمی‌تونه دخالت کنه. مثلاً اضافه کردن یه مقدار به یه متغیر می‌تونه یه عملیات اتمی باشه.

3️⃣ Synchronization (همگام‌سازی) ⏰:
با همگام‌سازی می‌تونید مطمئن بشید که یه ترد قبل از اینکه ترد دیگه کارش تموم بشه، کاری رو شروع نکنه. این کار معمولاً با استفاده از دستوراتی مثل synchronized در جاوا یا پایتون انجام میشه.

4️⃣ Thread Pools (مجموعه تردها) 🏊:
استفاده از Thread Pool‌ها می‌تونه به مدیریت بهتر تردها کمک کنه. اینجوری تعداد تردها محدود میشه و از مشکلاتی مثل Overhead جلوگیری می‌کنید.

مشکلات ناشی از راه‌حل‌ها 🤯

حالا که از راه‌حل‌ها گفتیم، یه نکته خیلی مهم رو هم باید اضافه کنم: همه این روش‌ها مشکلات خودشون رو دارن. مثلاً استفاده زیاد از قفل‌ها می‌تونه کارایی برنامه رو کاهش بده، چون تردها باید منتظر بمونن تا قفل آزاد بشه. از طرف دیگه، اگه قفل‌ها رو درست مدیریت نکنید، ممکنه برنامه‌تون دچار Deadlock بشه و کلاً قفل بشه 😵

نتیجه‌گیری 🎯
مشکل همزمانی یه موضوع پیچیده و حساس تو برنامه‌نویسیه که اگه درست مدیریت نشه، می‌تونه مشکلات بزرگی رو ایجاد کنه. باید همیشه به این فکر کنید که چطور می‌تونید از منابع مشترک بهینه استفاده کنید، بدون اینکه برنامه‌تون دچار مشکلاتی مثل Race Condition یا Deadlock بشه. پس دفعه بعدی که داشتید یه برنامه چندتردی نوشتید، حتماً به این نکات فکر کنید و مطمئن بشید که بهترین راه‌حل رو انتخاب کردید ✅

مرسی که تا اینجا همراه من بودید، امیدوارم این توضیحات براتون مفید بوده باشه. اگه سوال یا نظری دارید حتماً تو کامنتا بنویسید 😁✌️

#Concurrency #برنامه_نویسی #مشکل_همزمانی #RaceCondition #Deadlock #Synchronization #Threading #programming

YouTube | Instagram | Group

@ninja_learn_ir

#fun

🌚 یکی به من دالار بده

@ninja_learn_ir