ما یک git flow داریم، که شاید اسمشو نشنیده باشین ولی حتما احتمال زیاد همینو رعایت میکنید. تو عکس توضیح داده. تو پروژه واقعی main میشه پروداکشن، و جای release branches میشه staging و develop هم که میشه نسخه dev که معمولا خیلی استیبل نیست.
معمولا وقتی هاتفیکس انجام میدین رو پروداکشن، رو برنچ staging و dev باید rebase کنید.

حالا سوال دارم ازتون، فکر کنید هات فیکس انجام دادید، ولی‌بخاطر اون هاتفیکس برنچ develop کانفلیکت خورد موقع ریبیس که حل کردین. ولی شما ۱۰۰ تا برنچ فیچر دیگه دارین از develop، که حالا همشون دقیقا همون کانفلیکت رو خوردن. بنظرتون راهکارش چیه؟

@PyBackendHub

این ماه در کانال متمرکز رو فرانت اند و وب خواهم بود. ابتدا تو یک پلی لیست پروژه محور رو DOM و جزییاتش کار خواهم کرد که پایه و اساس پلی لیست بعدیمون یعنی ساخت یک فریمورک جاوا اسکریپت شبیه React خواهد بود. در پلی لیست DOM سعی می‌کنم یک برد کانبان شبیه ترلو رو بدون استفاده از فریمورک خاصی یا به عبارتی VanillaJS پیاده کنم بعد همون رو از طریق Web Component بازنویسی خواهم کرد تا با ShadowDOM هم آشنا بشیم.
چون فریمورک وب‌مون نهایتا قراره رو DOM کار کنه درکش بسیار مهمه. پس از این پلی لیست یک چیزی شبیه React یا Vue خواهیم نوشت که هم درک عمیق تری از جاوا اسکریپت و فریمورک‌ها و ابزارها داشته باشیم و هم اینکه در مصاحبه‌های فنی اعتماد به نفس بیشتری داشته باشیم.

در این پلی لیست‌ها از تایپ اسکریپت به عنوان زبان اصلی استفاده خواهم کرد که رو اون هم مسلط ‌تر بشیم.
پیشاپیش چشم انتظار فیدبک و نقدهاتون هستم :)

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

✅ آپدیت جدید دوره فروشگاه اینترنتی با جنگو منتشر شد.

چند قسمت از این دوره رو اینجا ببینید:
https://t.me/djangolearn_ir/531
https://t.me/djangolearn_ir/533
https://t.me/djangolearn_ir/573
https://t.me/djangolearn_ir/676
https://t.me/djangolearn_ir/724

لینک دوره در دانشجویار:
https://www.daneshjooyar.com/project-django/

✅ خطای هزینه هدر رفته (Sunk Cost Fallacy) یا اثر کنکورد

حتماً برای شما هم پیش آمده که به دیدن فیلم یا مسابقه‌ای رفته باشید و با شروع آن احساس کنید فیلم یا مسابقه خوبی انتخاب نکرده اید؟ در اینجا دو راه دارید یا محل را ترک کنید و یا تا آخر برنامه بنشینید. جالب است بدانید اکثر افراد راه دوم را انتخاب می‌کنند. به این رفتار، سوگیری هزینه هدر رفته (Sunk Cost Fallacy) می‌گویند. در واقع افراد تمایل دارند تصمیمات خود را به سمتی سوق دهند که انتخاب های قبلی آنها را تایید یا توجیه نماید. افراد به چیزی که برای آن زمان، پول، انرژی و یا احساس هزینه کرده باشند می‌چسبند و حتی با درک این موضوع که انتخاب آنها اشتباه بوده، دست از آن نمی‌کشند. در واقع زمانی‎که به دیدن ادامه آن برنامه اختصاص داده شد می توانست صرف فعالیتی که برای ما خوشایند تر است شود. این سوگیری باعث هدر رفتن بیشتر منابع ارزشمندی مانند زمان و پول می شود. چه بسیار پروژه هایی که در سازمان‌ها تعریف می‌شود و با گذشتن زمان تیم به این نتیجه می‌رسد که پروژه مناسب نبوده است اما مدیر بخاطر زمان، هزینه و انرژی که صرف آن شده است اصرار به ادامه کار و در نتیجه اتلاف بیشتر منابع دارد. این یک مدل تفکر و تصمیم گیری غیر منطقی می باشد. نباید اجازه داد هزینه‌های گذشته روی تصمیمات منطقی بعدی اثر بگذارد. به این هزینه‌ها، هزینه‌های هدر رفته یا بازگشت ناپذیر می‌گویند، زیرا مانند آبی که بر زمین ریخته نمی‌توان حاصلی برای آن در نظر گرفت.

