آموزش ویدیویی جاوا اسکریپت، Node.js ، React ، jQuery ، Vue و ...
1.61K subscribers
155 photos
71 videos
121 files
1.85K links
Download Telegram


🔵 نکته برنامه نویسی



CQRS (Command Query Responsibility Segregation) 📑


خواندن (Query) و نوشتن (Command) داده‌ها رو جدا می‌کنه.
اینطوری می‌تونی خوندن داده‌ها رو سریع و سبک کنی، و نوشتن داده‌ها رو دقیق و امن.
خیلی برای سیستم‌های بزرگ مقیاس (enterprise) استفاده میشه.


ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
💡 نکته #React

🟣 موضوع : ‏مدیریت استایل‌ها در پروژه‌های بزرگ

نکته :

‏از یه سیستم توکن (Design Tokens) برای رنگ‌ها، فونت‌ها و فاصله‌ها استفاده کن. اینطوری کل پروژه یکدست می‌مونه. 🎨


ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین

از SARIMA برای مدل‌سازی سری‌های زمانی فصلی استفاده می‌شه.

🔹 SARIMA = ARIMA + Seasonal Components

AR, I, MA مثل ARIMA کلاسیک

Seasonal AR, Seasonal I, Seasonal MA برای الگوهای تکراری فصلی

🔹 مثال: پیش‌بینی فروش ماهانه محصول که هر سال در تابستان افزایش داره ☀️📈

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

به زبان ساده: SARIMA مثل ARIMA با “چشمی که الگوهای فصلی رو هم می‌بینه” 👀

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


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




🌱 Strangler Fig Pattern



🔹 ایده اصلی

وقتی می‌خوای یک سیستم قدیمی (Legacy System) رو بازنویسی کنی، خیلی پرریسکه که همه چیز رو یک‌باره تغییر بدی (Big Bang Rewrite).

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



مراحل کار

1. درخواست‌های کاربر اول به یک Facade (دروازه) می‌رن.
2. این Facade تصمیم می‌گیره هر درخواست به سیستم قدیمی بره یا به ماژول جدید.
3. به مرور ماژول‌های جدید اضافه می‌شن و جایگزین بخش‌های قدیمی می‌شن.
4. در نهایت سیستم قدیمی کامل حذف می‌شه.



مثال ساده (Python)

class LegacySystem:
def process(self, request):
return f"📟 Legacy response for {request}"


class NewSystem:
def process(self, request):
return f"🚀 New response for {request}"


class StranglerFacade:
def __init__(self):
self.legacy = LegacySystem()
self.new = NewSystem()

def handle_request(self, request):
# به مرور شرط‌ها تغییر می‌کنن
if request.startswith("new_"):
return self.new.process(request)
else:
return self.legacy.process(request)


# تست
facade = StranglerFacade()
print(facade.handle_request("old_feature")) # 📟 Legacy response for old_feature
print(facade.handle_request("new_feature")) # 🚀 New response for new_feature


📖 کاربردهای واقعی

⬅️ مهاجرت سیستم بانکی قدیمی به معماری مایکروسرویس
⬅️ انتقال اپلیکیشن‌های قدیمی به Cloud بدون خاموش کردن سیستم
➡️ Refactoring تدریجی سیستم‌های بزرگ



🛠️ مزایا

⬅️ مهاجرت بدون ریسک بالا
⬅️ سیستم همیشه قابل استفاده می‌مونه (Downtime نزدیک به صفر)
⬅️ امکان تست بخش‌های جدید در کنار بخش‌های قدیمی



🎯 تشبیه ساده

مثل بازسازی یک خونه قدیمی 🏚️ → دیوارها رو یکی‌یکی تعمیر می‌کنی و خونه جدید رو می‌سازی، در حالی که هنوز می‌تونی توی خونه زندگی کنی.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
💡 نکته #React

🟣 موضوع : ‏مقدمه‌ای بر ساختار پروژه در React

نکته :

‏فایل index.js نقطه شروع گشت و گذارته؛ از همینجا همه چیز شروع میشه! 🚀


ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


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




🚦 Rate Limiting

(محدودسازی نرخ درخواست‌ها)


🔹 ایده اصلی

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

⬅️ یک کاربر فقط می‌تونه ۱۰ درخواست در دقیقه بفرسته.
⬅️ یا هر IP نهایتاً ۱۰۰۰ درخواست در روز داشته باشه.



🔹 چرا مهمه؟

⬅️ جلوگیری از سوءاستفاده (DoS, Brute Force, Spam)
⬅️ کنترل هزینه‌های سرور و API
⬅️ ایجاد عدالت بین کاربران (یکی همه منابع رو نبلعه 😅)



مثال ساده (Python)

import time

class RateLimiter:
def __init__(self, max_calls, period):
self.max_calls = max_calls
self.period = period
self.calls = []

def allow(self):
now = time.time()
# پاک کردن درخواست‌های قدیمی‌تر از period
self.calls = [t for t in self.calls if t > now - self.period]

if len(self.calls) < self.max_calls:
self.calls.append(now)
return True
return False


# مثال: حداکثر 3 درخواست در 10 ثانیه
limiter = RateLimiter(3, 10)

for i in range(5):
if limiter.allow():
print(f" درخواست {i+1} پذیرفته شد")
else:
print(f" درخواست {i+1} رد شد")
time.sleep(2)


📖 کاربردهای واقعی

➡️ APIهای عمومی (مثل GitHub API → محدودیت درخواست‌ها در ساعت)
⬅️ سیستم لاگین → جلوگیری از Brute Force (مثلاً نهایتاً ۵ بار تلاش در ۱ دقیقه)
⬅️ وب‌سایت‌ها برای جلوگیری از اسپم در فرم‌ها یا چت‌ها
⬅️ پرداخت آنلاین → محدود کردن تعداد تراکنش‌های یک کارت در روز



🛠️ مزایا

⬅️ افزایش امنیت
⬅️ بهبود پایداری سیستم در برابر ترافیک زیاد
⬅️ مدیریت منصفانه منابع



⚠️ چالش‌ها

⬅️ پیاده‌سازی توزیع‌شده (در چند سرور مختلف) سخت‌تره
⬅️ ممکنه باعث نارضایتی کاربران واقعی بشه (اگه بیش از حد سخت‌گیرانه باشه)



🎯 تشبیه ساده

Rate Limiting مثل چراغ قرمز سر چهارراه 🚦 هست:

⬅️ حتی اگه همه بخوان رد شن، چراغ فقط به تعداد مشخصی اجازه میده.
⬅️ بقیه باید صبر کنن تا دوباره نوبتشون بشه.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکات برنامه‌نویسی



📖 Tolerant Reader Pattern



🔹 ایده اصلی

وقتی داده (مثلاً JSON یا XML) از یک سرویس خارجی میاد، ممکنه در طول زمان تغییر کنه.

⬅️ اگر مصرف‌کننده (Consumer) ما خیلی سخت‌گیر باشه، با کوچکترین تغییر، سیستم کرش می‌کنه.
⬅️ ولی با Tolerant Reader ما فقط بخش‌های موردنیاز رو می‌خونیم و بقیه رو نادیده می‌گیریم.

به این ترتیب سیستم ما در برابر تغییرات کوچک مقاوم میشه.



مثال ساده (Python)

فرض کن یک سرویس API این داده رو می‌ده:

{
  "id": 101,
  "name": "Alice",
  "email": "alice@example.com",
  "extra_field": "something new"
}
نسخه قدیمی کد ما:

import json

def parse_user(data):
    user = json.loads(data)
    return {
        "id": user["id"],
        "name": user["name"],
        "email": user["email"]
    }

data = '{"id": 101, "name": "Alice", "email": "alice@example.com", "extra_field": "something new"}'
print(parse_user(data))
🔹 اینجا اگر فیلد جدیدی مثل extra_field بیاد → کد ما اصلاً حساسیتی نشون نمی‌ده.
ولی اگر ما همه فیلدها رو به شکل سخت‌گیرانه چک می‌کردیم → کرش می‌کرد.



📖 کاربردهای واقعی

➡️ APIهای نسخه‌دار (Versioned APIs): وقتی یک API فیلدهای جدید اضافه می‌کنه، کلاینت‌های قدیمی همچنان کار کنن.
⬅️ سیستم‌های توزیع‌شده: جایی که Producer و Consumer همیشه Sync نیستن.
➡️ Backward Compatibility: پشتیبانی از نسخه‌های قدیمی داده.



🛠️ مزایا

⬅️ مقاوم در برابر تغییرات کوچک
⬅️ جلوگیری از Down شدن سرویس در تولید (Production)
⬅️ امکان توسعه سریع‌تر API بدون نگرانی از شکستن Clientها



🎯 تشبیه ساده

مثل وقتی که تو یک فرم پر می‌کنی:

⬅️ برایت فقط "نام" و "ایمیل" مهمه.
⬅️ اگر طرف مقابل یک "شماره موبایل" یا "عکس پروفایل" هم فرستاد، تو نادیده می‌گیری و کارت رو انجام می‌دی.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی


بریم سراغ Circuit Breaker Pattern 🔌



🎯 تعریف Circuit Breaker

وقتی برنامه شما به یک سرویس خارجی (مثل API، دیتابیس یا سرویس پرداخت) وابسته است، اگر اون سرویس خراب بشه یا کند بشه، ممکنه کل سیستم شما هم قفل کنه.
Circuit Breaker مثل یک فیوز برق عمل می‌کنه:

* اگر درخواست‌ها پشت سر هم fail بشن، ارتباط رو موقتاً قطع می‌کنه.
* بعد از مدتی دوباره تست می‌کنه که سرویس درست شده یا نه.
* اگر درست بود، دوباره اتصال برقرار میشه.



حالت‌های Circuit Breaker

1. Closed (عادی): همه درخواست‌ها ارسال می‌شن.
2. Open (قطع): چون خطا زیاد بوده، همه درخواست‌ها بلاک می‌شن.
3. Half-Open (آزمایشی): بعضی درخواست‌ها برای تست فرستاده می‌شن، اگر موفق بودن دوباره به حالت عادی برمی‌گرده.



🐍 مثال ساده با Python

import time
import random

class CircuitBreaker:
def __init__(self, failure_threshold=3, recovery_time=5):
self.failure_threshold = failure_threshold
self.recovery_time = recovery_time
self.failure_count = 0
self.state = "CLOSED"
self.last_failure_time = None

def call(self, func, *args, **kwargs):
# اگر فیوز قطع شده باشه
if self.state == "OPEN":
if time.time() - self.last_failure_time > self.recovery_time:
self.state = "HALF_OPEN"
else:
raise Exception("Circuit is OPEN! Requests are blocked.")

try:
result = func(*args, **kwargs)
self.failure_count = 0
self.state = "CLOSED"
return result
except Exception as e:
self.failure_count += 1
self.last_failure_time = time.time()
if self.failure_count >= self.failure_threshold:
self.state = "OPEN"
raise e

# شبیه‌سازی یک سرویس خارجی که گاهی خراب میشه
def unstable_service():
if random.random() < 0.5: # 50 درصد احتمال خطا
raise Exception("Service failed!")
return "Success!"

cb = CircuitBreaker(failure_threshold=2, recovery_time=3)

for i in range(10):
try:
print(cb.call(unstable_service))
except Exception as e:
print(f"Request {i}: {e}")
time.sleep(1)


💡 مزایا:

* جلوی فشار آوردن بیش از حد به سرویس خراب رو می‌گیره.
* سیستم شما رو پایدارتر می‌کنه.
* تجربه کاربر بهتر میشه (به‌جای انتظار طولانی، سریع پیام خطا می‌گیره).
* خیلی مهمه برای سیستم‌های microservices.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


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





📜 Event Sourcing

(ذخیره‌سازی رویدادها)**


به جای ذخیره وضعیت نهایی، کل رویدادهایی که منجر به اون وضعیت شدن ذخیره می‌شن.
بعدش هر وقت بخوای وضعیت فعلی رو به‌دست بیاری، فقط کافیه رویدادها رو دوباره "پخش" (Replay) کنی.



📌 چرا مهمه؟

⬅️ همه تغییرات سیستم ثبت میشن → می‌تونی گذشته رو بازسازی کنی.
⬅️ برای سیستم‌های حساس (مثل مالی) فوق‌العاده کاربردیه.
⬅️ امکان Debug، Auditing و حتی Machine Learning روی تاریخچه واقعی وجود داره.



مثال ساده (Python)

# لیست رویدادها
events = [
("deposit", 100),
("withdraw", 20),
("deposit", 50)
]

# وضعیت رو از روی رویدادها محاسبه می‌کنیم
balance = 0
for action, amount in events:
if action == "deposit":
balance += amount
elif action == "withdraw":
balance -= amount

print("Balance:", balance) # نتیجه: 130
اینجا ما وضعیت نهایی (130) رو ذخیره نکردیم، بلکه رویدادهای مسیر رو نگه داشتیم.



📖 جاهای کاربردی

⬅️ سیستم‌های مالی و بانکی 💰 (هیچ تغییر نباید گم بشه)
⬅️ سیستم‌های حسابداری و ERP
⬅️ پلتفرم‌های Collaborative (مثل Google Docs) که تغییرات مرحله‌ای ذخیره میشن
⬅️ DDD (Domain-Driven Design) برای مدل‌سازی درست دامنه



🛠️ مزایا

⬅️ تاریخچه کامل و دقیق داری (Auditing)
⬅️ امکان Undo/Redo ساده
⬅️ مقیاس‌پذیری بهتر برای Queryها (می‌تونی Projection درست کنی)



⚠️ چالش‌ها

⬅️ ذخیره همه رویدادها می‌تونه حجم داده رو زیاد کنه
⬅️ بازسازی وضعیت ممکنه زمان‌بر باشه (برای همین معمولاً Snapshot هم ذخیره میشه)
⬅️ طراحی و پیاده‌سازی پیچیده‌تر از CRUD ساده است



👉 تشبیه ساده

Event Sourcing مثل جعبه سیاه هواپیما ✈️ هست:

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



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی



Feature Toggle (Feature Flags) 🎚️



🎯 تعریف

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

راه‌حل:
Feature Toggle → یعنی قابلیت‌ها رو پشت یک "پرچم" (flag) می‌ذاری و با تنظیمات ساده، روشن یا خاموشش می‌کنی.



چرا خوبه؟

* می‌تونی قابلیت جدید رو اول روی گروه کوچکی از کاربرا تست کنی (A/B Testing).
* در صورت وجود باگ، سریع بدون انتشار نسخه جدید غیرفعالش می‌کنی.
* کمک می‌کنه توسعه به صورت Continuous Delivery باشه.




🐍 مثال ساده در Python

# سیستم مدیریت Feature Flags
FEATURE_FLAGS = {
"new_checkout": True,
"dark_mode": False
}

def checkout(user):
if FEATURE_FLAGS["new_checkout"]:
return f"{user} is using the NEW checkout "
else:
return f"{user} is using the OLD checkout 🛒"

def ui_theme(user):
if FEATURE_FLAGS["dark_mode"]:
return f"{user} sees DARK MODE 🌙"
else:
return f"{user} sees LIGHT MODE ☀️"


# استفاده
print(checkout("Ali"))
print(ui_theme("Sara"))


💡 مزایا:

* انعطاف بالا → بدون انتشار دوباره می‌تونی فیچر رو کنترل کنی.
* کاهش ریسک → در صورت بروز مشکل، سریع خاموشش می‌کنی.
* مناسب برای A/B Testing، قابلیت‌های آزمایشی (Beta) و انتشار تدریجی.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی



بریم سراغ Idempotency 🔁



🎯 تعریف

Idempotent یعنی یک عملیات، حتی اگر چند بار پشت سر هم اجرا بشه، نتیجه‌اش تغییری نکنه.

مثال ساده:

* DELETE /user/123 اگر کاربر حذف بشه، چه یک‌بار اجرا بشه چه ۱۰ بار، نتیجه نهایی یکیه → کاربر دیگه وجود نداره.
* در مقابل POST /payments اگر بدون idempotency باشه، هر بار درخواست بزنی پول دوباره برداشت میشه 😱



کاربرد در APIهای پرداخت

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

راه‌حل: استفاده از Idempotency Key 🔑



🐍 مثال با Python (ساده‌سازی شده)

class PaymentAPI:
def __init__(self):
self.processed_requests = {} # ذخیره idempotency key

def process_payment(self, user_id, amount, key):
if key in self.processed_requests:
# درخواست تکراری → نتیجه قبلی رو برگردون
return self.processed_requests[key]

# اینجا فرض کنیم تراکنش انجام میشه
result = {
"user_id": user_id,
"amount": amount,
"status": "success"
}

# ذخیره نتیجه بر اساس کلید idempotency
self.processed_requests[key] = result
return result


# استفاده
api = PaymentAPI()

# کاربر دوبار درخواست میفرسته با همون key
print(api.process_payment(1, 100, "txn_123"))
print(api.process_payment(1, 100, "txn_123")) # دوباره پول کم نمیشه


💡 مزایا:

* جلوگیری از عملیات تکراری (مخصوصاً توی پرداخت‌ها).
* سیستم پایدارتر و امن‌تر میشه.
* تجربه کاربری بهتر (کاربر دوبار پول کم شدن یا ثبت اشتباه رو نمی‌بینه).





ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین

رگولاریزیشن (Regularization) 🔒

در مورد بیش‌برازش (Overfitting) شنیدین؟ اون مدلی که خیلی وسواسی می‌شه و به جای یادگیری الگو، نویزها و جزئیات بی‌ربط داده‌های آموزشی رو حفظ می‌کنه؟ 😫

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

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

به زبان ساده‌تر:

فرض کن مدل ما یه بچه شیطونه که دوست داره هر چیز کوچیکی رو یاد بگیره. رگولاریزیشن بهش می‌گه: "اگه زیادی شلوغ و پیچیده باشی، من بهت جریمه می‌دم!" 😈 در نتیجه، مدل ترجیح می‌ده یه مقدار ساده‌تر و منظم‌تر باشه.

رگولاریزیشن انواع مختلفی داره (مثل Lasso و Ridge)، اما همه‌شون یک هدف مشترک دارن: کنترل پیچیدگی مدل و جلوگیری از بیش‌برازش.

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

خلاصه که، رگولاریزیشن یه ترفند باحاله که به مدل می‌گه: «ساده‌تر باش تا بهتر باشی!» 😎

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی

"کد رو طوری بنویس که انگار قراره شش ماه بعد، خودت با حافظه نصفه‌نیمه‌ات بخوای اون رو بخونی."
این یعنی استفاده از نام‌گذاری واضح متغیرها و توابع، نوشتن کامنت‌های کوتاه ولی گویا، و تقسیم کد به بخش‌های ماژولار و کوچک.
خیلی وقت‌ها، مشکل برنامه‌نویس‌ها با کد دیگران نیست — با کدی هست که قبلاً خودشان نوشته‌اند و الان فراموشش کرده‌اند 😄



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین


روش‌های تجمیعی (Ensemble Methods) معمولاً از یک مدل تنها بهتر عمل می‌کنن.

🔹 ایده اصلی: به‌جای اعتماد به یک مدل، چند مدل رو با هم ترکیب کن. مثل اینه که به‌جای یک متخصص، نظر چندین نفر رو بپرسی.

روش Bagging (مثل Random Forest): چندین مدل مشابه روی بخش‌های مختلف داده آموزش می‌دی و جواب‌ها رو میانگین/رأی‌گیری می‌کنی → کاهش واریانس.

روش Boosting (مثل XGBoost, LightGBM): مدل‌ها به‌صورت زنجیره‌ای ساخته می‌شن، هر مدل خطاهای مدل قبلی رو اصلاح می‌کنه → افزایش دقت.

روش Stacking: چند مدل مختلف (مثلاً Logistic Regression + Random Forest + SVM) رو ترکیب می‌کنی و خروجی‌شون رو به یک مدل نهایی می‌دی → قدرت بیشتر.

به زبان ساده: Ensemble یعنی “چند تا مغز با هم بهتر از یک مغزه.”

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین

تعادل بین Bias و Variance خیلی مهمه.

🔹 خطای بایاس یا Bias : وقتی مدل خیلی ساده باشه و نتونه الگوهای واقعی داده رو یاد بگیره → Underfitting.
🔹 واریانس Variance : وقتی مدل خیلی پیچیده باشه و روی جزئیات و نویز داده‌ها بیش‌ازحد حساس بشه → Overfitting.

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

مدل‌های ساده (مثل Linear Regression) بایاس بالا ولی واریانس کم دارن.

مدل‌های پیچیده (مثل Random Forest عمیق یا Neural Network بزرگ) واریانس زیاد ولی بایاس کم دارن.

به زبان ساده:

یعنی Bias زیاد = مدل “کُند ذهنه” 🤔

