Descriptor
استفاده از descriptor ها هم یک روش قوی برای اضافه کردن رفتار متد مانند به یک اتریبیوت بدون تغییر دادن اینترفیس یک کلاس است. فرض کنید یک برنامه طراحی نوشتید و دو تا کلاس به نام های دایره و مربع دارید. میخواهیم عددی را به عنوان شعاع/ طول بگیریم و قبل ان چک کنیم که عدد حتما مثبت باشد. خب طبق چیزی که تا الان یاد گرفتیم میدانیم که با property میشود همین کار را انجام داد اما این کار باعث کد تکراری زدن میشود و خوب نیست پس از descriptor استفاده میکنیم.
با استفاده از descriptor کدی مانند زیر خواهیم داشت.

import math

class PositiveNumber:
    def __set_name__(self, owner, name):
        self._name = name

    def __get__(self, instance, owner):
        return instance.__dict__[self._name]

    def __set__(self, instance, value):
        if not isinstance(value, int | float) or value <= 0:
            raise ValueError("positive number expected")
        instance.__dict__[self._name] = value

class Circle:
    radius = PositiveNumber()

    def __init__(self, radius):
        self.radius = radius

    def calculate_area(self):
        return round(math.pi * self.radius**2, 2)

class Square:
    side = PositiveNumber()

    def __init__(self, side):
        self.side = side

    def calculate_area(self):
        return round(self.side**2, 2)

در قطعه کد بالا میبینیم که یک کلاس به نام PositiveNumber داریم.
این همان descriptor ما هست. سه داندر متد داره که به ترتیب به توضیح انها میپردازم.
متد اولی توسط پایتون به صورت اتومات هنگامی که از ان یک اینستنس بسازید صدا زده میشود و نام ان اینستنس هرچه که باشد به عنوان ارگومان name به متد پاس داده میشود. ارگومان owner هم نام کلاسی است که descriptor در ان استفاده شده است. ( در مثال ما Circle یا Square)
متد دوم همان متد getter و متد سوم هم همان متد setter همانند کاری که در پراپرتی انجام دادیم.
ارگومان instance که در دو متد getter,setter وجود داره درواقع همون اینستنسی هست که از کلاس Circle یا Square ما ساخته شده.
توجه داشته باشید که برای ذخیره یا مشاهده از اتریبیوت

__dict__

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

__dict__

ان را بخواند یا ذخیره کند، متد های getter, setter از کلاس PositiveNumber با توجه به عملیات مورد نیاز صدا زده میشود و ارگومان های مورد نیاز پاس داده خواهد شد.
منبع
#Descriptor #Python
@Code_Crafters

وقتی پروژه رو با اموزش هندی‌ها از یوتیوب پیش میبری

#fun

@code_crafters

فصل چهارم کتاب

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

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

فرایندها(processes)
فرآیند خود یک برنامه است که روی دیسک مینشیند یک مجموعه دستورالعمل‌ها رو نشون میده که منتظر اجرا هستند، سیستم عامل این دستورالعمل هارو میگیره به حالت اجرا میبره و به یک برنامه با ارزش تبدیل میکند

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

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

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

در سطح دستورالعمل ماشین هیچ مفهومی از فرآیند وجود ندارد

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

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

نگاهی به درون فرآیند تصویر اول در کامنت‌ها
فرایند فقط یک برنامه در حال اجرا است، که با دسترسی به سیستم

داده هایی که فرآیند می خواند یا می نویسد در حافظه ذخیره می شود.  بنابراین، حافظه ای که فرآیند می تواند ببیند یا به آن دسترسی داشته باشد (فضای آدرس) بخشی از فرآیند در حال اجرا است.
 • فایل اجرایی با تمام دستورالعمل های ماشین بخشی از فرآیند است.
 • فرآیند همچنین به یک شناسه نیاز دارد: یک نام منحصر به فرد که فرآیند را می توان با آن شناسایی کرد.  به آن شناسه فرآیند (PID) می گویند.
 • در نهایت، برنامه ها اغلب به دیسک ها، منابع شبکه یا سایر دستگاه های شخص ثالث دسترسی دارند.  چنین اطلاعاتی باید شامل فهرستی از فایل‌هایی باشد که در حال حاضر توسط فرآیند باز می‌شوند، اتصالات شبکه باز و هرگونه اطلاعات اضافی درباره منابعی که استفاده می‌کند.

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

