خب خب خب gRPC چیه؟ 🛰

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

gRPC (Google Remote Procedure Call)

یه سیستم Remote Procedure Call یا همون RPC مدرنه که گوگل توسعه داده. تو این مدل، می‌تونی توابعی رو از یه سرویس صدا بزنی انگار که دارن تو همون سرویس لوکال اجرا می‌شن.

چرا gRPC؟

دلیل‌هاش زیاده:

سرعت بالا 🚀

ـgRPC از HTTP/2 استفاده می‌کنه که خیلی سریع‌تر از HTTP/1.1 عادیه. این یعنی درخواست‌ها موازی می‌شن، فشرده‌سازی هدرها انجام می‌شه و ارتباطات پایدار (persistent connections) دارن.

استفاده از Protocol Buffers 📦

ـgrpc به جای JSON یا XML، از ProtoBuf استفاده می‌کنه که فشرده‌تر، سریع‌تر و بهینه‌تره. این باعث کاهش پهنای باند مورد نیاز می‌شه که برای سیستم‌های توزیع‌شده فوق‌العاده مهمه.

پشتیبانی از استریم 📡

ـgRPC بهت اجازه می‌ده ارتباط دوطرفه (bidirectional streaming) داشته باشی. این یعنی هم کلاینت و هم سرور می‌تونن هم‌زمان داده بفرستن و دریافت کنن.

زبان‌باز بودن 🌍

ـgRPC از خیلی زبان‌ها مثل Go، Python، Java، C# و... پشتیبانی می‌کنه.

قابلیت مقیاس‌پذیری 🔄

ـgRPC به دلیل طراحی کارآمد و استفاده از HTTP/2 برای سیستم‌هایی که قراره در آینده بزرگ بشن، انتخاب خیلی خوبیه.

ـgRPC چطور کار می‌کنه؟
برای استفاده از gRPC، باید با مفهوم Protocol Buffers (یا همون ProtoBuf) آشنا باشی. ProtoBuf یه فرمت برای تعریف داده‌ها و توابعه. یه فایل .proto می‌نویسی و توش مشخص می‌کنی که چه متدهایی داری و ورودی و خروجی‌هاش چیه. بعدش gRPC این فایل رو به کدی برای زبان دلخواهت تبدیل می‌کنه.

مثلاً:

syntax = "proto3";  

service Greeter {  
  rpc SayHello (HelloRequest) returns (HelloResponse);  
}  

message HelloRequest {  
  string name = 1;  
}  

message HelloResponse {  
  string message = 1;  
}  

اینجا یه متد SayHello داریم که یه درخواست می‌گیره و یه پاسخ برمی‌گردونه.

کجاها از gRPC استفاده کنیم؟
ـgRPC معمولاً تو سیستم‌های توزیع‌شده استفاده می‌شه، مثل:

ارتباط بین میکروسرویس‌ها 🔗

اگه داری میکروسرویس‌ها رو مدیریت می‌کنی، gRPC می‌تونه ارتباط بینشون رو سریع‌تر و ساده‌تر کنه.

سیستم‌هایی با نیاز به استریم 🎥

مثل چت‌روم‌ها، بازی‌های آنلاین یا هر جایی که داده‌ها باید به‌صورت زنده رد و بدل بشن.

سیستم‌های چندزبانه 🌐

چون gRPC از زبان‌های مختلف پشتیبانی می‌کنه، تو سیستم‌های چندزبانه عالیه.

کجاها از gRPC استفاده نکنیم؟

وب اپلیکیشن‌های عمومی 🌍:

اگه می‌خوای چیزی مثل REST API برای کلاینت‌های مرورگر بسازی، gRPC خیلی انتخاب مناسبی نیست چون مرورگرها به طور مستقیم با gRPC سازگار نیستن. البته می‌تونی از gRPC-Web استفاده کنی تا این محدودیت رو رفع کنی.

وقتی که نیاز به دیباگ ساده داری 🛠️:

ـJSON رو راحت می‌تونی تو مرورگر یا ابزارهای مختلف دیباگ کنی، ولی ProtoBuf این‌طور نیست و نیاز به ابزارهای خاص خودش داره.

پروژه‌های کوچیک 🪶:
برای پروژه‌هایی که سرعت یا مقیاس‌پذیری خیلی مهم نیست، پیچیدگی gRPC ممکنه بیش از حد باشه. REST API یا حتی JSON-RPC می‌تونه ساده‌تر و کافی باشه.

اشتباهات رایج در استفاده از gRPC 🚨
نادیده گرفتن محدودیت مرورگرها:
مرورگرها مستقیم gRPC رو ساپورت نمی‌کنن و باید از gRPC-Web استفاده کنی.

بی‌توجهی به اندازه پیام‌ها:
اگه پیام‌های بزرگ یا سنگین می‌فرستی، ممکنه gRPC بهینه نباشه.

عدم استفاده از استریم وقتی لازمه:
بعضی وقت‌ها دولوپرها استریم رو نادیده می‌گیرن و همین باعث می‌شه از پتانسیل gRPC کامل استفاده نکنن.

تنظیم نکردن Timeouts و Retries⏱️:
فراموش کردن تنظیم timeouts و retries می‌تونه باعث مشکلات بزرگی در ارتباط بین سرویس‌ها بشه.

جمع‌بندی 🎯
ـgRPC یه ابزار قدرتمنده که سرعت و کارایی بالایی به ارتباط بین سرویس‌ها می‌ده. ولی باید دقیق و هوشمندانه ازش استفاده کنی. اگه تو جای درست به کارش بگیری، می‌تونه کلی از مشکلات سیستم‌های توزیع‌شده رو برات حل کنه.

یادت باشه: هر ابزاری جای خودش رو داره. با انتخاب هوشمندانه، می‌تونی بهترین نتیجه رو بگیری.

#programming #web #grpc

➖➖➖➖➖➖➖➖➖
🔆 CHANNEL | GROUP

خب خب خب Django Channels چیه؟ و چرا من ازش خوشم نمیاد

قبل از اینکه با هم بریم سراغ Django Channels، یه کم درباره WebSocket بگیم که اصلاً بدونیم داریم درباره چی حرف می‌زنیم. خب، WebSocket یه پروتکل که بهت اجازه میده ارتباط دوطرفه و دائمی بین کلاینت و سرور داشته باشی. یعنی چی؟ یعنی مثلاً تو یه اپلیکیشن چت، به جای اینکه هر چند ثانیه یه بار درخواست بفرستی "چیزی جدید اومده؟"، سرور خودش هر وقت یه پیام جدید داشت، بلافاصله می‌فرسته سمتت 🚀.

حالا Django Channels چی میگه؟ 🤔
ـDjango Channels یه ابزار تو اکوسیستم Djangoئه که میاد پشتیبانی از WebSocket، پروتکل‌های real-time و کارای async رو به پروژه‌هات اضافه می‌کنه. به زبان ساده، اگه Django عادی رو یه "خیابون یک‌طرفه" فرض کنیم، Channels میاد این خیابون رو دوطرفه می‌کنه. این یعنی می‌تونی کارایی مثل:

چت real-time 💬

نوتیفیکیشن‌های فوری 🔔

استریم داده (مثل قیمت‌های ارز دیجیتال) 📈

و...

رو خیلی راحت‌تر با Django انجام بدی.

خب پس مشکلش چیه؟ چرا من ازش خوشم نمیاد؟ 🤷‍♂️

از دور که نگاه می‌کنی، Channels خیلی جذاب به نظر میاد، ولی وقتی می‌خوای باهاش کارکنی، مشکلات خودش رو نشون میده:

1⃣ پیچیدگی توی تنظیمات 😵‍💫
ـDjango همیشه به خاطر سادگی معروف بوده، ولی Channels میاد این سادگی رو خراب می‌کنه خیلی خراب میکنه. باید ASGI رو راه بندازی، Redis نصب کنی، routing یاد بگیری، و کلی تنظیمات دیگه انجام بدی. یه پروژه ساده که با Django راحت بود، یهو برات میشه یه جنگل از تنظیمات.

نکته: از Django 4.0 به بعد، پشتیبانی از ASGI مستقیم داخل هسته Django اومده، پس برای پروژه‌های ساده شاید نیاز نباشه کل پروژه رو وابسته به Channels کنی.

2⃣ وابستگی به Redis 🤦‍♂️
یکی از مشکلات بزرگ Channels اینه که برای مدیریت eventها و ارتباط‌ها حتماً نیاز به Redis داره. خب چرا؟ دلیلش اینه که Redis به‌عنوان message broker استفاده میشه تا پیام‌ها بین کلاینت‌ها و سرور مدیریت بشه. ولی اگه پروژه کوچیک باشه، این وابستگی می‌تونه دردسرساز بشه.

جایگزین: می‌تونی از RabbitMQ یا حتی راه‌حل‌های ساده‌تر مثل In-Memory Layers برای پروژه‌های سبک استفاده کنی.

3⃣ محدودیت توی scale کردن 😩
اگه پروژه کوچیک باشه، Channels بد نیست. ولی وقتی تعداد کاربران زیاد میشه و حجم درخواست‌ها بالا میره، Channels سریع از نفس می‌افته. این محدودیت بیشتر به خاطر پیچیدگی WebSocket و محدودیت‌های سرورهای تک رشته ای هست تا خود Channels. برای پروژه‌های بزرگ و real-time محور، ابزارای دیگه‌ای مثل Socket.IO یا FastAPI خیلی بهتر عمل می‌کنن.

4⃣ مشکلات performance 🚨
حتی اگه پروژه خیلی هم بزرگ نباشه، Channels برای real-time پروژه‌های سنگین خوب عمل نمی‌کنه. کارای پیچیده async و ارتباطات real-time می‌تونن سرور رو داغون کنن. البته با تنظیم درست workerها و Redis channel layers می‌تونی بخشی از این مشکلات رو کم کنی، ولی باز هم کار اضافه‌ست.

5⃣ کمبود مستندات و منابع آموزشی درست و حسابی 📚
یکی دیگه از مشکلات اینه که منابع آموزشی کامل و به‌روزی برای Channels خیلی کمه. هر وقت گیر کنی، یا باید بری توی GitHub دنبال issueها، یا دست به دامن دیگران بشی. این باعث میشه زمان زیادی صرف حل مشکلات کنی.

خب حالا راه‌حل چیه؟ 💡
اگه بخوای real-time کار کنی، اینا می‌تونن گزینه‌های بهتری باشن:

ـFastAPI: اگه دنبال سرعت، سادگی و پرفورمنس خوب هستی، FastAPI انتخاب فوق‌العاده‌ایه. با WebSocket خیلی راحت کار می‌کنه و خبری از دردسرای Channels نیست 🚀.

ـSocket.IO: این یکی برای پروژه‌های real-time شاهکاره. خیلی ابزارای متنوع داره و با Node.js هم عالی مچ میشه.


جمع‌بندی 🎯
ـDjango Channels می‌تونه برای پروژه‌های کوچیک و ساده مناسب باشه، ولی اگه بحث scale، پرفورمنس یا راحتی کار مطرح باشه، اصلاً گزینه خوبی نیست. من از پیچیدگی‌ها و محدودیت‌هاش خسته شدم و به جای اون سراغ ابزارای دیگه رفتم.
نظر تو چیه؟ Django Channels تا حالا اذیتت کرده یا ازش خوشت میاد؟ بگو ببینم چی تو ذهنت می‌گذره🧐

#programming #web #django

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

⚡️ خب خب خب starlette چیست؟ ⚡️

ـStarlette یکی از فریم‌ورک‌های عالی برای ساخت اپلیکیشن‌های وب در پایتونه که به طور خاص برای پردازش درخواست‌ها به صورت غیرهمزمان (async) ساخته شده. این فریم‌ورک با استفاده از ASGI (Asynchronous Server Gateway Interface)
سرعت و کارایی بالایی رو به ما میده.

یکی از ویژگی‌های خوب Starlette اینه که خیلی سبک و کم‌حجم هست، به طوری که می‌تونید به راحتی ازش برای ساخت سرویس‌ها و API های پیچیده استفاده کنید بدون اینکه بخواید با پیچیدگی‌های اضافی روبه‌رو بشید. 🚀

پشت صحنه‌ی Starlette 🎬
ـASGI:

ـStarlette از ASGI به جای WSGI استفاده می‌کنه. این تغییر باعث میشه که تو بتونی درخواست‌ها رو به صورت همزمان پردازش کنی و کارایی بهتری داشته باشی، مخصوصاً در مواقعی که نیاز به پردازش‌های طولانی یا مولتی تسک داری.

ـNon-blocking I/O:

با non-blocking I/O درخواستو عملیات ها منتظر نمی‌مونن. این یعنی که هر درخواست به سرعت پردازش می‌شه و سیستم هیچ‌وقت از کار نمی‌افته.

ـEvent-driven:

ـStarlette معماری event-driven داره، به این معنی که هیچ عملیات غیرضروری انجام نمیده. فقط وقتی که یه اتفاقی بیفته، کاری انجام می‌ده، که باعث میشه سرعت پردازش بالاتر بره.

ـMiddleware:

ـStarlette کاملاً روی middleware ها بنا شده که می‌تونید به راحتی ویژگی‌هایی مثل لاگینگ، احراز هویت، یا مدیریت خطاها رو به برنامه اضافه کنید.

ـUvicorn:

معمولا از Uvicorn برای راه‌اندازی اپلیکیشن استفاده میشه که یه سرور ASGI خیلی سریع و سبک هست. این باعث میشه که اپلیکیشن شما به راحتی به HTTP/2 و WebSocket متصل بشه.

چرا Starlette سریع‌تره؟ 💨
سبک بودن:
ـStarlette به شدت مینیمال طراحی شده و چیز اضافی توش نیست که بخواد سرعت رو پایین بیاره. به همین خاطر به راحتی می‌تونید اپلیکیشن‌هایی با کارایی بالا بسازید.

پشتیبانی از async:
استفاده از async و await برای پردازش درخواست‌ها بصورت همزمان باعث میشه تا اپلیکیشن شما بدون هیچ کندی درخواست‌ها رو پردازش کنه. این یه ویژگی خیلی مهم برای اپلیکیشن‌هایی هست که نیاز به سرعت بالا دارن.

ـUvicorn:
ـ Uvicorn باعث میشه که اپلیکیشن‌ها با کمترین تأخیر و بیشترین کارایی اجرا بشن.

پشتیبانی از WebSocket:
ـStarlette از WebSocket به خوبی پشتیبانی می‌کنه که باعث میشه اپلیکیشن‌های real time سریع و کارآمد اجرا بشن.

ویژگی‌های کاربردی Starlette 🛠️
ـWebSocket:

پشتیبانی از WebSocket برای اپلیکیشن‌های realt time مثل چت یا نوتیفیکیشن‌های زنده.

ـBackground Tasks:

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

ـMiddleware قدرتمند:

می‌تونید به راحتی هر middleware دلخواهی رو برای احراز هویت، لاگینگ و موارد دیگه اضافه کنید.

ـRouting منعطف:

مسیرهای URL رو می‌تونید به صورت خیلی دقیق و منعطف تعریف کنید.

و...

چرا starllete باعث سرعت Fastapi میشه؟ 🔄
در حقیقت، FastAPI یه فریم‌ورک مبتنی بر Starlette هست که ویژگی‌هایی مثل Pydantic برای اعتبارسنجی و OpenAPI برای مستندسازی خودکار API‌ها و... موارد دیگه رو اضافه کرده. بنابراین، FastAPI از Starlette استفاده می‌کنه.
پس الان کاملا براتون واضح هست که چرا Fastapi سریع هست

نمونه کد ساده از Starlette 🖥️

from starlette.applications import Starlette
from starlette.responses import JSONResponse
from starlette.routing import Route

async def homepage(request):
    return JSONResponse({'message': 'Hello, Starlette!'})

routes = [
    Route("/", endpoint=homepage)
]

app = Starlette(debug=True, routes=routes)

برای اجرای اپلیکیشن:

uvicorn app:app --reload 

اینم سایت خود starllette

https://www.starlette.io/

شیرو و ریکشن فراموش نشه ❤️

#programming #fastapi #web

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

دوستانیم که تازه تشریف اوردید کانال (خیلی خوش اومدید ❤️)

حتما این دسته بندی کانال رو مطالعه کنید که از مطالب قبلی کانال استفاده ببرید 😉

خب خب خب SMTP چیه؟ 📩

امروز می‌خوام درباره‌ی یه چیز خیلی مهم تو دنیای وب حرف بزنم: SMTP یا همون Simple Mail Transfer Protocol. شاید تا حالا اسمش رو شنیده باشین، ولی دقیقا چیه و چطور کار می‌کنه؟

📨 ‏SMTP چیه؟
‏SMTP یه پروتکل استاندارده که مسئول ارسال ایمیل‌ ها‌هست. اگه ایمیل رو مثل یه نامه در نظر بگیریم، SMTP همون پیک‌پستی‌ایه که نامه‌ت رو از صندوق تو به مقصد می‌رسونه.
این پروتکل تعیین می‌کنه که ایمیل از کجا بیاد، کجا بره و چجوری به درستی تحویل داده بشه.

🛠 چجوری کار می‌کنه؟
وقتی یه ایمیل می‌فرستی، پشت صحنه این اتفاقات میفته:
1️⃣ اتصال به سرور:

کلاینت ایمیل (مثل Gmail یا Outlook) به یه سرور SMTP متصل می‌شه تا ایمیل رو ارسال کنه.

2️⃣ دستورات ارسال می‌شن:

دستوراتی مثل HELO (یا EHLO) اجرا می‌شن تا ارتباط برقرار بشه. بعد، MAIL FROM و RCPT TO مشخص می‌کنن ایمیل از کجا اومده و قراره به کجا بره.

3️⃣ متن ایمیل ارسال می‌شه:

با دستور DATA، متن و جزئیات ایمیل به سرور فرستاده می‌شه. درست مثل وقتی که نامه‌ت رو به پیک‌پست تحویل می‌دی.

4️⃣ تأیید و پایان ارتباط:

بعد از ارسال، سرور یه تأییدیه می‌فرسته و ارتباط قطع می‌شه. این یعنی ایمیل با موفقیت ارسال شده.

🔒 نکات مهم درباره‌ی SMTP
🔹 استاندارد جهانی:

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

🔹 امنیت بالا:

بیشتر سرورها از TLS/SSL استفاده می‌کنن تا ایمیل‌ها رمزنگاری بشن و کسی نتونه تو مسیر ارسال، اطلاعات رو بدزده.

🔹 دستورات مهم:

