یه مشکلی داشتم تو کدا
داشتم فکر میکردم که من این فلو رو قبلا توسعه دادم چرا قبلا مشکل نداشتم!
رفتم کدای قبلیمو خوندم دیدم عه چه راه حل خوبی برای حل این مشکل قبلا به فکرم رسیده! 😂😂
بعد به این نتیجه رسیدم گاهی آدم میتونه از کدایی که قبلا خودش نوشته چیز های خوبی یاد بگیره 🤣🤣
🆔 @CodeBazDev

وقتی یه برنامه‌نویس حرفه‌ای پایتون، کدی ببینه که کلی قانون PEP 8 رو زیر پا گذاشته، حتی اگه چیزی نگه، احتمال زیاد داره تو دلش داره غر می‌زنه 😅

بخشی از کتاب two scoops of django
#two_scoops_of_django
🆔 @CodeBazDev

💡 چرا در PEP 8 طول هر خط کد باید حداکثر ۷۹ کاراکتر باشه؟

قدیما مانیتورهای کامپیوتر خیلی بزرگ نبودن و نهایتاً فقط می‌شد ۸۰ کاراکتر توی هر خط نمایش داد. به همین دلیل برنامه‌نویس‌ها تصمیم گرفتن که طول هر خط از کدهاشون بیشتر از ۷۹ کاراکتر نباشه، تا بتونن همه خطوط رو بدون اسکرول افقی ببینن. 📱💻

اما امروزه، با مانیتورهای عریض و رزولوشن بالا، به راحتی میشه حتی ۱۲۰ کاراکتر رو توی یک خط نمایش داد. بنابراین، این مورد در PEP 8 کمی غیرمنطقی به نظر می‌رسه. 😅

با این حال، در PEP 8 گفته شده که:

"Consistency is more important than perfection."
(یکپارچگی مهم‌تر از کمال است.) 🔑

یعنی اگه در تیم شما تصمیم گرفته شده که استانداردهایی متفاوت از PEP 8 استفاده بشه، پایبندی به همون استانداردهای تیمی مهم‌تره. 🧑‍💻🤝

پس اگر محدودیت ۷۹ کاراکتر براتون اذیت‌کننده است، می‌تونید استاندارد جدیدی برای تیم‌تون وضع کنید و به اون پایبند باشید. 👌
#python #pep
🆔 @CodeBazDev

💡 بهترین راه برای یادگیری PEP ها چیه؟

برای یادگیری PEPها (Python Enhancement Proposals)، دو راه اصلی وجود داره:

1️⃣ مطالعه به ترتیب PEPها
شما می‌تونید تمام PEPها رو به ترتیب مطالعه کنید و سعی کنید مفاهیم و استانداردهای مطرح شده در هر کدوم رو به خاطر بسپارید. این روش ممکنه کمی زمان‌بر باشه، اما در نهایت با درک عمیق‌تری از زبان پایتون و اصولی که بر اون حاکمه آشنا می‌شید.

2️⃣ استفاده از ابزارهای خودکار مثل flake8
یک روش عملی‌تر اینه که از ابزارهایی مثل flake8 یا black استفاده کنید. این ابزارها به‌طور اتوماتیک کد شما رو بررسی می‌کنن و ارورها یا وارنینگ‌ها رو نشون می‌دن.
شما می‌تونید هر ارور یا وارنینگ رو بررسی کنید و بفهمید که مربوط به کدوم PEP هست. این روش به شما کمک می‌کنه که یاد بگیرید کد شما چطور باید استانداردهای PEP رو رعایت کنه و در نهایت خودکار به یک کدنویس پایتون حرفه‌ای تبدیل بشید.

🔧 مزایای روش دوم:

✅ بررسی خودکار کد
✅ آشنایی با ارورها و هشدارها به‌صورت عملی
✅ سرعت بیشتر در یادگیری استانداردهای پایتون

هر دو روش مفیدن، اما استفاده از ابزارهای خودکار معمولاً سرعت یادگیری رو بالا می‌بره و شما رو در مسیر بهینه‌تری قرار می‌ده. 🚀
#python #pep
🆔 @CodeBazDev

کوه یخ یادگیری جنگو به روایت تصویر.

@normal_developer