فرآیندها معمولاً توسط سیستم عامل ایجاد می شوند. علاوه بر ایجاد فرآیندها، سیستم عامل مسئولیت خاتمه فرآیند را نیز بر عهده دارد.  این یک کار پیش پا افتاده نیست.  سیستم عامل باید بفهمد که فرآیند به پایان رسیده است - یا کار کامل شده است، فرآیند ناموفق است و زمان پاکسازی آن فرا رسیده است، یا فرآیند والد تمام شده است. ایجاد یا خاتمه یک فرآیند نسبتاً پرهزینه است زیرا همانطور که دیدیم، یک فرآیند منابع زیادی به آن متصل است و باید ایجاد یا آزاد شوند.  انجام این کار به زمان سیستم نیاز دارد و تاخیر اضافی را معرفی می کند.

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

درک این موضوع در کد راحتتر از تئوری آن است کدهای فرآیند در کامنت‌ها


لینک وب‌سایت

#concurrency

@code_crafters

رشته‌ها threads
اشتراک گذاری حافظه بین فرآیندها در اکثر سیستم عامل ها امکان پذیر است، اما به موارد اضافی نیاز دارد که تلاش بیشتری طلب میکند، اما یک مفهوم دیگر که در اشتراک حافظه یک بیت بیشتر به ما کمک میکند وحود دارد:رشته

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

گفتیم یک فرآیند یک برنامه در حال اجرا به اضافه منابع است، اگر برنامه را به اجزای جداگانه تقسیم کنیم، یک فرآیند محفظه ای از منابع (فضای آدرس، فایل ها، اتصالات و غیره) است و یک رشته یک بخش پویا است - دنباله ای از دستورالعمل ها که در داخل این ظرف اجرا می شوند.  بنابراین، در زمینه سیستم عامل، یک فرآیند را می توان به عنوان واحدی از منابع در نظر گرفت، در حالی که یک رشته را می توان به عنوان واحد اجرا مشاهده کرد

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

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

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

مزایای استفاده از رشته‌ها نسبت به فرآیندها

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

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

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

کد رشته‌ها در کامنت

لینک وبسایت

#concurrency

@code_crafters

وقتی رو شغلش و تخصصش کراش میزنی

سوا ازین‌ها گذشته هر آدمی رابطه مستقیمی با الانش داره، بابت همین بشدت موضوع مهمی هستش که مدام و مدام راجب داشتن سابقه تو هر استخدامی میپرسن😅😅😅😅😅

مثلا کسی که سابقه کار با php رو داشته باشه قطعا واسه پایتون خوب نیست یا سابقه فرانت شما برای بکند فقط افتضاح ببار میاره

#fun

@code_crafters

دوستان داریم یک مقدار سایت رو توسعه میدیم

و ازین ببعد مطالب حجیم رو در سایت میزاریم فقط و لینک رو در کانال براتون قرار میدیم

حدود ده نفر از دوستان در حال ترجمه و تبدیل مقالات سایت real python هستند و این مطالب هم در سایت براتون میزاریم و بخشی رو براش جدا میکنیم

خلاصه کتاب همزمانی رو هم در سایت میزارم براتون ازین ببعد (اینجوری یکم سرعتم بیشتر میشه بابت خلاصه نوشتن کتاب و لازم نیست دو نسخه مناسب تلگرام و سایت ازش بسازم )

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


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

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

@code_crafters

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


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

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

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

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


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

#book

@code_crafters

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

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

✔️ ویس بعد راجب اجایل در ایران و فریمورک‌های اجایل صحبت می‌کنیم.

آیدی بنده:
@AminAlih47

#agile

@code_crafters

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

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

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

✔️ ویس بعد راجب فریمورک اسکرام صحبت خواهیم کرد. (تا آخر هفته منتشر می‌شه)

آیدی بنده:
@AminAlih47

#agile

@code_crafters

🔸telAdviser
🔰ربات cli تلگرام برای راحتی بیشتر و دورزدن محدودیتها

💠ویژگی‌ها:
🔹کانال/گروه هایی که محدودیت گذاشتن و فوروارد پستاشونو بستن راحت دور بزنید
🔹پستهای کانال و گروهای پابلیک و پرایوت به هرجایی که خواستید فوروارد کنید تا بکاپ داشته باشید
🔹تایمتونو سر سلکت کردن پست‌ها هدر ندید و...

https://github.com/maanimis/telAdviser

@code_crafters

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

در این بخش پوشش میدیم جنگو رو و مناسب کسانی است که به تازگی باهاش آشنا شده‌اند موارد پوششی این بخش شامل ساختار جنگو، چرخه حیات درخواست (request) و پاسخ (response) ، دستورات پایه‌ای جنگو، کنترل جریان در اپلیکیشن، هندلرهای جنگو، ساخت فایلهای url و view و دانش template ها، بعد از اتمام این بخش شما توانایی دانستن دانشی از web application ها و ساخت rest api با جنگو و چگونه ارائه دادن درخواست داده و باز گرداندن پاسخ بدست خواهید آورد

نکته: دانش پایتونی در خصوص موارد بالا الزامی می‌باشد

جنگو یک فریمورک وب اپلیکیشن بر پایه پایتون هستش، که هر کاربری میتواند با استفاده از آن اقدام به ساخت web application و web api کند، که بسیار ساختارمند و سریعتر از برخی دیگر از زبانهای سمت وب(داخل کتاب اشاره به php دارد) می باشد، که میتوان پروژه‌های بزرگ را با آن به راحتی پیاده سازی کرد.جنگو، از پایتون پشتیبانی می‌کند به این معنا که میتوان از تمامی ویژگی‌های پایتون مانند objects, class, polymorphism, list, tuple, dictionary و ... را در آن استفاده کرد

پایه جنگو، پایتون می‌باشد پس تمامی سینتکس کدها و تلفیق آنها شبیه پایتون است ،جنگو از یک مفسر (interpreter) داخلی برای اجرای فایل‌ها استفاده می‌کند، ما میتونیم بصورت جداگانه اجرا کنیم فایلهای جنگو رو در یک مفسر پایتونی


ما بارها درباره طراحی الگوی ساختار MVC شنیده‌ایم، که فرم کامل آن به شکل Model, View, Controller می‌باشد این الگوی طراحی برنامه رو به سه قسمت منطقی تقسیم میکند، هر قسمت عملکرد متفاوتی دارد و هر قسمت ساخته شده برای هندل کردن جنبه‌هایی از یک برنامه هستش، به این معنا که تمام ساختار یک پروژه توزیع شده در سه بخش قرار میگیرد، جنگو هم تقریبا شبیه با MVC و از الگوی طراحی(معماری) MVT View استفاده میکند، طراحی پروژه‌های جنگو تقسیم شده در سه بخش هستش که ساخت وهندل کردن ساختار پروژه‌های بزرگ رو راحت میکنه

مفهوم MVT

بخش M مورد استفاده برای هندل کردن داده ،مانند واکشی داده از دیتابیس و انتقال داده به ویو

بخش V ویو مربوطه به ذخیره سازی و منطق تجاری(business logic) پروژه که مرتبط هست با مدل و تملیپت

بخش T فرانت، به این معنا که صفحات html و GUI مرتبط با کار، میان داخل بخش تمپلیت، که با مدل و ویو بطور مستقل ارتباط میگیرد

بیایید یک نگاه به ساختار جنگو بیاندازیم

├── first_django_project
│   ├── asgi.py
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

1 directory, 6 files

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

در پایتون متد init (dunder init) که یک سازنده کلاس هستش، این احرا میشه وقتی یک نمونه کلاس ساخته میشه، در جنگو هم فایل (dunder init.py) در مرحله اول اجرا میشود،ما میتونیم ازین فایل استفاده کنیم برای مثال ما بسته‌هایی رو داریم که در جاهای مختلف ازش استفاده میکنیم کافیه در این فایل واردش کنیم


فایل settings.py
این فایل اصلی است، ازین جهت بسیار حائز اهمیت می‌باشد که تمامی پیکربندی‌های پروژه در آن نوشته میشود

ALLOWED_HOSTS = []

در این لیست ما میتونیم یک یا چندین ip بنویسیم که میخواهیم پروژه به آن گوش بدهد، اگر چیزی ننویسیم پیش فرض localhost رو مدنظر میگیره

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

در این لیست ما میتونیم برنامه‌های خودمون رو تعریف کنیم داخل این لیست و خود جنگو برخی برنامه‌های پیش فرض را هم داخل آن جا داده که برای اجرای پروژه ذکر شده

ROOT_URLCONF = 'first_django_project.urls'

این متغیر مسیر پیش فرض url روت پروژه رو معرفی میکنه

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

این دیکشنری برای اتصال به دیتابیس مهم است و شامل اطلاعات درایور و پارامترهای ارتباطی با دیتابیس می باشد، که جنگو بصورت پیش فرض sqlite3 رو تنظیم میکنه


فایل دیگر ما که urls.py است، ما در این فایل URRهای پروژه رو تعریف میکنیم، که مورد استفاده برای کاربران پروژه جهت پردازش request و response هستش

لینک وبسایت

#microservice
#django

@code_crafters

در این فایل است که با ویو ارتباط میگیریم و تمامی urlهای پروژه که توسط جنگو و برای کاربران تعریف شده است قرار دارد


فایل uwsgi.py وقتی استفاده میشه که ما مستقر میکنیم پروژه رو بر روی سرور برنامه، در جنگو این فایل ایجاد میکنه تنظیمات رو برای استقرار، با استفاده از این فایل وب سرور میتونه به راحتی با اپلیکیشن جنگو‌ ارتباط برقرار کند،

فایل manage.py ازین جهت حائز اهمیت است که جنگو با کمک این فایل پروژه رو استارت میکنه (به زبان دیگر setup پروژه جنگو با این فایل اجرا میشه) اگر دقت کنید پوشه داخلی (first_django_priject) با این فایل در یک سطح ساخته میشوند که نشان از اهمیت یکسان آن دو هست


برای اجرای پروژه جنگویی ما دو گام پیش رو داریم:

ابتدا با دستور 
django-admin startproject first_project_django
که ساختار اولیه پیش فرض ساخته میشود با نام مدنظر ما (first_project_django)

سپس با دستور 
python manage.py runserver 
پروژه روی ip مدنظر ما (اگر در قسمت allow host تعریف شده باشد ip مدنظر ما و در غیر این صورت در ip پیشفرض 127.0.0.1) بر روی پورت پیش فرض 8000 اجرا خواهد شد همچینین میتونیم با پاس دادن پورت مدنظرمون به دستور پورت پیشفرض رو هم تغییر داد 
python manage.py runserver 8001

اگر در مرورگر خود 127.0.0.1:8000 رو وارد کنیم خروجی رو میبینیم


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

۱-درون فایل manage.py، فایل settings.py ذکر شده که به معنای فایل تنظیمات است
۲- درون فایل settings بخش‌های کدی وجود دارد که خط به خط هر بخش اجرا میشود

۱- ماژول‌های ضروری جهت اجرا رو import میکند

۲- مسیر پروژه رو میسازه

۳-در بخش allow host هر مقدار ip رو‌تعریف میکنیم و سپس پروژه در اون ip خاص استارت خواهد شد

۴-در بخش بعدی تمامی appها لود شده که ما در install app تعریف کرده‌ایم

۵-در بخش بعدی مجموعه URLها رو در بخش روت تعریف میکند، که تعریف شده داخل فایل urls.py 

۶-حالاجستجو برای پوشه templateها شروع میشه که چون تعریف نشده مقدار خالی رو تنظیم میکنه

۷-در بخش دیتابیس اجرا میکنه کد رو و با دیتابیس پروژه ارتباط برقرار میکند

۳-پس از اجرا کردن فایل settings سرور استارت زده و در ip با پورت مدنظر ما در دسترس قرار میگیرد


جنگو‌ چگونه درخواست‌هارو‌هندل میکنه
۱-متغیر ROOT_URLCONF از فایل settings رو لود میکن
۲-این منغییر را بصورت گلوبال تنظیم کرده و سپس مسیر را برای یافتن URLهای تعریف شده توسط کاربر مشخص می کند

۳-هر url تعریف شده به یک تابع نسبت داده شده است

urlpatterns = [
    path('admin/', admin.site.urls),
]

۴-که بعد از کاما مشخص شده و هنگام صدا زدن تابع مدنظر رو اجرا میکنه


شرح مراحل کنترل جریان درخواست:

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

در مرحله اول درخواست کاربر بصورت شی HttpRequest ارسال میشه، سپس برای ارسال پاسخ از یک شی HttpResponse استفاده میشه
اگر url درخواستی کاربر وجود داشته باشد تابع نسبت داده شده آن در فایل views.py فراخوانده میشود

صفحات خطای پیش فرض:

خطای 400: اگر کاربر ارسال کنه درخواستی رو و به خطا بخوره جنگو مقدار تابع django.views.defaults.bad_request()
صدا میزنه و یک استثنا پیش فرض با وضعیت رو برمیگردونه

خطای 403:اگر کاربر ارسال کنه درخواستی و اجازه دسترسی نداشته باشد مقدار تابع  django.views.defaults.permission_denied()
صدا زده میشود

خطای 404: اگر کاربر ارسال کنه درخواستی رو و با خطای نبود URL مواجه بشه مقدار django.views.defaults.page_not_found()
صدا زده میشه

خطای 500: اگر کاربر ارسال کنه درخواستی رو و با خطای سرور مواجه بشه مقدار تابع django.views.defaults.server_error()
صدا زده میشه

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

مقدار get
این روش برای دریافت داده از طریق ارسال داده‌های مرتبط به سرور استفاهده میشه، دارای طول محدود داده جهت ارسال است، اطلاعات و داده‌ها در url قابل مشاهده است و انتقال داده آن ناامن است

مقدار post
برای ارسال داده‌های حساس کاربر به سرور مناسب است، داده ها در url قابل مشاهده نیست و امنتر از get می‌باشد و محدودیت ارسال اطلاعات آن نیز بیشتر

لینک وبسایت
#microservice
#django

@code_crafters

مقدار connect
این درخواست یک خط لوله (pipline) را به سرور ایجاد خواهد کرد و بعد از احرازهویت و سنجش آن را تایید و ایجاد میکند

مقدار put
این روش شبیه به مقدار post است دقیقا با این تفاوت که اگه بارها اون رو تکرار کنیم یک مقدار یکسان به ما خواهد داد در حالیکه در post ممکن مقادیر متفاوت ایجاد گردد، این روش مناسب ایجاد یا تغییر منابع با آپلود داده است

مقدار delete
اگر کاربر بخواهد هر داده‌ای رو حذف از دیتابیس این بهترین روش است


ایجاد فایل ویو و پیکربندی url پیش تعریف کاربر
طبق الگوی MVT ،بیزنس لاجیک در فایل view تعریف میشه، و این فایل توسط URLها صدا زده میشه و همچین رابط بین مدل و تمپلیت است، پوشه داخلی و در کنار settings.py یک فایل با نام views.py میسازیم

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world. this is my first URL.")

ابتدا ماژول مدنظر خودمون رو ایمپورت کرده و سپس تابع ویوی مدنظر خودمون رو میسازیم و در فایل urls.py اون رو صدا میزنیم

from . import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('polls/', views.index),
]

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

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

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

بخش Formatters:
ما تعریف میکنیم فرمتی رو برای رکوردها، که چاپ کنن متن رو، همچنین میتونیم فرمت مدنظر خودمون رو تعریف کنیم برای چاپ لاگ‌ها


انواع لاگ‌ها

DEBUG:
استفاده میشه برای چاپ و نوشتن اطلاعات اندکی درباره سیستم و برنامه

INFO:
استفاده میشه برای گرفتن اطلاعاتی از سیستم

WARNING:
بیشتر استفاده میشه بوسیله سیستم ارائه دهنده اطلاعات برای مشکلات جزئی که در سیستم رخ میده

ERROR:
این لاکر اطلاعات مهم را میگیرد، که روی میدن در سیستم و برنامه

CRITICAL:
برای چاپ پیامی استفاده میشه که سیستم یا برنامه دارای مشکل جزئی است

اجرای لاگر
لاگرها به سادگی در جنگو اجرا میشن، در بخش اول ما پیکربندی میکنیم فایل settings رو و میسازیم فایل لاگ رو، و اشاره میکنیم نوع لاگ رو در کد

یک نمونه ساده از پیکربندی لاگر

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/home/debug.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

برای دیدن خروجی و اجرا در برنامه هم بصورت زیر در ویو

import logging

logger = logging.getLogger(name)

logger.debug('this is example of debug logger')
logger.info('this is example of info logger')
logger.warn('this is example of warn logger')
logger.error('this is example of error logger')

و برای تغییر فرمت هم

formatters = {
'f': {'format':
'%(asctime)s %(name)-12s %(levelname)-8s %(message)s'}
},

لینک وبسایت

#microservice
#django

@code_crafters

توسعه API در جنگو

در این قسمت ما شروع میکنیم به پیاده سازی api و یادگرفتن آن در جنگو و پیاده سازی کردنش، api در میکروسرویس جایگاه بسیار حائز اهمیتی دارد

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

ساخت یک اپ در جنگو
اجازه بدید یک اپ جنگو بسازیم جهت نگهداری کدها، کارایی اپ جنگو در مناسب بودن هندل کردن بخش‌های جداگانه هر ماژول است، اگر در ماژولی تغییر ایجاد کنیم نباید روی دیگر ماژول‌ها تاثیر گذار باشد، ما کار رو در یک پروژه جدید با نام django_project01 پیش میبریم و یک اپ داخل آن با نام first_app میسازیم

django-admin startproject django_project01

cd django_project01

python manage.py startapp first_app

بعد از زدن دستورات ساختار پروژه به این شکل خواهد بود

.
├── django_poject01
│   ├── asgi.py
│   ├── __init__.py
│   ├── pycache
│   │   ├── init.cpython-310.pyc
│   │   └── settings.cpython-310.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── first_app
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── manage.py

4 directories, 15 files

جنگو برای اپ نیز یکسری فایل تولید میکند(که از بررسی آن سر باز میزنیم، اپ را در فایل settings به لیست install apps اضافه میکنیم)

ما میتونیم ویوهای خودمون رو به دو شکل CBV و FBV در فایل views.py بنویسیم


برای قسمت fbv(function base view)

from django.http import HttpResponse
import json


def get_method_example(request):
    userid = request.GET.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')
    
@csrf_exempt
def get_method_example(request):
    userid = request.POST.get('userid', '')
    resp = {}
    if userid:
        resp['status'] = 'Success'
        resp['status_code'] = '200'
        resp['data'] = userid
        return HttpResponse(json.dumps(resp), content_type='application/json')

دو تابع درست کرده‌ایم یکی برای درخواست‌های GET و یکی برای درخواست‌های POST، حال با اضافه کردن دوتا url به پروژه میتوانیم هر دو ویو رو با برنامه postman تست کنیم


برای قسمت cbv(class base view)

from django.http import HttpResponse
import json
from django.views import View

class ClassBaseViewExample(View):
    def get(self, request):
        userid = request.GET.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

    def post(self, request):
        userid = request.POST.get('userid', '')
        resp = {}
        if userid:
            resp['status'] = 'Success'
            resp['status_code'] = '200'
            resp['data'] = userid
            return HttpResponse(json.dumps(resp), content_type='application/json')

برای cbv یک کلاس با دو تابع نوشته شده که مشابه کدهای قبلی می باشد و اکنون با نوشتن یک urlبرای آن میتوان هر دوتابع این ویو رو در postman تست کرد


برای مثال در قسمت url اصلی پروژه

from django.contrib import admin
from django.urls import path
from first_app import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('get_method/', views.get_method_example),
    path('post_method/', views.post_method_example),
    path('cbv_method/', views.ClassBaseViewExample.as_view()),
]

لینک وبسایت

#microservice
#django

@code_crafters

🎙قسمت سوم سری پادکست‌های توسعه چابک (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