احتمالا این اتفاق برای اکثر ماها افتاده ولی خوبه درخصوصش بقیه هم بدونن.

#ویکی_تجربه
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

🥳 Go 1.23.4 and 1.22.10 are released!

🗣 Announcement: https://groups.google.com/g/golang-announce/c/3DyiMkYx4Fo?pli=1

⬇️ Download: go.dev/dl/#go1.23.4

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

وقتی میخوای از CPU حسابی کار بکشی 😂😂

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

یه مطلب خوب درخصوص ثبات یا ریجستری

https://news.1rj.ru/str/SoniaNotes/879

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

🎊 Go 1.24 Release Candidate 1 is released!

📄 draft note: https://tip.golang.org/doc/go1.24

🔈 Announcement: https://groups.google.com/g/golang-announce/c/vYMfuq_XO6w

📦 Download: go.dev/dl/#go1.24rc1

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Go Developer Survey 2024 H2 Results

Go was designed with a focus on developer experience, and we deeply value the feedback we receive through proposals, issues, and community interactions. However, these channels often represent the voices of our most experienced or engaged users, a small subset of the broader Go community.

https://go.dev/blog/survey2024-h2-results

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Decorator pattern in Go

In Go (Golang), decorators are not a built-in feature as they are in some other languages like Python. However, you can achieve similar functionality using higher-order functions. A higher-order function is a function that takes one or more functions as arguments and/or returns a function.

In Go, you can create a decorator by defining a function that takes another function as an argument, wraps it in some additional behavior, and returns a new function. Here is a simple example to demonstrate this concept:

✅ Example: Logging Decorator

Let's create a logging decorator that logs the execution time of a function.

1. Define a function type that will be decorated:

package main

import (
  "fmt"
  "time"
)

// Function type that takes an int and returns an int
type IntOperation func(int) int

// Sample function to be decorated
func square(n int) int {
  return n * n
}

2. Create the decorator function:

// LoggingDecorator is a decorator that logs the execution time of a function
func LoggingDecorator(fn IntOperation) IntOperation {
  return func(n int) int {
    start := time.Now()
    result := fn(n)
    fmt.Printf("Execution time: %v\n", time.Since(start))
    return result
  }
}

3. Use the decorator:

func main() {
  // Apply the LoggingDecorator to the square function
  decoratedSquare := LoggingDecorator(square)

  // Call the decorated function
  fmt.Println("Result:", decoratedSquare(5))
}

✅ Explanation

- IntOperation: A type alias for a function that takes an int and returns an int.
- square: A sample function that calculates the square of an integer.
- LoggingDecorator: A decorator function that takes an IntOperation function, wraps it with logging behavior, and returns a new IntOperation function.
- In the main function, we apply the LoggingDecorator to the square function and call the decorated function.

When you run this code, it will output the result of the square function and log the execution time.

✅ Use Cases

Decorators can be useful for:
- Logging
- Caching
- Validating input
- Measuring performance
- Handling retries

By using higher-order functions, you can implement these behaviors in a reusable and modular way in Go.

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

دوستان اگه اپلیکیشن رو بصورت مونولیت مینیوسید، کار خوبی میکنید، اما aggregation pattern رو جدی بگیرید، کمک بزرگی میکنه به حفظ loosely coupled بودن ماژول و سرویس هاتون.

یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه.

بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه.

بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده
https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation

باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش
https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2

#gocasts | #hossein
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

یکی این عکس رو گذاشته لینکدین نوشته رفتم شرکت رهپویان‌‌ اندیشه برای پوزیشن UI/UX Designer و این سوالات رو بعنوان سوالات آزمون استخدامی گذاشتن جلوم!!

دیوونه خونه‌اس قشنگ.

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

تجربه یه incident با رعایت نکردن اصول ساده

خیلی وقت ها پیش میاد که ما یه سری نکته ساده رو رعایت نمی کنیم و همین موضوع باعث میشه که مشکلات بزرگی در سیستم رخ بده.

من سعی میکنم نکات کوچیکی که طبق تجربه خودم داشتم یا اطرافیانم داشتند رو گاه به گاه منتشر کنم. امروز در مورد یکی از این موارد که باعث incident هم شد صحبت می کنم.

قبل از اینکه شرح بدم incident چی بود در مورد root cause صحبت می کنم که تابع Get از پکیج net/http بود. خیلی هاتون ممکنه برای ارسال درخواست های http در گولنگ از این تابع استفاده کنید و خیلی کار رو هم ساده می کنه.

