Md Daily

اگه این مدت برای کد زدن زیاد با Codex کار کرده باشید، احتمالاً می‌دونید که وسط کار و دقیقاً جایی که غرق دیباگ یا پیاده‌سازی یه فیچرید، خوردن به لیمیت چقدر عذاب اوره :) من خودم برای اینکه این چالش رو دور بزنم، اول رفتم سراغ ابزارهایی مثل Omni Router تا بیام خود ChatGPT Web رو پروکسی کنم و از اون طریق کارم رو راه بندازم. روی کاغذ ایده خوبی بود، ولی توی عمل به یه مشکل اساسی خوردم: نسخه وب عملاً هیچ دسترسی مستقیمی به فایل‌های روی سیستمم نداشت! یعنی باز مجبور بودم هی کدها رو کپی-پیست کنم و دستی بهش کانتکست بدم که عملاً کل سرعت کار رو می‌گرفت. توی همین گشت‌وگذارها رسیدم به یه پروژه متن‌باز و خیلی خفن به اسم Chat On Steroids که دقیقاً اومده همین خلا رو پر کنه و ChatGPT معمولی رو تبدیل کنه به یه محیط کدنویسی به سبک Codex. 💡 داستان این ابزار چیه و پشت صحنه چطوری کار می‌کنه؟ برخلاف پروکسی‌های ساده، این ابزار مستقیم سراغ صدا زدن Codex نمیره؛ بلکه از همون مکالمات خودتون توی ChatGPT استفاده می‌کنه. مکانیزمش هم اینطوریه که یه افزونه مرورگر (برای Chrome، Edge یا Brave) داره یا میتونید مثل من از مرورگر خودش استفاده کنید که رابط کاربری ChatGPT رو توی مرورگر کنترل و اتومیت می‌کنه و از طرف دیگه، ابزارهای لوکال سیستم شما رو از طریق پروتکل MCP (به عنوان یه Custom MCP Server و از طریق تانل) به چت‌بات وصل می‌کنه. 🔥 مهم‌ترین قابلیت‌هاش: 🔹 دسترسی مستقیم به پروژه و ترمینال: به ChatGPT اجازه میده مستقیم فایل‌های پروژه‌تون رو بخونه و ادیت کنه، تست‌ها رو ران بگیره، ترمینال‌ها رو باز نگه داره و حتی از محیط دسکتاپتون استفاده کنه. نتایج اجرای هر ابزار رو هم به صورت زنده می‌تونید دنبال کنید. 🔹 ساختن تیم با Workerهای موازی: می‌تونید تسک‌های مستقل رو بین چندتا Worker تقسیم کنید و در نهایت خروجی‌هاشون رو جمع کنید. نکته باحالش اینه که هر ورکر کانتکست خودش رو نگه می‌داره و برای تسک بعدی دقیقاً از همون‌جایی که کارش تموم شده ادامه میده. 🔹 کنترل کامل روی تسک‌های طولانی: وسط اجرای کار می‌تونید براش اصلاحیه بفرستید. دو تا قابلیت Goal (برای پیگیری کارهای ناتمام) و Loop داره و از همه مهم‌تر، ویژگی Compact & Resume رو داره که تاریخچه سشن و ورکرها رو فشرده می‌کنه و می‌بره توی یه چت کاملاً جدید تا وقتی چت طولانی شد، به مشکل پر شدن کانتکست نخورید. 🔹 مولتی‌پلتفرم و رایگان: پروژه با لایسنس MIT منتشر شده و برای ویندوز، مک (Apple Silicon) و لینوکس (پکیج‌های .deb و AppImage) نسخه آماده داره. ⚠️ چندتا نکته فنی که قبل از استفاده باید حواستون باشه: - خود توسعه‌دهنده توی مستندات تاکید کرده که این ابزار برای دور زدن قوانین یا ساختن سهمیه اضافه نیست؛ چون در نهایت ChatGPT Work و Codex از لیمیت‌های مشترک اکانت استفاده می‌کنن. اما اینکه می‌تونید بدون درگیری با کپی-پیست، کانتکست رو با Compact & Resume تمیز نگه دارید و از چت وب مثل یه ایجنت لوکال کار بکشید، مصرف و بهره‌وری رو خیلی بهینه‌تر می‌کنه. - برای راه‌اندازیش نیاز به اکانتی دارید که قابلیت ساخت Custom MCP App توش فعال باشه. - چون افزونه‌ش داره UI مرورگر رو اتومیت می‌کنه (و یه API رسمی اتومیشن نیست)، حتماً روی فولدرهایی که بهش دسترسی میدید نظارت داشته باشید و با مسئولیت خودتون ازش استفاده کنید. اگه شما هم دنبال این بودید که از اشتراک ChatGPT خودتون مستقیم روی فایل‌های لوکال و ترمینال سیستم استفاده کنید، حتماً یه سر به ریپوش بزنید، راهنمای نصبش هم مرحله‌به‌مرحله و تصویریه :) 🐱 لینک گیت‌هاب پروژه: https://github.com/totec448-spec/chat-on-steroids —- 💡 مثل همیشه کنجکاو بمونید 🆔 @MdDaily

