به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد. کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

@DevTwitter | <Hossein Moradi/>

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

https://blogfa.sohrabbehdani.ir/kernel-busybox


#فقط_برای_سرگرمی

@SohrabContents

🔵 عنوان مقاله
switch Statements in Go

🟢 خلاصه مقاله:
این مطلب از Golang Weekly به‌صورت عملی سراغ عبارت‌های switch در Go می‌رود و نشان می‌دهد چگونه می‌توان به‌جای زنجیره‌های if/else طولانی، کدی خواناتر نوشت. ابتدا نحو و قواعد ارزیابی switch، استفاده از چند مقدار در یک case، نقش default، و این نکته که در Go سقوط خودکار بین caseها وجود ندارد و فقط با fallthrough فعال می‌شود، توضیح داده می‌شود. سپس فرم بدون تگِ switch { ... } برای نگارش نگهبان‌های منطقیِ مرتب معرفی می‌شود.

بخش بعدی به type switch اختصاص دارد: وقتی با interface سروکار دارید، switch روی v.(type) اجازه می‌دهد بر اساس نوع واقعی تصمیم بگیرید، از nil به‌درستی عبور کنید و محدوده متغیرها در سربرگ switch و داخل caseها را مدیریت کنید. مقاله الگوهای کاربردی مثل مسیردهی بر اساس روش HTTP، دسته‌بندی خطاها برحسب نوع، شاخه‌بندی زمان‌محور و استفاده از ثابت‌ها را مرور می‌کند و در کنار آن به نکات سبک و کارایی اشاره دارد. جمع‌بندی این است که با رعایت چند قاعده ساده و پرهیز از دام‌های متداول، switch در Go ابزاری شفاف، قابل نگهداری و گاه سریع‌تر از شرط‌های زنجیره‌ای خواهد بود.

#Go #Golang #GolangWeekly #switch #TypeSwitch #GoTips #Programming #Backend

🟣لینک مقاله:
https://golangweekly.com/link/176626/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

این پروژه اپن سورس جالب strix رو یه نگاه بندازین. یه جورایی انگار یه تیم هکر هوش مصنوعی اپن‌سورس استخدام کردین که شبانه‌روزی حواسشون به اپلیکیشن‌هاتون هست.
این ایجنت‌های AI دقیقاً مثل هکرهای واقعی رفتار می‌کنن. کد شما رو به صورت داینامیک اجرا می‌کنن، آسیب‌پذیری‌ها رو پیدا می‌کنن و برای اینکه ثابت کنن الکی نمیگن، براتون PoC (اثبات مفهومی) واقعی می‌سازن.

بهترین بخشش اینه که دیگه از شر اون همه false positive (هشدارهای الکی) که ابزارهای اسکن استاتیک میدن خلاص میشید. Strix واقعاً باگ رو پیدا می‌کنه و بهتون نشون میده.
یه جعبه ابزار کامل هکری هم داره:
- پراکسی HTTP
- اتوماسیون مرورگر
- محیط ترمینال
- و حتی ران‌تایم پایتون

تازه، می‌تونه تو CI/CD شما هم ادغام بشه و جلوی کدهای آسیب‌پذیر رو قبل از اینکه اصلاً به پروداکشن برسن بگیره.
به جای اینکه هفته‌ها منتظر تست نفوذ دستی بمونید، با Strix می‌تونید تو چند ساعت یه تست کامل بگیرید.
Github: https://github.com/usestrix/strix

@DevTwitter | <Mehdi Allahyari/>

نمی دونم این چقدر به کار بقیه میاد ولی اگر Vibe-Coding می کنید و ایجنت کلی روی پروژتون کامنت های بیخود نوشت می تونید با استفاده از این اسکریپت پایتونی که نوشتم کامنت هایی که نیاز ندارید رو پاک کنید

https://github.com/naseridev/vibecleaner

@DevTwitter | <Nima Naseri/>

همون‌طور که احتمالاً می‌دونید، AWS یکی دو هفته پیش ریجن us-east-1 رو از دست داد و باعث شد بخش قابل‌توجهی از اینترنت در دنیا یا کند بشه یا عملاً قطع.
کلی هم خبر و محتوای جالب منتشر شد؛ از هم‌دردی شرکت‌ها با مهندس‌های AWS گرفته تا ابراز نگرانی درباره این‌که اصلاً سازوکار اینترنت نباید طوری باشه که از کار افتادن یه region، این‌همه کسب‌وکار و کاربر رو تحت تأثیر بذاره.

در این بین، بامزه‌ترین خبری که خوندم مربوط به شرکت Eight Sleep بود که تخت‌های هوشمند تولید می‌کنه. به خاطر مشکل AWS، نیمه‌شب ارتباط این تخت‌ها با سرورها قطع شده بود و دیگه نمی‌تونستن دماشون رو درست تنظیم کنن. بعضی‌هاشون زیادی داغ شده بودن و خیلی‌ها نتونستن اون شب درست بخوابن 😄
اینجا بخونید:
🔗 Owners of Luxury Smart Beds Literally Lost Sleep Due to AWS Outage

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

به این آمادگی می‌شه در سطوح مختلف فکر کرد. از بهبود فرآیندها و ابزارهای مدیریت incident گرفته تا بازبینی استراتژی زیرساخت، انتخاب locationهای متفاوت و تنوع پلتفرم‌ها.

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

به نظرم این تمرین ذهنی در تصمیم‌گیری‌های فنی آینده‌امون کمک می‌کنه و در چند پست بعدی درباره‌ش خواهم نوشت. شما هم بهش فکر کنید و اگر دوست داشتید توی بخش ‌کامنت بنویسید.

@aminrbg

🔵 عنوان مقاله
The first release candidate of Bubble Tea 2.0

🟢 خلاصه مقاله:
اولین release candidate برای Bubble Tea 2.0 منتشر شده و نشان می‌دهد این فریم‌ورک محبوب TUI به انتشار نهایی نزدیک است. مهم‌ترین تغییر، جابه‌جایی import URL است؛ بنابراین لازم است مسیرهای import در پروژه‌ها به‌روزرسانی و تست شوند. علاوه بر این، تغییرات و بهبودهایی که پیش‌تر در یادداشت‌های beta آمده بود در این نسخه جمع‌بندی شده‌اند. پیشنهاد می‌شود برای جلو افتادن از انتشار نهایی، همین حالا RC را امتحان کنید، وابستگی‌ها را به‌روز کنید، تست‌ها را اجرا کنید و بازخورد بدهید.

#BubbleTea #TUI #ReleaseCandidate #ImportURL #Beta #DeveloperTools #OpenSource

🟣لینک مقاله:
https://golangweekly.com/link/176661/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

امسال Black Hat 2025 اروپا در انگلستان برگزار می‌شود.

می‌دونیم که تب استفاده از AI الان زیاد است که این قاعدتا بد نیست و در این کنفرانس هم چندین AI در زمینه کمک به امنیت معرفی خواهند شدند که زودتر از کنفرانس می‌توانید، آن ها را نصب و آزمایش کنید.
https://medium.com/@Ethansalan/black-hat-europe-2025-arsenal-8-ai-security-tools-transforming-cybersecurity-ccd08c472aaa

@DevTwitter | <VAHID NAMENI/>

قبل از شروع این سری پست‌ها، یه پرانتز باز کنم.

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

اگر به شرکت در چنین گفت‌وگویی علاقه‌مندین، چه روز و ساعتی براتون مناسب‌تره؟ (به وقت ایران)
👇

🔶 خواهران و برادران : برای مدیریت بحران آب میگم.

یک تانکر هزار لیتری بخرید و نصب کنید. قیمتش ۷ یا ۸ میلیون تومانه

تانکر با آب شهری وصل می کنید که شناور داره و تانکر پر شد, خودش آب رو قطع می کند.

اگر روزی با قطع آب مواجه شدید, بتوانید خودکار با آب تانکر وصل بشید.

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

نه فقط ایران کمبود آب داره که بلکه با تغییرات اقلیمی ترکیه و کشورهای اروپایی درگیر بحران آب کرده و این کشورها در برخی استان ها اصلا آب ندارن.

@TheRaymondDev

🔶 بفرمایید.

@TheRaymondDev

به MVC میگه Clean Architecture !!
شاید من معنی Clean Architecture را بد متوجه شدم.

https://youtube.com/watch?v=H9Blu0kWdZE

@DevTwitter | <Babak.uk/>

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

باورتان می‌شود که هکرها می‌توانند از گفتگوهای شما با چت‌ چی‌پی‌تی (یا هر هوش مصنوعی مشابهی) مطلع شوند؟ البته این موضوع شرایط خاصی دارد که در ادامه توضیح می‌دهیم:

مایکروسافت در یک گزارشی پژوهشی جدید از یک حمله جدید با نام «Whisper Leak» خبر داده که می‌تواند بدون شکستن رمزنگاری، موضوع مکالمات کاربران با مدل‌های زبانی بزرگ (LLM) را شناسایی کند.

این حمله، به خاطر ضعف در پروتکل‌های رمزنگاری مانند HTTPS نیست، بلکه یک حمله‌ی تحلیل ترافیک (Side-Channel) محسوب می‌شود.

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

- اندازه بسته‌های داده
- فاصله زمانی میان ارسال بسته‌ها

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

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

آزمایش‌ها نشان داده‌اند که در برخی سناریوها، دقت این تشخیص به حدود ۹۸ درصد می‌رسد. این موضوع به‌ویژه از منظر حریم خصوصی نگران‌کننده است.

مایکروسافت تأکید می‌کند که این یافته‌ها به معنی ناامن بودن رمزنگاری نیست، بلکه نشان می‌دهد نحوه پیاده‌سازی استریم پاسخ در سرویس‌های هوش مصنوعی می‌تواند اطلاعات فراداده‌ای (متادیتا) حساسی را افشا کند.

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

- استفاده از VPN معتبر می‌تواند تحلیل ترافیک را برای مهاجم دشوارتر کند.

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

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

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

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

@DevTwitter | <NooshDaroo/>

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۱۶۷۵

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

#مولانا | گنجور
📍@iipoem

⭐️جلوگیری از حملات زیر به سادگی با یادگیری یک تکنیک لینوکسی:

حملاتی که به آدرس‌دهی ثابت متکی‌اند (مثل ROP یا Return-Oriented Programming)
حملات سرریز بافر (Buffer Overflow Attacks)
بهره‌برداری از فساد حافظه (Memory Corruption Exploits)
حملات برنامه‌نویسی بازگشت‌محور (Return-Oriented Programming - ROP

با فعال سازی KASLR:

🔹در هر بار بوت شدن سیستم، هسته در آدرسی تصادفی از حافظه بارگذاری می‌شود — یعنی آدرس هسته در هر بوت متفاوت است. این ویژگی باعث می‌شود حملاتی که به آدرس‌دهی ثابت متکی‌اند (مثل ROP یا Return-Oriented Programming) تقریباً غیرممکن شوند، چون مهاجم دیگر نمی‌داند کد هسته یا ساختارهای حساس حافظه دقیقاً کجا هستند.
1️⃣ فایل تنظیمات GRUB را باز کنید:

sudo nano /etc/default/grub


2️⃣ خط زیر را پیدا کنید:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


3️⃣ گزینه‌ی kaslr را به انتهای آن اضافه کنید:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash kaslr"


4️⃣ فایل را ذخیره کنید و سپس تنظیمات GRUB را به‌روزرسانی کنید:

sudo update-grub


5️⃣ سیستم را ری‌استارت کنید.

بررسی فعال بودن:kaslr
sudo dmesg | grep -i "Kernel random"

🔻پست و آموزش بیشتر در وبلاگ آکادمی:
https://learninghive.ir/linux-blogs/

⭐️ افزایش امنیت لینوکس با یک نکته و تنظیم ساده
🚫 حملاتی که با این روشی که میگم بی‌اثر می‌شوند:

🔸 Cold Boot Attack (حمله بوت سرد)
🔸Tampered Resume Attack (حمله از طریق فایل Hibernate آلوده)
🔸 Memory-forensic & Offline Extraction (بازیابی حافظه و کلیدها از دیسک)
🔸 Privilege Escalation از طریق بازگردانی حافظه آلوده

🔹 با فعال کردن پارامتر noresume به کرنل لینوکس می‌گوید که هیچ‌وقت از پارتیشن یا فایل hibernation برای بازگرداندن حافظه استفاده نکند. وقتی سیستم Hibernate می‌شود، محتوای RAM روی دیسک ذخیره می‌شود تا در بوت بعدی دوباره بارگذاری گردد.
اما اگر شخصی به این فایل‌ها دسترسی پیدا کند، می‌تواند داده‌های حساسی مثل کلیدهای رمزنگاری، پسوردها یا نشست‌های فعال را استخراج کند.
🔸 با فعال‌کردن noresume، کرنل کاملاً از این پارتیشن صرف‌نظر می‌کند و هیچ داده‌ای از RAM ذخیره‌شده روی دیسک بازگردانی نمی‌شود.
یعنی Hibernate (Suspend-to-Disk) غیرفعال میشه.
🔸 نتیجه: Hibernate از کار می‌افتد، اما سیستم در برابر حملات و دسترسی به حافظه رمزنگاری‌شده ایمن‌تر می‌شود.

1️⃣ فایل زیر را ویرایش کنید:
/etc/default/grub
2️⃣ پارامتر noresume را به خط زیر اضافه کنید:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
3️⃣ تنظیمات را اعمال کنید:
sudo update-grub
4️⃣ سیستم را ریبوت کنید ✅
🛡 از این پس، لینوکس شما دیگر از حالت Hibernate استفاده نخواهد کرد و داده‌های RAM ذخیره‌شده روی دیسک به‌طور کامل نادیده گرفته می‌شوند.

🔻پست و آموزش بیشتر در وبلاگ آکادمی:
https://learninghive.ir/linux-blogs/

راهنمای جامع همزمانی در گولنگ

همزمانی (Concurrency) یکی از قوی‌ترین ویژگی‌های زبان Go است. این مقاله مفاهیم کلیدی همزمانی را توضیح می‌دهد تا بتوانید برنامه‌های قابل اعتماد و کارآمد بنویسید.


1. ا CSP و GMP: اساس همزمانی گولنگ

CSP (Communicating Sequential Processes)


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

اصل اساسی: "برای به اشتراک گذاشتن حافظه ارتباط برقرار کنید، نه برای ارتباط حافظه را به اشتراک بگذارید."

// مثال ساده: ارسال پیام از طریق کانال
func example() {
    messages := make(chan string)
    
    go func() {
        messages <- "سلام از Goroutine!"
    }()
    
    msg := <-messages
    fmt.Println(msg)
}

GMP (Goroutine, M, P Model)

گولنگ از یک scheduler هوشمند استفاده می‌کند:

- G (Goroutine):
واحد کار که می‌خواهد اجرا شود

- M (Machine/OS Thread):
ا thread سیستم عامل واقعی

- P (Processor/Context): context
اجرایی که حاوی یک صف محلی از Goroutine ها است

این مدل به گولنگ اجازه می‌دهد هزاران یا حتی میلیون‌ها Goroutine را مدیریت کند، زیرا تعداد M (OS threads) کم‌تر است و تنظیم‌پذیری کننده (scheduler) آن‌ها را بهینه می‌کند.


2.ا Unbounded Concurrency: مشکل نامحدودیت


مشکل

بسیاری از توسعه‌دهندگان فکر می‌کنند که می‌توانند به راحتی هزاران Goroutine بسازند. اما بدون کنترل، این می‌تواند به مشکل جدی منجر شود.

// ❌ غلط: Concurrency نامحدود
func badExample(urls []string) {
    for _, url := range urls {
        go func(u string) {
            resp, _ := http.Get(u)
            // پردازش...
        }(url)
    }
}

اگر لیست URL‌ها بسیار بزرگ باشد، هزاران Goroutine می‌سازید که منابع سیستم را تمام می‌کند.

راه‌حل: Worker Pool Pattern

// ✅ صحیح: محدود کردن concurrency
func goodExample(urls []string) {
    const numWorkers = 10
    jobs := make(chan string, len(urls))
    var wg sync.WaitGroup
    
    // کارگران
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for url := range jobs {
                resp, _ := http.Get(url)
                // پردازش...
            }
        }()
    }
    
    // فرستادن کارها
    for _, url := range urls {
        jobs <- url
    }
    close(jobs)
    
    wg.Wait()
}

این روش تعداد Goroutine های فعال را محدود می‌کند و منابع را کارآمد‌تر مدیریت می‌کند.

---

3. Race Condition و Shared State

مشکل Race Condition

زمانی که چندین Goroutine به طور همزمان به یک متغیر نوشتن یا می‌خوانند، race condition پیش می‌آید.

// ❌ غلط: Race Condition
var counter = 0

func increment() {
    for i := 0; i < 1000; i++ {
        counter++ // نوشتن بدون sync
    }
}

func main() {
    go increment()
    go increment()
    time.Sleep(time.Second)
    fmt.Println(counter) // نتیجه نامعین است!
}

می‌توانید این مشکل را با go run -race تشخیص دهید.

### راه‌حل 1: Mutex

// ✅ صحیح: استفاده از Mutex
var (
    counter = 0
    mu      sync.Mutex
)

func increment() {
    for i := 0; i < 1000; i++ {
        mu.Lock()
        counter++
        mu.Unlock()
    }
}

### راه‌حل 2: Channel

// ✅ صحیح: استفاده از Channel
func main() {
    counter := 0
    increment := make(chan int)
    
    go func() {
        for i := 0; i < 1000; i++ {
            increment <- 1
        }
        close(increment)
    }()
    
    for val := range increment {
        counter += val
    }
    
    fmt.Println(counter) // 1000
}

Shared State vs. Message Passing

- Shared State (Mutex): مناسب برای داده‌های محلی کوچک
- Message Passing (Channel): بهتر برای ارتباطات پیچیده و تفکیک مسئولیت



4. ا Goroutine Leaks: تسریب‌های خطرناک


مشکل


یک Goroutine تسریب (leak) زمانی اتفاق می‌افتد که Goroutine‌ای برای همیشه معلق بماند:

// ❌ غلط: Goroutine Leak
func leakyExample() {
    ch := make(chan int)
    go func() {
        val := <-ch // منتظر می‌ماند برای همیشه!
    }()
    
    // هرگز چیزی به ch نفرستاده نمی‌شود
}

علل معمول

1. کانال بدون بستن: Goroutine منتظر می‌ماند داده دریافت کند
2. بدون timeout: درخواست تا ابد معلق می‌ماند
3. بدون cancel: نحوه‌ای برای توقف نیست

راه‌حل 1: بستن کانال

// ✅ صحیح: بستن کانال
func goodExample() {
    ch := make(chan int)
    go func() {
        for val := range ch { // حلقه بعد از بستن پایان می‌یابد
            fmt.Println(val)
        }
    }()
    
    ch <- 1
    ch <- 2
    close(ch)
}

راه‌حل 2: Context با Timeout

// ✅ صحیح: استفاده از Context Timeout
func goodTimeout() {
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel()
    
    result := make(chan string)
    go func() {
        time.Sleep(2 * time.Second)
        result <- "نتیجه"
    }()
    
    select {
    case res := <-result:
        fmt.Println(res)
    case <-ctx.Done():
        fmt.Println("Timeout!")
    }
}

راه‌حل 3: WaitGroup

// ✅ صحیح: استفاده از WaitGroup
func goodWaitGroup() {
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Println("کارگر", id)
        }(i)
    }
    
    wg.Wait() // منتظر تمام Goroutine ها
}

---

5. Context، Cancellation و Shutdown

Context چیست؟

Context نحوه‌ای برای انتقال اطلاعات در سراسر Goroutine ها و کنترل lifecycle آن‌ها است.

انواع Context

// 1. Background Context (ریشه)
ctx := context.Background()

// 2. Context با Timeout
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// 3. Context با Deadline
deadline := time.Now().Add(5 * time.Second)
ctx, cancel := context.WithDeadline(context.Background(), deadline)
defer cancel()

// 4. Context قابل لغو
ctx, cancel := context.WithCancel(context.Background())
defer cancel()

مثال عملی: Graceful Shutdown

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    
    // شروع سرویس
    go serve(ctx)
    
    // منتظر سیگنال خاموشی
    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
    <-sigChan
    
    fmt.Println("خاموشی شروع...")
    cancel() // تمام Goroutine ها را متوقف کن
    time.Sleep(time.Second) // فرصت تمیز کردن
}

func serve(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            fmt.Println("سرویس متوقف شد")
            return
        default:
            // کار انجام بده
            time.Sleep(time.Second)
            fmt.Println("در حال اجرا...")
        }
    }
}

Best Practices

- همیشه Context را pass کنید: به تمام تابع‌هایی که Goroutine می‌سازند
- defer cancel(): برای جلوگیری از نشت‌های context
- استفاده از select: برای مراقبت از cancellation

---

6. Scheduler و Runtime Behavior

چطور Scheduler کار می‌کند؟

Scheduler گولنگ یک cooperative scheduler است:

1. Goroutine بر روی P اجرا می‌شود
2. زمانی که یک blocking operation (مثل I/O) اتفاق بیفتد، M برای P دیگری پیدا می‌شود
3. اگر P جدید نباشد، M جدید ایجاد می‌شود

// تعیین تعداد GOMAXPROCS
runtime.GOMAXPROCS(4) // فقط 4 P (CPU cores)

// دریافت اطلاعات runtime
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("Goroutines: %d\n", runtime.NumGoroutine())

Goroutine Scheduling Points

Goroutine‌ها در نقاط خاصی جا به جا می‌شوند:

// نقاط Scheduling:
1. Channel operations: <-ch, ch <-
2. go statement
3. Blocking syscalls
4. sync package operations
5. Garbage Collection

مثال: آثار Scheduling

func main() {
    runtime.GOMAXPROCS(1) // فقط یک CPU
    
    var wg sync.WaitGroup
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        for i := 0; i < 5; i++ {
            fmt.Println("Goroutine 1:", i)
            // بدون scheduling point، این برای همیشه اجرا می‌شود!
        }
    }()
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        for i := 0; i < 5; i++ {
            fmt.Println("Goroutine 2:", i)
        }
    }()
    
    wg.Wait()
}

نکات کارکرد Runtime

- GOMAXPROCS: تعداد P‌ها (معمولاً برابر CPU cores)
- NumGoroutine(): تعداد Goroutine‌های فعال
- Stack Growth: Goroutine‌ها با stack کوچک شروع و رشد می‌کنند

فقط در ۷۶ دقیقه، خلاصه‌ی تمام دانسته‌های مهندسی هوش مصنوعی

اگه واقعا می‌خوای بفهمی AI Engineering یعنی چی، این ویدیو رو از دست نده.
نه یه آموزش سطحی‌ه، نه یه ویدیوی تبلیغاتی.
یه خلاصه‌ی فشرده از مفاهیمیه که هر کسی که با هوش مصنوعی کار می‌کنه باید بدونه، اونم فقط توی ۷۶ دقیقه.

در این ویدیو درباره‌ی چیزهایی صحبت می‌شه که نگاهت رو به AI برای همیشه تغییر می‌دن

چرا نباید از صفر مدل بسازی (و چطور باید از مدل‌های آماده استفاده کنی)
چطور (Self-supervised learning) همه‌چیز رو عوض کرده
چرا داده‌های آموزشی همیشه سوگیرانه‌ان و چطور باید باهاش کنار بیای
چرا طولانی‌تر بودن پرامپت همیشه به معنی نتیجه‌ی بهتر نیست
این‌که مدل بزرگ‌تر الزاماً مدل هوشمندتر نیست
چطور یه پرامپت خوب می‌تونه جای هفته‌ها فاین‌تیونینگ رو بگیره RAG چیه و چرا باید جزو ابزار اصلی هر تیم AI باشه

اگه توی مسیر ساخت محصول، رهبری تیم یا توسعه‌ی پروژه‌های هوش مصنوعی هستی،
این ویدیو احتمالاً یکی از مفیدترین ۷۶ دقیقه‌هایی خواهد بود که می‌گذرونی.

https://www.youtube.com/watch?v=JV3pL1_mn2M

@DevTwitter | <Mohsen Rad/>