✅معرفی پکیج های پایتونی

فروشگاه saleor یه نسخه قدیمی داره که دیگه آرشیو ش کرده.
من یه فورک ازش گرفتم توی این آدرس:
https://github.com/miladhzz/saleor-old

فایل requirements.txt رو که دیدم، پکیج های خیلی زیادی توش بود.
از ChatGPT کمک گرفتم و خواستم کار هر کدوم رو در یک جمله کوتاه بگه
خروجی ChatGPT رو عینا توی پست های بعدی قرار میدم.

آپدیت: یکی از دوستان زحمت کشید و pdf ش کرد. پست بعدی

لیست همه پکیج های استفاده شده در فروشگاه اوپن سورس saleor نسخه قدیمی تمپلت
در قالب pdf
تشکر از Arash

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

⚠️خواهشا ردیس را به عنوان Primary Database استفاده نکنید!

از لینکدین Hasan Arab borzo
✔️کامنت هاشم بخونید. لینک این مطلب

💥 یکی از جذاب‌ترین ریفکتور هایی که در اکالا انجام دادم، به ریلیز کردن ۴۰ گیگابایت رم ردیس برای استفاده در سبد خرید و سفارش‌ها مربوط میشه. در این فرآیند، موفق شدم تنها از ۴۰۰ مگابایت رم استفاده کنم!
در شروع کار، به این فکر می‌کردم که چگونه می‌توانم ۴۰ گیگابایت رم را آزاد کنم. اولین راه‌حلی که به ذهنم رسید، فشرده‌سازی داده‌ها بود. اما هیچ کامپرسوری نمی‌توانست به اندازه کافی این حجم داده را فشرده کند، و هزینه‌ی Decompress کردن آن بخاطر لود بالای سیستم، بسیار بالا بود.

🤔 هر کلید ما حاوی حدود ۱-۲ کیلوبایت JSON بود و مجبور بودیم که هر محصول را بدون TTL در Redis نگه داریم، زیرا Round Trip ما به Redis در لحظه به حدود ۳۰K می‌رسید و Redis ۴۰ گیگابایتی را مصرف می‌کرد. هیچ اپلیکیشنی نمی‌توانست این حجم Request را با منابع پایین و زمان پاسخ‌دهی ۱۰ میلی‌ثانیه انجام دهد!
در ادامه، وقتی وارد فضای حل مسئله شدم:

💡 پاک‌سازی داده‌های اضافی: اولین قدم ما حذف کلی داده‌های غیرضروری بود که هر کلید را به حدوداً ۵۰۰ بایت تبدیل کرد.

💡 استفاده از Protobuf: به این فکر کردم که چرا از JSON استفاده کنیم؟ با استفاده از deserializer و serializer قدرتمندی مثل Protobuf، می‌توانستیم حجم داده‌ها را به طور چشمگیری کاهش دهیم. با تبدیل داده‌ها به باینری و ذخیره آن، حجم هر کلید به حدود ۳۰۰ بایت کاهش یافت، که به معنای کاهش ۸۰ درصدی مصرف رم بود. با این حال، کیفیت و سرعت بالا در اکالا برای ما بسیار مهم بود.

💡 شکستن کلیدها: کلیدها را به دو بخش تقسیم کردم:
اطلاعات محصول (شامل نام، بارکد، آدرس عکس و...) در یک کلید با حجم تقریباً ۲۰۰ بایت.
موجودی هر محصول در فروشگاه‌ها در کلیدی دیگر با حجم حدود ۱۰۰ بایت.
در روش قبلی، اگر یک میلیون کالا داشتیم، مصرف حدود ۲۸۶ مگابایت بود. اما در روش جدید، فرض کنیم از یک میلیون تا 2000 محصول داریم و برای یک میلیون کالا موجودی در استور های مختلف، حدود ۹۵ مگابایت مصرف می‌شد!

💡 کش کردن محصولات: همچنین، کالاهای اضافه‌شده به سبد خرید مشتریان را به مدت ۴ روز کش کردم. به جای استفاده از Redis به عنوان Primary Database و بدون TTL، هرگاه داده‌ای نداشتیم، از منبع اصلی اطلاعات را می‌گرفتیم و دوباره به مدت ۴ روز کش می‌کردیم. اگر کاربری همان کالا را دوباره به سبد خرید اضافه می‌کرد، TTL آن به صورت Sliding افزایش می‌یافت.

در نهایت، با همین ۴۰۰ مگابایت، همه چیز به خوبی به هم رسید و ما توانستیم پرفورمنس و سرعت را بدون هیچ افت کیفیتی حفظ کنیم!

✅این پست که در مورد DRF هست رو بخونید به همراه نظراتش

https://t.me/dr_biglari_ds/2961

✅بهینه سازی Query Performance : متد Only در ORM جنگو

از لینکدین آقای عموزاده

یکی از فعالیتهای روزمرهام برای محصولات این است که بخش Issues و Performance سرویس Sentry رو بررسی کنم و از لیست مشکلات Performance ای که Sentry تشخیص داده، موارد مهم رو پیدا و به تیم ارجاع بدم و گاهی اوقات هم خودم برم سروقت حل شون و یادگیری ام حفظ بشه. تو گزارش ها، endpoint و background task هایی داریم که Response time یا failure rate شون بیشتر از انتظاره و یا گاهی اوقات سرویس زیر بار کلاً از دست میره (504 میگیریم برای مثال). یکی از روش هایی که میشه برای حل این دست مشکلات استفاده کرد، محدود کردن انتخاب ستونها به اونایی که واقعاً نیاز هستند است. در ORM ها معمولاً ستونهای بیشتر به معنی مصرف منابع بیشتر است و میتونه Capacity و Response time سرویس/محصول را تحت تأثیر قرار بده. در Django یکی از ابزار هایی که برای بهبود Query ها استفاده میکنم متد only است. به این شکل که اول جایی که نتیجه قراره استفاده بشه (مثلاً Template، REST یا …) رو اول بررسی میکنم تا ببینم که چه تعداد از ستونها ضروری هستند و اونا رو به عنوان آرگومان به متد only میدم. بعد با کمک ابزار های مشاهده Query (مثل Debug toolbar یا مشابهش) نتیجه کار رو از نظر دیتابیس چک میکنم. نکته مهم این است که مطمئن باشیم همه ستونهای مورد نیاز رو به متد داده ایم، اگر متدی جای دیگه ای استفاده بشه،ORM مجبور میشه مجدد کوئری بزنه و از هدف اولیه دور میشیم. نکته بعدی اینکه در تجربه و کیس های کاری من، استفاده از این متد، بیشتر مواقع باعث تحول سرویس نشد،قدم مثبتی به جلو بود و خودش رو برای مثال در تهیه گزارش ها (جایی که تعداد زیادی iteration داشتیم) بیشتر نشون داد و اکثر مواقع تفاوت محسوسی نداشت (تفاوت رو با اندازهگیری زمان DB response time، مقدار مصرف حافظه و HTTP response time اندازهگیری کردم). تفاوت Query بدون و با استفاده از Only رو توی تصویر میتونین ببینید و امیدوارم یک ابزار مفید توی جعبه ابزارتون باشه. 🙂 لینک مستندات: https://lnkd.in/dhiwfcb4

تصاویر در نظرات پست

اصل single responsibility چرته

✔️کامنت هاش رو حتما بخون
لینک


کلمه responsibility خودش خیلی کلمه نامفهومیه، اصلا responsibility ینی چی؟ شما وظیفه رو دقیقا چی تعریف میکنی؟ به چی میگی وظیفه؟

آقای uncle Bob در تعریف single responsibility میگه:

A class should have one and only one reason to change

ینی چی only one؟

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

الان تکلیف ما چیه؟ این تعریف رفت زیر سوال، ینی دیگه من single responsibility رو رعایت نکردم؟


حالا فرض کنید یه نفر یک کلاسی نوشته که دو تا متد داره، یکی کاربر رو ایجاد میکنه و یه متد دیگه داره به اون کاربر notification خوش آمد گویی ارسال میکنه.

آیا طبق معیاری به اسم single responsibility میشه گفت این کلاسی که تعریف کردم single responsibile هست؟

به نظرم من خیر نمیشه گفت

حالا معیار درست چی میتونه باشه؟
Cohesion

به نظرم معیار درست تر Cohesionهه، چرا؟

احتمالا وقتی که من کلاس بالارو براتون تعریف کردم به خودتون گفتید ارسال notification چه ربطی به ایجاد کاربر داره، دقیقا درست گفتید

معیار Cohesion بهتره چون شما میتونید ببینید متدهای که چیدید کنار هم چقدر به هم دیگه مرتبط هستند

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

چرا مهندسی نرم افزار؟

تمام آن چه که ما نیاز داریم برای پیشرفت تو صنعت مهندسی نرم افزاره. نه زبان و نه فریمورک و نه ابزار.

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

بلکه دقیقا به این معنیه که پیچیدگی رو کم کنی و نسبت به موقعیت بهترین متدولوژی رو ارائه بدی..

حالا تو این میان هر چی ابزار بیشتر بدونی راحت تر کارت رو راه میندازی.

از این به بعد اینو هر روز با خودم تکرار میکنم، توصیه میکنم شما هم تکرارش کنید😁:

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

✅مصاحبه با مهندس امیر موسوی برنامه نویس ارشد دات نت شرکت Utravs - هنرستان دبیریان نازی آباد تهران

✔️نکاتی که گفتن ارتباطی به زبان برنامه نویسی خاصی نداره و برای همه برنامه نویس های تازه کار میتونه مفید باشه

توی این ویدئو با هماهنگی هنرستان شهید دبیریان واقع در محله نازی آباد تهران
و سر کلاس دوازدهم تجارت الکترونیک با ایشون مصاحبه داشتم.

✔️مهندس موسوی هنرستانی بودن

سوالهای زیر رو ازشون پرسیدیم:
-چه شرکتهایی کار کردید
-رمز موفقیت شما چی بوده
-آیا مدرسه دانشگاه و... میتونه در برنامه نویس خوب شدن کمک کنه
-نظر شما در مورد هوش مصنوعی چیه
-اگر نسخه ۱۸ ساله خودشون رو ملاقات میکردین چه توصیه هایی بهشن می کردید
-اگر برمیگشتن به دوران انتخاب رشته و کنکور آیا از طریق رشته ریاضی و دانشگاه ادامه میدادن یا دوباره با کنکور فنی میرفتن
- کجا واسه کاراموزی برن ک توش کار یاد بگیرن

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

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

✅Partial Functions در پایتون چیه

با این توابع که با استفاده از partial از ماژول functools میشه ساختشون.
می تونیم تعداد مشخصی از آرگومان های تابع را با مقادیر مشخصی تعیین کنیم و تابع جدیدی بسازیم.

مثال:
یک تابع برای ارسال ایمیل با مقادیر پیش‌فرض مانند "از" و "موضوع":

from functools import partial  

def send_email(from_address, to_address, subject, body):  
    print(f'Sending email from {from_address} to {to_address}')  
    print(f'Subject: {subject}')  
    print(f'Body: {body}')  

send_marketing_email = partial(send_email, from_address='marketing@example.com', subject='Our New Product')  

send_marketing_email(to_address='customer@example.com', body='Check out our new product!')  

این مثال شاید زیاد کاربردی نبود.
اگه شما کاربرد درست partial رو میدونید، ممنون میشم توی کامنت بنویسید.

✅ویس های ادامه دار از کتاب Designing data-intensive applications
با ارائه عثمان
@osman_makhtoom

✔️این مفاهیم ارتباطی به زبان برنامه نویسی ندارن. لکن و من الله التوفیق

ویس اول- بخشی از مقدمه کتاب
https://t.me/osmanmakhtoomdev/76

ویس دوم- بخش دوم و پایانی مقدمه کتاب
https://t.me/osmanmakhtoomdev/79

ویس سوم- مقدمه بخش اول کتاب
https://t.me/osmanmakhtoomdev/80

ویس چهارم- بخش اول کتاب
https://t.me/osmanmakhtoomdev/85

ویس پنجم- تفکر در خصوص دیتا سیستم ها و دیزاین درست دیتا سیستم و شرایطی که دیزاین ما وابسته به اوناست.
https://t.me/osmanmakhtoomdev/95

ویس ششم- مفهوم قابل اعتماد بودن اپلیکیشن و ی سافت اسکیل مهم.
https://t.me/osmanmakhtoomdev/96

ویس هفتم- انواع خطاها
https://t.me/osmanmakhtoomdev/97

ویس هشتم- مقدمه قابلیت مقیاس پذیری
https://t.me/osmanmakhtoomdev/98

ویس نهم- توصیف لود
https://t.me/osmanmakhtoomdev/99

ویس دهم- توصیف پرفورمنس (پارت اول)
https://t.me/osmanmakhtoomdev/111

✅معرفی پکیج جنگویی

برای اضافه کردن لاگین با گوگل، فیس بوک، گیت هاب و...
به سایت خودتون می تونید از پکیج social-auth-app-django استفاده کنید.

لینک pypi:
https://pypi.org/project/social-auth-app-django/
لینک گیت هاب:
https://github.com/python-social-auth/social-app-django
لینک داکیومنتش:
https://python-social-auth.readthedocs.io/en/latest/intro.html

