🎙قسمت سوم سری پادکست‌های توسعه چابک (Agile)

✅ توی این قسمت یک مقدار توی مفهوم اجایل و مفهوم پروژه بیشتر صحبت کردیم و یکم بیشتر با اسکرام آشنا شدیم.

✅ توی قسمت بعد می‌ریم سراغ توضیحات بیشتر راجب فریمورک اسکرام.

☁️ ممنون می‌شم نظراتتون رو بشنوم که استفاده کنیم.

آیدی بنده:
@AminAlih47

#agile

@code_crafters

من بارها و بارها گفتم که در زندگی نه خواسته شما و نه اهداف شما از اهمیت بسیار کمتری برخوردارن، چیزی که در موفقیت بشدت تاثیر گذار هست میزان استفاده شما از فرصت‌هاییست که براتون رخ میده، این مسئله در تمام زندگی شما صدق میکنه براتون و قرار نیست همیشه براتون فرصت بیافته که از بعضی‌هاشون به هر دلیلی چشم پوشی کنید

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

#free

@code_crafters

طراحی میکروسرویس با جنگو بخش دوم میکروسرویس چیست

میکروسرویس ها روندهای جدید توسعه هستند. امروزه شرکت ها معماری میکروسرویس را برای توسعه پروژه ترجیح می دهند. این یک راه حل بسیار فشرده برای یک پروژه است. مدیریت ماژول را آسان می کند و اجرای پروژه را سریعتر می کند. همچنین به توسعه سریعتر پروژه کمک می کند. این دلایل ذکر شده و بسیاری موارد دیگر باعث تقاضای میکروسرویس می شود.

معرفی میکروسرویس
برای میکروسرویس تعریف خاصی وجود ندارد و ممکن هست هر فرد به شکلی آنرا تعریف کند اما دو تعریف عمده آن به شکل زیر است
۱-میکروسرویس‌ها، سرویس‌های کوچک و مستقلی هستند که باهم کار میکنند
۲-میکروسرویس‌ها معماری سرویس گرا با زمینه‌های محدود هستند،بطور مستقل و با یک جزء دیگر در داخل ارتباط برقرار میکنند، این معماری بسیار خودکار و و سیستم‌های نرم افزاری را تکامل می‌دهد

بیایید ببینیم که آیا از معماری سرویس گرا (SOA) آگاه هستید یا خیر، سپس ماژولار بودن پروژه و ارتباط از طریق پیام را نیز می دانید. اگر از شیوه های DevOps آگاه هستید، در مورد استقرار خودکار نیز می دانید. هر دو بیشتر به رویکرد میکروسرویس نزدیک هستند.


سه اصل مهم در طراحی میکروسرویس‌ها:
۱-از میکروسرویس برای استقرار سیستم‌ها و پروژه‌های بزرگ استفاده کنید: برای تمام مقیاس‌های پروژه استفاده از میکروسرویس اشتباه است، بلکه مناسب پروژه‌های بزرگ است که مدیریت آن چالش برانگیز باشد، اما خود این موضوع هم سردرگم کننده هستش اینکه کدوم پروژه رو کوچیک، متوسط، بزرگ بنامیم، منتها اگر سیستم ما دارای بار بالایی از درخواست کاربر است و نیاز به مقیاس پذیری دارد، میتوانیم رویکرد میکروسرویس رو پیاده سازی کنیم(در حجم تعداد اپ نیز تعداد اپ بالا میتواند به این منزله باشد)

۲-این رویکرد هدف‌محور است: مهم نیست که وقتی با مشکل مواجه می‌شویم، باید از رویکرد میکروسرویس پیروی کنیم. امروزه بسیاری از متخصصان برای توسعه پروژه به این رویکرد اشاره می کنند زیرا هدف آنها تنها ارائه راه حل مشکلات نیست، همچنین برای دید بیشتر و حفظ سهولت در ماژول ها، چنین معماری را در عمل به کار می گیرند.

۳-قابلیت تعویض ماژول ها: در پروژه های توسعه یافته قبلی که با رویکرد میکروسرویس ساخته نشده اند، امکان تغییر هر جزء از پروژه کمتر است. قبل از تغییر سازنده کامپوننت باید در مورد تغییرات برنامه ریزی کند، وابستگی کد خاصی را پیدا کند، در صورت عدم موفقیت کد به هر دلیلی، مراحل بازگشت را فهرست کند و تاثیر کد را مشخص کند. پس از همه، تغییرات نیاز به انجام عملیات تست واحد و سپس آزمایش ادغام با کل محصول دارند


در برخی سناریوها، پروژه ها بسیار پیچیده هستند یا وابستگی‌های حیاتی شدیدی دارند، در چنین شرایطی در مورد مسائل آینده یا افزایش حجم بار، ما مجبوریم به جای تغییر، اجزا را حفظ کنیم، که این بزرگترین ضرر یک رویکرد است

در میکروسرویس ها، کل پروژه را بر اساس ماژول ها به یک جزء‌های کوچک تقسیم می کنیم. بطوری که امکان تکرارپذیری را بر روی هر جزء فراهم می کند که تعمیر و نگهداری پروژه رو راحتتر میکند

اپلیکیشن‌های میکروسرویس دارای بخش‌های مهم زیر هستند:
● به اندازه های کوچک تقسیم می شوند
● برای برقراری ارتباط نیازمند انتقال پیام هستند
● مقید به زمینه‌ها هستند
● توسعه انها بصورت مستقل هستش
● استقرار هر بخش مستقل هست
● متصل به کنترل کننده مرکزی نیستند
● ساخت ها توسط فرآیندهای خودکار مستقر می شوند

به شکل آرمان گرایانه به میکروسرویس‌ها نگاه نکنید و با این تصور که در دنیای واقعی قابل پیاده سازی نیست، اگر تصور میکنید که میکروسرویس‌ها توسط بانک‌ها، سیستم‌های بیمارستانی و هتلی پیاده سازی میشه سخت در اشتباه هستید هیچکدام از میکروسرویس استفاده نمیکنند بلکه بیشتر توسط شرکت‌های فعال در حوزه محتوای جریانی(stream content) مورد استفاده قرار میگیرد، استفاده و پیاده سازی میکروسرویس یک انتخاب فردی هست و محدود به دامنه‌ای نیست، اما هدف از آن دو مورد تمرکززدایی و استقلال می‌باشد

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

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

