خیلی وقتا برای ما پیش میاد که تو یه برنچی کار میکنیم که میخوایم با main/master مرجش کنیم ولی کس دیگه‌ای اول مرج میکنه برنچشو و ما conflict می‌خوریم.
حالا وقتی میخوایم کانفلیکت‌ها رو حل کنیم می‌تونیم برنچ main رو با برنچ خودمون merge کنیم یا برنچ خودمون رو rebase کنیم به main جدید.

اینکه کدومش خوبه کدومش نه، جوابش بستگی داره‌س!
تو تیم‌هایی که جونیور زیاد دارن توصیه می‌شه مرج کنید و تموم. اینطوری تاریخچه پیچیده‌تری دارید (چون چرا یهو main تو یه برنچ مرج شده) ولی مجیک خاصی اتفاق نمی‌افته.
از طرفی rebase باعث می‌شه که یه تاریخچه شبیه‌سازی شده و جدید به وجود بیاد که توش کامیت‌های برنچ جدید شما انگار بعد از آخرین کامیت main به وجود اومدن! برای کسی که بعدا نگاه کنه فهمش راحت تره ولی نکته اینه که چنین چیزی اصلا وجود نداشته و ممکنه مشکل لاجیکی تو کد ایجاد کنه.
تو این ویدیو این بحث رو خیلی خوب در قالب یه مکالمه توضیح دادن. توصیه می‌کنم ببینید.
https://www.youtube.com/watch?v=7gEbHsHXdn0

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

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

💎 مشکل همزمانی یا همون 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

YouTube | Instagram | Group

@ninja_learn_ir

دوره های🔥 رایگانی 🔥که در حال برگزاریه و تو کانال @itshield داره قرار میگیره:

⭐️دوره  اسمبلی (به هدف مقدمه برای مهندسی معکوس و تحلیل بدافزار)
https://t.me/itshieldassembly
⭐️دوره رایگان پایتون برای نفوذگر سطح مقدمات
https://t.me/itshield/1452
⭐️دوره  پایتون برای تست نفوذ پیشرفته (دوره مقدماتیش تموم شده که تو همین کانال  @itshield قرار گرفته)
https://t.me/PythonForPentester
⭐️دوره برنامه نویسی سی پلاس پلاس (به هدف ابزار امنیتی نوشتن)
https://t.me/CPlusPlus4Pentester
⭐️ دوره جرم شناسی ویندوز (For 500)
https://t.me/for500
⭐️ دوره اتوماسیون صنعتی
https://t.me/ICS_ITShield

😎پکیج رایگان ccna
https://t.me/itshield/1322
🤓پکیج رایگان MCSE
https://t.me/itshield/1326
🤓دوره رایگان ISMS
#isms
🥸دوره رایگان مقدمات SOC
#soc
🥸مینی دوره مهندسی اجتماعی
#مهندسی_اجتماعی
🥸 دوره جمع آوری اطلاعات برای تست نفوذ وب
#web_recon
🔥ماژول دوم دوره CEH
#CEH
یه سری دوره دیگه هم هست  که باید سرچ بزنین پیدا کنین
نکته هزینه شرکت در این دوره ها اینه که روی لینک زیر کلیک کنین و فاتحه برای عزیزان من بفرستین :
https://fatehe-online.ir/g/13486
🤓یه سری دوره و مباحث آموزشی رایگان دیگه هم هست که با سرچ و ... تو کانال بدست میاد
👆اینها رو تا میتونین نشر بدین تا کسی بخاطر یادگیری مقدمات هزینه نکنه
رایگان بودن دوره ها باعث نشده سطحی تدریسشون کنم و واقعا به اندازه دوره تجاری و حتی گاهی بیشتر بهشون اهتمام داشتم و دارم

مقاله جدیدم در وبسایت داکبورد با موضوع نکات امنیتی که باید در جنگو رعایت کنیم منتشر شد✌️❤️💣

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

امروزه جنگو یک فریم‌ورک محبوب وب است که توسط بسیاری از برنامه نویسات برای ساخت وب اپلیکیشن‌های امن و مقیاس‌پذیر استفاده می‌شود و از آن در پروژه های بسیار بزرگی مانند اینستاگرام استفاده میشود🔥🔥

در این مقاله، به بررسی نکات امنیتی که باید در پروژه های جنگویی خود رعایت کنیم میپردازیم تا بتوانیم اپلیکیشن های تحت وب خود را تا سطح بالایی ایمن و از داده های مربوط به آن حفاظت کنیم👌🤌

@shahriaarrr12
@duckboardnet