من معمولا از تجربه های شخصی خارج از دنیای فنی چیزی نمی نویسم توی کانال ولی این بار فرق داره! چیزایی که می‌خوام بگم احتمالاً برای خیلیاتون بدیهیه. خودمم می‌دونستم استراحت مهمه، ولی توی برنامه‌م همیشه یه کار مهم‌تر از استراحت پیدا می‌شد. انگار بعضی چیزا انقدر واضحن که کمتر از خودمون می‌پرسیم: خب چقدر داریم بهشون عمل می‌کنیم؟ روتین روزمره‌ی خودمو داشتم. صبح بیدار شم، کار کنم، یه تایمی برم باشگاه، تودولیست و مدیریت پروژه داشته باشم و دوباره بخش زیادی از روز رو صرف درس و کار کنم. روی کاغذ همه‌چیز خوب بود. هدف داشتم، برنامه داشتم، می‌دونستم برای چی دارم تلاش می‌کنم. ولی از یه جایی به بعد، با وجود همه‌ی اینا، هر روز بی‌انگیزه‌تر می‌شدم. صبح‌ها بیدار موندن و شروع‌کردن روز برام سخت شده بود. خواب‌هام آشفته شده بود و یه اضطراب درونی یا بی‌حوصلگی‌ای داشتم که حتی خودمم دقیق نمی‌فهمیدم از کجا میاد. همین گیج‌کننده بود؛ وقتی برای بیدارشدن دلیل داری، چرا شروع‌کردن روز این‌قدر سخت میشه؟ 💭 این تجربه باعث شد به یه بخش از برنامه‌م بیشتر فکر کنم: توی این همه کاری که برای خودم چیده بودم، استراحت واقعی کجا بود؟ یه تایمی که قرار نباشه چیزی یاد بگیرم، پروژه‌ای رو جلو ببرم یا حتی از وقتم «استفاده‌ی مفید» بکنم. انگار برای استراحت هم باید آخر روز یه خروجی قابل ارائه داشته باشیم. یه بار که پیش تراپیستم بودم، ازم پرسید: «آخرین بار کی مسافرت رفتی؟»\ گفتم بیشتر از یه ساله جایی نرفتم. همین سؤال باعث شد فکر کنم آخرین بار کی واقعاً از این روتین فاصله گرفتم؟ یه تایمی که ذهنم درگیر کار بعدی و برنامه‌ی فردا نباشه. خب اوکی، شاید الان شرایط سفر فراهم نباشه. شاید نشه رفت یه جای جدید و اون تجربه‌ها رو داشت. ولی اون بخشی از سفر که دلم می‌خواست، یعنی فاصله‌گرفتن از کار و استراحت‌کردن رو چطور؟میشه توی همین شرایط براش جا باز کرد؟ مثلاً یه روز لپ‌تاپو باز نکنم، تسک جدیدی برای خودم نچینم، پیام‌های کاری رو تا جایی که میشه بذارم برای بعد و چند ساعتی برم یه فضای سبز نزدیک. بدون اینکه توی مسیر هم بخوام یه پادکست آموزشی گوش بدم که مبادا چیزی یاد نگرفته باشم :) قرار نیست تمام حس و تجربه‌ی سفر رو بازسازی کنم. ولی می‌تونم برای بخشی از چیزی که از سفر می‌خواستم، همین‌جا جا باز کنم؛ بدون اینکه منتظر فراهم‌شدن شرایط یه سفر کامل بمونم. خب این موضوع از نظر علمی هم ارزش توجه داره. CDC توضیح میده که استرس می‌تونه با تغییر انرژی و علاقه، مشکل تمرکز و خواب آشفته همراه بشه. البته این علائم به‌تنهایی علت رو مشخص نمی‌کنن؛ از روی تجربه‌ی خودم هم نمی‌تونم نتیجه بگیرم که همه‌ش فقط به خاطر کمبود استراحت بوده. از اون طرف، مؤسسه‌ی ملی سلامت روان آمریکا، NIMH، کنار خواب کافی و فعالیت بدنی، روی زمان منظم برای فعالیت‌های آرامش‌بخش، حضور توی طبیعت و محدودکردن کارهایی که قبول می‌کنیم تأکید می‌کنه. چیزی که باید توی روزمره‌مون براش جا داشته باشیم. برای من، چیزی که می‌خوام جدی‌تر بگیرم همینه: یه زمان مشخص برای استراحت خالص. مثلاً یکی‌دو بار در ماه یه روز کامل رو خالی بذارم و سریع با کارهای عقب‌افتاده پرش نکنم. این عدد پیشنهاد شخصیه؛ نیاز همه یکسان نیست و اون یه روز هم جای خواب کافی و استراحت‌های روزمره رو نمی‌گیره. یه تایمی ابزارهای تکنولوژی رو بذاریم کنار، با آدمی که کنارش راحتیم وقت بگذرونیم یا فقط محیط اطرافمون رو ببینیم. حتی بذاریم یه کم حوصله‌مون سر بره، بدون اینکه اولین واکنشمون بازکردن اینستا باشه. لازم نیست هر لحظه‌ی خالی رو با یه ورودی جدید پر کنیم. از اون طرف، علاوه بر زمانی که برای استراحت نمی‌ذاریم، نحوه‌ی گذروندن ساعت‌های کارمون هم جای فکر داره. فرض کنید داریم کد می‌زنیم یا یه مطلب درسی می‌خونیم. وسطش یه پیام رو جواب میدیم، ایمیل رو چک می‌کنیم، یه نگاه به تسک پروژه‌ی بعدی میندازیم و قبل از برگشتن هم میگیم «حالا این نوتیفیکیشن رو هم ببینم چیه». اگه هم مشغول وایب کدینگ باشیم، کنار همه‌ی اینا یه ایجنت داره فیچر پیاده می‌کنه، یکی دیگه داره تست می‌نویسه و ما توی یه تب دیگه داریم تغییرات قبلی رو ریویو می‌کنیم. اولی برای ادامه‌ی کار سؤال می‌پرسه، دومی میگه تست‌ها پاس نمیشن، هم‌زمان هم پیام میاد که «راستی اون باگو دیدی؟» بعد برمی‌گردیم سر کاری که دستمون بود. خب کجا بودیم؟ این پاراگراف چی می‌گفت؟ این دیف مال کدوم تسکه؟ اصلاً به این ایجنت گفته بودم چی کار کنه؟ :)) یه بخش از روزمون این‌طوری صرف دوباره فهمیدنِ کاری میشه که همین چند دقیقه پیش می‌دونستیم چیه. حتی وقتی ایجنت‌ها موازی کار می‌کنن، بررسی خروجی‌ها و تصمیم‌گرفتن هنوز توجه ما رو می‌خواد. توی کارهای فکریِ نیازمند توجه، چیزی که اسمش رو میذاریم multitasking، خیلی وقت‌ها جابه‌جایی مداوم بین چند کاره. انجمن روان‌شناسی آمریکا، APA، توضیح میده که این رفت‌وبرگشت هزینه داره: باید هدف و قواعد کار بعدی رو دوباره فعال کنیم و موقع برگشت یادمون بیاد کجا بودیم. تکرار این جابه‌جایی‌ها می‌تونه زمان انجام کار و احتمال خطا رو بیشتر کنه؛ مخصوصاً وقتی کارها پیچیده‌ترن. 📖 برای فکرکردن به این بخش از روزمره‌مون، پیشنهاد می‌کنم اگه نخوندید، سراغ کتاب کار عمیق، Deep Work، از کال نیوپورت برید. موضوعش تمرکز بدون حواس‌پرتی روی کارهای فکریِ دشواره. چندتا ایده‌ی کاربردی ازش: 🎯 برای یه کار مشخص، زمان مشخص بذارید. معلوم باشه قراره روی چی کار کنید و چه چیزهایی تا پایان اون بازه می‌تونن منتظر بمونن. 🌱 تحمل بی‌حوصلگی رو تمرین کنید. توی هر فاصله‌ی کوتاه، سریع سراغ گوشی نرید. نیوپورت این رو بخشی از تمرینِ توانایی تمرکز می‌دونه. 🔕 برای پیام‌ها و کارهای ریز مرز بذارید. تا جایی که شرایط کار اجازه میده، زمان رسیدگی بهشون مشخص باشه تا تمام روز رو تکه‌تکه نکنن. 🛠 ابزارها رو آگاهانه انتخاب کنید. ببینید فایده‌ی واقعی هر ابزار برای کار و زندگی‌تون، نسبت به توجهی که ازتون می‌گیره چقدره. 📝 برای روز کاری یه پایان داشته باشید. کارهای باز و قدم بعدیشون رو یادداشت کنید، مشخص کنید کی بهشون برمی‌گردید و بعد کار رو تموم کنید. این همون ایده‌ی روال پایان کار نیوپورته. خودش درباره‌ی استراحت بین کار عمیق هم توضیح میده که قرار نیست ساعت‌ها بدون وقفه تمرکز کنیم. یه قدم‌زدن کوتاه می‌تونه فرصت نفس‌کشیدن بده؛ بازکردن اینباکسی که چندتا دغدغه‌ی جدید میاره، جنس متفاوتی داره. یه نکته هم این وسط مهمه: اگه اضطراب، آشفتگی خواب یا بی‌علاقگی ادامه پیدا کرده و روی زندگی روزمره اثر گذاشته، بهتره با پزشک یا متخصص سلامت روان مطرحش کنیم. استراحت و تغییر شیوه‌ی کار، جای بررسی علت این حال رو نمی‌گیرن. چیزی که این تجربه برای من پررنگ کرد این بود که هدف‌داشتن و نیاز به استراحت می‌تونن هم‌زمان وجود داشته باشن. میشه مسیرت رو دوست داشته باشی و باز هم به توقف نیاز داشته باشی. دلم می‌خواد برای اون زمانی که هیچ تسکی تیک نمی‌خوره هم جا باز کنم. یه روز که آخرش اگه از خودم پرسیدم «خب امروز چی کار کردی؟»، بتونم راحت بگم: استراحت کردم و بابتش احساس نکنم روزم از دست رفته. —- 💡 مثل همیشه کنجکاو بمونید؛ حواستون به خودتون هم باشه :) 🆔 @MdDaily