مزیت این دو رویکرد این است که تغییرات در نرم افزار آسانتر و سریعتر میشود و امکان تصمیم گیری سریعتر را فراهم میکند


ادامه در وبسایت

لینک وبسایت


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

#microservice
#django

@code_crafters

موقعیت: وقتی پروژه و ایده‌ رو به مهندسین نرم افزار و سنیورهای داخل گروه‌های تلگرام میدی و فکر میکنی با قیمت کم و مدیریت خودت تمومش کردی



#fun

@code_crafters

فصل پنجم کتاب همزمانی

ارتباط بین فرآیندی

ما نمیتونیم همیشه تضمین کنیم که همیشه وظایف همزمان در سیستم مستقل هست، گاهی وقت یک اجرای یک وظیفه وابسته به خروجی وظیفه دیگری است،اگر همچین مسئله‌ای روی بده برنامه باید بداند چه وقتی کار کند، ارتباط بین وظایف بخش جدایی ناپذیر سیستم‌های همزمانی است و اگر نتوانیم این مورد رو هندل کنیم دستاوردی نداشتیم در این فصل به این مسئله میپردازیم


انواع ارتباط
سیستم عامل مکانیزم‌هایی براتون فراهم میکنه تا بتونید در فرآیندها و رشته‌ها امکان ارتباط گرفتن رو ایجاد کنید این مکانیسم رو با نام IPC میشناسیم

( خب IPC مجموعه‌ای از روش‌ها برای تبادل اطلاعات بین چندین فرآیند یا رشته در حال اجرا در یک سیستم عامل است. این فرآیندها می‌توانند در یک یا چند رایانه متصل به هم توسط یک شبکه اجرا شوند.)
خود IPC به معنای ارتباط بین فرآیندی هستش اما این به این معنا نیست که فقط در فرآیند مورد استفاده هست، در واقع هر فرآیند حداقل یک رشته دارد و ارتباط هم فقط توسط رشته ها صورت میگیرد 

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

محبوبترین نوع‌های IPC دو مورد هستند، اشتراک حافظه (shared memory) و ارسال پیام (message passing)


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

اگر دو‌پردازنده در یک رایانه به مکان حافظه فیزیکی یکسانی اشاره داشته باشند یا زمانی که در رشته‌های درون یک برنامه اشیا مشابهی را به اشتراک میگذراند IPC حافظه مشترک یافت میشه کدها در کامنت


اشتراک‌گذاری حافظه مزایا و معایب خودش رو داره

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


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

مورد دیگر این است که حافظه مسترک برای کارهای محلی قابل استفاده است و در سیستم‌های پراکنده بزرگ مشکل ساز است که داده‌های مورد پردازش نمیتوانند در یک ماشین قرار بگیرند، اما برای سیستم‌های معماری کتقارن چند پردازشی (SMP) مناسب است (در این سیستم‌ها تمام فرایندها و رشته‌ها در در پردازنده‌های مختلف، یک فضای آدرس منطقی منحصر بفرد نگاشت شده و به حافظه فیزیکی را به اشتراک میگذارد)


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

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

فلسفه زبان گولنگ اشتراک گذاری حافظه از طریق ارتباط است و با این شعار (از طریق اشتراک حافظه، ارتباط برقرار کنید، بلکه با برقراری ارتباط، حافظه را به اشتراک بگذارید)


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

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

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

ادامه مبحث در وبسایت...

لینک وب‌سایت

#concurrency

@code_crafters

طراحی میکروسرویس با جنگو بخش سوم طراحی سیستم میکروسرویس

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

رویکرد میکروسرویس
در سطح اولیه توسعه دهندگان زیادی در ساخت سرویس‌ها حضور دارند، اما زمانی که به معماری میکروسرویس روی میاوریم طراحی دقیق سرویس‌ها بصورت جداگانه و بر اساس نیازها جهت توسعه حائز اهمیت هستش، همچنین باید این رو در نظر بگیریم سرویس‌ها چگونه باهم ارتباط میگیرند

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

اگر ما از رویکرد مدل‌پایه استفاپه کنیم میتونیم به راحتی مفهوم سازی کرده و راحب سیستم صحبت کنیم

مدل طراحی میکروسرویس به پنج بخش تقسیم میشود
Service, Solution, Process, Organization, Culture

بخش service
طراحی خوب میکروسرویس ها و API های برای سیستم مهم هستند. در یک سیستم میکروسرویس، سرپیس‌ها بلوک‌های ساختمان اتمی را تشکیل می‌دهند که کل ارگانیسم از آن ساخته می‌شود.اگر بتوانیم طراحی، محدوده و مقیاس خدمات خود را تعیین کنیم، می توانیم پیچیدگی را کاهش دهیم و آن را ساده کنیم

بخش solution
این بخش ارائه میده این چنین معماری و راه حلی که برای هر سرویس متفاوت باشد و همچنین نمایی از آینده رو نشون میده. هنگامی که ما میکروسرویس را طراحی می کنیم، باید همیشه نگران هماهنگی ورودی ها و خروجی های چندین سرویس باشیم. سیستم آینده نگر سیستم مطلوب تری را ارائه می دهد. به عنوان مثال، اگر ما روی ویژگی‌های ایمنی و مسیریابی در اجرای سطح اول کار کنیم، می‌توانیم پیچیدگی هر سرویس را کاهش دهیم.

بخش process
میکروسرویس تنها مؤلفه ای نیست که باعث موفقیت بشه، ما برای ارتباط سرویس داخلی به مکانیزم ارسال پیام نیاز داریم.
اگر خدمات فردی با موفقیت اجرا شود، نتیجه فرآیند و ابزارهایی است که ما از آنها برای انجام وظایف خود در سیستم ها استفاده کردیم. هنگامی که ما سیستم میکروسرویس را طراحی می کنیم، باید فرآیند خاصی را برای توسعه، استقرار کد، نگهداری و مدیریت محصول دنبال کنیم. انتخاب ابزار و فرآیند عالی مهم است زیرا سیستم میکروسرویس به خوبی طراحی شده را تولید می کند.

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

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

کار روی تمامی عناصر باهم
ما زمانیکه طراحی میکنیم تمام عناصر میکروسرویس رو باهم پیش میبریم، نباید فراموش کنیم که این عناصر همه در کنار همدیگه و متصل به هم هستند و تغییر در یکی معنی دار و میتواند بر روی بقیه هم تاثیر غیر قابل پیش بینی بگذارد، به عبارت ساده، سیستم میکروسرویس پیچیده است و نتایج مطلوبی را از آن سیستم تولید می کند.کار آسانی نیست.

ادامه موضوع در وبسایت ...

لینک وبسایت

#microservice
#django

@code_crafters

انتخاب محل ذخیره سازی تصاویر: فایل سیستم یا پایگاه داده؟

تصمیم گیری در مورد بهترین راه برای ذخیره سازی تصاویر بین Blob (Binary Large Object)در پایگاه داده و فایل سیستم (مانند S3) همیشه بحث برانگیز بوده.

پایگاه داده یا فایل سیستم؟ کدوم بهتره؟

اول از همه، بریم سراغ مزایای هر کدوم:

پایگاه داده:

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

فایل سیستم (مانند S3):

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

پس کدوم رو انتخاب کنیم؟

خب، بستگی به نیاز شما داره!

تصاویر کوچیک: اگه تصاویر شما حجم کمی دارن (مثلا چند صد کیلوبایت)، مثلا عکس پروفایل یا مدارک شناسایی، ذخیره کردنشون تو پایگاه داده منطقی تره.
تصاویر بزرگ و به اشتراک گذاری شده: اگه پلتفرمی دارید که کاربرا تصاویر بزرگی رو آپلود و به اشتراک میذارن، بهتره از فایل سیستم استفاده کنید.
آپدیت کم: اگه تصاویر زیاد آپدیت نمی شن و بیشتر جایگزین یا حذف می شن، نیازی به استفاده از ویژگی های ACID پایگاه داده ندارید و فایل سیستم گزینه بهتر و به صرفه تریه.

در نهایت...

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

#Database #General
@Code_Crafters

در این پست  قراره تمایز اغلب گیج کننده بین function  و  method  هارو  را بررسی  کنیم🥸
هر دو بلوک های اساسی در  پایتون هستند اما اهداف کمی تفاوت دارد. ما آنها را در کنار هم در قالب جدول با هم مقایسه خواهیم کرد و نمونه های کد واقعی را برای نشان دادن نحوه استفاده از هر کدام ارائه می دهیم. چه مبتدی باشید و چه به دنبال تقویت مهارت های پایتون خود باشید، این تفکیک دقیق به شما درک روشنی از زمان و نحوه استفاده موثر از function  ها و method  ها می دهد.                                                                                                                                                                                                                                                                                   

تابع(functios)در پایتون چیست؟                                                                                                                در پایتون، یک تابع یک بلوک از کد است که برای انجام یک کار خاص طراحی شده است. توابع به تقسیم برنامه ما به قطعات کوچکتر و ماژولار کمک می کنند. با ایجاد برنامه های پیچیده تر، توابع را می توان مجدداً مورد استفاده قرار داد و کد شما را سازماندهی و مدیریت کرد.                                                                                                                                                                                                                           مثالی از یک تابع:

def greet(name):
    return f"Hello, {name}!"

print(greet("ali"))  # Output: Hello, ali!

متد در پایتون چیست؟
متد، به عکس تابع، یک تابع است که به یک شیء مرتبط است. در پایتون، متدها مستقل نیستند و باید بر روی یک شیء یا داخل یک کلاس فراخوانی شوند. متدها به طور ضمنی از یک شیء استفاده می‌کنند که برای آن فراخوانی شده‌اند.
برای درک بهتر به مثال زیر توجه کنید.

class Greeter:
    def __init__(self, name):
        self.name = name
    
    def greet(self):
        return f"Hello, {self.name}!"

g = Greeter("ali")
print(g.greet())  # Output: Hello, ali!

در اینجا، greet یک متد از کلاس Greeter است و بر روی نمونه g از آن کلاس فراخوانی می‌شود.

در ادامه چند مثال عملی رو باهم بررسی میکنیم.
Function:

def factorial(n):
    if n == 0:
        return 1
    else:
        return n * factorial(n-1)

print(factorial(5))  # Output: 120

در اینجا یک تابع ساده برای به دست اوردن فاکتوریل یک عدد داریم.(5!)

Method:

class Car:
    def __init__(self, make, model):
        self.make = make
        self.model = model

    def description(self):
        return f"{self.make} {self.model}"

my_car = Car("Toyota", "Corolla")
print(my_car.description())  # Output: Toyota Corolla

در اینجا تابع description  یک متود است که جزئیات مربوط به یک نمونه خودرو رو نشون میده.


درک تمایز بین توابع و متودها در پایتون برای نوشتن کد واضح و موثر بسیار مهم است. توابع ماژولار بودن و قابلیت استفاده مجدد را ارائه می دهند، در حالی که متود ها ما را قادر می سازند تا رفتارهای درون اشیاء را با رعایت اصول برنامه نویسی شی گرا محصور کنیم. اینکه یک تابع یا یک روش را انتخاب کنید تا حد زیادی به نیازهای خاص برنامه و ترجیحات طراحی شما بستگی دارد. با درک این مفاهیم، ​​می توانید از انعطاف پذیری و استحکام پایتون در پروژه های برنامه نویسی خود استفاده کنید و کد خود را سازماندهی و پویا تر کنید.
در قسمت کامنت ها جدولی رو برای اختلاف بین function و method میتونید مشاهده کنید
منبع

#python

@code_crafters

در این پست  نکات و ترفند های پیشرفته مدل های جنگو رو بررسی خواهیم کرد.🥸
از جمله: ...indexing, custom managers, inheritance

ارث بری مدل ها به شما امکان می دهد یک مدل پایه با اطلاعات رایج ایجاد کنید و آن را در مدل های دیگر گسترش دهید. جنگو از سه نوع model inheritance پشتیبانی می کند:
abstract base classes, multi-table inheritance, and proxy models

Using Abstract Models:
روشی فوق‌العاده برای جمع‌بندی اطلاعات و رفتار مشترک هستند. برای یک abstract model هیچ جدولی در دیتابیس نشان داده نمی شود. در عوض، فیلدها و متدهای آن توسط زیر کلاس‌ها به ارث می‌رسند.
Example:

class BaseProfile(models.Model):
    bio = models.TextField()
    avatar = models.ImageField(upload_to='avatars/')

    class Meta:
        abstract = True

class StudentProfile(BaseProfile):
    graduation_year = models.IntegerField()

class TeacherProfile(BaseProfile):
    office = models.CharField(max_length=100)

در اینجا BaseProfile مانند یک الگو عمل میکند.StudentProfile, TeacherProfile هر دو دارای فیلد های bio , avatar خواهند بود اما هر کدام در جدول های پایگاه داده خودشان ذخیره میشوند.


Custom Managers :
در جنگو Custom Managers به شما این امکان را می دهند که عملکردهای سطح جدول را به مدل های جنگو خود اضافه کنید. آنها را می توان برای کپسوله کردن و عملیات های crud پیچیده و ارائه یک API تمیزتر برای مدل استفاده کرد.
Example:

class ActiveProfileManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(deleted=False)

class Profile(models.Model):
    name = models.CharField(max_length=100)
    deleted = models.BooleanField(default=False)
    objects = models.Manager()  # The default manager.
    active_objects = ActiveProfileManager()  # Our custom manager.

# Usage:
active_profiles = Profile.active_objects.all()

این custom manager تمامی query های شمارو بر اساس "deleted" فیلتر میکند.


Models Migrations:
مدیریت Migrations مدل‌ها
در جنگو migrations به شما امکان می‌دهند تا طی زمان، طرح پایگاه داده خود را تکامل دهید. مدیریت مناسب migrations ها برای حفظ یک پروژه سالم بسیار حیاتی است.

توصیه‌ها:

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


Proxy Models:
مدل‌های پروکسی برای تغییر رفتار یک مدل، مانند defualt ordering یا custom manager بدون ایجاد جدول پایگاه داده جدید استفاده می‌شوند.

Example:

class OrderedProfile(Profile):
    class Meta:
        proxy = True
        ordering = ['name']

# Usage:
ordered_profiles = OrderedProfile.objects.all()

این پروکسی مدل تمامی profile هارا بر اساس نام نشان میدهد.

Multi-table Inheritance:
این نوع وراثت زمانی استفاده می شود که هر مدل در سلسله مراتب به تنهایی یک موجودیت کامل در نظر گرفته شود که به طور بالقوه به جدول پایگاه داده دیگری مرتبط است.به زبان ساده هر مدل به تنهایی می‌تواند در یک جدول جداگانه در پایگاه داده نمایش داده شود، به جای اینکه همه اطلاعات در یک جدول واحد ذخیره شود.

class Place(models.Model):
    name = models.CharField(max_length=50)

class Restaurant(Place):
    serves_pizza = models.BooleanField(default=False)

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

ادامه مطالب در پست بعد
#python

@code_crafters

در ادامه پست قبلی:
Indexing:
ایندکس ها برای بهبود عملکرد عملیات پایگاه داده، به ویژه برای مجموعه داده های بزرگ، ضروری هستند.
به عنوان مثال، فرض کنید شما یک جدول کاربران دارید و می‌خواهید بر اساس نام آن‌ها جستجو کنید. بدون ایندکس، پایگاه داده باید هر رکورد را از ابتدا تا انتها بررسی کند تا نام مورد نظر را پیدا کند. اما با ایجاد یک ایندکس بر روی فیلد نام، پایگاه داده می‌تواند به سرعت به رکوردهای مرتبط با نام مورد نظر دسترسی پیدا کند.

Example:

class User(models.Model):
    username = models.CharField(max_length=100, db_index=True)
    email = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=['username'], name='username_idx'),
            models.Index(fields=['email'], name='email_idx')
        ]

Overriding Model Methods:
وقتی در Django یک مدل ایجاد می‌کنید، می‌توانید رفتارهای خاصی را برای عملیات‌های مختلف مدل، مانند ذخیره‌سازی یا حذف، سفارشی‌سازی کنید. این کار به شما این امکان را می‌دهد که قبل یا بعد از انجام یک عملیات، کارهای خاصی انجام دهید. شما میتوانید عملیات save , delete ,.... رو بازنویسی کنید.

Example:

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    def save(self, *args, **kwargs):
        self.name = self.name.upper()
        super().save(*args, **kwargs)

در این مثال، هر زمان که یک نمونه از MyModel ذخیره می‌شود، مقدار فیلد name به حروف بزرگ تبدیل می‌شود قبل از ذخیره‌سازی و سپس عملیات ذخیره‌سازی انجام می‌شود.


Soft Deletion:

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

class SoftDeleteModel(models.Model):
    is_deleted = models.BooleanField(default=False)

    def delete(self, *args, **kwargs):
        self.is_deleted = True
        self.save()

هر یک از این تکنیک ها مجموعه ای از مزایای خاص خود را ارائه می دهد و می تواند به طور قابل توجهی بر کارایی و عملکرد پروژه های شما تأثیر بگذارد. با اجرای این استراتژی‌ها، می‌توانید از قابلیت‌های قدرتمند مدل‌سازی جنگو برای ساخت برنامه‌های کاربردی وب قوی‌تر و مقیاس‌پذیرتر بهره ببرید.
منبع
#python

@code_crafters

کلاس دیاگرام اولیه پروژه‌ی فعلی

تو شرکت‌ها کسانی هستند که بهشون طراح و معمار سیستم میگیم کارشونdesign systemهستش،چکاری میکنند؟

میان پروژه ورودی شرکت رو تحلیل میکنن و بیزنس مدل‌های اون رو در میارن و معماری مناسب روجهت پیاده سازی شدن پروژه بر اساس بیزنس مدل‌ها مشخص میکنن،دیاگرام روطراحی میکنن و میفرستن سمت توسعه دهندگان جهت پیاده سازی پروژه بر اساس اون معماری و بیزنس مدلهای مشخص میشه،اینکار رو معمولا در پروژه‌های بزرگ که نیاز هست بر اساس میکروسرویس وDDDپیاده سازی بشه انجام‌ میدن،این پیاده سازی بر اساس اصول سازمانی هر شرکت مخصوص خودش صورت میگیره این مسئله کمک میکنه تا تیم و یا تیم‌های فنی از چهارچوب سازمان خارج نشده و دید یکسانی از پروژه داشته باشن،آماده کردن اون بر اساس میزان بزرگی پروژه زمان بر هست،طراح سیستم بایدآینده نگری نسبت به پروژه داشته باشه تاهزینه‌های شرکت رو بشدت کاهش بده ونقش حیاتی درمشخص کردن هسته بیزنس ایفا میکنه،اشتباه در طراحی این دیاگرام در مرحله اول اون موجب آسیب رسیدن به دیتابیس و داده‌های اون خواهد شد و در مرحله بعدی به کوئری‌ها و پرفورمنس پروژه میرسه
#microservice

#daily

@code_crafters

در ادامه کار بعد از کلاس دیاگرام(در واقع کلاس دیاگرام لایه‌های دیتا data layers رو برامون مشخص میکنه) میرسیم به پیدا کردن بیزنس‌های تجاری پروژه، طبق ساختاری که از دیتا لایرها هستش، کاری که صورت میگیره این هست که دنبال الگوهایی میگردیم، که طبق اون بتونیم دومین‌هامون رو شناسایی کنیم و بر اساس خروجی اون بتونیم سرویس‌هامون رو تشخیص و تفکیک بدیم، هر دومین ممکنه طبق دیدگاه و برآورد شما به یک یا چند سرویس تقسیم بشه

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

#microservice

#daily

@code_crafters

باینری ها در PostgreSQL: ذخیره سازی اطلاعات خام

تصور کنید می‌خواهید عکسی از گربه‌تان را در PostgreSQL ذخیره کنید. چطور می‌توانید این کار را انجام دهید؟

پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است.

تفاوت باینری و رشته‌های کاراکتری:

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

فرمت‌های ذخیره سازی:

هگزادسیمال: هر بایت به عنوان دو رقم شانزده‌گانی نمایش داده می‌شود (مثلاً "00" برای بایت صفر). این فرمت خوانایی بیشتری دارد.
نوع Escape: برخی از بایت‌ها با کاراکترهای خاص علامت‌گذاری می‌شوند. این فرمت قدیمی‌تر است و کاربرد کمتری دارد.

کاربردها:

۱.ذخیره تصاویر، فایل‌های صوتی و ویدئوها
۲.ذخیره داده‌های باینری مانند کدهای برنامه
۳.ذخیره اطلاعات رمزنگاری شده

مثال:

فرض کنید می‌خواهید تصویر گربه‌تان را با نام cat.jpg در پایگاه داده ذخیره کنید:

INSERT INTO photos (name, data)
VALUES ('cat.jpg', BYTEA('\xFF\xD8\xFF\xE0'));

نکات:

پایگاه داده PostgreSQL از نوع داده BLOB (Binary Large Object) نیز برای ذخیره داده‌های باینری پشتیبانی می‌کند. فرمت ورودی BLOB با bytea متفاوت است، اما توابع و عملگرهای مشابهی دارند.
می‌توانید از توابع و عملگرهای مختلفی برای کار با داده‌های bytea استفاده کنید، مانند LENGTH(), SUBSTRING() و COMPARE().

نتیجه:

نوع داده bytea یک ابزار قدرتمند برای ذخیره و مدیریت داده‌های باینری در PostgreSQL است. با استفاده از این نوع داده، می‌توانید انواع مختلف اطلاعات را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

ذخیره سازی اطلاعات خام ولی در حجم بالا با Blob در PostgreSQL

در پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است. اما گاهی اوقات با داده‌های باینری خیلی بزرگتر از حد معمول سروکار داریم. در اینجاست که مفهوم BLOB یا "Binary Large Object" به کمک ما می‌آید.

تعریف BLOB چیست؟

در واقع BLOB یک نوع داده در PostgreSQL است که برای ذخیره داده‌های باینری بسیار بزرگ مانند:

۱. فایل‌های چند گیگابایتی
۲. مجموعه داده‌های علمی
۳. تصاویر با وضوح بالا
۴. فایل‌های ویدئویی با کیفیت بالا

استفاده می‌شود.

مزایای استفاده از BLOB:

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

نحوه استفاده از BLOB:

برای استفاده از BLOB در PostgreSQL، باید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE my_table (
  id INT PRIMARY KEY,
  data BYTEA
);

2. با استفاده از دستور INSERT، داده‌های BLOB را در جدول ذخیره کنید:

INSERT INTO my_table (id, data)
VALUES (1, lo_import('image.jpg'));

3. با استفاده از دستور SELECT، داده‌های BLOB را از جدول بازیابی کنید:

SELECT data FROM my_table WHERE id = 1;

نکات مهم:

برای ذخیره و بازیابی BLOB ها، باید از توابع lo_import و lo_export استفاده کنید.
پایگاه داده PostgreSQL ابزارهای مختلفی برای مدیریت BLOB ها ارائه می‌دهد، مانند توابع و عملگرهای خاص.
برای اطلاعات بیشتر در مورد BLOB ها، می‌توانید به مستندات PostgreSQL مراجعه کنید.

مثال:

فرض کنید می‌خواهید یک ویدیو با حجم 2 گیگابایت را در PostgreSQL ذخیره کنید. می‌توانید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE videos (
  id INT PRIMARY KEY,
  title VARCHAR(255),
  data BYTEA
);

2. با استفاده از دستور INSERT، ویدیو را در جدول ذخیره کنید:

INSERT INTO videos (id, title, data)
VALUES (1, 'My Video', lo_import('video.mp4'));

3. با استفاده از دستور SELECT، ویدیو را از جدول بازیابی کنید:

SELECT data FROM videos WHERE id = 1;

با استفاده از BLOB ها، می‌توانید هر نوع داده باینری را در PostgreSQL ذخیره کنید و به آنها دسترسی داشته باشید. این امر PostgreSQL را به یک راه حل قدرتمند برای ذخیره سازی و مدیریت داده‌های باینری تبدیل می‌کند.

در ادامه، چند نمونه دیگر از کاربردهای BLOB در PostgreSQL آورده شده است:

۱. ذخیره سازی اسناد و مدارک
۲. ذخیره سازی تصاویر و ویدیوها
۳. ذخیره سازی فایل‌های صوتی
۴. ذخیره سازی پایگاه داده‌های NoSQL
۵. ذخیره سازی داده‌های رمزنگاری شده

جمع بندی:

در واقع BLOB ها یک ابزار قدرتمند برای ذخیره سازی داده‌های باینری در PostgreSQL هستند. با استفاده از BLOB ها، می‌توانید داده‌های حجیم را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters

در ادامه مباحث مربوط به طراحی سیستم و معماری آن میریم به سراغ مشخص کردن محدوده و لبه‌های بخش‌های مختلف سرویس، ابتدا دیتا لایه رو مشخص کردیم و سپس دومین‌های تجاری رو پیدا کردیم و اکنون بر روی یک طرح مشخص میکنیم هر سرویس با چه سرویس‌های دیگه ارتباط داره و اشتراکاتشون کجاست(شکل هندسی آن با توجه به هر سیستم متفاوت میگردد) هر سرویس رو با دیتا لایر خودش مشخص میکنیم(در تصویر بلوک‌های زرد رنگ)، یک سیستم میتواند چند دومین تجاری داشته باشد و هر دومین نیز یک یا چند سرویس مجزا بر اساس این طرح بندی در تصویر اولویت‌های ما کامل مشخص خواهد شد و تیم یا تیم‌های توسعه راحت میتوانند تصمیم بگیرند کدام سرویس‌ها پایه و اولویت بالاتری دارن و کدام وابستگی‌های بیشتری ایجاد میکنند و این در پیش برد صحیح و اجرای اولیه بسیار به سازمان کمک میکند، علاوه بر ان میتوان قسمت mvp (نمونه اولیه را نیز مشخص کرد، کادر سبز رنگ)


#microservice

#daily

@code_crafters

رویه ذخیره شده Stored Procedure ناجی برنامه های تحت فشار:
در دنیای برنامه‌نویسی(منظور ما سمت Back-End است نه Front-End 🥸)، بهینه‌سازی و عملکرد روان برنامه‌ها از اهمیت بالایی برخوردار است. در این میان، پایگاه‌های داده نقش حیاتی در ذخیره‌سازی و بازیابی اطلاعات ایفا می‌کنند.

رویه ذخیره‌شده یا Stored Procedure چیست ؟
به صورت خلاصه Stored Procedure یک مجموعه از دستورات SQL است که کار خاصی را انجام میدهد و ما برای آن یک نام مرتبط میگذاریم و در هر جایی که نیاز داشته باشیم آن را فراخوانی میکنیم (اگر پارامتر خاصی نیاز داشته باشد هم میتوانیم به آن پاس بدهیم )

به صورت معمول برنامه نویس ها از ORM هایی مخصوص زبان برنامه نویسی که با آن کار میکنند برای ایجاد کوئری بر روی دیتابیس استفاده میکنند ولی ORM (منظورم هر ORM است حتی اگر معجزه برنامه نویسی قرن باشد!!!) چندین ایراد مهم و اساسی دارند که در ادامه به آن ها اشاره میشود:

۱. شما باید هزینه تبدیل کد هایتان را به SQL پرداخت کنید(با کاهش قدرت برنامه) در نهایت پایگاه داده شما با SQL کار میکند نه زبان برنامه نویسی شما !!!

۲.وقتی از ORM ها استفاده میکنید اگر نیاز به کوئری پیچیده و یا خیلی خاصی داشته باشید قدرت زیادی برای مدیریت این چالش با استفاده از ORM نخواهید داشت.

۳. معمولا برای فراخوانی یک مقدار از پایگاه داده به چندین روش مختلف میتوان این کار را انجام داد که یه سری از این روش ها دارای پرفومنس خوب و بعضی از روش ها دارای پرفومنس وحشتناک هستند
(این مورد مربوط به افزایش پرفومنس در SQL است که توضیح طولانی دارد که در اینجا جای نمیگیرد ولی برای آشنایی بیشتر ساده ترین مورد را اشاره میکنم :
تصور کنید جدولی به نام کارکنان و با ۱۵ ردیف داریم و میخواهید مقدار نام از جدول کارکنان خود را بخوانید با استفاده از ORM خود در نهایت به این کوئری خواهید رسید :

select * from employee;

در حالی که شما فقط به نام کارکنان در این جدول نیاز دارید و این جدول دارای ۱۵ ردیف است که فراخوانی ۱۴ ردیف دیگر بیهوده و هزینه برخواهد بود
و این کوئری نیاز شما را برطرف میکرد :

select name from employee;

که دارای پرفومنس بهتری خواهد بود
{شاید بتوانید جلوی استفاده از * بگیرید و ORM را مجبور به فراخوانی تنها name کنید ولی در موارد دیگر چنین ساده نخواهد بود })
وقتی از ORM خود استفاده میکنید شما کنترل زیادی برای اینکه از چه روشی استفاده کند نخواهید داشت و صرفا کد های ORM خود را خواهید دید

۴. گاها پیش میآید که شما برای فراخوانی مقدار در پایگاه داده با استفاده از ORM کوئری میسازید ولی ORM کوئری عجیبی تولید میکند که فشار فوق العاده ای بر روی برنامه شما وارد میکند.(برای جلوگیری این مورد اگر اصرار به استفاده از ORM دارید باید به موارد پیشرفته ORM خود مراجعه کنید که نیاز به تمرین و زمان است)

از معایب استفاده از Stored Procedure میتوان به این موارد اشاره کرد:

۱. نیاز به دانش خوبی از SQL دارد

۲. در صورت تغییر پایگاه داده نیاز به بازنویسی خواهند داشت

۳.نوشتن برنامه با سرعت خیلی پایین تری پیش خواهد رفت.

مقایسه Stored Procedure با ORM:

در واقع ORMها (Object-Relational Mapping) ابزاری برای نگاشت اشیاء برنامه به ساختارهای پایگاه داده هستند. ORMها به طور خودکار وظایف مربوط به ترجمه کوئری‌ها از زبان برنامه‌نویسی به زبان SQL را انجام می‌دهند.

در حالی که ORMها مزایایی از جمله سادگی و سهولت استفاده را ارائه می‌دهند، اما در مقایسه با Stored Procedureها، معایبی نیز دارند. ORMها می‌توانند به دلیل ترجمه‌های اضافی، باعث افت عملکرد شوند. همچنین، ORMها در مدیریت کوئری‌های پیچیده و خاص، انعطاف‌پذیری Stored Procedureها را ندارند.

در نتیجه :اگر برنامه شما دارای فشار زیادی بر روی پایگاه داده است و همین طور برنامه شما دارای بار زیادی است میتوانید برای مدیریت آن از Stored Procedure ها در پایگاه داده تان استفاده کنید
یا اینکه میتوانید استفاده نکنید و به زیبایی کد های خود با استفاده از ORM به خود افتخار کنید و بگذارید پایگاه داده تحت فشار کد های SQL عجیب شما تبدیل به نفت شود
این مورد کاملا بستگی به برنامه و نیاز شما بستگی دارد.

#Database #General
@Code_Crafters

در ادامه مباحث مربوط به میکروسرویس و soa بارها به سیاست و اصول سازمانی اشاره کردیم (در کتاب طراحی میکروسرویس با جنگو یک بخش مهم از کتاب که نظر خود من رو بشدت جلب کرده بود بارها و بارها به این موضوع اشاره کرده بود) و گفتیم بخش مهمی از طراحی به سبک این معماری‌های نوین بشدت وابسته به این مسئله می‌باشد

در این پست پست‌های با تگ soa# راجب این موضوع حرف میزنیم و مثالهایی برای اون خواهیم گفت تا دیدگاهمون نسبت بهش بازتر بشه و شناخت دقیقتری ازش داشته باشیم

مسئله بر سر حاکمیت soa در سازمان هست
حاکمیت SOA به مجموعه ای از اصول و روش‌ها میگیم که این اطمینان رو حاصل کنه برامون که معماری سرویس گرا (SOA) به طور موثر و کارآمد و مطابق با نیازهای سازمان اداره و بکار گرفته میشود، که شامل تعیین فرآیندها،روابط،کنترل مکانیسم‌ها و اعمال سیاست‌ها میشود

مبحث سیاست‌ها توسط ذینفعان سازمان مشخص میشه و بر کل امور سازمانی اجبار بر اجرای اون خواهد شد و توسعه دهندگان اجازه خروج ازین چهارچوب رو ندارن این سیاست‌ها برای همگان چه توسعه دهندگان و چه مدیران و ادمین‌ها و تحلیل گران کاملا قابل فهم و درک هستش

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

سیاست‌های سازمانی برای حاکمیت soa به چند بخش مختلف تقسیم میشود که برای هر کدام چند مثال جهت درک بیشتر خواهیم گفت، سیاست‌ها رو میتوان در دو بخش پایه و دسته بندی شده بررسی کنیم


1-سیاست‌های پایه

1-1 سیاست پایه زمان طراحی (design-time policies):

۱-سرویس‌های بدون تکرار:
در یک بخش، بسیاری از عملکردها بین خدمات تکراری است.  رسمی کردن این مورد در یک خط‌مشی و بررسی این خط‌مشی قبل از شروع کار بر روی یک سرویس جدید، می‌تواند باعث صرفه‌جویی در کارهای تکراری شود

۲-استانداردسازی فناوری:
این سیاست چیزی شبیه به این است که: "همه خدمات ارائه شده به عموم مردم، به عنوان مثال، از طریق اینترنت، باید از الگوی REST پیروی کنند.خدماتی که منحصراً برای اهداف B2B ارائه می شوند باید از معماری WS-* استفاده کنند." این یک سیاست اساسی است، اما سیاستی است که مانع از آن می‌شود که طراحان پروژه‌ها آنچه را که فکر می‌کنند بهترین است بدون نگاه کردن به شمای بزرگ‌تر انجام دهند.


۳-تایید محتوای پیام:
این سیاست می تواند به شما در ایجاد یک چشم اندازی یکسان از سرویس کمک کند.  وقتی عمیق‌تر به این خط‌مشی نگاه می‌کنیم، احتمالاً باید نوع اعتبارسنجی مورد نیاز را نیز تعریف کنیم، به عنوان مثال، این می تواند به این معنی باشد که تمام قالب های پیام این سرویس باید XML همراه با یک شماتیک باشد.  یا اینکه تمام پیام های JSON ارسال شده می توانند با استفاده از شماتیک JSON تأیید شوند.

1-2 سیاست‌های پایه زمان اجرا (runtime policies):

۱-سرویس باید در یک بازه زمانی مشخص پاسخ دهد(برای مثال کمتر از ۲ ثانیه):
با ایزارهای مشخص و معینی میتوانید این مورد رو مورد بررسی قرار دهید، این یک سیاست ساده در این بخش خواهد بود، شما میتوانید یک داکیومنت بسازید که در آن مشخص شده چه زمان‌هایی سرویس شما در دسترس بوده یا نبوده، این سند میتواند مورد استفاده تحلیلگران سیستم در سازمان قرار گیرد که سیستم رو مورد بررسی قرار دهند

۲-صداکردن (تماس) سرویس‌ها باید در یک کانال امن صورت گیرد:
یکی دیگر از سیاست‌های اساسی برای شروع میتواند این مورد باشد، اگر قرار است ارتباط سرویس‌ها در یک بستر امن صورت گیرد این میتواند یک مورد مناسب باشد، برای مثال جهت اجرای این سیاست ارتباطات میتوانند توسط Apache اجرا کنید

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

ما سیاست‌های پایه خودمون رو مشخص کردیم حال به سراغ سیاست‌های دسته‌بندی میریم و اونهارو بررسی میکنیم


#microservoce
#soa

@code_crafters

2-سیاست‌های دسته بندی شده

2-1سیاست های طراحی و مستندسازی

۱- مستندسازی سرویس‌های خود را ایجاد کنید:
تمام سرویس‌ها باید مستندسازی شوند.  شما باید بتوانید بدون نیاز به بررسی دفترچه راهنما از یک سرویس استفاده کنید

۲-استفاده مجدد از استانداردهای تبادل داده (پیام)  موجود:
اگر یک مدل استاندارد یا واقعی وجود دارد که در سازمان یا دامنه تجاری شما استفاده می شود، باید از آن مدل در سرویس خود استفاده کنید.(برای مثال استفاده از REST برای کاربران نهایی و WS-* برای تجارت بین سازمانی، شماتیک json مشخص در خروجی)