➖حالا باز بگو با این همه دوره رایگان آخه کسی پول میده دوره بخره.
➖قبلا هم گفتم بازم میگم: دوره رایگان فقط دانلود میشه (دیده نمیشه) و وقتی هارد برای فیلم و سریال جدید جا نداره. دوره رو حذف می کنیم.
➖من با تجربه به این واقعیت رسیدم. نمی دونستم بهش میگن اثر کنکورد
✔️لذا آپدیت جدید دوره فروشگاه اینترنتی با جنگو منتشر شد. لینک دوره غیر رایگان فروشگاه اینترنتی با جنگو

هشتگ خودزنی

بدبختی های ساخت اسرائیل و دیگران 😔

✅انواع ارتباطات در ایجاد پایگاه داده
از لینکدین علی بیگدلی

برای اینکه یه جمع بندی داشته باشیم از relation های توی database سعی کردم یه قاب کلی از معمول ترین ها رو دور هم جمع کنم تا یه آشنایی اولیه باهاشون داشته باشید.
اما بزرگترین نقش و معمولا ضعف توی طراحی پایگاه داده ارتباطات هستش که در بیشتر مواقع به خاطر دانش کم ممکن هستش که نتونیم در هر جا مدل مناسب برای استفاده رو انتخاب کنیم و همین موضوع باعث سخت شدن طراحی و پیاده سازی سرویس ها میشه.
اما اگر یک ایده کلی از برخی از اون ها رو پیدا کنیم تصمیم گیری راحت تر میشه، برای شروع یک دسته از رایج ترین ارتباطات رو که توی مدل های مختلف با سناریو های متفاوت اتفاق میافته رو جمع کردم تا یه دید اولیه پیدا کنیم و بعد به مرور ساختارشون رو توی جنگو بررسی خواهیم کرد و اینکه چطور میشه این داده ها رو باستفاده از ORM در جنگو واکشی کرد.

مواردی که بررسی خواهیم کرد شامل:
- One-To-One
- Many-To-One
- One-To-Many
- Many-To-Many
- Self-referential Relationships
- Recursive Foreign Keys
- Through Relationships
- Generic Relationships

✅استفاده از replication در جنگو
از لینکدین Erfan Ali aghdam

تو این پست با master-slave replication آشنا میشیم
همچنین برای دسترسی به دستور العمل پیاده سازی replication با جنگو میتونین به لینک زیر از گیتهابم مراجعه کنین.
لینک:
https://github.com/erfanAliaghdam/master-slave-replication-in-django

✅مصاحبه علی بیگدلی با من در مورد فروشگاه اینترنتی با جنگو

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

لینک آپارت:
https://www.aparat.com/v/kuocju0

لینک یوتیوب:
در حال آپلود

لینک مکتب خونه

✅مصاحبه فنی امیربهادر با من برای پوزیشن برنامه نویس پایتون

با شروع دیده نشده از خودم😎

توی این ویدئو که لقب بدترین مصاحبه خاورمیانه رو کسب کرد، امیر بهادر در نقش مصاحبه کننده با من مصاحبه کرد.

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

امیربهادر توی این ویدئو سوالات متفاوتی رو مطرح کرد و یک مساله عنکبوت و غذاش رو هم مطرح کرد و میخواست که اثبات کنم سریع ترین مسیر رسیدن عنکبونت به غذاش کدوم هست.
بعد از مصاحبه هم شروع به بررسی و تحلیل کرد و به من ثابت کرد که چطور من صد در صد توی این مصاحبه رد میشم.
امیدوارم از این مصاحبه چیزی یاد بگیرید. لااقل یاد بگیرید توی مصاحبه مثل میلاد نباشید 😉
ولی یادتون باشه طوری نشود که طوری شود که همش فکر کنید هنوز برای مصاحبه دادن آماده نیستید

✔️پیام هایی از دوستان دیدم که نوشتن با دیدن این مصاحبه فهمیدیم که برای مصاحبه دادن آماده ایم

لینک آپارات:
https://aparat.com/v/haxk9tk

لینک پست امیربهادر در تلگرام:
https://t.me/BenDevelop/140

شاید برای شما هم سوال بود که چطور SQL کوئری‌هایی که با ORM جنگو میزنیم رو ببینیم؟

https://b0uh.github.io/django-show-me-the-sql.html

@TorhamDevCH

یک نکته درباره primary key داخل #جنگو اینه که شما میتونید برای هر app به شکل خاص primary key خاص خودش رو داشته باشید. مثلا برای یک app از big integer استفاده کنید و برای یکی از UUID این رفتار رو برای هر اپ میتونید به مشخص کردن AppConfig.default_auto_field مشخص کنید. حالا #django این قابلیت رو هم بهتون میده که جدا از انتخاب دونه دونه برای هر اپ یک حالت گلوبال در نظر بگیرید که اگر مخصوص اپ ست نکرده باشید از اون استفاده میکنه که پیش‌فرض خود جنگو BigIntegerField در نظر میگیره و میشه با تغییر دادن DEFAULT_AUTO_FIELD داخل settings.py به شکل گلوبال تغییرش داد

@TorhamDevCH

این توانایی که خود #جنگو بهتون میده ولی از trick دیگه هم میتونید استفاده کنید و اون هم ساختن یک مدل ابسترکت و بقیه مدل‌ها ازش ارث ببرن.
مثال:

from django.db import models 
from uuid import uuid4
  
  
class Base(models.Model): 
    id = models.UUIDField(default=uuid.uuid4, primary_key=True)
  
    class Meta: 
        abstract = True

از اونجایی که اگه داخل مدل #django فیلدی داشته باشید که داخلش primary_key مقدار True داشته باشه جنگو دیگه از اون مقدار دیفالتی که مشخص کردید (هردو حالت دو پیام بالا) استفاده نمیکنه و میاد از این فیلد استفاده میکنه. حالا شما میتونید بقیه مدل‌هاتون رو از این مدل ارث بری کنید و دیگه نگران مقدار id نباشید.

@TorhamDevCH

خب من یک چیز خیلی جالب و در این حال گیج‌کننده درباره ORM #جنگو فهمیدم.

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

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

اول این قانون تو ذهنتون داشته باشید: هر چیزی که باعث ایجاد یک QuerySet جدید بشه، باعث هیت به دیتابیس خواهد شد اگر اون کوئری اجرا بشه.

به مثال زیر دقت کنید:

users = User.objects.all()
print(users)

if users:
    for u in users:
         print(u)

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

اما اگر من بگم فقط دو بار دیتابیس هیت میکنه چی؟

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

خط بعدی ما از if استفاده کردیم و اینجا یک هیت دیگه به دیتابیس میخوره اما این‌بار کل کوئری اجرا میشه و اینجاست که جنگو ریزالت کوئری میگیره و داخل کش ذخیره میکنه. تو خط بعدی که اومدیم حلقه زدیم روی کوئری جنگو دیگه نمیاد به دیتابیس درخواست بزنه و از کش استفاده میکنه!

در نتیجه اینجا فقط ۲ بار دیتابیس هیت میخوره.

ادامه داخل پیام بعد...

@TorhamDevCH

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

users = User.objects.all()
print(users)
print("Cache: ", users._result_cache)

if users:
    print("Cache: ", users._result_cache)
    for u in users:
        print(u)

خروجی این خواهد بود: ( اگر فقط یک یوزر داشته باشیم)

<QuerySet [<User: torham>]>
Cache:  None
Cache:  [<User: torham>]
torham

همینطور که میبینید بعد از اجرا کردن پرینت رو کوئری کش هنوز None ( اینجا یکم شاید فهمیدنش سخت بشه با یکدونه یوزر ولی فکر کن هزارتا یوزر داریم پرینت فقط ۱۰ تاشو نشون خواهد داد)
پس بعد پرینت کش اتفاق نیوفتاد. ولی بعد از اینکه if اجرا شد کش پر شد و از اون به بعد جنگو از کش استفاده میکنه. البتهههههههه یک سری نکته هست که برمیگرده به قانونی که تو پست قبل گفتم. برای مثال:

users = User.objects.all()
print(users)

if users:
    for u in users.values("username"):
        print(u)

تو این کد اینبار ۳ بار کوئری به دیتابیس میخوره. چرا؟ چون وقتی از .values استفاده میکنید یک QurySet جدید میسازید و اون کوئری‌ست کش جدا خودش رو داره و از اونجایی که کشش خالیه در اون لحظه جنگو یک درخواست دیگه به دیتابیس خواهد زد :)

پایان\

@TorhamDevCH

دیتابیس SQL در مقابل NoSQL: کی چی به کارمون میاد؟

توی دنیای امروز، انتخاب بین SQL و NoSQL می‌تونه گیچ کننده باشه، مخصوصاً با این همه گزینه‌ دردسترس. از دیتابیس های relational مثل MySQL یا PostgreSQL گرفته تا دیتابیس های مدرن مبتنی بر داکیومنت مثل MongoDB یا ذخیره‌سازهای کلید-مقدار مثل DynamoDB، انتخاب بهترین گزینه برای پروژه‌هامون می‌تونه حسابی سخت باشه.

تو این پست قرار این موضوع رو ساده‌تر کنیم و بفهمیم کدومشون برای چه کاری بهتره.

دیتابیس ها SQL چی هستن؟

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

یکی از مزایای اصلی دیتابیس ها SQL مثل MySQL و PostgreSQL  اینه که با استفاده از relationship ها، می‌تونن از یکپارچگی داده‌ها مطمئن بشن. دیتابیس ها SQL با تعریف یه سری قوانین از قبل، یه جوری داده‌ها رو ذخیره می‌کنن که همیشه دقیق و منظم باشن.


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

👈 سیستم‌های Transactional: برای سیستم‌هایی که نیاز به انجام تراکنش‌های دقیق دارن (مثل سیستم‌های بانکی یا فروشگاه‌های اینترنتی) عالیه. این سیستم‌ها یه جوری باید کار کنن که هیچوقت مشکلی تو ذخیره یا تغییر اطلاعات پیش نیاد.

👈 گزارش‌گیری و تحلیل

👈 انبار داده: از SQL خیلی وقت‌ها برای ذخیره و تحلیل اطلاعاتی مثل اطلاعات مربوط به فروش یا رفتار مشتری‌ها استفاده می‌شه.

دیتابیس ها NoSQL

دیتابیس ها NoSQL مثل MongoDB و ElasticSearch برخلاف پایگاه‌های SQL، رویکردی منعطف‌تر و بدون اسکما (schema-less) برای داده‌ها ارائه می‌دن. این پایگاه‌ها برای مدیریت حجم زیادی از داده‌های بدون ساختار یا نیمه ساختار طراحی شدن و برای مواردی که در اونجا مقیاس‌پذیری، انعطاف‌پذیری و کارایی حرف اول رو می‌زنن، عالی هستن.

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

علاوه بر این، دیتابیس های NoSQL بسیار انعطاف‌پذیر هستن و به توسعه‌دهنده‌ها این امکان رو می‌دن که بدون نیاز به اسکماهای از پیش تعریف‌شده، داده‌های بدون ساختار رو ذخیره و بازیابی کنن. این ویژگی اون‌ها رو برای سناریوهایی که فرمت داده‌ها ممکنه در طول زمان تغییر کنه، ایده‌آل می‌کنه.

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

👈 سیستم‌های توزیع‌شده و مقیاس‌پذیر.

👈 داده‌های حجیم و Real-Time Analytics: دیتابیس های NoSQL در سناریوهایی که شامل داده‌های حجیم و تحلیل لحظه‌ای هستن و در اونجا توان عملیاتی بالا و تأخیر کم اهمیت زیادی داره، عالی عمل می‌کنن.اون‌ها به طور معمول در اپلیکیشن‌هایی مانند IoT، تحلیل شبکه‌های اجتماعی و real-time recommendation engines استفاده می‌شن.


تصورات غلط رایج

با وجود تمام نقاط قوتی که دیتابیس های SQL و NoSQL دارن، در موردشون یه سری تصورات غلط رایج وجود داره.

دیتابیس ها SQL انعطاف‌پذیر نیستن: درسته که دیتابیس ها SQL اسکما یا ساختار ثابتی دارن، اما اون‌ها امکانات قدرتمندی برای تعریف روابط بین جداول و اعمال محدودیت‌های یکپارچگی داده ارائه می‌دن.

دیتابیس ها SQL نمی‌تونن به صورت horizontal مقیاس‌پذیر باشن: هر دوی دیتابیس ها SQL و NoSQL می‌تونن به صورت horizontal مقیاس‌پذیر باشن، حتی اگه روش های مقیاس پذیریشون متفاوت باشه

دیتابیس ها NoSQL از transactional پشتیبانی نمی‌کنن: بسیاری از دیتابیس ها NoSQL قابلیت‌های تراکنشی رو ارائه می‌دن، با وجود اینکه با چیزی که تو دیتابیس ها SQL به عنوان ACID شناخته می‌شه، فرق کنه.

دیتابیس ها NoSQL همیشه از دیتابیس ها SQL سریع‌تر هستن: عملکرد یه پایگاه داده به عوامل مختلفی بستگی داره، از جمله ماهیت حجم کاری، توزیع داده، الگوهای دسترسی به داده و استراتژی‌های ایندکس‌گذاری. هر دوی دیتابیس ها SQL و NoSQL می‌تونن بهینه سازی بشن.

نتیجه‌گیری

در نتیجه، انتخاب راه‌حل مناسب دیتابیس برای پروژه نیازمند درک دقیق نقاط قوت و ضعف دیتابیس هاس. در حالی که دیتابیس های SQL در یکپارچگی داده قوی و پشتیبانی از کوئری های پیچیده رو ارائه می‌دن، دیتابیس ها NoSQL مقیاس‌پذیری و انعطاف‌پذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و می‌تونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت داده‌های شما و نیازهای خاص اپلیکیشن شما بستگی داره.

جونیور و میدلول ها :

رفقا اگر به هر زبانی برنامه مینویسین
و در سطح جونیور و میدلول هستین
دوره جنگو رو ببینین


راستش این دوره اصلا جنگو نیست



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


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

نست جی اس
لاراول
جین
و.........





پارت سوم سی ای سی دی
و دپلویمنت



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




https://youtube.com/playlist?list=PLYrn63eEqAzY5uG5ks_OquWcojzHvhp9Z&si=aYZXHwT2GHn2da5p

یک مبحثی که خیلی وقت‌ها آدم‌های رو داخل #جنگو گیج میکنه موضوع Aggregation هستش. برای مثال کوئری پایین:

>>> from django.db.models import Avg, Max, Min
>>> Book.objects.aggregate(Avg("price"), Max("price"), Min("price"))
# {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}

خب این کوئری مشخصه چه کاری داره انجام میده، همه میتونن بفهمنش مخصوصا وقتی خروجی کوئری رو میبینن، اما اگر ازشون بپرسید خب Aggregation چی هستش هیچ ایده ای ندارن! و این ماجرا از ضعف در دانش SQL سر چشمه میگیره. چون خیلی از آدم‌هایی که دارن #django کار میکنن مستقیم سراغ جنگو اومدن و نرفتن چیزهای دیگه رو مطالعه کنن و یاد بگیرن.

اسم Aggregation داخل ORM جنگو مستقیما از SQL میاد. در SQL یک سری فانکشن وجود داره که بهشون Aggregation functions میگن و کارشون خلاصه سازی اطلاعات:
MIN() - returns the smallest value within the selected column
MAX() - returns the largest value within the selected column
COUNT() - returns the number of rows in a set
SUM() - returns the total sum of a numerical column
AVG() - returns the average value of a numerical column

و خب شما میتونید داخل کوئری‌های SQL ازشون استفاده کنید و دیتا خروجی رو خلاصه سازی کنید و یا یک آمار ازش دربیارید. مثلا میانگین قیمت کتاب‌های تو سال اخیر و ...
یک کوئری مثال برای Aggregation میتونه این باشه:

SELECT AVG(Price) as price_avg FROM Books WHERE puddate='2023-01-01';

خب از اونجایی که ORM جنگو در نهایت قرار کار همین SQL نوشتن برای شما انجام بده و کوئری‌ شمارو به SQL تبدیل کنه شما دقیقا همین کوئری میتونید داخل جنگو به این صورت بنویسید:

>>> from django.db.models import Avg
>>> from datetime import datetime
>>> Books.objects.filter(pubdate=datetime(2023, 1, 1)).aggregate(price_avg=Avg("price"))

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

در نهایت از دانش SQL غافل نباشید و حتما یادش بیگیرید. هرچی بیشتر SQL بدونید زندگی راحت‌تری خواهید داشت.

@TorhamDevCH

شاید شما هم مثل من پوشه‌ی تنظیمات editorتون رو به gitignore همه‌ی پروژه‌هاتون اضافه می‌کنید، اما اگر پروژه، پروژه‌ی ما نیست چی؟ به تمام پروژه‌‌هایی که contributor شون هستیم چی؟ یا مثلا فایل .DS_Store مک رو در نظر بگیرید، چون یک نفر مک داره باید این به gitignore پروژه اضافه بشه؟
راه حل بهترش استفاده از global gitignoreئه، یه فایل گیت ایگنور که برای سیستم شما روی همه چی اعمال میشه نه فقط یه ریپوزیتوری.
در موردش اینجا بخونید:
https://sebastiandedeyne.com/setting-up-a-global-gitignore-file/