Dev Fuel

اگه برنامه‌نویسی و بودجه محدودی داری، این ریپو خیلی به دردت می‌خوره. اسمش stack-on-a-budget هست و یه لیست کامل از سرویس‌هایی رو جمع کرده که free tier خوبی دارن. از هاستینگ و دیتابیس گرفته تا CI/CD و مانیتورینگ. لینک: https://github.com/255kb/stack-on-a-budget @DevTwitter | <Reza/>

اشکان یک ویدیو خیلی خوب راجع به نقشه راه یادگیری برنامه‌نویسی با هوش مصنوعی در ۲۰۲۶ گذاشته. https://www.youtube.com/watch?v=cCtpz9cU9Mg یه جاییش یه حرف خیلی خوبی زد که به نظرم منطقی بود و با واقعیت هم میخونه.

AI is an amplifier

هوش مصنوعی یک تقویت کننده است. اگر واقعا یک مهندس نرم‌افزار باشی قدرت‌ات چندین برابر میشه. و اگر ضعف هایی داشته باشی همون ضعف رو چندین برابر می‌کنه.

این ۳ قابلیت در کلاد Design Presentation Document از این به بعد برای کاربران با پلن رایگان در دسترسه. از بخش Artifacts در دسترس اند.

وقتشه که شهر رو نجات بدم! Source code

وقتشه که شهر رو نجات بدم! Source code

یه ماشین لینوکسی رایگان با Railway بساز سرویس Railway یه قابلیت جالب برای اجرای یک محیط لینوکسی موقت ارائه کرده که می‌تونی بدون ساخت حساب کاربری، اون رو امتحان کنی! 💻 مشخصات ماشین:

پردازنده: ۲ vCPU رم: ۲ گیگابایت سیستم‌عامل: Linux زمان استفاده اولیه: ۶۰ دقیقه مهلت Claim کردن محیط: تا ۲۴ ساعت

❓چطور ازش استفاده کنیم؟

ترمینال ویندوز یا PowerShell رو باز کن. دستور زیر رو اجرا کن: "ssh railway.new" مراحل نمایش‌داده‌شده رو دنبال کن تا محیط لینوکسی برات ساخته بشه. برای حفظ محیط، قبل از پایان مهلت ۲۴ ساعته، از لینک Claim که دریافت می‌کنی استفاده کن و ثبت‌نام رو تکمیل کن.

📝 چند نکته مهم:

برای شروع، نیازی به ساخت حساب کاربری یا واردکردن کارت بانکی نیست. اگر محیط رو در مهلت تعیین‌شده Claim نکنی، ماشین و اطلاعاتش حذف می‌شن. این قابلیت بیشتر برای تست، توسعه و آزمایش دستورات لینوکس مناسبه. رایگان و دائمی بودن سرور تضمین‌شده نیست و ادامه استفاده به شرایط پلن Railway بستگی داره. ممکنه هنگام شلوغی، امکان ساخت ماشین موقتاً غیرفعال باشه.

🔗 لینک: https://railway.com/free-vm #ماشین_مجازی #لینوکس #رایگان

مدل فارسی میزان 4B منتشر شد یه مدل تصمیم‌گیری (decision model) اوپن weight که برای فارسی ساخته شده. متن و سوال هارو دریافت میکنه و مثل jev برای هر سوال تایپ شده جواب و احتمال بهتون خروجی میده. با نسخه gguf فقط 2.5G رم میخواد و روی یک لپ تاپ هم اجرا میشه برای کامنت، تیکت پشتیبانی، پیامک و آگهی کلاهبرداری، رزومه و... سوال‌تون رو فارسی یا انگلیسی می‌نویسید و جواب رو میگیرید. روی 3000 داده واقعی فارسی داخل بنچ مارکی که انجام دادیم امتیاز 78.7 درصد گرفت، یعنی 5 درصد پایین‌تر از Jev و Clef 27B و تقریبا 16 درصد بیشتر از Laya huggingface.co/xmanii/Mizan-4B @Linuxor ~ mirzaei_mani

چرا هوش مصنوعی ها عشق Rust و React رو دارند؟ استدال خوب و منطقی بود .

داشتم یه مقاله‌ای رو از Ryan Carniato (خالق فریم‌ورک SolidJS) می‌خوندم با عنوان «هیچ‌کس برای استک شما استدلالی نیاورد» (Nobody Argued For Your Stack) که واقعاً ذهنم رو درگیر کرد. این مقاله دست گذاشته روی یه موضوع خیلی عمیق و خطری که هوش مصنوعی داره برای آینده مهندسی نرم‌افزار ایجاد می‌کنه. قضیه از جایی شروع شد که رایان متوجه شد توی داکیومنت‌های رسمی Anthropic (سازنده هوش مصنوعی Claude)، دستور نمونه برای قابلیت «مهاجرت کد در مقیاس بزرگ»، دقیقاً مثالِ مهاجرت از SolidJS به React هست! اونم درست توی همون هفته‌ای که تیم رایان بزرگ‌ترین آپدیت تاریخ پروژه‌شون یعنی نسخه Solid 2.0 RC رو منتشر کرده بودن. چطور همه‌چیز از یه خط داکیومنت شروع شد؟ رایان می‌گه اولش واقعاً دلم شکست، چون حاصل سال‌ها کارم شده بود مثالِ کلاسیکِ «چیزی که باید ازش مهاجرت کنی!». اما وقتی رفتم توی Internet Archive چک کردم، دیدم این مثال از آوریل ۲۰۲۶ توی داکیومنت‌های آنتروپیک بوده؛ یعنی حدود ۴ ماه قبل از اینکه خبر مهاجرت Cursor رسانه‌ای بشه! داستان این بود که ادیتور Cursor حدود ۷ ماه پیش بی‌سروصدا از Solid رفته بود روی React و فقط توی یه پست وبلاگ توی ماه ژانویه به عنوان یه «آزمایش» بهش اشاره کرده بود؛ بدون هیچ بنچمارک، عدد و رقم یا استدلال فنی. نکته ترسناک مقاله دقیقاً همین‌جاست: یا نویسنده داکیومنت Anthropic اون یه خطِ گم‌شده رو توی وبلاگ Cursor دیده، یا اصلاً بدون هیچ منبعی، خودش دیفالت رو بر این گذاشته که "همه دارن از Solid کوچ می‌کنند روی React"! یعنی صنعت ما به جایی رسیده که به جای انتقال «استدلال‌ها و بحث‌های فنی»، داره فقط «نتیجه‌گیری‌ها و حکم‌های صادرشده» رو پخش می‌کنه. چرا الان این موضوع بیشتر از قبل خطرسازه؟ رایان می‌گه قدیما هم تقلید کورکورانه وجود داشت (اینکه چون فیسبوک یا نتفلیکس از یه چیزی استفاده می‌کردن بقیه هم تقلید می‌کردن)، اما اون موقع تغییر استک هزینه انسانی و زمان زیادی می‌خواست، برای همین منطق و استدلال می‌تونست جلوی جوگیری و مدگرایی رو بگیره. ولی الان هزینه اجرا (Execution Cost) به لطف هوش مصنوعی تقریباً به صفر رسیده! چند تا مثال فنی خیلی جالب توی مقاله می‌زنه: بازنویسی Bun: پروژه Bun حدود ۱ میلیون خط کدش رو از زبان Zig به Rust بازنویسی کرد؛ اونم کلاً توی چند روز و به کمک ایجنت‌های Claude! مهاجرت Cognition (سازنده Devin): شرکت Cognition سایت مارکتینگش رو از Astro برد روی Next.js. اونم سایتی که محتواییه و زمین بازی و قلمروی اصلی Astro به حساب میاد! این مهاجرت رو خود ایجنت Devin انجام داد و به عنوان یه کیس‌استدی (Case Study) منتشرش کردن؛ بدون ارائه ریپازیتوری، بدون بنچمارک قبل و بعد، و بدون هیچ عدد و رقمی! خروجی این کار اصلاً «سایت» نبود، «داستان و نمایشی» بود که برای قدرت ایجنتشون ساختن. الان مهاجرت دادن کدها شده ژانر نمایشی (Demo Genre) برای صنعت ایجنت‌های هوش مصنوعی. ایجنت‌ها هم طبیعتاً کدهایی رو بی‌نقص‌تر مهاجرت می‌دن که به سمت تکنولوژی‌های غالب (که بیشترین دیتای آموزشی رو ازشون دارن) باشه. استدلال فنی واقعی چه شکلیه؟ رایان می‌گه استدلال فنی داره توی صنعت ما کمیاب میشه، در حالی که قبلاً اساس رشد ما بوده. چند تا نمونه از استدلال واقعی: بازنویسی Bun: وقتی Bun از Zig رفت روی Rust، جرد سامنر (Jarred Sumner) اومد با سند و مدرک توی دنیای واقعی در مورد کلاسِ باگ‌ها و مشکلات مدیریت مموری صحبت کرد و استدلال آورد. چیزی که بشه باهاش چالش کرد، ردش کرد یا قبولش کرد. تیم TanStack: وقتی اونا React Server Components (RSC) رو روی سایت tanstack.com تست کردن، اول با بنچمارک رفتن سمتش و بعد که دیدن توی کیس خاص اونا تریدآف‌ها (Trade-offs) جواب نمی‌ده، با یه پست تحلیلی و بدون جنجال برگشتن روی حالت قبلی و علتش رو باز کردن. شکست jQuery: فریم‌ورک jQuery به React نباخت چون دیتای آموزشی هوش مصنوعی اینطوری می‌گفت؛ توی یه رقابت چندساله و بر اساس شایستگی فنی مبارزه رو واگذار کرد. تحلیل پشت پرده تصمیم Cursor (حجم دیتا vs تأییدپذیری) رایان میاد تصمیمی که Cursor برای مهاجرت گرفته بود و خودشون بازش نکرده بودن رو کالبدشکافی می‌کنه: تیم Cursor توی پستشون گفتن ایجنت‌ها توی نوشتن کد Solid بد بودن و سیگنال‌ها (Signals) باعث «تله‌های پرفورمنسی» و «پخش شدن تصادفی وضعیت‌ها» می‌شدن و برای حلش رفتن سراغ React Compiler. رایان می‌گه علت اصلی اینه که ایجنتی که مدل ذهنی React رو حفظ کرده، کد Solid رو هم مثل React می‌نویسه (و کد Solidای که مثل React نوشته بشه فاجعه‌ست!). وقتی ایجنت موقع نوشتن React اشتباه می‌کنه، دیتای آموزشیِ عظیم (Volume) دستش رو می‌گیره. ولی موقع Solid دیتای آموزشی کمتره و ایجنت گیج میشه. اما نکته جالب‌تر اینجاست: Cursor هم‌زمان از Tailwind کوچ کرده روی StyleX! با اینکه حجم دیتای StyleX توی اینترنت خیلی کمه، چرا این کار رو کردن؟ چون StyleX قابلیت تأییدپذیری (Verification) بالایی داره؛ استایل‌ها تایپ‌شده‌ن و اگه ایجنت کلاسی رو توهم بزنه (Hallucinate)، موقع بیلد ارور میده! رایان می‌گه برای کم‌هزینه کردن خطاهای ایجنت هوش مصنوعی دو تا محور داریم: حجم دیتا (Volume) و تأییدپذیری (Verification). React به لطف حجم بالای دیتای آموزشیش برنده میشه. StyleX به لطف قابلیت تأییدپذیری و تایپینگش برنده میشه. اتفاقاً تمام تمرکز طراحی توی نسخه Solid 2.0 هم دقیقاً رفته سمت بالا بردن همین بخش Verification تا ایجنت‌ها نتونن توش اشتباه کنن. خطری به نام «تک‌کشتی شدن» دنیای برنامه‌نویسی رایان هشدار میده که اگه این روند ادامه پیدا کنه، دنیای برنامه‌نویسی تبدیل میشه به یه محیط «تک‌کشتی» (Monoculture)؛ فرانت‌اند کلاً قفل میشه روی React، سیستم‌ها روی Rust، اسکریپت‌ها روی Python و همه سایت‌ها روی Next.js. چرا؟ چون سیستم‌های هوش مصنوعی نمی‌تونن فرق بین «فراوان بودن توی دیتای آموزشی» و «واقعاً بهتر بودن» رو تشخیص بدن! حتی اگه طرفدار سرسخت React هستید هم باید نگران باشید. React به این دلیل انقدر خوب شد که رقیب داشت؛ ویژگی‌هایی مثل Hooks یا همین React Compiler دقیقاً در جواب به فشار فریم‌ورک‌های جدیدتر و سیگنالی به وجود اومدن. اگه رقابت نابود بشه، اکوسیستم درجا می‌زنه. ایده بزرگ بعدی قراره از کجا بیاد؟ خود React سال ۲۰۱۳ وقتی اومد، به خاطر JSX توسط کل جامعه برنامه‌نویسی مسخره شد که "چرا مارک‌آپ رو آوردی توی جاوااسکریپت؟! پس جداسازی دغدغه‌ها چی میشه؟!". اگه ایجنت‌ها و دیتابیس‌های آموزشیِ امروز توی سال ۲۰۱۳ وجود داشتن، React رو توی همون قدم اول نابود می‌کردن چون با عرفِ اون زمان (jQuery و Backbone) فرق داشت و توی دیتابیس هوش مصنوعی نبود! حرف نهایی رایان اینه: درسته‌ که ابزارهای هوش مصنوعی مهاجرت دادن کدها رو خیلی ارزون و سریع کردن، اما ما برنامه‌نویس‌ها نباید بگذاریم هوش مصنوعی و جوّ مارکتینگ جای «استدلال، بنچمارک و تحلیل مهندسی» رو بگیرن. ما هنوزم باید سر تکنولوژی‌های بهتر با استدلال فنی بجنگیم، وگرنه نوآوری توی دنیای توسعه نرم‌افزار متوقف میشه. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

شرکت Anthropic قوانین استفاده از هوش مصنوعیش یعنی Claude رو آپدیت کرده و یه بند عجیب بهش اضافه شده: بدرفتاری کلامی و توهین مکرر به مدل‌هاش رسما ممنوعه! این شرکت حتی رفته با پژوهشگرهای مذهبی صحبت کرده تا ببینه کلود ممکنه آگاهی یا روح داشته باشه یا نه. حالا هم گفتن اگه یوزری بی‌دلیل و مدام به این هوش مصنوعی فحاشی کنه یا باهاش بی‌رحمانه رفتار کنه، حسابش رو می‌بندن. ظاهرا دیگه به هوشنوعی هم نباید بگیم بالای چشمت ابروئه! Mahdi Hazrati

🌐 IPCheck.ing | جعبه‌ابزار کامل تست IP و VPN اگر می‌خواهید از عملکرد صحیح VPN، پروکسی یا کانفیگ Clash، Sing-box و Xray مطمئن شوید، IPCheck.ing یکی از بهترین ابزارهای رایگان و متن‌باز برای این کار است. 🔗 وب‌سایت: https://ipcheck.ing 💻 سورس پروژه: https://github.com/jason5ng32/MyIP 🧰 ابزارهای موجود: 🔍 جستجوی آی‌پی 🌍 پرس‌وجوی هر IP 🌐 تست اتصال 🎥 تست نشت WebRTC 🛡 تست نشت DNS 🚀 تست سرعت 📶 تست پینگ جهانی 🌎 آزمون جهانی MTR 📋 تست قوانین (Rule Test) 🌐 حل‌کننده DNS 🚫 بررسی سانسور 📄 جستجوی Whois 🖧 جستجوی سازنده MAC Address 💻 اطلاعات مرورگر 🔐 چک‌لیست امنیت آنلاین 🥷 تست نامرئی بودن (Invisibility Test) 📡 وضعیت سرویس‌ها 🧬 تست نشت DNS پیشرفته ✅ این ابزار برای بررسی نشتی DNS و WebRTC، تست کیفیت اتصال، عیب‌یابی کانفیگ‌ها و بررسی وضعیت دسترسی به سرویس‌های مختلف، یکی از کامل‌ترین گزینه‌های موجود است. #معرفی_سایت #آی_پی_شناسی پ‌ن: حتما ثبتنام کنید تا همه‌ی قابلیتها برای شما در دسترس باشه

