#موقت

اگر ۳ تا کتاب لازم باشه (۸۰۰ صفحه) تا فقط ۱ نکته جهت بهبود پروژه‌هام یاد بگیرم

کاملاً خوشحال خواهم بود!
خلاصه که راضی شدم 👌

حیف توی کتاب راجبش توضیح نداده بود و فقط ابزار رو اسم برده بود (اگر کسی گیت‌هابش رو چک نکنه نمی‌دونه پروژه‌اش چیکار می‌کنه)

هرکسی گوه غزه رو خورد اینو بزنید تو صورتش!

بعد از این‌ همه جنگ و بزرگ‌نمایی، فقط ۲۰٪ کودکان غزه سو تغذیه دارند
ولی از طرفی در ایران
۵۴٪ بچه‌های سیستان و بلوچستان سو تغذیه دارند

اون حرومزاده‌هایی که غزه از دهنشون نمیوفته یک کامنت هم برای بچه‌های سیستان و بلوچستان ندارند!

آره عزیز؛ حتی توی این همدردی هم به فکر وام دولتی و پشتیبانی حکومتی هستید.

لینک خبر رکنا

رکنا اقتصادی: یک استاد اقتصاد با بیان اینکه در سیستان و بلوچستان 54 درصد از کودکان، دچار سوء تغذیه و کوتاه قامتی هستند و 25 درصد هم دچار کم وزنی ناشی از اختلال در تغذیه هستند، گفت: در استان خوزستان، 58 درصد ازخانوارها دچار تغذیه ناامن هستند. این رقم در سیستان و بلوچستان 70 درصد و در استان کرمان 74 درصد است.

#Quick
سوال مصاحبه یکی از دوستان بوده.

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

Pass by Value
Pass by Reference

اشاره می‌کنید؛ اما توی پایتون اینطوری نیست توی پایتون ما
Pass By Object Reference (Pass by Assignment)
رو داریم. اول برگردیم به این تعریف که:

همه چیز در پایتون نهایتا object هست.

وقتی یک آرگومان رو به تابع میدید؛ رفرنس اون آبجکت رو براش می‌فرستید و نه یک کپی از اون رو ولی این رفرنس رو بصورت pass by value می‌فرستید! گیج گننده شد؟ برای همین میگیم پایتون نه Pass By Reference هست نه Pass By Value

یک صندوق رو فرض کنید که توش وسایل شما قرار داره (این حکم object رو داره) حالا فرض کنید برای اینکه جاش رو یادتون نره آدرسش رو روی یک کاغذ نوشتید و توی جیبتون می‌ذارید (این میشه reference شما)
یکی از دوستانتون می‌خواد صندوق رو ببینه؛ شما فقط کافیه آدرس رو بهش بدید که برای اینکار شما آدرس رو روی یک کاغذ جدید می‌نویسید و اون رو بهش میدید (این میشه Pass reference by Value)

و این میشه مدل پایتون؛ اگر رفیق شما بره اونجا و از داخل صندوق چیزی برداره یا تغییراتی روی صندوق انجام بده؛ شما هم اون تغییرات رو خواهید دید. اگرم که صندوق رو ببینه و کارش که تموم شد کاغذ آدرس صندوق رو بندازه دور اونوقت صندوق هنوز سرجاش خواهد بود و شما صاحبش هستید.

اگر بره از صندوق یدونه بسازه؛ صندوق شما تغییری نمی‌کنه فقط یکی دیگه مشابهش وجود داره (که ممکنه چیزایی که داخلش هست فرق کنه)

مثال بالا میشه برای Object هایی که قابل تغییر هستند مثل list
اما اگر Object قابل تغییر نبود چی ؟ مثل Int
اونوقت رفیق شما هر تغییری که بخواد بده اول باید ی دونه از روی چیزی که مال شما هست برای خودش بسازه بعد تغییرش بده.

def demonstrate_passing_behavior(my_list, my_int):
    print("\n--- INSIDE FUNCTION ---")
    print(f"List ID: {id(my_list)}, Int ID: {id(my_int)}")

    my_list.append(4)
    print(f"List after append: {my_list}, ID(append): {id(my_list)}")

    print("Copy of the original list")
    my_list = list(my_list)
    print(f"List copy and reassignment: {my_list}, ID(copy): {id(my_list)}")

    print("Modifying integer...")
    my_int = my_int + 10
    print(f"Int after modification: {my_int}, ID(modified) : {id(my_int)}")


original_list = [1, 2, 3]
original_int = 5

print(f"Original list: {original_list}, ID: {id(original_list)}")
print(f"Original int: {original_int}, ID: {id(original_int)}")

demonstrate_passing_behavior(original_list, original_int)

print("\n--- AFTER FUNCTION CALL ---")
print(f"Original list: {original_list}, ID: {id(original_list)}")
print(f"Original int: {original_int}, ID: {id(original_int)}")

رفتار Rust هم شباهت‌های زیادی داره به Python اما با مفاهیم دیگری مثل ownership, ... ارزیابی می‌شه.

#تجربه

بیش از ۹۸٪ پروژه‌های اپلیکیشن‌هایی که کار کردم دیتابیس رو اشتباه انتخاب کرده بودند!

اصلا طبیعیت دیتاها و کار با دیتابیس و ... اشون SQL نیست
اما ۱۰۰٪ تأکید دارند که از SQL استفاده بشه و اکثراً بعد از مدتی کوئری‌های پیچیده کل سیستمشون رو می‌گیره !


مشکل کجاس ؟
- عدم شناخت کافی از دیتابیس‌های دیگه:
Mongo, Janus, Casandra, Scylla, ....
این بیشترین موردی هست که دیدم.

- عدم توانایی طراحی درست سیستم؛ معماری سیستم خیلی مهم هست.

- عدم بررسی و آنالیز نیازمندی‌های سیستم؛ اینکه درگیر دنبال بهترین‌ها بودن نشید چیز خوبیه ولی اینکه سر چیزای ابتدایی هم تحقیق نمی‌کنید و می‌ندازید گردن اینکه من نمی‌خوام کمالگرا باشم یک موضوع متفاوت هست.

- ترس، ترس از تست کردن چیزای جدید.
طرف می‌گه من ۱۰ ساله دارم SQL کار می‌کنم (خب به درک!!)، نهایت همرو خودم Query می‌نویسم! به فکر نفرات بعدی روی پروژه هم باش
احمقانه تصمیم نگیر


راجب mongodb بخونید، خیلی از شما چیزی که بهش نیاز دارید mongodb هست
Transaction
رو هم داره؛ تا ۱۰۰ لول ارتباط تو در تو هم نگه میداره (که عمرا و عملاً بهش نمی‌رسید)
به راحتی می‌تونید replication و read-only داشته باشید

دیزاین collection (مثل table بهش فکر کنید) می‌تونی ثانیه‌ای عوض بشه اگر بخواید.
فرض کنید توی sql بتونید، هروقت خواستید بدون دردسر و migration, ... ستون اضافه کنید.

به کمک پکیج motor خیلی راحت؛ async رو هم در اختیار خواهید داشت

Janus
هم گزینه خوبی هست برای اون‌هایی که به دیتابیس Graph نیاز دارند.
۶ سال قبل بعنوان جایگزین رایگان Neo4j ازش استفاده کردم روی حجم داده بسیار بسیار بالا و خیلی رضایت بخش بود.


خلاصه که زرتی نرید با SQL شروع کنید.

متا دیگه دنبال coder نمی‌گرده
حتی اینکه چندتا leetcode هم حل کردید و حفظ کردید توی متا مهم نیست.

ازین پس، توی مصاحبه‌های شرکت META اجازه استفاده از هوش مصنوعی رو هم دارید.

۱ سال و نیم قبل گفتم، شرکت‌ها قطعاً و حتماً به این سمت خواهند رفت 👌

تعریف جونیور هم بیشتر عوض خواهد شد !

پی‌نوشت:
Coder != Software Engineer
برای دوستان تازه‌ وارد

طبق تجربه خودم؛

بیشترین دلیل fail شدن استارتاپ‌‌هایی که دیدم ایده بد یا وجود رقیب و .... نیست!

فقط یک چیز هست؛ انجام کارهای تکراری به تعداد دفعات تغییر توی کدها

دلیلش؛ عدم تست نویسی!

از هر ۱۰ مورد، ۹ مورد دلیلش جز این نبوده.

پ.ن:
راجب این مورد، قطعاً روی استارتاپ یکی از دوستان صحبت خواهم کرد (صحبتی که باهم داشتیم، راجب اینکه حتی وقتی پول زیادی هم پشتوانه‌اش بود بازم نهایتاً استارتاپ fail شد)

#مصاحبه

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

قرار بود من فقط ۲ روز براشون وقت بذارم و مصاحبه کنم ولی انقدر تعداد روزمه‌ها زیاد بود که ۱ هفته کار می‌برد؛ مصاحبه رو ۲ مرحله‌ای کردیم توی مرحله اول سوال جوابای کلی پایتون بود که نیروهای خود شرکت انجام میدادند و درنهایت هم ۱ تسک بهشون داده میشد که توی همون مصاحبه انجام بدند؛ تسک این بود (چون خودم تسک رو داده بودم میگم):

یک کد ۸ رقمی با الگوریتم sha256 هش شده؛ و تونستیم هش خروجی رو بدست بیاریم. کدی بنویسید که عدد رو برامون پیدا کنه.
توی سوال و جواب بهشون گفته می‌شد که عدد می‌تونه مثلا 5 هم باشه ولی به اینصورت:
"00000005"

تقریبا همه شرکت‌ کننده‌ها حل کردند مسئله رو؛ به هیچکس هیچ راهنمایی داده نمی‌شد و از هیچکدوم از افراد هم چیزی اضافه بر متن بالا خواسته نمی‌شد.

حدود ۱۲ نفر موندند که به مصاحبه مرحله دوم دعوت شدند؛ اما یکنفر بود که کلا آدم اعتراض کردن هست (پست‌هاش توی لینکدین توی چند وقت اخیر چیزایی که منم تگ شدم)
نمی‌دونست سوال مصاحبه با من بوده و ادعا کرده توی لینکدین که بهترین راه حل رو ارائه داده ولی رد شده (انگاز کسی باهاش جنگ داره) ازش خواستم پستش رو پاک کنه وگرنه براش خیلی بد میشه ...

اما این قضیه و دیدن اینکه خیلی از بچه‌های حتی سنیور عکسی که از راهکار گذاشته رو لایک کردند باعث شد بیام و بگم چرا کدی که اون آدم گذاشته بود اصلا بدرد نمیخورد:
بله کد parallel اجاره میشه ولی

همه‌ی کدهای parallel به یک اندازه خوب نیستند و یا حتی درست هم نیستند.

ادامه پست بعدی ...

اول کد آقای اعتراض (این سورس کد رو خودم زدم ولی با تکنیکی که ایشون بعنوان راهکار نهایی ثبت و ایمیل کردند.)

کد پارالل هست و اجرا هم میشه؛ هش اول رو توی ۲۲ ثانیه پیدا می‌کنه و عدد 5 رو به درستی بر میگردونه. (این هش‌ها توی تست به مصاحبه شونده‌ها داده نشده بود و من الان ایجادشون کردم اعدادش هم به عمد هست)

چرا 5 ؟
برای اینکه توی رنج اعدادی که ایجاد میشه اوایل اولین لیست chunk قرار میگیره پس سریع محاسبه میشه.

با همین نکته باید فهمیده باشید مشکل کد بالا چیه!
ربطی نداره کد ۸ رقمی کجای لیست قرار بگیره تمام اعداد ۸ رقمی رو باید تست کنه تا به جواب برسه. برای همین انقدر طول کشید.

چرا 69269268 ؟
مشگل دوم باگ برنامه‌نویس هست؛ من هم میخواستم خروجی رو برای یک عدد رندوم ببینم و هم میخواستم توی chunk های اول نباشه ولی برای این عدد بهم -1 برگردوند.
یک مقدار دقت کنید پیداش می‌کنید (البته من بخاطر این اشتباه ردش نکردم)

ادامه پست بعدی ...

اینم براساس راهکار کسی که استخدام شد؛ استفاده از

multiprocessing.Value

برای اینکه بتونه بین پراسس‌ها وضعیت رو بررسی کنه؛ به محض اینکه یکی از پراسس‌ها اعلام کنه به جواب رسیده

found.value

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

با این روش؛ جواب هش اول توی 7ms بدست میاد.

اما این کد هم می‌تونه بهتر بشه؛ برای hash دوم با عدد 69269268 تقریبا ۲ برابر روش قبلی زمان نیاز داره!
بطور کلی برای اعدادی که توی ۲۵٪ انتهای chunk خودشون قرار میگیرند!

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

=================
سوال شده:
۱- لینکدین من روی پست اول توی پین شده‌ها هست

۲- فونتی که استفاده می‌کنم operator mono هست

۳- ادیتور و تم و ... هم مربوط به تنظیمات neovim هست که گذاشتم البته از برنچ javascript استفاده کنید این تغییرات اونجاس (فونت رو باید روی ترمینال فعال کنید)

۴- توی مصاحبه اول، دسترسی به ai وجود نداشت؛ مصاحبه دوم بلامانع بود استفاده از ai

۵- سوال اصلی مصاحبه نبود؛ برای حذف روزمه‌های اضافه بود

یه کار خوب دیگم که میشه کرد استفاده از concurrent.futures هست به نظر من. interface راحتی در اختیار میذاره برای حل کردن این موضوع. میشه یه process pool ساخت، تسک ها رو submit کرد و بعد wait کرد روی future ها. منتها با return_when عه FIRST_COMPLETE. اولی که اومد باقی kill بشن. برای مواقعی که نیاز نداریم gracefully تسک ها رو shutdown بکنیم (مثل اینجا) این جواب میده.
حالا من انتظار داشتم که متد shutdown یه argument ای چیزی تحت عنوان force میگرفت من مجبور نشم process ها رو اونطوری بگیرم و کیل کنم. ولی بازم خونه api تمیزی داره این.

پ.ن:
یک راهکار خوب از سروش؛ منم توضیحاتم رو همینجا می‌نویسم.

توی راه‌حل اول گفتم نتایج بهتری می‌شه داشت؛ مشکل راه‌حل این بود که فرقی نمی‌کرد کی به جواب برسیم باید برای همه صبر می‌کردیم.
اما یک کار خوب کرده بودیم؛ استفاده از ProcessPool و عدم نیاز به SharedMemory و انتقال مقدار اون‌ بین پروسس‌ها (اینکار سربار زیادی داره)

ادامه پست بعدی ....

چرا این راهکار بهتره ؟

۱- نیازی به Shared Memory نداریم؛ به محض اینکه یکی از future ها جواب بده، می‌دونیم به نتیجه رسیدیم.

۲- حتی اگر جواب توی آخرین عناصر یکی از chunk ها هم باشه بازم، نهایتاً به اندازه تست اون صبر می‌کنیم.

اما یک مسئله‌ای هم با این راهکار دارم؛
توی سیستم‌های فعلی که core ها سرعت متفاوتی دارند (بعضی‌ از cpu ها) اونایی که سرعت بالاتری دارند chunk خودشون رو سریعتر انجام می‌دهند، این روش اونجا مشکل ساز میشه یا نه ؟

سوال بالا رو بهش فکر کنید؛ اگر توی مصاحبه به Senior بر می‌خوردم قطعاً این سوال رو ازش می‌پرسیدم ولی کسی نبود حالا که سروش جواب خوب رو داد؛ این سوال رو هم با باقی اعضا به اشتراک می‌ذارم!

پ.ن:
چون گفتید؛ شخصاً نظرم اینه که
یا یک موضوعی رو نباید بررسی کرد؛ یا اینکه به همه‌ی حالاتش باید دقیق فکر کرد.
حالا که انقدر زحمت کشیدید و خوندید، بهتره کامل بررسیش کنیم! تا با نحوه تفکر مغز مریض منم آشنا بشید 😂

سروش خودش راهکار درست رو ارائه داد، ولی شماهم بهش فکر کنید.
راهکار درست و بهینه توی همون کد قبلی سروش هست؛ فقط مشکلی که توی چند خط بالا گفتم رو حل کنید.

وقتی یکی میگه؛ حالا مگه الگوریتم چقدر مهمه ؟

آدما این سوال رو می‌پرسند،چون هیچوقت تفاوت عددی بین مثلا
O(log n), O(n log n)
درک نکردند و دوتا دلیل هم داره؛

۱- پردازنده‌ها سرعت بسیار بالایی دارند.
۲- هیچوقت روی دیتاهای خیلی حجیم کار نکردند.

برای همین گشتم تا یک جدولی رو پیدا کنم؛ که الگوریتم‌ها رو با زمان اجرا اونها مقایسه کنه!

مثلاً توی این جدول ñ² رو با n مقایسه کنید؛ برای ۱ میلیون ورودی!

دیگه همینجوری for تو در تو ننویسید!

پ.ن:
برای !n هم مسئله داریم توی دنیای کامپیوتر، فروشنده دوره‌گرد

این یکی هم مقایسه سرعت عملکرد CPU نسبت به گرفتن داده هست!

دلیل پافشاری من بر اینکه؛ حتماً concurrency رو یاد بگیرید هم همین هست!

خوندنش اینطوری هست؛ ۱ سیکل سی‌پی‌یو (توی چند نسل قبل اینتل ۱۴ تا instruction می‌تونست انجام بده) رو اگر فرض کنیم ۱ ثانیه زمان میبره (زمان واقعی‌تر ستون وسط هست)

خوندن داده از سریعترین رم‌های موجود؛ ۶ دقیقه می‌شه به نسبت اون! و خوندن از درایو SSD (بسته به سرعت و ...) مثل این می‌مونه که بین ۲ تا ۶ روز زمان ببره!
و اگر async کد نمی‌زنید توی تمام این مدت CPU شما بیکار هست، باید صبر کنه تا اون داده‌ها بهش برسه!

حالا می‌تونید قشنگ درک کنید که چرا می‌گیم تسک‌های I/O bound رو حتماً async کنید‌.

#خارج_از_بحث

پست قبلی یک کلمه غلط املایی داشت؛
اصرار رو من اسرار نوشتم که باید بگم!

I don't give a shit about it ...

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

ولی ازونجایی که توی هر جمعی چندتا بیشعور هم هست؛ بعضی‌ها با کلمات و لحن نامناسب جواب دادند.

خطاب به این بی‌شعورها؛
یاد هزاران بار؛ مصاحبه‌ها، دمو محصول برای مدیران و دانشگاه افتادم ...

وقتایی که یک بحث تخصصی رو انجام می‌دادی؛ یک محصول رو نشون میدادی یا ...
و همگی لال بودند، چون سواد نداشتند و مغزشون به این بحث‌ها نمی‌کشید.
بعد در آخر جلسه؛ می‌گفتن چرا رنگ بنر رو آبی نکردی ؟ چرا اسلایدت فونت Arial نبود و ...

پست‌های قبلی گواه این موضوع هستند؛ گروهی که به کانال متصل بود بیشتر!

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

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

اما برای دوستان متخصص:

پیشنهادمم اینه که، نه تنها نادیده بگیرید بلکه این افراد رو از گروها و کانال‌هاتون بن کنید!

همونجوری که کسی آدم لاابالی رو توی مهمونیش دعوت نمی‌کنه؛ تو میزبان این مهمونی هستی بذار مهمونات لذت ببرند، تمرکزت رو بذار روی لذت اون‌هایی که دعوتند.

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

اینو می‌خواستم توی یک کانال دیگری بذارم ولی دیدم بحث انتخاب اشتباه دیتابیس اینجا بوده اینجا می‌ذارم!

۵-۶ ماه پیش، یکی سوال پرسیده بود آقا من پستگرسم هی به مشکل میخوره روی پروژه‌ام!

من هی میومدم کمک کنم، هر سوالی می‌پرسیدم یا جواب نمی‌داد (انگار داشت ناسا رو هک می‌کرد) یا نمی‌دونست.

چندبار بهش گفتم تا مشکل رو پیدا نکنم نمی‌شه به راهکار رسید
ولی
آخر عصبی شدم؛ گفتم برو sqlite بزن! واقعاً منظورم این نبود که اینکارو بکنه می‌خواستم بفهمه که اینجوری نمیشه راهنمایی کرد و البته دیگه پیام نده.

الان پیام داد، تشکر کرد بابت پیشنهاد sqlite (صحبت کردم باهاش اجازه گرفتم این پست رو بذارم) منم توضیحات بالا رو دادم بهش ....

بعد توی همین صحبت فعلی متوجه شدم؛ دیتابیس برای کار ایشون واقعاً در همین حد sqlite زیادم بوده؛ کل دیتابیس‌اش بعد از ۶ ماه کار به کمی کمتر از ۱۰۰ مگ رسیده (البته ازینجا به بعد سرعت رشدش کمتر می‌شه شاید سالی ۲۰-۳۰ مگ)

برای بکاپ هم بهش گفتم بذار برای خودت ایمیل کنه هر ۶ ساعت؛ واقعاً رفت اینم پیاده‌سازی کنه! 😂


خلاصه که تا ی چیزی توی ویدئو آموزشی می‌بینید نپرید سراغش؛ یک مقدار تحقیق بد هم نیست!

تجربه جالبی هم بود برای خودم!

#یکبار_برای_همیشه

خیلی دیدم؛ دوستانی که از لینوکس دسکتاپ استفاده می‌کنند پارتیشن Swap رو تحت همه شرایط فعال می‌کنند.
بعضی‌ وقتا حتی تا ۱۶ گیگ روی لپ‌تاپ با رم ۱۶ گیگ دیدم بهش هارد اختصاص دادند.

اولاً که؛ ۹۹.۹٪ روی Desktop و یوزر عادی نباید اصلا کار به Swap بکشه؛ توی باقی موارد هم برای ۱۶ گیگ رم نهایتاً ۱-۲ گیگ باید باشه که به محض اینکه دیدید رم درحال پرشدن هست؛ قبل از هنگ سیستم بتونید مشکل رو حل کنید.

اینکه خیلی از مدرسین لینوکس، هی میگن swap رو فعال کنید و ... رو هم نمی‌فهمم!
اگر از تاریخچه‌اش بگذریم (اگر خواستید بخونید باید دنبال این باشید، از llm کمک بگیرید)
1970s Virtual memory on IBM OS/360 or Unix

این virtual memory یا نوع پیشرفته تر امروزش به اسم swap برای این اومد که سیستم‌عامل‌ها برای multi-task مشکل رم داشتند و چون تکنولوژی رم حجم بالا اون موقع نبود ازین تکنیک استفاده کردند.

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

که ۹۹.۹٪ کاربرهای دسکتاپ این مشکل رو ندارند (نهایتاً ری‌استارت می‌کنید، سرور که نیست بگی صدای یوزرهام در میاد) و استفاده از swap فقط باعث افت سرعت سیستم و هنگ کردن بسیار براشون می‌شه بخصوص اونایی که swappiness رو هم کانفیگ نمی‌کنند.

چه تغییرات قشنگی داریم روی؛ PostgreSql 18 شماهم دیدید ؟
برای من سه موردش خیلی جذاب هست؛
اولیش بالاخره؛ Asynchronous I/O بله منم خوندم فعلا فقط روی Read ولی همینم خوبه ۲-۳ برابر سرعت بیشتر اونم مفتی کیه که بدش بیاد ؟

دومیش؛ پشتیبانی کامل از UUIDv7 یعنی بدون دردسر می‌تونی حتی روی distributed system هم primary key کاملا یونیک داشته باشی.
تازه اگر پست‌های قبلی رو دنبال کرده باشید می‌دونید UUIDv7 برای ایندکس هم عملکرد بهتری داره (مشکلی که خیلی از پروژه‌ها با UUIDv4 داشتند و حالا تقریبا حل شده)

نهایتا یک سری Optimization های خاص که بصورت اتومات کوئری شما رو قبل از اجرا بهبود میده مثلا اگر OR زیاد باشه و بشه با Any تغییرش میده و ...


و یک اشاره هم بکنم به این پست (حدودا همین موقع‌ها ۲ سال پیش):
https://t.iss.one/pyHints/117
هنوزم دیر نشده؛ وقت بذارید براش و درکش کنید!


پ.ن؛
از دوستان اشاره کردند، created_at هم اگر یادمون بره به چخ نمی‌ریم 😁
شوخی خوبی بود، اگر نگرفتید:
بخاطر این هست که UUIDv7 بر اساس زمان هست

👆👆👆👆👆

هر ۵ تا کتابی که گفتم + ۱ کتاب هم شما گفتید همرو خوندم.

اگر تا حالا اصلا سراغ FastApi نرفتید و خیلی با مفاهیم بکند هم آشنا نیستید؛ هرکدوم از کتاب‌ها که تاریخ 2024 یا 2025 خورده رو می‌تونید بخونید!

اما اگر ۳ ساعت بیشتر روی FastApi وقت گذاشتید؛ هیچکدوم از کتاب‌ها بدرد شما نخواهد خورد!

داکیومنت FastApi رو بخونید!
داکیومنت ابزارهایی که معرفی کرده رو بخونید مثل celery یا sqlmodel بطور استثنا برای sqlalchemy کتاب خوب داریم (سرچ کنید میاد)

نگاهی هم به اسپانسرهاش و پروژه‌های open-source که باهاش نوشته شده بندازید که خودش یک دانشگاه هست!


متاسفم، کتابی برای این مورد نمی‌تونم معرفی کنم.
چون کتاب درخوری ندیدم