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

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

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

چندبار بهش گفتم تا مشکل رو پیدا نکنم نمی‌شه به راهکار رسید
ولی
آخر عصبی شدم؛ گفتم برو 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 که باهاش نوشته شده بندازید که خودش یک دانشگاه هست!


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

پست‌های پروفایلینگ 👆👆👆

چون الان scalene روزم رو نجات داد و توی ۱۵ دقیقه اشتباهات کد async همکارم رو توی code review پیدا کردم، گفتم یک اشاره بکنم به پست‌های قدیمی که درمورد profiling بوده

ابزار scalene واقعاً کاربردی و فوق‌العاده جذاب و راحت هست.

الان متوجه شدم پست آموزشش رو نذاشتم؛ ولی یادم نیست برای اینکه با متن نمی‌تونستم توضیح بدم پست نذاشتم
یا اینکه توی شلوغی روزهام فراموشش کردم!

#یادآوری
پست scalene رو روی کدهای Bashutils بذارم 🤔

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

البته سمی نبود؛ که خب مار پایتون هم سمی نیست. 😂

ماه دیگه!
شدیدا منتظر انتشار این کتاب هستم.

Python3.11, Django 4

اولین بار که 1st edition این کتاب رو می‌خوندم قبل از این بود که وارد حوزه AI بشم (چندماه قبلتر) و خیلی چیزا ازش یاد گرفتم.

امیدوارم 3rd edition هم به همون خوبی باشه.

اگر از Docker Desktop استفاده می‌کنید حتما باید آپدیتش کنید؛ یک vulnerability سطح بالا توی نحوه پیاده‌سازی داره (آپدیت آخر مشکل رو حل کرده)

https://nvd.nist.gov/vuln/detail/CVE-2025-9074

این مورد باعث میشه با ۲ خط کد بشه تمام موارد امنیتی رو دور زد و به سیستم عامل اصلی دسترسی گرفت.

توی گزارش اصلی فقط ویندوز گفته شده (نمی‌دونم مک هم داره یا نه)

دارم فصل ۱۰ کتاب Rust web programming 3rd edition رو ریویو می‌کنم، این بخش بهترین نکته‌ای هست که داره.

خیلی پست‌های مختلف می‌بینم که می‌گن؛ لایه logic, data, view, .... رو از هم جدا کنید و ازین حرفا (طرف ۲ هفتس کلین کد خونده) که نکته خیلی خوبی هست اما نه همه جا

و خیلی وقتا هم کد دستم اومده که دیدم؛ طرف زده get_repository بعد این رو گذاشته توی یک پوشه و فایل دیگه
میرم کد رو می‌خونم می‌بینم ۱ خط کد نوشته یک return ساده.

این مدل جداسازی مزخرف‌ترین کاری هست که می‌تونید انجام بدید.

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

repository= .....

همون کار رو می‌کنه؛ ۱۰۰ برابر خواناتر و تمیزتر‌ هست و در صورت رشد کردن کدش؛ توی refactor جدا خواهد شد.

بعضی وقتا آدما برای clean code زدن، گند میزنند توی خوانایی و حتی clean بودن پروژه چرا چون clean code رو فقط در سطح یک اسکریپت بهش نگاه می‌کنند در سطح کل پروژه.


مثال دیگر:
این رو زیاد می‌بینم؛

cleaned_text = preprocess(mytext)

بعد میرم توی مسیری که گفته شده:

utils/preprocessing.py

def preprocess(text:str):
    return text.strip()

ببین ذهن من چقدر باید اذیت بشه که توی توسعه کدهای بعدی یادش باشه که اینکار رو برای یک strip ساده انجام بده.
حالا فرض کنید یک پروژه ۱ میلیون خط کدی؛ اینطوری نوشته شده باشه!

بنظرتون این پروژه clean code هست یا shit code ؟!

یادتون نره؛ refactor پنالتی نیست، بلکه نشون می‌ده شما به کد و پروژه زیر دستتون اهمیت می‌دید!
من ترجیح میدم
text = input.strip()
رو داشته باشم و وقتی این تمیز کاری دیتای ورودی بزرگتر شد اونوقت اون رو جدا کنم.

#موقت
وسط توضیح برق رفت

utils/preprocessing.py:

def preprocessing(text: str) :
    return text.strip()

utils/__init__.py
```python
```

from utils.preprocessing import preprocess

...
cleaned_text = preprocess(text)
...

این میزان کدی هست که باید برنامه نویس بعدی توی ذهنش نگهداره 👆

بجای :

text = input.strip()

حالا اینو ضربدر ۱۰۰ یا ۱,۰۰۰ کنید برای یک پروژه توی اسکیل استاندارد.

دستورات مهم uv, چون درموردش ازم پرسیدید.

تمام پروژه‌های خودم رو بردم روی این مورد؛ و اکثر پروژه‌های شرکت که مسئولیت تیم نگهداری و توسعه‌اش با من هست.

برای دپلوی‌ها هم، از uv تو مرحله build روی Docker استفاده می‌کنم

تا همین ماه پیش هم اگر از من راجب کتاب داکر می‌پرسید، نسخه اول کتاب
Docker in a month of lunches
رو معرفی می‌کردم؛ نوشتار فوق‌العاده و جزئیات به اندازه کافی و البته تصاویر خوب برای انقال نکات مهم.

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

حالا نسخه دوم کتاب معرفی شده (برای اونایی که بهونه‌اشون تغییر دستورات بود)

شخصاً هنوز فرصت نکردم بخونم، اما یک مرور سریع کردم و بنظرم ازین به بعد باید این نسخه رو دنبال کرد.

(راستی قابلیت استوری گذاشتن کانال رو از دست دادیم، اگر کتاب‌هایی که قبلتر معرفی شدند رو خواستید روی اسم کانال بزنید و وارد بخش posts بشید)

#Book@pyHints

Bruno
نسخه vscode-extension رو هم منتشر کرد.

توی معماری سیستم یک اصطلاحی داریم به اسم؛
distributed monolithic
که خب یک anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس)

معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده می‌شه اما به اشتباه.

کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تست‌ها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواست‌هایی که هندل میشه بیشتره.

البته من مطمئن بودم که اینطوری می‌شه به سه دلیل :
۱- به وضوح anti pattern رو می‌دیدم
۲- تعداد درخواست‌های بین سرویس‌ها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویس‌ها هدر می‌رفت روی نتورک. (که خب حتی async هم نبود که حداقل cpu هدر نره)

این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم می‌شنوم رو انتقال بدم:

۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.

این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر می‌کنند این یعنی برای هر سرویس باید یک سرور Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که:
مثلاً سرویس auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده

۲- هر تابع، متد یا ... باید single responsibility داشته باشه.

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

اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یک‌جا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویس‌های دیگه رو دستکاری کنی)؛ برگشته می‌گه پس Single Responsiblity چی می‌شه ؟

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


۳- ماکروسرویس بهتره ...

نه چون یک چیزی سخت‌تر هست پیاده‌سازیش لزوماً بهتر نیست، بسیار بسیار پروژه دیدم که گفتم خب همه‌ی چیزایی که اینا لازم دارن اگر monolithic بود، هم سریعتر بود هم سرعت توسعه‌اش بیشتر بود هم نیاز به این همه دولوپر نداشت.


چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه،‌ ولی تبدیل سیستم به یک monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balance
و بالا آوردن چندتا instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.


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

ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.

#توضیح

خیلی وقتا بهم میگن؛ این چیزایی که میگی و تأکید می‌کنی روش برای کسی که تازه شروع کرده یا داره شروع می‌کنه خوب نیست، دست انداز می‌شه دلزده میشه و ....
اولاً من اینارو برای بچه‌های سطح بالاتر میگم؛ برای تازه‌کار شنیدنش خوبه ولی لزومی نداره روز اول بره سراغ این موارد.

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

تست کنید 👆

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

در نهایت:
همونطوری که خروجی همه‌ی کلاس‌های آموزش زبان انگلیسی، مترجم‌های برتر ادبیات کلاسیک انگلیسی نیست و حتی ممکنه فقط
I am a blackboard
ازش در بیاد؛ قرار هم نیست خروجی همه شاگردهای شما Dennis Ritchie باشه، اتفاقاً خیلی‌هاشون قراره خیلی زود متوجه بشوند اصلا علاقه‌ای به برنامه‌نویسی ندارند فقط لایک شدن پستای اینستاگرامشون و ویدئو دادن توی یوتیوب براشون مهمه

خلاصه؛ اگر حتی مقدمات یک چیزی رو درس میدی، باید اصول و قواعد رو رعایت کنی وگرنه خیانت داری می‌کنی

4: It is appalling. Please, please don't do this.

source: Architecture Patterns with Python page 14

من یک پستی روی لینکدین گذاشتم؛ چندروزه برای ارتباط گرفتن با maintainer های یک پروژه‌ای فعالیتم زیاد شده اونجا و کامنت گذاشتن زیر پست‌ها و ... ازم راجب منبع زیاد سوال شد.

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

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

و کامنتی که هیچوقت جواب داده نشد؛ چندنفر سوال کردند گفتم بازم توضیح بدم:

اول نگاهی به کتاب‌ها بندازیم و دسته‌بندی کنیم اونارو ؟
من کتاب هوش مصنوعی رو توی لینکدین نذاشتم.

کل کتاب‌هایی که معرفی کردم به ۴ دسته تقسیم می‌شه:
۱- پایتون مقدماتی تا کمی پیشرفته.
مگه میشه شما زبان برنامه‌نویسی که کد می‌زنی رو درست نشناسی ؟
۲- برنامه‌نویسی async و کمی optimization برای پایتون.
واجب هست؛ چون باعث میشه نسبت به رقبای بازار بهتر باشید
۳- ساختمان داده و الگوریتم؛
هرجای استانداردی که برید مصاحبه فنی حداقل چیزی هست که پرسیده میشه
۴- طراحی و معماری نرم‌افزار و سیستم
امکان نداره یک سوال هرچند کوچیک و ساده راجب این موضوع ازتون نشه.

پست بعدی

یک نگاهی به مصاحبه‌های software engineering بندازید
یا حتی mock interview هایی که موجود هست!

تمام این موارد حداقل‌ای ها هست ولی در سطوح مختلف از شما پرسیده میشه.

در نهایت؛ فکر می‌کنم از پست‌هایی که تا به امروز گذاشته شده همه درک کردید!
من پست‌هام برای
software engineer

شدن هست و کسایی که شاید بودنشون توی این کانال هم اشتباه باشه؛ اما قطعاً خوشحالیم از اینکه هستند:

۱- انواع و اقسام وایب کدر
۲- بطور‌کلی تر؛ کدر‌‌ها
۳- هرکسی که نیازی به درک داشتن از کاری که می‌کنه نداره و فقط می‌خواد ی چیزی دمو کنه

درنهایت برای سه مورد خاص هم هیچکدوم از مطالب کتاب‌های بالا نیاز نیست :

۱- دانشجویی که می‌خواد از شر تسک‌های استاد زودتر راحت بشه.

۲- کارمند دولتی که ۱/۳ شرکت خصوصی حقوق میگیره و مدیرانش هم هیچ درکی از هیچی ندارند.

۳- کسی که ایده خوبی داره و کمتر از ۱-۲ هفته وقت داره برای ارائه ایده‌اش MVP داشته باشه که کار کنه

اگر توی این ۲ دسته بندی و ۶ مورد نیستید؛ شرمنده‌ام باور کنید یا نه تأکید می‌کنم!

کتاب‌هایی که گفتم حداقل‌هایی هست که باید یاد بگیرید تا بهتون بگن Software Engineer

پرسیدید چرا نویسنده می‌گه این مورد appalling هست؟ با اینکه بنظر رفتار خیلی خوبی میاد.

من یک نمونه کد زدم که نشون بدم چرا بد هست این رفتار؛ توی این حالت من بیش از حد سخت گرفتم و همه چیز NewType هست (یا یک رفتاری رو نباید دنبال کنید یا کل کد باید یک استاندارد رو رعایت کنه)

اولین و مهمترین نکته :
توجه کنید نویسنده همین رفتار یعنی تعریف مداوم تایپ جدید برای نوع داده‌های اصلی رو بد می‌دونه!
اینکه بجای str, bool, int تایپ جدید تعریف کنید که پارامتر ورودی شما بهتر بنظر برسه!

حالا بررسی کنیم خود ایرادات وارده رو:

۱- تعریف نوع داده‌ای جدید هیچ عملکرد بهتری برای runtime بهم نمیده!
خیلی از افرادی که اینکار رو می‌کنند برای فرار از تست کردن کدها؛ فرار از نوشتن ولیدیشن؛ فرار از چک کردن پارامتر‌های ورودی و ... اینکار رو می‌کنند! این چیزی هست که شخصا بسیار توی این مدل کد زدن دیدم (قطعا هستند افرادی که اینطوری عمل نمی‌کنند ولی خب من ندیدم)

۲- خط ۹۱ کد رو ببینید؛ هرجایی از کدم که بخوام یک str یا ... رو برای این توابع استفاده کنم حتما باید توی NewType ایی که تعریف کردم بذارمش!

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