🟢 اگر کارفرما یا کارجو هستی

و دنبال نیرو یا موقعیت شغلی توی حوزه‌های زیر هستی، به من پیام بده 👇

⚔️ DevOps Engineer
⚔️ Site Reliability Engineer (SRE)
⚔️ Linux SysAdmin
⚔️ Cloud Engineer (AWS/GCP/Azure)
⚔️ Infrastructure Engineer
⚔️ Security Engineer (DevSecOps/Linux)
⚔️ Automation Engineer
⚔️ Platform Engineer
⚔️ Software Security
⚔️ Software QA
⚔️ Backend
⚔️ AI Engineer / Machine Learning
⚔️ Database Engineer / DBA

📩 همین الان پیام بده و استارت بزن! تا هم بتونی نیروی خوب پیدا کنی و یا یتونی یه موقعیت شغلی مناسب پیدا کنی

به من پیام بده آگهی یا رزومه ات رو قرار بدم اینجا

@mrbardia72

🔵 عنوان مقاله
you can read it in article form.

🟢 خلاصه مقاله:
این نوشته دو مطلب فنی را معرفی می‌کند: نخست، ترور اسلاکِم به رفتاری ظریف در الحاق عناصر به اسلایس‌های Go می‌پردازد؛ جایی که به‌دلیل اشتراک آرایهٔ پشتیبان، append می‌تواند به‌صورت غیرمنتظره دادهٔ اسلایس‌های دیگر را تغییر دهد یا بسته به ظرفیت، باعث تخصیص جدید شود. نتیجه این است که باید حواسمان به ظرفیت، اشتراک حافظه و جداسازی داده با copy یا تخصیص هدفمند باشد. دوم، الی بندرسکی پیاده‌سازی یک مفسر کوچک Forth را در Go و C مقایسه می‌کند تا تفاوت‌های عملی میان ایمنی و سهولت (در Go) و کنترل و سربار کم (در C) را نشان دهد. پیام کلی: با درک دقیق جزییات زبان و مدل حافظه، می‌توان از خطاهای پنهان پرهیز کرد و انتخاب‌های بهینه‌تری انجام داد.

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
What is the Go Proxy Even Doing?

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

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

تابع atomic.LoadInt32 در زبان برنامه‌نویسی Go (گولنگ) برای خواندن ایمن (safe) یک مقدار 32 بیتی از نوع int32 از حافظه به صورت اتمیک (atomic) استفاده می‌شود. عملیات اتمیک به این معناست که این عملیات به صورت کامل و بدون وقفه انجام می‌شود و از تداخل (race condition) بین گوروتین‌ها (goroutines) جلوگیری می‌کند.

توضیح دقیق‌تر:
- پکیج: این تابع در پکیج sync/atomic قرار دارد.
- کاربرد: atomic.LoadInt32 برای خواندن مقدار یک متغیر int32 از حافظه به صورت اتمیک استفاده می‌شود. این تابع تضمین می‌کند که مقدار خوانده‌شده دقیق و بدون تأثیر از تغییرات همزمان توسط گوروتین‌های دیگر است.
- ساختار:

  func LoadInt32(addr *int32) (val int32)
  

- addr: اشاره‌گر به متغیر int32 که می‌خواهید مقدارش را بخوانید.
- val: مقداری که از حافظه خوانده می‌شود و به عنوان خروجی برگردانده می‌شود.


مثال:

package main

import (
  "fmt"
  "sync/atomic"
)

func main() {
  var counter int32 = 42

  // خواندن مقدار counter به صورت اتمیک
  value := atomic.LoadInt32(&counter)
  fmt.Println("Value:", value) // خروجی: Value: 42
}

چرا از atomic.LoadInt32 استفاده کنیم؟
- وقتی چندین گوروتین به یک متغیر مشترک دسترسی دارند، استفاده از عملیات معمولی (غیراتمیک) ممکن است به مشکلات همزمانی (concurrency issues) مثل race condition منجر شود.
- atomic.LoadInt32 تضمین می‌کند که مقدار خوانده‌شده همیشه معتبر و به‌روز است، بدون اینکه نیازی به قفل (lock) باشد.

نکات:
- این تابع فقط برای متغیرهای از نوع int32 کار می‌کند. برای انواع دیگر (مثل int64 یا uint32) توابع مشابهی مثل atomic.LoadInt64 یا atomic.LoadUint32 وجود دارد.
- عملیات اتمیک معمولاً سریع‌تر از استفاده از قفل‌ها (مثل sync.Mutex) هستند، اما فقط برای عملیات‌های ساده مثل خواندن یا نوشتن مناسب‌اند.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

کجا نباید از داداشمون RabbitMQ استفاده کنیم؟

1- وقتی نیاز به real-time response داریم.
چرا؟ چون RabbitMQ صف هست و ارسال/دریافت پیام ممکنه با تاخیر انجام شود.
پیشنهادم WebSocket، gRPC یا Redis Pub/Sub است.

2- وقتی به message replay یا history نیاز داریم
چرا؟ چون RabbitMQ پیام‌ها رو بعد از مصرف حذف می‌کند. البته میشه کانفیگ کرد که نگه داره.

3- زمانی که پیام‌ها حجمشون خیلی زیاد است.
چرا؟ چون در حجم بالا RabbitMQ دچار افت performance می‌شود. Kafka رو پیشنهاد می‌کنم برای اینجا.

4- وقتی ترتیب دقیق پردازش پیام‌ها خیلی مهم است. چرا؟ چون  RabbitMQ تضمین دقیقی برای ترتیب پیام‌ها ندارد. اینجا هم پیشنهادم Kafka است.


<Amirhossein Dehghan/>

🔵 عنوان مقاله
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/>