✔️فریمورک های زیر رو هم ساپورت میکنه:
Django
Flask
Pyramid
Webpy
Tornado

✔️آپدیت هم هست. و افراد زیادی روش کار کردن. 131 ایشو باز داره و 167 تا ایشو کلوز شده داره.

✅12factor

قبلا توی این پست در موردش نوشتم:
https://t.me/djangolearn_ir/78

اما بازم امروز از از Sider Fusion پرسیدم 12factor چیه؟ و ctrl + c بعدش ctrl + v 😁

یک سری اصول و الگوهایی است که برای توسعه و استقرار برنامه‌های وب مدرن طراحی شده‌اند. هدف آن کمک به توسعه‌دهندگان نرم‌افزار برای ساخت برنامه‌هایی است که مقیاس‌پذیر، پایدار و قابل نگهداری باشند. این اصول عبارتند از:

Codebase:
یک برنامه باید بر اساس یک کدبیس (codebase) واحد باشد که می‌تواند در محیط‌های متفاوت مانند توسعه، آزمایش و تولید عمل کند.

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

Config:
پیکربندی‌ها باید خارج از کد اصلی برنامه (در محیط) قرار گیرند تا قابلیت تغییر و مدیریت آسان‌تر شود.

Backing services:
هرگونه خدمات پشتیبان (مانند پایگاه داده، پیام‌رسان و ...) باید به‌عنوان منابعی از نوعی وابستگی در نظر گرفته شوند و راحت قابل تعویض باشند.

Build, release, run:
فرآیند توسعه باید به مرحله ساخت، انتشار و اجرا تفکیک شود.

Processes:
برنامه‌ها باید به‌صورت پروسه‌های بدون حفظ حالت (stateless) اجرا شوند.

Port binding:
برنامه باید به طور مستقل به پورت‌ها متصل شود و نیازی به خدمات خارجی برای راه‌اندازی نداشته باشد.

Concurrency:
برنامه باید از ویژگی همزمانی (concurrency) به خوبی بهره‌برداری کند.

Disposability:
برنامه‌ها باید به‌راحتی و سریع خاموش و روشن شوند.

Dev/prod parity:
محیط‌های توسعه و تولید باید مشابه یکدیگر باشند تا مشکلات ناشی از تفاوت‌ها کاهش یابد.

Logs:
لاگ‌ها باید به‌عنوان جریانی از رویدادها در نظر گرفته شوند و به‌صورت مرکزی مدیریت شوند.

Admin processes:
کارهای اداری و مدیریتی باید به‌صورت برنامه‌های یکباره (one-off) قابل اجرا باشند و به‌طور جداگانه از جریان اصلی برنامه اجرا شوند.

این اصول باعث می‌شوند که توسعه‌دهندگان برنامه‌هایی بسازند که نگهداری از آن‌ها ساده‌تر است و می‌توانند به راحتی مقیاس پذیر شوند.

✅فاکتور چهارم: Backing services

توضیحات از ویرگول Mohammad Ghodsian که لینکش بالاتر هست:

منظور از Backing services هر سرویسیه که برنامه حین روند طبیعی خودش از اونا استفاده میکنه. مثل دیتابیسها، راه‌های ارتباطی و ساز‌و‌کار‌های پیام‌محور (مثل ربیت یا حتی وب‌هوک‌ها)، چیزایی مثل سیستمِ کشینگ (مثل Memcached) یا هر سرویس دیگه‌ای که برنامه باهاش سر و کار داره. تمامی این سرویس‌ها باید روی بستر شبکه مثلاً به کمک آدرس‌دهی http قابل دسترس باشن، و تعیین‌کننده آدرس یا نحوه ارتباط همون کانفیگیه که به عنوان فاکتور سوم باهاش آشنا شدیم. عملاً هر کدوم از این موارد به عنوان ریسورس برنامه شناخته میشن، و چقدر خوبه که برنامه طوری نوشته شده باشه که اگه سیستم مَسِیجینگ خواست تغییر بکنه (مثلا از RabbitMQ به ZeroMQ) حتی‌المقدور با یه تغییر توی کانفیگ این امر محقق بشه (طبیعتاً نمیشه همه حالات مختلف رو در نظر گرفت ولی حدأقل میشه توی کد در نظر گرفت لایه‌ای که مثلاً وظیفه مسیجینگ رو مدیریت میکنه با کمتری تغییر ممکنه و به سرعت بتونه تغییرات لازمه رو اعمال کنه). یا به عنوان یه مثال دیگه، اگه به هر دلیلی مثلاً ادمین سیستم خواست دیتابیس رو تغییر بده (فرض کنید مشکلی برای دیتابیس فعلی بوجود اومده و برنامه خواست روی یه بک‌آپی که از دیتابیس قبلی گرفته شده و روی دیتابیس جدید نشسته ران بشه) نباید هیچ مشکلی بابت این قضیه بوجود بیاد و تغییر کد خاصی نباید صورت بگیره. این مورد نه فقط روی ورژن نهایی برنامه، بلکه در مورد تمامی deployهای برنامه صدق میکنه، به این مفهوم که برنامه نباید توی برنچ‌ها یا ورژنای مختلف، عملکردای متفاوتی نسبت به محیطی که داره روش ران میشه داشته باشه و اکثر عملکردها تنها وابستگیشون به ریسورسهاشون (که اینجا منظورمون همون backing service ها) هست باید صرفاً اطلاعاتی باشه که از کانفیگ و پارامترای سیستمی دریافت میکنن.

✅معرفی پکیج جنگویی dj-database-url
در راستای فاکتور Backing services

✔️این پکیج کاری میکنه که اطلاعات مربوط به اتصال به دیتابیس رو به سادگی از یه URL بگیریم. به‌جای استفاده از سری متغیرهای جداگانه (مثل NAME، USER، PASSWORD، HOST، PORT) با یه URL کارمون راه میافته.

✔️توی توضیحات خودش متن زیر رو نوشته، لذا لازم شد قبلش اشاره کنم به 12factor:
This simple Django utility allows you to utilize the 12factor inspired DATABASE_URL environment variable to configure your Django application.

لینک pypi:
https://pypi.org/project/dj-database-url/
لینک گیت هاب:
https://github.com/jazzband/dj-database-url

✔️آپدیت هم هست. و افراد زیادی روش کار کردن. 3 ایشو باز داره و 97 تا ایشو کلوز شده داره.

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

اون 15 میلیون شده 1.5 رو نادیده بگیرید. همه دارن این کارو میکنن

✔️فارغ از اینکه یکی از دوره های خودم هم توی پکیج هست، ولی واقعا این همه آموزش خیلی بیشتر از 1 و 500 ارزش دارن.

به نظرم از دست ندید

توی لینک زیر پیداش کنید:
https://www.daneshjooyar.com/blackfriday

به نظرم از دست ندید

با این تخفیف

دوره من شده کمتر از 190 هزار تومن 😱
بیش از 25 ساعت ویدئو برای این دوره ضبط کردم

✔️لذا تخفیفش واقعا خوبه

✅مصاحبه با مهندس میلاد غیاث بیگی، معمار نرم افزار و توسعه دهنده ارشد شرکت رایادرس
سر کلاس یازدهم توسعه برنامه سازی و پایگاه داده هنرستان دبیریان نازی آباد تهران

✔️ایشون تکنیکال لید شرکت رسمیو بوده
✔️هنرستانی بودن

لینک آپارات:
https://www.aparat.com/v/fwqf92h
لینک یوتیوب:
https://youtu.be/pW8uud6fFzY
✔️سوالهای زیر رو ازشون پرسیدیم:
چند سال دارید؟
دبیرستان بودید یا هنرستان؟ چه رشته ای؟
چه شرکت هایی کار کردید و چه سمتی داشتید؟
رمز موفقیت شما چی بوده؟
آیا مدرسه، دانشگاه میتونه به برنامه نویس خوب شدن کمک کنه؟
سوال دانش آموزها:
-اگر نسخه ۱۸ ساله خودشون رو ملاقات میکردن چه توصیه هایی بهشون میکردن و بهش چیا میگفتن؟
-نظر شما در مورد کارآموزی چیه؟
-نظرتون درباره واژه فول استک دولوپر چیه
-بهترین استک یا زبان برنامه نویسی کدومه؟
-چه مهارت یا ابزار یا تکنولوژی هایی لازمه که فارغ از زبان برنامه نویسی یاد بگیریم؟
-من اگه بخوام برنامه نویس بکند بشم. دیکه لازم نیست html css javascript یاد بگیرم؟

✔️ادیت ویدئو: علی اکبر غلامی - پایه یازدهم - رشته شبکه و نرم افزار رایانه

ضمن تشکر از دوستان

ویس دو تا ویدئو قبلی
این لینک ویدئوها

https://t.me/djangolearn_ir/939

https://t.me/djangolearn_ir/948