‏HELO, MAIL FROM, RCPT TO, DATA از دستورات کلیدی SMTP هستن که تو پروسه‌ی ارسال اجرا می‌شن.

🔹 احراز هویت SMTP AUTH:

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

🎯 چرا SMTP مهمه؟
ما وقتی یه ایمیل می‌فرستیم، معمولا حواسمون به این نیست که چجوری ارسال می‌شه. اما پشت پرده، SMTP داره حسابی کار می‌کنه تا مطمئن بشه ایمیل سالم و بدون مشکل می‌رسه. بدون این پروتکل، ارسال ایمیل کلی دردسر داشت و ممکن بود پیام‌ها گم بشن یا به درستی تحویل داده نشن.

جمع‌بندی ✍
‏SMTP همون پیک‌پست دیجیتاله که ایمیل‌های ما رو جابه‌جا می‌کنه. با یه سری دستورات استاندارد و نکات امنیتی مثل TLS/SSL و SMTP AUTH، ایمیل‌ها رو با امنیت و اطمینان کامل ارسال می‌کنه.

#️⃣ #programming #web #backend

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

#MP4 #Security #Web #WordPress #Security_WP

🎥 آموزش تصویری 7 راه برای ایمن سازی وردپرس
➖➖➖➖➖
🆔 @PenetrationTest

پیرامون صحبت اخیر جلسه دوم انلاین ته‌لاگ در باب اقتصاد اون سورس
https://freeasinweekend.org

https://www.youtube.com/watch?v=0kQqONqMeLQ

سام علیک و از این حرفا Github Actions 🎬

حتماً اسم GitHub Actions به گوشتون خورده این ابزار می‌تونه خیلی از کارهای تکراری و روتین پروژه‌تون رو خودکار کنه، بدون اینکه لازم باشه خودتون دست به کار بشین. از بررسی کدهای کامیت‌شده تا اجرای تست‌ها و دیپلوی خودکار، همه‌چیز رو می‌سپارین بهش و خیالتون راحته تو این پست قراره حسابی راجب GitHub Actions حرف بزنیم، ببینیم این ابزار چیه، چه کارایی می‌تونه بکنه و چرا باید یه پای ثابت تو هر رپوی برنامه‌نویسی باشه.

🧠اول از همه GitHub Actions چیه؟

‏GitHub Actions یه پلتفرم اتوماسیونه که مستقیم تو GitHub ادغام شده و بهتون اجازه می‌ده workflow خودکار برای پروژه‌هاتون بسازین. این ابزار برای CI/CD (ادغام مداوم و تحویل/استقرار مداوم) (همیشه انگلیسی رو به معادل فارسی ترجیح میدم) طراحی شده، ولی فقط به این محدود نیست، می‌تونه هر کاری از تست کد و دیپلوی اپلیکیشن تا مدیریت مسائل (issues) و حتی ارسال نوتیفیکیشن رو خودکار کنه. به زبان ساده، GitHub Actions مثل یه رباته که با یه سری دستور (نوشته‌شده با YAML) بهش می‌گین چیکار کنه.

این ابزار از سال ۲۰۱۸ توسط GitHub معرفی شد و حالا یکی از محبوب‌ترین ابزارهای اتوماسیون تو اکوسیستم توسعه نرم‌افزاره، چون هم قدرتمنده، هم انعطاف‌پذیره و هم با خود GitHub جوش خورده.

📚 قابلیت‌های کلیدی GitHub Actions

1⃣ ‏CI/CD (ادغام و تحویل مداوم) 🛠️
می‌تونین پایپ لاین‌هایی بسازین که کدتون رو به‌صورت خودکار بیلد، تست و دیپلوی کنه.

مثال:
هر بار که یه تغییر (push) تو شاخه main می‌کنین، کد بیلد بشه، تست‌ها اجرا بشن و اگه همه‌چیز اوکی بود، به سرور production دیپلوی بشه.

name: CI Pipeline
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.10'
    - name: Install dependencies
      run: pip install -r requirements.txt
    - name: Run tests
      run: pytest

2⃣ اتوماسیون وظایف مختلف ⚙️
فراتر از CI/CD، می‌تونین هر کار تکراری رو خودکار کنین، مثل اضافه کردن لیبل به issues یا ارسال نوتیف به اسلک.

مثال:
وقتی یه issue جدید باز می‌شه، به‌صورت خودکار لیبل "triage" بهش اضافه بشه:

name: Auto Label Issues
on:
  issues:
    types: [opened]
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/github-script@v6
      with:
        script: |
          github.rest.issues.addLabels({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            labels: ['triage']
          })

3⃣ پشتیبانی از چند پلتفرم 🖥️
‏GitHub Actions روی ماشین‌های مجازی لینوکس، ویندوز و مک اجرا می‌شه. حتی می‌تونین self-hosted runners (ماشین‌های خودتون) رو استفاده کنین.

مثال: تست کد روی نسخه‌های مختلف پایتون و سیستم‌عامل‌ها با یه matrix workflow:

name: Test on Multiple Platforms
on: [push]
jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        python-version: ['3.8', '3.9', '3.10']
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}
    - name: Run tests
      run: pytest

4⃣ اکشن‌های آماده و Marketplace 🛒
یه عالمه اکشن آماده تو GitHub Marketplace وجود داره که می‌تونین مستقیم تو ورک‌فلاتون استفاده کنین.

مثال: اکشن برای ارسال نوتیفیکیشن به اسلک یا دیپلوی به AWS.

- name: Notify Slack
  uses: slackapi/[email protected]
  with:
    slack-bot-token: ${{ secrets.SLACK_BOT_TOKEN }}
    channel-id: 'my-channel'
    text: 'New deployment completed!'

✍ جمع‌بندی
‏GitHub Actions یه ابزار قدرتمند و انعطاف‌پذیره که می‌تونه پروژه‌هاتون رو از یه مجموعه کد ساده به یه سیستم خودکار و حرفه‌ای تبدیل کنه. از CI/CD و تست چندپلتفرمی گرفته تا اتوماسیون کارهای روزمره مثل ارسال اعلان یا مدیریت مسائل، این ابزار همه‌چیز رو تو یه پکیج بهتون می‌ده. فقط کافیه یه فایل YAML بسازین.