دوستان کانال خوبیه جوین شید ضرر نمیکنید 😊👆

🚨 نگاهی به یکی از ارورهای کار با pip freeze 🚨

در حین توسعه پروژه، ممکنه تعدادی پکیج نصب کنید. وقتی دستور
pip freeze
رو وارد می‌کنید، یک لیست بلند از پکیج‌ها نمایش داده میشه. اما سوال اینجاست:

چرا بعضی از پکیج‌ها به نظر شما ناشناخته‌اند؟ 🤔
دستور pip freeze تمام پکیج‌های نصب‌شده رو نمایش می‌ده، حتی پکیج‌هایی که به‌طور خودکار نصب شدن! این یعنی ممکنه ۲۰ پکیج ببینید، ولی فقط ۷ تا از اون‌ها رو بشناسید. 😯

این پکیج‌ها از کجا اومدن؟
این پکیج‌های اضافی، وابستگی‌های پکیج‌هایی هستن که شما نصب کردید. برای مثال، وقتی Django رو نصب می‌کنید، pip به‌طور خودکار پکیج‌هایی مثل pytz یا sqlparse رو هم نصب می‌کنه. این‌ها وابستگی‌ها هستن که برای عملکرد Django ضروری هستن، ولی شما مستقیماً اون‌ها رو نصب نکردید. 📦

مشکلات هنگام انتقال پروژه به سیستم دیگه
حالا فرض کنید پروژه‌ای دارید که روی سیستم خودتون اجرا شده، ولی می‌خواهید پروژه رو روی یک سیستم دیگه اجرا کنید. با دستور
pip install -r requirements.txt
ممکنه با ارورهای عجیبی مواجه بشید که مثلا می‌گه فلان پکیج پیدا نمی‌شه یا نصب نمی‌شه. 😣

چرا این ارورها پیش میاد؟
این پکیج‌ها وابستگی‌های غیرمستقیم هستند. مثلاً در سیستم لینوکس شما از psycopg2 برای اتصال به PostgreSQL استفاده کردید، اما در ویندوز ممکنه pip به‌جای اون، psycopg2-binary رو نصب کنه، چون این نسخه برای ویندوز مناسب‌تره. پس ممکنه با ارور مواجه بشید چون نسخه‌های متفاوت برای سیستم‌های مختلف استفاده میشه. 💻🖥

نتیجه‌گیری
برای جلوگیری از این مشکلات، پیشنهاد می‌کنم از ابزارهایی مثل pip-tools یا Poetry استفاده کنید که وابستگی‌ها رو دقیق‌تر مدیریت می‌کنن. همچنین فقط پکیج‌های ضروری رو در requirements.txt قرار بدید تا از اضافه شدن وابستگی‌های غیرضروری جلوگیری بشه. ✅

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

#python #pip
🆔 @CodeBazDev

🐍 چرا زبان پایتون اسمش شد پایتون؟

شاید براتون جالب باشه که اسم زبان برنامه‌نویسی پایتون ربطی به مار پایتون نداره! 😄

در واقع، این نام از یک کمدی تلویزیونی بریتانیایی به نام "Monty Python's Flying Circus" گرفته شده. این برنامه توسط گروه کمدی معروف Monty Python ساخته شده بود که به خاطر طنز خاص و نگاه متفاوتش به دنیای اطراف شناخته می‌شه.

👨‍💻 گیدو ون راسوم، خالق زبان پایتون، زمانی که در حال انتخاب اسم برای زبان جدیدش بود، تصمیم گرفت نام پایتون رو از این برنامه کمدی بگیره چون خودش طرفدار این گروه بود و از سبک شوخ‌طبعی و نگاه متفاوتشون الهام گرفت.
#python
🆔 @CodeBazDev

چرا فریمورک جنگو اسمش شد django؟

نام جنگو (Django) برای فریمورک محبوب پایتون از دنیای موسیقی آمده است! 🎵

در واقع، این نام از "Django Reinhardt" (بخوانید: جنگو راینهارت) گرفته شده، که یکی از بزرگ‌ترین و معروف‌ترین نوازندگان گیتار جاز در تاریخ موسیقی است. 🎸

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

