در این ویدیو از پلی‌لیست نکته ها و ترفندهای پایتون به بررسی مدیریت پکیج‌های پایتون با استفاده از Poetry پرداختیم.
Poetry یک ابزار مدیریت وابستگی‌ها و پروژه‌های پایتون است که به شما کمک می‌کند تا به راحتی و به صورت مدرن با محیط توسعه وابسته‌های پروژه‌های خود را مدیریت کنید. این ابزار امکاناتی مانند مدیریت و نصب وابستگی‌ها، ساخت محیط‌های مجازی، مدیریت ورژن‌ها و ... را فراهم می‌کند.
در این ویدیو ابتدا برخی از مشکلات pip را بررسی و سپس Poetry را نصب و با آن یک پروژه ساختیم و در نهایت پروژه خودر PyPi منتشر کردیم

Link : https://youtu.be/UX5O7Z0aQb8

playlist: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwZcy2wRRBNqXZP8wf--TmF


〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

✅معرفی چند ویرایشگر متن (rich-text editor) در جنگو
از لینکدین علی بیگدلی

خیلی پیش میاد در پروژه هایی که مبتنی بر render هستش بخواید از یک ویرایشگر متن خیلی خوب برای تولید محتوا استفاده کنین. تمام ویرایشگر های متنی خصوصیت های مشترکی دارن منتهی بعضی هاشون توی ساز و کار جنگو بهتون قابلیت آپلود عکس و در کل کار با media ها رو هم فراهم می کنن و جایگاهشون خاص تر میشه.

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

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

- django-ckeditor
- django-froala-editor
- django-summernote
- django-quill
- django-tinymce

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

انتخاب خودم:
من به شخصه بیشتر از ckeditor استفاده می کنم به خصوص اینکه پشتیبانی از آپلود فایل رو هم داره
انتخاب خودم (جنگولرن): django-tinymce

✅ویدئوی مصاحبه ام با علی بیگدلی پیرامون طراحی فروشگاه اینترنتی با جنگو
در مورد موضوعات زیر صحبت شد:
-ساختار اپ ها
-درگاه های پرداخت
-بکاپ
-اولویت های طراحی
-فیلدهای بیس محصول
و مسائل دیگه
لینک:
لینک مکتب خونه

قبل از همه اینها. عیدتون مبارک 🎉🎉🎉

تو جنگو هیچوقت از .save() خالی استفاده نکنید موقعه آپدیت کردن. چون هرچی تو مموری باشه فلاش میکنه به دیتابیس. پس بهتره explicit باشین و بگین چی میخواین فرستاده شه سمت دیتابیس. یک مثال عینی میزنم که متوجه شین یعنی چی این جمله.

ببین فکر کن یک مدل داری با ۳ تا فیلد

MyModel
- id
- first_name
- last_name

که دو تای پایینی nullable هستن. رکورد ایدی اول تو دیتابیس هم first name اش null هست هم last name اش. من ۲ درخواست همزمان میدم. درخواست اول first name رو مانی میکنم. درخواست دوم last name رو مظفر.
اتفاقی که میفته اینه که اول از دیتابیس MyModel رو میخونه جفت درخواستا. برای جفتشون first_name=None و last_name=None هست. بعد هرکدومشون همچین query ای میزنن:

درخواست اول:

// model.first_name = "Mani"
// model.save()
UPDATE MyModel
SET first_name = 'Mani', last_name = NULL
WHERE MyModel.id = 1

درخواست دوم:

// model.last_name = "Mozaffar"
// model.save()
UPDATE MyModel
SET first_name = NULL, last_name = 'Mozaffar'
WHERE MyModel.id = 1

دیدی چی شد؟ جفتشون یک NULL هم فرستادن سمت دیتابیس. چرا؟ چون تو مموری یکی از نام و نام خانوادگی null بود و وقتی .save رو میزنی همونو میفرسته به دیتابیس.
بنابراین یا first name نال میمونه یا last name. در صورتی که درستش اینه:

// req 2
UPDATE MyModel
SET last_name = 'Mozaffar'
WHERE MyModel.id = 1

// req 1
UPDATE MyModel
SET first_name = 'Mani'
WHERE MyModel.id = 1

معادل orm اش چی میشه؟

# req 1
MyModel.object.filter(id=instance.id).update(last_name="Mani")

# req 2
MyModel.object.filter(id=instance.id).update(last_name="Mozaffar")

# OR...
mymodel.save(update_fields=['first_name'])

@PyBackendHub

✅سوال: چرا توی جنگو به app ها نیاز داریم؟ یا چه مواقعی اپ بسازیم؟

✔️یه نفر توی forum جنگو سوالاتی در این زمینه پرسیده و developer ها که از سازنده های جنگو هم هستن جواب دادن

لینک:
https://forum.djangoproject.com/t/why-do-we-need-apps/827

✅نکاتی در مورد سشن و سریالایز در جنگو

بخشی از آپدیت جدید دوره فروشگاه اینترنتی با جنگو. این قسمت در مورد موارد زیر صحبت شد:
✔️سبد خرید
✔️دکوریتور required_post
✔️سریالایز و دی سریالایز چیه؟
✔️فرمت json چیه؟
✔️نکاتی در مورد سریالایزر کردن آبجکت ها در جنگو
✔️مشکل امنیتی pickle در پایتون
و غیره

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

هر انتقاد یا پیشنهادی به این قسمت دارید به @miladhzz پیام بدید
تشکر

✅چرا داکیومنت نویسی مهم می‌شه؟
از کانال @tobecomesoftwareengineer

فرض کنید ما میخوایم یه غذای خوشمزه طبخ کنیم. در پختن این غذا. نوع ادویه، ظرف مناسب، میزان مختلف مواد و ... اهمیت پیدا میکنه و ما باید یه جایی مستند شده اونا رو داشته باشیم و هم تغییری در فرمول غذا ایجاد شد که اون رو خوشمزه تر کرد، ما به شکل بصری داشته باشیم.

نرم افزار هم همینه. سیستم نرم افزاری ما قسمت های مختلفی داره، مثل کلاسهای مختلف و این کلاسها با هم ارتباط دارن و دارن با هم یه کاریو انجام میدن.
حالا فرض کنید ما یه سیستم نسبتا بزرگی داریم که پیچیدگی های خاص خودشو داره و این سیستم رو خیلی سال پیش با زبانی مثل perl پیاده کردن و الان با توجه به این که سیستم ما یه سیستم legacy محسوب میشه می‌خوان اون رو به زبان سیشارپ یا پایتون، باز-مهندسی کنن (re engineering).

اگر نرم افزار قدیمی داکیومنت نشده باشه طبیعتا این کار محاله و با مشکلات خیلی خیلی زیادی ما رو مواجه میکنه‌.
وجود یه شخصی که متخصص داکیومنت سازی نرم افزاره در هر شرکتی لازمه. چون هر بار که نرم افزار اپدیت میشه باید داکیومنت هم اپدیت شه.
داکیومنت نویسی طبیعتا در سطوح مختلفی از abstraction انجام میشه اما خب اون داکیومنت نویسی معتبره که خیلی concerete باشه یعنی ریز به ریز سیستم رو با جزئیات داکیومنت کرده باشه که صد البته یه تیم باید این کارو انجام بده چه از ابزار استفاده کنه و چه به شکل دستی کار رو تموم کنه.
معمولا با دونستن زبان UML و BPMN این کار شدنیه.
این دیاگرام ها در هنگام باز-مهندسی کردن سیستم قدیمی به شکل مهندسی-معکوس مورد استفاده قرار میگیرن و با ابزارهای تولید کد، کد نهایی رو تولید میکنن که با صرفه جویی زیادی در وقت و هزینه به تیم نرم افزاری کمک میکنن.

سلام!

مانی هستم, فاندر دو تا استارت آپ, از سال 2020 برنامه نویسی میکنم, از همون روز اول, از اولین تابعی که نوشتم برای پروژه استارت آپم بوده تا 2023. اواسط سال 2023 تصمیم گرفتم که کار شرکتی انجام بدم, برای همین الان تحت پوزیشن software engineer مشغول هستم.


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

تجربه پایتون خیلی زیادی ندارم, شاید خیلیا تجربه پایتونشون بیشتر باشه, اما تصمیم گرفتم همین تجارب کمم رو هم به اشتراک بذارم, امیدوارم مطالب کانال براتون مفید باشه و سمی نباشه 😅 کنار پایتون به web scraping و تست نویسی و اصول توسعه نرم افزار و بقیه بحث ها هم میپردازم, پس کانال فقط مربوط به پایتون نخواهد بود.

یوتیوب من:
https://www.youtube.com/@GitOverHere