موقع ثبت نام از کد دعوت اختصاصی MdDaily استفاده کنید و ثبت نامتون شامل ۲۰ درصد تخفیف میشه. 🎁 —- 💡 مثل همیشه کنجکاو بمونید : ) 🆔 @MdDaily

⭕️ هشتمین رویداد ماگ تهران (مارکتینگ و توسعه کسب‌و‌کار) 🔥 شبکه سازی، ارائه و گفتگوی کاری در کنار متخصصین 🎤 ارائه‌ تجربه محور توسط مهدی شجاری 🗣️ پنل گفتگو با موضوع بکارگیری هوش مصنوعی در توسعه کسب و کارهای آنلاین با همراهی آقایان حمیدرضا نظری، لقمان آوند و حمید پورجم 👇👇👇 🔗 https://abrh.ir/latestevent 🔗 👆👆👆 در کانال ابرها عضو شوید: ✌️ 📣@abrhacom

داشتم یه مقاله‌ای رو از 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

داشتم رویه سرویسی کار میکردم که نیاز به نقشه داشتم. از یه طرف میخواستم از OSM استفاد کنم به دلیل مشکلات اینترنتی لود شدنش کند بود و از طرفی هم بقیه ی سرویس های نقشه ی ایرانی مثل نشان پولی بودن. توی سرچ هام سرویس مَپ‌آپ رو پیدا کردم. هم توی Leaflet و هم OpenLayers ساپورت میشه و افزونه ی وردپرسی هم دارن. طبق گفته ی سایتش دسترسی پایدار ۲۴/۷ داره و بدون محدودیت تحریم هست و به‌روزرسانیشم به صورت لحظه ای انجام میشه. 🔗 https://mapup.ir/ 🔄 آپدیت: سرویس https://memaps.ir/ هم هست ولی نیاز به ثبت نام داره —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

