Dev Perfects – Telegram
Dev Perfects
40 subscribers
9.23K photos
1.26K videos
468 files
13K links
بخوام خیلی خلاصه بگم
این کانال میاد مطالب کانالای خفن تو حوزه تکنولوژی و برنامه نویسی رو جمع میکنه

پست پین رو بخونید
https://news.1rj.ru/str/dev_perfects/455


ارتباط:
https://news.1rj.ru/str/HidenChat_Bot?start=936082426
Download Telegram
Forwarded from Gopher Academy
در فایل go.mod، toolchain برای تعیین نسخه ابزار Go (مانند go و ابزارهای مرتبط با آن) استفاده می‌شود. این ویژگی به شما امکان می‌دهد تا پروژه را به نسخه خاصی از ابزار Go مقید کنید، حتی اگر نسخه پیش‌فرض go در سیستم شما متفاوت باشد.
نحوه استفاده از toolchain
اگر در فایل go.mod خطی به شکل زیر مشاهده کنید:
toolchain go1.20
این به این معنی است که پروژه نیازمند نسخه go1.20 است و باید از این نسخه استفاده شود، صرف‌نظر از نسخه Go نصب‌شده روی سیستم.
کاربردهای اصلی toolchain
اطمینان از سازگاری نسخه Go
با استفاده از toolchain، می‌توانید مطمئن شوید که همه توسعه‌دهندگان و محیط‌های CI/CD از یک نسخه خاص از ابزار Go استفاده می‌کنند.
مدیریت نسخه‌ها در پروژه‌های تیمی
این ویژگی تضمین می‌کند که مشکلات ناشی از ناسازگاری نسخه‌ها (مانند تغییرات در syntax یا behavior) به حداقل برسند.
ساخت خودکار با نسخه مشخص
اگر نسخه‌ای که در toolchain تعریف شده، روی سیستم نصب نشده باشد، ابزار Go به‌طور خودکار آن را از وب‌سایت Go دریافت و نصب می‌کند.
نکته مهم درباره toolchain
این قابلیت با ابزار Go نسخه 1.21 و بالاتر در دسترس است. اگر نسخه Go قدیمی‌تری دارید، خط مربوط به toolchain در فایل go.mod نادیده گرفته خواهد شد.
toolchain مستقل از دستور go در فایل go.mod عمل می‌کند. دستور go نسخه حداقل زبان Go برای کدنویسی و بیلد کردن را مشخص می‌کند: go 1.20
مثالی کامل از go.mod
module example.com/myproject go 1.20 toolchain go1.20 require ( github.com/some/library v1.2.3 )
go 1.20: نسخه حداقل برای ویژگی‌های زبان Go.
toolchain go1.20: نسخه ابزار Go که پروژه باید با آن ساخته شود.
جمع‌بندی
toolchain یک ابزار قوی برای مدیریت و تثبیت نسخه ابزار Go در پروژه‌های بزرگ است. این قابلیت به‌خصوص در محیط‌های توسعه تیمی و پروژه‌هایی که وابستگی شدیدی به نسخه خاصی از Go دارند، بسیار مفید است.

https://news.1rj.ru/str/addlist/KpzXaiSpKENkMGM0
Forwarded from Gopher Academy
در فایل go.mod، دو دستور go و toolchain نقش‌های متفاوتی دارند، هرچند هر دو به نسخه‌های Go مرتبط هستند. در ادامه به تفاوت‌های این دو دستور می‌پردازیم:
1. go: مشخص کردن نسخه حداقل زبان Go
این دستور نشان‌دهنده نسخه حداقل زبان Go است که پروژه باید با آن سازگار باشد. به عبارتی، این مقدار مشخص می‌کند که کدام نسخه از ویژگی‌های زبان و استاندارد Go برای کامپایل و اجرای پروژه لازم است.
کاربرد:
تعیین نسخه حداقل زبان Go که برای این پروژه لازم است.
اگر نسخه ابزار Go نصب‌شده روی سیستم از این مقدار کمتر باشد، ابزار Go اجازه بیلد (build) یا اجرای پروژه را نمی‌دهد.
این دستور به طور مستقیم بر رفتار زبان و کتابخانه‌های استاندارد تأثیر می‌گذارد.
مثال:
go 1.20
ویژگی‌های زبان و کتابخانه‌های استاندارد Go 1.20 به بالا در دسترس هستند.
اگر نسخه Go نصب‌شده روی سیستم از 1.20 کمتر باشد، هنگام اجرای دستورات go build یا go run خطا خواهید گرفت.
2. toolchain: تعیین نسخه ابزار Go
این دستور که در Go 1.21 معرفی شده، نسخه‌ای از ابزار Go (Go Toolchain) را مشخص می‌کند که پروژه باید از آن استفاده کند. ابزار Go شامل مواردی مانند go build, go run, go mod, و غیره است.
کاربرد:
مجبور کردن سیستم یا محیط CI/CD به استفاده از نسخه مشخص ابزار Go، صرف‌نظر از نسخه نصب‌شده روی سیستم.
در صورت نبود نسخه مشخص‌شده از ابزار Go، به طور خودکار آن نسخه دانلود و نصب می‌شود.
مثال:
toolchain go1.20
حتی اگر نسخه go روی سیستم شما 1.19 باشد، ابزار Go نسخه 1.20 را دانلود و استفاده می‌کند.
این خط تضمین می‌کند که تمام ابزارهای مرتبط با Go (کامپایلر، مدیریت ماژول‌ها، و غیره) از نسخه خاصی پیروی کنند.
تفاوت‌های اصلی
ویژگیgotoolchainهدفنسخه حداقل زبان Goنسخه ابزار Go (Go Toolchain)اثرگذاریروی ویژگی‌های زبان و استانداردهاروی ابزارهای مرتبط با Goزمان معرفیقدیمی (از ابتدای Go Modules)جدید (از Go 1.21 به بعد)رفتار در نبود نسخهخطا می‌دهدنسخه مناسب را دانلود و استفاده می‌کندتأثیر بر ساخت پروژهفقط بررسی زبان و استانداردهاتعیین دقیق نسخه ابزار برای کل فرآیند
چرا از هر دو استفاده کنیم؟
go: برای اطمینان از این که کد با نسخه خاصی از زبان سازگار است.
toolchain: برای تضمین این که ابزارها و محیط ساخت دقیقاً از نسخه خاصی استفاده کنند.
مثال ترکیبی
module example.com/myproject go 1.20 // حداقل نسخه زبان Go toolchain go1.21 // نسخه ابزار Go
زبان Go باید حداقل 1.20 باشد (برای ویژگی‌های زبان و استانداردها).
ابزارهای مرتبط با Go باید از نسخه 1.21 استفاده کنند (حتی اگر نسخه نصب‌شده 1.20 باشد، نسخه 1.21 دانلود و استفاده می‌شود).
نتیجه‌گیری
go برای تعیین حداقل سازگاری زبان Go است.
toolchain برای کنترل نسخه ابزار Go در محیط‌های مختلف به کار می‌رود.
ترکیب این دو، کنترل دقیق‌تری بر محیط توسعه و اجرای پروژه فراهم می‌کند.


https://news.1rj.ru/str/addlist/KpzXaiSpKENkMGM0
Forwarded from Linuxor ?
توزیع های لینوکسی رو فقط از لحاظ ظاهری نمیتونین کاستومایز کنید از لحاظ باطنی هم می‌تونین.


@Linuxor
Forwarded from Armon technical logs (armon Taheri)
Media is too big
VIEW IN TELEGRAM
چند روز پیش صحبتی انجام شد توی یکی از اسپیس های توییتر راجع بحث استخدام و بحران نیرو متخصصی که در ایران شکل گرفته و شرایط به شدت خاص شرکت های تک ایران و اقای علی تولایی اشاره کردن به ارایه ای که توی جشن انتشار دبیان ۱۲ داشتن
به نظرم خالی از لطف نیست که یه بار دیگه این صحبت هارو گوش بدیم
Forwarded from Linuxor ?
انقدر گفتین فرانت کارا برنامه نویس نیستن، خارجی هام یاد گرفتن😂


@Linuxor
Forwarded from Agora (Alireza Azadi)
یه بلاگ پستی رو تازه خوندم که نویسنده میاد این رو بررسی میکنه که: اگر از LLM ها بخواییم راه‌حل یک مسئله رو برامون پیاده‌سازی کنه و هربار که جوابی رو پیاده کرد، ازش بخواییم که اون رو بهتر کنه، آیا واقعا خروجی بهتر میشه یا نه؟

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

خلاصه، میاد و یک مسئله معروف رو میده به Claude 3.5 Sonnet و قدم به قدم خروجی رو بررسی و تحلیل میکنه. به دو روش هم پیش میبره، یک بار خیلی معمولی و یک بار دیگه هم با Prompt Engineering. به‌نظرم جالبه. هم از نظر دیدن عملکرد LLMها هم این که کد پایتونی که بعضی‌ جاها خروجی میده چیز‌های جالبی داشت واسم که خودم ازشون چیز یاد گرفتم D:

https://minimaxir.com/2025/01/write-better-code/#fnref:1
👍1
Forwarded from C & micro & fpga (فرهاد ناصری زاده 🐍)
Light Dimmer

@c_micro
Forwarded from Alireza Azadi
ولاگ و بلاگری - بخش اول
ــــــــــــــــــــــ

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

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

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

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

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

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

حالا وقتشه که بفهمیم هزینه‌ی خورد و خوارک تو شهر شهناز چقدره. از نظر قدرت تولید محتوا، شهناز پا به‌پای بزرگترین مستند‌ساز‌های بی‌بی‌سی و نشنال‌جغرافی پیش میره. مستند روایی‌های که حتماً شما رو میخ‌کوب میکنه پای مانیتورتون. دوربین رو‌دست‌ها و POVهای شاهکار از لحظات نون خریدن توی فروشگاه تا لحظات نفس‌گیر انتخاب بین مرغ و تخم‌مرغ از یخچال فروشگاه و صدای گوینده (با گویندگی شهناز) که با لحنی آرام، در صحنه‌‌ای که از هیجان نفس‌ها در سینه حبس شده میگه: «عاممممممممممم نمیدونم بین اینا کدومو انتخاب کنم»... من رو یاد شاهکار‌های دیوید اتنبرو میندازه در مستند‌های حیات وحش. و این‌ها همه، درخدمت سکانس پایانی هستند:
Forwarded from Alireza Azadi
ولاگ و بلاگری - بخش دوم
ــــــــــــــــــــــ

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

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

ذاتاً به‌نظر من بلاگری/ولاگری نه تنها کار بدی نیست که خیلی هم میتونه جذاب باشه. همون مثال ونیز که باهاش شروع کردم. یک ولاگ میتونست خیلی بی‌واسطه به سوال من راجع‌به زندگی در ونیز جواب بده و پارو فراتر بذاره واین امکان رو به من بده که درک عمیق‌تری رو نسب به یک شهروند ونیزی و چالش‌های جدی‌ترش که احتمالا توی مستند‌ها نمیشه پیداش کرد کسب کنم. به‌نظرم انتقال دسته‌اول تجربه‌ی زیستن خیلی خوب و اساسیه و البته گرانبها. من اینطور استدلال میکنم که تجربه‌ی زیستن هرکسی با هرکسی متفاوته و ماجرایی که من نوعی تعریف میکنم قطعا متناسبه با جهان‌بینی من. اگر قرار باشه من روایتی داشته باشم از اون چه که بر من گذشت، حتما و منطقا باید برخواسته از دیدی باشه که من دارم. این که من بیفتم کپی کاری و دست بردن در روایت، دیگه این تجربه‌ی زیستن من نیست پس در نتیجه دوزار هم نمیارزه. برای همین میگم که بلاگر/ولاگری که شکل روایی خودش رو نداره یا اصلا روایت خودش رو نداره کارش نه‌تنها شایسته تشویق و دنبال کردن نیست که سزاوار نقدی خیلی تند و تیزه.
Forwarded from Anophel | آنوفل
💢آیا تا حالا براتون پیش اومده تو کدهای Go، فرستنده ی داده منتظر بمونه تا گیرنده آماده بشه؟

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

بیاید مثال داخل تصویر رو بررسی کنیم.

اینجا فرستنده منتظر گیرنده نمی‌مونه، ولی اگه تعداد داده‌ها بیشتر از ظرفیت بافر بشه چی؟ آیا باید اندازه بافر رو زیاد کنیم یا ی استراتژی دیگه به کار ببریم؟

💠سوال: چطور می‌تونیم بدون افزایش بیش از حد اندازه‌ی بافر، عملکرد و کارایی برنامه رو در شرایط بار بالا تضمین کنیم؟

#گولنگ #گو #بهینه‌سازی_کد #Go
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Anophel | آنوفل
تست
Forwarded from Anophel | آنوفل
تست
Forwarded from کانال مهرداد لینوکس (Mehrdad Linux)
شرکت های CA مثل Let’s Encrypt که گواهینامه SSL صادر میکنند

برای احراز هویت certificate های دامنه ها
مکانیزم CRL را جایگزین مکانیزم OCSP به علت مشکلات Privacy Performance ،Availability کردند برای درک بهتر به مبحث OCSP Stapling مراجعه کنید

💠 پروتکل تعیین وضعیت گواهی آنلاین(Online Certificate Status Protocol) یا همان OCSP برای پی بردن به وضعیت ابطال یک SSL (TLS)x.۵۰۹ است

🔥 مشکلی که داره در مورد privacy کلاینت‌ها از کاربران می‌خواهد با نرم افزار ثالثی ارتباط بگیرند تا اعتبار گواهی معلوم شود.
دلیل عدم استفاده CA ها جلوگیری از انتشار ip مربوط به بازدید کنندگان وب سایت ها برای CA ها و حفظ Privacy است.

❤️ چون کسی به این محتوا ها علاقه ای ندارد این محتوا به عنوان یادداشت شخصی سایلنت منتشر شده 💐🌺
https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/
#security
من وبسایت http://thewebscraping.club رو بار ها معرفی کردم که در مورد وب‌اسکرپینگ مطالب مختلفی میذاره. الان تصمیم گرفتم به مرور با http://notebooklm.google برای پست هاش پادکست بسازم و با روشی که دارم براش زیرنویس فارسی تولید کنم و تو یوتیوب بذارم.

@DevTwitter | <وحید/>
Forwarded from Agora (Alireza Azadi)
ولاگ و بلاگری - بخش دوم
ــــــــــــــــــــــ

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

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

ذاتاً به‌نظر من بلاگری نه تنها کار بدی نیست که خیلی هم میتونه جذاب باشه. همون مثال ونیز که باهاش شروع کردم. یک ولاگ میتونست خیلی بی‌واسطه به سوال من راجع‌به زندگی در ونیز جواب بده و پارو فراتر بذاره واین امکان رو به من بده که درک عمیق‌تری نسب به یک شهروند ونیزی و چالش‌های جدی‌ترش که احتمالا توی مستند‌ها نمیشه پیداش کرد کسب کنم. به‌نظرم انتقال دسته‌اول تجربه‌ی زیستن خیلی خوب و اساسیه و البته گرانبها. من اینطور استدلال میکنم که تجربه‌ی زیستن هرکسی با هرکسی متفاوته و ماجرایی که من نوعی تعریف میکنم قطعا متناسبه با جهان‌بینی من. اگر قرار باشه من روایتی داشته باشم از اون چه که بر من گذشت، حتماً و منطقا باید برخواسته از دیدی باشه که من دارم. این که من بیفتم به کپی‌کاری و دست بردن در روایت تا به خیالم جذابش کنم، این دیگه تجربه‌ی زیستن من نخواهد بود. چون میخوام داستانی رو تعریف کنم که همه تعریف کردن و فروخت و حالا نوبت منه که بفروشمش. و به طبع این داستان حتماً دوزار هم نمیارزه. برای همین میگم که بلاگری که شکل روایی خودش رو نداره یا اصلا روایت خودش رو نداره کارش نه‌تنها شایسته احترام و تشویق نیست که سزاوار نقد‌های تند و تیزه.
Forwarded from 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
Forwarded from ~Loveaвle (Hanie)
به نظرم بزرگ‌ترین چیزی که آدما باید یاد بگیرن، بیرون کشیدنه!
از هرکی، هرچی، هرموقع که نیاز بود.

@luvablee
فکت زندگی