اگه خواستین بیشتر درمودش صحبت بکنم و نکات حرفه ای تری بگم با ریکشن و شیر این پست رو حمایت کنید 😊❤️

#️⃣ #web #programming

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

چرا Async تو کار با دیتابیس همیشه کار امد نیست؟ 🧵

یه باور رایج بین برنامه‌نویس ها اینه که استفاده از Async (برنامه‌نویسی ناهمزمان) تو همه‌چیز معجزه می‌کنه، مخصوصاً وقتی با دیتابیس کار می‌کنین. اما می‌دونستید که Async زدن کد برای کار با دیتابیس همیشه اون تأثیر که فکر می‌کنید رو نداره؟ تو این پست قراره ببینیم چرا.

🧠 چرا Async تو دیتابیس تأثیر کمی داره؟

وقتی با دیتابیس کار می‌کنین (مثل PostgreSQL، MySQL یا MongoDB)، عملیات‌ها مثل خوندن (SELECT)، نوشتن (INSERT) یا آپدیت کردن معمولاً CPU-bound هستن، نه I/O-bound. حالا این یعنی چی؟

‏CPU-bound:
یعنی گلوگاه اصلی تو عملیات، پردازش CPUئه. مثلاً وقتی یه کوئری SQL اجرا می‌کنی، دیتابیس باید کارایی مثل پارس کردن کوئری، بهینه‌سازی پلن، پردازش داده‌ها و مرتب‌سازی رو انجام بده. اینا همشون به CPU وابسته‌ان.

‏I/O-bound:
یعنی گلوگاه اصلی منتظر موندن برای ورودی/خروجی (مثل خوندن از دیسک یا شبکه). Async تو این سناریوها خوب عمل میکنه چون می‌تونه CPU رو آزاد کنه تا وقتی منتظر I/O هستیم، کارهای دیگه انجام بده.

دیتابیس‌ها معمولاً تو محیط‌های خودشون بهینه شدن که عملیات CPU-bound رو سریع انجام بدن (مثل استفاده از ایندکس‌ها یا کش). برای همین، وقتی از یه کلاینت (مثل یه برنامه پایتون) به دیتابیس وصل می‌شین، بیشتر زمان صرف پردازش کوئری تو خود دیتابیسه، نه منتظر شبکه یا دیسک. حالا Async (مثل async/await تو پایتون) اینجا کمک زیادی نمی‌کنه، چون CPU داره کار اصلی رو انجام می‌ده و چیزی برای "منتظر موندن" وجود نداره.

مثال ساده:
فرض کنین یه کوئری سنگین مثل این تو PostgreSQL دارین:

SELECT * FROM orders WHERE total > 1000 ORDER BY created_at;

این کوئری CPU دیتابیس رو حسابی درگیر می‌کنه (برای فیلتر کردن و مرتب‌سازی). حالا اگه تو پایتون اینو با یه کلاینت sync (مثل psycopg2) یا async (مثل asyncpg) اجرا کنین، تفاوت سرعت خیلی کمه، چون گلوگاه اصلی تو خود دیتابیسه، نه تو کلاینت.

📚 چرا Async همیشه مفید نیست؟

وقتی از یه کلاینت Async استفاده می‌کنین (مثل asyncpg یا motor برای MongoDB)، انتظار دارین عملیات دیتابیس سریع‌تر بشه چون می‌تونه همزمان کارهای دیگه رو انجام بده. اما چندتا دلیل باعث می‌شه این تأثیر کم باشه:

1⃣ گلوگاه تو دیتابیسه:
همون‌طور که گفتم، بیشتر عملیات دیتابیس CPU-bound هستن. Async فقط می‌تونه I/O شبکه رو مدیریت کنه (مثل زمان ارسال کوئری یا گرفتن نتیجه)، ولی این بخش معمولاً کسری از کل زمانه.

2⃣ ‏Overhead خود Async: استفاده از async/await یه مقدار سربار (overhead) به کد اضافه می‌کنه. اگه عملیات دیتابیستون سریع باشه (مثلاً چند میلی‌ثانیه)، این سربار ممکنه حتی باعث شه Async کندتر بشه.

3⃣ مدیریت اتصالات:
دیتابیس‌ها معمولاً تعداد اتصالات همزمان (connection pool) رو محدود می‌کنن. حتی با Async، اگه تعداد کوئری‌ها زیاد باشه، ممکنه منتظر اتصال بمونین.

🔍 کی Async به کار میاد؟

هرچند Async تو اکثر عملیات دیتابیس تأثیر زیادی نداره، تو یه سری سناریوها می‌تونه خوب عمل کنه:

1⃣ دیتابیس‌های توزیع‌شده:
تو دیتابیس‌های NoSQL مثل MongoDB یا Cassandra که عملیات شبکه‌ای (مثل اتصال به نودهای مختلف) زمان‌بره، Async می‌تونه کمک کنه کلاینت همزمان چند درخواست رو مدیریت کنه.

2⃣ عملیات I/O-heavy:
اگه دیتابیستون روی یه سرور دور باشه یا شبکه کند باشه، Async می‌تونه زمان انتظار برای اتصال و انتقال داده رو بهتر مدیریت کنه.

3⃣ چندین درخواست همزمان:
اگه برنامه‌تون نیاز داره چند کوئری رو به‌صورت موازی اجرا کنه (مثل یه API که باید از چند جدول داده جمع کنه)، Async می‌تونه این درخواست‌ها رو همزمان مدیریت کنه.

4⃣ دیتابیس‌های خاص:
بعضی دیتابیس‌ها مثل CockroachDB یا Redis که برای عملیات سریع و توزیع‌شده طراحی شدن، با کلاینت‌های Async بهتر کار می‌کنن.

✍ جمع‌بندی
اینکه بگیم Async تو کار با دیتابیس معجزه می‌کنه یه کم زیاده‌رویه چون بیشتر عملیات دیتابیس CPU-bound هستن، استفاده از کلاینت‌های Async مثل asyncpg یا motor معمولاً تأثیر چشمگیری روی پرفورمنس نداره. اما تو سناریوهای خاص مثل دیتابیس‌های توزیع‌شده، عملیات شبکه‌محور یا درخواست‌های موازی، Async می‌تونه مفید باشه. پس قبل از اینکه همه‌چیز رو Async کنین، نوع عملیات‌تون رو بررسی کنین و ببینین کجا واقعاً به کارتون میاد.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