اینم از مقاله ای که قولشو داده بودم . توی خود مقاله به صورت کامل همراه با مثال و پرامپت توضیح داده شده مفاهیم ولی به صورت خلاصه بخوام نکاتی که تو مقاله هست رو بگم: مفاهیم پایه روند کار هوشمندتر از چت معمولی از ۳ لایه تشکیل شده: ایجنت (برنامه‌ریزی و اجرا)، حلقه (تکرار تا رسیدن به کیفیت مطلوب) و گراف (اجرای موازی و وابسته). ایجنت‌ها (Agents) مفهوم اصلی: تفاوت چت و ایجنت در توانایی دنبال کردن هدف بدون دخالت انسان است. عناصر سه گانه: دسترسی به ابزارها (سرچ، اجرای کد، API)، حافظه بین وظایف، و حلقه اجرای مستمر. سطوح ایجنتی: از سطح ۱ (چت متنی ساده) تا سطح ۴ (سیستم کاملاً خودمختار با زمان‌بندی و محرک‌های خارجی). حل مشکل حافظه: جلوگیری از Context Drift با ثبت چک‌پوینت‌های فشرده (زیر ۱۵۰ کلمه)، خلاصه کردن مکالمات طولانی، و درج اطلاعات ثابت در سیستم‌پرامپت. حلقه‌ها (Loops) چرخه ۵ مرحله‌ای: برنامه‌ریزی (Plan) ⬅️ اجرا (Execute) ⬅️بررسی (Check) ⬅️ اصلاح (Iterate) ⬅️توقف (Stop). بررسی سخت‌گیرانه (Gate): یک حلقه بدون تست قابلیت رد شدن خروجی، فقط پیش‌نویس تولید می‌کند نه پیشرفت. شرط توقف سخت: تعیین سقف تعداد تکرار (مثلاً حداکثر ۸ بار) برای جلوگیری از هدررفت توکن و بودجه. شرایط توجیه اقتصادی: کار تکراری باشد، قابلیت نمره‌دهی خودکار داشته باشد، مداخله انسانی نخواهد و معیار پایان شفاف داشته باشد. مدیریت هزینه: تکرار حلقه طول بافت را رشد می‌دهد؛ اگر نرخ نگه‌داشت خروجی‌ها زیر ۵۰٪ باشد، ساخت حلقه صرفه اقتصادی ندارد. گراف‌ها (Graphs) تعریف: ساختاری از واحدهای مستقل کار (گره/Node) و روابط داده‌ای واقعی بین آن‌ها (یال/Edge). تست یال ساختگی: حذف ترتیب‌های زمانی خودساخته و تبدیل مراحل بی‌ارتباط به کارهای هم‌زمان (موازی). الگوی لوزی (Fan-out / Fan-in): پخش شدن کار بین چند گره موازی و سپس جمع‌بندی آن‌ها در یک گره نهایی جهت کاهش چشمگیر زمان اجرا. بررسی‌کننده ایزوله (Isolated Verifier): ایجنت مجری نباید خودش کارش را نمره‌دهی کند؛ گره Verifier باید حافظه/بافت (Context) کاملاً تازه و خالی داشته باشد. فرمت ساختاریافته: استفاده از خروجی‌های مشخص (مثل JSON یا کلیدواژه depends_on) برای دست‌به‌دست شدن اتوماتیک اطلاعات بین گره‌ها. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

گوگل مدل Gemini 3.7 Flash رو معرفی کرد طبق گفته ی خودش توی پست اینستاگرام اکانت googlefordevs :

با Gemini 3.7 Flash⚡️ آشنا بشید— باهوش‌ترین مدل همه‌فن‌حریف ما تا به امروز برای کدنویسی و ایجنت‌ها! این مدل، هوشمندی بالاتری رو برای جریان‌های کاری (ورک‌فلوهای) پیچیده ارائه می‌ده و تا پایان سال با قیمت معرفی ۰.۷۵ دلار به ازای هر ۱ میلیون توکن ورودی و ۳.۷۵ دلار به ازای هر ۱ میلیون توکن خروجی در دسترسه. همین حالا می‌تونید از طریق Google AI Studio و Android Studio، توی Google Antigravity و Gemini API بهش دسترسی داشته باشید

پ ن : باید منتظر بنچمارک هاش باشیم ولی همه کامنت گذاشته بودن و منتظر 3.5 pro هستن. احساس میکنم گوگل حوصله اش سر میره یه نسخه فلش جدید میده بیرون. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

این چند وقته احتمالا اسم Graphs , Agents, loops و اینا رو زیاد شنیدید یا خواهید شنید به زودی راجب اینکه هر کدوم از اینا دقیقا چی هستن و چیکار میکنن رو میذارم

خب خب، اینم از اولین Article منتشر شده تو کانال :) نظرتون با این سبک محتوا چیه؟

خِفتم کن! وقتی با AI کد می‌زنید، بزرگ‌ترین سم اینه که شما فقط بگی چی می‌خوای و اونم یه مشت کد بپاشه جلتون و شما هم بی‌فکر فقط «Accept» بزنید. اینجوری بعد از نیم ساعت کلاً پرت می‌شید که پروژه داره به کجا میره و کنترل از دستتون در میره. تکنیک اینه که بهش بگی: «Grill me» (خفتم کن!) درواقع داری بهش می‌گی قبل از اینکه دست به کد بشی، حتی قبل از اینکه به پلن برسی، زیر و بم قضیه رو ازم بکش بیرون. سوالای سخت بپرس، حالت‌های خاص (Edge cases) رو رو کن و همه‌چیز رو به چالش بکش. ایجنت شروع می‌کنه به سوال و جواب‌ها و در اکثر مواقع چند جواب ممکن رو پیشنهاد میده و گزینه پیشنهادی خودش رو هم با ذکر دلیل میگه، ولی تو همیشه میتونی جواب خودت رو اضافه کنی یا در مورد سوال باهاش بحث کنی. گاهی سوال‌های ارزشمندی می‌پرسه که تو حتی بهش فکر هم نکرده بودی. در نهایت یه پلن تر و تمیز و حساب شده تحویل میگیری که آماده پیاده‌سازیه. با این کار: ۱. فهم شما و AI از مسئله و نقشه راه دقیقاً یکی میشه. ۲. خودت هوشیار می‌مونی، می‌فهمی داری چیکار می‌کنی و فرمان دست خودته. ۳. برنامه‌نویسی با AI از حالت خسته‌کننده و رباتیک درمیاد و میشه یه همکاری واقعی. این مفهوم به نظر ساده میرسه و حتی اگه فایل skillهای مرتبط و مشابه grill-me رو نگاه کنید می‌بینید چند خط بیشتر نیست. ولی واقعاً تاثیر فوق‌العاده‌ای میذاره. اگه MCPهای کافی، به‌خصوص مربوط به resourceهای داخلی شرکت یا پروژه‌تون رو هم فعال داشته باشید، روند سوال‌وجواب‌ها و نتیجه کار واقعاً شگفت‌زده‌تون می‌کنه. پیشنهاد می‌کنم حتماً یک بار هم که شده امتحانش کنید. استاد @mattpocockuk توی این مقاله خیلی خوب و دقیق مفهومش رو باز کرده و خودِ skill رو هم پابلیش کرده که می‌تونید راحت نصبش کنید و رو ابزاراتون استفاده کنید: 🔗 https://www.aihero.dev/skills-grill-me —- 📲 منبع پست <Nick> 🆔 @MdDaily

🔥 پیشنهاد طلایی آروان کوین 🔥 🚀 اشتراک پریمیوم هوش مصنوعی جمینای ♊️ 🎉 قیمت ویژه: ۲۵۹,۰۰۰ تومان ماهانه! 📌 مشخصات اشتراک: • 📧 فعال‌سازی مستقیم روی ایمیل شخصی شما • 🔒 اکانت ۱۰۰٪ قانونی و اختصاصی (تضمین کیفیت) • ⚡️ تحویل فوری و پشتیبانی فنی سریع 📦 (سایر خدمات ربات: تلگرام پریمیوم، شارژ استیم، اپل آیدی و...) 🛒 ثبت سفارش و خرید آنی از ربات رسمی: @ArvanCoinBot 🤖

سلام به همگی 🫶 اول از همه نوروز🤍🐎🤍اتون مبارک باشه. وقتی که داشتم پیام تبریک نوروز ۱۴۰۴ رو مینوشتم و درگیر شوخی با سال ۴۰۴ بودیم، این سال مثل اسمش با کلی اتفاقات همراه بود و کلی چیز دیدیم و داغدار شدیم و در نهایت با جنگ به پایان رسید. امسال درحالی سال رو تحویل میکنیم که برای روز هاس در خاموشی دیجیتال به سر میبریم و به سختی به اینترنت ازاد متصل هستیم و حتی نمیدونم چند نفر قراره این پیام من رو ببین. به هرحال، امید با ارزش ترین چیزیه که داریم و امیدوارم سالی پر از اتفاقات به همراه حال دل خوب برای تک تک مردم کشورم داشته باشیم. به امید روز های روشن ❤️ بار دیگه سال نو رو به خانواده ی بزرگ Md daily تبریک میگم ارادتمند شما ماهان --- امسال بیشتر از پارسال کنجکاو باشید :) 🆔 @MdDaily

معرفی llmfit: ابزاری برای پیدا کردن مدل هوش مصنوعی مناسب سخت‌افزار شما این پروژه خیلی باحاله با راست نوشته شده و حجم نصبش کلا چند مگه و تحت ترمینال TUI اجرا میشه میاد بر اساس نیاز های سخت افزاری مدل ها بهتون میگه که با توجه به سیستمون کدوم مدل اجراش به چه صورته و چه قدر منابع مصرف میکنه ازتون 👩‍💻 https://github.com/AlexsJones/llmfit —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

توسعه وب فراتر از فرانت‌اند و بک‌انده خیلیا فکر می‌کنن توسعه وب یا اپلیکیشن ساده‌ست: فرانت، بک، تمام! تصور عمومی اینه که اگه بشه دیتا رو از دیتابیس به رابط کاربری (UI) رسوند، کار تمومه. واسه همین همه‌ی تمرکز می‌ره روی روت‌ها و کامپوننت‌ها، اما تهش پروژه‌ها انگار یه چیزی کم دارن. واقعیت اینه که توسعه وب یا اپلیکیشن، دقیقاً همون اتفاقاتیه که بین فرانت و بک می‌افته. 🧠 مدل ذهنی اولیه معمولاً یاد می‌گیریم همه‌چیز رو تفکیک کنیم: ⬅️فرانت‌اند: چیزی که کاربر می‌بینه. ⬅️ بک‌اَند: کاری که سرور انجام می‌ده. این مدل برای شروع خوبه، اما جلوی رشد رو می‌گیره. برنامه‌های واقعی معمولاً به‌خاطر کدِ بد شکست نمی‌خورن؛ اونا به این دلایل به مشکل می‌خورن: ❌ تصمیمات ضعیف در UX ❌ در نظر نگرفتن حالت‌های خاص (Edge cases) ❌ افت سرعت و پرفورمنس ❌ رعایت نکردن دسترسی‌پذیری (Accessibility) ❌ چالش‌های دیپلوی و کار تیمی این مسائل در دلِ کل سیستم جا دارن، نه فقط یک سمتِ کار. 🖥 وقتی «کار کردنِ کد» کافی نیست گاهی اپلیکیشن از نظر فنی سالمه، اما حس خوبی نداره. صفحه‌ها به‌خاطر عدم بهینه‌سازی عکس‌ها یا کش نشدن، کُند لود می‌شن. فرم‌ها کاربر رو خسته می‌کنن و ارورها نامفهومن. اینجا کد خراب نیست، تجربه‌ی کاربری خرابه. تحویل دادن فیچر فقط بخشی از کاره؛ طراحیِ رفتارِ درست سیستم، بخشِ اصلیه. 🫣 لایه‌های نامرئی بیشترِ چیزی که باعث می‌شه یه سایت یا اپ«خوب» باشه، نامرئیه: ✅حالت‌های لودینگ معنادار ✅ ارورهایی که راهنمایی می‌کنن، نه سرزنش ✅ کارکرد درست با کیبورد ✅ کنتراست رنگی و URLهای تمیز ✅ بهینه‌سازی‌های کوچک پرفورمنس این‌ها رو هیچ فریم‌ورکی خودکار انجام نمی‌ده؛ اینا انتخاب‌های آگاهانه‌ی برنامه‌نویسه. 🖥 بک‌اند فقط API زدن نیست توی بک‌اند هم همه‌چیز اندپوینت نیست. سوال اصلی ایناست: ارورها چطور مدیریت می‌شن؟ لاگ‌ها چقدر مفید‌ن؟ ورودی‌ها چطور اعتبارسنجی می‌شن؟ این کد کار می‌کنه:

app.get('/users', async (req, res) => { const users = await db.getUsers(); res.json(users); });

اما این نسخه مسئولانه‌ست:

app.get('/users', async (req, res) => { try { const users = await db.getUsers(); res.json(users); } catch (err) { logger.error(err); res.status(500).json({ message: "خطایی پیش اومد" }); } });

بک‌اند یعنی رفتار سیستم، نه فقط منطق کد. 📝 جای خالیِ آموزش‌ها توی آموزش‌ها معمولاً فقط «مسیر بی‌دردسر» رو می‌بینیم. کسی نمی‌گه: 🙋 وقتی API قطع شد یا اینترنت کاربر کُند بود، چی نشون بدیم؟ 🙋این کد شش ماه دیگه چقدر قابل فهمه؟ اینجاست که مرز بین «کد زدن» و «مهندسی نرم‌افزار» مشخص می‌شه. 🧠 سیستمی فکر کردن توسعه‌دهنده‌ی حرفه‌ای به جای «آیا این کار می‌کنه؟» می‌پرسه: ✔️ آیا این کد قابل نگهداری و پیش‌بینی هست؟ ✔️ آیا با کاربر و توسعه‌دهنده‌ی بعدی مهربونه؟ این یعنی دیدنِ کلِ مسیر؛ از فرانت و بک تا ابزارهای بیلد و دیپلوی. 📈 رشد در نگاه از دور پیشرفت واقعی وقتی شروع می‌شه که به جای زوم روی ابزارها، کل سیستم رو ببینید. کافیه دفعه بعد به چیزایی دقت کنید که قبلاً نادیده می‌گرفتید: یه تصمیم بهتر در UI، یه منطق امن‌تر در بک‌اند و کمی همدلی بیشتر با کاربر. این‌طوری پروژه‌ها کامل می‌شن. باورهای اشتباه ❌فرانت‌اند فقط ظاهره. ❌ بک‌اند فقط منطق و دیتابیسه. ❌یاد گرفتن فریم‌ورک سخت‌ترین بخش کاره. ❌ سریع تحویل دادن، همون خوب تحویل دادنه. توسعه وب یا اپلیکیشن، وصل کردنِ تصمیم‌های هوشمندانه به همدیگه است. توسعه یعنی تجربه، پرفورمنس، پایداری و جزئیات ریزی که کسی براشون دست نمی‌زنه، اما همه حسشون می‌کنن. یک لایه عمیق‌تر فکر کردن، همون چیزیه که توسعه‌دهنده‌های معمولی رو به عالی تبدیل می‌کنه. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

دردسرِ کدهای «تقریباً درست» 🔍 تصور کن سه‌شنبه هفته پیشه و یه برنامه‌نویس سه ساعت تمام وقتش رو گذاشته تا باگی رو پیدا کنه که اصلاً وجود خارجی نداره! کد در ظاهر حرف نداشت؛ ساختار تمیز، رعایت تمام اصول و حتی کامنت‌های دقیق برای هر تابع. اما مشکل از جای عجیبی آب می‌خورد: یکی از تابع‌ها داشت مسئله‌ای رو حل می‌کرد که اصلاً کسی ازش نخواسته بود! Claude با اون دانشِ الگویابیِ بی‌پایانش، خودش تصمیم گرفته بود که اندپوینت API حتماً به صفحه‌بندی نیاز داره. در حالی که اصلاً نیازی بهش نبود. همین کدِ اضافه، ساختار پاسخ‌ها رو جوری بهم ریخته بود که دیباگ کردنش بیشتر از زمانی که آدم خودش کد رو از صفر بنویسه، طول کشید. این دقیقاً همون مشکل ۶۶ درصدیه. 📉 طبق آخرین نظرسنجی «استک اورفلو» از ۹۰ هزار برنامه‌نویس، ۶۶ درصدشون گفتن بزرگترین کلافگی‌شون با هوش مصنوعی اینه که کدها «تقریباً درستن، اما نه کاملاً». ۴۵ درصد دیگه هم معتقد بودن که عیب‌یابی کدهای هوش مصنوعی، اصلاً به زحمتش نمی‌ارزه. ابزارهایی که قرار بود سرعت ما رو بالا ببرن، یه مدل باگ جدید ساختن که تا چند سال پیش اصلاً نبود: باگی که ظاهرش کاملاً شبیه کد سالمه. داستان کدی که کلاً غلطه واضحه؛ ارور می‌ده، اجرا نمی‌شه و توی تست‌ها معلوم میشه. اما کدی که «تقریباً درسته» چی؟ این همون کدیه که تست‌ها رو پاس می‌کنه، می‌ره روی سرور و بعد ساعت ۲ نصفه‌شب، وقتی مشتری داره یه کاری انجام می‌ده، یهو یه رفتار عجیب و غریب از خودش نشون میده که کل سیستم رو می‌بره زیر سوال. 🐞 باگ‌های قدیمی صادق بودن و خودشون رو لو می‌دادن. اما این باگ‌های جدید خیلی مودب هستن؛ صبر می‌کنن تا در بدترین زمانِ ممکن غافلگیرت کنن. برنامه‌نویس‌های قدیمی هر اشتباهی که فکرش رو بکنی انجام دادن؛ از سوتی‌های امنیتی تا پاک کردن دیتابیس اصلی. اون‌ها اشتباهات خودشون بود و وقتی سیستم می‌ترکید، سریع می‌فهمیدن چی شده. چرخه بازخورد سریع بود: یه کار اشتباه انجام می‌دادی، سیستم اطلاع میداد و یاد می‌گرفتی دیگه تکرارش نکنی. 🤖 اما باگ‌های هوش مصنوعی اینطوری نیستن. الان وقتی چیزی خراب می‌شه، اولین سؤال این نیست که «من کجای کار رو اشتباه کردم؟»، بلکه اینه که «هوش مصنوعی چه کاری انجام داده که من متوجهش نشدم؟». این یه مدل کاملاً متفاوت از عیب‌یابی‌یه. به جای فهمیدن منطق خودت، باید فرضیات یکی دیگه رو مهندسی معکوس کنی. 🧑‍💻 تحقیقات مایکروسافت هم این رو تایید می‌کنه. مدل‌های هوش مصنوعی توی تست‌های عیب‌یابی واقعی، حتی بهترین‌شون مثل Claude 3.7 Sonnet، زیر ۵۰ درصد موفق بودن. این نشون می‌ده مدل‌ها در نوشتن کد عالی‌ان، اما در اصلاح کردنش بدجوری لنگ می‌زنن. 🧩 چرا؟ چون تولید کد برای هوش مصنوعی یعنی «تکمیل الگو». اون بر اساس میلیاردها نمونه، پیش‌بینی می‌کنه کلمات بعدی چی باشن. این برای کدهای تکراری عالیه، اما دیباگ کردن یعنی «تست کردن فرضیه‌ها». هوش مصنوعی نمی‌دونه چرا ساختار سیستم تو این شکلیه یا فلان قانون بیزنس که منطقی به نظر نمی‌رسه، چقدر حیاتیه. اون فقط الگوها رو می‌بینه و تکرار می‌کنه. ⚡️ یه آزمایش جالب نشون داده برنامه‌نویس‌هایی که از هوش مصنوعی استفاده کردن، ۱۹ درصد کندتر بودن، اما حس می‌کردن ۲۴ درصد سریع‌تر شدن! یعنی اون لذتِ سریع آماده شدنِ کد، باعث شده بود بدهی فنی که پشت سرشون جمع می‌شد رو نبینن. 👨‍💻 قرار نیست کسی استفاده از این ابزارها رو کنار بذاره. اما باید جوری بهشون نگاه کرد که انگار یه برنامه‌نویس تازه‌کار اون‌ها رو نوشته؛ کسی که خیلی به خودش مطمئنه ولی مهارتش معمولیه. مشکل این نیست که این ابزارها بد هستن؛ مشکل اینجاست که اون‌قدر خوب هستن که می‌تونن خطرناک باشن. چکشی که کلاً به میخ نخوره رو اعصابه، اما چکشی که «تقریباً» جای درست می‌خوره، آخرش یه خونه کج و معوج بهت تحویل می‌ده. فعلاً راه حل قطعی وجود نداره. شاید در آینده هوش مصنوعی یاد بگیره به جای فرض کردن، سوال بپرسه. اما تا اون موقع، بهتره برنامه‌نویس‌ها حواسشون به تست‌ها و کدهای خودشون باشه. بعضی مهارت‌ها رو نباید سپرد به ماشین؛ باید اون‌ها رو دقیق‌تر کرد. ✅ —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily

ترس از جا ماندن (FOMO) چیست و چگونه با آن کنار بیاییم؟ ۷ تمرین ساده برای آرامش ذهن لحظه‌ای را تصور کنید که وارد اینستاگرام شده‌اید و پست‌ها و استوری‌های دیگران را می‌بینید: دوستانی که به سفر خارج از کشور می‌روند، همکارانی که موفقیت‌هایی بزرگ را جشن می‌گیرند و غریبه‌هایی که به‌ نظر می‌رسد یک زندگی رویایی برای خود ساخته‌اند. ذهن‌تان بی‌اختیار شروع می‌کند به مقایسه: «چرا همه دارند پیشرفت می‌کنند و من هنوز تغییر ملموسی در زندگی‌ام ندیده‌ام؟». در این لحظه ترس عجیبی وجودتان را فرا می‌گیرد. این همان «ترس از جا ماندن» یا FOMO (مخفف Fear of Missing Out) است. اما واقعاً چرا ذهن ما مدام دست به مقایسه می‌زند و به این فکر می‌کند که اگر مانند دیگران زندگی می‌کردیم، خوشحال‌تر یا موفق‌تر می‌بودیم؟ البته این حس فقط محدود به شبکه‌های اجتماعی نیست. حتی در جمع دوستان هم وقتی همه از برنامه‌های آینده‌شان حرف می‌زنند، ممکن است از خودتان بپرسید: «پس چرا من هیچ برنامه‌ای ندارم؟» اما شبکه‌های اجتماعی این حس را تشدید می‌کنند. کافی‌ست در هر ساعتی از شبانه‌روز گوشی را بردارید و وارد اینستاگرام، ایکس یا تیک‌تاک شوید تا ببینید دیگران کجا هستند، با چه کسانی‌ ارتباط دارند و چه می‌کنند. فومو در زندگی روزمره شکل‌های متفاوتی دارد. گاهی دیدنِ ویدیوی یک جشن عروسی یا عکس یک مهمانی، فقط چند دقیقه ذهن‌تان را درگیر می‌کند. اما گاه این حس به یک «الگوی تکرارشونده» تبدیل می‌شود، یعنی مدام به سراغ گوشی می‌روید و نوتیفیکیشن‌ها، پیام‌ها و استوری‌های دیگران را می‌بینید. پس از آن‌ همه اسکرول‌ کردن، مضطرب می‌شوید. حتی حس حسادت‌تان برانگیخته می‌شود. ولی کمی بعد متوجه می‌شوید که چقدر زمان از دست داده‌اید و انرژی روانی‌تان تحلیل رفته است. ⛓ مطالعه ادامه مطلب در نوشدارو: https://nooshdaroo.ir/digital-literacy/fomo-coping-tips/ ✍️ آزاده رمضانی #سواد_دیجیتال #سلامت_روان نوشدارو را در تلگرام دنبال کنید: 💡 @NooshDaroo_web

