Exception Inheritance Hierarchy
اینم موارد اصلی هست که خوبه داشته باشید.

لیست کامل Exception :
https://docs.python.org/3/library/exceptions.html

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

می‌تونید حدس بزنید چی هست ؟

توضیحات پست بعدی

پ.ن : typing توی پروژه‌ها موضوع مهمی هست اما توی پایتون الزامی نیست
هیچوقت باگ محسوب نمی‌شه و فقط جزو شرایط
clean code
هست (به این مورد اشاره نکنید)

@PyHints

مشکل اصلی استفاده از
except Exception as ex:
که دوستان توی کامنت اشاره کردند.

اصطلاحا به این روش میگن
Broader Approach

مسئله اینه که توی کد بالا من با ارور هیچ‌کاری نمیکنم (اما توی این شرایط هم broader approach اشتباه هست) ولی فرض کنید شما باید این موارد رو لاگ بندازید. در این شرایط exception handle شما به درد نمیخوره احتمالا لاگ هم همینطور چون کسی اروری نمی‌بینه که بخواد لاگ فایل رو بخونه (حتی اگر توی لاگ جزئیات بیشتری هم نوشته شده باشه)
منبع بسیاری از BUG های مخفی همین مورد هست.

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

ی مدل دیگه exception داریم که اصطلاحا بهش میگن :
naked exception
از همینجا شاید متوجه شدید دیگه؛ 😂😂

نوع تعریفش اینطوری هست :
except:

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

ازین ۲ مدل هیچوقت استفاده نکنید که یا BUG مخفی میخورید یا خدایی نکرده ایستگاه می‌شید.

راه حل کد بالا :
۲ تا Exception جدا بنویسید :
except IndexError as ex:
و اگر قرار هست TypeError هم silent کنید در ادامه‌اش
except TypeError as ex:

یا حتی ادغام هر ۲ :
except (IndexError, TypeError) as ex:

✅ یه سوال در این مورد داشتم که زیر پست پرسیدم. سوال و جوابم رو در ادامه ببینید. شاید سوال شما هم باشه (البته من آماتورم که پرسیدم)

❔ سوال در مورد این قسمت:
در این شرایط exception handle شما به درد نمیخوره احتمالا لاگ هم همینطور چون کسی اروری نمی‌بینه که بخواد لاگ فایل رو بخونه (حتی اگر توی لاگ جزئیات بیشتری هم نوشته شده باشه)
توی همین متد doubled که اشاره کردید. باید به کاربر ارور نشون بدیم؟ توی این مثال چطوری بهتره؟

✔️ یک سری ارورها رو هندل می‌کنید مثلا
TypeError, IndexError
و از کاربر ورودی درست رو ممکنه درخواست کنید ولی مثلا اگر
MemoryError
بگیرید و از broder یا naked استفاده کرده باشید
هیچوقت نمی‌شه متوجه شد چرا برنامه stop می‌شه بهتره این موارد هندل نشده بمونه شاید
چون وقتی داکر استفاده می‌کنید؛ موردی مثل MemoryError توی لاگ‌های داکر و ... می‌مونه و علاوه بر اون داکر ی container دیگر رو اجرا می‌کنه خودکار که یوزر هم experience بدی نداشته باشه (فرضم روی docker swarm هست)

❔ "بهتره این موارد هندل نشده بمونه شاید"
که excption اش رو raise کنه؟

✔️ دقیقا چون این‌ها Exception های خطرناکی هست
MemoryError
می‌تونه نشون دهنده باگ‌های خطرناکی مثل
Memory leak
باشه یا حتی مثلا نشون بده توی نسخه وب اتک خاصی به برنامه زده شده
Exception
ایی مثل ValueError , .... هم نیست که بگیم بخاطر استفاده غلط کاربر داره پیش میاد
قطعا توی کد باگ هست و اشتباه برنامه نویس پس بهتره هندل نشه و raise بخوره

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

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

✅ به قول دوستان. برگه تقلب دیزاین پترن ها
دستت درد نکنه جیسون 😂
𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝗤𝘂𝗶𝗰𝗸 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲

If you need a short cheat sheet on design patterns, you can download it from here.

Credits: Jason McDonald.

درود دوستان!

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

اگه فکر می‌کنید رفرنس یا ابزاری ارزش قرارگیری در این لیست رو داره، حتما یا Issue باز کنید یا PR بزنید. سعی می‌کنم ریویو کنم. ❤️

مثل همیشه، استار یادتون نره. ✨

Link 👉 https://github.com/DjangoEx/python-engineer-roadmap

(شیر کردن این ریپو، موجب خوشحالیست 😁)

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

https://www.linkedin.com/posts/irancysec_%D9%87%D8%B1-%DA%86%DB%8C-%D8%AF%D8%B1-%DA%A9%D8%B4%D9%88%D8%B1%D9%85%D9%88%D9%86-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-%D8%B6%D8%B1%D8%A8%D9%87-%D9%85%DB%8C%D8%AE%D9%88%D8%B1%DB%8C%D9%85-%D8%A7%D8%B2-%D8%A8%D8%B2%D8%B1%DA%AF-activity-7050703996843380736-fMcu?utm_source=share&utm_medium=member_desktop

از لینکدین Ali Bigdeli

✅ قالب پیاده سازی django با celery در همروش

تو بعضی پروژه ها لازم میشه که عملکرد های background process داشته باشید و خوب celery یکی از انتخاب هاس. برای اینکه بتونید celery رو با در نظر گرفتن worker و beater توی همروش پیاده سازی کنین باید ۳ تا اپ مجزا ایجاد کنین که شبیه به هم هستن ولی توی beater و worker دستورات اجراییش متفاوت میشه. این رپو به صورت اختصاصی برای پیاده سازی این ساختار در Hamravesh ایجاد شده و ممکنه بخواید برای استفاده شخصی تغییرش بدید.

توی این رپو می تونین قالب آماده برای تست و پیاده سازی یک پروژه ساده که worker و beater داره رو ببینید و پیاده سازی کنین. اما نکته مهم این داستان بخش cicd هستش که توی یک pipeline هر سه اپ پیاده سازی بشن که این جریان توی رپو به نمایش گذاشته شده.


آدرس رپو:

https://lnkd.in/evpeV4kV

یه بنده خدایی توی لینکدین اینو پست کرده و یه نکته برای DRF گفته.

✅ کامنت مفید Mohammad Amin Amjadi این بوده (عکسی که کامنت کردم رو هم ببینید):
There are six problems (bad pattern) in the code.

1. Do not use 'all' in serializer fields. =>
"""
fields = ('start_date', 'end_date', ...)
"""

2. To override methods, the signature of the main method must be observed (even the name of the parameters). =>
"""
def validate(self, attrs):
"""

3. Strings must be translatable. =>
"""
_("offer's end date should be after start date")
"""

4, 5, 6. Error message should not be written anywhere in the code and ValidationError should not be used directly. And the error should be sent along with the error code =>
"""
default_error_messages = {
'invalid_start_date_range': _("offer's end date should be after offer start date"),
}

def validate(self, attrs):
if attrs['start_date'] > attrs['end_date']:
self.fail('invalid_start_date_range')
"""

✅ ده تا اشتباه رایج برنامه نویس های جنگو
(البته درستش Django Developers هست)
1: Using the Global System Python Environment for Project Dependencies
2: Not Pinning Project Dependencies in a requirements.txt File
3: Using Old-style Python Functions Instead of Class-based Views
4: Writing Fat Views and Skinny Models
5: A Huge, Unmanageable Settings File
6: All-in-one Application, Bad Application Structure, and Incorrect Resource Placement
7: STATICFILES_DIRS and STATIC_ROOT Confuse Newbie Django Developers
8: Default STATICFILES_STORAGE, Django Templates Loaders in Production
9: Pure Python Scripts for Utilities or Scripts
10: Reinventing the Wheel
توضیحات هر مورد رو توی لینک زیر ببینید:
https://www.toptal.com/django/django-top-10-mistakes

✅ 28 تا best practice توی کار با مدل های جنگو (عناوین مقاله رو اینجا گذاشتم)
برای دیدن جزییات لینک رو باز کنید.
1. Correct Model Naming
2. Relationship Field Naming
3. Correct Related-Name
4. Do not use ForeignKey with unique=True
5. Attributes and Methods Order in a Model
6. Adding a Model via Migration
7. Denormalisations
8. BooleanField
9. Business Logic in Models
10. Field Duplication in ModelForm
11. Do not use ObjectDoesNotExist
12. Use of choices
13. Why do you need an extra .all()?
14. Many flags in a model?
15. Redundant model name in a field name
16. Dirty data should not be found in a base
17. Getting the earliest/latest object
18. Never make len(queryset)
19. if queryset is a bad idea
20. Using help_text as documentation
21. Money Information Storage
22. Don't use null=true if you don't need it
23. Remove _id
24. Define unicode or str
25. Transparent fields list
26. Do not heap all files loaded by user in the same folder
27. Use abstract models
28. Use custom Manager and QuerySet
لینک:
https://steelkiwi.com/blog/best-practices-working-django-models-python/

✅ اگه دقت کرده باشید توی فایل settings.py در جنگو خیلی تاکید شده که مراقب SECRET_KEY باشید. به جای اینکه دلایل رو توضیح بدم، لینک کدهای جنگو که صراحتا SECRET_KEY رو استفاده کردن اینجا میگذارم. بد نمیشه یه نگاه بندازید. (لینک ها همه مربوط به ریپازیتوری اصلی جنگو و نسخه 3.1.x هستن)

1- https://github.com/django/django/blob/stable/3.1.x/django/contrib/auth/tokens.py
2- https://github.com/django/django/blob/stable/3.1.x/django/core/checks/security/base.py
3- https://github.com/django/django/blob/stable/3.1.x/django/core/signing.py
4- https://github.com/django/django/blob/stable/3.1.x/django/utils/crypto.py

بعضی پترن هایی که حضرت Fowler معرفی کرده و جنگو داره ازشون استفاده میکنه.

📌 مدیریت وابستگی ها در پایتون

خب امروزه دیگه خیلی از پایتونر ها برای شروع یک پروژه اول میان یک virtual env میسازن و برای مدیریت وابستگی ها با pip freeze میان هر چی داده رو میریزن توی یک فایل متنی مثل requirements.txt و خب به خودمون میبالیم که چقدر ما خفنیم و مثل برنامه نویس های ارشد داریم اصولی جلو میریم

اما یک لحظه صبر کنید. آیا این کار درسته🤔 ؟ آیا نوشتن این کامند توی ترمینالمون بحث وابستگی های پروژه رو هندل کردیم و هر وقت بخوایم روی سیستم دیگه ای اجرا کنیم با زدن یک کامند نصب همه چیز درست انجام میشه ؟
pip freeze > requirements.txt
pip install -r requirements.txt

نه اینجا یک مشکلی داریم. بریم ببینیم مشکل چیه و چطور پیش میاد.

فرض کنید کتابخانه A را توی پروژه خودتون نصب کردید، که ممکنه یک وابستگی فرعی B، C و D داشته باشه. حالا، فایل requirements.txt شما با دستور بالا شبیه به این هستش.

A==1.0
B==2.0
C==1.4
D==1.2

حالا میگیم که، مالک کتابخانه A نسخه جدیدی رو منتشر می کنه که از نسخه دیگری از کتابخانه B استفاده می کنه و کتابخانه C را حذف می کنه. از اونجایی که B و C قبلاً نصب شده اند، پیپ فریز اون رو به طور خودکار انتخاب می کنه و در نسخه های اصلی قرار میده. حالا در پروژه ای با 100 وابستگی، فایل نیازمندی های شما با تغییر کتابخانه ها بسیار مشکل ساز می شه. شما باید تمام وابستگی های فرعی را شناسایی کنید و بر اساسش اونهارو را حذف کنید. در این مثال اگر A از پروژه حذف بشه، شما همچنان با B، C و D گیر می‌افتید، حتی اگر آنها فقط به دلیل A نصب شده باشند. حذف هر یک از اونها یک کار بزرگه و میتونه در پروژه‌های بزرگ بسیار آزاردهنده باشه.

💡راه حل ؟
خب دیگه خودتون برید دنبال راه حلش باشید. به من چه 😕

باشه حالا.بیایید بگم یکی از راه حل ها چیه.😁 یک کتابخونه هست به نام pipreqs که لینکش رو این پایین میزارم. و میتونه خیلی به حل این مشکل کمک کنه
https://pypi.org/project/pipreqs/

🔰 خب بریم برای دلایل برتری این نسبت به pip freeze :


1⃣ نکته اول اینکه توی pip freeze فقط پکیج هایی که با pip install نصب شدند و وابستگی هاشون میاد.
و اگر ما بیاییم از chocolatey, conda, setuptools استفاده کنیم توی خروجی pip freeze این ها نمیان 🤨
اما خب pipreqs این محدودیت هارو نداره.


2⃣ نکته دوم اینه که pip freeze تمام وابستگی های پروژه هارو هم توی خودش ذخیره میکنه. که خب ما اصلا اون هارو به صورت مستقیم توی پروژه ایمپورت نمیکنیم.
خب این کار اشتباهی هست که در اول این متن توضیح داده بودم . اما توی pipreqs ما فقط وابستگی هایی رو نصب میکنیم که توی پروژه ایمپورت شده باشند.

🎊 حالا نمیخواد بترسید. کار با pipreqs خیلی آسونه. مثلا با دستور زیر یک فایل requirements.txt میسازه خودش .
$ pipreqs

اگر فایلش هم از قبل موجود باشه با این دستور باید انجام بدید
$ pipreqs --force

دوتا جایگزین هم برای pipreqs هست که میتونید از اون ها هم استفاده کنید .
https://github.com/jazzband/pip-tools
https://python-poetry.org

📋 نتیجه گیری :
با دستور pip freeze ممکنه در ابتدا بسیار مفید به نظر برسه، اما به دلایل زیر می تونه پروژه شما را خراب کند:
تمام کتابخانه های نصب شده در پروژه شما از جمله وابستگی ها و وابستگی های فرعی را در فایل requirements.txt تخلیه می کنه.
هنوز کتابخانه هایی را که با استفاده از pip نصب نشده اند از دست می ده.
اگر کتابخانه ای در پروژه استفاده نشه، به طور خودکار حذف نمی شه.
به دلایل ذکر شده، توصیه می شود از pipreqs استفاده کنید، یک کتابخانه پایتون که تمام مشکلات بالا را برطرف می کنه و استفاده از اون خیلی آسون تره.

🖥 @SEYED_BAX

✅ شما برای ساختن محیط ایزوله از کدوم استفاده میکنید؟
virtualenv or python -m venv or pipenv
لینک زیر رو بخونید. هر کسی دلیل خودش رو گفته. من خودم از python -m venv استفاده میکنم.
https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe

✅ The Power of Django ORM
مقاله ای در مورد جنگو از صدرا یحیی پور
در مورد Django ORM

- What is ORM
- Use Exceptions in get()
- Django connection
- Iterators
- Set The Timeout
- ORM Best Tricks
-- F() Function
-- Aggregations
-- len() or count()
-- bulk() For Ever

✔ لینک:
https://imsadra.me/the-power-of-django-orm

✅ مطلبی از دانیال کیماسی، مهندس نرم افزار از کوئرا - Django و Nextjs

ما توی کوئرا حدود یک سالی هست که از Nextjs استفاده می‌کنیم. از همون ابتدا برای integration بین Django و Next.js پکیجی رو توسعه دادیم که به تازگی داخل گیت‌هاب منتشر کردیم.
داخل این مقاله شیوه انجام این کار رو توضیح دادم و همینطور یه راهنمایی اولیه برای استفاده از این پکیج قرار داده شده.

✔ لینک مقاله در Medium:
https://medium.com/@danialkeimasi/django-next-js-the-easy-way-655efb6d28e1

✔ لینک ریپو گیت‌هاب:
https://github.com/QueraTeam/django-nextjs

برنامه نویسی از پایه قسمت پنجاه و هفتم - اعمال استایل های flex

توی این قسمت اول از همه، استایل هایی که قسمت بعدی با developer مرورگر اعمال کرده بودیم رو توی styles.css اضافه کردیم. بعد commit کردیم که توی ریپازیتوری گیت اونارو داشته باشم. بعدش تلاش کردیم که منو رو fixed کنیم و توی این مسیر نکاتی با هم یاد گرفتیم. البته یاد گرفتیم که html و css واقعا نیاز به تخصص داره و به همین دلیل هست که بعضی برنامه نویس های back-end اینقدر ازش فراری هستن. کاری که من توی 40 دقیقه انجام دادم، شاید کار 5 دقیقه یه برنامه نویس فرانت باشه. امیدوارم توی این مسیر و با همدیگه دانش خودمون در زمینه html و css بیشتر کنیم.

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

لینک یوتیوب:
https://youtu.be/ehqI1EEkPkU

یه اکشن هایی توی کد هستن که گاهی نیازه یا همه با هم انجام بشن یا هیچ کدوم.
که توی جنگو ما از #transaction_atomic واسه هندل کردنش استفاده میکنیم.
و این فقط مربوط به بخش های مالی پروژه نمیشه.
چون معروف ترین مثالی که واسه اش زده میشه مثال حساب بانکیه.
ولی شما فرض کنید که یک موجودیت teacher دارید که یک نوع از User هستش. شما واسه ساخت موجودیت تیچر ؛ اول یوزر رو میسازید ؛ بعد از اون هم تیچر رو. توی خط کد های پشت سر هم.
حالا در نظر بگیرید برنامه خط اول رو پشت سر میذاره ؛ یوزر داخل مدل یوزر ساخته میشه اما قبل از این که همین یوزر داخل مدل تیچر هم ساخته بشه ؛ کد کرش میکنه یا هر نوع اکسپشنی رخ میده.
اینجاست که شما با اطلاعات ورودی یک دیتای ناقص در دیتابیس تعریف کردید.
میخوام بگم استفاده از #transaction_atomic ها مختص شرایط خیلی خاصی نیست.
فقط کافیه یه کم راجع به ترنزکشن ها توی دیتابیس بدونید و روش استفاده ازش رو مطالعه کنید.
از لینکدین fateme Akrami

✅ شاید همگی با این جمله ی خفن و معروف آشنا باشیم .

"premature optimization is the root of All evil"

بنظر شما رانندگی با ماشین فرمول یک تو خیابون های شهر کار عاقلانه ایه؟
خب مشخصه ، نه .
پس یادمون باشه قبل هر تصمیمی برای ارتقای یک پروژه یه شاخص مهم رو در نظر بگیریم ، این شاخص چیزی نیست جز نیاز مشتری ، باید این نیاز رو پیدا کنیم .
یه سوال
از کجا بفهمیم که نیاز به improvement هست یا نه و یا ساده تر بگم چطور تشخیص بدیم که نیاز داریم ارتقا بدیم یا نه ؟ اینحاست که performance testing مطرح میشه.
بنظر من performance testing ارزش یک برنامه نویس رو نشون میده ، تنها راه مقابله با کمالگرایی بیهوده ، سدیه به نام performance testing.
ما به عنوان یک برنامه نویس قراره ارزشمون رو با پاسخ به یک نیاز نشون بدیم ، نه آب در هاون کوبیدن .
سوال بعدی، خب چطور performance testing انجام بدیم ؟
یکی از روش ها تو پروژه های جنگویی استفاده از locust هست با اینکار میتونین بفهمین که پروژتون چند مرده حلاجه و به بیانی دیگر نیاز به improvement رو تشخیص بدین .

پس یادمون نره کنار هر مهارت خفنی که یاد میگیریم در نظر بگیریم که مدیریت زمانی میکنیم و ارزش اون کار دیده میشه یا نه.

کمالگرایی آفتیه که تو باغ هر برنامه نویسی میوفته ، با locuat آفتکشی کنید .

بازم از لینکدین Erfan Aliaghdam
لینک:
https://www.linkedin.com/posts/erfan-aliaghdam-20a439204_performanceabrtesting-testing-django-activity-6955392499020349440-ktMP?utm_source=linkedin_share&utm_medium=member_desktop_web