DevTwitter | توییت برنامه نویسی

وسط نبودنش داره اذیتم می‌کنه @DevTwitter

توی این سایت و ریپو الگوریتم های مرتب سازی رو سعی شده با مصورسازی نحوه کار و عملکردشون مقایسه بشه. https://ds-fall2025.github.io/sorting_algo/ https://github.com/hrnrxb/sorting_algo از کلاس ساختمان داده دانشگاه آزاد شیراز هست که اگر خواستید میتونید از سایت زیر به محتوای درسی نابشون دسترسی پیدا کنید https://ds-fall2025.github.io/ds-fall2025/ @DevTwitter | <hrnrxb/>

بررسی نظرسنجی Stack Overflow 2025 نتایج نظرسنجی امسال سایت Stack Overflow منتشر شده. بیاید ببینیم صنعت و تکنولوژی های مختلف تو چه وضعیتی قرار دارن. تو این ویدیو یه بررسی خیلی سریع رو این نتایج انجام میدیم. در نهایت نتایج بهتون میگه که Rust رو بیشتر جدی بگیرید و دوستش داشته باشید، اگه از شغلتون خوشحال نیستید خیلی طبیعیه و تقریبا مثه بقیه هستید، آدما به هوش مصنوعی اعتماد ندارن و هنوز هم اونو یه تهدید جدی برای شغلشون نمیدونن :) لینک یوتیوب https://www.youtube.com/watch?v=8D8xQV9pgFw @DevTwitter | <Rouzbeh/>

یه مینی پروژه بازی‌سازی با Vanilla JS که برای یادگیری بیشتر خودم شروع به توسعه‌ش کردم. توش سعی کردم قواعد clean code رو رعایت کنم و خود کدها هم پیچیدگی خاصی ندارن و قابل درکن. اگه هنوز اول راه JS هستید، پیشنهاد می‌کنم یه نگاهی بهش بندازید، شاید بهتون ایده بده یا کمکتون کنه. https://github.com/whosfatima/Snake_Mini_Game @DevTwitter | <whosfatima/>

یه اپی با پایتون زدم که میتونه از یک single source (برای مثال یک عکس) برای چندین پلتفرمی که داریم توسعه میدیم ( برای مثال یک اپلیکیشن اندرویدی یا حتی برای IOS و..) که قراره ایکون لانچر اپ از اون Folder Structure ، بخونه ، به راحتی این فولدر و عکس های مختلف در سایز های مختلف درست کنه و اون رو توی پروژه تون اضافه کنید https://github.com/aminrms/app_icon_generator/ @DevTwitter | <Amin Ramezani/>

همیشه به چیزای فان گیکی علاقه داشتم و الان هم سعی کردم 24 ایده‌ی فان توی حوزه کامپیوتر رو طراحی کنم. طبیعتا یک برنامه نویس واقعی خودشو با لباسش و استیکرای روی لپتاپش به بقیه معرفی میکنه. برای همین یه ریپو کامل که بیشترش ایده‌ی خودم بوده رو براتون گذاشتم به همراه فایل psd (به رسم اوپن‌سورسی بودن) و کاملا آماده‌ی چاپ. در آینده هر ایده‌ای به ذهنم برسه آپدیتش میکنم. بیاید این ریپو رو با هم دیگه بزرگ و بزرگترش کنیم دنیارو بگیریم :) لینک ریپازیتوری : https://github.com/thekourox/Geek-Clothes @DevTwitter | <Koroush/>

#میم_شبانگاهی وقتی ذهنت درگیره @DevTwitter | <Hossein Jorfi/>

اخیرا یکی از دوستان یک framework کامل برای توسعه‌ی ربات‌های تلگرامی با زبان PHP توسعه داده که با الهام از ساختار لاراول ساخته شده و قابلیت‌های خیلی خوبی داره -- همچنین به‌صورت پیش‌فرض این امکان رو داره که بر بستر Swoole/OpenSwoole اجرا شه تا از لحاظ پرفورمنسی به‌شدت بهبود پیدا کنه، مشابه Laravel Octane. اگر PHP کار می‌کنید، امتحان‌ش کنید: https://github.com/laraXgram/LaraGram @DevTwitter | <Mahi/>

آموزش عملی داکر هر چیزی که برای یادگیری مفاهیم داکر و کاربردهاش نیاز داری رو توی دوره آموزش عملی داکر کوئراکالج برات آماده کردیم. فقط ۲۴ ساعت وقت داری که با تخفیف ۳۰ درصدی اونم به صورت قسطی ثبت‌نام کنی. 🔗 https://quera.org/r/cfx50

وقتی شرکتا نیروی بالای 35 سال نمیگیرن :))) @DevTwitter | <Farshad Tofighi/>

جمع ۲۰۰۰ تا ورکفلو از hashtag#n8n همه مدلی میشه توش پیدا کرد امیدوارم بکارتون بیاد https://github.com/Zie619/n8n-workflows @DevTwitter | <Shayan razi/>

ما وقتی برنامه 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/>

یه ابزار خوب برای اینکه به دولوپر معرفی کنی تا با ssh به سرور وصل بشه و یک فولدر رو مثل یک شیر درایو توی ویندوزش ببینه. بعدشم ادیتورش رو روش باز میکنه و بعدش گند میزنه به سرور و ... https://github.com/evsar3/sshfs-win-manager ولی خوب چیزیه امتحانش کنید @DevTwitter | <E Gholami/>

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

فونت پرستو، توسط گوگل فونت اصلاح شده، فونت متغیر شده و حالا توی سایت گوگل فونت قرار گرفته: https://fonts.google.com/specimen/Parastoo https://github.com/googlefonts/parastoo-font فونت پرستو، یکی از فونت هایی بود که توسط صابر آرشیو شده بود و از لحاظ ساختار، خیلی به فونت ساحل نزدیکه. @DevTwitter | <محمد درویشی/>

#کوته_خبر امریه دانش‌بنیان لغو شد. اون کورسوی امید هم از بین رفت متاسفانه... @DevTwitter

خیلی از ماها دنبال 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/>

یک بلاگ فوق العاده راجع به اینکه دیپلوی کردن 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/>

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

دیروز قابلیت‌های جدید Livewire 4 معرفی شد! ویدئوی کامل معرفی رو می‌تونید از این لینک ببینید: https://www.youtube.com/live/GM0glP77tsA?t=18740s @DevTwitter | <Ali Baghernia/>