از اون طرف Variance زیاد = مدل “خیلی وسواسیه” 😅

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین

تشخیص ناهنجاری یا Anomaly Detection برای پیدا کردن داده‌های غیرمعمول استفاده می‌شه.

🔹 کاربردها:

تشخیص تقلب در تراکنش‌های بانکی 💳

شناسایی خطا در ماشین‌آلات صنعتی ⚙️

مانیتورینگ امنیت شبکه 🛡

🔹 روش‌ها:

روش Statistical Methods: داده‌های خیلی دور از میانگین رو ناهنجاری می‌دونن.

روش Distance-Based Methods: نمونه‌هایی که از بقیه فاصله زیادی دارن Outlier هستن.

روش Isolation Forest: الگوریتم مبتنی بر درخت که نمونه‌های ناهنجار رو سریع جدا می‌کنه.

روش Autoencoders: داده‌های غیرمعمول خطای بازسازی بالایی دارن.

به زبان ساده: Anomaly Detection یعنی “یافتن کسی که در مهمونی خیلی متفاوت عمل می‌کنه” 🎉

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین


رگرسیون خطی مثل یک دستیار پیشگوئه که با نگاه کردن به داده‌های گذشته، سعی می‌کنه آینده رو پیش‌بینی کنه. 🔮 مثلاً فرض کن می‌خوای بدونی قیمت یه خونه چقدر می‌شه. رگرسیون خطی میاد و با بررسی داده‌هایی مثل متراژ خونه، تعداد اتاق‌ها و محل قرارگیری (که بهشون می‌گیم متغیرهای مستقل)، یه خط صاف 📈 روی نمودار می‌کشه. این خط بهش کمک می‌کنه که رابطه بین این عوامل و قیمت خونه (که بهش می‌گیم متغیر وابسته) رو پیدا کنه و بهترین حدس رو برای قیمت یه خونه جدید بزنه. 🏠💰

هدف اصلیش هم اینه که این خط جوری باشه که کمترین فاصله رو با تمام داده‌های موجود داشته باشه، تا پیش‌بینی‌ش دقیق‌تر باشه. در واقع، رگرسیون خطی دنبال "بهترین خط ممکن" می‌گرده. 🎯

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی

یک نکته مفید درباره یادگیری الگوهای طراحی (Design Patterns) اینه که:

🌿🌿 الگوهای طراحی مثل “زبان مشترک” بین برنامه‌نویس‌ها عمل می‌کنند؛ وقتی بلدشون باشی، هم فهمیدن کد دیگران ساده‌تر میشه، هم می‌تونی سریع‌تر و تمیزتر مسائل مشابه رو حل کنی.

مثلاً وقتی میگی «این بخش از کد از الگوی Singleton استفاده کرده»، هم‌تیمی یا هر برنامه‌نویسی که اون الگو رو می‌شناسه، فوراً می‌فهمه هدف چی بوده و ساختار چطوریه.

مزایای یادگیری الگوهای طراحی:

⬅️ کاهش دوباره‌کاری در حل مسائل معمول.
⬅️ افزایش خوانایی و نگهداری کد.
⬅️ داشتن راه‌حل‌های اثبات شده برای مشکلات رایج.



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir


🔵 نکته برنامه نویسی



## 🔄 Idempotency (ایدِم‌پوتنسی)

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



📌 چرا مهمه؟

* در سیستم‌های توزیع‌شده و APIها خیلی مهمه.
* وقتی درخواست دوباره ارسال بشه (به‌دلیل قطعی اینترنت، timeout یا retry)، سیستم نباید چندبار یک کار رو انجام بده.
* از تکرار عملیات حساس (مثل دوبار پول برداشت کردن از حساب 😱) جلوگیری می‌کنه.



مثال ساده

فرض کن یک API برای "ایجاد کاربر" داریم:

بدون idempotency:

def create_user(username):
db.append(username)
return "User created"
اگر درخواست دوباره فرستاده بشه، کاربر چندبار ایجاد میشه.

✔️ با idempotency:

def create_user(username):
if username in db:
return "User already exists"
db.append(username)
return "User created"
اینجا هرچند بار هم درخواست ارسال بشه، نتیجه یکیه.



مثال API پرداخت

* کاربر روی "پرداخت" کلیک می‌کنه.
* اینترنتش ضعیفه → درخواست دوبار فرستاده میشه.
* اگر API idempotent نباشه → دو بار پول کم میشه.
* ✔️ اگر idempotent باشه → فقط یک تراکنش ساخته میشه، درخواست دوم همون تراکنش قبلی رو برمی‌گردونه.



📖 جاهای خیلی کاربردی:

* پرداخت آنلاین 💳
* APIهای REST و GraphQL
* سیستم‌های توزیع‌شده (که retry طبیعی هست)
* پیام‌رسان‌ها (ارسال یک پیام نباید چندبار تکرار بشه)



🛠️ روش‌های پیاده‌سازی

* کلید Idempotency → برای هر درخواست یک شناسه یکتا ارسال بشه:


  POST /payment
Idempotency-Key: abc123

سرور اگر همون کلید رو دوباره ببینه، نتیجه قبلی رو برمی‌گردونه.
* Check قبل از Insert (مثل مثال create user).
* UPSERT (Update یا Insert).
* حذف عملیات‌های تکراری در صف پردازش.



⚠️ نکته مهم

ایدِم‌پوتنسی به این معنی نیست که عملیات تغییر نمی‌کنه،
بلکه یعنی نتیجه نهایی تکرارها یکیه.

مثلاً:

* DELETE /user/1 → هرچند بار بزنی، کاربر حذف میشه (و نتیجه یکیه).
* GET /user/1 → ذاتاً idempotent هست.
* POST /user → باید idempotent بشه (با کلید یا شرط).



👉 تشبیه ساده:
ایدِم‌پوتنسی مثل کلید چراغ برقه 💡
هر چند بار هم فشارش بدی → چراغ یا روشن میشه یا خاموش.
نه اینکه هر بار یه لامپ جدید اضافه بشه 😅



ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir
🔵 نکته یادگیری ماشین


تقسیم داده‌ها (Data Splitting) ✂️

بزرگترین اشتباهی که یه تازه‌کار می‌تونه انجام بده اینه که مدلش رو با همون داده‌هایی که آموزش داده، تست کنه. 🤦‍♂️ این مثل این می‌مونه که یه دانش‌آموز برای امتحان، سوال و جواب‌ها رو از قبل حفظ کنه و سر جلسه امتحان هم دقیقاً همون سوال‌ها رو جواب بده. خب معلومه که نمره‌اش ۲۰ می‌شه، ولی آیا واقعاً مطلب رو یاد گرفته؟ نه!

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

مجموعه آموزشی (Training Set): 📚
این بخش اصلی داده‌هاست (معمولاً ۷۰٪ تا ۸۰٪) که مدل از روی اون یاد می‌گیره. مثل جزوه‌ها و کتاب‌هایی که یه دانش‌آموز برای درس خوندن استفاده می‌کنه. مدل هزاران بار این داده‌ها رو می‌بینه تا الگوها رو پیدا کنه.

مجموعه اعتبارسنجی (Validation Set): 📝
این بخش برای تنظیم کردن مدل و هایپرپارامترها استفاده می‌شه. مثل امتحان‌های آزمایشی که دانش‌آموز قبل از امتحان اصلی می‌ده تا ببینه چقدر آماده‌ست و کجا باید بیشتر تلاش کنه. این مجموعه به ما کمک می‌کنه جلوی بیش‌برازش (Overfitting) رو بگیریم.

مجموعه آزمون (Test Set): 💯
این بخش رو برای کل فرآیند آموزش و تنظیم مدل "کاملاً مخفی" نگه می‌داریم. فقط و فقط یک بار، در آخر کار، از این مجموعه استفاده می‌کنیم تا عملکرد نهایی و واقعی مدل رو روی داده‌های کاملاً جدید و ندیده بسنجیم. مثل امتحان نهایی و اصلی که نمره واقعی دانش‌آموز رو مشخص می‌کنه.

خلاصه که، داده‌های آزمون رو مثل یه راز مخفی برای مدل نگه دار تا وقتی که می‌خوای ببینی واقعاً چقدر یاد گرفته! 😉

ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــ


لطفا ما رو به دیگران هم معرفی کنید...

آدرس کانال اصلی :
https://t.me/Tu_24

آدرس وبسایت:
https://Tutorial24.ir