در جاوااسکریپت، مفاهیم "Execution Context"و "Execution Stack"و "Variable Object" و "Scope Chain" به ترتیب با مکانیزم‌های اجرایی و مدیریت متغیرها و توابع در کد ارتباط دارند.
خب این مفاهیم برای درک چگونگی اجرای کدهای جاوااسکریپت و مدیریت فضای حافظه اهمیت دارند. بیاید بیشتر باهاش آشنا شیم:
1. Execution Context:
این مفهوم به معنای فضاییه که کدهای جاوااسکریپت توش اجرا میشن. وقتی یه اسکریپت یا تابع اجرا میشه، یه "بافت اجرایی" براش ساخته میشه که مرورگر بهش نیاز داره تا کد رو درست اجرا کنه.
سه نوع کلی داریم:
- Global Execution Context: وقتی کد برای اولین بار اجرا میشه، این بافت ساخته میشه و همه کدهای خارج از توابع توش قرار میگیرن.
- Function Execution Context: هر بار که یه تابع فراخوانی میشه، یه بافت اجرایی جدید برای اون ساخته میشه.
- Eval Execution Context: وقتی کدها از طریق تابع eval() اجرا میشن، یه بافت اجرایی خاص برای اون ساخته میشه.
هر Execution Context سه بخش اصلی داره:
1.Variable Object: جایی که متغیرها و توابع تعریف‌شده توش ذخیره میشن.
2. Scope Chain: برای دسترسی به متغیرها و توابع در دامنه‌های دیگه استفاده میشه.
3. this: به آبجکت فعلی یا محیط اجرایی خاص در زمان اجرا اشاره داره.
2. Execution Stack:
اینو بهش Call Stack هم میگن. یه جور ساختار داده‌ای از نوع استک (LIFO: Last In, First Out) که بافت‌های اجرایی رو مدیریت میکنه. هر بار که یه تابع فراخوانی میشه، بافت اجرایی اون تابع به استک اضافه میشه و بعد از اتمام اجرا، از استک خارج میشه.
3. Variable Object:
فضایی که تو هر بافت اجرایی ایجاد میشه و متغیرها، توابع و پارامترهای مربوط به اون رو ذخیره میکنه.
دو نوع اصلی داره:
- Global Execution Context: آبجکت متغیر به عنوان Global Object عمل میکنه (معمولاً window تو مرورگر).
- Function Execution Context: شامل پارامترهای تابع، متغیرهای داخل تابع و توابع درونی اون.
۴. Scope Chain:
مکانیزمیه که جاوااسکریپت برای دسترسی به متغیرها و توابع ازش استفاده میکنه. هر بافت اجرایی یه زنجیره‌ای از دامنه‌ها داره که تو اون به دنبال متغیرها و توابع میگرده. وقتی جاوااسکریپت دنبال مقدار یه متغیره، اول از دامنه فعلی شروع میکنه و اگه اونجا پیدا نکرد، میره سراغ دامنه‌های بالاتر (مثلاً دامنه گلوبال).
این مفهوم اجازه میده که متغیرها و توابع تو جاوااسکریپت به طور سلسله مراتبی و براساس مکان تعریفشون تو کد دسترسی‌پذیر باشن.
ANOPHEL I آنوفل
#جاوااسکریپت #javascript #stack #react #vue
خب این مفاهیم برای درک چگونگی اجرای کدهای جاوااسکریپت و مدیریت فضای حافظه اهمیت دارند. بیاید بیشتر باهاش آشنا شیم:
1. Execution Context:
این مفهوم به معنای فضاییه که کدهای جاوااسکریپت توش اجرا میشن. وقتی یه اسکریپت یا تابع اجرا میشه، یه "بافت اجرایی" براش ساخته میشه که مرورگر بهش نیاز داره تا کد رو درست اجرا کنه.
سه نوع کلی داریم:
- Global Execution Context: وقتی کد برای اولین بار اجرا میشه، این بافت ساخته میشه و همه کدهای خارج از توابع توش قرار میگیرن.
- Function Execution Context: هر بار که یه تابع فراخوانی میشه، یه بافت اجرایی جدید برای اون ساخته میشه.
- Eval Execution Context: وقتی کدها از طریق تابع eval() اجرا میشن، یه بافت اجرایی خاص برای اون ساخته میشه.
هر Execution Context سه بخش اصلی داره:
1.Variable Object: جایی که متغیرها و توابع تعریف‌شده توش ذخیره میشن.
2. Scope Chain: برای دسترسی به متغیرها و توابع در دامنه‌های دیگه استفاده میشه.
3. this: به آبجکت فعلی یا محیط اجرایی خاص در زمان اجرا اشاره داره.
2. Execution Stack:
اینو بهش Call Stack هم میگن. یه جور ساختار داده‌ای از نوع استک (LIFO: Last In, First Out) که بافت‌های اجرایی رو مدیریت میکنه. هر بار که یه تابع فراخوانی میشه، بافت اجرایی اون تابع به استک اضافه میشه و بعد از اتمام اجرا، از استک خارج میشه.
3. Variable Object:
فضایی که تو هر بافت اجرایی ایجاد میشه و متغیرها، توابع و پارامترهای مربوط به اون رو ذخیره میکنه.
دو نوع اصلی داره:
- Global Execution Context: آبجکت متغیر به عنوان Global Object عمل میکنه (معمولاً window تو مرورگر).
- Function Execution Context: شامل پارامترهای تابع، متغیرهای داخل تابع و توابع درونی اون.
۴. Scope Chain:
مکانیزمیه که جاوااسکریپت برای دسترسی به متغیرها و توابع ازش استفاده میکنه. هر بافت اجرایی یه زنجیره‌ای از دامنه‌ها داره که تو اون به دنبال متغیرها و توابع میگرده. وقتی جاوااسکریپت دنبال مقدار یه متغیره، اول از دامنه فعلی شروع میکنه و اگه اونجا پیدا نکرد، میره سراغ دامنه‌های بالاتر (مثلاً دامنه گلوبال).
این مفهوم اجازه میده که متغیرها و توابع تو جاوااسکریپت به طور سلسله مراتبی و براساس مکان تعریفشون تو کد دسترسی‌پذیر باشن.
ANOPHEL I آنوفل
#جاوااسکریپت #javascript #stack #react #vue
Anophel
Anophel | Where Developers Create Their Own Path
Anophel is an ecosystem for developers—a place for those who prefer building over consuming. If you want to create tools, think differently, and forge your own path in coding, Anophel is with you.
بهترین Best Practice های گولنگ که هر برنامه نویس Go بداند
🔺 گولنگ (Golang) که با نام Go نیز شناخته می شود، یک زبان برنامه نویسی منبع باز محبوب است که توسط غول فناوری گوگل توسعه یافته است. Go با سادگی، کارایی و پشتیبانی قوی از همزمانی، محبوبیت زیادی در بین توسعه دهندگان در سراسر جهان به دست آورده است. از آنجای...
🌐 : بهترین Best Practice های گولنگ که هر برنامه نویس Go بداند
🔺 گولنگ (Golang) که با نام Go نیز شناخته می شود، یک زبان برنامه نویسی منبع باز محبوب است که توسط غول فناوری گوگل توسعه یافته است. Go با سادگی، کارایی و پشتیبانی قوی از همزمانی، محبوبیت زیادی در بین توسعه دهندگان در سراسر جهان به دست آورده است. از آنجای...
🌐 : بهترین Best Practice های گولنگ که هر برنامه نویس Go بداند
تسلط و بررسی package.json : قلب پروژه Node.JS
🔺 اگر تا به حال با یک پروژه node.js یا ری اکت کار کرده اید، احتمالا با فایل package.json مواجه شده اید. این فایل که بی سر و صدا در ریشه شما قرار دارد اما اجازه ندهید اندازه خودتون شما را فریب دهد این یکی از مهم ترین بخش های هر پروژه JavaScript/TypeScri...
🌐 : تسلط و بررسی package.json : قلب پروژه Node.JS
🔺 اگر تا به حال با یک پروژه node.js یا ری اکت کار کرده اید، احتمالا با فایل package.json مواجه شده اید. این فایل که بی سر و صدا در ریشه شما قرار دارد اما اجازه ندهید اندازه خودتون شما را فریب دهد این یکی از مهم ترین بخش های هر پروژه JavaScript/TypeScri...
🌐 : تسلط و بررسی package.json : قلب پروژه Node.JS
آیا تا به حال به یک ساختار کامل و منظم برای مدیریت پروژه‌های #گولنگ ( Go# ) با معماری Domain-Driven Design (DDD) فکر کرده‌اید؟ در این پست قصد داریم این ساختار را با جزئیات بیشتری بررسی کنیم و به شما نشان دهیم چگونه می‌توانید پروژه‌تان را مرتب‌تر و کارآمدتر پیش ببرید.
پست قبلی ما در این لینک:
https://lnkd.in/evuPH7cB
1. سطح بالا (Root Directory):
-cmd/:
- این دایرکتوری برای نقاط ورود برنامه استفاده میشه. هر اپلیکیشن قابل‌اجرا، چه سرور باشه چه ابزارهای CLI یا میکروسرویس‌ها، اینجا قرار می‌گیره.
- مثال: cmd/app/main.go: فایل اصلی که نقطه شروع اجرای برنامه است. این فایل باید تمیز و ساده باشه و فقط وظیفه‌ی مقداردهی اولیه مثل خواندن تنظیمات، ایجاد کانکشن‌ها، و شروع سرور رو برعهده داشته باشه.
- internal/:
- کدهایی که مختص پروژه‌ی ما هستن و نباید توسط ماژول‌های خارجی استفاده بشن، اینجا قرار میگیرن. در گولنگ، دایرکتوری internal به‌صورت پیش‌فرض دسترسی ماژول‌های خارجی رو محدود میکنه.
- pkg/:
- شامل کتابخانه‌ها و کدهای قابل استفاده مجدد هست که ممکنه در پروژه‌های دیگه یا بخش‌های دیگه همین پروژه استفاده بشن. دقت کنید که این دایرکتوری باید از internal جدا باشه چون عمومی‌تر هست.
- configs/:
- تنظیمات پروژه مثل فایل‌های yaml، json یا toml که برای کانفیگ سرور، دیتابیس یا سرویس‌های دیگه استفاده میشن اینجا قرار میگیرن.
- go.mod و go.sum:
- این فایل‌ها وظیفه مدیریت وابستگی‌ها رو به عهده دارن و توسط Go Modules استفاده میشن.
2. دایرکتوری داخلی (internal/):
این دایرکتوری قلب پروژه‌ست و تمامی دامنه‌های پروژه رو در خودش جای میده. هر دامنه یا Bounded Context به صورت جداگانه سازمان‌دهی شده.
ساختار دامنه (مثال: user/):
- user.go (Model):
- شامل مدل‌ها و ساختارهای داده‌ای مرتبط با دامنه است.
- repository.go:
- مسئول مدیریت دسترسی به داده‌ها (Data Access Layer) هست.
- service.go:
- این لایه منطق تجاری رو پیاده‌سازی میکنه و سرویس‌ها با repository تعامل دارند و مدیریت فرآیندهای مربوط به دامنه رو انجام می‌دن.
- handler.go:
- این لایه مدیریت درخواست‌های ورودی (HTTP یا gRPC) و اتصال اون‌ها به سرویس‌ها رو بر عهده داره.
ساختار دامنه دیگر (مثال: product/):
- دامنه‌های دیگه مثل product ساختاری مشابه دارند. هر دامنه به‌صورت مستقل پیاده‌سازی شده و شامل لایه‌های مدل، سرویس، ریپازیتوری و هندلر هست.
کاربرد این ساختار در DDD:
- تفکیک دامنه‌ها :
- هر دامنه کاملاً مستقل پیاده‌سازی شده و می‌تونه به صورت جداگانه توسعه یابد.
- انعطاف‌پذیری:
- با این ساختار، می‌تونید تغییرات یا افزودن دامنه‌های جدید رو بدون تأثیر روی سایر بخش‌ها انجام بدید.
-مقیاس‌پذیری:
- هر دامنه می‌تونه به‌صورت مجزا تست و مقیاس‌دهی بشه. برای مثال، در صورت نیاز، می‌تونید دامنه خاصی رو به یک سرویس مستقل تبدیل کنید.
سازگاری با معماری‌های مدرن:
- این ساختار برای پروژه‌های میکروسرویس، مونولیت ماژولار یا حتی معماری‌های لایه‌ای مناسب است.
آیا شما هم تجربه‌ای در استفاده از معماری DDD# دارید؟ خوشحال می‌شوم که تجربیات و نظرات خود را با ما به اشتراک بگذارید!
Anophel | آنوفل
پست قبلی ما در این لینک:
https://lnkd.in/evuPH7cB
1. سطح بالا (Root Directory):
-cmd/:
- این دایرکتوری برای نقاط ورود برنامه استفاده میشه. هر اپلیکیشن قابل‌اجرا، چه سرور باشه چه ابزارهای CLI یا میکروسرویس‌ها، اینجا قرار می‌گیره.
- مثال: cmd/app/main.go: فایل اصلی که نقطه شروع اجرای برنامه است. این فایل باید تمیز و ساده باشه و فقط وظیفه‌ی مقداردهی اولیه مثل خواندن تنظیمات، ایجاد کانکشن‌ها، و شروع سرور رو برعهده داشته باشه.
- internal/:
- کدهایی که مختص پروژه‌ی ما هستن و نباید توسط ماژول‌های خارجی استفاده بشن، اینجا قرار میگیرن. در گولنگ، دایرکتوری internal به‌صورت پیش‌فرض دسترسی ماژول‌های خارجی رو محدود میکنه.
- pkg/:
- شامل کتابخانه‌ها و کدهای قابل استفاده مجدد هست که ممکنه در پروژه‌های دیگه یا بخش‌های دیگه همین پروژه استفاده بشن. دقت کنید که این دایرکتوری باید از internal جدا باشه چون عمومی‌تر هست.
- configs/:
- تنظیمات پروژه مثل فایل‌های yaml، json یا toml که برای کانفیگ سرور، دیتابیس یا سرویس‌های دیگه استفاده میشن اینجا قرار میگیرن.
- go.mod و go.sum:
- این فایل‌ها وظیفه مدیریت وابستگی‌ها رو به عهده دارن و توسط Go Modules استفاده میشن.
2. دایرکتوری داخلی (internal/):
این دایرکتوری قلب پروژه‌ست و تمامی دامنه‌های پروژه رو در خودش جای میده. هر دامنه یا Bounded Context به صورت جداگانه سازمان‌دهی شده.
ساختار دامنه (مثال: user/):
- user.go (Model):
- شامل مدل‌ها و ساختارهای داده‌ای مرتبط با دامنه است.
- repository.go:
- مسئول مدیریت دسترسی به داده‌ها (Data Access Layer) هست.
- service.go:
- این لایه منطق تجاری رو پیاده‌سازی میکنه و سرویس‌ها با repository تعامل دارند و مدیریت فرآیندهای مربوط به دامنه رو انجام می‌دن.
- handler.go:
- این لایه مدیریت درخواست‌های ورودی (HTTP یا gRPC) و اتصال اون‌ها به سرویس‌ها رو بر عهده داره.
ساختار دامنه دیگر (مثال: product/):
- دامنه‌های دیگه مثل product ساختاری مشابه دارند. هر دامنه به‌صورت مستقل پیاده‌سازی شده و شامل لایه‌های مدل، سرویس، ریپازیتوری و هندلر هست.
کاربرد این ساختار در DDD:
- تفکیک دامنه‌ها :
- هر دامنه کاملاً مستقل پیاده‌سازی شده و می‌تونه به صورت جداگانه توسعه یابد.
- انعطاف‌پذیری:
- با این ساختار، می‌تونید تغییرات یا افزودن دامنه‌های جدید رو بدون تأثیر روی سایر بخش‌ها انجام بدید.
-مقیاس‌پذیری:
- هر دامنه می‌تونه به‌صورت مجزا تست و مقیاس‌دهی بشه. برای مثال، در صورت نیاز، می‌تونید دامنه خاصی رو به یک سرویس مستقل تبدیل کنید.
سازگاری با معماری‌های مدرن:
- این ساختار برای پروژه‌های میکروسرویس، مونولیت ماژولار یا حتی معماری‌های لایه‌ای مناسب است.
آیا شما هم تجربه‌ای در استفاده از معماری DDD# دارید؟ خوشحال می‌شوم که تجربیات و نظرات خود را با ما به اشتراک بگذارید!
Anophel | آنوفل
Linkedin
Mohammad Abdorrahmani on LinkedIn: #گولنگ #golang #go #project_folder_structures
وقتی در اولین قدم، پروژه گولنگ (Golang) رو شروع می‌کنید، چطور ساختار پوشه‌ها رو انتخاب می‌کنید تا هم سرعت توسعه‌تون بالا باشه و هم تجربه‌ی خوبی داشته باشید؟…
) همون چیزیه که دنبالش می‌گردی!
-هسته کسب‌وکار (Core Domain): منطق اصلی برنامه که بدون وابستگی به هیچ چیزی کار میکنه.
- پورت‌ها (Ports) : رابط‌هایی که هسته از طریق اونا با دنیای بیرون ارتباط می‌گیره.
- آداپتورها (Adapters): وظیفه‌ی پیاده‌سازی پورت‌ها و برقراری ارتباط بین هسته و اجزای خارجی.
- کاهش وابستگی‌ها: بخش‌های مختلف مستقل از همدیگه هستن.
- انعطاف‌پذیری: راحت می‌تونی واسط‌های خارجی رو بدون دست زدن به هسته عوض کنی.
- بهبود تست‌پذیری: تست‌نویسی خیلی ساده‌تر میشه چون هسته مستقله.
- قابلیت تغییر فناوری: راحت می‌تونی تکنولوژی‌های خارجی رو بدون تغییرات زیاد جایگزین کنی.
این معماری به خصوص برای پروژه‌هایی که تغییرات زیادی دارن یا نیاز به انعطاف بالایی دارن عالیه. با این روش، کدهای تمیز و قابل تست می‌نویسی و راحت‌تر می‌تونی سیستم رو توسعه بدی.
https://lnkd.in/evuPH7cB
https://www.linkedin.com/posts/mohammad-abdorrahmani-051914198_agvaewaesaeuagv-agvaew-go-activity-7273570842481942528-vlh6?utm_source=share&utm_medium=member_desktop
#گولنگ #گو #go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
در معماری Vertical Slice، به جای اینکه سیستم را به لایه‌های مختلف (مثل لایه UI, business logic, data access) تقسیم کنیم، هر قابلیت یا ویژگی را به یک واحد مستقل به نام Slice تبدیل می‌کنیم. هر Slice شامل تمام اجزای مورد نیاز برای ارائه یک قابلیت خاص است. و هر Slice را می توان به عنوان یک برنامه کوچک با عملکرد متمایز دید.
هدف اینه که کد رو براساس ویژگی‌ها و نیازهای خاص دسته‌بندی کنیم، نه براساس موارد فنی.
تفکیک مسئولیت‌ها: هر قابلیت تو Slice خودش قرار می‌گیره، که باعث میشه وابستگی‌ها کمتر و کدها خواناتر بشن.
تست راحت‌تر: چون هر Slice مستقله، تست کردنش راحت‌تره.
مقیاس‌پذیری تیم: تیم‌های مختلف می‌تونن به صورت مستقل رو Slices مختلف کار کنن.
کاهش وابستگی‌ها: سیستم تمیزتر و مدیریت کردنش آسون‌تر میشه.
انعطاف‌پذیری در تغییرات: تغییرات تو یه Slice معمولاً تأثیری رو بقیه سیستم نداره.
پیچیدگی برای سیستم‌های کوچیک: این معماری ممکنه برای سیستم‌های کوچیک بیش از حد پیچیده باشه.
کد تکراری: بعضی کدها ممکنه بین Slices تکرار بشن.
یادگیری و تنظیم تیم‌ها: ممکنه یه کم زمان ببره تا تیم‌ها به این معماری عادت کنن.
سیستم‌های بزرگ و پیچیده: برای سیستم‌هایی که ویژگی‌های متعددی دارن.
تیم‌های چندگانه: وقتی تیم‌های مختلف رو قابلیت‌های مختلف کار می‌کنن.
سیستم‌های مبتنی بر میکروسرویس: این معماری با میکروسرویس‌ها خیلی خوب سازگاره.
سیستم‌های با نیاز به توسعه مستمر: برای سیستم‌هایی که نیاز به انتشار مکرر و سریع ویژگی‌های جدید دارن.
#گولنگ #گو #Go #Golang #Vertical_Slice
Please open Telegram to view this post
VIEW IN TELEGRAM
چطور گوروتین‌های گولنگ رو مدیریت کنیم؟💢
تا حالا شده تو برنامه‌هاتون بخواید یه کار طولانی رو نصفه‌نیمه قطع کنید؟ اینجاست که دو تا ابزار قدرتمند گولنگ یعنی Cancel و Done به کمکتون میان!
💠 Cancel:
فرض کنید یه گوروتین دارید که نمی‌خواید ادامه بده. با Cancel می‌تونید مستقیم بهش بگید "بسه، دیگه جلوتر نرو!" و منابعش هم آزاد بشه. این کارو با تابع context.WithCancel انجام میدید و هر وقت ()cancel رو صدا بزنید، همه گوروتین‌های مربوط به اون کانتکست متوقف میشن.
💠 Done:
حالا یه حالت دیگه: به جای اینکه دستی گوروتین‌ها رو متوقف کنید، بذارید خودشون بفهمن باید کارشون رو تموم کنن. اینجا Done به درد میخوره. Done یه کاناله که وقتی کانتکست تموم شد (مثلاً به خاطر تایم‌آوت یا لغو شدن)، بسته میشه و گوروتین‌ها سیگنال میگیرن که "وقت رفتنه!".
⭐️ خلاصه صحبت ها
💢 Cancel برای متوقف کردن مستقیمه.
💢 Done برای سیگنال دادن غیرمستقیمه.
💙 Anophel | آنوفل
#گولنگ #گو #go #golang
تا حالا شده تو برنامه‌هاتون بخواید یه کار طولانی رو نصفه‌نیمه قطع کنید؟ اینجاست که دو تا ابزار قدرتمند گولنگ یعنی Cancel و Done به کمکتون میان!
فرض کنید یه گوروتین دارید که نمی‌خواید ادامه بده. با Cancel می‌تونید مستقیم بهش بگید "بسه، دیگه جلوتر نرو!" و منابعش هم آزاد بشه. این کارو با تابع context.WithCancel انجام میدید و هر وقت ()cancel رو صدا بزنید، همه گوروتین‌های مربوط به اون کانتکست متوقف میشن.
حالا یه حالت دیگه: به جای اینکه دستی گوروتین‌ها رو متوقف کنید، بذارید خودشون بفهمن باید کارشون رو تموم کنن. اینجا Done به درد میخوره. Done یه کاناله که وقتی کانتکست تموم شد (مثلاً به خاطر تایم‌آوت یا لغو شدن)، بسته میشه و گوروتین‌ها سیگنال میگیرن که "وقت رفتنه!".
#گولنگ #گو #go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
Anophel
Anophel | Where Developers Create Their Own Path
Anophel is an ecosystem for developers—a place for those who prefer building over consuming. If you want to create tools, think differently, and forge your own path in coding, Anophel is with you.
توی این روش، کانال‌ها یکی‌یکی خونده میشن. یعنی اول داده‌های کانال اول رو می‌خونیم، وقتی تموم شد میریم سراغ کانال بعدی.
این روش ساده‌تره ولی ممکنه زمان بیشتری بگیره چون منتظره که هر کانال بسته بشه.
مثال: تصویر 1
گه دو کانال داشته باشیم که هر کدوم ۴ عدد تولید می‌کنن و هر عدد ۵۰ میلی‌ثانیه طول بکشه، زمان کلی ۳۵۰ میلی‌ثانیه میشه (یعنی یکی بعد از دیگری).
اینجا همه کانال‌ها همزمان خونده میشن و داده‌ها به کانال مقصد ارسال میشن. این روش سریع‌تره ولی ترتیب داده‌ها رو تضمین نمی‌کنه. معمولاً برای پروژه‌هایی که سرعت مهمه از این روش استفاده می‌کنیم.
مثال : تصویر 2
با استفاده از این روش، دو کانال ما فقط ۲۰۰ میلی‌ثانیه طول می‌کشن تا داده‌ها رو ترکیب کنن.
از روش Sequential استفاده کنید.
اگر کارایی و همزمانی اهمیت دارند: از روش Concurrent استفاده کنید.
#گو #گولنگ #go #golang #goroutines
Please open Telegram to view this post
VIEW IN TELEGRAM
یا شاید دلت بخواد یه بار فانکشن‌ها رو آماده کنی و هر وقت خواستی دوباره اجراشون کنی؟
اینجاست که مفهوم Wrapper Types تو گولنگ میاد وسط. تو این پست، می‌خوام یه راه حل تمیز و شیک بهت معرفی کنم: ConcRunner
Wrapper Types چیه؟
فرض کن یه چیزی داری مثل اجرای فانکشن‌ها به صورت همزمان (concurrently). خب، این کار خودش یه ذره پیچیدگی داره چون باید با goroutineها و sync.WaitGroup کلنجار بری. حالا ما اومدیم یه نوع جدید به اسم ConcRunner درست کردیم که این داستان رو می‌پیچه تو خودش. دولوپر فقط میگه «هی، این فانکشن‌هام رو بگیر و همزمان اجراشون کن»، دیگه نمی‌پرسه چطور این کار انجام میشه.
مثال تصویر 1
سادگی در استفاده: دیگه کسی لازم نیست نگران goroutine و sync.WaitGroup باشه.
قابلیت استفاده مجدد: فانکشن‌ها رو هر چند بار که بخوای می‌تونی اضافه و اجرا کنی.
محافظت از جزئیات: کل سینک شدن و داستان‌های پشت پرده رو می‌سپری به ConcRunner، تمیز و بی‌دردسر.
#گو #گولنگ #go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
یه راه خفن برای کنترل این داستان استفاده از چیزی به اسم Semaphore هست. اینجوری می‌تونی تعداد گوروتین‌های در حال اجرا رو محدود کنی.
1. یه کانال با ظرفیت مشخص (N) درست می‌کنی که این ظرفیت میشه تعداد گوروتین‌های همزمانی که می‌خوای اجرا بشه.
2. کانال رو با N تا "توکن" (هرچیزی مثل عدد) پر می‌کنی.
3. هر گوروتین قبل از اجرا باید یه توکن از کانال بگیره و وقتی کارش تموم شد، توکن رو برمی‌گردونه.
4. اگه توکن نباشه، گوروتین منتظر می‌مونه تا یکی آزاد بشه.
کد داخل تصویر یه مثال ساده با N=2 هست.
#Golang #go #گو #گولنگ
Please open Telegram to view this post
VIEW IN TELEGRAM
بیاید مثال داخل تصویر رو بررسی کنیم.
اینجا فرستنده منتظر گیرنده نمی‌مونه، ولی اگه تعداد داده‌ها بیشتر از ظرفیت بافر بشه چی؟ آیا باید اندازه بافر رو زیاد کنیم یا ی استراتژی دیگه به کار ببریم؟
#گولنگ #گو #بهینه‌سازی_کد #Go
Please open Telegram to view this post
VIEW IN TELEGRAM
Anophel | آنوفل
💠چندتا گیرنده همزمان (Worker Pool)
وقتی کار زیاده، چرا یه گیرنده داشته باشیم؟ می‌تونیم چند گوروتین گیرنده راه بندازیم تا موازی کار کنن. مثلاً:
stream := make(chan int, 5)
go func() {
for i := 1; i <= 10; i++ { fmt.Println("فرستنده:", i)
stream <- i }
close(stream) // کانال بسته میشه}()
for i := 0; i < 3; i++ { go func(id int) {
for data := range stream { fmt.Printf("گیرنده %d: داده %d پردازش شد\n", id, data)
} }(i)
}
با این روش چند تا گوروتین داده‌ها رو به صورت همزمان میگیرن و پردازش می‌کنن.
💠کنترل فشار لحظه‌ای (Backpressure)
اگه نمی‌خوایم سیستم پر بشه و فرستنده هی داده بریزه، کانال‌های بدون بافر می‌تونن کمک کنن. فرستنده منتظر می‌مونه و فشار کنترل میشه.
💠محدود کردن نرخ ارسال (Rate Limiter)
وقتی گیرنده‌ها نمی‌تونن سریع پردازش کنن، می‌تونیم سرعت فرستنده رو محدود کنیم. با استفاده از time.Ticker خیلی راحت میشه این کارو انجام داد:
rateLimiter := time.Tick(100 * time.Millisecond)
go func() { for i := 1; i <= 10; i++ {
<-rateLimiter fmt.Println("فرستنده:", i)
stream <- i }
close(stream)}()
💠صف‌های پیشرفته (Priority Queue)
اگه اولویت‌بندی مهمه، می‌تونیم از صف‌های اولویت‌دار استفاده کنیم.
⭐️آخرش چی؟
همه چی به نیاز پروژه بستگی داره:
اگه بار بالاست و توزیع شده، از worker pool استفاده کن.
اگه نمی‌خوای سیستم منفجر بشه، کانال‌های بدون بافر و محدود کردن نرخ ارسال جواب میده.
برای نیازهای خاص مثل اولویت‌بندی، ابزارهای پیشرفته‌تر لازم داری.
#گولنگ #گو
#بهینه‌سازی_کد #go #Golang@anophel
Please open Telegram to view this post
VIEW IN TELEGRAM
حالا جذابیتش چیه؟ هر مرحله، یه مسئولیت خاص داره و میشه به راحتی تغییرش داد، کم یا زیادش کرد، یا حتی تو پروژه‌های دیگه استفاده‌ش کرد.
تو یه پخش زنده، ممکنه داده‌ها این شکلی پردازش بشن:
این مدل به راحتی قابل توسعه و سفارشی‌سازی هست.
توضیح مراحل:
rangeGen: اعداد رو در بازه مشخص تولید میکنه.
takeLucky: فقط اعداد خوش‌شانس (قابل تقسیم بر 7 ولی نه بر 13) رو انتخاب میکنه.
merge: داده‌های خروجی از چند کانال مستقل رو یکی میکنه.
sum: جمع اعداد خوش‌شانس و تعدادشون رو محاسبه میکنه.
printTotal: نتایج رو چاپ میکنه.
راستی، تا حالا تو پروژه‌هاتون از همچین روشی استفاده کردین؟
خوشحال می‌شم تجربه‌هاتون رو بشنوم.
#گو #گولنگ #go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
ولی خب، چون احتمال داره عدد زوج تولید بشه، پانیک می‌خوریم و برنامه می‌ترکه!
برای مدیریت این خطا، اولین ایده ممکن اینه که یه recover تو گوروتین اصلی بذاریم حالا اگر بیاییم و یه recover توی گوروتین اصلی بیذاریم، ولی بازم پانیک میکنه! چرا؟
چون recover فقط توی همون گوروتینی جواب میده که خطا توش اتفاق افتاده. اینجا خطاها توی گوروتین‌های کارگر اتفاق میفته، ولی ما داریم توی گوروتین اصلی recover رو صدا می‌زنیم. (گوروتین ها مستقل از هم دیگه هستن!)
اینجوری هر گوروتین خودش خطای خودش رو مدیریت میکنه و توی گوروتین اصلی متوجه می‌شیم که همه چیز اوکی بود یا نه.
#گو #گولنگ #Go #golang
Please open Telegram to view this post
VIEW IN TELEGRAM