لینکدین من:
https://www.linkedin.com/in/manimozaffar/

گیت هاب من:
https://github.com/manimozaffar


@ManifoldsPython

✅رمز موفقیت مانی رو ازش پرسیدم:
بازم تشکر از مانی

سوالات من:
1.توی این مدت چند زبان برنامه نویسی کار کردی؟
2.بیشتر تمرکزت روی چی بوده؟
3.آیا بهتره تمرکز کنیم روی یه زبان / استک / تکنولوژی؟

پاسخ های مانی:
صرفا زیاد تمرین میکنم و سعی میکنم بروز باشم و مباحث جدید رو سریع یاد بگیرم.
۱. تخصصی فقط پایتون. ts و راست هم یک سرکی زدم. البته تو پروژه هام استفاده نکردم. صرفا تمرین طوری بود جفتشون.
۲. بک اند و مهندسی نرم افزار. تمرکزم رو این بوده که بفهمم دارم چیکار میکنم همین. مثلا سلری استفاده میکنم چه اتفاقی میفته. یا kafka چطوری کار میکنه. پارتیشن هاش چین. چطوری scale میشه. چطوری rebalance میشه . چطوری مسیج رو produceمیکنه و لاگش چیه و ... . همین سوالات راجب دیتابیس و پایتون و ... . کلا هرچیزی باهاش سروکار دارم سعی میکنم درکش کنم تا یک لایه ای که چطور کار میکنه.
۳. بستگی داره. بنظرم به محیط کار کاملا بستگی داره. هرچی تو محیط کار داره استفاده میشه طبیعیه ادم بخواد دیپ تر شه توش. میخواد بروکر kafka یا rabbitmq باشه. میخواد کلاد باشه (aws/gcp/...) یا هر استکی. چون بهترین موقعیته برای دیپ شدن تو اون بحث. چون میتونی راحت تمرینم کنی و مشارکت کنی و از دانشت استفاده واقعی ببری و چالش های واقعی رو باهاش حل کنی.

من محمد عباسی (@abbasi_ai)

یک توسعه دهنده پایتون هستم با بیش از ۸ سال تجربه کار با پایتون (البته زمانی که دارم این پست رو می‌نویسم و باقی موارد تجربیاتم هم برای این کانال اهمیتی نداره)

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

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

ازین به بعد قرار هست اینجا در مورد core python صحبت کنم تا اینطوری بتونم به دوستانم هم کمک کنم و نیازی هم به تکرار‌های مجدد نباشه.

هیچکدوم از موارد رو از خودم نمی‌گم (مگر با #نظر_شخصی علامت گذاری بشه) منابع همه صحبت‌ها داکیومنت‌ اصلی پایتون و کتاب‌های معروف پایتونی هست.

LinkedIn Profile

@pyHints

چرا جنگو‌ فریمورک محبوبی هست؟؟؟

بیاید یکم راجبش حرف بزنیم

جنگو‌ خیلی از موارد برنامه نویسی مدرن رو براتون فراهم میکنه بدون اینکه خودتون راجبش حتی دانش کافی داشته باشید و بدونید، که میتونیم به design patterns و clean architecture اشاره کرد

بارها به بچه‌ها گوشزد کردم که business logic رو فراموش نکنید و جدی بگیرید ،کار سختی نیست یک فایل با نام services.py بسازید و موارد مربوط به orm رو داخلش بنویسید (یک دایرکتوری با نام services بسازید و ماژول‌های پایتونی خودتون رو داخلش بزارید) حالا کافیه با dependency inversion principle رو بدونید و داخل کدهاتون رعایت کنید

خب چه اتفاقی افتاد؟؟؟
الان شما اومدین و app رو به سه لایه تقسیم کردید لایه application ، لایه service ، لایه infrastructure , خب این چه مزیتی داره برامون

بیایم ببینیم هر لایه شامل چه چیزی میشه؟؟؟

Application: urls, views
درخواست‌های مشتری در این قسمت مورد پردازش قرار میگیره که داده‌های مورد نیاز رو از لایه service میگیره و اون رو تبدیل میکنه به مقداری که قابل خوندن واسه مشتری هست که میتونه http, drf, grpc و ... باشه


Service: 
این لایه همون مبحث business logic رو ارائه میده و تمام موارد مورد نیاز رو در خودش هندل میکنه(وظیفه ذخیره و بازیابی موجودیت‌هارو برامون هندل میکنه) اینجا orm django کار میکنه لایه انتزاع از دیتابیس رو میسازه و بواسطه شی گرایی مارو از پیچیدگی کار رها میکنه

Infrastructure: migrations , models
تو این قسمت شما موجودیت‌ها و مجموعه‌ها رو در یک سیستم ذخیره ساز، ذخیره میکنید ،اینکار با استفاده از مدل‌های جنگو و queries صورت میگیره ، بخش مایگریشن‌ها هم اینجا صورت میگیره 

من این همه سردرد رو واسه چی دارم تحمل میکنم خدایی؟؟؟

شما دارید ذره ذره به سمت bounded context ها میرید

خب اینکه گفتیم به چه معناست اصلا؟؟
نکته: ما همیشه میگیم تسک بزرگ رو به چند تسک کوچیکتر بشکنید (بصورت منطقی البته) یک کلاس بزرگ ننویسید یک تابع طولانی نسازید

ما اینهارو‌ رعایت کردیم به کجا داریم میرسیم؟؟؟
جالبه بدونید که داریم به سبک معماری DDD نزدیک میشیم

بیایید ادامه بدیم
خب اصل SoC میاد وسط(پروژه میتونه به بخش‌های کوچکتر و قابل مدیریت تر تقسیم بشه، اجزا میتونه میکروسرویس یا ماژولهای مستقل در یک مونولیت باشند)
همین ترکیب بالا رو بزاریم داخل microservice ، پروژه خودمون رو به چند سرویس منطقی و درست تقسیم کنیم، مدلهای هر سرویس رو داخل یک دیتابیس جدا بزاریم ، FKهای مدل رو به Bigint تبدیل کنیم ارتباط‌ بین سرویس‌ها رو مدیریت و هندل کنیم (اینجا rabbitmq سلام میرسونه) الزامات سرویس‌های بیس رو انجام بدیم (این شد bounded context)

چه اتفاقی داره میافته ؟؟؟

هر بخش داره بصورت مستقل توسعه داده میشه 

نگرانی حاصل از پیچیدگی داره رفع میشه

بهبود توسعه کد و پایداری داره بخوبی اتفاق میافته

پایگاه داده از شکستن داره خارج میشه

به معماری DDD خوش آمدید
این معماری برای پروژه‌های بزرگ مناسبه و اگر یک پروژه قدیمی با حداقل 20 app دارید لازم نیست تعطیلش کنید فقط کافیه با DDD تبدیلش کنید

یک معماری میکروسرویس پیاده سازی کنید

که شامل چند سرویس میشه 

هر سرویس در دل خودش چندتا app داره

 هر app طبق DDD به سه لایه application , services , infrastructure تقسیم میشه و دیتابیس خودش رو داره

خود جنگو براتون clean architecture رو تا سطح بالایی براتون اتخاذ میکنه 

در کدهاتون dependency inversion principle رو رعایت کنید

@code_crafters

چقدر باحال. mysql تعداد اتفاق افتادن ارورهاش از زمان استارت شدنش ذخیره میکنه. خیلی باحال به درد مانیتورینگ میخوره
داخل تیبیل
performance_schema.events_errors_summary_global_by_error
نگاه کنید.

تلک القضیة - حمایت از مردم فلسطین

🔸 فصل : سوّم
🔸 جلسه : چهارم
🔸 عنوان دوره : صفر تا قهرمانیِ پایتون 
🔸 عنوان جلسه : مفهوم iterable در پایتون

👨‍💻👩‍💻 وبسایت : izlearn.ir

🔸 فصل : سوّم
🔸 جلسه : پنجم
🔸 عنوان دوره : صفر تا قهرمانیِ پایتون 
🔸 عنوان جلسه : مفهوم mutable در پایتون

👨‍💻👩‍💻 وبسایت : izlearn.ir

https://github.blog/2015-06-08-how-to-undo-almost-anything-with-git/

این مقاله رو حتما توصیه میکنم بخونید. به شدت کاربردیه.
@PyBackendHub

سری مهندسی نرم‌افزار: پست 9
از لینکدین Saeed Shahrivari Joghan
اسکرام: قدیمی، سبک، پر حاشیه

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

من همیشه اولین چیزی که راجع به اسکرام متذکر میشم چارچوب بودن اسکرامه. اسکرام بنابر تاکید آقایان شوئبر و ساترلند یه چارچوبه. در دنیای کامپیوتر چارچوب چیزیه که شما کارتون رو روی اون می‌سازید بنابراین قواعد و کلیاتش رو نمیشه عوض کرد. هر چند چارچوب رو میشه توسعه داد ولی تغییر چارچوب کار غلطیه و نباید تغییرش داد. مولفه‌های اصلی چارچوب اسکرام این موارد هستند:
◀️ نقش‌ها: توسعه‌دهندگان، اسکرام مستر، مالک محصول
◀️ ایونت‌ها: اسپرینت، جلسه پلنینگ، جلسه دیلی، جلسه ریویو، جلسه رترو
◀️ آرتیفکت‌ها: بک‌لاگ محصول، بک‌لاگ اسپرینت، اینکرمنت (همون خروجی اسپرینت)
اگه شما هر کدوم از این موارد رو حذف کنید چارچوب رو بهم زدید و دیگه اسکرام نیستید. مثلاً اگه دیلی رو برگزار نمی‌کنید شما از چارچوب تخطی کردید یا اگه آیتم‌های بک‌لاگ سایزبندی و اولویت‌بندی ندارند شما از اسکرام تبعیت نمی‌کنید. آخرین راهنمای رسمی اسکرام چیزی حدود ۱۵ صفحه است و از این نظر اسکرام خیلی چیز سنگینی نیست پس لطفاً یه بار همگی به دقت بخونیمش و رعایتش کنیم اگه هم ازش خوشمون نمیاد به جای اینکه توش دست ببریم و با کارهایی مثل حذف نقش «مالک محصول» که شاکله اسکرام رو بهم می‌زنه، بهتره بذاریمش کنار و بگیم که اسکرام نیستیم. در این پست صرفاً من راجع به مهمترین نکته‌ در اسکرام از دید خودم یعنی «چارچوب بودن اسکرام» صحبت کردم. در پست بعدی انشالله راجع به یک‌ سری اشکالات رایج وارد و غیر وارد به اسکرام صحبت می‌کنم.

✅توی تنظیمات جنگو به صورت پیشفرض 4 تا context processor فعال هست:

'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages'

✔️اولویت همیشه با آخری هست (برخلاف urls ها ) یعنی اگه یه پروسسور مقداری رو به کانتکس اضافه کنه که توی بعدی هم باشه. override میشه.
✔️به صورت پیشفرض یه پروسسور به اسم django.template.context_processors.csrf هم وجود داره که هارد کد شده.
✔️ما میتونیم پروسسور اختصاصی خودمون رو بسازیم. دیتایی که processor میسازه توی همه template ها در دسترس هست.

✅چرا django shell ؟

اگه توی فولدر پروژه جنگو باشید و دستوری مثل

 from shop.models import Product 

رو توی پایتون اجرا کنید. خطای زیر رو احتمالا می گیرید:

django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

✔️ولی وقتی django shell رو اجرا می کنیم. خودش DJANGO_SETTINGS_MODULE رو توی environment variable ست میکنه.

لینک زیر هم بیشتر توضیح داده:
https://stackoverflow.com/a/23157955/7547739

در دنیا ما دو نوع scale کردن وجود داره، horizontal و vertical اما فرقشون چیه؟

خیلی ساده:
horizontal: سرور جدید اضافه کردن

vertical: سخت افزار سرور ارتقا دادن


خوبی‌های هر کدوم چیه؟
horizontal:
1. پرفورمنس داخل سیستم‌های distributed یا همون توزیع یافته بهتر میکنه
2‌. در دسترس بودن سیستم بیشتر میکنه، اگه یک node بیا پایین بقیه میتونن جاشو بگیرن یا یک instance جدید ازش بالا میارن
3. راحت میشه با رشد یوزر، سیستم هم ارتقا داد
نکته: بیشتر به درد شرکت‌های بزرگ با تعداد یوزر بالا خواهد خورد

vertical:
1. بسیار راحت تره از چیزی مثل horizontal
2. هزینه کمتری نصبت به اون یکی داره

نکته: بیشتر به درد بیس‌های کوچیک میخوره که هزینه زیادی نمیخوان انجام بدن و رشد یوزر خیلی عجیبی ندارن


مطالعه بیشتر:
https://www.cloudzero.com/blog/horizontal-vs-vertical-scaling/

@TorhamDevCH