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

آموزش عملی داکر هر چیزی که برای یادگیری مفاهیم داکر و کاربردهاش نیاز داری رو توی دوره آموزش عملی داکر کوئراکالج برات آماده کردیم. فقط ۲۴ ساعت وقت داری که با تخفیف ۳۰ درصدی اونم به صورت قسطی ثبت‌نام کنی. 🔗 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/>

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

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

دو تا ویجت برای داشبورد وردپرس دست و پا کردم که چارت سفارش ها و چارت فروش رو نشون میده https://github.com/HamxaBoustani/wandtech-woochart @DevTwitter | <Hamxa/>

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

گزارش کوتاه از وضعیت بازار کار مهندسی نرم‌افزار در سال 2025 که با Relocation همراه بوده است : بیش از ۱۵۰۰ آگهی شغلی بررسی شده‌اند که از دارای (Relocation) بوده اند - آلمان در صدر کشورهای منتشرکننده آگهی برای مهندسان نرم‌افزار بوده است. - صنعت فین‌تک (Fintech) پرتقاضاترین حوزه بوده ، حتی جلوتر از حوزه های پر سر و صدای مرتبط با هوش مصنوعی. - شرکت‌های متوسط و Scale-upها بیش از غول‌های فناوری (مثل MAANG) در حال جذب نیرو بوده و هستند توزیع سمت ها و موقعیتهای کاری : - برنامه نویسان بک‌اند ( که سلام و درود خدا بر آنها باد ): ۵۱۷ موقعیت (بیشترین تعداد) - نقش‌های مرتبط با Data و هوش مصنوعی: ۳۵۲ موقعیت شامل: Data Engineer، Data Scientist، Machine Learning Engineer - موارد مرتبط با DevOps و زیرساخت: رتبه سوم از نظر تقاضا نتیجه: به شعور خواننده بستگی دارد !. ( البته به ما چه ؟! ) @DevTwitter | <Ali Kolahdoozan/>

این بلاگ از کمپانی 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/>

خب بریم سراغ نتایج StackOverFlow Developer Survey سال ۲۰۲۵ فقط یک چهارم developerها از شغل فعلی شون رضایت دارن استفاده کنندگان از AI agentها اکثرا معتقدند که productivityشون زیاد شده بیشتر developerها به نتایج AI tools اعتماد ندارن که بنظرم منطقی هم هست استفاده از python هفت درصد نسبت به پارسال رشد داشته که از بقیه زبان ها بیشتر بوده همچنان Visual Studio Code و Visual Studio پرکاربردترین development environmentها هستند از most admiredها بگیم. این نشون میده که برنامه نویسا هر چیزی رو چقدر ستایش میکنن و دوست دارن (لزوما به معنی استفاده و کاربرد نیست) زبان Rust و بعدش Gleam و Elixir و Zig تحسین برانگیزترین(محبوب ترین) زبان ها هستند. تحسین برانگیزترین مدل AI هم claude sonnet شده هر چند که most desired یا اونی که بیشتر استفاده میشه یا قصد استفاده دارن ChatGPT بوده Claude Sonnet is the most admired AI model گزارش کامل ش رو میتونید تو این لینک ببینید https://survey.stackoverflow.co/2025 @DevTwitter | <Hossein Nazari/>

وردپرس ۶.۹ قراره تغییرات و امکانات جالبی داشته باشه: - بدون پوسته پیش‌فرض (اولین‌بار از ۲۰۱۰) - فرستادن دیدگاه روی بلوک‌ها - حالت ویرایش ساده‌تر توی ویرایشگر - شروع بازطراحی مدیریت - بهبود Interactivity API و HTML API - تمرکز روی سرعت، تجربه کاربری و تجربه مدیریت محتوا @DevTwitter | <Morteza Geransayeh/>