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

می‌خوام طی هفته‌های آینده یه جلسه گفت‌وگوی آنلاین یک ساعته با شما داشته باشم درباره‌ی تغییرات اخیر بازار کار و layoffهای جدید تحت تأثیر AI، این‌که الان در چه وضعیتی هستیم و در شرایط جدید چه اقداماتی خوبه که انجام بدیم صحبت کنیم.

اگر به شرکت در چنین گفت‌وگویی علاقه‌مندین، چه روز و ساعتی براتون مناسب‌تره؟ (به وقت ایران)
👇

🔶 خواهران و برادران : برای مدیریت بحران آب میگم.

یک تانکر هزار لیتری بخرید و نصب کنید. قیمتش ۷ یا ۸ میلیون تومانه

تانکر با آب شهری وصل می کنید که شناور داره و تانکر پر شد, خودش آب رو قطع می کند.

اگر روزی با قطع آب مواجه شدید, بتوانید خودکار با آب تانکر وصل بشید.

بحث مدیریت بحران و بقاست.

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

@TheRaymondDev

🔶 بفرمایید.

@TheRaymondDev

به MVC میگه Clean Architecture !!
شاید من معنی Clean Architecture را بد متوجه شدم.

https://youtube.com/watch?v=H9Blu0kWdZE

@DevTwitter | <Babak.uk/>

کشف نوع جدیدی از حمله‌ی سایبری: وقتی الگوهای ترافیک، راز گفتگوی شما با چت‌بات‌ها را لو می‌دهند!

باورتان می‌شود که هکرها می‌توانند از گفتگوهای شما با چت‌ چی‌پی‌تی (یا هر هوش مصنوعی مشابهی) مطلع شوند؟ البته این موضوع شرایط خاصی دارد که در ادامه توضیح می‌دهیم:

مایکروسافت در یک گزارشی پژوهشی جدید از یک حمله جدید با نام «Whisper Leak» خبر داده که می‌تواند بدون شکستن رمزنگاری، موضوع مکالمات کاربران با مدل‌های زبانی بزرگ (LLM) را شناسایی کند.

این حمله، به خاطر ضعف در پروتکل‌های رمزنگاری مانند HTTPS نیست، بلکه یک حمله‌ی تحلیل ترافیک (Side-Channel) محسوب می‌شود.

بر اساس این گزارش، زمانی که کاربر با یک چت‌بات هوش مصنوعی گفتگو می‌کند و پاسخ‌ها به صورت استریم (تکه‌تکه و لحظه‌ای) ارسال می‌شوند، الگوهای قابل تحلیلی در ترافیک شبکه شکل می‌گیرد؛ از جمله:

- اندازه بسته‌های داده
- فاصله زمانی میان ارسال بسته‌ها

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

در این مدل حمله، مهاجم به‌دنبال تشخیص مستقیم محتوای پیام‌ها نیست، بلکه بررسی می‌کند آیا گفتگو حول محور موضوعاتی خاص مانند مسائل سیاسی، مالی و… می‌چرخد یا نه.

آزمایش‌ها نشان داده‌اند که در برخی سناریوها، دقت این تشخیص به حدود ۹۸ درصد می‌رسد. این موضوع به‌ویژه از منظر حریم خصوصی نگران‌کننده است.

مایکروسافت تأکید می‌کند که این یافته‌ها به معنی ناامن بودن رمزنگاری نیست، بلکه نشان می‌دهد نحوه پیاده‌سازی استریم پاسخ در سرویس‌های هوش مصنوعی می‌تواند اطلاعات فراداده‌ای (متادیتا) حساسی را افشا کند.

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

- استفاده از VPN معتبر می‌تواند تحلیل ترافیک را برای مهاجم دشوارتر کند.

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

- سازمان‌ها و نهادها هنگام به‌کارگیری LLMها (ابری یا داخلی) باید حملات مبتنی بر تحلیل ترافیک را نیز در مدل تهدید خود لحاظ کرده، تست‌های امنیتی تکمیلی انجام دهند و از مکانیزم‌های دفاعی مناسب استفاده کنند.

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

جالب‌تر اینجا است که اینجا از یک هوش مصنوعی برای رمزگشایی از یک هوش مصنوعی دیگر استفاده می‌شود!

@DevTwitter | <NooshDaroo/>

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۱۶۷۵

از عشق تو هر طرف یکی شبخیزی
شب کشته ز زلفین تو عنبر بیزی
نقاش ازل نقش کند هر طرفی
از بهر قرار دل من تبریزی

#مولانا | گنجور
📍@iipoem

⭐️جلوگیری از حملات زیر به سادگی با یادگیری یک تکنیک لینوکسی:

حملاتی که به آدرس‌دهی ثابت متکی‌اند (مثل ROP یا Return-Oriented Programming)
حملات سرریز بافر (Buffer Overflow Attacks)
بهره‌برداری از فساد حافظه (Memory Corruption Exploits)
حملات برنامه‌نویسی بازگشت‌محور (Return-Oriented Programming - ROP

با فعال سازی KASLR:

🔹در هر بار بوت شدن سیستم، هسته در آدرسی تصادفی از حافظه بارگذاری می‌شود — یعنی آدرس هسته در هر بوت متفاوت است. این ویژگی باعث می‌شود حملاتی که به آدرس‌دهی ثابت متکی‌اند (مثل ROP یا Return-Oriented Programming) تقریباً غیرممکن شوند، چون مهاجم دیگر نمی‌داند کد هسته یا ساختارهای حساس حافظه دقیقاً کجا هستند.
1️⃣ فایل تنظیمات GRUB را باز کنید:

sudo nano /etc/default/grub


2️⃣ خط زیر را پیدا کنید:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


3️⃣ گزینه‌ی kaslr را به انتهای آن اضافه کنید:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash kaslr"


4️⃣ فایل را ذخیره کنید و سپس تنظیمات GRUB را به‌روزرسانی کنید:

sudo update-grub


5️⃣ سیستم را ری‌استارت کنید.

بررسی فعال بودن:kaslr
sudo dmesg | grep -i "Kernel random"

🔻پست و آموزش بیشتر در وبلاگ آکادمی:
https://learninghive.ir/linux-blogs/

⭐️ افزایش امنیت لینوکس با یک نکته و تنظیم ساده
🚫 حملاتی که با این روشی که میگم بی‌اثر می‌شوند:

🔸 Cold Boot Attack (حمله بوت سرد)
🔸Tampered Resume Attack (حمله از طریق فایل Hibernate آلوده)
🔸 Memory-forensic & Offline Extraction (بازیابی حافظه و کلیدها از دیسک)
🔸 Privilege Escalation از طریق بازگردانی حافظه آلوده

🔹 با فعال کردن پارامتر noresume به کرنل لینوکس می‌گوید که هیچ‌وقت از پارتیشن یا فایل hibernation برای بازگرداندن حافظه استفاده نکند. وقتی سیستم Hibernate می‌شود، محتوای RAM روی دیسک ذخیره می‌شود تا در بوت بعدی دوباره بارگذاری گردد.
اما اگر شخصی به این فایل‌ها دسترسی پیدا کند، می‌تواند داده‌های حساسی مثل کلیدهای رمزنگاری، پسوردها یا نشست‌های فعال را استخراج کند.
🔸 با فعال‌کردن noresume، کرنل کاملاً از این پارتیشن صرف‌نظر می‌کند و هیچ داده‌ای از RAM ذخیره‌شده روی دیسک بازگردانی نمی‌شود.
یعنی Hibernate (Suspend-to-Disk) غیرفعال میشه.
🔸 نتیجه: Hibernate از کار می‌افتد، اما سیستم در برابر حملات و دسترسی به حافظه رمزنگاری‌شده ایمن‌تر می‌شود.

1️⃣ فایل زیر را ویرایش کنید:
/etc/default/grub
2️⃣ پارامتر noresume را به خط زیر اضافه کنید:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
3️⃣ تنظیمات را اعمال کنید:
sudo update-grub
4️⃣ سیستم را ریبوت کنید ✅
🛡 از این پس، لینوکس شما دیگر از حالت Hibernate استفاده نخواهد کرد و داده‌های RAM ذخیره‌شده روی دیسک به‌طور کامل نادیده گرفته می‌شوند.

🔻پست و آموزش بیشتر در وبلاگ آکادمی:
https://learninghive.ir/linux-blogs/

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

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

فقط در ۷۶ دقیقه، خلاصه‌ی تمام دانسته‌های مهندسی هوش مصنوعی

اگه واقعا می‌خوای بفهمی AI Engineering یعنی چی، این ویدیو رو از دست نده.
نه یه آموزش سطحی‌ه، نه یه ویدیوی تبلیغاتی.
یه خلاصه‌ی فشرده از مفاهیمیه که هر کسی که با هوش مصنوعی کار می‌کنه باید بدونه، اونم فقط توی ۷۶ دقیقه.

در این ویدیو درباره‌ی چیزهایی صحبت می‌شه که نگاهت رو به AI برای همیشه تغییر می‌دن

چرا نباید از صفر مدل بسازی (و چطور باید از مدل‌های آماده استفاده کنی)
چطور (Self-supervised learning) همه‌چیز رو عوض کرده
چرا داده‌های آموزشی همیشه سوگیرانه‌ان و چطور باید باهاش کنار بیای
چرا طولانی‌تر بودن پرامپت همیشه به معنی نتیجه‌ی بهتر نیست
این‌که مدل بزرگ‌تر الزاماً مدل هوشمندتر نیست
چطور یه پرامپت خوب می‌تونه جای هفته‌ها فاین‌تیونینگ رو بگیره RAG چیه و چرا باید جزو ابزار اصلی هر تیم AI باشه

اگه توی مسیر ساخت محصول، رهبری تیم یا توسعه‌ی پروژه‌های هوش مصنوعی هستی،
این ویدیو احتمالاً یکی از مفیدترین ۷۶ دقیقه‌هایی خواهد بود که می‌گذرونی.

https://www.youtube.com/watch?v=JV3pL1_mn2M

@DevTwitter | <Mohsen Rad/>

استفاده از ai تو مصاحبه، آره یا نه؟ از زبون مصاحبه کننده.

https://leaddev.com/ai/why-expect-candidates-ai-hiring-process

نظر شخصی من اینه که در کل مهم نیست از چی استفاده می‌کنید، چه کپی پیست، چه لایبرری، چه GenAI، نهایتا مهمه که بتونید مسئولیتش رو بپذیرید و بدونید چه trade offهایی توش برقراره. به طور خلاصه وقتی پرسیدن چرا اینطوری، بتونید شفاف پاسخ بدید و نگید AI نوشته.

سایت های بزرگ ایران چی بودن و چی شدن؟

@Linuxor ~ hesamkianikhah

اگر #فرگمنت tlshello روی سرویس‌دهنده اینترنت شما مختل شده، می‌تونین از تنظیمات زیر استفاده کنید:

packets = 1-1
length = 3-5
interval = 4-8

برای کاهش پینگ، توصیه میشه از xhttp بهره ببرین، یا اگر از ws استفاده می‌کنین mux رو روشن کنید. همچنین می‌تونید interval رو تا جای ممکن کاهش بدین.

© GFW-knocker

🔍 ircf.space
@ircfspace

وقتی نیاز شخصی‌ات میشه محصول ۵۰۰ میلیون دلاری

سپتامبر ۲۰۲۴، یه برنامه‌نویس به اسم Boris Cherny تازه به Anthropic جوین شده بود. داشت با مدل Claude ور می‌رفت که خودش رو با APIهاشون بیشتر آشنا کنه. اولین ابزارش یه چیز خیلی ساده بود: یه برنامه ترمینال که بهش می‌گفتی الان چه آهنگی داری گوش میدی! خیلی basic، خیلی شخصی، ولی جالب بود. بعد یه روز یهو به ذهن Boris خطور کرد که چرا فقط AppleScript؟ چرا نذاریم فایل‌سیستم رو ببینه؟ چرا نذاریم bash commands بزنه؟

همین که این قابلیت‌ها رو اضافه کرد، دنیاش عوض شد. Claude شروع کرد به explore کردن کد، خوندن فایل‌ها، دنبال کردن importها، و پیدا کردن جواب‌ها. Boris خودش میگه: "این همون لحظه‌ای بود که فهمیدم یه چیز بزرگ داره میشه." ابزاری که برای خودش ساخته بود، یهو تبدیل شد به چیزی که همکاراش هم می‌خواستن ازش استفاده کنن. تا روز پنجم، ۵۰٪ تیم مهندسی Anthropic داشتن باهاش کار می‌کردن!

حالا Claude Code یه ماشین درآمدزایی ۵۰۰ میلیون دلاری شده. یه تیم کامل داره، features جدید هر روز اضافه میشه، و داستانش شبیه همون چیزیه که Ken Thompson درباره Unix گفته بود:
"Unix was built for me. I didn't build it as an operating system for other people, I built it to do games, and to do my stuff."
یعنی Unix هم اول یه ابزار شخصی بود، بعد شد اساس سیستم‌عامل‌های امروزی.

نکته داستان چیه؟ وقتی چیزی می‌سازی که واقعاً نیاز خودت رو رفع کنه، احتمالش خیلی زیاده که برای دیگرانی که نیاز مشابه دارن هم مفید باشه. Boris داشت یه مشکل شخصی حل می‌کرد، نه یه محصول تعریف‌شده. تیم Claude Code الانم با همین فلسفه کار می‌کنه: کمترین کد ممکن، ساده‌ترین معماری، و اجازه بده مدل کارشو بکنه. حتی ۹۰٪ کد Claude Code با خود Claude Code نوشته شده! پس دفعه بعد که احساس می‌کنی یه ابزاری لازمه، نشین منتظر شرکت‌ها یا استارتاپ‌ها. خودت بساز. شاید امروز فقط برای خودته، ولی فردا میشه یکی از بهترین ابزارهای دنیا.

https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built

@DevTwitter | <Hossein Nazari/>

🔥 New GitHub Trending Repositories 🔥

Found 8 new trending repositories:

1. material-ui by mui
📝 Material UI: Comprehensive React component library that implements Google's Material Design. Free fo...
💻 JavaScript | ⭐ 97,046 | 🌟 Today: 70
🔗 Link

2. adk-go by google
📝 An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agent...
💻 Go | ⭐ 518 | 🌟 Today: 185
🔗 Link

3. axios by axios
📝 Promise based HTTP client for the browser and node.js
💻 JavaScript | ⭐ 108,133 | 🌟 Today: 6
🔗 Link

4. HyDE by HyDE-Project
📝 HyDE, your Development Environment 🖥️💻
💻 Shell | ⭐ 6,860 | 🌟 Today: 19
🔗 Link

5. librespot by librespot-org
📝 Open Source Spotify client library
💻 Rust | ⭐ 5,900 | 🌟 Today: 23
🔗 Link

6. Kimi-K2 by MoonshotAI
📝 Kimi K2 is the large language model series developed by Moonshot AI team
💻 Star | ⭐ 8,836 | 🌟 Today: 143
🔗 Link

7. ImHex by WerWolv
📝 🔍 A Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at...
💻 C++ | ⭐ 51,222 | 🌟 Today: 146
🔗 Link

8. kotlin by JetBrains
📝 The Kotlin Programming Language.
💻 Kotlin | ⭐ 51,643 | 🌟 Today: 33
🔗 Link


🔘 @github_trending_daily

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

دوتا روش معروف داره:
توی Bully algorithm هر نود یه id داره و اون که id بزرگ‌تره، انتخاب میشه؛ وقتی مستر قبلی پرید، نودها با هم تماس می‌گیرن و در نهایت اون که آی‌دی بزرگ‌تری داره مستر میشه

ولی توی Raft ماجرا دموکراتیک‌تره. همه نودها اول فالورن، اگه مدتی خبری از مستر نباشه، اولین نفری که میفهمه مستر مرده🖤 خودش رو کاندید می‌کنه و از بقیه رای می‌گیره. هر کی اکثریت رای رو ببره میشه مستر جدید
فقط، نودها فقط به کسی رای میدن که از خودشون عقب‌تر نباشه. یعنی استیت و لاگش جلوتر یا برابر باشه، تا مطمئن شن لیدر جدید داده‌های به‌روزتری داره و عقب مونده نیست😅

اینجا یه لیست خیلی خوب از پادکست های برنامه نویسی و تکنولوژی جمع کردن، به زبان انگلیسی و آلمانی و روسی و... هستن، هم برای یادگیری زبان تخصصی خوبه هم خود اون تکنولوژی، فریم ورک یا زبان برنامه نویسی رو دنبال می‌کنید


github.com/rShetty/awesome-podcasts


@Linuxor

ذات ادوبی و ویندوز: