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

توی شرکت چندتا نیروی بخش
Backend - software engineering

بهم سپرده شده (سنیور توشون نیست) که توی همین چند مدتی که گذشته به
conflict
های بسیاری خوردیم (روی پروژه‌های قبلی) حالا قرار هست با این دوستان پروژه جدیدی رو شروع کنیم و برای همین دارم استاندارد سازی می‌کنم و آموزش میدم نیروها رو.

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

اما وقتی صحبت از

Backend development, software engineering

می‌شه بنظرم باید این موارد رعایت بشه.

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

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

@PyHints

je n'ai pas changé
Artist: Julio Iglesias
Album : Sono Un Pirata, Sono Un Signore
Released: 1978
Produce: 1978
Genres: Pop

@PytensMusic

این ترجمه هم خواهد ماند

به مناسبت 2k شدن ممبرهای کانال و پیام‌های گرم که این مدت از شما عزیزان دریافت کردم.
مرسی از همگی

امیدوارم این آهنگ رو دوست داشته باشید (هرچند می‌دونم سلیقه موسیقی‌‌ام با نسل امروز هماهنگ نیست خیلی)

اما برای تشکر از همه‌ی لطفی که دوستان توی این مدت داشتید چیز بهتری برای ارائه نداشتم.

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

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

Readme.md

حداقل باید شامل ۳ مورد باشه :
۱- سیستم عاملی که روش کد زدید یا تست گرفتید :
OS: Ubuntu 20.04
۲- ورژن پایتونی که دارید استفاده می‌کنید:
Python: CPython 3.10.12
پایتون نسخه‌های مختلفی داره اگر از نسخه سایت python.org استفاده می‌کنید به اسم CPython شناخته می‌شه (توی شرکت‌هایی که از نسخه‌های دیگه مثل IronPython - Pypy - IntelPython استفاده می‌کنند رعایت این نکته بسیار مهم هست)

۳- دستور اصلی به جهت اجرای پروژه :
$ python main.py —help


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

اگر Dockerfile یا docker image استفاده می‌کنید توی پروژه می‌تونید به ترتیب هر ۳ مورد یا ۲ مورد اول رو توی گزارش ننویسید.

فایل بعدی که باید داشته باشید
requirements.txt
نبودش توی تیم ما خطای بزرگی هست :
۱- دیلی شرکت نکردن بدون اطلاع قبلی؛ دستمزد اون روز رو حذف می‌کنه
۲- پروژه تحویل دادن بدون
requirements.txt
درست بین ۲ تا ۷ روز کسر از دستمزد داره (اهمیت رو ببینید)

اما توی تیم من حداقل ۳ نکته هم باید رعایت بشه :
۱- بجای یک فایل باید ۳ تا فایل برای requirements داشته باشید
base.txt- local.txt - product.txt
یک پوشه به این اسم میسازید و این ۳ فایل داخلش قرار میگیره
تصویر بالا برای فایل
base.txt
هست؛ این فایل شامل پکیج‌هایی میشه که چه توی محیط توسعه چه توی پروداکشن باید وجود داشته باشه
local.txt
برای محیط توسعه هست خط اول این فایل همیشه باید
-r base.txt
باشه که بصورت اتومات پکیج‌های داخل base رو هم شامل بشه موقع نصب و باقی خط‌های فایل شامل پکیج‌هایی میشه که فقط توی محیط توسعه لازم هست :
black, isort, flake8, pre-commit, ...
و در نهایت
prod.txt
مواردی که فقط روی پروداکشن لازم هست بازم خط اول باید
-r base.txt
باشه حتما و قطعا چیزی که توی local هست نباید اینجا باشه.

۲- تمامی پکیج‌ها باید ورژن داشته باشند اما استفاده از
==
برای ورژن زدن پکیج‌ها ریکامند نمی‌شه بجاش از
~=
استفاده می‌کنیم دلیلش هم این هست که آپدیت‌های پچ رو بتونیم دانلود و نصب کنیم (چه امنیتی باشه چه رفع باگ‌های ساده) بدون اینکه نیازی به تغییر حتی ۱ خط کد باشه

۳- تا جایی که امکان داره موارد رو بصورت دستی بنویسید و از pip freeze دوری کنید؛ که فقط پکیج‌های اصلی ذکر بشه و فایل تمیزتری برای بررسی وجود داشته باشه.

این مواردی هست که توی تیم بنده رعایت می‌شه و تجربه بهم نشون داده کار خوبی هست (جاهای دیگه هم دیدم این مورد رو)
برخی از toml , ... استفاده می‌کنند که من برای پروژه تیمی تایید نمی‌کنم چون هرکسی ممکن ازین ابزارها استفاده نکنه ولی اگر کل تیم شما با اون فرمول پیش میره شما هم همون کار رو بکنید.

بازم میگم ما ترجیح میدیم راجب انتخاب ابزار هیچ فشاری روی باقی تیم نداشته باشیم.

.editorconfig

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

javascript, python, rust 

و هر گروه از آدم‌هایی که باهاشون کار میکردم هم استاندارد خودشون رو داشتند مثلا تیم js تعداد indent رو دو درنظر میگرفت و یک تیم دیگه این مقدار رو چهار و ... یعنی هر پروژه کانفیگ خودش رو داشت.


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

مهمترین option ها اینجا هست؛ فقط توجه کنید همه‌ی IDE ها و ... معروف ازین مورد پشتیبانی می‌کنند فقط شاید لازم باشه تیک فعال سازیش رو بزنید
vscode :
settings > search for : EditorConfig > Use Editor Config

برای توضیحات بیشتر :
https://editorconfig.org/

خیلی حق بود ...

.flake8

وقتی از flake8 استفاده می‌کنید که یکسری از استاندارد‌ها رو بررسی کنه و درصورت رعایت نشدن ارور بده احتمالش زیاد هست که بخواید یکسری تغییرات توی تنظیمات دیفالتش اعمال کنید.

برای مثال من روی پروژه‌های django بعد از پایتون ورژن ۳.۴ بصورت تصویر بالا تنظیمش می‌کنم؛ خطوطی که کامنت کردم تنظیمات مهمی هست که بنظرم لازم بود بدونید.

البته که وقتی از pre-commit استفاده می‌کنیم به این فایل نیازی نداریم؛ توی پست‌های بعدی می‌گم چرا

.pre-commit-config.yaml
من نمونه تنظیمات خودم رو گذاشتم که هرکسی دوست داشت استفاده کنه

pre-commit
س سری تنظیمات میگیره (به اسم هوک) و قبل از کامیت کدها اون‌هارو اجرا می‌کنه برای مثال توی تصویر بالا من :

flake8, black, isort, mypy 

و یکسری از extension های معروف flake8 که خودم باهاشون کار می‌کنم رو گذاشتم.

نکات مهم :
۱- من از poetry استفاده نمی‌کنم برای همین تنظیمات مورد نیازم رو توی همین فایل مینویسم.
۲- نیازی ندارید پکیج‌های بالا

flake8, black, isort, mypy 

رو توی requirements/local.txt که قبلتر توضیح دادم قرار بدید؛ فقط
pre-commit
رو به فایل local.txt اضافه و نصب می‌کنید خود این ابزار با شعور هست و پکیج‌های مربوط به هر هوک رو دانلود و نصب می‌کنه.

فقط توجه کنید هربار که یک repo جدید اضافه می‌کنید یا تغییرات اساسی روی این فایل دارید ۲ تا دستور رو بزنید :
pre-commit uninstall
pre-commit install

این دستورات چیزی رو حذف نمی‌کنه فقط pre-commit متوجه می‌شه چه مواردی رو باید دنبال کنه (یادتون نره قبلش git رو داشته باشید)

تصویر: نمونه خروجی pre-commit

در نهایت برای بررسی ارورها (
isort, black, mypy
بصورت اتوماتیک بعد از اینکه ارور رو نشون دادند فایل‌ها رو تغییر میدند و درست می‌کنند) دستور زیر رو اجرا می‌کنید
pre-commit run --all-files
البته
--all-files
رو اگر نزنید pre-commit بصورت خودکار فقط روی فایل‌هایی اعمال میشه که گیت اعلام کنه تغییرات داشتند ولی خب برای پروژه‌های کوچیک اجراش ضرری نداره.

الان دوستان اشاره کردند، فونت ترمینالم هم از همون قانون فونت vscode پیروی می‌کنه ؟

باید بگم هم بله هم خیر،
بله : بابت اینکه فونت شکسته هست
نه : خودم شخصاً این فونت رو راحت‌تر میخونم و چشمم رو کمتر اذیت می‌کنه

#موقت

دوستان
reaction
روی پست‌ها داشته باشید لطفا
من بر اساس این مورد متوجه میشم که یک موضوع رو ادامه بدم یا اینکه پست‌هاش رو حذف کنم.
بعد حذف می‌کنم ی دفعه میشه مثل مورد چندماه پیش که اکثرا بعد از حذف گفتید موضوع خوبی بود.

پ.ن : روی موضوعی که حال نمی‌کنید
Reaction
نداشته باشید یا حتی
dislike
بدید (به این موارد هم توجه دارم)

آخرین موردی که راجبش صحبت می‌کنیم

Makefile

هست؛ ی ابزار روی لینوکس داریم به اسم
make
که خودش ی دوره (حداقل ۴ ساعته لازم داره تا درست متوجه بشید) مثالی که توی تصویر بالا زدم ساده ترین حالت استفاده از make هست و برای توسعه دهنده پایتون کافی.
اگر C - Rust , ... کد میزنید بهتره کامل یادبگیرید خیلی کمک می‌کنه واقعا

Documentation

فقط ی توضیح کوتاه بدم؛ تعریفش این هست.
make command compiles different program pieces and builds a final executable.

توی فایل بالا و روی 20:

.PHONY:
توی دنیای پایتون همیشه این رو قبل از دستوری که میخواید بنویسید بذارید؛ اگر این رو نذارید make ابتدا دنبال فایلی با اسم دستوری که گذاشتید می‌گرده و اگر توی پروژه فایلی به این اسم وجود داشته باشه که به تازگی هم آپدیت شده دستور رو اجرا نمی‌کنه؛ در صورت نبود اون فایل یا تغییر زمانی دستور شما رو بصورت کامند اجرا می‌کنه و timestamp فایل رو تغییر میده
خلاصه که ی خط در میون ممکنه ببینید دستور شما اجرا نمیشه.

دو خط بعدی میگه که make در صورت دیدن این دستور باید چی رو اجرا کنه
برای اجرا میزنید :
make migrate
برای مثال بالا.

برای خط ۳۸-۳۹ تصویر بالا؛ اگر خواستید چندتا دستور رو پشت هم اجرا کنید باید همرو توی یک خط بنویسید.
make
متوجه هست که ابتدا باید

make prodsetup 

و بعد

make migrate

رو اجرا کنه تا make produpdate به درستی انجام بشه.

نکته دیگه اینکه ممکنه یک سری علامت توی
Makefile
هایی که از جایی میگیرید ببینید؛ توی پایتون من ندیدم و بیشتر توی C- Rust دیدم این موارد رو مثل :
$<, @, %, $^
هر کدوم ازین‌ها یک معنای خاص دارند که من چون توی پایتون کاربرد نداره توضیح نمیدم ولی برای ساده سازی
Makefile
ازش استفاده می‌شه و بهشون
Automatic Variables
گفته میشه برای آشنایی بیشتر :
Automatic Variables documentation

به یک باگ (باگ هم نمیشه گفت البته، بیشتر سر نبود داکیومنت هست شاید) بر خوردم بعد فهمیدم این آهنگ چقدر به موقعیت میاد

خشم و خستگیم به لبخند تبدیل شد :

https://t.iss.one/PytensMusic/145


پ.ن : مخاطب آهنگ‌های شما هم هستم،
کسی موسیقی خوب داشت حتماً برای منم بفرسته 🌹

خیلی دوست دارم این کتاب رو بخونم، چند بخشش رو برای دمو گذاشتند که بنظرم این مباحث رو خیلی خوب توضیح داده بود (نمی‌دونم باقی موارد هم همینطور هست یا خیر)

برای خرید فقط نسخه
Epub
رو می‌تونم بخرم (که اصلاً طرفدارش نیستم)

نسخه pdf رو چندتا سایت ایرانی برای فروش گذاشتند، که خب پیگیر شدم بدون مجوز نویسنده هست و ایشون هیچ درآمدی ازش نداره.

Amazon Link

اگر کسی این کتاب رو خونده، یک پیام بهم بده حتماً. (می‌خوام نسبت به کتاب قبلی مقایسه کنیم)

#django_roadmap #roadmap

امروز یک دوستی، گفت بهش یک roadmap برای شروع جنگو بدم با این بکگراند :
۱- پایتون رو تا سطح خوبی بلد هست
۲- ساختمان داده و الگوریتم رو می‌شناسه
۳- لینوکس، گیت و داکر رو هم بلده

یک بخش دیگه که باعث میشه این Roadmap رو بنویسم، همین موضوع هست که خیلی از بچه‌ها بهم گفتند چطوری تونستی بعد از ۲ هفته یادگیری جنگو شروع به کار کنی ؟

اول باید بگم که من ۲ هفته‌ای فهمیدن جنگو رو مدیون زحماتی هستم که روی پایتون کشیدم، بر عکس خیلی‌ها که شروع می‌کنند فریمورک یادگرفتن من فارغ از فریمورک توسعه وب رو یاد گرفتم و بعد اومدم سراغ جنگو (هرچند توی جنگو خیلی جا برای پیشرفت دارم و باید زحمتش رو بکشم هنوز)
برای همین هست که وقتی کسی بهم میگه roadmap بده میگم ۳-۶ ماه اول فقط پایتون، من به خیلی‌ها گفتم کتاب
Fluent Python
رو جلوت بذار و سرفصل‌هاش رو بخون، اگر مفهومی رو بلد نیستی یعنی هنوز آماده نیستی که بری سراغ فریمورک (حالا اینکه این موضوع برای نسل آینده برنامه‌نویسی توسعه میشه، خودش یک داستان هست. یعنی این نسخه رو نمیشه برای همه پیچید ولی قطعاً این بهترین راه هست)

تکنیکی که شخصاً باهاش فریمورک و ... رو یاد میگیرم، مختص خودم هست و اسمش رو منبع سوزی میذارم، چطوری هست ؟

۱- اول مطمئن میشم با اون فریمورک ارتباط برقرار می‌کنم و جوگیر شدن و ... درکار نیست

برای مثال روی همین جنگو :

اول رفتم سراغ این پلی لیست :
Youtube Playlist

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

دفعه‌‌ی دوم همین پلی لیست رو با دقت بیشتر و روی سرعت 1.5x نگاه کردم.

توی این تکنیک برای قدم اول هیچ نیازی به کد زدن نیست، شما تکیه میدی و از دیدن فیلم لذت میبری، توی دفعه‌ی دوم دیدن ویدئو منابع مهم رو روی یک مرورگر دیگه باز می‌کنید مثلاً: من متوجه شدم چیزهایی به اسم :
Redis, Celery, Flower, django rest framework, ...
وجود داره و همینجا متوجه شدم نیاز من یادگیری با جزئیات
DRF
هست و نه Django forms یا template نویسی پس این دو مورد رو خیلی کم روش وقت گذاشتم.

2- یادگیری از یک منبع مناسب، من کتاب‌های زیادی رو خوندم چون منبع جامع و مناسبی پیدا نکردم برای
DRF
ولی دیروز شروع کردم به خوندن یک کتابی که سرفصل‌های جالبی داشت و ۳ فصل اول رو خوندم و تموم شد که بنظرم منبع خیلی خوبی اومد نسبت به کتاب‌های دیگری که خوندم :

Becoming an Enterprise Django Developer
By Michael Dinder (Packt pub)

دقت کنید من هنوز کل این کتاب رو نخوندم ولی تا اینجا خیلی خوب توضیح داده برای شروع.
توی این قدم معمولاً اینطوری عمل می‌کنم که وقتی ۱ فصل رو خوندم و تموم شد، چند ساعتی به کارهام میرسم و بعد بر میگردم سراغ کتاب اما قبل از شروع فصل جدید بدون اینکه به کتاب رجوع کنم سعی می‌کنم کل نیازمندی و چیزی که توی اون فصل یادگرفتم و نیاز هست برای فصل بعدی رو بر اساس یادگیریم پیاده‌سازی کنم.
وقفه بین کتاب و کد برای این هست که مطمئن‌ بشم چیزی رو از حفظ نمیزنم و موضوع رو درک کردم تنها منبعی که میشه توی این بخش ازش استفاده کرد : گوگل + داکیومنت رسمی جنگو هست

۳- هرکتابی که انتخاب کنید، وقتی یک مفهوم رو توضیح میده برای موارد بیشتر و دقیق‌تر به منبع اصلی reference میده، مثلاً کتاب بالا
وقتی یک فصل رو تموم می‌کنید، بعد از اینکه اون فصل رو کدهاش رو زدید و تموم شد
باید برگردید روی کتاب و همون فصل و منابعی که برای خوندن بیشتر بهتون معرفی کرده رو بخونید.
این قدم بسیار بسیار مهم هست، چون هم با اصطلاحات آشنا می‌شید، هم با اکو سیستم اون فریمورک و هم یاد میگیرید چطور باید از داکیومنت فریمورک استفاده کنید بدون اینکه وقت تلف کنید.

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

پس اگر از نحوه خوندن من و البته بخش اول که پیش‌نیاز هست بگذریم ۴ تا منبع معرفی می‌شه کرد :

1- YouTube PlayList
نسخه DRF هم هست (اگر دوست داشتید توی همون کانال ببینید)
2- Becoming an Enterprise Django Developer By Michael Dinder (Packt pub)

3- Django documentation
4- Django Rest Framework