این داستان ‏Query Planning 😯

احتمالا با دیتابیس هایی مثل PostgreSQL یا MySQL کوئری زدین، اگه دقت کرده باشید این کوری ها چه ساده باشن چه پیچیده سریع اجرا میشن، دلیلشم تو یه فرایند جالب به اسم Query Planning هست.
تو این پست قراره ببینیم چیه، چطور کار می‌کنه.

‏🧠 Query Planning چیه؟

‏Query Planning (یا برنامه‌ریزی کوئری) فرایندی تو دیتابیس‌های رابطه‌ایه که توش دیتابیس تصمیم می‌گیره بهترین راه برای اجرای یه کوئری SQL چیه. وقتی یه کوئری مثل SELECT * FROM users WHERE age > 30
می‌نویسین، دیتابیس نمی‌ره مستقیم اجرا کنه؛ اول یه نقشه می‌کشه که چطور داده‌ها رو پیدا کنه، فیلتر کنه و برگردونه. این نقشه که بهش Query Plan یا Execution Plan می‌گن، مثل یه GPSه که به دیتابیس می‌گه از کدوم مسیر بره تا سریع‌تر به مقصد برسه.

هدف اصلیش بهینه‌سازی پرفورمنس با کم کردن زمان اجرا، مصرف CPU، حافظه و I/O (خوندن/نوشتن دیسک). دیتابیس این کار رو با تحلیل ساختار کوئری، آمار جدول‌ها و ایندکس‌ها انجام می‌ده.

‏📚 Query Planning چطور کار می‌کنه؟

دیتابیس‌ها (مثل PostgreSQL، MySQL، SQL Server) یه بخش به اسم Query Optimizer دارن که مسئول ساختن پلن بهینه‌ست. بیاین قدم‌به‌قدم ببینیم چی به چیه:

1⃣ پارس کردن کوئری (Parsing)
دیتابیس اول کوئری رو بررسی می‌کنه تا مطمئن شه درست نوشته شده (از نظر گرامری و معنایی). مثلاً چک می‌کنه جدول users وجود داره یا نه.
خروجی این مرحله یه درخت نحوی (parse tree)ه که ساختار کوئری رو نشون می‌ده.

2⃣ بازنویسی کوئری (Rewriting)
تو این مرحله، دیتابیس کوئری رو ساده‌تر یا بهینه‌تر می‌کنه، بدون اینکه نتیجه‌ش تغییر کنه. مثلاً:
  تبدیل ساب کوری ها به جوین‌ها.
  حذف شرط‌های اضافی (مثل WHERE TRUE).
تو PostgreSQL، این کار توسط Query Rewriter انجام می‌شه.

3⃣ تولید پلن‌های ممکن (Plan Generation)
حالا Query Optimizer کلی پلن ممکن برای اجرای کوئری می‌سازه. مثلاً برای یه کوئری ساده:

  SELECT * FROM users WHERE age > 30;
  

  ممکنه این گزینه‌ها بررسی شه:

  ‏Sequential Scan:
کل جدول رو خط‌به‌خط بخونه.

  ‏Index Scan:
از ایندکس روی ستون age استفاده کنه.

  ‏Bitmap Scan:
ترکیبی از ایندکس و اسکن.

برای کوئری‌های پیچیده (با جوین، گروه‌بندی و غیره)، تعداد پلن‌ها می‌تونه به هزارتا برسه

4️⃣ تخمین هزینه (Cost Estimation)
دیتابیس برای هر پلن یه هزینه (cost) تخمین می‌زنه. این هزینه یه عدد خیالیه که شامل:

  مصرف CPU (برای مقایسه‌ها، مرتب‌سازی و غیره).

  ‏I/O (خوندن از دیسک یا کش).

شبکه (اگه دیتابیس توزیع‌شده باشه).

دیتابیس از آمار جدول‌ها (مثل تعداد ردیف‌ها، توزیع داده‌ها) و ساختار ایندکس‌ها برای این تخمین استفاده می‌کنه.
مثلاً تو PostgreSQL، دستور ANALYZE این آمار رو به‌روز می‌کنه.

5️⃣ انتخاب بهترین پلن
‏Optimizer پلنی رو انتخاب می‌کنه که کمترین هزینه رو داره. این پلن می‌شه Execution Plan و برای اجرا به Executor فرستاده می‌شه.
تو بعضی دیتابیس‌ها (مثل Oracle)، می‌تونین از hints استفاده کنین تا Optimizer رو به یه پلن خاص هدایت کنین.

6️⃣ اجرا و بازخورد
بعد از اجرا، دیتابیس ممکنه بازخورد بگیره (مثلاً آمار واقعی تعداد ردیف‌ها) و پلن‌های بعدی رو بهتر کنه.

🛠 چرا Query Planning مهمه؟

‏Query Planning مثل مغز دیتابیسه و مستقیم روی پرفورمنس تأثیر می‌ذاره:

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

مصرف منابع: پلن بد می‌تونه CPU و دیسک رو بیخودی درگیر کنه و سرور رو خفه کنه.

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

تجربه کاربر: اگه API‌تون به یه دیتابیس کند وصل باشه، کاربراتون فرار می‌کنن

🔍 مشکلات رایج تو Query Planning

آمار قدیمی: اگه آمار جدول‌ها به‌روز نباشه، Optimizer ممکنه پلن بد انتخاب کنه.

کوئری‌های پیچیده: جوین‌های چندگانه یا شرط‌های مبهم می‌تونن Optimizer رو گیج کنن.

عدم ایندکس: بدون ایندکس، دیتابیس مجبوره کل جدول رو اسکن کنه.

دیتابیس‌های توزیع‌شده:
تو دیتابیس‌هایی مثل CockroachDB، شبکه هم به معادله اضافه می‌شه و پلن‌ها پیچیده‌تر می‌شن.

✍ جمع‌بندی

‏Query Planning مثل یه شطرنج‌باز حرفه‌ایه که تو دیتابیس تصمیم می‌گیره بهترین حرکت چیه. با تحلیل کوئری، آمار جدول‌ها و ایندکس‌ها، یه پلن بهینه می‌سازه که می‌تونه سرعت و کارایی پروژه‌تون رو زیر و رو کنه.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

این داستان Pypy 🐉

‏PyPy ابزاری قدرتمند برای برنامه‌نویس‌های پایتونه که به دنبال بهبود پرفورمنس کدهای خودشون هستن. اگه با کندی اجرای کد تو پروژه‌هاتون مواجه شدین یا می‌خواین بدونین چطور می‌شه سرعت پایتون رو بدون تغییر زیاد تو کد بالا برد، این پست برای شماست. اینجا قراره بررسی کنیم PyPy چیه، چه قابلیت‌هایی داره، کجا به کار میاد و چه محدودیت‌هایی داره.

🧠اول از همه PyPy چیه؟
‏PyPy یه مفسر (interpreter) جایگزین برای پایتونه که به جای CPython (مفسر استاندارد پایتون که با C نوشته شده) استفاده می‌شه. PyPy خودش با پایتون (به طور دقیق‌تر، یه زیرمجموعه به اسم RPython) پیاده‌سازی شده و از Just-In-Time Compilation (JIT) برای کامپایل کردن کد پایتون به کد ماشین تو زمان اجرا استفاده می‌کنه. این باعث می‌شه تو خیلی از سناریوها سرعتش به مراتب از CPython بیشتر باشه.

شروع این پروژه به سال ۲۰۰۲ برمی‌گرده و حالا یه پروژه متن‌باز با جامعه‌ای فعاله که مدام در حال بهبودشه. هدف PyPy اینه که کدهای پایتون رو سریع‌تر، بهینه‌تر و بدون نیاز به تغییر زیاد تو ساختار کد اجرا کنه.


📚 قابلیت‌های مهم PyPy

‏PyPy چندتا ویژگی اصلی داره که اون رو از CPython متمایز می‌کنه:

1⃣ سرعت بالا با JIT Compilation
‏PyPy به جای تفسیر خط‌به‌خط کد (مثل CPython)، بخش‌های پرتکرار کد رو به کد ماشین کامپایل می‌کنه. این یعنی برای حلقه‌ها و عملیات تکراری، سرعتش خیلی بیشتره.
مثال: یه تابع ساده برای محاسبه فیبوناچی:

  def fib(n):
      if n <= 1:
          return n
      return fib(n-1) + fib(n-2)
  print(fib(35))
  

تو CPython این کد برای n=35 ممکنه چند ثانیه طول بکشه، ولی تو PyPy به لطف JIT خیلی سریع‌تره (گاهی تا ۷ برابر).

2⃣ سازگاری بالا با پایتون
‏PyPy سعی می‌کنه تا حد زیادی با استانداردهای CPython سازگار باشه، یعنی اکثر کدهای پایتون بدون تغییر روی PyPy اجرا می‌شن.
مثلا اگه یه اسکریپت با Python 3.8 روی CPython کار کنه، به احتمال زیاد روی PyPy هم بدون دردسر اجرا می‌شه مگر از کتابخانه هایی استفاده کرده باشید که C extension استفاده میکنه.

3⃣ مصرف حافظه بهینه
‏PyPy یه Garbage Collector پیشرفته داره که می‌تونه مصرف حافظه رو تو بعضی سناریوها بهینه‌تر از CPython کنه.
کاربردشم تو برنامه‌هایی که مدت طولانی اجرا می‌شن (مثل وب‌سرورها) و نیاز به مدیریت خوب حافظه دارن.

4⃣پشتیبانی از Stackless Python
‏PyPy از قابلیت‌های Stackless Python (مثل micro-threads یا taskletها) پشتیبانی می‌کنه که برای برنامه‌های concurrent مناسبن.

🔍 چرا PyPy مناسبه؟
PyPy تو موقعیت‌هایی که پرفورمنس کد حیاتیه، می‌تونه بازی رو عوض کنه:

سرعت:
تو بنچمارک‌های مختلف، PyPy برای کدهای محاسباتی (مثل حلقه‌ها و الگوریتم‌های ریاضی) تا ۷ برابر سریع‌تر از CPython عمل کرده.

بدون نیاز به بازنویسی کد: برخلاف ابزارهایی مثل Cython که نیاز به تغییر کد دارن، PyPy فقط با تغییر مفسر کار می‌کنه.

متن‌باز و فعال:
جامعه PyPy مدام داره باگ‌ها رو فیکس می‌کنه و پشتیبانی از نسخه‌های جدید پایتون رو اضافه می‌کنه.


🛠 کجا PyPy به کار میاد؟

1⃣ محاسبات سنگین:
اگه پروژه‌تون پر از حلقه‌های پیچیده یا الگوریتم‌های محاسباتیه (مثل پردازش داده یا شبیه‌سازی)، PyPy سرعت رو حسابی بالا می‌بره.

2⃣ وب‌سرورها:
برای وب‌اپلیکیشن‌هایی که با فریم‌ورک‌هایی مثل Flask یا Django کار می‌کنن، PyPy می‌تونه پاسخ‌گویی رو بهتر کنه.

3⃣ اسکریپت‌های طولانی‌مدت: برنامه‌هایی که مدت زیادی اجرا می‌شن (مثل دیمن‌ها یا سرویس‌ها) از بهینه‌سازی حافظه PyPy سود می‌برن.

📚 محدودیت‌های PyPy

هرچند PyPy عالیه، ولی محدودیت‌هایی هم داره:

1⃣ عدم پشتیبانی کامل از C Extensions:
خیلی از کتابخونه‌های پایتون (مثل NumPy، Pandas یا TensorFlow) از C Extensionها استفاده می‌کنن که تو PyPy ممکنه کندتر باشن یا کار نکنن. البته PyPy داره روی این موضوع کار می‌کنه.

2⃣ سربار اولیه JIT:
‏PyPy تو شروع اجرا یه کم کندتره چون باید کد رو کامپایل کنه. برای اسکریپت‌های کوتاه این می‌تونه نقطه‌ضعف باشه.

3⃣ مصرف حافظه اولیه:
‏ PyPy گاهی تو شروع کار حافظه بیشتری نسبت به CPython مصرف می‌کنه.

✍ جمع‌بندی

‏PyPy یه ابزار قدرتمنده که می‌تونه کدهای پایتون شما رو بدون نیاز به بازنویسی، سریع‌تر و بهینه‌تر اجرا کنه. با استفاده از JIT Compilation، این مفسر برای پروژه‌های محاسباتی، وب‌اپلیکیشن‌ها و اسکریپت‌های طولانی‌مدت یه انتخاب عالیه. هرچند محدودیت‌هایی مثل سازگاری با C Extensionها داره، ولی برای خیلی از سناریوها می‌تونه پرفورمنس رو چند برابر کنه.

#️⃣ #web #programming

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

خب همونجور که میدونید درمورد GIL یا همون Global Interpreter Lock بحث زیاده 🤯

مشکل ما با GIL چیه؟
اینه که نمیذاره مولتی‌تردینگ واقعی داشته باشیم.
یعنی چی؟
یعنی نمی‌تونیم چندتا تسک رو همزمان روی چندتا ترد اجرا کنیم.
چرا؟
چون GIL میگه:
«در هر لحظه فقط یه ترد حق داره اجرا بشه، بقیه باید وایسن نوبتشون بشه.»

حالا نکته بامزه اینجاست:
اگه بیای چندتا ترد ران کنی، این تردا میان سر GIL دعوا می‌کنن کلی context switching می‌خوره latency میره بالا یه عالمه overhead میاد رو برنامه.
نتیجه؟ مولتی‌تردینگ برای کارای CPU-bound نه تنها کمک نمی‌کنه، بدترم می‌کنه برای همین باید single-thread باشه 😅
(احتمالاً خودتونم وقتی async برای CPU-bound نوشتید دیدید چه وضعیه.)

حالا چرا اصلاً GIL وجود داره؟
سؤال خوبیه 👌
خیلی خلاصه بگم نذاشته پایتون به چوخ بره 😂
چطوری؟
میاد thread safety رو برات تضمین می‌کنه، نمیذاره race condition بیاد وسط و همه چی بترکه.

ولی خب GIL دردسرم کم درست نمیکنه:

نمیذاره مولتی‌تردینگ CPU-bound داشته باشیم.

بعدم بخوای حذفش کنی هزاران لایبری که با درنظر گرفتن gil نوشته شده باید اپدیت بشن :)

و....
کلاً محدودمون می‌کنه.

راه‌حل چیه؟

1. C Extension
یعنی توابع سنگینت رو تو C بنویسی، اونجا اجرا بشه، فقط از پایتون صدا بزنی. اینجوری GIL رو می‌تونی دور بزنی.

2. Multiprocessing
این یکی مطرح ترین راهه. به تعداد core های CPU پروسس بالا میاری. هر پروسس مفسر خودش و در نتیجه GIL خودش رو داره اینجا واقعاً موازی میشه.
ولی اینجا یه توهمه که «ایول مشکل حل شد»…
سخت در اشتباهید 😅
چرا؟
چون:
ـprocess خیلی سنگینه، هر کدوم کلی overhead دارن.

ارتباط بین processها (همون IPC) خودش یه هزینه‌ی جداست.
داده‌ها باید بین processها جابه‌جا بشن (queue، pipe، shared memory و …) که اینم کندی و مصرف حافظه میاره.

گزینه اپشنال شدن گیل هم توی ۳.۱۳ کامل گیل رو حذف نمیکنه میتونیم مولتی پراسسینگ و موازی سازی کنیم ولی خب خودشون هنوز تایید نکرده و ازمایشیه و کلی مشکلات داره.

گزینه هاییم هست مثل استفاده از nogil که خب یکسری مشکلات دارن که توی این پست جا نمیشن بگم

📌 خلاصه: GIL هم ناجیه، هم قاتل. ناجی چون امنیت میده، قاتل چون مولتی‌تردینگ CPU-bound رو ازمون میگیره. ولی خب این مورد توی I/O bound process نیست چون وقتی یه پراسس io ران میشه گیل خاموش میشه و میتونی parallel processing داشته باشی :)

#️⃣ #web #programming

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

🔹 سیستم چت حرفه ای در وردپرس (فارسی) علیرضا ریسی

📌 تمام جلسات یکجا

#فیلم #ویدئو #وب #وبسایت #وردپرس #چت
#Video #Web #Website #WordPress #Chat #Online_Chat
🆑 @Computer_IT_Engineering

تا حالا کلی مطالب خفن و کاربردی تو کانال NinjaLearn براتون آماده کردیم و الان صدها مطلب مختلف و جذاب داریم.

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


این شما و این لیست دسته‌بندی‌های کانال🔻:

🦫 #go: آموزش‌ها و نکات کاربردی زبان گو

💻 #programming: مطالب برنامه نویسی

🐍 #python: ترفندها و نکات پایتونی

🦄 #django: مطالب فریم‌ورک جنگو

⚡️ #fastapi: مطالب فریم ورک فست

🌐 #web: مطالب مرتبط به وب

📡 #network: مطالب مرتبط به شبکه

🗂️ #db: معرفی و نکات دیتابیس

🔖 #reference: معرفی مقاله و ویدیو

📢 #notif: اطلاع رسانی ها

❓ #question: سوالات جالب در برنامه نویسی

🎊 #event: رویداد هایی که معرفی کردیم

🎬 #movie: معرفی فیلم و سریال

📚 #book: معرفی کتاب‌های تخصصی

🤖 #AI: مطالب مرتبط به هوش مصنوعی

📊 #ml: مطالب مرتبط به یادگیری ماشین

🛠️ #backend: آموزش‌ها و ترفندهای بک‌اند

🔒 #security: نکات امنیتی

⚙ #devops: مطالب مرتبط به دواپس

📺 #YouTube: ویدیوهای چنل یوتیوب ما

🌏 #geo: تکنولوژی های جغرافیایی

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

اگه موضوع جدیدی به مطالب کانال اضافه بشه، حتماً تو این لیست قرار می‌گیره ✅

راستی میتونید بنر کانال رو برای دوستاتون هم بفرستید تا اونا هم به جمع ما بپیوندن و از این مطالب مفید استفاده کنن 😉

NinjaLearn Banner 🥷🤝

#category

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

🔶 استک های برنامه نویس وب :

1. MERN
MongoDB + Express.js + ReactJS + Node.js

2. LEMP
Linux + Nginx + MySQL + PHP

3. MEVN
MongoDB + Express.js + Vue.js + Node.js

4. MEAN
MongoDB + Express.js + AngularJS + Node.js

5. LAMP
Linux + Apache + MySQL + PHP

#web

@TheRaymondDev