۳-طراحی برای قابلیت استفاده مجدد
قبل از شروع کار بر روی یک سرویس جدید، باید مطمئن شوید که در حال حاضر سرویسی وجود ندارد که همان عملکرد را ارائه دهد یا به راحتی قابل توسعه (داخل متن مرجوعی از کلمه تغییر بجای توسعه استفاده کرده و با توجه به اصول solid در این خصوص من از کلمه توسعه استفاده کردم تا ذهنیت توسعه دهندگان در خصوص اصول باقی بماند) باشد تا عملکرد مورد نیاز را ارائه دهد.

۴-پشتیبانی از چندین نسخه از سرویس:
 پشتیبانی از چندین نسخه از یک سرویس در کنار یکدیگر باید امکان پذیر باشد.تغییرات در نسخه ها باید تا حد امکان بر مصرف کننده تأثیر بگذارد.

2-2 سیاست‌های امنیتی

۱-رمزنگاری کانال ارتباطی برای داده‌های حساس:
تمامی ارتباطات با سرویس شما باید در یک کانال امن صورت بگیرد

۲- تایید یکپارچگی و عدم انکار پیام:
 باید مطمئن شوید که می‌توانید یکپارچگی و منشأ داده‌های پیام را تضمین کنید.(برای مثال ارسال مشخص امضا شده دو طرفه، استفاده از گواهینامه‌های اعتبارسنجی، در برخی از پروتکل‌ها مانند ws-secureconversion این امکان بصورت فیچر وجود دارد)

۳-سرویس احرازهویت مرکزی:
هنگامی که یک مصرف کننده نیاز به احراز هویت برای خدمات شما دارد، باید فقط یک بار احراز هویت کند، نه به طور جداگانه برای هر سرویس.

۴-استفاده از یک سیستم هویت متمرکز برای مجوزها:
 مجوز مورد استفاده همه سرویس‌ها می باشد.برای جلوگیری از اجرای این مورد برای هر سرویس به طور جداگانه، باید از یک سیستم هویت و مجوز متمرکز استفاده کنید.

2-3موارد تست و کارایی

۱-پردازش پیام در ۱۰ ثانیه:
یک سرویس همیشه باید در کمترین زمان ممکن پاسخ دهد

۲-مانیتور سرویس بموقع(real time):
اگر می خواهید خدمات خود را به طور موثر نظارت کنید، باید بتوانید عملکرد را در زمان واقعی اندازه گیری کنید.

۳-یک ویوی منعطف برای نحوه استفاده از سرویس ارائه دهید:
بسته به نیازهای تحلیلگران، باید بتوانید دیدگاه های متفاوتی از نحوه استفاده از سرویس خود نشان دهید.

۴-اجرای سرویس‌ها در فضای ابری:
تمام سرویس هایی که توسعه می یابند باید به صورت افقی مقیاس پذیر باشند تا از صرف سرمایه زیاد در سخت افزار جلوگیری شود و امکان رشد خطی فراهم گردد

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

در سازمان خود اگر برای بخش‌هایی از سیاست‌ها ابزار خاصی مدنظر دارید در داخل سند ارائه شده مطرح کنید برای مثال:

در بخش مانیتورینگ از graphana telegraf یا Prometheus یا BAM استفاده میشود

در بخش کیفیت سنجی و تحلیل کد از sonarqube با sage استفاده میگردد

در بخش تست کدها از end2end یا integration استفاده میگردد

برای بررسی لاگ‌ها ELK استفاده میگردد

برای container orchestrations از k8s استفاده میگردد

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

#microservice
#soa

@code_crafters

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


#fun

@code_crafters

Queue¹
صف²
یک صف شبیه به یک استک³ است، اما روش متفاوتی را برای افزودن و حذف عناصر تعریف می‌کند.
عناصر از یک انتها اضافه می‌شوند که به آن rear⁴ می‌گویند و از انتهای دیگر به نام front⁵ حذف می‌شوند.

به این رفتار FIFO⁶ (First in First Out) گفته می‌شود.
برای تجسم عملکرد آن می توانید یک صف از افراد را در نظر بگیرید. افراد به ترتیب وارد صف می شوند. به مرور طول صف افزایش می‌یابد. سپس افراد به ترتیبی که وارد صف شده اند، از صف خارج می‌شوند. در این صورت اولین نفری که وارد صف شده، اولین نفری است که از صف خارج خواهد شد.

اصطلاح شناسی
فرآیند افزودن عناصر جدید به صف را enqueue⁷ می‌گویند.
فرآیند حذف یک عنصر از صف را dequeue⁸ می‌گویند.

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

📌 لیست¹¹های پایتون ساده‌ترین راه برای پیاده‌سازی عملکرد یک صف هستند.


پانوشت:
1. به فارسی: صف
2. به انگلیسی: Queue
3. Stack (به فارسی: پُشته)
4. انتها، پشت
5. جلو
6. First in First Out
یا به اختصار FIFO یعنی خروج به ترتیب ورود، یکی از روش‌های سازماندهی کنترل داده با توجه به زمان و اولویت‌بندی است.
7. enqueue
کردن، عنصری را به انتهای Queue (صف) اضافه میکند.
8. dequeue
کردن، اولین عنصر یا همان عنصر جلوی صف را از Queue خارج و حذف خواهد کرد.
9. Object
10. Document
11. List

#data_structures
#algorithm

@code_crafters

صف در پایتون

بیایید کلاس Queue را با متُدهای enqueue، dequeue، is_empty و print مربوطه پیاده سازی کنیم.

ما از یک لیست برای ذخیره عناصر استفاده خواهیم کرد.

class Queue:
    def __init__(self):
        self.items = []

    def is_empty(self):
        return self.items == []

    def enqueue(self, item):
        self.items.insert(0, item)

    def dequeue(self):
        return self.items.pop()

    def print_queue(self):
        print(self.items)

q = Queue()
q.enqueue('a')
q.enqueue('b')
q.enqueue('42')
q.print_queue()

q.dequeue()
q.print_queue()

متُد enqueue یک عنصر را در ابتدای لیست اضافه می‌کند، در حالی که متُد dequeue آخرین عنصر را حذف می‌کند.

ℹ️ با کد بازی کنید و صف را در عمل ببینید!

#data_structures
#algorithm

@code_crafters