خطای CORS باگ نیست؛ داره دقیقاً از وب‌اپلیکیشن شما محافظت می‌کنه. اگه با API کار کرده باشی، حتماً با این ارور اعصاب‌خُردکن برخورد کردی: پیغام Access to fetch has been blocked by CORS policy (مسدود شدن درخواست به‌خاطر سیاست CORS) آدرس درسته، کدت سالمه، اما مرورگر اجازه نمی‌ده. نکته مهم اینه: CORS خطا نیست؛ یه مکانیزم امنیتیه که درست داره کارش رو انجام می‌ده. بریم ببینیم داستان چیه 👇 اول اصل ماجرا: قانون SOP مرورگر یه قانون پایه داره به اسم Same-Origin Policy یا SOP (سیاست هم‌مبدأ). طبق این قانون، یه سایت فقط اجازه داره به پاسخِ درخواست‌هایی دسترسی داشته باشه که از همون مبدأ اومدن. پس CORS دقیقاً چی‌کار می‌کنه؟ حالا CORS (اشتراک‌گذاری منابع بین مبدأهای مختلف) راهیه که سرور می‌تونه به‌صورت کنترل‌شده به مرورگر بگه: «اوکیه، اجازه بده این مبدأ خاص به پاسخ من دسترسی داشته باشه.» پس CORS دشمن SOP نیست. یه جورایی مکمل هم دیگه هستن چرا اصلاً این محدودیت لازمه؟ (سناریوی بانک) فرض کن توی یه تب وارد حساب بانک شدی و لاگین هستی. کوکی‌ها (اطلاعات نشست کاربر) ذخیره شدن. حالا توی یه تب دیگه، یه سایت مخرب باز می‌کنی و این کد اجرا می‌شه: fetch("https://bank.com/api/balance") مرورگر ممکنه درخواست رو با کوکی‌های تو بفرسته، اما نکته حیاتی اینجاست: بدون CORS، سایت مخرب نباید بتونه پاسخ سرور رو بخونه. اینجا SOP و CORS وارد می‌شن و می‌گن: «درخواست شاید بره، ولی دسترسی به پاسخ ممنوعه.»

نکته: جمله دسترسی به پاسخ ممنوعه برای متدهای GET درسته اما برای متدهای تغییردهنده مثل POST یا DELETE که اثر جانبی (Side Effect) دارن، خطر اصلی ارسال خودِ درخواست وجود داره (نه فقط صرف دسترسی به پاسخ). برای همین Preflight Request درست شد تا از رسیدنِ درخواست‌های غیرایمن به سرور جلوگیری کنن، نه اینکه فقط جلوی خوندن پاسخ رو بگیره. که در ادامه بیشتر راجبش توضیح دادم.

نتیجه: اطلاعات حساس کاربر لو نمی‌ره. 🌐 دقیقاً "Origin" یا مبدأ یعنی چی؟ مبدأ یا Origin فقط دامین نیست. مرورگر سه چیز رو با هم چک می‌کنه: پروتکل (http یا https) هاست (نام دامنه مثل site.com) پورت (مثل 80، 443، 5173) اگه یکی فرق کنه، Origin فرق کرده: ❌ https://site.dev vs https://api.site.dev (هاست متفاوت) ❌ https://site.dev vs http://site.dev (پروتکل متفاوت) ❌ localhost:3000 vs localhost:8000 (پورت متفاوت) ✅ نکته: آدرس‌هایی مثل site.com/page1 و site.com/page2 چون فقط مسیر (Path) متفاوتی دارن، "Same-Origin" حساب میشن و مشکلی ندارن. 🤔 چرا توی Postman یا Curl کار می‌کنه ولی توی مرورگر نه؟ چون CORS فقط توسط مرورگر enforce می‌شه (اعمال می‌شه). حالا Postman و curl مشمول SOP نیستن. مهم نیست کوکی دارن یا نه؛ اصلاً این قوانین براشون وجود نداره. مرورگر اما جاییه که کدِ هزاران سایت مختلف کنار هم اجرا می‌شه، پس مجبورِ سخت‌گیر باشه. ✈️ داستان Preflight چیه؟ برای درخواست‌های حساس (مثل PUT، DELETE یا ارسال JSON)، مرورگر ریسک نمی‌کنه. اول یه درخواست OPTIONS (درخواست آزمایشی) می‌فرسته و از سرور می‌پرسه: «اجازه هست با این متد و این هدرها درخواست بدم؟» اگه سرور با هدرهای مناسب جواب بده، درخواست اصلی ارسال می‌شه. این فقط برای non-simple request (درخواست‌های غیرساده) اتفاق می‌افته؛ GETهای ساده معمولاً preflight ندارن. 🛠 چطور حلش کنیم؟ قاعده طلایی: مسئله CORS از فرانت‌اند (کد جاوااسکریپت سمت کاربر) قابل حل نیست. سروره که باید صریحاً بگه به کدوم Origin اجازه دسترسی می‌ده: Access-Control-Allow-Origin: https://my-app.com (دامنه مجاز)

⚠️ هشدار مهم: Wildcard (*) راه‌حل نیست یکی از رایج‌ترین اشتباه‌ها برای «حل» CORS اینه که روی سرور بنویسن: Access-Control-Allow-Origin: * این کار فقط در ساده‌ترین حالت‌ها بی‌خطره. به محض اینکه Credentials (کوکی، سشن، Authorization header) وارد بازی بشن، wildcard عملاً امنیت رو نابود می‌کنه. مرورگر حتی طبق استاندارد اجازه نمی‌ده * با Access-Control-Allow-Credentials: true هم‌زمان استفاده بشه، چون یعنی: «هر سایتی به اطلاعات احراز هویت‌شده‌ی کاربر دسترسی داشته باشه». راه درست اینه که Originها رو صریح و محدود تعریف کنی، نه اینکه در رو به روی همه باز بذاری و CORS اگر بد تنظیم بشه، دیگه مکانیزم امنیتی نیست میشه توهم امنیت.

در محیط توسعه، ابزارهایی مثل dev proxy فقط درخواست رو server-side (سمت سرور) می‌کنن و CORS رو دور نمی‌زنن، فقط مسیر درخواست رو عوض می‌کنن.

💡 حرف آخر دفعه بعد که ارور CORS دیدی، عصبی نشو. این مرورگره که داره از اطلاعات کاربر محافظت می‌کنه. راه‌حل همیشه ‌طرفه سرور. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily