🔵 عنوان مقاله
GitHub MCP Server 0.13

🟢 خلاصه مقاله:
گیت‌هاب با انتشار GitHub MCP Server نسخهٔ 0.13 یک پیاده‌سازی رسمی و قابل اتکا از سرور MCP ارائه کرده است. این سرور با زبان Go نوشته شده تا کارایی، سادگی استقرار و قابل‌حمل بودن را فراهم کند. رسمی بودن آن، نقش مرجع را برای رفتار و سازگاری ایفا می‌کند و نسخه‌گذاری 0.13 نشان‌دهندهٔ توسعهٔ تدریجی و تمرکز بر بلوغ و پایداری است؛ بنابراین گزینه‌ای مناسب برای تیم‌هایی است که به یک راهکار مطمئن و نگهداشت‌پذیر نیاز دارند.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Understanding Go Error Types: Pointer vs. Value

🟢 خلاصه مقاله:
تفاوت میان تعریف خطا با گیرنده مقداری و اشاره‌گری در Go می‌تواند به خطاهای پنهان منجر شود. اگر متد Error را با گیرنده مقداری تعریف کنید، هر دو T و *T اینترفیس error را پیاده‌سازی می‌کنند؛ اما با گیرنده اشاره‌گری فقط *T این کار را می‌کند. پیامدها: امکان ایجاد اینترفیس error غیرnil که حاوی اشاره‌گر nil است و بررسی err != nil را گمراه می‌کند، و شکست بی‌سروصدای errors.Is/As در صورت عدم تطابق نوع مقداری/اشاره‌گری. راهکارها: برای انواع کوچک و تغییرناپذیر از گیرنده مقداری استفاده کنید و فقط در صورت نیاز واقعی از گیرنده اشاره‌گری بهره ببرید؛ سازگاری در ساخت و بازگرداندن خطاها را رعایت کنید؛ با assertion کامپایلی اطمینان بگیرید نوع شما error را پیاده‌سازی می‌کند و تست رفتار nil را اضافه کنید.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

جدا از مهندسی پشت تلگرام که بهینه نوشته شده، تلگرام چیزی داره به اسم Update Queue. چیزی که ۱ سال از دوران جوونیم رو صرف مهندسی معکوسش کردم.
تلگرام برای پوش کردن تغییرات مثل پیام جدید، ادیت، ری اکشن، تایپینگ و… به کلاینت‌ها از سرویس Updates تو پروتکل MTProto استفاده میکنه، ایده ی کلی و کلیدی خیلی ساده اس و اینه که کلاینت ها یه state محلی نگه میدارن و آپدیتارو دقیقا با ترتیب درست اعمال میکنن؛ اگه شکافی بینشون افتاد، Difference می‌گیرن و دوباره پرش میکنن.

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

از اونجایی که هر پیامرسان منبع عظیمی از اتفاقاتیه که هر لحظه میوفته ما میتونیم اسم این اتفاقات رو event بزاریم. تلگرام هم یه پیامرسان مولتی کلاینته، یعنی هر کاربر میتونه چندین دیوایس برای یه حساب داشته باشه، پس وقتی یه ایونت اتفاق میوفته که باید یه کاربر از اون خبردار بشه باید اون ایونت رو به دیوایس های دیگه ی کاربر هم بفرسته، حدودا با مرتبه زمانی On^2.

مکانیزم اینجوریه که وقتی دیوایسی انلاین باشه و سوکت همون سوکتی باشه که keep alive هست یا اخرین rpc رو کال کرده سرور ایونت رو توی queue برای اون دیوایس نگه نمیداره و مستقیم میفرسته به کلاینت، حالا از اونجایی که کلاینت های دیگه ممکنه افلاین باشن یا حتی توی بکگراند پروسسشون کیل شده باشه عقب میمونن. حالا وقتی اون دیوایسی که عقب مونده بود با باز شدن سوکتش درخواست گرفتن اپدیت هارو وقتی که افلاین بوده رو از سرور میکنه و اطلاعات لوکالش رو میفرسته به سرور، من برای ساده شدنش اینجوری میگم که دیوایس میاد به سرور میگه من تا این زمان t رو داشتم و بعد این رو بهم بده، سرور هم میاد حساب کتابش رو میکنه و جواب رو توی یه پچ میفرسته! حالا چی توی این پچ هست و چی رو میفرسته رو میتونم یه رشته توییت دیگه در موردش بزنم.

حالا اگه اعدادی که توی پچ میاد با اعداد توی کلاینت نخونه عملا میگیم گپ اتفاق افتاده، برای همین هم کلاینت باید رکویست getDiff رو بزنه.
رکویست updates.getDifference به کلاینت اجازه می‌ده بگه:
من الان pts = X و seq = Y هستم و هر چی بین این و حالت جدید هست بهم بده.
• سرور ممکنه جواب بده:
difference: همه ی آپدیت های گمشده
differenceSlice: بخشی از آپدیت ها یعنی هنوز باید به فچ کردن ادامه بدی
differenceEmpty: چیزی تغییر نکرده

جالبترش اینه که توی نسخه های جدیدترش برای کانال ها مکانیسم جدا getChannelDifference هست، چون هر کانال pts مستقل داره و این باعث میشه شما فقط کانال هایی رو بگیری که تغییر کردن! برای سوپر گروه هم مکانیزم همینه.

این باعث می‌شه حتی اگر چند ساعت آفلاین باشی، بعد از اتصال دوباره دقیقاً همه‌چی رو بگیری و هیچ پیامی رو از دست ندی

حتی با packet loss یا reconnect، state کلاینت خراب نمیشه و سرور مجبور نیست برای هر کلاینت همه چی رو دوباره بفرسته. فقط gap ها sync میشن

<Abolfazl/>

🔵 عنوان مقاله
From Go Code to Container Image with Depot API

🟢 خلاصه مقاله:
**این مطلب دو مسیر عملی را پوشش می‌دهد: ۱) تبدیل کد Go به ایمیج کانتینری با API دیپوت برای بیلدهای سریع، قابل‌تکرار و مناسب CI، و انتشار در رجیستری؛ ۲) استقرار سایت استاتیک Hugo در هتزنر با ساخت آرتیفکت‌ها، راه‌اندازی وب‌سرور یا کانتینر، تنظیم دامنه و SSL، و خودکارسازی در CI/CD. هدف، ساده‌سازی مسیر از کد تا تولید با تکیه بر سرعت، پایداری نتایج و هزینه‌ اثربخش است.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

ارتباط IPv6 از سمت زیرساخت کشور دچار اختلال و قطعی شده است.

🔵 عنوان مقاله
a fantastic illustrated introduction to Big O notation

🟢 خلاصه مقاله:
** این مقاله معرفی‌ای تصویری و روان از نمادگذاری Big O ارائه می‌دهد و با تکیه بر مثال‌ها، تفاوت مرتبه‌هایی مانند O(1)، O(log n)، O(n) و موارد رایج دیگر را توضیح می‌دهد. هدف آن نشان‌دادن مفهوم رشد با بزرگ‌شدن ورودی و مقایسهٔ مقیاس‌پذیری الگوریتم‌هاست، بدون درگیرشدن با جزئیات پیاده‌سازی یا ثابت‌ها. برای هر کسی که تا به حال معنی O(1) و O(log n) برایش سؤال بوده، این نوشته یک شروع عالی است.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

امروز یکی از همکارانم سوال خوبی پرسید که فکر می‌کنم دغدغه خیلی‌هاست:
"فرق واقعی Async و Concurrency چیه؟ مگه هر دو به معنی انجام همزمان کارها نیستن؟"
این دو مفهوم اغلب با هم اشتباه گرفته می‌شن. بذارید با یک مثال ساده تفاوتشون رو باز کنم:
۱. Synchronous vs. Asynchronous
این مفاهیم درباره انتظار کشیدن هستن.
Sync
مثل اینه که بری کافه، قهوه سفارش بدی و همونجا جلوی پیشخوان منتظر بمونی تا آماده بشه و تحویل بگیری.
تا قهوه رو نگیری، هیچ کار دیگه‌ای نمی‌کنی.
Async
سفارش می‌دی، یک پیجر (Pager) می‌گیری و می‌ری سر میزت می‌نشینی.
در این فاصله می‌تونی ایمیل‌هاتو چک کنی.
هر وقت قهوه‌ات آماده شد، پیجر بهت خبر می‌ده.
تو منتظر نموندی و از زمانت استفاده کردی.

۲. Concurrency
این مفهوم درباره مدیریت چند کار در یک بازه زمانی هست.
باریستای کافه رو در نظر بگیرید:
اون همزمان هم سفارش شما رو آماده می‌کنه، هم سفارش نفر بعدی رو می‌گیره و هم شیر رو برای یک سفارش دیگه گرم می‌کنه.
در واقع اون با جابجایی سریع بین کارها (Context Switching)، چند وظیفه رو پیش می‌بره.
این یعنی هم‌روندی.

نکته کلیدی
برنامه‌نویسی Async یکی از راه‌های رسیدن به Concurrency هست.
درک این تفاوت، در طراحی سیستم‌های مدرن مثل میکروسرویس‌ها یا پایپ‌لاین‌های پردازش دیتا، یک مزیت فوق‌العاده است.
این درک به شما کمک می‌کنه تا بین ابزارهایی مثل Kafka, gRPC یا WebSockets انتخاب درستی داشته باشید و سیستمی بسازید که هم Scalable و هم Reliable باشه.


@ | <Ali Naseri/>

🔵 عنوان مقاله
The 9 Go Test Assertions I Use (and Why)

🟢 خلاصه مقاله:
این مقاله با تکیه بر بحثی قدیمی در دنیای Go بررسی می‌کند که آیا باید از پکیج‌های Assertion استفاده کرد یا خیر. نویسنده می‌گوید به‌جای چارچوب‌های سنگین، از چند تابع کمکی ساده و دست‌ساز برای آزمون‌ها استفاده می‌کند؛ تابع‌هایی که کارهای رایجی مثل برابری/نابرابری، بررسی خطا (از جمله خطاهای انتظاررفته یا پیچیده)، nil بودن یا نبودن، شامل بودن، طول مجموعه‌ها، مقایسه تقریبی اعداد/زمان و انتظار وقوع panic را پوشش می‌دهند و پیام خطای واضحی می‌دهند بدون اینکه وابستگی خارجی اضافه کنند. او به پرسش «آیا Assertionها ضدالگو هستند؟» پاسخ می‌دهد: وقتی منطق را پنهان کنند و به زنجیره‌سازی و DSLهای مبهم تبدیل شوند، بله؛ اما اگر کوچک، هدفمند و شفاف باشند نه‌تنها ایرادی ندارند، بلکه خوانایی و نگهداشت را بهتر می‌کنند. در نهایت توصیه می‌کند Helperها حداقلی و محلی باشند، نام‌گذاری روشن داشته باشند، از اغراق در انتزاع پرهیز شود، و فقط در موارد لازم سراغ ابزارهایی مثل go-cmp یا testify برویم. نتیجه‌گیری: مشکل در خود Assertion نیست، در استفاده بی‌ملاحظه از آن است.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🎙 پادکست جدید
🚧 Go Improvement: 🫸 waitgroup.Go, json/v2, 🐍 new features for cobra apps, with Jeremy Foran

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Making Games in Go: 3 Months Without LLMs vs 3 Days With LLMs

🟢 خلاصه مقاله:
**این مقاله روایت شخصی و سرگرم‌کننده‌ای از ساخت دو بازی کارتی با زبان Go است که دو رویکرد را مقایسه می‌کند: بدون کمک LLMها حدود سه ماه زمان برد، اما با کمک LLMها ظرف سه روز به نتیجه رسید. نویسنده نشان می‌دهد که بخش عمده زمان بدون LLM صرف مطالعه مستندات، اتصال کتابخانه‌ها و رفع خطاها می‌شود، در حالی‌که LLMها با تولید اسکلت کد، خلاصه‌سازی اسناد و پیشنهاد راه‌حل‌ها، کارهای زمان‌بر را فشرده می‌کنند. نتیجه‌گیری مقاله این است که LLMها جایگزین مهارت مهندسی نیستند، اما با نظارت و آزمون مناسب می‌توانند مسیر رسیدن از ایده به نمونهٔ قابل اجرا را به‌طور چشمگیری کوتاه کنند، و Go بستر ساده و محکمی برای این کار فراهم می‌کند.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

امنیت در Docker: چیزی که اغلب فراموش می‌کنیم!

*  از rootless containers استفاده کنید: اجرای اپلیکیشن با کاربر non-root ریسک نفوذ رو خیلی کم می‌کنه.
* از Base image سبک و امن استفاده کنید: مثلاً alpine یا distroless. imageهای بزرگ‌تر مثل ubuntu اغلب پکیج‌های غیرضروری دارن که سطح حمله رو زیاد می‌کنن.
* حتما وDependencyها رو pin کنید: همیشه نسخه دقیق کتابخونه‌ها رو مشخص کنید تا از تغییرات ناخواسته جلوگیری بشه.
* از .dockerignore استفاده کنید: فایل‌های حساس (مثل .env یا کلیدها) هرگز نباید داخل image قرار بگیرن.
* به‌روز نگه داشتن imageها: آسیب‌پذیری‌ها خیلی سریع پیدا می‌شن، پس آپدیت مرتب imageها ضروریه.
بارها پیش میاد که به خاطر استفاده از یک base image قدیمی، vulnerability جدی توی اسکن امنیتی پیدا میشه. فقط با عوض کردن base image به نسخه‌ی جدیدتر و سبک‌تر، هم امنیت بیشتر میشه، هم حجم image کاهش پیدا میکنه.

نکات تکمیلی امنیت در Docker
1. استفاده از Healthcheck
- توی Dockerfile با HEALTHCHECK وضعیت سرویس رو بررسی کنید که باعث می‌شه container ناسالم زودتر شناسایی و جایگزین بشن.
2. حداقل کردن Surface Attack با distroless images
- این imageها فقط باینری نهایی رو دارن (بدون package manager یا shell).
- دسترسی مهاجم به شدت محدود می‌شه.
3.فعال کردن User namespace remapping
- باعث می‌شه کاربر root داخل container، روی سیستم میزبان واقعاً root نباشه.
4. استفاده از Read-Only Filesystem
- container رو با --read-only بالا بیارید تا کسی نتونه فایل‌های سیستمی داخلش رو تغییر بده.
5. مدیریت Secretها به‌درستی
- هرگز secrets رو داخل image نذارید.
- از ابزارهایی مثل Docker secrets، HashiCorp Vault یا AWS/GCP Secret Manager استفاده کنید.
‏6. Scan امنیتی منظم
- ابزارهایی مثل Trivy, Grype یا Docker Scout رو برای اسکن image استفاده کنید.
- این ابزارها آسیب‌پذیری‌های شناخته‌شده (CVE) رو شناسایی می‌کنن.
7. محدود کردن Resourceها
- با --cpus و --memory منابع container رو محدود کنید تا جلوی حملات DoS یا مصرف بی‌رویه گرفته بشه.
8. استفاده از شبکه‌های ایزوله
- کانتینرهایی که لازم نیست با اینترنت یا کانتینرهای دیگه در ارتباط باشن رو توی یک شبکه‌ی جداگانه نگه دارید.
9. امضای دیجیتال و اعتبارسنجی Imageها
- با Docker Content Trust (DCT) یا cosign امضا و اعتبارسنجی کنید که image تغییر نکرده باشه.
10. بروزرسانی مرتب Docker Engine و Runtime
- چون آسیب‌پذیری‌ها فقط توی imageها نیستن، بلکه خود daemon و runtime هم می‌تونه مشکل امنیتی داشته باشه.


*امنیت در Docker فقط به Dockerfile محدود نیست؛ از انتخاب base image شروع می‌شه، به مدیریت secret و network می‌رسه و حتی شامل CI/CD pipeline هم می‌شه*

<Somaye Omidi/>

🔵 عنوان مقاله
How to Deploy a Hugo Static Site to Hetzner

🟢 خلاصه مقاله:
یک راهنمای مرحله‌به‌مرحله برای استقرار سایت استاتیک Hugo روی Hetzнер است که با تکیه بر سادگی، هزینه کم و کارایی بالا، دو مسیر اصلی را توضیح می‌دهد: میزبانی روی یک سرور ابری سبک (با Nginx/Caddy) یا استفاده از سرویس‌های ذخیره‌سازی برای حذف نگهداری سرور. سپس یک خط لولهٔ خودکار پیشنهاد می‌کند که با هر push کد، سایت را می‌سازد و با ابزارهایی مثل rsync/scp/rclone منتشر می‌کند، همراه با مدیریت امن کلیدها، استقرار اتمیک و امکان rollback. در ادامه تنظیم DNS و TLS (Let’s Encrypt)، هدرهای کش، فشرده‌سازی، و در صورت نیاز CDN پوشش داده می‌شود. خروجی، فرآیندی تکرارپذیر از گیت تا تولید است که HTTPS، کارایی مناسب و نگهداری کم‌هزینه را روی Hetzner فراهم می‌کند.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
YARR: Yet Another RSS Reader

🟢 خلاصه مقاله:
یک گردآورنده‌ی فید به نام YARR است که به‌عنوان یک RSS Reader، به‌روزرسانی‌های چندین وب‌سایت را در یک محیط واحد جمع می‌کند. هسته‌ی سرویس با زبان Go نوشته شده تا سمت سرور سریع و کارآمد باشد و رابط کاربری با Vue.js ساخته شده تا تجربه‌ای واکنش‌گرا و روان ارائه دهد. تفکیکِ روشن بین بک‌اند و فرانت‌اند، نگه‌داری و گسترش را ساده می‌کند و YARR را به گزینه‌ای مناسب برای دنبال‌کردن متمرکز خبرها و مطالب از منابع مختلف تبدیل می‌سازد.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Announcing GoReleaser v2.12

🟢 خلاصه مقاله:
گو ریلیزر نسخه ۲.۱۲ منتشر شد؛ ابزاری برای خودکارسازی انتشار پروژه‌های Go. این نسخه یکپارچه‌سازی جدید با Docker، گواهی‌گذاری (attestation) تصاویر Docker، پشتیبانی از بسته‌بندی Makeself برای ساخت بسته‌های خوداستخراج/اجرایی، سازگاری با Go 1.25 و بهبودهای دیگر را ارائه می‌کند.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

کد ۴۸ ساله معروف بیل گیتس، اوپن‌سورس شد!
مایکروسافت کد ۴۸ ساله‌ی معروف بیل گیتس را متن‌باز کرد تا هر کسی بتواند آن را ببیند و استفاده کند.

https://github.com/microsoft/BASIC-M6502

| <Saber V/>

🔵 عنوان مقاله
Go 1.25 Released

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

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Getting Started with Falco Security Tool on GKE

🟢 خلاصه مقاله:
این آموزش نحوه راه‌اندازی و پیکربندی Falco روی GKE را برای امنیت زمان اجرا نشان می‌دهد: نصب عامل‌های Falco در خوشه، آزمایش قوانین پیش‌فرض با شبیه‌سازی رفتارهای مشکوک، اتصال رویدادها به Google Cloud Monitoring برای ساخت هشدارهای قابل اقدام، و افزودن قوانین سفارشی برای متناسب‌سازی تشخیص‌ها با نیازهای کلاستر. نتیجه، یک لایه تشخیص زمان اجرا روی GKE با هشداردهی یکپارچه و قابلیت تنظیم برای کاهش خطاهای مثبت کاذب است.

🟣لینک مقاله:
https://ku.bz/zFRVy94dl

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon