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

دوره جدید استنفورد با موضوع ایجنت‌های خود بهبود دهنده (Self-Improving AI Agents) دست روی یکی از بنیادی‌ترین تغییرات پارادایم هوش مصنوعی گذاشته. تا الان تمرکز اصلی صنعت روی بزرگ‌تر کردن مدل‌ها در مرحله پیش‌آموزش (Pre-training) بود. اما مدرسین دوره که از اساتید استنفورد و محققان سابق DeepMind و Anthropic هستن، نشون میدن که این مسیر به تنهایی دیگه جوابگو نیست و آینده دست ایجنت‌هایی هست که می‌تونن خودشون رو اصلاح کنن. سه محور اصلی که این تحول روی اون‌ها شکل می‌گیره: ۱. پردازش در زمان استنتاج (Test-time Compute): به جای پاسخ لحظه‌ای، ایجنت فرصت تفکر، جستجو در فضای حل مسئله و بررسی راه‌حل‌های مختلف رو پیدا می‌کنه. ۲. بازخورد قابل راستی‌آزمایی (Verifiable Feedback): استفاده از محیط‌های واقعی مثل کامپایلرها، اجرای کد و تست‌های نرم‌افزاری تا ایجنت خروجی خودش رو ارزیابی کنه نه اینکه فقط متن تولید کنه. ۳. حلقه‌های خوداصلاحی (Self-Correction & Reflection): طراحی pipelineهایی که ایجنت بتونه دلیل شکست در یک کار رو تحلیل کنه و در تلاش بعدی بدون نیاز به انسان، خطاش رو برطرف کنه. در واقع شیفت اصلی از «مدل‌های ایستا» به سمت «سیستم‌های پویای یادگیرنده» است. Youtube: https://youtube.com/watch?v=6YnLB0XbTnI @DevTwitter | <Mehdi Allahyari/>

#کوته_نیوز «بله» رفته تو اپ‌استور و ادعا کرده که end-to-end داره. @DevTwitter

اگه پرووایدر antigravity روی 9router و هارنس hermes بهتون ارور 429: resource exhaustion میده چارش اینجاس: https://github.com/decolua/9router/issues/2964#issuecomment-5161082471 توضیح کوتاه اینکه روی هرمس یه فایل هست به اسم SOUL.md که همون توضیحات اولیه مدل هست که رو هر پرامپت ارسال میشه، داخلش برین و این لاین رو: You are Hermes Agent, an intelligent AI assistant created by Nous Research. تغییر بدین به این لاین: You are Hermes Agent, an intelligent AI assistant. و مشکل حل میشه. @DevTwitter | <Soheil/>

شرکت Liquid AI مدل LFM2.5-2.6B رو معرفی کرده که دقیقاً برای اجرای ایجنت‌های هوش مصنوعی روی خود دستگاه (On-Device) طراحی شده. اجرای محلی ایجنت‌ها یعنی حذف هزینه توکن، کاهش تاخیر به حداقل و حفظ کامل حریم خصوصی. این مدل ۲.۶ میلیارد پارامتری با اینکه خیلی کوچیکه، توانایی برنامه‌ریزی و فراخوانی ابزارها رو داره. چند نکته مهم درباره این مدل: • سرعت خروجی روی گوشی همراه به ۳۰ توکن در ثانیه می‌رسه (زیر ۲.۵ گیگ رم) و روی تراشه‌های اپل تا ۲۲۰ توکن در ثانیه‌ست. • پنجره کانتکست ۱۲۸K داره و برای ورودی‌های بلند ایجنت‌ها آماده شده. • پایپ‌لاین آموزش ۴ مرحله‌ای جالبی داره: ترکیب SFT، مدل‌های معلم متخصص، تقطیر دانش چندحوزه‌ای (MOPD) و Agentic RL با الگوریتم GRPO داخل محیط‌های واقعی ایجنت مثل OpenClaw. • در بنچمارک‌های پیروی از دستورات و استفاده از ابزار، مدل‌های بزرگتر مثل Gemma 4 (5B/8B) و Qwen3.5-4B رو شکست داده. • از روز اول هم در llama.cpp (فرمت GGUF)، کتابخانه MLX، فریم‌ورک‌های vLLM و SGLang پشتیبانی میشه. • سازگاری کامل با فریم‌ورک‌های ایجنت مثل Hermes Agent، OpenClaw و Pi متن کامل مقاله و لینک چک‌پوینت‌ها: https://liquid.ai/blog/lfm2-5-2-6b @DevTwitter | <Mehdi Allahyari/>

چندوقت بود زیاد با مارک‌داون سروکار داشتم و هر ادیتوری یه مشکلی داشت - یکی RTL رو درست ساپورت نمی‌کرد، یکی اصلاً پیش‌نمایش نداشت، و از همه بدتر توی بیشترشون نمی‌شد روی خودِ پیش‌نمایش ویرایش کرد. پس این رو زدم: markdowneditor.ir بازش می‌کنی و می‌نویسی. نه ثبت‌نام، نه اکانت، نه نصب. هیچ بک‌اندی نداره - سندت توی localStorage همون مرورگر ذخیره می‌شه و هیچی آپلود نمی‌شه. کاملاً هم اوپن‌سورسه. چیزایی که داره: • پیش‌نمایش زنده - و برعکس بقیه، خودِ پیش‌نمایش هم قابل ویرایشه؛ متن رو انتخاب می‌کنی، تولبار فرمت‌دهی میاد و مثل Word با دکمه فرمت می‌دی - لازم نیست سینتکس مارک‌داون رو بلد باشی - هایلایت سینتکس برای ۴۰+ زبان برنامه‌نویسی - دیاگرام Mermaid و فرمول LaTeX - جدول با تنظیم چینش ستون‌ها، چک‌لیست، فوت‌نوت، reference link و بلاک‌های تاشو - سرچ و جایگزینی (Ctrl+F) - خروجی Markdown / PDF / HTML و کپی در سه فرمت - حالت مطالعه، تم تیره و روشن - پشتیبانی کامل RTL برای فارسی و عربی لینک گیت‌هاب: github.com/vahidaskari/md-editor @DevTwitter | <Vahid/>

اگه اخیراً سعی کرده باشید درگاه پرداخت کافه‌بازار رو روی پروژه‌های جدید فلاترتون پیاده کنید، احتمالاً شما هم با ارورهای روی اعصاب گریدل، خطای Duplicate class و گیر دادن به نسخه‌های قدیمی جاوا و کاتلین مواجه شدید. پکیج اصلی poolakey متاسفانه خیلی وقته آپدیت نشده و روی فلاتر و اندروید استودیوهای جدید رسماً بیلد نمیده یا تداخل ایجاد می‌کنه. من برای پروژه‌های خودم حسابی درگیر این داستان بودم و دیدم بهترین کار اینه که کدهاش رو فورک کنم و کلاً با استانداردهای جدید سیستمِ بیلدِ اندروید بازنویسیش کنم. نتیجه‌اش شد این پکیج: Flutter Poolakey Plus تغییرات مهمی که تو این فورک دادم: - ارتقای AGP به نسخه 9.0 - هماهنگی کامل با کاتلین 2.3 و جاوا 17 - حذف مخازن منسوخ شده مثل JCenter - سازگاری کامل با اندروید 14 - حل مشکل namespace در گریدل‌های جدید خوبی‌اش اینه که نیازی نیست کدهای دارتِ سمت اپلیکیشنتون رو حتی یک خط تغییر بدید؛ API همون قبلیه. فقط کافیه آدرس این ریپازیتوری رو توی فایل pubspec.yaml جایگزین نسخه قبلی کنید و تمام. اگه مشکلتون رو حل کرد و به کارتون اومد، ممنون میشم بهش Star بدید تا بقیه بچه‌های کامیونیتی هم بتونن راحت‌تر پیداش کنن. دمتون گرم! https://github.com/4itsam/flutter_poolakey_plus @DevTwitter | <Ali Miri/>

بعضی پروژه‌ها برای پیدا کردن یک تکه کد، بیشتر از تغییر دادنش وقت می‌گیرن. اگه برای تغییر یه component مجبور میشی بین پنج تا پوشه رفت‌وبرگشت کنی، معماری پروژه تمیز نیست؛ فقط فایل‌ها خوب از هم قایم شدن. روی کاغذ همه‌چیز مرتب و تفکیک‌ شدست؛ اما برای فهمیدن یک feature باید نصف پروژه رو بگردیم. خیلی وقت‌ها Separation of Concerns رو با جداکردن فایل‌ها بر اساس نوعشون اشتباه می‌گیریم: همه‌ی componentها یک‌جا، همه‌ی hookها یک‌جا، testها در یک پوشه و هر تابع کوچیکی هم داخل utils. اوایل پروژه این ساختار خیلی مرتب به نظر میاد. اما بعد از مدتی برای فهمیدن رفتار یک feature باید چند جای مختلف پروژه رو بگردیم و رابطه‌هایی رو پیدا کنیم که داخل ساختار پوشه‌ها اصلاً دیده نمیشن. اینجاست که Colocation کاربردی میشه. ایده‌اش این نیست که همه‌چیز رو داخل یک فایل بریزیم. میگه چیزهایی که به هم وابسته‌ان و معمولاً با هم تغییر می‌کنن، باید تا جای ممکن نزدیک هم باشن. مثلاً اگه یک utility فقط داخل ProductCard استفاده میشه، منتقل‌کردنش به utils عمومی پروژه باعث reusable شدنش نمیشه؛ فقط مالکیتش رو مبهم می‌کنه. بعداً ProductCard حذف میشه ولی اون utility و testهاش باقی می‌مونن، چون کسی مطمئن نیست جای دیگه‌ای استفاده میشن یا نه. تا وقتی مصرف‌کننده‌ی دومِ واقعی وجود نداره، اون utility بهتره کنار همون feature بمونه. وقتی واقعاً shared شد و قرارداد مشخصی پیدا کرد، انتقالش به یک بخش عمومی معنی پیدا می‌کنه. برای تصمیم‌گیری میشه سه سؤال ساده پرسید: ۱. اگه این feature حذف بشه، این فایل هنوز کاربردی داره؟ ۲. الان چند مصرف‌کننده‌ی واقعی داره، نه احتمالی؟ ۳. برای تغییر این رفتار باید بین چند پوشه جابه‌جا بشم؟ اگه فایل فقط به یک feature وابسته‌ست، احتمالاً جاش همون نزدیکی‌هاست؛ چه test باشه، چه style، hook، query یا utility. طبیعتاً E2E testهایی که چند flow رو پوشش میدن، مستندات سراسری و کدهایی که واقعاً بین چند بخش مشترکن، می‌تونن جای عمومی‌تری داشته باشن. Colocation قانون «همه‌چیز کنار component» نیست؛ محل هر فایل باید با محدوده‌ی کاربردش هماهنگ باشه. هدف از ساختار پروژه فقط مرتب‌کردن فایل‌ها نیست. ساختار خوب باید مالکیت و وابستگی‌ها رو واضح کنه تا تغییر، حذف و refactor کردن کد هزینه‌ی کمتری داش