Scaling API Independence: Mocking, Contract Testing & Observability in Large Microservices Environments
https://www.infoq.com/presentations/microservices-mocking-observability/

google/adk-go: An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
https://github.com/google/adk-go

🔵 عنوان مقاله
go-sqlite3: Go Bindings to SQLite Using Wazero

🟢 خلاصه مقاله:
این کتابخانه با نام go-sqlite3 امکان استفاده از SQLite در Go را بدون cgo فراهم می‌کند. هسته SQLite به‌صورت WebAssembly اجرا و درون runtimeِ wazero بارگذاری می‌شود، در حالی‌که رابطی سازگار با database/sql ارائه می‌دهد. نتیجه این است که بیشتر کدهای موجود مبتنی بر database/sql با کمترین تغییر کار می‌کنند و در عوض، مزایایی مثل باینری‌های کاملاً استاتیک، کراس‌کامپایل آسان، وابستگی‌های کمتر به سیستم‌عامل و استقرار ساده‌تر (به‌ویژه در کانتینر و Serverless) به دست می‌آید. اجرای SQLite داخل WebAssembly علاوه‌بر یک محیط ایزوله و قابل پیش‌بینی، ممکن است محدودیت‌هایی هم داشته باشد؛ از جمله عدم پشتیبانی برخی افزونه‌های بومی و کارایی پایین‌تر نسبت به نسخه‌های cgo. با این حال برای بسیاری از کاربردها مانند ابزارهای خط فرمان، سرویس‌های سبک، تست‌ها و محیط‌های ابری، این مبادله به‌خاطر قابل‌حمل بودن و سادگی عملیاتی ارزشمند است.

#Go #SQLite #WebAssembly #wazero #database_sql #cgo #GoBindings #Serverless

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

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

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

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

همزمانی (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 کوچک شروع و رشد می‌کنند

🔵 عنوان مقاله
Revisiting Interface Segregation in Go

🟢 خلاصه مقاله:
این مطلب «Interface Segregation Principle (ISP)» را از منظر Go مرور می‌کند: مشتری نباید به متدهایی وابسته شود که از آن‌ها استفاده نمی‌کند. در Go، راهکارهای رایج شامل ساختن رابط‌های کوچک و رفتاری، تعریف رابط‌ها در محل استفاده، «پذیرفتن interface و برگرداندن نوع‌های concrete»، و الهام گرفتن از نمونه‌های استاندارد مثل io.Reader و io.Writer است.

مشکل وقتی پیش می‌آید که یک پکیج، رابط‌های چاق و همه‌چیزدار صادر می‌کند؛ این کار تغییرات را سخت و پیاده‌سازی‌ها را پر از متدهای بی‌مصرف می‌کند. بهتر است رابط‌های کوچک را ترکیب یا embed کنیم، فقط وقتی واقعاً لازم است سراغ رابط‌های بزرگ برویم، و از میان‌افزارها/adapterها برای سازگاری در مسیر ریفکتور کمک بگیریم.

راهبرد عملی: ابتدا پیاده‌سازی‌های concrete بسازید، بعد بر اساس نیاز واقعی رابط استخراج کنید؛ مجموعه‌متدها را کوچک نگه دارید، برای تست از فیک/ماک بهره ببرید، و APIها را تدریجی تکامل دهید. با وجود generics هم باید از تعمیم بی‌جا پرهیز کرد و رابط‌های runtime را بر رفتار متمرکز نگه داشت. نتیجه پایبندی به ISP در Go، کدی ساده‌تر برای تست، نگهداشت و توسعه است؛ نکاتی که در تازه‌ترین مطلب معرفی‌شده توسط Golang Weekly نیز برجسته شده‌اند.

#Go #Golang #InterfaceSegregation #ISP #GoInterfaces #SoftwareDesign #Refactoring #GolangWeekly

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

💋چی کار می‌کنه sync.Once

تضمین می‌کنه یک تابع دقیقاً یک‌بار اجرا بشه حتی اگر چندین goroutine هم‌زمان تلاش کنن اون رو اجرا کنن. متد اصلیش Do(f func()) هست: اولین فراخوانی Do تابع f را اجرا می‌کنه و فراخوانی‌های بعدی هیچ کاری نمی‌کنن (بلوک نمی‌شن؛ فقط بازمی‌گردن).

💋موارد متداول استفاده

* پیاده‌سازی Singleton (یک‌بار ساختن نمونهٔ مشترک).
* بارگذاری تنبل (lazy load) کانفیگ یا منابع سنگین فقط وقتی لازم شدن.
* عمل‌هایی که باید فقط یک‌بار انجام بشن (مثلاً ثبت یک handler، close ای که نباید دوباره انجام بشه، و غیره).

مثال ساده (Singleton)

var instance *MyType
var once sync.Once

func GetInstance() *MyType {
    once.Do(func() {
        instance = &MyType{ /* init */ }
    })
    return instance
}

مثال: امن کردن close یک channel`

var once sync.Once
var ch = make(chan struct{})

func safeClose() {
    once.Do(func() { close(ch) })
}

💋 نکات و خطرات (خیلی مهم)

1. اگر تابعِ داخل `Do` پانیک کند: در نسخهٔ فعلیِ استاندارد، Do آن فراخوانی را «تمام‌شده» در نظر می‌گیرد — یعنی بعد از پانیک، فراخوانی‌های بعدی Do دیگر f را اجرا نخواهند کرد. (در عمل پانیک به caller برمی‌گردد ولی Once وضعیتِ «انجام‌شده» را علامت می‌زند). پس اگر f ممکن است پانیک کند یا نیاز به retry دارید، sync.Once ممکن است مناسبِ کامل نباشد.

> (نکته: در Go 1.21 به‌علاوه توابعی مثل OnceFunc / OnceValue اضافه شدند که رفتار پانیک/بازگردانی را متفاوت ارائه می‌دهند؛ خوب است اگر از این ورژن‌ها استفاده می‌کنید نگاهی به مستندات بیندازید).

2.ا `Once` را بعد از استفاده کپی نکنید — کپی کردن یک Once بعد از اولین استفاده خطا/رفتار غیرمنتظره ایجاد می‌کند.
3. تابعِ داخل `Do` نباید خودش `Do` را صدا بزند (یا باعث قفل/deadlock شود). اگر f در همان Once دوباره Do را فراخوانی کند، قفل/deadlock یا رفتار نامناسب ممکن است رخ دهد. (به‌صورت کلی از بلوک‌های طولانی یا عملیات که ممکن است بلوکه شوند داخل f خودداری کنید).

4. ا`Do` مقدار/خطا برنمی‌گرداند — اگر تابع شما ممکن است خطا داشته باشد و بخواهید آن را به callerها برگردانید، معمولاً از pattern زیر استفاده می‌کنند:

var once sync.Once
var cfg Config
var cfgErr error

func LoadConfig() error {
    once.Do(func() {
        cfg, cfgErr = loadFromDisk()
    })
    return cfgErr
}

اما دقت کنید: اگر loadFromDisk پانیک کند یا با خطاهای خاصی مواجه شود و شما نیاز به retry داشته باشید، این الگو کافی نیست چون Do بعد از اولین اجرا (حتی اگر پانیک شد) اجازهٔ تکرار نمی‌دهد.

💋 پیشنهاد وقتی می‌خواهید retry یا مقدار/خطای دقیق داشته باشید

اگر نیاز دارید تابع مقدار برگردونه و رفتارِ retry داشته باشید، باید از الگوهای دیگری استفاده کنید (مثلاً mutex + state machine، یا کانال‌ها، یا بسته‌های ثالث که این الگو رو پیاده‌سازی می‌کنن). در Go 1.21 توابعی مثل OnceValue هم اضافه شدند که کمک می‌کنند مقدار بازگردونده و رفتار پانیک مشخص‌تر بشه

بیایید هر دو حالت را ببینیم:
۱️⃣ نمونهٔ Retry‌دار (برای مواقعی که تابع ممکن است خطا بدهد)
۲️⃣ نمونهٔ واقعی‌تر (مثلاً بارگذاری فایل کانفیگ فقط یک‌بار)

---
🧩 مثال ۱: sync.Once با قابلیت Retry

sync.Once به‌صورت پیش‌فرض فقط یک‌بار اجرا می‌شود — حتی اگر اون اجرا شکست بخوره.
اما گاهی می‌خواهیم تابع فقط *در صورت موفقیت* «once» باشد، وگرنه دفعهٔ بعدی دوباره تلاش کند.
برای این کار، باید رفتار خودمان را روی Once شبیه‌سازی کنیم:

package main

import (
  "errors"
  "fmt"
  "sync"
)

type OnceRetry struct {
  mu    sync.Mutex
  done  bool
}

func (o *OnceRetry) Do(f func() error) error {
  o.mu.Lock()
  defer o.mu.Unlock()

  if o.done {
    return nil
  }

  err := f()
  if err != nil {
    return err
  }

  o.done = true
  return nil
}

func main() {
  var once OnceRetry
  counter := 0

  task := func() error {
    counter++
    if counter < 3 {
      fmt.Println("❌ Failed attempt", counter)
      return errors.New("temporary error")
    }
    fmt.Println("✅ Success on attempt", counter)
    return nil
  }

  for i := 0; i < 5; i++ {
    err := once.Do(task)
    if err != nil {
      fmt.Println("Error:", err)
    }
  }

  fmt.Println("Final counter =", counter)
}

🟢 نتیجه خروجی:

❌ Failed attempt 1
Error: temporary error
❌ Failed attempt 2
Error: temporary error
✅ Success on attempt 3
Final counter = 3

یعنی تابع تا زمانی که موفق نشده، باز هم قابل اجراست — اما بعد از موفقیت فقط یک‌بار انجام می‌شود ✅

🧱 مثال ۲: بارگذاری فایل کانفیگ فقط یک‌بار (Real-world)

package main

import (
  "encoding/json"
  "fmt"
  "os"
  "sync"
)

type Config struct {
  Port int    `json:"port"`
  Mode string `json:"mode"`
}

var (
  cfg     Config
  cfgErr  error
  cfgOnce sync.Once
)

func LoadConfig() (Config, error) {
  cfgOnce.Do(func() {
    fmt.Println("📁 Reading config.json only once...")
    data, err := os.ReadFile("config.json")
    if err != nil {
      cfgErr = err
      return
    }
    cfgErr = json.Unmarshal(data, &cfg)
  })
  return cfg, cfgErr
}

func main() {
  for i := 0; i < 3; i++ {
    c, err := LoadConfig()
    if err != nil {
      fmt.Println("Error:", err)
    } else {
      fmt.Println("Loaded config:", c)
    }
  }
}

🔹 حتی اگر LoadConfig() چندبار فراخوانی شود، فایل فقط یک‌بار خوانده می‌شود.
🔹 در برنامه‌های بزرگ (microserviceها، سرورها، یا SDKها) این pattern خیلی رایج است.

🔵 عنوان مقاله
Chans: Building Blocks for Idiomatic Go Pipelines

🟢 خلاصه مقاله:
** آنتون در مقاله «Chans: Building Blocks for Idiomatic Go Pipelines» بسته‌ی chans را معرفی می‌کند؛ مجموعه‌ای از عملگرهای عمومی و نوع‌امن روی channelها در زبان Go—مثل filter، map، partition و takeWhile—برای ساختpipelineهای همزمان به‌شکل idiomatic. این بسته با کاهش کد تکراری و افزایش ترکیب‌پذیری، نوشتن جریان‌های پردازش داده را ساده‌تر، خواناتر و قابل نگه‌داری‌تر می‌کند و برای پردازش جریان‌ها، رویدادها و کارهای IO-محور بسیار کاربردی است.

#Go #Concurrency #Channels #Pipelines #Generics #FunctionalProgramming #SoftwareEngineering

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

Here's a toy example:

// Given a channel of documents.
docs := make(chan []string, 10)
docs <- []string{"go", "is", "awesome"}
docs <- []string{"cats", "are", "cute"}
close(docs)

// Extract all words from the documents.
words := make(chan string, 10)
chans.Flatten(ctx, words, docs)
close(words)

// Calculate the total byte count of all words.
step := func(acc int, word string) int { return acc + len(word) }
count := chans.Reduce(ctx, words, 0, step)
fmt.Println("byte count =", count)

byte count = 22

✅ این تصویر نمونه‌ای از مفهوم Summary برای یک bitmap در حافظه‌ی Go رو نشون می‌ده

🧩 این Bitmap Summary در مدیریت صفحات Go

در این شکل، هر بیت از bitmap نشان‌دهنده‌ی وضعیت یک صفحه‌ی حافظه است:

* 0 → صفحه آزاد (free)
* 1 → صفحه در حال استفاده (allocated)

برای بهینه‌سازی جستجوی صفحات آزاد، Go برای هر bitmap سه مقدار خلاصه‌شده (summary) نگه می‌داره:

* start = 3 → یعنی در ابتدای bitmap، ۳ صفحه‌ی متوالی آزاد داریم
* end = 7 → یعنی در انتهای bitmap، ۷ صفحه‌ی متوالی آزاد داریم
* max = 10 → طولانی‌ترین دنباله‌ی صفحات آزاد در کل bitmap برابر با ۱۰ صفحه است

🔹 فلش در تصویر جهت افزایش آدرس حافظه (از پایین به بالا) رو نشون می‌ده.
در نتیجه، ۳ صفحه‌ی آزاد در بخش پایین‌تر حافظه (low address) و ۷ صفحه‌ی آزاد در بالاترین بخش (high address) قرار دارن.

این ساختار باعث می‌شه Go خیلی سریع‌تر بتونه محدوده‌های بزرگ از صفحات آزاد رو پیدا کنه بدون این‌که کل bitmap رو اسکن کنه — فقط با نگاه کردن به summaryها!
➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
progjpeg: image/jpeg But With Progressive Encoding Support

🟢 خلاصه مقاله:
progjpeg نسخه‌ای از بسته image/jpeg در زبان Go است که امکان Progressive Encoding را به آن اضافه می‌کند؛ قابلیتی که تصویر را ابتدا به‌صورت کم‌جزئیات نشان می‌دهد و در چند گذر با دریافت داده‌های بیشتر شفاف‌تر می‌شود. این ویژگی می‌تواند در شبکه‌های کند تجربه کاربری را بهبود دهد و توسط بیشتر مرورگرها و دیکدرهای تصویر پشتیبانی می‌شود. چون درخواست افزودن این قابلیت در مخزن رسمی Go «متوقف/فریز» شده بود، progjpeg این خلأ را برای توسعه‌دهندگان پر می‌کند. هرچند کاربرد آن تخصصی است، اما برای سرویس‌های وب و سامانه‌های سنگینِ تصویر می‌تواند تجربه بارگذاری روان‌تری فراهم کند، با درنظرگرفتن ملاحظاتی مثل پیچیدگی کدنویسی و تفاوت احتمالی در اندازه فایل.

#Go #Golang #JPEG #ProgressiveJPEG #ImageProcessing #WebPerformance #OpenSource

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

➖➖➖➖➖➖➖➖
👑 @gopher_academy

Clients should not be forced to depend on methods they do not use.

— Robert C. Martin (SOLID, interface segregation principle)