💎 ابزار Django debug toolbar 💎
امروز می‌خوایم دربارهٔ یه ابزار فوق‌العاده برای دیباگ کردن توی پروژه‌های جنگویی صحبت کنیم: Django Debug Toolbar. این ابزار می‌تونه بهتون کمک کنه تا جزئیات دقیق درخواست‌ها، کوئری‌های پایگاه داده، قالب‌ها و خیلی چیزای دیگه رو ببینید و مشکلات پروژه‌تون رو سریع‌تر پیدا و برطرف کنید. توی این پست قراره قدم به قدم نحوهٔ نصب و استفاده از این ابزار رو توضیح بدم. 🚀


1. نصب Django Debug Toolbarبرای شروع، باید Django Debug Toolbar رو نصب کنید :
این ابزار به‌راحتی از طریق pip قابل نصب هست. کافیه ترمینال رو باز کنید و این دستور رو وارد کنید: 💻

pip install django-debug-toolbar

با این کار، پکیج مورد نیاز نصب میشه. ✅

2. اضافه کردن به تنظیمات پروژه  :
حالا باید Django Debug Toolbar رو به تنظیمات پروژهٔ جنگوییتون اضافه کنید. برای این کار، فایل settings.py رو باز کنید و این کدرو رو به تنظیمات اضافه کنید: 🛠️

اضافه کردن به INSTALLED_APPS:

INSTALLED_APPS = [
    ...
    'debug_toolbar',
]

اضافه کردن به MIDDLEWARE:

MIDDLEWARE = [
    ...
    'debug_toolbar.middleware.DebugToolbarMiddleware',
]

با این کار، Django Debug Toolbar به پروژه‌تون اضافه می‌شه و میتونید ازش استفاده کنید. 🎉
3. تنظیم آیپی‌های مجازبرای اینکه این ابزار بتونه توی مرورگر نمایش داده بشه، باید آیپی‌هایی که برای دیباگ تولبار مجاز هستن رو تنظیم کنید. معمولاً برای توسعه توی لوکال از 127.0.0.1 استفاده می‌کنیم. بنابراین، این خط رو به settings.py اضافه کنید: 🌐

INTERNAL_IPS = [
    '127.0.0.1',
]

این تنظیمات به تولبار میگه که فقط وقتی از این آیپی درخواست میاد، نمایش داده بشه. 👀

4. اضافه کردن URLهای مربوطه حالا باید URLهای مربوط به Django Debug Toolbar رو به پروژه‌تون اضافه کنید. برای این کار، فایل urls.py رو باز کنید و این خطوط رو اضافه کنید: 🌍

django.conf import settings
from django.conf.urls import include
from django.urls import path

if settings.DEBUG:
    import debug_toolbar
    urlpatterns = [
        path('__debug__/', include(debug_toolbar.urls)),
    ] + urlpatterns

این کار باعث می‌شه که وقتی پروژه توی حالت DEBUG هست، تولبار فعال بشه و URLهای مربوط به اون هم در دسترس باشن. 🔧

5. استفاده از Django Debug Toolbar حالا دیگه کارمون تمومه! کافیه سرور جنگو رو دوباره راه‌اندازی کنید و یکی از صفحات پروژه‌تون رو باز کنید. اگه همه چیز درست پیش رفته باشه، یه نوار ابزار (Toolbar) در سمت راست صفحه نمایش داده می‌شه.
این نوار ابزار اطلاعات خیلی مفیدی دربارهٔ درخواست HTTP، کوئری‌های پایگاه داده، قالب‌ها، تنظیمات و موارد دیگه بهتون نشون میده.

مثلاً با استفاده از این ابزار می‌تونید ببینید چه کوئری‌هایی به پایگاه داده زده شده، چقدر زمان برده و جای بهینه‌سازی داره یا نه.
همچنین میتونید اطلاعات مربوط به درخواست‌ها و پاسخ‌های HTTP رو به‌دست بیارید و از نحوهٔ پردازش درخواست‌ها در سمت سرور مطلع بشید. 🔍

جمع‌بندی ✅
فهمیدیم Django Debug Toolbar ابزاری قدرتمنده که میتونه خیلی بهتون کمک کنه تا پروژه‌هاتون رو بهینه تر کنید و مشکلات رو سریع‌ تر پیدا کنید.
پیشنهاد میکنم حتماً امتحانش کنید و ببینید چقدر کارتون رو راحت‌تر می‌کنه. 💪

دراینده یه ویدیو هم درمورش ضبط میکنیم

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

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: دوم

#کتاب

💎 معماری وب 💎

در اواخر سال ۱۹۹۳، "روی فیلدینگ"، یکی از بنیان‌گذاران پروژه سرور HTTP آپاچی، نگران مشکل مقیاس‌پذیری وب شد.
بعد از تحلیل، فیلدینگ متوجه شد که مقیاس‌پذیری وب تحت تأثیر یه سری محدودیت‌های کلیدی قرار داره. اون و دیگران تصمیم گرفتن که با یه رویکرد عملیاتی، وب رو بهبود بدن: باید همه این محدودیت‌ها رو به‌صورت یکسان برآورده کنن تا وب بتونه به گسترش خودش ادامه بده.
فیلدینگ این محدودیت‌ها رو به شش دسته تقسیم کرد و به مجموعه این دسته‌ها "سبک معماری وب" گفت:

۱. کلاینت-سرور (Client-server)
۲. رابط یکپارچه (Uniform interface)
۳. سیستم لایه‌ای (Layered system)
۴. کش (Cache)
۵. بدون حالت (Stateless)
۶. کد به‌صورت درخواستی (Code-on-demand)

1️⃣ کلاینت-سرور (Client-server)
موضوع اصلی محدودیت‌های کلاینت-سرور در وب، جداسازی وظایف است. وب یک سیستم مبتنی بر کلاینت-سرور است که در آن کلاینت‌ها و سرورها نقش‌های مجزا و مشخصی دارند. این بخش‌ها می‌توانند به‌صورت مستقل پیاده‌سازی و مستقر شوند، با استفاده از هر زبان یا فناوری، به شرطی که با رابط یکنواخت وب سازگار باشند.

2️⃣ رابط یکپارچه (Uniform interface)
تعاملات بین اجزای وب، یعنی کلاینت‌ها، سرورها و واسطه‌های مبتنی بر شبکه، به یکنواختی رابط‌هایشان بستگی دارد. اگر هر یک از این اجزا از استانداردهای تعیین‌شده خارج شوند، سیستم ارتباطی وب دچار اختلال می‌شود.
اجزای وب در چارچوب چهار محدودیت رابط یکنواخت که فیلدینگ شناسایی کرده است، به‌طور سازگار با هم کار می‌کنند:

1- شناسایی منابع
2- دستکاری منابع از طریق نمایه‌ها
3- پیام‌های خودتوصیفی
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)

1- شناسایی منابع
هر مفهوم مجزای مبتنی بر وب به عنوان یک منبع شناخته می‌شود و می‌تواند با یک شناسه یکتا، مثل URI، مورد خطاب قرار گیرد. برای مثال، یک URI خاص مثل https://www.google.com منحصراً به مفهوم ریشه‌ی یک وبسایت خاص اشاره دارد.

2- دستکاری منابع از طریق نمایه‌ها
کلاینت‌ها نمایه‌های منابع را دستکاری می‌کنند. یک منبع مشخص می‌تواند به شکل‌های مختلف برای کلاینت‌های مختلف نمایه شود. مثلاً، یک سند ممکن است به‌صورت HTML به یک مرورگر وب نمایش داده شود و به‌صورت JSON به یک برنامه خودکار. ایده کلیدی این است که نمایه‌ها راهی برای تعامل با منبع هستند، اما خود منبع نیستند. این تمایز مفهومی اجازه می‌دهد که منبع به روش‌ها و فرمت‌های مختلف نمایه شود بدون اینکه شناسه‌اش تغییر کند.

3- پیام‌های خودتوصیفی (Self-descriptive)
وضعیت مورد نظر یک منبع می‌تواند در پیام درخواست کلاینت نمایه شود. وضعیت کنونی منبع ممکن است در پیام پاسخ سرور که بازمی‌گردد، نمایش داده شود. به‌عنوان مثال، یک ویرایشگر صفحه ویکی ممکن است از پیام درخواست برای انتقال یک نمایه که پیشنهاد یک بروزرسانی صفحه (وضعیت جدید) برای یک صفحه وب مدیریت‌شده توسط سرور است، استفاده کند. سرور تصمیم می‌گیرد که درخواست کلاینت را بپذیرد یا رد کند.

4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
نمایش وضعیت یک منبع شامل لینک‌هایی به منابع مرتبط هست. لینک‌ها مثل نخ‌هایی هستند که وب رو به هم متصل می‌کنن و به کاربرا این امکان رو می‌دن که به صورت معنادار و هدفمند بین اطلاعات و برنامه‌ها حرکت کنن. وجود یا نبودن یه لینک روی یک صفحه، بخش مهمی از وضعیت فعلی اون منبعه.

3️⃣ سیستم لایه‌ای (Layered system)
محدودیت‌های سیستم لایه‌ای این امکان رو می‌ده که واسطه‌های مبتنی بر شبکه مثل پروکسی‌ها و درگاه‌ها، به‌صورت شفاف بین کلاینت و سرور مستقر بشن و از رابط یکنواخت وب استفاده کنن. به‌طور کلی، یه واسطه مبتنی بر شبکه برای یه هدف مشخص ارتباط کلاینت و سرور رو رهگیری می‌کنه. این واسطه‌ها معمولاً برای اجرای امنیت، کش کردن پاسخ‌ها و متعادل کردن بار ترافیکی استفاده می‌شن.

4️⃣ کش (Cache)
کش کردن یکی از مهم‌ترین محدودیت‌های معماری وب هست. محدودیت‌های مربوط به کش به سرور وب می‌گن که باید قابلیت کش شدن داده‌های هر پاسخ رو مشخص کنه. کش کردن داده‌های پاسخ می‌تونه به کاهش تأخیر احساس‌شده توسط کاربر، افزایش دسترسی‌پذیری و قابلیت اطمینان یک برنامه، و کنترل بار سرور وب کمک کنه. به طور خلاصه، کش کردن هزینه کلی وب رو کاهش می‌ده.
کش می‌تونه در هر جایی از مسیر شبکه بین کلاینت و سرور وجود داشته باشه. این کش‌ها ممکنه در شبکه سرور وب یک سازمان، داخل شبکه‌های تحویل محتوای تخصصی (CDNها) یا حتی داخل خود کلاینت باشن.

5️⃣ بدون حالت (Stateless)
محدودیت بدون حالت (Stateless) می‌گه که یه سرور وب نباید وضعیت برنامه‌های کلاینت‌هاش رو به خاطر بسپاره. به همین خاطر، هر کلاینت باید تو هر تعامل با سرور، تمام اطلاعات مرتبط و مورد نیازش رو همراه داشته باشه. سرورهای وب از کلاینت‌ها می‌خوان که پیچیدگی مدیریت وضعیت برنامه‌هاشون رو خودشون انجام بدن تا سرور بتونه به تعداد بیشتری از کلاینت‌ها خدمات بده. این مبادله یکی از عوامل کلیدی در مقیاس‌پذیری سبک معماری وب هست.

6️⃣ کد به‌صورت درخواستی (Code-on-demand)
وب به شدت از "کد به صورت درخواستی" (Code-on-demand) استفاده می‌کنه، این محدودیت به سرورهای وب اجازه می‌ده که به‌طور موقت برنامه‌های اجرایی مثل اسکریپت‌ها یا پلاگین‌ها رو به کلاینت‌ها منتقل کنن. کد به صورت درخواستی باعث می‌شه که یه نوع وابستگی تکنولوژیکی بین سرورهای وب و کلاینت‌ها ایجاد بشه، چون کلاینت باید توانایی فهم و اجرای کدی که به صورت درخواستی از سرور دانلود می‌کنه رو داشته باشه. به همین دلیل، کد به صورت درخواستی تنها محدودیت سبک معماری وب هست که اختیاری در نظر گرفته می‌شه. تکنولوژی‌هایی که در مرورگرهای وب استفاده می‌شن، مثل جاوا اپلت‌ها، جاوا اسکریپت و فلش، نمونه‌های بارز این محدودیت هستن.


💎 استاندارد های وب 💎
فیلدینگ همراه با تیم برنرز-لی و چند نفر دیگه برای افزایش مقیاس‌پذیری وب کار کرد. برای استانداردسازی طراحی‌هاشون، اونا یه مشخصات جدید برای نسخه جدید پروتکل انتقال ابرمتن (HTTP/1.1) نوشتن.
همچنین، نحو شناسه‌های یکنواخت منابع (URI) رو هم در RFC 3986 رسمی کردن.
این استانداردها به‌سرعت در سراسر وب پذیرفته شد و راه رو برای رشد بیشترش هموار کرد.

@ninja_learn_ir

💎 همه چیز درباره DDoS و روش‌های جلوگیری با Cloudflare 💎

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

حالا DDoS یعنی چی؟ 🤔

خب DDoS مخفف Distributed Denial of Service هست. یعنی یه تعداد زیادی کامپیوتر یا سرور همزمان کلی درخواست به یه سرور خاص می‌فرستن تا اون سرور از کار بیفته و سایتتون بالا نیاد.

چرا DDoS خطرناکه؟ ⚠️

1⃣ قطعی سرویس: سایت یا سرور شما ممکنه زمان زیادی از دسترس خارج بشه.

2⃣ افت عملکرد: سرعت سایتتون به شدت میاد پایین.

3⃣ ضرر مالی: ممکنه ضرر مالی زیادی ببینید.

چجوری با Cloudflare جلوی DDoS رو بگیریم؟ 🛡

1⃣ استفاده از CDN: Cloudflare به عنوان یه CDN، محتوای سایت شما رو توی سرورهای مختلف تو دنیا ذخیره می‌کنه. این کار باعث میشه درخواست‌ها به جای سرور اصلی، برن به نزدیک‌ترین سرور Cloudflare و فشار روی سرور اصلی کم بشه. 🌍
 
2⃣ فایروال‌های پیشرفته: Cloudflare فایروال‌های خیلی قوی داره که میتونن درخواست‌های مشکوک رو تشخیص بدن و مسدودشون کنن. 🔥

3⃣ محافظت از لایه DNS: خب Cloudflare از Anycast DNS استفاده می‌کنه، یعنی درخواست‌ها رو بین سرورهای مختلف پخش می‌کنه و این کار جلوی DDoS رو می‌گیره. 🌐

4⃣ تحلیل و نظارت ترافیک: با ابزارهای Cloudflare میتونید ترافیک ورودی به سایتتون رو دقیق بررسی کنید و از حملات احتمالی مطلع بشید. 📊

5⃣ محدود کردن درخواست‌ها: Cloudflare به شما این امکان رو میده که تعداد درخواست‌های ورودی از هر IP رو محدود کنید. ⛔

6⃣ خدمات Mitigation: خب Cloudflare ابزارهای ویژه‌ای برای مقابله با حملات DDoS داره که خودکار و فوری وارد عمل میشن. 💼

چیکار کنیم موقع حمله DDoS؟ 🤔

- پیکربندی Cloudflare: مطمئن بشید که تنظیمات Cloudflare درست انجام شده و محافظت DDoS فعال هست. 🛠️

سخن پایانی🎯:
فهمیدیم که ddos چقدر خطرناکه و چطوری میتونیم با استفاده از ابزارهایی مثل cloud flare جلوشو بگیریم

امیدوارم این مطلب به دردتون خورده باشه :)❤️

#cdn #ddos #وب #امنیت_اینترنتی

@ninja_learn_ir

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

قسمت ۱۰:
https://youtu.be/7EIETZsnug4?si=8scR_A4B-MaihEew

قسمت ۱۱:
https://youtu.be/mlRZ_SMetbc?si=evTftHxoIJBqkUS1


@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: سوم

#کتاب

💎 REST 💎
در سال ۲۰۰۰، بعد از اینکه مشکل مقیاس‌پذیری وب حل شد، فیلدینگ تو پایان‌نامه دکترای خودش سبک معماری وب رو اسم‌گذاری کرد و اسمش رو "انتقال حالت نمایشی" یا همون REST رو برای این سبک معماری انتخاب کرد. این سبک شامل محدودیت‌هایی هست که قبلاً بهشون اشاره کردیم.

💎 REST API ها 💎

وب سرویس‌ها (Web Services) سرورهای مخصوصی هستن که نیازهای یه سایت یا هر اپلیکیشن دیگه‌ای رو برطرف می‌کنن.

برنامه‌های کلاینت (یا همون نرم‌افزارهایی که با سرور ارتباط می‌گیرن) از طریق API با این وب سرویس‌ها ارتباط برقرار می‌کنن.

به زبان ساده، API ها یه سری داده و عملکرد رو در اختیار برنامه‌های دیگه قرار می‌دن تا بتونن با هم تعامل کنن و اطلاعات رد و بدل کنن.

یه وب API مثل ویترین یه وب سرویسه که مستقیماً درخواست‌های کلاینت رو می‌شنوه و بهشون جواب می‌ده.

سبک معماری REST معمولاً برای طراحی API های وب سرویس‌های مدرن استفاده می‌شه. اگه یه وب API با سبک معماری REST طراحی شده باشه، بهش می‌گیم REST API.


⭕️ نکات:

مقیاس‌پذیری: یعنی یه سیستم بتونه بدون کاهش کیفیت، با افزایش ترافیک (مثلا تعداد کاربران) کنار بیاد و بتونه هندلشون کنه.

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

وب سرویس: یه سرویس تحت وب که از طریق اینترنت قابل دسترسیه و خدمات خاصی رو ارائه می‌ده.

API: یه واسطه که به برنامه‌ها اجازه می‌ده با هم ارتباط برقرار کنن.


وقتی یه وب سرویس از REST API استفاده کنه، بهش می‌گیم که اون سرویس "RESTful" هست. یه REST API از یه سری منابع به هم پیوسته تشکیل شده که بهشون مدل منابع (Resource Model) گفته می‌شه. REST API هایی که خوب طراحی شده باشن، می‌تونن برنامه‌نویس‌های کلاینت رو جذب کنن تا از اون وب سرویس استفاده کنن. امروزه که سرویس‌های وب رقیب دارن با هم برای جلب توجه رقابت می‌کنن، داشتن یه REST API با طراحی تمیز و کاربرپسند یه ویژگی ضروریه.

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

با این حال، هنوز هم باید دنبال جواب برای یه سری سوالات مهم بگردیم، مثلا:

- کی باید اسم route هامون رو با اسم‌های جمع بنویسیم؟
- از کدوم متد ریکوست (مثل POST یا PUT) باید برای به‌روزرسانی وضعیت منابع استفاده کنیم؟
- چطور باید عملیات‌هایی که مربوط به CRUD نیستن (CRUD: ایجاد، خواندن، به‌روزرسانی، حذف) رو به route ها مپ کنیم؟
- کدوم کد استاتوس HTTP برای یه سناریوی خاص مناسبه؟
- چطور می‌تونم نسخه‌های مختلف نمایه‌های وضعیت یه منبع رو مدیریت کنم؟
- چطور باید لینک‌ها رو توی JSON ساختاردهی کنم؟

⭕️ نکات:
- URI آدرس مشخصی که برای دسترسی به یه منبع توی وب استفاده می‌شه.
- CRUD مخفف چهار عمل اصلی روی داده‌ها؛ ایجاد (Create)، خواندن (Read)، به‌روزرسانی (Update)، و حذف (Delete).
- HTTP Status Code کدهایی که وضعیت درخواست‌های HTTP رو نشون می‌دن، مثل 200 برای موفقیت‌آمیز بودن یا 404 برای پیدا نشدن.


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

خیلی از قوانین طراحی این کتاب از بهترین روش‌هایی گرفته شدن که به‌نوعی استانداردهای نانوشته‌ای شده‌ان. اگه تجربه‌ای توی طراحی REST API ها داری، احتمالاً با قوانینی که مربوط به طراحی URI در فصل ۲ و استفاده از HTTP در فصل ۳ هستن، آشنا خواهی بود. ولی در مقابل، بیشتر قوانین فصل ۴ و فصل ۵ (مخصوصاً اونایی که به نوع داده‌ها و فرم‌های نمایشی مربوط می‌شن) راه‌حل‌هایی هستن که خودم برای مسائلی که توافقی روشون نیست، ارائه دادم.

@ninja_learn_ir

#کتاب

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

💎 توابع بازگشتی 💎

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

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


❓تابع بازگشتی چیه؟ 🤔

تابع بازگشتی یعنی تابعی که توی خودش دوباره خودش رو صدا می‌زنه!

یعنی تابع می‌تونه یه مسئله رو به نسخه‌های کوچیک‌تر از همون مسئله تقسیم کنه و حل کنه.

این روش توی مسائل پیچیده مثل محاسبه فاکتوریل یا سری فیبوناچی خیلی به کار میاد.


✅ مثال فاکتوریل با تابع بازگشتی 🔢

بیاین با یه مثال شروع کنیم: محاسبه فاکتوریل!

فاکتوریل یه عدد (n!) یعنی حاصل ضرب همه اعداد از ۱ تا n. مثلاً 5! می‌شه 120 (یعنی 1×2×3×4×5).

1⃣ جاوااسکریپت:

function factorial(n) {
    if(n === 1) {
      return 1;
    } else {
      return n * factorial(n-1);
    }
}

2⃣ پایتون:

def factorial(n):
    if n == 1:
        return 1
    else:
        return n * factorial(n-1)

تو این کد، تابع factorial خودش رو صدا می‌زنه تا وقتی که به عدد ۱ برسه. وقتی به ۱ رسید، مقدارها به ترتیب برمی‌گردن و جواب نهایی محاسبه می‌شه.

❓چرا توابع بازگشتی؟ 🤓

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

تمرین عملی 📝

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

امیدوارم این آموزش براتون مفید بوده باشه!

اگه سوالی دارید یا نظری دارید، حتماً توی گروه مطرح کنید. 🌹

@ninja_learn_ir

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

قسمت ۱۲:
https://youtu.be/3a-eMvZR3N0?si=u5Iit6niuEOmXWUj

قسمت ۱۳:
https://youtu.be/MV62c2umUO0?si=DF3y4eYoOU-iUwYp

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: چهارم (پارت آخر فصل اول)

#کتاب

💎 WRML 💎

من (نویسنده کتاب) یه چارچوب مفهومی به نام Web Resource Modeling Language (WRML) اختراع کردم که به طراحی و پیاده‌سازی REST API ها کمک می‌کنه. WRML، که به صورت "ورمل" تلفظ می‌شه، اول به عنوان یه تکنیک برای رسم مدل منابع به وجود اومد که از یه سری اشکال ساده برای نمایش هر کدوم از الگوهای منابع استفاده می‌کنه.

دامنه‌ی WRML با ایجاد نوع رسانه‌ای به نام application/wrml که قابلیت اضافه کردن فرمت و اجزای اسکیمای جدید رو داره، گسترده‌تر شد. در خیلی از قواعد بعدی کتاب، از ایده‌های WRML استفاده می‌کنم تا شکاف‌های موجود در بهترین روش‌های فعلی رو با توصیه‌های منطقی برای موقعیت‌های رایج پر کنم.

در فصل‌های ۵ و ۶ متوجه می‌شی که خیلی از قوانین با مثال‌هایی که از JSON استفاده می‌کنن، توضیح داده شدن. JSON یه فرمت مهمه که مزایای زیادی داره، مثل پشتیبانی بومی از جاوااسکریپت، پذیرش تقریبا جهانی، و سینتکس آشنا. اما JSON به تنهایی ساختارهای یکسانی برای بعضی از مهم‌ترین مفاهیم REST API مثل لینک‌ها، روابط لینک‌ها، و اسکیم‌ها ارائه نمی‌ده. قوانین توی فصل‌های "نمایش هایپرمیدیا" و "نمایش اسکیم" از WRML استفاده می‌کنن تا فرم‌های نمایشی مبتنی بر JSON رو برای این ساختارهای اصلی نشون بدن.

در نهایت، فصل ۷ تأکید می‌کنه که یکنواختی در طراحی API فقط یه موضوع تئوری نیست؛ بلکه می‌تونه زندگی برنامه‌نویسا رو بهتر کنه و به ما ابزاری غنی بده تا با استفاده از اون‌ها REST API ‌های بهتری طراحی و توسعه بدیم.


✅ خلاصه
این فصل خلاصه‌ای از اختراع و تثبیت وب رو ارائه داد. همچنین به معرفی رویکرد قوانین‌محور کتاب و چارچوب مفهومی WRML پرداخت، که ایده‌های اون به طراحی یکپارچه REST API کمک می‌کنن. فصل‌های بعدی بر این پایه استوار می‌شن تا به ما کمک کنن که از REST در طراحی API استفاده کنیم.

جدول ۱-۱ هم خلاصه‌ای از اصطلاحات جدیدی که توی این فصل معرفی شدن رو ارائه می‌ده.

@ninja_learn_ir

#کتاب

جدول ۱-۱:

Application Programming Interface (API)
یه مجموعه از داده‌ها و توابع رو در اختیار می‌ذاره تا برنامه‌های کامپیوتری بتونن با هم تعامل داشته باشن.

Architectural constraint
محدودیتی که رفتار اجزای یه سیستم رو کنترل می‌کنه تا یکنواختی رو برقرار کنه و یه ویژگی خاص رو به دست بیاره.

Architectural style
این اصطلاح رو روی فیلدینگ توی رساله دکترای خودش استفاده کرده تا یه سری محدودیت‌ها رو توصیف کنه که رفتار اجزای به هم متصل یه سیستم رو محدود می‌کنن.

Cache
محدودیت‌های REST که به واسطه‌ها توی شبکه اجازه می‌ده که وضعیت نمایشی منابع رو نگه دارن و این به سرورهای وب کمک می‌کنه تا نیازهای کاربرانشون رو برآورده کنن.

Client–server
محدودیت‌های REST که نگرانی‌های دو جزء اصلی سیستم رو از هم جدا می‌کنه و این باعث می‌شه که این اجزا بتونن به صورت مستقل پیشرفت کنن.

Code-on-demand
یه محدودیت REST که به طور اختیاری به سرور وب اجازه می‌ده که برنامه‌های اجرایی رو در صورت نیاز به کاربرانش انتقال بده.

Entity body
بخشی از یه پیام HTTP که برای نگه داشتن محتوای (اختیاری) طراحی شده، که ممکنه نمایشی از یه منبع باشه.

Entity headers
بخشی از یه پیام HTTP که می‌تونه اطلاعات متا مربوط به یه منبع و نمایشش رو انتقال بده.

HATEOAS
مخفف "Hypermedia as the Engine of Application State" در REST، که به روش ارائه لیستی از لینک‌ها برای نمایش "اقدامات" قابل دسترس برای یه منبع اشاره می‌کنه.

Hypermedia
یه گسترش از هایپرمتن که امکان ترکیب و پیوند دادن چندین فرمت رو فراهم می‌کنه تا یه شبکه اطلاعات چندرسانه‌ای طراحی بشه.

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

HyperText Mark-up Language (HTML)
توسط تیم برنرز-لی ساخته شده تا وضعیت اطلاعات و روابط یه منبع وب رو نمایش بده.

HyperText Transfer Protocol (HTTP)
در ابتدا توسط تیم برنرز-لی توسعه داده شد. این یه زبان مبتنی بر پیام هست که کامپیوترها می‌تونن ازش برای ارتباط از طریق اینترنت استفاده کنن.

Hypertext Transfer Protocol version 1.1 (HTTP/1.1)
روی فیلدینگ، تیم برنرز-لی، و دیگران به استانداردسازی این نسخه از پروتکل ارتباطی کمک کردن.

JavaScript
یه زبان اسکریپت‌نویسی قدرتمند که معمولاً توسط توسعه‌دهندگان وب استفاده می‌شه.

JavaScript Object Notation (JSON)
یه فرمت متنی استاندارد شده که از جاوااسکریپت مشتق شده و برای تبادل داده‌های ساختاریافته استفاده می‌شه.

Layered system
محدودیت‌های REST که به واسطه‌های شبکه اجازه می‌ده بین مشتری و سرور قرار بگیرن بدون اینکه محدودیت‌های یکنواختی رابط رو نقض کنن.

Media type
یه سینتکس که فرم محتوا رو توصیف می‌کنه.

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

Representation
وضعیت فرمت شده یه منبع که ممکنه از طریق پیام‌هایی که بین اجزا منتقل می‌شن، انتقال داده بشه.

Representational State Transfer (REST)
روشی که روی فیلدینگ برای توصیف سبک معماری وب به کار برد.

Request message
پیامی که از طرف کاربر (کلاینت) فرستاده می‌شه تا با یه منبع وب که از طریق URI مشخص شده، تعامل کنه. ممکنه شامل یه نمایش از وضعیت منبع هم باشه.

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

Resource identifier
یه شناسه‌ی جهانی و منحصر به فرد برای یه مفهوم خاص در وب.

Resource model
یه مجموعه از مفاهیم وبی که به هم مرتبط هستن.

Resource state representation
وضعیت رندر شده‌ی یه منبع که تحت مالکیت سرور وب هست و بین کلاینت و سرور یه برنامه منتقل می‌شه.

Response message
پیامی که از طرف سرور فرستاده می‌شه تا نتیجه‌ی درخواست کلاینت رو اعلام کنه. ممکنه شامل یه نمایش از وضعیت منبع هم باشه.

REST API
یه رابط خدمات وب که با سبک معماری وب همخوانی داره.

Scalability
توانایی مدیریت بار کاری بیشتر به شکل مناسب و بدون مشکل.

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

Uniform interface
یه مجموعه از چهار محدودیت REST که ارتباط بین اجزای وب رو استاندارد می‌کنه.

Uniform Resource Identifier (URI)
یه سینتکس که توسط تیم برنرز-لی اختراع شد تا به هر منبع وب یه شناسه‌ی منحصر به فرد اختصاص بده.

Web API
ابزاری که توسط کاربران (کلاینت‌ها) برای تعامل با یه خدمات وب استفاده می‌شه.

Web browser (browser)
یه نوع معمول از کلاینت وب. تیم برنرز-لی اولین مرورگر رو توسعه داد که قادر به مشاهده و ویرایش اسناد HTML بود.

Web client (client)
یه برنامه کامپیوتری که از رابط یکنواخت REST پیروی می‌کنه تا بتونه نمایش وضعیت منابع رو از سرور بگیره و ارسال کنه.

Web component (component)
یه کلاینت، واسطه‌ی شبکه‌ای، یا سرور که با رابط یکنواخت REST مطابقت داره.

Web Resource Modeling Language (WRML)
یه چارچوب مفهومی که ایده‌هاش رو می‌تونیم برای طراحی و پیاده‌سازی API‌های REST یکنواخت استفاده کنیم.

Web server (server)
یه برنامه کامپیوتری که از محدودیت‌های رابط یکنواخت REST پیروی می‌کنه تا نمایش وضعیت منابع رو از کلاینت بگیره و ارسال کنه.

Web service
یه سرور وب که با منطق خاص و معمولاً قابل استفاده مجدد برنامه‌ریزی شده.

خب فصل اول که کلا مقدمه بود تموم شد و از فردا شروع میکنیم مباحث اصلی رو برای طراحی اصولی یک 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