به همین دلیل، فریمورک جنگو نه تنها یک ابزار قدرتمند برای توسعه وب است، بلکه نام آن به نوعی به آزادی و خلاقیت در کدنویسی و طراحی وب اشاره دارد. 🚀

پس دفعه بعد که با جنگو کار می‌کنید، شاید بخواهید همزمان یکی از قطعات جنگو راینهارت را هم گوش بدید! 🎶

پ.ن: اگه دقت کنید دو انگشت کوچکتر دست چپ ایشون مشکل داره. این دو انگشت در یک آتش‌سوزی آسیب دیده و نکته جالب در مورد ایشون اینه که با وجود این ضایعه قطعات دشوار و پیچیده جاز رو اجرا میکردن

#django
🆔 @CodeBazDev

در ادامه این پست که ریپلای کرده ام ...

📏 حداکثر طول خطوط در پایتون طبق PEP8 و کتاب Two Scoops of Django:

🔹 من با خوندن داکیومنت رسمی PEP8 و بخش 1.2.1 کتاب Two Scoops of Django به این نتیجه رسیدم:

✅ در پروژه‌های اپن‌سورس:
حداکثر طول هر خط کد باید ۷۹ کاراکتر باشه.

✅ در پروژه‌های شخصی یا تیمی (غیراپن‌سورس):
می‌تونید این محدودیت رو تا ۹۹ کاراکتر افزایش بدید،
💬 به شرطی که همه اعضای تیم باهاش موافق باشن.

✅ برای docstringها و commentها (توضیحات):
چه پروژه اوپن‌سورس باشه، چه نباشه،
🔸 حداکثر طول باید ۷۲ کاراکتر بمونه.
این باعث می‌شه متون طولانی در ادیتورها به شکل منظم و خوانا شکسته بشن.

🧠 نکته مهم ۲:
این قوانین نه‌تنها ظاهر کد رو مرتب نگه می‌دارن،
بلکه همکاری تیمی و code review رو هم خیلی راحت‌تر می‌کنن!

🧠 نکته مهم ۲:
امریک آگوستن از توسعه دهندگان هسته جنگو میگه پایبندی به این محدودیت‌ها نباید انتخاب نام‌های کوتاه و ناخوانا رو برای متغیر ها، توابع و ... توجیه کنه. یعنی به هر حال باید اسم های انتخابی مون معنی دار باشن

📌 شما از کدهای ۷۹ کاراکتری استفاده می‌کنید یا ۹۹ کاراکتری؟
نظرتون رو برام بنویسید 👇
#two_scoops_of_django #pep #pep8
🆔 @CodeBazDev

استفاده از

import *

به چند دلیل بده!

یکی از این دلایل تصادف نام‌ها یا Name Collisions نام داره.

فرض کن در یک فایل جنگو می‌خوای هم از فرم‌ها استفاده کنی، هم از مدل‌ها

# ANTI-PATTERN ❌
from django.forms import *
from django.db.models import *

class MyForm(Form):
    name = CharField()

💥 الان مشکل چیه؟
هم django.forms و هم django.db.models کلاسی به اسم CharField دارن!
چون تو import * کردی، آخرین CharField که وارد شده (models.CharField) جایگزین forms.CharField شده.

نتیجه؟ فرم به جای یک فیلد فرم معمولی، داره یه فیلد مدل استفاده می‌کنه! 🤯

نسخه صحیح

from django import forms
from django.db import models

class MyForm(forms.Form):
    name = forms.CharField()

🔐 اینطوری هم کد خواناتر و ایمن‌تره، هم هیچ نامی روی دیگری تاثیر نمیذاره

شما چه مشکلات دیگه ای در مورد استفاده از import * سراغ دارید؟ کامنت بذارید 😁

#python
🆔 @CodeBazDev

فقط من از دیدن اکی های سبز migration جنگو خوشم میاد یا شما هم اینطوری اید؟ 😂
#django
🆔 @CodeBazDev

کدام سناریو درست تره؟

سناریو اول
استفاده از SQLite در development و postgres در production

سناریو دوم
استفاده از postgres هم در development و هم در production

ببینید postgres و sqlite تفاوت هایی تو عملکردشون دارند. به صورت خلاصه، sqlite خیلی شما رو در قید و بند نمیذاره اما postgres رو خیلی از قوانین حساس تر از sqlite عمل میکنه.
همین باعث میشه شما تو development روی sqlite اروری نبینی اما روی production ببینی!
در این مورد به زودی یه مقاله مینویسم و به تفصیل توضیح میدم
🆔 @CodeBazDev

چند سال پیش توی یک شرکت کار میکردم که چند محصول نرم‌افزاری داشت.
پلفرم A یک پلتفرم گردشگری بود که من با django و react و postgres داشتم توسعه اش میدادم.
پلفرم B هم یک پلفرم رزرو آنلاین وقت دکتر بود (شبیه اسنپ‌دکتر یا تپسی‌دکتر) که یک تیم دیگه با node js و vue و mysql توسعه داده بودند.

تو پلتفرم A ما نقش های تورلیدر و مسافر رو داشتیم و تو پلتفرم B نقش های دکتر و بیمار

از اونجایی که این نقش ها خیلی شبیه به هم بودند، یه روز مدیر عامل پیشنهاد داد چی میشه اگه پلتفرم B رو بیاریم در دل A بگنجونیم. اینطوری که پزشک اسمش عوض بشه به تورلیدر و بیمار هم اسمش عوض بشه به مسافر!

خیلی ایده قشنگی بود ولی ما مخالفت کردیم چون این دو تا محصول با دو تا تکنولوژی خیلی متفاوت توسعه داده شده بودند. هر طوری فکر میکردیم میدیدیم نمیشه به راحتی این دو رو با هم مرتبط کرد.

اولین ایده ای که به ذهنم رسید این بود که برم node js و vue یاد بگیرم.

این ایده رو امتحان کردم. یه مقدار که با پروژه دست و پنجه نرم کردم دیدم من حتی اگه node و vue هم یاد بگیرم بعدش باید ببینم برنامه‌نویسان قبلی تو این پروژه چه کرده اند. آخه پروژه B خودش دو سه سالی توسعه اش طول کشیده بود برای همین دو سه بار معماری عوض کرده بودند و دست خط های مختلفی از برنامه‌نویس های مختلفی توش دیده میشد. هر جای پروژه یه قانون خاصی برای خودش داشت. مثلا داشبوردش با ین منطق متفاوتی از فرانتش کار میکرد در صورتی که هر دو هم node و vue بودند.

یه مقدار بیشتر که R&D کردم با معجزه ای به نام inspectdb در جنگو آشنا شدم.
این دستور میتونه از روی جداول دیتابیس، براتون مدل بسازه

میدونستم که جنگو میتونه همزمان چندین دیتابیس رو مدیریت کنه. پس دست به کار شدم و دیتابیس mysql رو به پروژه خودم وصل کردم.
بعد یه اپ جدید ساختم و با استفاده از inspectdb مدل ها رو از روی دیتابیس ساختم.

بعد از اینم دیگه همه چی برام روال شد. دیگه هر دیتایی میخواستم با orm جنگو کوئری میزدم. حتی میتونستم با drf براش api بنویسم.

خلاصه:
با دستور inspectdb به راحتی هر دیتابیسی رو به مدل تبدیل کنید و بعد با orm هر طور میخواهید باهاش کار کنید.

پ.ن: فقط مشکلش این بود که نمیشد روش migrate زد. اگه گفتید چرا؟ 😊
#django
🆔 @CodeBazDev

به نظرتون کلاس بالایی بهتره یا پایینی؟
پاسخ رو بعد از نظر سنجی زیر بخونید
#pep8
🆔 @CodeBazDev

یه چیز خوبی که مهندس دلشاد، مدیرم سالها قبل یادم داد این بود که تو نامگذاری از قانون prefix استفاده کنم.
البته ایشون اسمش براش نذاشته بود من اسمش رو میذارم prefix
این قانون میگه که همه
- پوشه های کنار هم
- فایل های کنار هم
- توابع کنار هم
- متغیر های کنار هم
- و ...
که یه بخش یکسان تو اسمشون هست، اون بخش یکسان رو اولش بنویس
اینطوری چشم سریع تر پیداش میکنه

تو این عکس اپ مورد نظرتون رو از سمت راست سریع تر پیدا میکنید یا از سمت چپ؟
#djangop #pep8
🆔 @CodeBazDev