💢 تا حالا به این فکر کردی چجوری میشه یه کاری رو دقیقاً تا یه لحظه مشخص زمان‌بندی کرد و مطمئن شد که یا تموم میشه یا لغو؟



💠تو Go و ابزار context می‌تونی عملیات‌هاتو دقیقاً با یه مهلت مشخص (Deadline) کنترل کنی.



مثلاً فرض کن یه کدی داریم که باید یه تابع به اسم ()work رو اجرا کنه. این تابع قراره 100 میلی‌ثانیه طول بکشه. حالا دو تا سناریو داریم:



1️⃣سناریوی اول: مهلت کافیه (150+ میلی‌ثانیه)

اینجا Deadline رو 150 میلی‌ثانیه تعیین می‌کنیم، یعنی کد ما زمان کافی داره.

func main() {
    deadline := time.Now().Add(150 * time.Millisecond)
    ctx, cancel := context.WithDeadline(context.Background(), deadline)  
    defer cancel()

    res, err := execute(ctx, work)
    fmt.Println(res, err)  // نتیجه درست برمی‌گرده
}

✅خروجی:

کد بدون مشکل اجرا میشه چون زمان کافی داشتیم.


2️⃣ سناریوی دوم: مهلت کافی نیست (50+ میلی‌ثانیه)

حالا Deadline رو 50 میلی‌ثانیه می‌ذاریم، اما ()work حداقل 100 میلی‌ثانیه نیاز داره.

func main() { 
    deadline := time.Now().Add(50 * time.Millisecond) 
    ctx, cancel := context.WithDeadline(context.Background(), deadline)   
    defer cancel() 
 
    res, err := execute(ctx, work) 
    fmt.Println(res, err)  // نتیجه لغو میشه 
} 
 

😀خروجی:

عملیات لغو میشه (context.Canceled) چون مهلت کافی وجود نداشت.



🫶فرق بین WithTimeout و WithDeadline چیه؟


بله WithTimeout یه مقدار زمان مشخص می‌گیره (مثلاً 5 ثانیه)، اماWithDeadline دقیقاً یه زمان مشخص (مثلاً 23:00:05).

جالبیش اینه که WithTimeout خودش از WithDeadline استفاده می‌کنه:

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
    return WithDeadline(parent, time.Now().Add(timeout))
}

💠چچطوری بفهمیم کانتکست Deadline داره؟

با متد Deadline، می‌تونیم زمان مشخص شده رو ببینیم.

اگه کانتکست با WithTimeout یا WithDeadline شده باشه، یه زمان مشخص می‌ده.

اما اگه با WithCancel یا Background ساخته شده باشه، می‌گه نه!

 
ctx, _ := context.WithCancel(context.Background()) 
 
deadline, ok := ctx.Deadline() 
 
fmt.Println(deadline, ok)  // نتیجه: false 
 
 
ctx = context.Background() 
 
deadline, ok = ctx.Deadline() 
 
fmt.Println(deadline, ok)  // باز هم false 
  

🔸اگر تجربه ای ازش داری،تجربه‌هات رو برامون بگو!



#گو #گولنگ #Go #Golang

💢گو(Golang) 1.24 اومد!

اگه شما هم با Golang کد می‌زنید، خبر خوب اینه که ورژن 1.24 قراره تو فوریه 2025 منتشر بشه و کلی بهبود خفن آورده که کارمون رو هم سریع‌تر می‌کنه، هم راحت‌تر.



🔺هایلایت‌های این نسخه:

1️⃣سوئیچ به SwissTable تو کامپایلر:

گولنگ با این تغییر، مدیریت مپ‌ها رو خیلی بهینه‌تر کرده! رم کمتر مصرف می‌شه و عملیات خوندن/نوشتن سریع‌تر شده.



2️⃣ آپدیت استاندارد لایبرری:

دو پکیج جدید داریم:

اولی os.Root برای راحت‌تر کردن کارهای مربوط به دایرکتوری‌ها.

دومی weak برای هندل کردن weak pointers که خیلی وقتا به درد می‌خوره.


یه قابلیت جدید برای alias کردن sliceها که به خصوص با افزایش استفاده از جنریک‌ها خیلی کاربردیه.


3️⃣ بهبود ابزارها (Tooling):

یه قابلیت خفن به اسم متا-پترن اضافه شده که نصب ابزارهایی مثل mockgen رو راحت‌تر از همیشه می‌کنه.

خروجی JSON برای go test: تحلیل تست‌ها دیگه یه لذت شده!

و GOAUTH: حالا می‌تونید راحت‌تر به ریپوزیتوری‌های پرایوت مثل GitHub وصل بشید.



🔺نظر شخصی من؟

این نسخه شاید تغییرات انقلابی نداشته باشه، ولی پر از آپدیت‌های کاربردی که واقعاً حس می‌کنید کارتون سریع‌تر و تمیزتر شده. تغییراتی مثل سوئیچ به SwissTable و GOAUTH کار رو برای تیم‌هایی که با پروژه‌های بزرگ و پرایوت کار می‌کنن، بسیار ساده‌تر کرده.



✅آپدیتش کنید، پشیمون نمی‌شید!

#گولنگ #گولنگ_1_24


#GoLang #Go1_24 #DeveloperExperience #Tooling

💢دیزاین پترن Facade در Golang

🫶یکی از دیزاین پترن های جذاب و کاربردی، پترن Facade! شاید اسمش یه کم شیک به نظر بیاد، ولی قول میدم که خیلی کاربردیه و کارمون رو راحت‌تر می‌کنه.

🔹فسید Facade چیه؟

فرض کن جلوی یه ساختمون خیلی شیک و بزرگ وایسادی، ولی لازم نیست بری داخلش و همه اتاقاشو ببینی. فقط کافیه از بیرون، نمای ساده و مرتبش رو ببینی و کارتو راه بندازی. پترن Facade دقیقاً همینه! یه رابط کاربری ساده می‌ده که دیگه لازم نباشه با پیچیدگی‌های سیستم درگیر بشی.

✅چرا باید ازش استفاده کنیم؟

دو تا اصل مهم دنیای کدنویسی اینجا برامون روشن‌تر می‌شه:

1️⃣ KISS (همه چی ساده باشه)

2️⃣ DRY (تکرار نکن)

وقتی از Facade استفاده می‌کنی، پیچیدگی‌های پشت پرده سیستم رو قایم می‌کنی و فقط چیزی که کاربر (یا حتی خودت!) نیاز داری رو نشون می‌دی. کدت مرتب‌تر، قابل نگهداری‌تر و قابل‌فهم‌تر می‌شه.


🔴ی مثال ساده: اتصال به دیتابیس

فرض کن می‌خوای به دیتابیس وصل بشی، کوئری بزنی و قطع کنی. بدون Facade اینجوریه:

type Database struct { 
 
 DatabaseConnection *sql.DB 
 
} 
 
 
func (db *Database) Connect() { 
 
 // کد اتصال 
 
} 
 
 
func (db *Database) Query() { 
 
 // کد کوئری 
 
} 
 
 
func (db *Database) Disconnect() { 
 
 // قطع اتصال 
} 
 
 
// استفاده 
 
var db Database 
 
db.Connect() 
 
db.Query() 
 
db.Disconnect() 
 

ولی با Facade، همه اینا تو یه دونه تابع جمع می‌شه:

 
type DatabaseFacade struct { 
 
 Database *Database 
 
} 
 
 
func (dbf *DatabaseFacade) ExecuteQuery() { 
 
 dbf.Database.Connect() 
 
 dbf.Database.Query() 
 
 dbf.Database.Disconnect() 
 
} 
 
 
 
// استفاده 
 
var dbf DatabaseFacade 
 
dbf.ExecuteQuery() 
 
 

🔸کاربردهای دیگه:

کار با فایل‌ها

ارتباط با API

راه‌اندازی وب‌سرور

مدیریت سفارش‌های فروشگاه آنلاین

🔺فسید Facade مثل یه شمشیر دولبه‌ست. اگه زیادی ساده‌سازی کنی یا بخوای همه کارها رو تو یه struct و متدهاش بذاری، ممکنه یه ساختار پیچیده (God Object) بسازی که خودش یه مشکل جدیده.

✅جمع‌بندی:

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

شما چطور از Facade استفاده کردید تجربه‌هاتون رو تو کامنت‌ها بگید.


#الگوی_طراحی #Facade #گو #گولنگ #Go #Golang #KISS #DRY

💙 چرا سرورلس (Serverless) یک کلاه‌برداریه؟
خیلی‌ها این روزها دوباره دارن از سرورلس به سمت سرورهای اختصاصی و VPS برمی‌گردن. چند سال پیش همه دنبال سرورلس بودن، ولی الان؟ دیگه اوضاع فرق کرده! توی این پست می‌خوام چند تا از دلایلی که سرورلس یه انتخاب ضعیفه رو به زبون ساده باهاتون به اشتراک بذارم.

1️⃣ قیمت سرسام‌آور
شرکت‌های بزرگی مثل AWS و Azure دقیقاً می‌دونن چطوری شما رو قفل سیستم خودشون کنن. وقتی واردش می‌شید، بیرون اومدن ازش هزینه‌های وحشتناک داره: 

🔹انتقال دیتا؟ 
🔹تغییر معماری؟

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


2️⃣پیچیدگی غیرضروری
سرورلس به‌شدت پیچیده‌ست. مثال ساده؟  یه کانفیگ اشتباه می‌تونه میلیاردها تومان خسارت بزنه! 

بودند کسایی که به‌خاطر فراموش کردن تنظیمات S3، هزینه‌های سنگینی دادن!
 
توی VPS، همه‌چی رو می‌تونی ساده و شفاف مدیریت کنی. مثلاً یه آموزش ساده برای قفل کردن سرور با Fail2Ban و غیرفعال کردن رمز ورود برای کاربر Root می‌تونه امنیت رو به‌شدت بالا ببره.

3️⃣آپتایم (Uptime) یا بهتر بگم، قطعی‌های سرورلس
وقتی سیستم ساده‌تر باشه، کمتر قطع می‌شه. از وقتی از سرورلس به VPS مهاجرت کردم، سرویس‌هام هیچ‌وقت خودبه‌خود قطع نشدن. ولی سرورلس؟ 

🔹مثلاFirebase Auth تو سال ۲۰۲۳ چند ساعت کامل از دسترس خارج شد. 
🔹 یا AWS همون سال قطعی داشت. 
🔹حتی Azure هم قربانی یه قطع برق بزرگ شد! 

آپتایم ادعایی این شرکت‌ها معمولاً روی کاغذه. ولی واقعیت؟ یه اشتباه کوچیک، یه کلیک اشتباه و تمام اون ۹۹.۹۹٪ می‌پره.


4️⃣سرورلس و داستان امنیت
با سرورلس، هر سرویس جداگانه باید کانفیگ بشه. برای هر میکروسرویس باید دستی کانفیگ امنیتی انجام بدی. این یعنی کار چند برابر. 

ولی روی VPS؟ یه سرور، یه کانفیگ، تمومه!

5️⃣ دی‌داس (DDoS) و راه‌حل‌های بهتر
بعضی‌ها می‌گن سرورلس بهتون محافظت رایگان DDoS می‌ده. اما یه نکته‌ی جالب: 
شما همون محافظت رو می‌تونید با Cloudflare به‌صورت رایگان بگیرید.  کافیه پروکسی Cloudflare رو فعال کنید و SSL/TLS رو روی حالت Full بذارید. همون یه کلیک، همون امنیت. نیازی به سرورلس نیست.

✅نتیجه‌گیری: چرا سرورلس دیگه جواب نمی‌ده؟
🔹سرورلس گرونه. 
🔹 پیچیده‌ست. 
🔹 امنیتش دردسره. 
🔹 آپتایمش همیشه اون‌قدر که می‌گن، نیست. 
🔹 و مهم‌تر از همه، امروز ابزارهایی هستن که می‌تونن جایگزینش بشن. از PocketBase و Appwrite گرفته تا Supabase.

❗سرورلس یه راه‌حل قدیمی برای یه مشکل قدیمی بود. ولی الان؟ تکنولوژی پیشرفته‌تر شده و گزینه‌های بهتری داریم.

🔺 نظر شما چیه؟ شما سرورلس استفاده می‌کنید یا VPS؟ خوشحال می‌شم تجربه‌هاتون رو بخونم.



#سرورلس #میکروسرویس #serverless #vps

💢 چرا وقتی این کد اجرا میشه، "...Sending 0" قبل از "Received 1" چاپ میشه؟

func send(ch chan<- int) {
    defer close(ch)
    fmt.Println("Sending 1...")
    ch <- 1 // Blocks until the receiver is ready

    for i := 0; i < 10; i++ {
        fmt.Printf("Sending %d...\n", i)
        ch <- i // Blocks until the receiver reads the value
    }
}

func main() {
    ch := make(chan int) // Unbuffered channel
    go send(ch)

    for val := range ch {
        fmt.Printf("Received %d\n", val)
    }
}

💠چون:

این رفتار به دلیل ماهیت همزمانی goroutine‌ها است:

1️⃣ ارسال داده بلوکه میشه، اما چاپ متن نه:

در فانکشن send، خط fmt.Println("Sending 0...") قبل از بلوکه شدن ch <- i اجرا میشه. یعنی حتی اگه فرستادن داده منتظر گیرنده بمونه، متن چاپ میشه.



2️⃣ گیرنده همزمان در حال پردازش است:

گیرنده در حلقه for در حال دریافت و چاپ داده است. اما عملیات ارسال و دریافت روی دو goroutine مختلف اجرا میشن. این یعنی ترتیب چاپ‌ها کاملاً قابل پیش‌بینی نیست.



3️⃣ ترتیب چاپ به زمان‌بندی goroutine‌ها بستگی داره:

گولنگ زمان‌بندی goroutine‌ها رو خودش مدیریت می‌کنه. به همین دلیل ممکنه چاپ متن ارسال قبل از دریافت داده تموم بشه.


🔹این رفتار طبیعیه و به دلیل اجرای همزمان goroutine‌ها اتفاق می‌افته.


🔹 چاپ روی کنسول (عملیات I/O) زمان می برد و می تواند با سایر عملیات در گوروتین های مختلف همپوشانی داشته باشد.


#گو #گولنگ #Go #Golang

⭕️ در حال کار بر روی ورژن جدیدی از آنوفل هستیم از ابتدا داریم باز نویسی می کنیم و یک سری تغییرات اصلی و مهم رو اعمال می کنیم و قرار با محصولات و خدمات جدیدی در خدمت همه علاقه مندان به برنامه نویسی و برنامه نویسان باشیم.

🔺اینم بگیم قرار دو زبان باشه (فعلا انگلیسی و فارسی) و جامعه هدفمون رو بیشتر کنیم.

🔻در صورت داشتن ایده یا مشارکت می توانید با پشتیبانی‌ در ارتباط باشید.

💢 از Next.js برای فرانت اند و گولنگ برای بک اند استفاده خواهت شد.

💙تیم برنامه نویسی آنوفل

💙 آنوفل ریلز شد✅

آنوفل دوباره باز نویسی شد و تغییرات بزرگی در UI و برندینگ داشته است، از بروزترین و آخرین تکنولوژی های حال حاضر استفاده شده.

🔴فعالیت ها از سر گرفته شده و طبق برنامه ریزی صورت گرفته پیش خواهیم رفت.

🫶بزودی اولین محصول آنوفل نیز ریلز خواهد شد.

🌐 آنوفل فارسی
🌐 ANOPHEL

داکر کامپوز docker compose چیست؟ بررسی تخصصی

💠داکر (Docker) به شما کمک می کند تا به سرعت یک محیط توسعه را روی دستگاه خود راه اندازی کنید. تنها چند دقیقه طول می کشد تا کل فرآیند را طی کنید. اما بیایید فرض کنیم برای اجرای پروژه شما به حداقل 10 سرویس مختلف در حالت در حال اجرا نیاز دارد. برای مثال، فرض کنید پروژه شما به PHP، Node 23، MySQL، MongoDB، Go، RabbitMQ و غیره نیاز دارد.


🔗داکر کامپوز docker compose چیست؟ بررسی تخصصی


#docker #داکر #docker_compose

💙10 قابلیت پنهان در Golang که برنامه‌نویسان حرفه‌ای از آن استفاده می‌کنند

🫶گو یا گولنگ (Golang) به خاطر سادگی، سرعت و کارایی‌اش شناخته شده است و همین امر آن را به زبانی محبوب برای توسعه‌دهندگانی تبدیل کرده است که برنامه‌های مدرن و مقیاس‌پذیر می‌سازند. اما فراتر از ویژگی‌های مستندسازی‌شده‌اش، گو نکات پنهانی دارد که می‌توانند بهره‌وری شما را به عنوان یک توسعه‌دهنده افزایش دهند. در اینجا 10 ویژگی منحصر به فرد و کمتر شناخته‌شده گو را معرفی می‌کنیم که می‌توانند تجربه کدنویسی شما را حتی بهتر کنند!

🔗 10 قابلیت پنهان در Golang که برنامه‌نویسان حرفه‌ای از آن استفاده می‌کنند


#گو #گولنگ #کد_تمیز #کد_نویسی
#go #golang #clean_code #Software_Development

💢Controlling Deadlines in Go: How to Timeout Your Code with Context

⭐️ https://youtu.be/S3YzCnuFodQ

👍Like, Subscribe, and Comment: What Go topic should we cover next? Goroutines, channels, or something else? Let me know!

💙شبکه سازی در داکر: هر آنچه باید درباره Docker Networking بدانید


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

🔗شبکه سازی در داکر: هر آنچه باید درباره Docker Networking بدانید



#داکر #شبکه #docker

💠چگونه یک سناریوی بهینه برای آپدیت نرم‌افزار بنویسیم؟

⭐️فرآیند به‌روزرسانی نرم‌افزار فقط جایگزینی چند فایل جدید نیست؛ بلکه یک عملیات حساس و حیاتی است که اگر به درستی برنامه‌ریزی نشود، می‌تواند باعث از دست رفتن داده‌ها، ایجاد اختلال در سرویس و آسیب به تجربه کاربری شود.

⭐️در این پست به شما نشان می‌دهیم چطور یک سناریوی استاندارد و حرفه‌ای برای آپدیت نرم‌افزار طراحی کنید.


---

اهداف اصلی سناریوی آپدیت

حفظ پایداری سیستم

جلوگیری از از دست رفتن داده‌ها

کاهش حداکثری زمان داون‌تایم

امکان بازگشت (Rollback) سریع در صورت بروز خطا



---

⭐️اجزای اصلی یک سناریوی آپدیت

۱. شناسایی نسخه فعلی و نسخه مقصد

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

۲. تهیه نسخه پشتیبان (Backup)

از تمام داده‌های حساس مانند:

دیتابیس‌ها

فایل‌های کانفیگ

فایل‌های آپلود شده توسط کاربر
نسخه‌ی پشتیبان تهیه کنید و مطمئن شوید بازیابی آن تست شده باشد.


۳. بررسی پیش‌نیازها و ناسازگاری‌ها

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

۴. آماده‌سازی محیط آپدیت

خالی بودن فضای ذخیره‌سازی کافی

اطمینان از دسترسی به اینترنت یا منابع داخلی برای دریافت فایل‌های به‌روزرسانی

داشتن دسترسی‌های لازم (مانند دسترسی root یا admin)


۵. دریافت و اعتبارسنجی فایل‌های به‌روزرسانی

فایل‌های به‌روزرسانی باید:

به صورت امن دانلود شوند.

از طریق Checksum یا امضای دیجیتال اعتبارسنجی شوند.


۶. انجام عملیات آپدیت

توقف سرویس‌های مربوطه در صورت نیاز

جایگزینی یا نصب فایل‌های جدید

اجرای اسکریپت‌های Migration برای بروزرسانی دیتابیس


۷. راه‌اندازی مجدد سرویس و انجام تست‌های اولیه

اجرای سرویس‌ها

بررسی لاگ‌ها برای خطاهای احتمالی

انجام تست‌های Smoke یا Sanity برای اطمینان از صحت عملکرد برنامه


۸. آماده بودن برای بازگردانی (Rollback)

در صورت بروز خطا:

نسخه‌ی قبلی بازیابی شود.

دیتابیس یا تنظیمات به حالت قبل برگردانده شوند.

علت خطا مستندسازی و تحلیل شود.



---

قالب پیشنهادی برای نوشتن سناریو

عنوان: سناریوی آپدیت نرم‌افزار [نام برنامه]

هدف: ارتقا از نسخه [فعلی] به نسخه [جدید] بدون ایجاد اختلال یا از دست رفتن داده.

مراحل:
1. شناسایی نسخه فعلی و مقصد
2. تهیه نسخه پشتیبان از [لیست منابع]
3. بررسی پیش‌نیازها
4. آماده‌سازی فایل‌های آپدیت
5. توقف سرویس‌های در حال اجرا (در صورت نیاز)
6. اعمال تغییرات و آپدیت سیستم
7. راه‌اندازی مجدد سرویس
8. بررسی صحت عملیات
9. اجرای سناریوی بازگردانی در صورت بروز خطا

نکات ویژه:
- زمان‌بندی آپدیت (ترجیحاً در ساعات کم ترافیک)
- اطلاع‌رسانی به کاربران پیش از شروع عملیات
- تست‌های Post-Deployment


---

⭐️سخن پایانی

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

به خاطر داشته باشید: در دنیای نرم‌افزار، یک آپدیت موفق برابر است با یک گام بزرگ به سوی حرفه‌ای بودن.


💙Anophel

💙مقایسه Rust و Go: کارایی، امنیت و سادگی

💠وقتی زبان‌های برنامه‌نویسی Rust و 💢Go را کنار هم قرار می‌دهید، اولین چیزی است که متوجه می‌شوید که این دو زبان، مخاطبان بسیار متفاوتی را هدف قرار می‌دهند.

و📱 Rust برای کسانی که در محراب امنیت حافظه و برنامه‌نویسی همزمان بی‌باکانه می‌پرسند، حرف‌های دلنشین می‌زند. از سوی دیگر، گو با روش ساده و عملی خود، مهندسان را جذب کند که می‌خواهند بدون درگیری با پیچیدگی‌های فنی، سریعاً به نتایج عملی دست یابند.


🔗 مقایسه Rust و Go: کارایی، امنیت و سادگی


#rust #golang #go #گو #گولنگ

💢Race Conditions in Golang: Break, Detect, and Fix Like a Pro! 🚀 | Anophel

⭐️https://youtu.be/rFFcsQygtZQ

👍Like, Subscribe, and Comment: What Go topic should we cover next? Goroutines, channels, or something else? Let me know!

💙مقایسه Shared Memory و Message Passing در Go: کدام روش بهتر است؟

💠در دنیای برنامه‌نویسی هم‌زمان (Concurrent Programming)، یکی از چالش‌های اصلی، برقراری ارتباط بین thread ها یا گوروتین‌ها (Goroutines) است. زبان برنامه‌نویسی Go (Golang) به دلیل طراحی ساده، کارآمد و ایمن، به یکی از محبوب‌ترین زبان‌ها برای توسعه نرم‌افزارهای چند thread ی تبدیل شده است. در Go، دو روش اصلی برای ارتباط بین گوروتین‌ها وجود دارد: حافظه اشتراکی (Shared Memory) و انتقال پیام (Message Passing). این مقاله به بررسی این دو روش، مزایا و معایب آن‌ها، و توصیه‌های Go برای استفاده از کانال‌ها (Channels) به جای حافظه اشتراکی می‌پردازد. با استفاده از یک مطالعه موردی ساده و مثال‌های عملی، تفاوت‌های این دو روش را به‌صورت عمیق بررسی می‌کنیم و به مشکلات رایجی مانند Deadlock و نحوه رفع آن‌ها اشاره خواهیم کرد.


🔗مقایسه Shared Memory و Message Passing در Go: کدام روش بهتر است؟

#گولنگ #گو
#go #golang #software

❗در MySQL، پارتیشن‌بندی (Partitioning) یک تکنیک برای تقسیم یک جدول بزرگ به بخش‌های کوچکتر و قابل مدیریت‌تر به نام پارتیشن است. این پارتیشن‌ها از نظر منطقی بخشی از یک جدول هستند، اما از نظر فیزیکی به صورت جداگانه ذخیره می‌شوند. هدف از پارتیشن‌بندی بهبود کارایی (performance) و مدیریت داده‌ها است.

🫶چرا از پارتیشن‌بندی استفاده می‌کنیم؟

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


مدیریت بهتر داده‌ها: حذف یا آرشیو کردن داده‌های قدیمی بسیار ساده‌تر است.


تسهیل در نگهداری: می‌توان فقط یک پارتیشن را بازسازی یا پشتیبان‌گیری کرد.

🟡حدودیت‌ها:

Index‌ها محدودیت‌هایی دارند (مثلاً فقط می‌توان روی ستون‌های پارتیشن‌شده ایندکس گذاشت).


FOREIGN KEY پشتیبانی نمی‌شود.


فقط در Storage Engine=InnoDB و NDB پشتیبانی می‌شود.


مقدار NULL باید در نظر گرفته شود چون می‌تواند باعث بروز خطا شود.

💙 Anophel

💠چطور یک گزارش باگ بانتی حرفه‌ای بنویسیم؟

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


---

۱. عنوان شفاف و دقیق

از همون اول واضح بگو مشکل چیه و کجاست.
مثال:

Stored XSS in comment section allows script execution as guest user




---

۲. خلاصه‌ی باگ (Bug Summary)

توضیح بده باگ چیه، کی می‌تونه ازش سوءاستفاده کنه، و نتیجه‌ش چیه.

مثال:

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




---

۳. مراحل بازتولید (Steps to Reproduce)

قدم‌به‌قدم توضیح بده چطور باگ رخ می‌ده. دقیق و بدون ابهام.

مثال:

1. وارد فرم دیدگاه شوید.


2. این payload را ارسال کنید:

<script>alert(document.cookie)</script>

3. اکانت مدیر وارد پیشخوان شود و صفحه دیدگاه‌ها را باز کند.


4. اسکریپت اجرا می‌شود.




---

۴. نتیجه واقعی (Actual Result)

بگو دقیقاً چه اتفاقی می‌افته.
مثال:

> اسکریپت اجرا می‌شود و دسترسی کاربر قربانی در معرض خطر است.




---

۵. نتیجه مورد انتظار (Expected Result)

باید چی می‌شد؟
مثال:

> کد HTML باید escape می‌شد و به عنوان متن ساده نمایش داده می‌شد.




---

۶. شدت آسیب (Impact)

بر اساس سناریو واقعی توضیح بده این باگ چه آسیبی می‌زنه.
مثال:

> مهاجم می‌تونه کوکی admin رو بدزده یا درخواست‌های مخرب اجرا کنه. خطر بالا (High/Critical).




---

۷. پیشنهاد رفع (Suggested Fix)

اگر بلدی، پیشنهاد رفع هم بده.
مثال:

> استفاده از ()wp_kses_post برای فیلتر کردن ورودی فرم دیدگاه.




---

۸. ضمائم (Proof of Concept یا ویدیو/تصویر)

هر چی نشون بده باگ واقعیه، ضمیمه کن. فیلم، اسکرین‌شات، curl request یا Burp request.


---

جمع‌بندی

یک گزارش خوب باید:

ساده و واضح باشه

بازتولیدش راحت باشه

اطلاعات اضافی نداشته باشه


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

Anophel

💙React Query یا Redux Toolkit؟ بهترین انتخاب مدیریت State و داده 2025

💙تصور کنید در میانه یک پروژه بزرگ، ساعت از نیمه‌شب گذشته و شما هنوز در حال کلنجار رفتن با یک باگ عجیب در مدیریت State هستید. مانیتور مقابلتان پر از خطوط کد است، فنجان قهوه‌تان برای سومین بار سرد شده، و کامپوننتی که باید داده‌های سرور را نمایش دهد، انگار در دنیای خودش سیر می‌کند. اکشن‌های Redux اجرا شده‌اند، Reducerها کارشان را کرده‌اند، اما صفحه همچنان خالی است. ناگهان به خودتان می‌گویید: «چرا این‌قدر همه‌چیز پیچیده است؟»

🔗React Query یا Redux Toolkit؟ بهترین انتخاب مدیریت State و داده 2025

#react #react_query

💠داستان نشت حافظه در Map، مقایسه Go و Rust

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

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

treasureChest := make(map[int][128]byte)
// پر کردن map
for i := 0; i < 1_000_000; i++ {
    treasureChest[i] = [128]byte{}
}
// پردازش داده‌ها...
// پاک‌سازی map
for i := 0; i < 1_000_000; i++ {
    delete(treasureChest, i)
}
runtime.GC() // اجرای دستی جمع‌آوری زباله

با وجود اجرای کامل delete روی کل map و همچنین فراخوانی مستقیم runtime.GC(), حافظه اشغال‌شده توسط برنامه به‌طور محسوسی کاهش نیافت.

💢علت رفتار Go
در Go، ساختار داخلی map به‌گونه‌ای طراحی شده که برای حفظ عملکرد، حافظه‌ی اختصاص‌یافته به bucketها را حتی پس از حذف مقادیر، بلافاصله آزاد نمی‌کند. این یعنی حتی زمانی‌که map منطقی خالی است، ساختار داده‌ای پشت آن همچنان بخش قابل‌توجهی از حافظه را نگه می‌دارد. جمع‌آورنده زباله (GC) نیز به‌دلیل باقی‌ماندن رفرنس‌های داخلی، این حافظه را آزاد نخواهد کرد — مگر در شرایط خاصی که بازسازی map یا اختصاص مجدد صورت گیرد.

📱مقایسه با Rust
برای ارزیابی رفتار متفاوت، همان سناریو در Rust با استفاده از HashMap پیاده‌سازی شد. پس از بارگذاری داده‌ها و استفاده از clear() برای حذف کامل محتوا، حافظه بلافاصله آزاد شد و مصرف به وضعیت اولیه بازگشت. در Rust، حافظه تحت مالکیت صریح داده‌هاست و زمانی که داده‌ها حذف می‌شوند، حافظه‌ی مربوط به آن‌ها نیز آزاد می‌شود؛ مگر این‌که عمداً نگه‌داری شود.

use std::collections::HashMap;

fn main() {
    let mut treasure_chest: HashMap<u32, [u8; 128]> = HashMap::new();
    for i in 0..1_000_000 {
        treasure_chest.insert(i, [0u8; 128]);
    }
    // پردازش داده‌ها...
    treasure_chest.clear(); // آزادسازی حافظه
}

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

❗نکته کلیدی: استفاده از map در زبان‌هایی مانند Go ممکن است رفتارهایی فراتر از سطح کد نشان دهد که در سناریوهای حساس به حافظه باید مورد توجه قرار گیرد. در شرایطی که کنترل دقیق بر حافظه لازم است، زبان‌هایی با مدل حافظه صریح‌تر مانند Rust انتخاب بهتری خواهند بود.

💙Anophel