https://pkg.go.dev/net/http#Get


اسم سرویس ها یه چیز دیگه ست من ساده سازی کردم.
یه سرویس اصلی رو در نظر بگیرید که وقتی درخواست بهش میرسه، ابتدا یه سری اطلاعات رو از طریق یه درخواست http از یه سرویس خارجی دریافت میکنه و بعد پاسخ درخواست کاربر رو پس میده.
حالا تصور کنید این سرویس کارهای دیگه ای هم انجام میده، مثلا همین سرویس برای انجام paymentها یه ماژول پرداخت داره که باز هم از درخواست های http استفاده میکنه که با ipgها صحبت کنه و پرداخت هارو انجام بده.

این سرویس با همین مشخصات روی پروداکشن زیر لود بود که فهمیدیم سرویس خارجی ای که اطلاعات رو ازش میگیریم خیلی latency بالایی داره و همین باعث شده درخواست های زیادی باز بمونن برای مدت طولانی و مصرف رم و cpu سرویس بالا رفته و پاسخ ها دچار response time بالا شدن.

اولین نکته ای که به ذهن میرسه اینه که خب بهتره از context timeout استفاده کنیم برای درخواست ها که مثلا یه درخواست http به سرویس خارجی بیشتر از ۳۰ ثانیه باز نمونه.
که خب تابع Get خودش ورودی context نمیگیره، پس باید به فکر راه دیگه ای بود.
برنامه نویس فهمیده بود که تابع Get داره از http.DefaultClient استفاده میکنه و این client یه فیلد timeout داره، پس خیلی سریع تایم اوت رو ست کرد، به این صورت

http.DefaultClient.Timeout = time.Second * 5

کد دیپلوی شد و رفت روی پروداکشن، اتفاقی که افتاد این بود که دیگه مشکل response time وجود نداشت برای سرویس خارجی و اگه درخواست بیشتر از ۵ ثانیه طول میکشید کنسل میشد.

اما یه مشکل جدید خیلی بد بوجود اومده بود، ماژول پرداخت به فنا رفته بود و نمیتونست پرداخت هارو درست مدیریت کنه.

علت چی بود؟‌ علت این بود که اونم داشت از http.Get استفاده میکرد و با تنظیم شدن تایم اوت ۵ ثانیه، اونم درخواست های بیشتر از ۵ ثانیه رو کنسل میکرد.

خب خیلی ها شنیدید که الگوی singleton خیلی جاها میتونه bad practice باشه و یکی از اون جاها همین default http clientی هست که پکیج net/http ارائه میده.

درست ش این بود که هر ماژول برای درخواست های خودش یه http client مجزا داشته باشه که تایم اوت خاص خودش رو ست کنه. حتی میشه از این تابع NewRequestWithContext
استفاده کرد که context رو هم پشتیبانی کنه.

https://pkg.go.dev/net/http#NewRequestWithContext


مشکل singleton اینه که side effectهای تغییر singleton object مبهم میشه، شما میای برای درخواست های سرویس خارجی تایم اوت ست کنی، ولی عملا درخواست های پرداخت رو به فنا میدی..

پکیج net/http و پکیج های دیگه گولنگ برای راحتی استفاده خیلی وقت ها یه default object ارائه میدن، ولی واقعا باید برای استفاده از این objectها احتیاط کرد. بهتره instance خاص خودت رو بسازی که مدیریت stateش فقط خودت رو تحت تاثیر بذاره و side effect نداشته باشه.

#gocast | #hossein
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

در نسخهٔ ۱.۲۴ زبان Go، اشاره‌گرهای ضعیف (Weak Pointers) معرفی شده‌اند که امکان ارجاع به اشیاء در حافظه را بدون جلوگیری از جمع‌آوری آن‌ها توسط جمع‌کنندهٔ زباله (Garbage Collector) فراهم می‌کنند.

مزیت اصلی اشاره‌گرهای ضعیف:

اشاره‌گرهای ضعیف به شما اجازه می‌دهند به اشیائی در حافظه اشاره کنید بدون اینکه مانع جمع‌آوری آن‌ها توسط جمع‌کنندهٔ زباله شوید. این ویژگی در ساختارهایی مانند کش‌ها (Caches) یا نقشه‌های هم‌ارزی (Canonicalization Maps) مفید است، جایی که می‌خواهید تنها یک نسخه از داده‌ها را نگه دارید و در عین حال اجازه دهید داده‌های غیرضروری به‌طور خودکار از حافظه حذف شوند.

مثال: ساخت یک کش با استفاده از اشاره‌گرهای ضعیف

فرض کنید می‌خواهیم یک کش ایجاد کنیم که داده‌های موقت را ذخیره کند و اجازه دهد جمع‌کنندهٔ زباله داده‌های غیرضروری را حذف کند:

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
    "weak"
)

// Cache ساختار کش با اشاره‌گرهای ضعیف
type Cache[K comparable, V any] struct {
    mu    sync.Mutex
    items map[K]weak.Pointer[V]
}

// NewCache ایجاد یک نمونهٔ جدید از کش
func NewCache[K comparable, V any]() *Cache[K, V] {
    return &Cache[K, V]{
        items: make(map[K]weak.Pointer[V]),
    }
}

// Get بازیابی یک آیتم از کش در صورت موجود بودن
func (c *Cache[K, V]) Get(key K) (*V, bool) {
    c.mu.Lock()
    defer c.mu.Unlock()

    ptr, exists := c.items[key]
    if !exists {
        return nil, false
    }

    val := ptr.Value()
    if val == nil {
        delete(c.items, key)
        return nil, false
    }
    return val, true
}

// Set افزودن یک آیتم به کش
func (c *Cache[K, V]) Set(key K, value V) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.items[key] = weak.Make(&value)
}

func main() {
    // ایجاد کش با کلیدها و مقادیر رشته‌ای
    cache := NewCache[string, string]()

    // افزودن یک داده به کش
    data := "cached data"
    cache.Set("key1", data)

    // بازیابی داده
    if val, ok := cache.Get("key1"); ok {
        fmt.Println("Cache hit:", *val)
    } else {
        fmt.Println("Cache miss")
    }

    // شبیه‌سازی از دست دادن ارجاع قوی
    data = ""
    runtime.GC() // اجرای جمع‌کنندهٔ زباله

    // تلاش برای بازیابی مجدد داده
    time.Sleep(1 * time.Second)
    if val, ok := cache.Get("key1"); ok {
        fmt.Println("Cache hit:", *val)
    } else {
        fmt.Println("Cache miss")
    }
}

در این مثال:

ساختار Cache از یک نقشه با اشاره‌گرهای ضعیف برای ذخیرهٔ داده‌ها استفاده می‌کند.

با استفاده از weak.Make، یک اشاره‌گر ضعیف به داده ایجاد می‌شود.

در صورت عدم وجود ارجاع قوی به داده، جمع‌کنندهٔ زباله می‌تواند آن را حذف کند و ptr.Value() مقدار nil برمی‌گرداند.


مزایای استفاده از اشاره‌گرهای ضعیف در این سناریو:

کارایی حافظه: اشیائی که دیگر استفاده نمی‌شوند، توسط جمع‌کنندهٔ زباله حذف می‌شوند و مصرف حافظه کاهش می‌یابد.

پاک‌سازی خودکار: نیازی به پیاده‌سازی منطق پیچیده برای حذف دستی داده‌های قدیمی نیست.

ایمنی در برابر شرایط رقابتی: اشاره‌گرهای ضعیف به‌طور مؤثر در ساختارهای ایمن در برابر شرایط رقابتی مانند Cache استفاده می‌شوند.


با استفاده از اشاره‌گرهای ضعیف، می‌توان کش‌هایی ساخت که به‌طور خودکار داده‌های غیرضروری را حذف کرده و کارایی حافظه را بهبود بخشند.

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

🚀 پکیج algo مجموعه‌ای از الگوریتم‌های پرفورمنس بالا و بهینه

سعی کردم در این پکیج یکسری الگوریتم های خاص بصورت بهینه و با بدون وابستگی به dependency های خارجی قرار دهم و فعلا یک الگوریتم را توسعه دادم و بزودی برخی الگوریتم های دیگر نظیر Reservoir Sampling, Consistent Hashing و برخی دیگر را قرار دهم.

در حال حاضر الگوریتم زیر را تکمیل کردم و قرار دادم.

✅ انتخاب تصادفی وزنی (Random Weighted Selection)

📌 مشاهده پکیج و مستندات:
🔗 گیت‌هاب: https://github.com/Ja7ad/algo
📚 مستندات: https://pkg.go.dev/github.com/Ja7ad/algo

🔥 خوشحال می‌شوم نظرات و پیشنهاداتتان را بشنوم! اگر علاقه‌مند به مشارکت در توسعه این پکیج هستید، PR بفرستید! 💡

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers