Forwarded from a pessimistic researcher (Kc)
دوستان جهت یادآوری
این ارائه امروز ساعت ۵ عصر به وقت ایران برگزار میشه، باعث افتخاره که در خدمت دوستان باشیم
این ارائه امروز ساعت ۵ عصر به وقت ایران برگزار میشه، باعث افتخاره که در خدمت دوستان باشیم
Forwarded from DevTwitter | توییت برنامه نویسی
This media is not supported in your browser
VIEW IN TELEGRAM
بالاخره وقتش رسید که datepicker خودم رو منتشر کنم
خوب دیگه وقتشه با Date Pickerهای قدیمیتون خداحافظی کنید و از Date Pickerهای جدید و مدرن و کم حجم استفاده کنید!
یه انتخابگر تاریخ سبک، سریع و مدرن که هم تقویم شمسی داره هم میلادی.
کاملا ریسپانسیو، با کلی تنظیمات که میتونید به راحتی شخصیسازی کنید.
کاملا واکنشگرا، با پشتیبانی کامل از RTL و ظاهر جذاب.
- پشتیبانی همزمان از تقویم شمسی و میلادی
- انتخاب تاریخ به سبک چرخوفلک (Wheel Picker) – روان و جذاب
- ساپورت کامل راست به چپ (RTL)
- مودال با دو حالت باز شدن: از وسط یا پایین صفحه
- قابل تنظیم برای سالهای مختلف (مثلاً از ۱۳۵۰ تا ۱۴۱۰)
- کاملاً قابل شخصیسازی با propsهای جدا برای input، modal و دکمه
- رسپانسیو و مناسب موبایل
- استایلپذیر با CSS Variables برای تمهای دلخواه
- سبک، کمحجم و بدون وابستگیهای اضافه
اگر دوست داشتید و به نظرتون خوب بود، لطفاً یه استار کوچیک هم به گیتهابش بدید تا انگیزه بگیرم و بهترش کنم!
https://github.com/sadegh1379/wheel-datepicker
https://www.npmjs.com/package/@buildix/wheel-datepicker
@DevTwitter | <Sadegh Akbari/>
خوب دیگه وقتشه با Date Pickerهای قدیمیتون خداحافظی کنید و از Date Pickerهای جدید و مدرن و کم حجم استفاده کنید!
یه انتخابگر تاریخ سبک، سریع و مدرن که هم تقویم شمسی داره هم میلادی.
کاملا ریسپانسیو، با کلی تنظیمات که میتونید به راحتی شخصیسازی کنید.
کاملا واکنشگرا، با پشتیبانی کامل از RTL و ظاهر جذاب.
- پشتیبانی همزمان از تقویم شمسی و میلادی
- انتخاب تاریخ به سبک چرخوفلک (Wheel Picker) – روان و جذاب
- ساپورت کامل راست به چپ (RTL)
- مودال با دو حالت باز شدن: از وسط یا پایین صفحه
- قابل تنظیم برای سالهای مختلف (مثلاً از ۱۳۵۰ تا ۱۴۱۰)
- کاملاً قابل شخصیسازی با propsهای جدا برای input، modal و دکمه
- رسپانسیو و مناسب موبایل
- استایلپذیر با CSS Variables برای تمهای دلخواه
- سبک، کمحجم و بدون وابستگیهای اضافه
اگر دوست داشتید و به نظرتون خوب بود، لطفاً یه استار کوچیک هم به گیتهابش بدید تا انگیزه بگیرم و بهترش کنم!
https://github.com/sadegh1379/wheel-datepicker
https://www.npmjs.com/package/@buildix/wheel-datepicker
@DevTwitter | <Sadegh Akbari/>
Forwarded from Linuxor ?
حواستون به خطا های مرورگر باشه!
اینترنت مودم یکی از آشنا ها هی خطای SSL میداد منم یه سایت باز کردم و از روی کنجکاوی دکمه باز کردن سایت به صورت ناامن کلیک کردم ببینم چی میشه؛ منو وارد یه سایت دیگه کرد و اون سایت منو انتقال داد به صفحه ای که میبینید.
مشکل از تنظیمات مودم بود، که باعث شده بود مرورگر نتونه سرتیفیکیت سایت اصلی رو اعتبارسنجی کنه و مهاجمین هم از این استفاده کرده بودن برای حمله MITM (یعنی یه نفر میاد وسط اتصال من و سایتی که میخوام) و در نتیجه مهاجم منو با سرور خودش ریدایرکت کرده بود به این آدرس که برای سایت خودش SEO بگیره اما میتونست هر کاری کنه.
حواستون باشه مرورگر ناامنی اتصال بین شما و سرور رو متوجه میشه همیشه روی اتصال ناامن کلیک نکنید چون مهاجم اگه بیاد وسط دستش بازه و هر کاری میتونه انجام بده.
@Linuxor
اینترنت مودم یکی از آشنا ها هی خطای SSL میداد منم یه سایت باز کردم و از روی کنجکاوی دکمه باز کردن سایت به صورت ناامن کلیک کردم ببینم چی میشه؛ منو وارد یه سایت دیگه کرد و اون سایت منو انتقال داد به صفحه ای که میبینید.
مشکل از تنظیمات مودم بود، که باعث شده بود مرورگر نتونه سرتیفیکیت سایت اصلی رو اعتبارسنجی کنه و مهاجمین هم از این استفاده کرده بودن برای حمله MITM (یعنی یه نفر میاد وسط اتصال من و سایتی که میخوام) و در نتیجه مهاجم منو با سرور خودش ریدایرکت کرده بود به این آدرس که برای سایت خودش SEO بگیره اما میتونست هر کاری کنه.
حواستون باشه مرورگر ناامنی اتصال بین شما و سرور رو متوجه میشه همیشه روی اتصال ناامن کلیک نکنید چون مهاجم اگه بیاد وسط دستش بازه و هر کاری میتونه انجام بده.
@Linuxor
Forwarded from Gopher Academy
استفاده از هوش مصنوعی در مصاحبههای شغلی متا آزاد شد!
▪️متا بهزودی به برنامهنویسهای تازهوارد اجازه میده حین تست کدنویسی از ابزارهای هوش مصنوعی استفاده کنن!
▪️چرا؟! چون اینطوری :
1. بهتر به واقعیت محیط کاری نزدیک میشن
2. جلوی تقلبهای پنهانی با AI گرفته میشه ، چون دیگه خود استفاده از AI بخشی از تست حساب میشه!
🧠 متا میگه آیندهی کدنویسی با هوش مصنوعیه، پس مصاحبهها هم باید با این واقعیت همسو بشن.
▪️متا بهزودی به برنامهنویسهای تازهوارد اجازه میده حین تست کدنویسی از ابزارهای هوش مصنوعی استفاده کنن!
▪️چرا؟! چون اینطوری :
1. بهتر به واقعیت محیط کاری نزدیک میشن
2. جلوی تقلبهای پنهانی با AI گرفته میشه ، چون دیگه خود استفاده از AI بخشی از تست حساب میشه!
🧠 متا میگه آیندهی کدنویسی با هوش مصنوعیه، پس مصاحبهها هم باید با این واقعیت همسو بشن.
Forwarded from DevTwitter | توییت برنامه نویسی
دیروز قابلیتهای جدید Livewire 4 معرفی شد!
ویدئوی کامل معرفی رو میتونید از این لینک ببینید:
https://www.youtube.com/live/GM0glP77tsA?t=18740s
@DevTwitter | <Ali Baghernia/>
ویدئوی کامل معرفی رو میتونید از این لینک ببینید:
https://www.youtube.com/live/GM0glP77tsA?t=18740s
@DevTwitter | <Ali Baghernia/>
Forwarded from محتوای آزاد سهراب
بنا به یک دلایلی توزیع رو از اول مجبور شدم نصب کنم و الان کلاً به ذن مهاجرت کردم.
واقعاً میتونم بگم مرورگر خیلی جالبیه، تا قبل اون هم چون از قبل فایرفاکس رو داشتم نمیرفتم سمتش ولی توی بیلدهای جدید #پارچ ذن به صورت پیشفرض نصبه.
تا الان که راضی بودم ازش.
یک سری ماد هم از توی مخزن خودش نصب کردم تا ببینم تجربم به صورت نهایی چطور میشه.
@SohrabContents
واقعاً میتونم بگم مرورگر خیلی جالبیه، تا قبل اون هم چون از قبل فایرفاکس رو داشتم نمیرفتم سمتش ولی توی بیلدهای جدید #پارچ ذن به صورت پیشفرض نصبه.
تا الان که راضی بودم ازش.
یک سری ماد هم از توی مخزن خودش نصب کردم تا ببینم تجربم به صورت نهایی چطور میشه.
@SohrabContents
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 به ساخت اپلیکیشن های هوشمند، جمع و جور و سفارشی با استفاده از PHP خام ادامه بده و در حالی که بقیه درگیر به روزرسانی بسته ها، قواعد سخت گیرانه فریم ورک ها، تولیدکننده های کد آماده و مجموعهای از «ابزارهای توسعه» هستند که هرکدام برای شروع به یادگیری یک آموزش جداگانه نیاز دارند.
@TheRaymondDev
@TheRaymondDev
Forwarded from Md Daily (Mahan)
داشتم یه پست از Nimrod Kramer میخوندم، میگفت:
کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)
چسبوندن کلمهی «مهندسی» به «نوشتن پرامپت»، مثل اینه که به مهندسی اجتماعی بگیم یک شاخه از مهندسی نرمافزار. مسخره است، ولی به طرز عجیبی برای معتبر نشون دادنِ کار، جواب میده.
بیاین روراست باشیم... نوشتن یه پرامپت خوب برای هوش مصنوعی میتونه هوشمندانه، نکتهسنجانه و حتی هنرمندانه باشه. اما این مهندسی نیست. نه طراحی سیستمی در کاره، نه ریاضیاتی، نه تکرارپذیری و نه منطقِ قابل آزمایش. فقط آزمون و خطاست و (گاهی وقتا) حس و حال.
این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرمافزار.
«مهندسی» خطاب کردنش، یکی از بزرگترین دروغهای تبلیغاتیه از وقتی که پای هوش مصنوعی به زندگی ما باز شد. این عنوان، یه کار ساده مثل تبلیغنویسی رو به یه شغل با حقوقهای نجومی تبدیل کرد. باعث شد آدما فکر کنن دارن سیستم میسازن، در حالی که فقط داشتن با مدلهای زبان بزرگ (LLMها) وَر میرفتن.
بله، پرامپت نوشتن میتونه کار مهمی باشه. اما اگه به این کار ادامه بدیم و بهش بگیم مهندسی، داریم هم به خودمون دروغ میگیم و هم به نسل بعدی توسعهدهندهها که سعی دارن بفهمن تسلط فنی واقعی یعنی چی.
بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی میده، لازم نیست لباس مهندسی تنش کنه.
---
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)
چسبوندن کلمهی «مهندسی» به «نوشتن پرامپت»، مثل اینه که به مهندسی اجتماعی بگیم یک شاخه از مهندسی نرمافزار. مسخره است، ولی به طرز عجیبی برای معتبر نشون دادنِ کار، جواب میده.
بیاین روراست باشیم... نوشتن یه پرامپت خوب برای هوش مصنوعی میتونه هوشمندانه، نکتهسنجانه و حتی هنرمندانه باشه. اما این مهندسی نیست. نه طراحی سیستمی در کاره، نه ریاضیاتی، نه تکرارپذیری و نه منطقِ قابل آزمایش. فقط آزمون و خطاست و (گاهی وقتا) حس و حال.
این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرمافزار.
«مهندسی» خطاب کردنش، یکی از بزرگترین دروغهای تبلیغاتیه از وقتی که پای هوش مصنوعی به زندگی ما باز شد. این عنوان، یه کار ساده مثل تبلیغنویسی رو به یه شغل با حقوقهای نجومی تبدیل کرد. باعث شد آدما فکر کنن دارن سیستم میسازن، در حالی که فقط داشتن با مدلهای زبان بزرگ (LLMها) وَر میرفتن.
بله، پرامپت نوشتن میتونه کار مهمی باشه. اما اگه به این کار ادامه بدیم و بهش بگیم مهندسی، داریم هم به خودمون دروغ میگیم و هم به نسل بعدی توسعهدهندهها که سعی دارن بفهمن تسلط فنی واقعی یعنی چی.
بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی میده، لازم نیست لباس مهندسی تنش کنه.
---
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Hamed
🚀 ترجمهی فارسی کتاب C# 12 in a Nutshell رو شروع کردم و روی GitHub منتشرش کردم:
🔗https://github.com/hheydarian/csharp-12-in-a-nutshell-persian
این کتاب یکی از کامل ترین منابع برای یادگیری و تسلط بر زبان #CSharp هست.
اگه علاقه مندید یه مرجع فارسی خوب و دقیق برای #CSharp بسازیم، خوشحال میشم همراه بشید.
میتونید فورک بگیرید، مشارکت کنید و به بهتر شدنش کمک کنید 💡
#CSharp #GitHub
#OpenSource #Net
🔗https://github.com/hheydarian/csharp-12-in-a-nutshell-persian
این کتاب یکی از کامل ترین منابع برای یادگیری و تسلط بر زبان #CSharp هست.
اگه علاقه مندید یه مرجع فارسی خوب و دقیق برای #CSharp بسازیم، خوشحال میشم همراه بشید.
میتونید فورک بگیرید، مشارکت کنید و به بهتر شدنش کمک کنید 💡
#CSharp #GitHub
#OpenSource #Net
Forwarded from DevTwitter | توییت برنامه نویسی
پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفهای
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
@DevTwitter | <Mojtaba Banaie/>
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
@DevTwitter | <Mojtaba Banaie/>
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 می دونی بدترین صدا در زندگی چیه؟
۱- صدای موتور سیکلت
۲- صدای اسباب بازی بچه شیبه موتور سیکلت 😂
@TheRaymondDev
۱- صدای موتور سیکلت
۲- صدای اسباب بازی بچه شیبه موتور سیکلت 😂
@TheRaymondDev
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 به نظر میرسد شرکت راکستار در حال کار بر روی افزودن سیستم تأیید سن است و دسترسی به بازی آنلاین GTA 6 برای افراد زیر ۱۸ سال دشوارتر خواهد شد.
#خبر
@TheRaymondDev
#خبر
@TheRaymondDev
👎1
Forwarded from Gopher Academy
پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفهای
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
| <Mojtaba Banaie/>
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
| <Mojtaba Banaie/>
Forwarded from Ninja Learn | نینجا لرن (Mohammad)
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from DevTwitter | توییت برنامه نویسی
یک بلاگ فوق العاده راجع به اینکه دیپلوی کردن AI Agent ها توی محیط پروداکشن خیلی فرق داره با درست کردن یک دمو!
ساخت یه حلقهی ساده برای ایجنتهای مبتنی بر مدلهای زبانی (LLM agents) خیلی آسونه. شاید با کمتر از ۲۰ خط کد! ولی این سادگی در واقع مشکلات پشت پردهٔ اجرای واقعی در محیط تولید (production) رو میپوشونه.
من خلاصه مقاله را میذارم ولی باید کامل خود مقاله بخونید.
- فاصلهی پنهان بین دمو و اجرا در عمل
۱. دمو مساوی نیست با محصول واقعی: شاید توی دمو همهچی خوب پیش بره، ولی توی محیط واقعی اتفاقاتی مثل:
-از کنترل خارج شدن ایجنتها
- نشت اطلاعات توی context
- گیر کردن توی حلقههای بیپایان
- یا خراب شدن زنجیره ابزارها خیلی رایجه.
- همچنین، تصمیمگیریهای معماری مثل مدیریت context، احراز هویت ابزارها یا ذخیرهسازی state، اگر از اول درست انتخاب نشن، بعداً تغییر دادنشون کلی دردسر داره.
۲. دنیای کنفرانسها با واقعیت فرق داره: شرکتهای بزرگ ممکنه از زیرساختهای خاص خودشون برای اجرای چندایجنت بهصورت موازی استفاده میکنن. ولی اکثر تیمها کار رو سادهتر میگیرن:
- با Docker و GitHub Actions
- یا اجرای ایجنتها روی AWS Lambda فقط برای صرفهجویی ماهانه ۱۰ دلار!
۳. کی اوضاع بهم میریزه؟
وقتی لازم باشه ایجنتهاتون حافظه داشته باشن، بتونن بعد از قطع شدن ادامه بدن، یا با context طولانی کار کنن، همه چی پیچیدهتر میشه. بعضی تیمها تجربهشون رو اینطوری به اشتراک گذاشتن:
- ذخیرهی state توی دیتابیس (مثلاً PostgreSQL) برای بررسی و بازیابی
- استفاده از پردازش غیرهمزمان مثل job queue و webhook
- حذف فریمورکهای سنگین مثل LangChain و استفاده از FastAPI و کلاینت ساده OpenAI
- چیها واقعاً مهمن؟
- زیرساخت موجود: همون جایی deploy کنید که تیمتون بلده (K8s، AWS Lambda، Docker و …)
- سرعت توسعه: گاهی اینکه زود به نتیجه برسید مهمتر از طراحیهای پیچیدهست
- هزینهها: حتی صرفهجوییهای کوچیک هم مهمه، مخصوصاً برای استارتاپها
- نیازهای سازمانی برای ایجنتها
- تناقض پلتفرم: شما دنبال قدرت یه پلتفرم کامل هستید (احراز هویت، حافظه، ارزیابی)، ولی در عین حال نمیخواید به یه vendor خاص وابسته بشید. استانداردهایی مثل MCP دارن کمک میکنن تا ابزارها باهم سازگار بشن.
- قابلیت اطمینان و مشاهدهپذیری: ایجنتهاتون باید بعد از crash شدن بتونن ادامه بدن. باید ردگیری کامل، حافظه پایدار، و توانایی بررسی لاگ داشته باشید. Redis برای سرعت، PostgreSQL برای ماندگاری.
- مقیاسپذیری و انعطاف: وقتی کار جدی میشه، باید ایجنتها بتونن از صفر تا هزاران اجرا در لحظه مقیاس پیدا کنن. اگه ایجنتهاتون کدنویسی انجام میدن، احتمالاً نیاز به sandbox برای امنیت و ایزوله کردن دارن.
- یکپارچهسازی و استانداردها: MCP داره نشون میده که همه دنبال یه راهحل استاندارد برای اجرای ایجنتها روی پلتفرمهای مختلف هستن.
- نتیجه اخلاقی:
- ساده شروع کنید، نیازهای واقعیتون رو تخمین بزنید
- اول با deploy ساده مثل Docker یا Lambda برید جلو
- زود تست کنید، چون مشکلات واقعی فقط توی دنیای واقعی مشخص میشن
- کمکم پیچیدگی اضافه کنید. هر چیزی رو وقتی لازمه پیادهسازی کنید.
حتما کامل بخونید اگه ایجنت تو پرداکشن دیپلوی میکنید!
https://zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it
@DevTwitter | <Mehdi Allahyari/>
ساخت یه حلقهی ساده برای ایجنتهای مبتنی بر مدلهای زبانی (LLM agents) خیلی آسونه. شاید با کمتر از ۲۰ خط کد! ولی این سادگی در واقع مشکلات پشت پردهٔ اجرای واقعی در محیط تولید (production) رو میپوشونه.
من خلاصه مقاله را میذارم ولی باید کامل خود مقاله بخونید.
- فاصلهی پنهان بین دمو و اجرا در عمل
۱. دمو مساوی نیست با محصول واقعی: شاید توی دمو همهچی خوب پیش بره، ولی توی محیط واقعی اتفاقاتی مثل:
-از کنترل خارج شدن ایجنتها
- نشت اطلاعات توی context
- گیر کردن توی حلقههای بیپایان
- یا خراب شدن زنجیره ابزارها خیلی رایجه.
- همچنین، تصمیمگیریهای معماری مثل مدیریت context، احراز هویت ابزارها یا ذخیرهسازی state، اگر از اول درست انتخاب نشن، بعداً تغییر دادنشون کلی دردسر داره.
۲. دنیای کنفرانسها با واقعیت فرق داره: شرکتهای بزرگ ممکنه از زیرساختهای خاص خودشون برای اجرای چندایجنت بهصورت موازی استفاده میکنن. ولی اکثر تیمها کار رو سادهتر میگیرن:
- با Docker و GitHub Actions
- یا اجرای ایجنتها روی AWS Lambda فقط برای صرفهجویی ماهانه ۱۰ دلار!
۳. کی اوضاع بهم میریزه؟
وقتی لازم باشه ایجنتهاتون حافظه داشته باشن، بتونن بعد از قطع شدن ادامه بدن، یا با context طولانی کار کنن، همه چی پیچیدهتر میشه. بعضی تیمها تجربهشون رو اینطوری به اشتراک گذاشتن:
- ذخیرهی state توی دیتابیس (مثلاً PostgreSQL) برای بررسی و بازیابی
- استفاده از پردازش غیرهمزمان مثل job queue و webhook
- حذف فریمورکهای سنگین مثل LangChain و استفاده از FastAPI و کلاینت ساده OpenAI
- چیها واقعاً مهمن؟
- زیرساخت موجود: همون جایی deploy کنید که تیمتون بلده (K8s، AWS Lambda، Docker و …)
- سرعت توسعه: گاهی اینکه زود به نتیجه برسید مهمتر از طراحیهای پیچیدهست
- هزینهها: حتی صرفهجوییهای کوچیک هم مهمه، مخصوصاً برای استارتاپها
- نیازهای سازمانی برای ایجنتها
- تناقض پلتفرم: شما دنبال قدرت یه پلتفرم کامل هستید (احراز هویت، حافظه، ارزیابی)، ولی در عین حال نمیخواید به یه vendor خاص وابسته بشید. استانداردهایی مثل MCP دارن کمک میکنن تا ابزارها باهم سازگار بشن.
- قابلیت اطمینان و مشاهدهپذیری: ایجنتهاتون باید بعد از crash شدن بتونن ادامه بدن. باید ردگیری کامل، حافظه پایدار، و توانایی بررسی لاگ داشته باشید. Redis برای سرعت، PostgreSQL برای ماندگاری.
- مقیاسپذیری و انعطاف: وقتی کار جدی میشه، باید ایجنتها بتونن از صفر تا هزاران اجرا در لحظه مقیاس پیدا کنن. اگه ایجنتهاتون کدنویسی انجام میدن، احتمالاً نیاز به sandbox برای امنیت و ایزوله کردن دارن.
- یکپارچهسازی و استانداردها: MCP داره نشون میده که همه دنبال یه راهحل استاندارد برای اجرای ایجنتها روی پلتفرمهای مختلف هستن.
- نتیجه اخلاقی:
- ساده شروع کنید، نیازهای واقعیتون رو تخمین بزنید
- اول با deploy ساده مثل Docker یا Lambda برید جلو
- زود تست کنید، چون مشکلات واقعی فقط توی دنیای واقعی مشخص میشن
- کمکم پیچیدگی اضافه کنید. هر چیزی رو وقتی لازمه پیادهسازی کنید.
حتما کامل بخونید اگه ایجنت تو پرداکشن دیپلوی میکنید!
https://zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it
@DevTwitter | <Mehdi Allahyari/>
Forwarded from Unlocking Software Verification
Monotonic Partial Order Reduction: An Optimal Symbolic Partial Order Reduction Technique
#paper #Aarti #CAV #2009
https://link.springer.com/content/pdf/10.1007/978-3-642-02658-4_31.pdf
#paper #Aarti #CAV #2009
https://link.springer.com/content/pdf/10.1007/978-3-642-02658-4_31.pdf
Forwarded from a pessimistic researcher (Kc)
امیرحسین نامی توی ارائه پرسید که آیا میشه non-determinism موجود در scheduling رو به SAT reduce کرد و حل کرد، من فراموش کردم که به این کار اشاره کنم. optimal نیست (برخلاف ادعای مقاله) و completeness نداره. ولی خودمم دارم میخونمش و ایدههایی دارم که بیارمش روی ConDpor.