دوستان توی کامنت ها اشاره کردن که این روش درستی نیست و خب حق با ایشان است. اینکار میتونه خطرات خیلی زیادی هم به همراه داشته باشه.
اگر خواستید نوع فایل رو چک کنید راه های به نسبت امن تر و بهینه تر زیادی هست.
مثلا شما میتونید خودتون Head فایل رو چک کنید یا از libmagic و لایبری پایتون python-magic استفاده کنید که استفاده ازش هم خیلی راحته.

مثال:

>>> import magic
>>> magic.from_file("testdata/test.pdf")
'PDF document, version 1.2'
# recommend using at least the first 2048 bytes, as less can produce incorrect identification
>>> magic.from_buffer(open("testdata/test.pdf", "rb").read(2048))
'PDF document, version 1.2'
>>> magic.from_file("testdata/test.pdf", mime=True)
'application/pdf'

لینک pypi

#نکتک@PhiloLearn

لازم نیست ساعت‌ها گوگل کنی برای پیدا کردن APIهای رایگان!

یه ریپازیتوری که هر دولوپری باید تو بوکمارک‌هاش داشته باشه:
https://github.com/public-apis/public-apis

لیست کاملاً مرتب‌شده و به‌روز از صدها API عمومی و رایگان در همه حوزه‌ها: Weather - Finance - Music - Animals - Jokes - Crypto Maps و صدها مورد دیگه.

@DevTwitter | <POURYA/>

اولین واکنش دولوپرا به لینوکس 😂💙

#fun@PhiloLearn

چطور وایب کدر ها رو گول بزنیم تا برنامه نویسی واقعی یاد بگیرن:


🔥 @Programming_Hobby 🔥

۱۲. از سیگنال‌های Django استفاده کنم یا مستقیم متد را صدا بزنم؟

جواب کوتاه:
۹۰٪ مواقع مستقیم متد رو صدا بزن. سیگنال فقط وقتی لازم شد.


✔️ کی از سیگنال استفاده کنیم؟

فقط وقتی:
- می‌خوای اپ‌ها از هم جدا باشن (app A نباید app B رو import کنه)
- با مدل‌های داخلی Django کار داری (مثل User، Group)
- می‌خوای اپ‌های سوم‌شخص بتونن به eventهای تو واکنش نشون بدن


❌ کی از سیگنال استفاده نکنیم؟

وقتی:
- کدها در یک اپ هستن
- می‌خوای جریان کد واضح و قابل‌ردگیری باشه
- دیباگ کردن مهمه

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

مثال:

❌ مثال بد – سیگنال بی‌دلیل

from django.db.models.signals import post_save
from django.dispatch import receiver

class Order(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    total = models.DecimalField(max_digits=10, decimal_places=2)

@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.user.email, 'Order confirmed')

مشکل:
اصلاً معلوم نیست ایمیل کجا ارسال می‌شه! پاکِ پنهانی.


✅ مثال خوب – مستقیم و واضح

class Order(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    total = models.DecimalField(max_digits=10, decimal_places=2)
    
    def send_confirmation_email(self):
        send_email(self.user.email, 'Order confirmed')

# In view
order = Order.objects.create(user=user, total=100)
order.send_confirmation_email()

واضح، قابل‌فهم، ساده برای دیباگ.


✅ مثال خوب – وقتی سیگنال واقعاً لازم است (برای decoupling)

در اپ analytics که نباید از اپ orders ایمپورت مستقیم داشته باشه:

from django.dispatch import receiver
from orders.signals import order_created  # Custom signal

@receiver(order_created)
def track_order_analytics(sender, order, **kwargs):
    AnalyticsEvent.objects.create(
        event_type='order_created',
        order_id=order.id
    )

این‌جا سیگنال کاملاً منطقیه.


قانون من:

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


پ.ن: یادتون نره پستا رو با دوستاتون به اشتراک بذارید ❤️❤️

پارت اول ۲۰ سوال جنگو
پارت دوم ۲۰ سوال جنگو
پارت سوم ۲۰ سوال جنگو
پارت چهارم ۲۰ سوال جنگو
پارت پنجم ۲۰ سوال جنگو
پارت ششم ۲۰ سوال جنگو
پارت هفتم ۲۰ سوال جنگو
پارت هشتم ۲۰ سوال جنگو
پارت نهم ۲۰ سوال جنگو
پارت دهم ۲۰ سوال جنگو
پارت یازدهم ۲۰ سوال جنگو

#پارت_دوازدهم #جنگو #django #پایتون #برنامه_نویسی

@PhiloLearn

رقیبمون با یه محصول "زشت" بازار رو گرفت؛ در حالی که ما درگیر خوشگل کردن دکمه‌ها بودیم!

چند سال پیش توی پروژه‌ای بودم که مدیرش عاشق کلمه پرفکت بود. هر دوشنبه جلسه میذاشتیم. روی وایت‌برد ایده‌های شاهکار مینوشتیم. "این دکمه انیمیشن داشته باشه."، "اون گزارش باید خروجی اکسل و PDF همزمان بده."، "UI باید در حد اپل باشه."

ما داشتیم برای ایده‌آل میجنگیدیم. احساس میکردیم قراره تاریخ‌سازی میکنیم.

نتیجه؟ یه فاجعه‌ی تمام‌عیار.

۶ ماه گذشت و ما هنوز داشتیم دکمه‌ها رو پولیش میکردیم. یه روز صبح بیدار شدیم و دیدیم رقیبمون با یه محصول "نصفه و نیمه"، "زشت" و "باگ‌دار" اومد بالا.

ما خندیدیم: "این چیه؟ آبروریزیه!" ولی بازار نخندید. بازار خرید.

چرا؟ چون وقتی ما داشتیم توی آزمایشگاه روی "کمال‌گرایی" کار میکردیم، اونا داشتن توی "بازار" فیدبک میگرفتن. اونا باگ‌هاشون رو با مشتری حل کردن، ما باگ‌هامون رو با تخیلاتمون.

به این پدیده میگن: Feature Creep (خزش ویژگی). این قاتلیه که با لباس شیک کیفیت میاد تو شرکتت و استارتاپت رو خفه میکنه.

رید هافمن (بنیان‌گذار لینکدین) یه جمله‌ داره که میگه: "اگر از اولین نسخه محصولتان شرمنده نیستید، یعنی خیلی دیر لانچ کرده‌اید."

محصول کامل، محصولیه که مرده. محصول زنده، ناقصه ولی داره کار میکنه.

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

@DevTwitter | <Hossein Moradi/>

دوستان
میشه بگید که بالایی به نظرتون بهتره یا پایینی

غزل 102

دوش آگهی ز یارِ سفر کرده داد باد
من نیز دل به باد دهم، هر چه باد باد
کارم بدان رسید که همرازِ خود کنم
هر شام برق لامِع و هر بامداد باد
در چینِ طرهٔ تو دل بی حِفاظِ من
هرگز نگفت مسکنِ مألوف یاد باد
امروز قدرِ پندِ عزیزان شناختم
یا رب روانِ ناصحِ ما از تو شاد باد
خون شد دلم به یادِ تو هر گَه که در چمن
بندِ قبایِ غنچهٔ گل می‌گشاد باد
از دست رفته بود وجودِ ضعیفِ من
صبحم به بویِ وصلِ تو جان باز داد، باد
حافظ نهادِ نیکِ تو کامت بر آورد
جان‌ها فدایِ مردمِ نیکو نهاد باد

غزل 102
دوش آگهی ز یارِ سفر کرده داد باد
من نیز دل به باد دهم، هر چه باد باد
کارم بدان رسید که همرازِ خود کنم
هر شام برق لامِع و هر بامداد باد
در چینِ طرهٔ تو دل بی حِفاظِ من
هرگز نگفت مسکنِ مألوف یاد باد
امروز قدرِ پندِ عزیزان شناختم
یا رب روانِ ناصحِ ما از تو شاد باد
خون شد دلم به یادِ تو هر گَه که در چمن
بندِ قبایِ غنچهٔ گل می‌گشاد باد
از دست رفته بود وجودِ ضعیفِ من
صبحم به بویِ وصلِ تو جان باز داد، باد
حافظ نهادِ نیکِ تو کامت بر آورد
جان‌ها فدایِ مردمِ نیکو نهاد باد

🍉🍉 @this_hafez_bot 🍉🍉

ربات فال حافظ رو یادتونه؟

https://news.1rj.ru/str/this_hafez_bot

آپدیتش کردم ❤️❤️ (طبق معمولا از AI برای نوشتن کامنت ها و ReadMe استفاده کردم)

https://github.com/Hr-ArshA/this_hafez_bot

پ.ن: یه سری آپشن ریز دیگه هم قراره بهش اضافه کنم. امیدوارم قبل از یلدا برسونمشون 😁.

گروهی داشتیم... انجمن ونداد
و البته داریم اما پرایوت شده
(اون قبلیه هم که عمومی بود تعطیله مدتیه)

دوستانی که تمایل دارن عضو بشن می‌تونن پیوی لینکش رو دریافت کنن یا این زیر کامنت کنن
@Pink0rca

جمع خوبیه، تلاش بر اینه که دوستانه و فنی باشه...
#موقت

خب اون آپشنی که میخواستم اضافه کنم هم اضافه شد.
کافیه آیدی کانال رو بنویسید و اسم اونی که میخواید براش فال بگیرید رو در ادامش و کمی صبر کنید و روی گزینه ای که بهتون نشون میده کلیک کنید. اینطوری:

@this_hafez_bot arsha

و بعد فال رو میفرسته توی چت مورد نظر 😂.
نتیجه مثل پست پایینی میشه

❤️❤️ فال برای @sohrabcontents ❤️❤️

- غزل ۱۲۱

هر آن کو خاطرِ مجموع و یارِ نازنین دارد

سعادت همدم او گشت و دولتْ همنشین دارد

حریمِ عشق را درگَه، بسی بالاتر از عقل است

کسی آن آستان بوسد، که جان در آستین دارد

دهانِ تَنگِ شیرینش، مگر مُلکِ سلیمان است

که نقشِ خاتمِ لعلش، جهان زیرِ نگین دارد

لبِ لعل و خطِ مشکین، چو آنش هست و اینش هست

بنازم دلبرِ خود را، که حُسنش آن و این دارد

به خواری منگر ای مُنعِم، ضعیفان و نحیفان را

که صدرِ مجلسِ عشرت، گدای رهنشین دارد

چو بر رویِ زمین باشی، توانایی غنیمت دان

که دورانْ ناتوانی‌ها، بسی زیرِ زمین دارد

بلاگردانِ جان و تن، دعایِ مستمندان است

که بیند خیر از آن خرمن که ننگ از خوشه چین دارد؟

صبا از عشقِ من رمزی، بگو با آن شهِ خوبان

که صد جمشید و کیخسرو، غلامِ کمترین دارد

و گر گوید نمی‌خواهم، چو حافظ عاشقِ مفلس

بگوییدش که سلطانی، گدایی همنشین دارد

🍉🍉 @this_hafez_bot 🍉🍉

ما به چین و روسیه و ایران می‌خندیم که حکومت توتالیتر داره 😂🤦🏻‍♂ این چه دلقک بازی ایه آخه؟

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

https://notegpt.io/youtube-video-summarizer

این سایت به شکل رایگان متن ویدیو و خلاصش رو بهتون میده
باقی آپشن هاشن رو فکر کنم باید خرید و همین دوتایی که گفتم هم فکر کنم محدودیت داشته باشه، خودم هیچ وقت بیشتر از ۳-۴ بار در روز نشده ازش استفاده کنم

@PhiloLearn

#telemetrio2025

یه نگاهی به آمار سال گذشته فیلولرن بندازیم...

۱۳. چطور باید چند-مستاجری (Multi-Tenancy) را در Django مدیریت کنم؟

جواب کوتاه:
به همه‌ی مدل‌ها یک فیلد tenant اضافه کن و همیشه موقع query گرفتن، بر اساس tenant فیلتر کن.

این ساده‌ترین و رایج‌ترین روشه.


رویکرد ۱:
Shared Schema + tenant_id (ساده‌ترین و برای ۹۰٪ پروژه‌ها کافی)

‌‌‏هر مدل یک tenant دارد:

class Tenant(models.Model):
    name = models.CharField(max_length=100)
    domain = models.CharField(max_length=100, unique=True)

class Post(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
    noscript = models.CharField(max_length=200)
    content = models.TextField()

‏Middleware برای پیدا کردن tenant از روی دامنه:

class TenantMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
    
    def __call__(self, request):
        domain = request.get_host()
        request.tenant = Tenant.objects.get(domain=domain)
        return self.get_response(request)

ویوها به‌صورت خودکار tenant را فیلتر می‌کنند:

def post_list(request):
    posts = Post.objects.filter(tenant=request.tenant)
    return render(request, 'posts.html', {'posts': posts})

مزایا:

- ساده
- بدون نیاز به ساختار پیچیده
- مناسب SaaS ساده، MVP، پنل‌های سازمانی

معایب:

- همه tenant ها در یک دیتابیس
- اگر یک tenant دیتابیس را overload کند، روی بقیه هم اثر دارد



رویکرد ۲:
یک دیتابیس/Schema جدا برای هر tenant (پیچیده‌تر ولی isolation کامل)

برای پروژه‌های خیلی بزرگ یا با سطح امنیتی بالا.

INSTALLED_APPS += ['django_tenants']

DATABASE_ROUTERS = ['django_tenants.routers.TenantSyncRouter']

class Tenant(TenantMixin):
    name = models.CharField(max_length=100)
    domain_url = models.CharField(max_length=128, unique=True)

‏Django Tenants به‌صورت خودکار درخواست‌ها را به schema درست می‌فرستد:

posts = Post.objects.all()  # فقط داده‌های tenant فعلی

مزایا:

- جدا شدن کامل داده‌ها
- هر tenant می‌تونه نسخه مخصوص خودش داشته باشه

معایب:

‏- Migrationها پیچیده‌تر می‌شن
- نگه‌داری سخت‌تر
- راه‌اندازی و DevOps سنگین


قانون من:
اگر دلیل امنیتی یا قانونی خیلی جدی نداری، از رویکرد ۱ (shared schema) استفاده کن.
۹۰٪ مواقع کاملاً کفایت می‌کنه.


پ.ن: یادتون نره پستا رو با دوستاتون به اشتراک بذارید ❤️❤️

پارت اول ۲۰ سوال جنگو
پارت دوم ۲۰ سوال جنگو
پارت سوم ۲۰ سوال جنگو
پارت چهارم ۲۰ سوال جنگو
پارت پنجم ۲۰ سوال جنگو
پارت ششم ۲۰ سوال جنگو
پارت هفتم ۲۰ سوال جنگو
پارت هشتم ۲۰ سوال جنگو
پارت نهم ۲۰ سوال جنگو
پارت دهم ۲۰ سوال جنگو
پارت یازدهم ۲۰ سوال جنگو
پارت دوازدهم ۲۰ سوال جنگو

#پارت_سیزدهم #جنگو #django #پایتون #برنامه_نویسی

@PhiloLearn

‌‏ ‌‏معماری Multi-tenant در سیستم‌های نرم‌افزاری

‏Multi-tenancy یه الگوی معماری نرم‌افزاریه که توش یک نمونه از اپلیکیشن می‌تونه همزمان چندین مشتری (tenant) رو سرویس‌دهی کنه. هر tenant یه گروه از کاربراست که دسترسی‌ها و امتیازات مشترکی دارن و از نظر منطقی از بقیه tenant‌ ها جدا شدن. این مدل بیشتر در SaaS (Software as a Service) کاربرد داره و با مفهوم single-tenancy که توش هر مشتری نمونه جداگانه‌ای از سرویس داره، تفاوت اساسی داره.


سطوح جداسازی داده

توی پیاده‌سازی multi-tenant سه رویکرد اصلی برای جداسازی داده وجود داره:

‏Shared Database, Shared Schema: همه tenant‌ ها از یک دیتابیس و یک schema استفاده می‌کنن. جداسازی از طریق یک فیلد TenantID توی هر جدول انجام می‌شه. این روش بیشترین کارایی رو از نظر مصرف منابع داره اما پیچیدگی کوئری‌ها رو افزایش میده و ریسک data leakage بالاتره. باید توی هر کوئری فیلتر TenantID اعمال بشه که معمولاً از طریق Row-level Security (RLS) یا ORM interceptors پیاده می‌شه.

‏Shared Database, Separate Schema: هر tenant یک schema اختصاصی توی یک دیتابیس مشترک داره. این روش تعادل خوبی بین ایزوله‌سازی و کارایی ایجاد می‌کنه. مدیریت مایگریشن ها پیچیده‌تر می‌شه چون باید برای هر schema به صورت جداگانه اجرا بشن. PostgreSQL و SQL Server این مدل رو خوب ساپورت می‌کنن.

‏Separate Database: هر tenant دیتابیس مجزایی داره که بالاترین سطح ایزوله‌سازی و امنیت رو فراهم می‌کنه. این روش امکان کاستومایز کردن schema برای هر tenant و backup/restore مستقل رو میده، اما فضای مدیریتی بیشتری داره. برای tenant‌های اینترپرایس با نیازهای compliance خاص مناسبه.


چالش‌های معماری

یکی از مهم‌ترین چالش‌ها تضمین tenant isolation هستش. اگه باگ یا اشتباهی توی کانفیگ وجود داشته باشه، ممکنه داده یک tenant برای tenant دیگه قابل دسترسی بشه. برای جلوگیری از این مشکل باید Defense in Depth پیاده بشه: validation در application layer، database-level constraints، و مانیتورینگ مداوم برای شناسایی access pattern‌ های غیرعادی.

مدیریت schema evolution توی محیط multi-tenant پیچیده‌تره. وقتی یه مایگریشن اجرا می‌شه، باید روی همه tenant‌ ها بدون downtime قابل توجه اعمال بشه. راهکارهایی مثل Blue-Green Deployment یا استفاده از backward-compatible changes (مثل adding nullable columns) کمک می‌کنن. برای سیستم‌های بزرگ، Online Schema Change tools مثل gh-ost برای MySQL یا pg_repack برای PostgreSQL استفاده می‌شه.

‏Performance isolation یه چالش دیگه‌ است. اگه یک tenant کوئری‌های سنگین اجرا کنه یا ترافیک زیاد آنی داشته باشه، نباید روی بقیه tenant‌ ها تاثیر بذاره. این مساله رو می‌شه با rate limiting، resource quotas، و connection pooling مدیریت کرد. توی database level می‌شه از query timeout‌ ها و resource governor (در SQL Server) استفاده کرد.


کانفیگ و کاستومایز

‌‏هر tenant معمولاً نیاز به کانفیگ اختصاصی داره: branding، feature flags، business rules، و integration settings. این کانفیگ باید به صورت بهینه ذخیره و کش بشه. یه الگوی معمول استفاده از یک tenant_configs جدول یا key-value store مثل Redis هستش که کانفیگ هر tenant رو نگه میداره.

‏برای tenant‌ های اینترپرایس که نیاز به کاستومایز عمیق‌تر دارن، می‌شه از Extension Points استفاده کرد: وب هوک هایی که tenant می‌تونه کانفیگ کنه، کاستوم فیلد‌ ها، یا حتی plugin system که اجازه اضافه کردن business logic اختصاصی رو میده. این قابلیت‌ها باید با احتیاط طراحی بشن تا امنیت و استیبیلیتی سیستم رو به خطر نندازن.

‏توی سیستم‌های بزرگ، گاهی از Tenant Tiering استفاده می‌شه: tenant‌ های پرمیوم روی infrastructure مجزا یا با resource allocation بیشتری اجرا می‌شن. این کار هم پرفورمنس بهتری براشون فراهم می‌کنه و هم tenant‌ های کوچیک‌تر رو از تاثیر workload‌ های سنگین محافظت می‌کنه.

پ.ن: یادتون نره پستا رو با دوستاتون به اشتراک بذارید ❤️❤️


#SystemArchitecture #معماری_نرم‌افزار #طراحی_سیستم


@PhiloLearn