یه صفر اضافه نزدن؟😐

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

بعد دیدن نه، ملت خر نمیشن
قیمتو اوردن پایین

بعد دیگه دیدن اوضاع جمع نمیشه،
نتو دارن کیلوبایت به کیلوبایت باز میکنن

اینترنت پرو هم دونه دونه اپراتور ها دارن جمعش میکنن 😂

😐 هوش مصنوعی Claude Opus 4.8 یک کلون از ماینکرفت ساخت

با یک کامنت، با استفاده از Three JS، یک کلون خیلی خوب از ماینکرفت ساخت.

https://t.me/perplexity/988

دیگه واقعا ترسیدم

@CodingLovers_OFF

چقدر ناامید داریم
خیالتون راحت هوش مصنوعیا شاید اینارو بتونن بسازن
ولی نمیتونن دیباگ کنن یا فیچر اضافی بدون باگ بزنن😔😂😂

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

خود مایکروسافت هم یه سیستم لینوکس منتشر کرده
حالا شما هی برو ویندوز بریز

Azure Linux 4.0

اپدیت خوشگل تلگرام
نظرتون چیه با مدل مارکاپ جدید؟

🚫 اشتباه بزرگی که همه در FastAPI انجام میدن: ترکیب اشتباه SQLAlchemy و Depends!

یک اشتباه رایج در پروژه‌های FastAPI، نحوه ترکیب کردن SQLAlchemy Session با Depends هست. اگه بفهمم اولین بار کی ترندش کرده ....

۱. پشت صحنه SQLAlchemy
در SQLAlchemy، هر Session در واقع کنترل‌کننده تراکنش‌های (Transactions) دیتابیس شماست. وقتی یک Session باز میشه، دیتابیس آماده اجرای دستورات شما در قالب یک تراکنش هست:

BEGIN;
-- دستورات
COMMIT;

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

۲. فاجعه زمانی رخ میده که با Depends ترکیب میشه!
وقتی شما Session دیتابیس را مستقیماً در ورودی Route با Depends تزریق میکنین، عمر این Session به عمر کل Request گره میخوره! یعنی چی؟

فرض کنید کاربر یک درخواست میفرسته. FastAPI یک تراکنش باز می‌کند. حالا سیستم شما میره سراغ کارهای دیگه؛ مثلاً:

- ارسال ایمیل به کاربر (۳ ثانیه زمان)
- صدا زدن یک API خارجی (۵ ثانیه زمان)
- پردازش‌های سنگین پایتونی

در تمام این مدت، اون تراکنش دیتابیس باز و معلق مونده! در نتیجه، کانکشن‌پول (Connection Pool) شما در کسری از ثانیه خالی میشه و دیتابیس خطای Too Many Connections میده؛ پروژه عملاً میخوابه، فقط چون دیتابیس منتظر مونده تا کارهای غیر دیتابیسی شما تمام بشه!

🛠 راه‌حل؟
به جای اینکه دیتابیس را به کل Request زنجیر کنین، از Context Manager استفاده کنین تا Session دقیقاً همون ثانیه‌ای که کارش با دیتابیس تمام شد، بسته شه:

# ❌ اشتباه
@app.get("/users")
def get_users(db: Session = Depends(get_db)):
    users = db.query(User).all()
    expensive_operation()
    return users

# ✅ درست
@app.get("/users")
def get_users():
    with db_context() as db:
        users = db.query(User).all()
    
    expensive_operation()
    return users

@CodingLovers_OFF 🔥

ربات یکی از کاربراس
دانلودره اگه بدردتون میخوره

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

🎨 از فرانت‌اند یاد میگیری که گاهی زیباترین ظاهر ها، پشتش آشفته ترین کدهاست.

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

💎 از زبان سطح پایین یاد میگیری که نانوثانیه ها و بیت ها حرمت دارن.

🗑️ از دیتاساینس یاد میگیری که داده‌ها بدون تحلیل، آشغالی بیش نیستن.

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

✨ از دیزاین یاد میگیری که چطور پیکسل ها زیبایی میبخشن.

💥 از باگ ها یاد میگیری که هرچقدر هم خفن باشی، تهش یه سمی‌کالن ; میتونه نابودت کنه.

شما ادامه بدید ...

امروز سعی داشتم ی سیستم واسه دیلیت کردن مسیج‌ها با ی دیلی مشخص پیاده سازی کنم. چیزی که توی وهله اول به فکرم رسید، استفاده ترکیبی از asyncio.sleep و asyncio.create_task بود، ولی خب خیلی مشکل داشت، واسه همین با چندتا سرچ به ماژول heapq رسیدم.


پایتون ماژولی تحت عنوان heapq داره که ساختمان داده‌ی Min-Heap رو پیاده سازی می‌کنه. به زبون ساده، داخل ی آرایه‌ی Min-Heap، سیستم این تضمین رو میده که کوچیک‌ترین عنصر ( توی معماری مد نظر من، نزدیک‌ترین تایم برای حذف کردن پیام ‌)  همیشه داخل ایندکس صفر وجود داره.

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

استفاده عملی از این ماژول رو می‌تونید توی آخرین کامیت این ریپو ببینید 👀؛

📦 github.com/Melfex/telegram-msg-bridge/blob/main/util/scheduler.py


⌨• #DevEdu@Melfex | #Python