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

سوالات من:
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