✅کد تخفیف ۸۰ درصدی

دوره غیر رایگان ساخت فروشگاه اینترنتی با جنگو

اگه کد تخفیف 80 درصدی میخواهید خصوصی به @miladhzz پیام بدید.

چند قسمت از این دوره رو اینجا ببینید:
https://t.me/djangolearn_ir/531
https://t.me/djangolearn_ir/533
https://t.me/djangolearn_ir/573
https://t.me/djangolearn_ir/676
https://t.me/djangolearn_ir/724
https://t.me/djangolearn_ir/808
https://t.me/djangolearn_ir/830

لینک دوره در دانشجویار:
https://www.daneshjooyar.com/project-django/

سلام به همه

پیرو این پست

✔️اگه کد یا پروژه ای دارید و می‌خواهید دوستان در موردش نظر بدهند.

لکن برای من بفرستید. آیدی من @miladhzz

✔️اگه کسی قبلاً فرستاده و یادم رفته، بهم یادآوری کنه لطفا

✅دومین پروژه برای کد ریویو

✔️پروژه جنگویی هست

اگه نظری دارید و نمیخواهید توی کامنت های این پست بنویسیدش خصوصی برام بفرستید. آیدی من @miladhzz

نکته: هر نظری اوکیه. فقط بی احترامی یا تحقیر و امثالهم نباشه. ممنون

✔️توضیحاتش:
این پروژه یک Api برای پنل پشتیبانی هست ممنون میشم اگر نگاهش کنید و بگید که چه مشکلاتی داره و چه ویژگی دیگر بهتر هست براش بگذارم

لینک:
https://github.com/yaser11138/Ticket-Api

✅ بخشی از آپدیت جدید دوره ساخت فروشگاه اینترنتی با جنگو

✔️ تبدیل ویو فانکشن بیس به کلاس بیس در جنگو

توی این ویدئو متد get فرم لاگین رو از فانکش بیس به کلاس بیس تغییر دادیم.

توی این ویدئو که بخشی از آپدیت جدید آموزش ساخت فروشگاه اینترنتی هست در مورد موضوعات زیر صحبت شد:
✔️آشنایی با کلاس View
✔️ویوهای جنریک و نحوه ارث بری شون
✔️آشنایی با متد as_view
✔️آشنایی مختصر با متد dispatch

لینک ویدئو در آپارات:
https://www.aparat.com/v/ifby9eo
لینک ویدئو در یوتیوب:
https://youtu.be/hefA2sEby7c

هر مشکل یا ابهامی دیدید. خصوصی به @miladhzz پیام بدید

وقتی با افراد باقی تیم‌های شرکت‌هایی که باهاشون کار می‌کنم صحبت می‌کنم؛ همیشه سعی می‌کنم با دقت بسیار منتظر کلمات کلیدی باشم.
مثلا امروز متوجه شدم؛ یکی ازین شرکت‌ها داره روی django-ninja کار می‌کنه پروژه‌های جدید که بیشتر هم کوتاه مدت لازم هست (نهایتا ۳-۶ ماه) رو دارند میبرند روی این فریمورک بجای استفاده از drf یک تیم برای fastapi هم داریم ولی drf, django از خیلی سال پیش توی شرکت بوده و جا افتاده اما نداشتن Async, ... باعث شده دنیال جایگزین باشند؛ چندماه قبل دنبال golang هم رفتند اما به دلیل زیاد شدن هزینه‌ها توسط شرکت مادر تایید نشد (چون باید ۲ تا تیم ساخته می‌شد؛ نگهداری پروژه‌های بزرگ قدیمی؛ جابجایی برخی از پروژه‌های فعلی و البته توسعه پروژه‌های جدید روی golang )

اما پروژه django-ninja با توجه به آنچه من از این بچه‌ها شنیدم احتمال داره فریمورک جایگزین برای drf باشه؛ بد نیست اگر فرصت دارید شبی ۱-۲ ساعت نیم نگاهی به داکیومنت این پروژه داشته باشید.
پارسال گفتم هرکی سمت Async نره؛ توی تیم بازنده‌های پایتون خواهد بود.

Django-Ninja Rest Framework Github

خواستم تاکید کنم: توجه کنید که گفتم اگر وقت خالی دارید؛ ۱-۲ ساعت نیم نگاه داشته باشید.

کامنت های این پست رو هم بخونید.

شغل تو در امانه...
از لینکدین Ali Bayat

📕 کتاب REST API Design Rulebook

📌 فصل سوم: Interaction Design with HTTP

📍پارت: دوم

#کتاب

💎 استاتوس کدهای ریسپانس (Response Status Codes) 💎

‏REST API‌ ها از قسمت Status-Line توی ریسپانس HTTP استفاده می‌کنن تا به کلاینت‌ها نتیجه درخواستشون رو اعلام کنن. استاندارد RFC 2616، ساختار Status-Line رو به این شکل تعریف کرده:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

‏HTTP حدود ۴۰ تا کد وضعیت استاندارد داره که برای بیان نتیجه درخواست‌های کلاینت استفاده میشه. این کدها به ۵ دسته اصلی تقسیم می‌شن که توی جدول زیر توضیح دادم:

⭕️ دسته‌بندی کدهای وضعیت:

1. 1xx: اطلاعاتی – اطلاعاتی در مورد سطح پروتکل انتقال میده.
2. 2xx: موفقیت‌آمیز – درخواست کلاینت با موفقیت قبول شده.
3. 3xx: تغییر مسیر – کلاینت باید یه کار اضافی انجام بده تا درخواست کامل بشه.
4. 4xx: خطای کلاینت – خطاهای این دسته مربوط به اشتباهات کلاینت هست.
5. 5xx: خطای سرور – سرور مسئولیت این خطاها رو قبول می‌کنه.

⭕️ قوانین استفاده از کدهای وضعیت:

⭕️ کد 200 (OK): برای موفقیت کلی
این کد معمولاً همون چیزیه که کلاینت انتظار داره ببینه. یعنی درخواست با موفقیت انجام شده و نیازی به استفاده از کد خاص دیگه‌ای از سری ۲xx نیست. برعکس کد 204، وقتی 200 برگرده، باید یه بدنه پاسخ (response body) هم داشته باشه.

⭕️ کد 200 (OK) نباید برای اعلام خطا استفاده بشه
همیشه باید از کدهای وضعیت HTTP درست استفاده کنید. به‌خصوص، نباید برای سازگار شدن با کلاینت‌های ساده‌تر از قواعد استاندارد API صرف‌نظر کرد.

⭕️ کد 201 (Created): برای ایجاد موفقیت‌آمیز منابع جدید
هر وقت که یه API یه منبع جدید برای درخواست کلاینت ایجاد می‌کنه (مثلاً توی یه کالکشن یا فروشگاه)، باید از کد 201 استفاده کنه. حتی اگر منبع جدید از طریق یه عمل کنترلر ایجاد بشه، باز هم 201 کد درستی برای پاسخ هست.

⭕️ کد 202 ("Accepted") باید برای شروع موفقیت‌آمیز یک عملیات غیرهمزمان استفاده بشه
کد 202 یعنی درخواست کلاینت قراره به صورت غیرهمزمان (آسنکرون) پردازش بشه. این کد به کلاینت میگه که درخواستش معتبر به نظر می‌رسه، اما ممکنه بعداً موقع پردازش به مشکل بخوره. این کد معمولاً برای عملیات‌هایی که زمان زیادی می‌برن استفاده می‌شه.
کنترلرها می‌تونن 202 رو برگردونن، اما منابع دیگه نباید این کار رو بکنن.

⭕️ کد 204 ("No Content") باید زمانی استفاده بشه که بدنه پاسخ (response body) خالیه
کد 204 معمولاً وقتی استفاده میشه که API به درخواست‌های PUT، POST یا DELETE پاسخ میده ولی قصد نداره که توی پاسخ، پیام یا داده‌ای برگردونه.
حتی در پاسخ به درخواست GET هم میشه از 204 استفاده کرد تا بگه منبع درخواست‌شده وجود داره، ولی چیزی برای نمایش نداره.

⭕️ کد 301 ("Moved Permanently") برای تغییر مکان دائمی منابع استفاده بشه
- کد 301 وقتی استفاده میشه که مدل منابع توی API تغییر بزرگی کرده و یه آدرس جدید برای منبع به کلاینت اختصاص داده شده. توی این حالت، آدرس جدید باید توی هدر "Location" به کلاینت اعلام بشه.

⭕️ از کد 302 ("Found") نباید استفاده بشه
کد 302 همیشه اشتباه فهمیده شده و برنامه‌نویسا توی پیاده‌سازیش اشتباه کردن. مشکل اصلی اینجاست که کلاینت‌ها به‌طور خودکار برای آدرس جدید یه درخواست GET می‌فرستن، حتی اگر روش اصلی درخواست چیز دیگه‌ای بوده.
برای رفع این مشکل، توی HTTP 1.1 کدهای 303 ("See Other") و 307 ("Temporary Redirect") معرفی شدن که به جای 302 باید استفاده بشن.

⭕️ کد 303 ("See Other") باید برای ارجاع کلاینت به یه URI دیگه استفاده بشه
وقتی یه کنترلر کارش رو تموم کرده، به جای فرستادن پاسخ توی بدنه‌ای که شاید کلاینت نمی‌خواد، می‌تونه با کد 303 یه URI جدید به کلاینت بده. این URI می‌تونه به یه پیام موقت یا یه منبع دائمی‌تر اشاره کنه.
این کد به API اجازه میده که به جای تحمیل دانلود اطلاعات به کلاینت، یه مرجع به منبع بده و کلاینت اگه بخواد می‌تونه با GET به URI جدید دسترسی پیدا کنه.

⭕️ کد 304 ("Not Modified") باید برای صرفه‌جویی در پهنای باند استفاده بشه
این کد شبیه کد 204 ("No Content") هست چون هیچ چیزی توی بدنه پاسخ نیست، اما تفاوت اصلی اینه که 204 وقتی استفاده می‌شه که هیچ داده‌ای برای فرستادن وجود نداره، ولی 304 وقتی استفاده میشه که منبع اطلاعات داره اما کلاینت قبلاً آخرین نسخه‌اش رو گرفته.
این کد بیشتر توی درخواست‌های HTTP شرطی (conditional requests) کاربرد داره.

@ninja_learn_ir

⭕️ کد 307 ("Temporary Redirect") برای تغییر موقتی مکان درخواست کلاینت استفاده بشه
‏- HTTP/1.1 کد 307 رو معرفی کرد تا کاربرد درست کد 302 ("Found") رو مشخص کنه. وقتی کد 307 برگرده، یعنی API قراره درخواست رو پردازش نکنه و کلاینت باید درخواستش رو به یه URI دیگه که توی هدر "Location" داده شده، بفرسته.
- این کد معمولاً برای اختصاص یه آدرس موقت به درخواست منبع استفاده میشه. مثلاً میشه درخواست رو به یه سرور دیگه انتقال داد.

⭕️ کد 400 ("Bad Request") برای اعلام شکست عمومی درخواست کلاینت استفاده بشه
کد 400 یه خطای کلی سمت کلاینت هست و زمانی استفاده میشه که هیچ کد دیگه‌ای از سری 4xx مناسب نباشه.

⭕️ کد 401 ("Unauthorized") باید زمانی استفاده بشه که مشکلی با اعتبارسنجی کلاینت وجود داره
این کد یعنی کلاینت سعی کرده به یه منبع محافظت‌شده دسترسی پیدا کنه ولی اعتبارنامه مناسب ارائه نداده. ممکنه اعتبارنامه‌ها اشتباه باشن یا اصلاً وجود نداشته باشن.

⭕️ کد 403 ("Forbidden") باید زمانی استفاده بشه که دسترسی به منبع غیرممکنه، فارغ از وضعیت اعتبارسنجی
- این کد یعنی درخواست کلاینت درسته ولی API اجازه انجامش رو نمیده. این موضوع ربطی به مشکل اعتبارنامه‌ها نداره (اون مورد 401 هست).
‏- APIهای REST از 403 برای مدیریت سطح دسترسی‌ها استفاده می‌کنن. مثلاً ممکنه یه کلاینت اجازه دسترسی به بعضی منابع رو داشته باشه ولی نه به همه. اگه کلاینت سعی کنه خارج از محدوده مجازش به منبعی دسترسی پیدا کنه، API باید با 403 پاسخ بده.

⭕️ کد 404 ("Not Found") باید زمانی استفاده بشه که URI کلاینت به منبعی مرتبط نمیشه
کد 404 یعنی API نمی‌تونه URI درخواست‌شده رو به منبعی متصل کنه.

⭕️ کد 405 ("Method Not Allowed") باید زمانی استفاده بشه که روش HTTP پشتیبانی نمیشه
‏- API با کد 405 پاسخ میده تا به کلاینت بگه که از روشی استفاده کرده که برای اون منبع مجاز نیست. مثلاً یه منبع فقط قابل خواندن ممکنه فقط GET و HEAD رو پشتیبانی کنه، ولی یه کنترلر ممکنه GET و POST رو مجاز بدونه اما PUT یا DELETE رو نه.
- پاسخ 405 باید شامل هدر "Allow" باشه که روش‌های مجاز برای اون منبع رو لیست کنه. مثلاً:

Allow: GET, POST

