این بلاگ از کمپانی ZenML اومده و ۲۸۷ مورد case study جدید از کمپانی های مختلف گذاشته که چطور از AI و بخصوص Gen AI استفاده میکنند. همه را خلاصه کرده و لینک به مقاله/بلاگ اصلی اون کمپانی را هم گذاشته. اینها کلی مثال واقعی از دیپلوی کردن سیستم های AI هست در محیط پروداکشن. که میتونید تو کمپانی های خودتون یا مسائل خودتون الگو بگیرید. خودش یکجور آمادگی برای مصاحبه های شغلی هم هست.
Link: https://zenml.io/blog/llmops-in-production-287-more-case-studies-of-what-actually-works…

@DevTwitter | <Mehdi Allahyari/>

گزارش کوتاه از وضعیت بازار کار مهندسی نرم‌افزار در سال 2025 که با Relocation همراه بوده است :
بیش از ۱۵۰۰ آگهی شغلی بررسی شده‌اند که از دارای (Relocation) بوده اند
- آلمان در صدر کشورهای منتشرکننده آگهی برای مهندسان نرم‌افزار بوده است.
- صنعت فین‌تک (Fintech) پرتقاضاترین حوزه بوده ، حتی جلوتر از حوزه های پر سر و صدای مرتبط با هوش مصنوعی.
- شرکت‌های متوسط و Scale-upها بیش از غول‌های فناوری (مثل MAANG) در حال جذب نیرو بوده و هستند

توزیع سمت ها و موقعیتهای کاری :
- برنامه نویسان بک‌اند ( که سلام و درود خدا بر آنها باد ): ۵۱۷ موقعیت (بیشترین تعداد)
- نقش‌های مرتبط با Data و هوش مصنوعی: ۳۵۲ موقعیت شامل: Data Engineer، Data Scientist، Machine Learning Engineer
- موارد مرتبط با DevOps و زیرساخت: رتبه سوم از نظر تقاضا

نتیجه: به شعور خواننده بستگی دارد !. ( البته به ما چه ؟! )

@DevTwitter | <Ali Kolahdoozan/>

یه کد نوشتم که ۲ هفته روی سرور روشن بوده و دیتای ۸۰۰ هزار تا رکورد اوردر بوک قیمت‌های ask و bid از ۶ صرافی wallex, nobitex, ompfinex, raastin, ramzinex, exir با تاخیر ۵ ثانیه رو دانلود کردم.
دیتابیس ۳ گیگه، زیپ شده ۸۱ مگ.
اینجاست:
https://github.com/NabiKAZ/arbitrage

@DevTwitter | <Nabi/>

دو تا ویجت برای داشبورد وردپرس دست و پا کردم که چارت سفارش ها و چارت فروش رو نشون میده

https://github.com/HamxaBoustani/wandtech-woochart

@DevTwitter | <Hamxa/>

اتفاقی لایو Brian Lovin؛ طراح محصول Notion که قبلاً هم GitHub بوده دیدم
یکی از نکات جالبش:
برای اولین طراح، دنبال کسی نباشید که فقط «طرح قشنگ» بزنه؛ یک طراح کارآفرین بیارید که بتونه استراتژی محصول رو شکل بده، بازخورد رو تحلیل کنه و مسئله واقعی رو حل کنه
https://www.youtube.com/watch?v=VZgrsDkZjHU

@DevTwitter | <S O D Ξ H/>

بالاخره وقتش رسید که 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/>

دیروز قابلیت‌های جدید Livewire 4 معرفی شد!

ویدئوی کامل معرفی رو می‌تونید از این لینک ببینید:
https://www.youtube.com/live/GM0glP77tsA?t=18740s

@DevTwitter | <Ali Baghernia/>

پردازش ۱.۲ میلیون پیام در ثانیه با 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/>

یک بلاگ فوق العاده راجع به اینکه دیپلوی کردن 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 ای هستیم تا بتونه جواب های معتبری بده و جواب هاش رو از خودش درنیاورده باشه. برای حل این مسائل چه سرویس هایی مناسبه. یکی از راهکار ها استفاده از سرویس deep search در LLM های موجوده. یکی دیگه از راهکار ها استفاده ازسرویس های سرچ و اتصال آنها به LLM هست

Tavily
امکانات خوبی داره میتونید deep search به صورت advanced بگذارید تاجواب های بهتری بدهد حتی میتوان دامنه و تاریخ رو نیز مشخص کرد. کرالش برای سایت هایی که داینامیک بودن، نتونست دیتا مورد نظرم رو بخونه.
https://app.tavily.com/playground

Linkup
تقریبا شبیه tavily هست ولی منابع ای که در تست های من می آورد با tavily متفاوت بود. منابع معتبر و خوبی بود.
https://linkup.so

سرویس گوگل بود که در منابعی که جدول و عکس داشت نسبت به tavily به درستی خوب عمل نکرد.
https://ai.google.dev/gemini-api/docs/google-search

این مقایسه مدل ها در زمینهhallucination یا توهم مدل ها همون طور که میبینید مدل های گوگل عملکرد بهتری نسبت به openai داشتن:
https://github.com/vectara/hallucination-leaderboard?tab=readme-ov-file…


@DevTwitter | <Mari/>

#کوته_نیوز

امریه دانش‌بنیان لغو شد.
اون کورسوی امید هم از بین رفت متاسفانه...

ویرایش: تکذیب شد.

@DevTwitter

فونت پرستو، توسط گوگل فونت اصلاح شده، فونت متغیر شده و حالا توی سایت گوگل فونت قرار گرفته:
https://fonts.google.com/specimen/Parastoo

https://github.com/googlefonts/parastoo-font

فونت پرستو، یکی از فونت هایی بود که توسط صابر آرشیو شده بود و از لحاظ ساختار، خیلی به فونت ساحل نزدیکه.

@DevTwitter | <محمد درویشی/>

#کوته_نیوز

معاونت علمی، فناوری و دانش‌بنیان ریاست‌جمهوری:
کدشر تفت ندید، تکذیبه.

@DevTwitter

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

https://github.com/evsar3/sshfs-win-manager

ولی خوب چیزیه امتحانش کنید

@DevTwitter | <E Gholami/>

ما وقتی برنامه Go مون رو می‌بندیم، فقط یه Ctrl+C می‌زنیم و می‌گیم:
“خب، shutdown شد!”
و تمام!
ولی واقعیت اینه که خاموش شدن یه سرویس واقعی، اونم توی Production،
خیلی بیشتر از یه سیگنال ساده‌ست.


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


تو این مقاله، به‌صورت خلاصه نوشتم:
- چطور با signal.NotifyContext درست shutdown رو هندل کنیم
- چطور http.Server رو با Shutdown(ctx) ببندیم
- چطور workerها رو با context و sync.WaitGroup تمیز ببندیم
- و تو Kubernetes چطور از terminationGracePeriodSeconds درست استفاده کنیم

https://medium.com/@a.mousavi/graceful-shutdown-in-go-part-1-build-production-ready-services-without-dropping-requests-b55934c217c1

@DevTwitter | <Arash Mousavi/>

جمع ۲۰۰۰ تا ورکفلو از n8n
همه مدلی میشه توش پیدا کرد
امیدوارم بکارتون بیاد
https://github.com/Zie619/n8n-workflows

@DevTwitter | <Shayan razi/>

وقتی شرکتا نیروی بالای 35 سال نمیگیرن :)))

@DevTwitter | <Farshad Tofighi/>

اخیرا یکی از دوستان یک framework کامل برای توسعه‌ی ربات‌های تلگرامی با زبان PHP توسعه داده که با الهام از ساختار لاراول ساخته شده و قابلیت‌های خیلی خوبی داره -- همچنین به‌صورت پیش‌فرض این امکان رو داره که بر بستر Swoole/OpenSwoole اجرا شه تا از لحاظ پرفورمنسی به‌شدت بهبود پیدا کنه، مشابه Laravel Octane.

اگر PHP کار می‌کنید، امتحان‌ش کنید:
https://github.com/laraXgram/LaraGram

@DevTwitter | <Mahi/>

#میم_شبانگاهی

وقتی ذهنت درگیره

@DevTwitter | <Hossein Jorfi/>

همیشه به چیزای فان گیکی علاقه داشتم و الان هم سعی کردم 24 ایده‌ی فان توی حوزه کامپیوتر رو طراحی کنم. طبیعتا یک برنامه نویس واقعی خودشو با لباسش و استیکرای روی لپتاپش به بقیه معرفی میکنه. برای همین یه ریپو کامل که بیشترش ایده‌ی خودم بوده رو براتون گذاشتم به همراه فایل psd (به رسم اوپن‌سورسی بودن) و کاملا آماده‌ی چاپ. در آینده هر ایده‌ای به ذهنم برسه آپدیتش میکنم. بیاید این ریپو رو با هم دیگه بزرگ و بزرگترش کنیم دنیارو بگیریم :)

لینک ریپازیتوری :
https://github.com/thekourox/Geek-Clothes

@DevTwitter | <Koroush/>

یه اپی با پایتون زدم که میتونه از یک single source (برای مثال یک عکس) برای چندین پلتفرمی که داریم توسعه میدیم ( برای مثال یک اپلیکیشن اندرویدی یا حتی برای IOS و..) که قراره ایکون لانچر اپ از اون Folder Structure ، بخونه ، به راحتی این فولدر و عکس های مختلف در سایز های مختلف درست کنه و اون رو توی پروژه تون اضافه کنید

https://github.com/aminrms/app_icon_generator/

@DevTwitter | <Amin Ramezani/>