یه مدل typed decisions با نام laya-mlx معرفی شد. برخلاف Jev اوپن سورسه. اما فعلا فقط مخصوص Apple Silicon عه. با Github actions میرم برای تستش.

توی هر پروژه ای شما لازم دارین برای بعضی از سکشن ها مثل پروفایل یک کاربر از آواتار های پیش ساخته شده استفاده کنین یا هوش مصنوعی اول اسم و فامیل کاربر رو به عنوان آواتار میزاره که بعضا میتونه ترکیبش جالب نشه ! این پکیج بهتون کمک میکنه که بتونین آواتار های باحال و جذاب به پروژتون اضافه کنین با کمتر از چند خط کد ! https://blobatar.dev/ @codehalics | کدهالیک

از اونجایی که لانچ graphify روی پروژه ها برای بار اول یه خیلی توکن میسوزونه، دنبال مدلی رایگان بودم که اینکار رو انجام بده. مدل های رایگان openrouter اصلا نتونستند کار رو در بیارن و مدام قطعی داشتند. مدل deepseek-v4-flash-0731:free هم یکی دو روز پیش در openrouter رایگان شده بود. اما درخواست بررسی هر جایی از سیستم رو میخواست الا خود پروژه :/ ‏ Qoder رو نصب کردم خوب کار رو درآورد.

من Jev رو روی زبان فارسی با پیچیدگی‌های مختلف امتحان کردم! و نتیجه واقعا شگفت‌زده‌ ام کرد. روی 5 سناریوی مختلف تستش کردم؛ از تشخیص یک درخواست ساده گرفته تا متن ‌هایی با چند درخواست همزمان، تناقض، شرط و جمله ‌های منفی. مثلا در یکی از تست ‌ها، کاربر قبلا درخواست بستن حسابش رو داده بود، ولی در حال حاضر نمی‌خواست حسابش بسته بشه. Jev تونست این دو موضوع رو از هم تفکیک کنه. در یک تست دیگه هم کاربر گفته بود فعلا درخواست بازگشت وجه نداره، اما اگر مشخص بشه مبلغ دوبار از حسابش کم شده، مبلغ اضافه رو می‌خواد؛ Jev این تفاوت رو هم درست تشخیص داد. در سناریو های چند موضوعی هم تونست نیت اصلی کاربر رو از مسائل فرعی جدا کنه؛ مثلا بین مشکل دسترسی به گزارش ‌ها، احتمال پرداخت تکراری و یک هشدار امنیتی، مشکل دسترسی رو به‌عنوان درخواست اصلی تشخیص داد. بعضی تست ‌ها 800 تا 900 توکن ورودی و چندین سوال همزمان داشتند و زمان ارزیابی Jev بین حدود 80 تا 200 میلی ‌ثانیه بود. برای فارسی و این نوع تصمیمات ساختاریافته، نتیجه‌ای که از چند سناریوی نسبتا سخت گرفتم واقعاً امیدوارکننده بود.

پروژه Kev که از ایده Jev الهام گرفته رو هم کلون گرفتم و تست کردم. پشت پرده از مدل Qwen2.5-0.5B استفاده می‌کنه که خب در نهایت یک LLM هست (البته با نیم میلیارد پارامتر میشه در دسته‌ی SLM ها حسابش کرد) و کیفیت نتایج به خوبی Jev نبود.

‏Jev که اخیرا زیاد سر و صدا کرده بود، عضو waitlist اش بودم و الان تونستم ثبت ‌نام کنم. یه چندتا تست گرفتم و با توجه به سرعت اجرا، نتایج خوبی داشت. برای دوستانی که نمی‌دونند: در بسیاری از سناریوها تا به حال از LLM ها استفاده می‌کردیم تا یک سری تشخیص کاملا ساختار یافته، بسته به نیازمون، بهمون بدن. یعنی چی؟ مثلاً فرض کنید ما یک پشتیبان هوش مصنوعی در سایتمون داریم. می‌خوایم با استفاده از هوش مصنوعی تشخیص بدیم که کاربر در این سیستم ما چی می‌خواد. آیا کاربر درخواست بازگشت وجه داده؟ آیا کاربر مشکلی در پرداخت داره؟ آیا کاربر ابهاماتی در مورد برنامه داره؟ بعد که دقیق تونستیم تشخیص بدیم نوع درخواست چیه، یک سری حرکات می‌تونیم بزنیم که می‌تونه خیلی خلاقانه باشه. مثلاً اگر هوش مصنوعی تشخیص داد درخواست کاربر بازگشت وجه هستش و صلاحیت این رو داره و با سیاست پروژه ما هم سازگاره، به‌طور اتومات بازگشت وجه رو براش انجام بدیم و یک پیام مناسب هم براش بفرستیم. تا الان خیلی از این کارها رو با LLM های عمومی انجام می‌دادیم؛ یعنی متن کاربر رو به مدل می‌دادیم و ازش می‌خواستیم تشخیص بده که پیام کاربر از کدام نوع هستش و خروجی ساختاریافته بهمون بده. که خب چون LLMهای عمومی مشخصا برای چنین تصمیم ‌گیری ‌هایی ساخته نشدند، ممکن بود با خطا، latency بالا و خروجی ‌های نامطمئن مواجه بشیم. اما مدل Jev از typesafe.ai یک مدل بهینه و مخصوص این نیاز هست. هم سرعتش خیلی بالاست و هم برای این نوع تصمیمات بهینه شده و به‌جای تولید متن آزاد، مستقیماً تصمیم ساختاریافته همراه با احتمال برمی‌گردونه.

یک مقاله درباره مفاهیم مدیریت داده ها در دنیای نرم افزار تدوین و منتشر کردم. که تدوینش واقعا زمان برد. خیلی طولانی شد ولی اگر دوست داشتید بخونید https://vrgl.ir/12Qtr

بعضی روز ها شک! به سراغم میاد و از خودم می‌پرسم، چیکار دارم میکنم واقعاً؟ یکم عجیبه. که خیلی اتفاقی با این بیت معروف از سعدی رو به رو شدم:

به راه بادیه رفتن به از نشستن باطل و گر مراد نیابم به قدر وسع بکوشم