Python Hints

هیچ چیز به اندازه دیدن ویدئو خوب آخر شب حال نمیده : Software Engineering Mock Interview (Python3)

#django_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 و در نهایتاً نمیشه توسعه دهنده جنگو باشید و عضو بزرگترین کامیونیتی جنگو فارسی نباشید : @DjangoEx ادمین کانال رو میشناسم و به هدفش ایمان دارم، از روز اول هم دنبال کننده‌اش هستم و خواهم بود.

خیلی دوست دارم این کتاب رو بخونم، چند بخشش رو برای دمو گذاشتند که بنظرم این مباحث رو خیلی خوب توضیح داده بود (نمی‌دونم باقی موارد هم همینطور هست یا خیر) برای خرید فقط نسخه Epub رو می‌تونم بخرم (که اصلاً طرفدارش نیستم) نسخه pdf رو چندتا سایت ایرانی برای فروش گذاشتند، که خب پیگیر شدم بدون مجوز نویسنده هست و ایشون هیچ درآمدی ازش نداره. Amazon Link اگر کسی این کتاب رو خونده، یک پیام بهم بده حتماً.

#موقت ی لحظه بهش فکر کن 🫠

به یک باگ (باگ هم نمیشه گفت البته، بیشتر سر نبود داکیومنت هست شاید) بر خوردم بعد فهمیدم این آهنگ چقدر به موقعیت میاد خشم و خستگیم به لبخند تبدیل شد : https://t.me/PytensMusic/145 پ.ن : مخاطب آهنگ‌های شما هم هستم، کسی موسیقی خوب داشت حتماً برای منم بفرسته 🌹

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

make prodsetup 

و بعد

make migrate

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

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

Makefile

هست؛ ی ابزار روی لینوکس داریم به اسم make که خودش ی دوره (حداقل ۴ ساعته لازم داره تا درست متوجه بشید) مثالی که توی تصویر بالا زدم ساده ترین حالت استفاده از make هست و برای توسعه دهنده پایتون کافی. اگر C - Rust , ... کد میزنید بهتره کامل یادبگیرید خیلی کمک می‌کنه واقعا Documentation فقط ی توضیح کوتاه بدم؛ تعریفش این هست. make command compiles different program pieces and builds a final executable. توی فایل بالا و روی 20: .PHONY: توی دنیای پایتون همیشه این رو قبل از دستوری که میخواید بنویسید بذارید؛ اگر این رو نذارید make ابتدا دنبال فایلی با اسم دستوری که گذاشتید می‌گرده و اگر توی پروژه فایلی به این اسم وجود داشته باشه که به تازگی هم آپدیت شده دستور رو اجرا نمی‌کنه؛ در صورت نبود اون فایل یا تغییر زمانی دستور شما رو بصورت کامند اجرا می‌کنه و timestamp فایل رو تغییر میده خلاصه که ی خط در میون ممکنه ببینید دستور شما اجرا نمیشه. دو خط بعدی میگه که make در صورت دیدن این دستور باید چی رو اجرا کنه برای اجرا میزنید : make migrate برای مثال بالا.

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

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

تصویر: نمونه خروجی pre-commit در نهایت برای بررسی ارورها ( isort, black, mypy بصورت اتوماتیک بعد از اینکه ارور رو نشون دادند فایل‌ها رو تغییر میدند و درست می‌کنند) دستور زیر رو اجرا می‌کنید pre-commit run --all-files البته --all-files رو اگر نزنید 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 رو داشته باشید)

.flake8 وقتی از flake8 استفاده می‌کنید که یکسری از استاندارد‌ها رو بررسی کنه و درصورت رعایت نشدن ارور بده احتمالش زیاد هست که بخواید یکسری تغییرات توی تنظیمات دیفالتش اعمال کنید. برای مثال من روی پروژه‌های django بعد از پایتون ورژن ۳.۴ بصورت تصویر بالا تنظیمش می‌کنم :

#موقت ☝️☝️☝️☝️☝️☝️☝️☝️☝️

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

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

javascript, python, rust 

و هر گروه از آدم‌هایی که باهاشون کار میکردم هم استاندارد خودشون رو داشتند مثلا تیم js تعداد indent رو دو درنظر میگرفت و یک تیم دیگه این مقدار رو چهار و ... یعنی هر پروژه کانفیگ خودش رو داشت. الان خیلی کاربردی نداره مخصوصا اینکه با تیمی که باهاش کار میکنم چندسالی هست باهم کد رد و بدل کردیم و یک توافق نانوشته باهم داریم روی کانفیگ vscode ولی خب توی آموزش باید این موضوع باشه مهمترین option ها اینجا هست؛ فقط توجه کنید همه‌ی IDE ها و ... معروف ازین مورد پشتیبانی می‌کنند فقط شاید لازم باشه تیک فعال سازیش رو بزنید vscode : settings > search for : EditorConfig > Use Editor Config برای توضیحات بیشتر : https://editorconfig.org/

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

فایل بعدی که باید داشته باشید 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 هست نباید اینجا باشه.

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

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 استفاده می‌کنید توی پروژه می‌تونید به ترتیب هر ۳ مورد یا ۲ مورد اول رو توی گزارش ننویسید.

خب با اسکریپت شروع می‌کنیم کل کد شما داخل فایل .py هست پایان آموزش ازین شوخی بی‌مزه‌ها بود درحال نوشتن متن هستم (از ساده‌ترین مورد شروع می‌کنم)