⭕️ کد 406 ("Not Acceptable") باید زمانی استفاده بشه که نوع داده‌ای که کلاینت درخواست داده قابل سرویس‌دهی نیست
- کد 406 یعنی API نمی‌تونه نوع مدیا (media type) درخواستی کلاینت رو ایجاد کنه. مثلاً اگه کلاینت درخواست داده به فرمت application/xml بده و API فقط با application/json کار کنه، کد 406 برمی‌گرده.

⭕️ کد 409 ("Conflict") باید زمانی استفاده بشه که درخواست کلاینت باعث نقض وضعیت منبع بشه
- کد 409 به کلاینت میگه که درخواستش باعث شده منبع API توی حالت ناسازگار یا غیرممکن قرار بگیره. مثلاً اگه کلاینت بخواد یه منبع پرشده رو حذف کنه و اون منبع هنوز داده داره، ممکنه API با 409 پاسخ بده.

⭕️ کد 412 ("Precondition Failed") باید برای پشتیبانی از عملیات‌های شرطی استفاده بشه
- این کد یعنی کلاینت یه سری شرایط رو توی هدر درخواستش مشخص کرده و به API گفته که فقط اگه اون شرایط برقرار باشه درخواستش رو انجام بده. اگه شرایط محقق نشه، API با کد 412 پاسخ میده.

⭕️ کد 415 ("Unsupported Media Type") باید زمانی استفاده بشه که نوع مدیا در payload درخواست قابل پردازش نباشه
- این کد یعنی API نمی‌تونه نوع مدیایی که کلاینت فرستاده رو پردازش کنه. مثلاً اگه کلاینت داده‌ها رو به فرمت application/xml بفرسته ولی API فقط با application/json کار کنه، کد 415 برگردونده می‌شه.

⭕️ کد 500 ("Internal Server Error") باید برای اعلام مشکل داخلی API استفاده بشه
- کد 500 یه خطای عمومی API هست که بیشتر فریم‌ورک‌های وب خودکار این کد رو برمی‌گردونن وقتی که درخواست کلاینت باعث ایجاد یه استثنا توی کد بشه.
- این خطا تقصیر کلاینت نیست، پس کلاینت می‌تونه همون درخواست رو دوباره امتحان کنه و امید داشته باشه که نتیجه متفاوتی بگیره.

@ninja_learn_ir

من میلاد حاتمی، برنامه نویس از سال 2008، قصد دارم به علاقمندان یادگیری طراحی سایت، به صورت خصوصی جنگو آموزش دهم.
🎯در صورتی که من مربی خصوصی جنگو شما بصورت آنلاین باشم:
⚡️یک اینترنت پر سرعت نیاز دارید.
✅قبل از شروع اولین جلسه به صورت رایگان:
⚡️با سوالاتی ساده، سطح مهارت شما در جنگو را ارزیابی می کنم.
⚡️به سوالات شما در مورد سرفصل ها پاسخ می دهم.
⚡️در صورت تمایل شما، با هم یک پروژه برای آموزش مشخص می کنیم.
⚡️در مورد هزینه، تعداد جلسات، ساعت آموزش و… صحبت می کنیم.
✅در طول جلسه :
⚡️نکات کاربردی را به شما یاد می دهم.
⚡️آموزش یکطرفه نخواهد بود و شما هم بعضی مواقع کد می نویسید و با چالش هایی مواجه خواهید شد.
⚡️با برخی ابزارهای کنترل سورس نظیر github آشنا خواهید شد.
⚡️با روش صحیح جستجوی سوالات برنامه نویسی در سایت های معتبر آشنا می شوید.
⚡️شما مجازید یک میلیون سوال بپرسید 🙂
✅بعد از هر جلسه:
⚡️با هم آموزش را مرور می کنیم.
⚡️در صورت لزوم به شما تمرین می دهم.
⚡️نظر شما را جهت بهتر شدن جلسه بعدی می پرسم.
⚡️در مورد جلسه بعدی برنامه ریزی می کنیم.
جهت ارتباط با من با @miladhzz در ارتباط باشید

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

موضوع، راجع‌به بروز رسانی نسخه‌ی PostgresSQL از ۱۱ به ۱۶‌ه. علاوه بر نقل تجربه‌شون از شیوه‌ و چالش‌های انجام این عملیات که به‌نظرم بسیار دونستنش با ارزشه، به تفصیل به معرفی ابزار و روش‌های انجام این کار و مزایا و معایب هر کدوم از جنبه‌های مختلف پرداخته.

https://techblog.torob.com/postgresql-upgrade-from-11-to-16-torob-experience-v62efb53gn6h

چرا سورس کد بیشتر بد است؟

https://huly.blog/source-code-is-poison

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