type LayoutProps = {
children: React.ReactNode; // بهترین انتخاب برای دریافت هر نوع محتوا
};
export default function Layout({ children }: LayoutProps) {
return <main className="main-container">{children}</main>;
}
سناریوی دوم: محدود کردن خروجی به تگهای ساختاریافته (Best Practice: ReactElement) تصور کنید در حال ساخت کامپوننتی به نام List هستید و میخواید کاربر فقط و فقط تگهای <ListItem /> رو به عنوان فرزند ارسال کنه و اجازه نداشته باشه رشته متنی ساده یا عدد خالی بفرسته. در این سناریو، ReactElement انتخاب بهتری هست:
type ListProps = {
// کاربر نمیتواند متن ساده بفرستد، حتماً باید یک کامپوننت یا تگ معتبر باشد
children: React.ReactElement;
};
سناریوی سوم: تایپ‌دهی خروجی توابع یا هوکهای کاستوم (Best Practice: JSX.Element) اگر متدی نوشتید که وظیفهش تولید و برگردوندن یک قطعه کد HTML یا کامپوننت هستش، تعیین JSX.Element به عنوان تایپ خروجی، خوانایی کد شما رو بالا میبره و مشخص می‌کنه که خروجی این تابع یک سینتکس JSX هستش:
جمع‌بندی انتخاب درست بین این سه تایپ، بستگی به میزان سخت‌گیری یا انعطافپذیری لازم در کدهای شما داره. اگر دنبال انعطاف زیاد برای رندر انواع داده‌ها باشید، ReactNode انتخاب خوبیه. اما اگر میخواید ساختار رو محدود به آبجکتهای معتبر طراحی UI کنید، ReactElement و JSX.Element بهترین گزینهها هستن. شما در پروژه‌های خودتون بیشتر با کدوم از این تایپ‌ها سر و کار دارید؟ تا حالا به خاطر استفاده جابجا از اون‌ها به باگ‌های تایپاسکریپتی خوردید؟ تجربیات خودتون رو در بخش نظرات با ما در میون بذارید!
برای یک اپ ساده مشکلی نیست. برای یک اپ موبایل با شبکهی ضعیف که هر round-trip اضافه چند صد میلیثانیه هزینه دارد، همین چیزی است که کاربران را اذیت می‌کند.
GraphQL: یک endpoint، دقیقاً همون چیزی که خواستی
GraphQL همین مشکل را حل می‌کند با این ایده که فقط یک endpoint داشته باشی، و کلاینت دقیقاً مشخص کند چه فیلدهایی را می‌خواهد:
query {
user(id: 42) {
name
posts(limit: 5) { title }
followersCount
}
یک درخواست، دقیقاً داده‌ای که لازم داری، نه کمتر نه بیشتر. تیم‌های فرانت‌اند معمولاً عاشق این می‌شوند چون دیگر برای هر تغییر کوچک در UI نباید از بک‌اند بخواهند یک endpoint جدید بسازد.
اما این آزادی قیمتی دارد. همان مثال N+1 که اول گفتم: اگر برای هر post بخواهی اطلاعات نویسنده‌اش را هم بگیری، resolver پیش‌فرض می‌تواند به‌ازای هر پست یک کوئری جدا به دیتابیس بزند. ده پست یعنی ده کوئری اضافه. راه‌حلش وجود دارد (مثل DataLoader برای batch کردن)، ولی این یعنی یک لایه‌ی پیچیدگی که در REST اصلاً مجبور نبودی به آن فکر کنی. کش کردن هم سرراست نیست؛ چون همه‌چیز از یک endpoint با متد POST می‌آید، کش‌های HTTP معمولی که برای REST جا افتاده‌اند، اینجا کار نمی‌کنند و باید کش را خودت در سطح اپلیکیشن مدیریت کنی.
gRPC: وقتی سرعت بین سرویس‌ها مهم‌تر از خوانایی است
gRPC داستان متفاوتی دارد. این یکی اصلاً برای مرورگر طراحی نشده (هرچند gRPC-Web هم هست)؛ هدف اصلی‌اش ارتباط بین سرویس‌ها در یک سیستم میکروسرویس است. به‌جای JSON متنی، از Protocol Buffers استفاده می‌کند که باینری و فشرده است، و روی HTTP/2 کار می‌کند که چندین استریم را روی یک کانکشن همزمان می‌برد.
نتیجه‌اش سرعت است؛ هم در حجم داده، هم در latency. قیمتش این است که دیگر نمی‌توانی با مرورگر یا curl ساده پاسخ را بخوانی؛ باید فایل .proto را داشته باشی و کد را generate کنی. برای ارتباط بین دو سرویس داخلی که هیچ‌کدام انسان نیست که مستقیم پاسخ را بخواند، این مشکلی نیست. برای یک API عمومی که توسعه‌دهنده‌های بیرونی باید با آن کار کنند، احتمالاً تجربه‌ی بدتری می‌سازد.
پس کدوم رو انتخاب کنیم؟
اگر یک API عمومی یا نسبتاً ساده می‌سازی که کلاینت‌های مختلف (وب، موبایل، شاید حتی توسعه‌دهنده‌های بیرونی) با آن کار می‌کنند و نیازهای داده‌ای‌شان شبیه هم است، REST هنوز انتخاب امن‌تری است. کسی که برای اولین‌بار با APIات روبه‌رو می‌شود، سریع‌تر می‌فهمدش.
اگر چند کلاینت با نیازهای داده‌ای خیلی متفاوت داری (مثلاً اپ موبایل که می‌خواهد کمترین داده ممکن را بگیرد، و داشبورد ادمین که می‌خواهد همه‌چیز را یکجا ببیند)، GraphQL این مشکل را با هزینه‌ی پیچیدگی بیشتر در بک‌اند حل می‌کند. فقط حواست به N+1 باشد.
و اگر صحبت از ارتباط داخلی بین سرویس‌هاست، جایی که سرعت مهم‌تر از قابل‌خواندن‌بودن است، gRPC معمولاً برنده است.
نکته‌ی آخر: هیچ قانونی نمی‌گوید باید فقط یکی را انتخاب کنی. خیلی از سیستم‌های واقعی، REST را برای API عمومی نگه می‌دارند و gRPC را برای ارتباط داخلی بین سرویس‌ها به کار می‌برند. انتخاب درست همیشه یکی نیست؛ گاهی سه‌تاست، هر کدام جایی که واقعاً مزیت دارد.
ویژگی‌های کلیدی و انقلابی زبان Verse
اگر با زبان‌هایی مثل پایتون، سی‌شارپ یا جاوااسکریپت کار کرده باشید، در مواجهه با Verse با مفاهیم شگفت‌انگیزی روبرو خواهید شد که فرآیند توسعه را به شدت ایمن‌تر و لذت‌بخش‌تر می‌کنند.
۱. همه چیز یک «عبارت» است (Everything is an Expression)
در زبان‌های سنتی، ما بین دستورات (Statements - مانند حلقه‌ها که مقداری برنمی‌گردانند) و عبارات (Expressions - که مقدار تولید می‌کنند) تفاوت قائل می‌شویم. در Verse این مرز وجود ندارد؛ همه چیز یک عبارت است و یک مقدار تولید می‌کند.
به عنوان مثال، یک شرط ساده یا حتی یک حلقه در ورس می‌تواند مستقیماً به یک متغیر نسبت داده شود:
Result := if (Condition[]) then "yes" else "no"
Multiply := for (X : Array) { X * 42 }
این ویژگی باعث می‌شود کدها فوق‌العاده ترکیب‌پذیر (Composable) و خلاصه شوند.
۲. سیستم شکست به جای مقادیر بولی (Failure as Control Flow)
یکی از جذاب‌ترین بخش‌های فنی ورس، سیستم شکست (Failure System) آن است. در ورس چیزی به نام مقدار Boolean (True/False) سنتی برای کنترل جریان برنامه وجود ندارد. در عوض، عبارات یا «موفق» می‌شوند و مقداری را برمی‌گردانند، یا «شکست» می‌خورند.
توابعی که ممکن است شکست بخورند با براکت [] مشخص می‌شوند. اگر عبارتی در یک محیط failable (قابل شکست) اجرا شود و شکست بخورد، تغییرات آن بخش از کد به صورت خودکار به حالت قبل برمی‌گردد (Speculative Execution). این یعنی دیگر نیازی به نوشتن ساختارهای تکراری try-catch برای مدیریت خطاها ندارید.
۳. همزمانی ساختاریافته (Structured Concurrency)
برنامه‌نویسی بازی‌های آنلاین و چندنفره به شدت به مدیریت زمان و رویدادهای همزمان وابسته است. ورس با معرفی مفاهیمی چون sync ،race ،rush و branch برنامه‌نویسی ناهمگام (Async) را به بازیچه تبدیل کرده است. شما می‌توانید چندین کار را به طور همزمان اجرا کنید، مشخص کنید که کدام یک باید منتظر دیگری بماند، یا در صورت برنده شدن یک پردازش در مسابقه (race)، بقیه پردازش‌ها را فوراً لغو کنید؛ همه این‌ها بدون ریزش حافظه یا تداخل‌های رایج شبکه!
جایگاه Verse در اکوسیستم Unreal Editor for Fortnite (UEFN)
در حال حاضر، دروازه ورود به دنیای ورس، ابزار UEFN یا همان محیط توسعه فورتنایت است. پیش از این، کاربران در بخش Fortnite Creative تنها می‌توانستند دستگاه‌های بازی (Devices) را با خطوط بصری و محدود به هم متصل کنند. اما ورس به شما قدرت مطلق می‌دهد.
با استفاده از Verse در UEFN می‌توانید:
تعاملات پیچیده بسازید: رفتار بازیکنان، قوانین بازی و محیط را با دقت میلی‌ثانیه‌ای کنترل کنید.
منطق‌های داینامیک خلق کنید: بازی‌هایی بسازید که بر اساس وضعیت فعلی جهان بازی یا مشخصات بازیکن، به صورت زنده تغییر می‌کنند.
محدودیت ابزارهای بصری را بشکنید: ساخت سیستم‌های امتیازدهی پیشرفته، هوش مصنوعی شخصی‌سازی‌شده برای NPCها و مکانیزم‌های خلاقانه که تا پیش از این غیرممکن بود.
مقایسه اجمالی: Verse در برابر زبان‌های دیگر
ویژگی
زبان Verse
زبان‌های سنتی (C++/C#)
هدف اصلی
شبیه‌سازی متاورس و بازی
توسعه عمومی و سیستم
مدیریت خطا
سیستم شکست (Failure Contexts)
استثناها (Exceptions / Try-Catch)
نوع پارادایم
تابعی - منطقی - امری
شیءگرا یا امری
امنیت شبکه
بالا و بومی (بدون Desync)
نیازمند کدنوسی دستی پیچیده
چگونه یادگیری Verse را شروع کنیم؟
برای شروع یادگیری این زبان، نیازی نیست یک برنامه‌نویس باسابقه باشید. اپیک گیمز مستندات آموزشی خود را به گونه‌ای طراحی کرده که حتی افراد بدون تجربه برنامه‌نویسی نیز بتوانند از آن بهره‌مند شوند.
گام اول: نصب ابزارها
ابتدا باید نرم‌افزار Epic Games Launcher را نصب کرده و از درون آن Unreal Editor for Fortnite (UEFN) را دریافت کنید. ورس به صورت بومی در این ادیتور ادغام شده است.
گام دوم: استفاده از قالب‌های آماده (Templates)
مستندات رسمی اپیک گیمز شامل پروژه‌های آماده‌ای مانند Verse Starter Template است. با باز کردن این پروژه‌ها، می‌توانید کدهای نوشته شده برای هدایت یک NPC یا تغییر یک دستگاه در بازی را ببینید، آن‌ها را دستکاری کنید و نتیجه را فوراً در بازی مشاهده کنید.
گام سوم: مطالعه منبع اصلی (Book of Verse)
اگر برنامه‌نویس هستید و می‌خواهید مستقیماً به سراغ مفاهیم عمیق مانند سیستم افکت‌ها (Effects)، کلاسیفیکیشن تایپ‌ها (Type System) و مدیریت حافظه بروید، کتاب آنلاین ورس (Book of Verse) که در آدرس verselang.github.io/book در دسترس است، بهترین و دقیق‌ترین مرجع برای شماست.
آینده زبان Verse؛ فراتر از فورتنایت
شاید بپرسید: «آیا ارزش دارد زبانی را یاد بگیرم که فقط در فورتنایت کاربرد دارد؟» پاسخ کوتاه این است: ورس محدود به فورتنایت نخواهد ماند.
تیم سویینی (مدیرعامل اپیک گیمز) بارها اشاره کرده است که هدف نهایی ورس، تبدیل شدن به زبان استاندارد موتور بازی‌سازی Unreal Engine و در نهایت کل اینترنت سه‌بعدی است. پتانسیل این زبان در هندل کردن پروژه‌های MMO (بازی‌های آنلاین انبوه) با هزاران بازیکن در یک سرور واحد، بدون ناهماهنگی (Desync)، توجه بسیاری از نظریه‌پردازان زبان‌های برنامه‌نویسی را جلب کرده است.
کلام آخر
زبان برنامه‌نویسی Verse مرزهای سنتی میان کدنویسی سخت‌گیرانه و خلاقیت در بازی‌سازی را جابه‌جا کرده است. چه یک بازی‌ساز مستقل باشید که می‌خواهد مپ‌های درآمدزا در فورتنایت خلق کند، و چه یک مهندس نرم‌افزار کنجکاو که به دنبال کشف پارادایم‌های نوین برنامه‌نویسی است، ورس ابزاری است که نباید از آن غافل شوید. رویای متاورس در حال ساختن است و خطوط کد آن، با زبان ورس نوشته می‌شوند. همین امروز یادگیری آن را شروع کنید!
و سیستم محبوب
Blueprints
را کنار می‌گذارد تا زبان جدید
Verse
را جایگزین کند.
اقتصاد و داراییهای مشترک (Interoperability): شاید عجیبترین بخش خبر این باشد که در UE6، کدهای برنامه‌نویسی و آیتمهای درون بازی (مثل اسکینها) قابلیت جابهجایی بین بازی‌های مختلف را دارند!اپیک تایید کرده که در اولین قدم، بازیکنان می‌توانند اسکینهای فورتنایت خود را به بازی‌های ساختهشده با UE6 ببرند و برعکس.
تزریق هوش مصنوعی مولد به رگهای موتور: با پشتیبانی از پروتکل MCP (مخفف Model Context Protocol)، توسعه‌دهندگان می‌توانند از هوش مصنوعیهای محبوبی مثل Claude و Gemini مستقیماً درون ابزار توسعه استفاده کنند تا کارهای تکراری و زمانبر حذف شوند و سرعت ساخت بازی‌ها چند برابر شود.
پشتیبانی باورنکردنی از سختافزارهای ضعیفتر: در حاشیه این رویداد، نسخه جدید UE 5.8 نیز منتشر شد که به عنوان پل پیشدرآمدی برای UE6 عمل می‌کند.فناوری نورپردازی Lumen حالا بهینه‌سازی شده تا بازی‌های سنگین بتوانند روی سختافزارهای ضعیفتری مثل کنسول Nintendo Switch 2 یا پیسیهای اقتصادی با نرخ 60 فریم بر ثانیه اجرا شوند.
این موضوع چه سودی برای ما (گیمرها) دارد؟
برای کاربر نهایی، این یعنی پایان دوران انتظار ۴ یا ۵ ساله برای ساخت بازی‌های بزرگ (AAA). بازی‌ها با کمک هوش مصنوعی و کدهای بهینه‌تر بسیار سریع‌تر ساخته می‌شوند، آپدیت‌ها فورا و بدون دانلودهای حجیم روی سرورها اعمال می‌شوند و از همه جذاب‌تر، پول و زمانی که برای خرید آیتم در یک بازی صرف کرده‌اید، در بازی‌های دیگرِ این اکوسیستم هم ارزش خواهد داشت.
تحلیل کوتاه (Peer Insight)
معرفی Unreal Engine 6 نشان می‌دهد که نگاه «تیم سوئینی» (مدیرعامل اپیک) به آینده صنعت گیم، فراتر از فروش بازی‌های مجزای خطی است. اپیک با این حرکت عملاً در حال ساخت زیرساختِ یک مِتاورس واقعی و کاربردی است؛ جایی که فورتنایت دیگر فقط یک بازی بتل‌رویال نیست، بلکه سیستم‌عاملِ بازی‌های آینده است. این انحصار و یکپارچگیِ بی‌نظیر، زنگ خطر بزرگی را برای رقبایی مثل موتور بازی‌سازی Unity به صدا درمی‌آورد.
نسخه دسترسی زودهنگام (Early Access) این موتور قدرتمند برای اواخر سال ۲۰۲۷ برنامه‌ریزی شده است، بنابراین تا دیدن اولین بازی‌های تماماً ساختِ UE6 هنوز چند سالی فاصله داریم.
interface Client {
name: string;
}
interface Client {
age: number;
}
// ادغام خودکار: حالا کلاینت هر دو فیلد را دارد
const newClient: Client = {
name: "Ali",
age: 25
};
اگر همین کار رو با type انجام بدید، بلافاصله با خطای دیتای تکراری (Duplicate identifier) مواجه می‌شد. این ویژگیِ interface برای زمانهایی که میخواید برای یک کتابخانه اکسترنال (مثل اضافه کردن فیلد به درخواست‌های Express یا تنظیمات تلویند) متغیر جدیدی اضافه کنید، حیاتیه. ۲. انواع دادههای غیر شیء یا Primitive Types (کدوم بهتره: Type) یک interface فقط و فقط می‌تونه شکل یک شیء (Object) یا تابع (Function) رو مشخص کنه. اما کلمه کلیدی type بسیار انعطافپذیرتره و می‌تونه برای تعریف انواع الیاسها (Aliases)، تایپهای ترکیبی (Union) یا چندوجهی (Intersection) استفاده شه:
// Union Types (تعریف تایپی که می‌تواند یکی از چند حالت باشد)
type Status = "pending" | "approved" | "rejected";
type ID = string | number;
// Tuple (آرایه‌ای با طول و تایپ مشخص)
type Point = [number, number];
انجام کارهای بالا با interface غیرممکنه. ۳. نحوه ارث‌بری و گسترش کد (Extending) هر دو ابزار روش خاص خودشون رو برای گسترش دادن تایپ‌ها دارن. interface از کلمه کلیدی extends استفاده می‌کنه که از نظر فکری به شیءگرایی (OOP) نزدیکتره، در حالی که type از عملگر & (Intersection) استفاده می‌کنه:
// گسترش با Interface
interface Animal { name: string; }
interface Bear extends Animal { honey: boolean; }
// گسترش با Type
type AnimalType = { name: string; };
type BearType = AnimalType & { honey: boolean; };
بالاخره چه زمانی از کدوم استفاده کنیم؟ (Best Practices) امروز تو دنیای توسعه وب، توافقهای نانوشته اما استانداردی شکل گرفته که بر اساس اون‌ها میشه از فرمول زیر برای پروژه‌ها به استفاده کرد: از Type استفاده کنید اگر: •در حال طراحی کامپوننت‌های فرانت‌اند (مثل Props در ری‌اکت و نکست) هستید؛ چون تایپ‌ها برای این کار تمیزترن، جلوی ادغامهای ناخواسته رو میگیرن و کار با قابلیت‌های کامپوننت رو راحت‌تر می‌کنن. •نیاز به تعریف Union Types دارید (مثلاً وضعیتهای یک دکمه یا کامپوننت: 'primary' | 'secondary' | 'danger'). •میخواید رفتارهای پیچیده‌ای مثل کدهای داینامیک، تایپهای شرطی (Conditional Types) یا الیاسهای ساده برای کدهای پایه (Primitives) بسازید. از Interface استفاده کنید اگر: •ساختار دادههای دیتابیس، مدل‌ها یا API (مثل خروجیهای Prisma یا آبجکتهای سمت بکآند) رو تعریف می‌کنید که فرمت کاملاً شیءگرا دارن. •در حال نوشتن یک کتابخانه (Library) یا بسته نرم‌افزاری هستید و میخواید دیگران بتونن با قابلیت Declaration Merging، ویژگی‌های جدیدی به متغیرهای شما اضافه کنن و اون رو گسترش بدن.
Ctrl + S
Cmd + S
.scss
.scss
settings.json
"scss.lint.unknownAtRules": "ignore"
نکته: اگر تو پروژه‌های مختلفتون هم از CSS معمولی و هم از SCSS استفاده می‌کنید، می‌تونید هر دو خط کد رو در فایل تنظیمات قرار بدید تا این خطا تو هیچکدوم از فایل‌ها تکرار نشه.
جمع‌بندی گاهی اوقات هشدارهای پیشفرضِ ابزارهای توسعه، برای کدهای مدرن بهینه‌سازی نشدن و باعث شلوغی محیط کدنویسی میشن. با انجام این تغییر ساده، ادیتورتون رو جوری شخصی‌سازی کردید که تنها خطاهای واقعی و ساختاری کد رو به شما نشون میده. شما برای حل این مشکل از چه روشی استفاده میکردید؟
تصور کنید طراح پروژه، یک رنگ اصلی (Primary Color) به شما داده که قراره در دکمه‌ها و لینک‌ها ازش استفاده کنید. خب، این المان‌ها قطعاً به حالت Hover (وقتی موس روی اون‌ها میر‌ه) نیاز دارن.
یک راه این هستش که رنگ اصلی رو در سایت oklch.com وارد کنید و فقط با کم و زیاد کردن بخش Lightness (روشنایی)، خیلی راحت نسخه‌های تاریک‌تر یا روشن‌ترِ همون رنگ رو برای Hover بسازید.
راه دوم که پیشنهاد میشه افزونه OKLChanger در VS Code هست:
برای اینکه مدام بین مرورگر و ادیتور جابجا نشید: ۱. افزونه OKLChanger رو در VS Code نصب کنید. ۲. در فایل استایل خود (مثلاً global.css در پروژه‌های Next.js) رنگ Hex خودتون رو بنویسید:
:root {
--color-primary: #3b82f6;
}
۳. کد رنگ رو با موس انتخاب کنید و کلیدهای Ctrl+Shift+P (در مک Cmd+Shift+P) رو بزنید. ۴. عبارت OKLChanger رو سرچ و اینتر کنید تا رنگ شما به فرمت OKLCH تبدیل بشه. به همین راحتی!
قسمت اصلی: ترکیب OKLCH با تابع color-mix
حالا چطور با این کار حجم باندل پروژه رو کم کنیم؟ جواب ساده است: با کمک تابع color-mix در CSS. با این فانکشن دیگه نیازی نیست برای هر حالت Hover یک متغیر رنگی جدید تعریف کنید؛ بلکه همه‌چیز رو به صورت داینامیک در خودِ مرورگر ترکیب می‌کنید!
به این کد نگاه کنید:
:root {
--color-primary: oklch(0.63 0.25 258.2); /* رنگ اصلی */
/* ساخت رنگ به صورت داینامیک */
--primary-hover: color-mix(in oklch, var(--color-primary), black 7%);
}
این تابع دقیقاً چطور کار می‌کنه؟
فرمولش خیلی ساده است: color-mix(فضای رنگی, رنگ اصلی شما, رنگی که می‌خواهید با آن مخلوط شود + درصد آن)
در مثال بالا، ما به مرورگر گفتیم: «در فضای رنگی oklch، رنگ اصلی ما رو با ۷٪ رنگ مشکی ترکیب کن». نتیجه؟ یک رنگ تیره تر و اصولی برای حالت Hover، بدون اینکه خط کد اضافی بنویسیم یا کلی متغیر جدید بسازیم. این یعنی کد کمتر، فایل خلوتتر و در نتیجه کاهش حجم باندل!
یک ایده برای خلاقیت: شما مجبور نیستید فقط از سیاه و سفید برای ترکیب استفاده کنید! در پروژه‌های شخصی یا کارهای خلاقانه می‌تونید رنگ اصلیتون رو با رنگهای دیگر (مثلاً کمی زرد یا آبی) ترکیب کنید تا افکتهای جدیدی خلق کنید؛ البته در پروژه‌های رسمی شرکتی بهتره خیلی ریسک نکنید و به همون تیره و روشن کردن بسنده کنید.
خبر خوب: سازگاری کامل با Tailwind CSS!
خبر خوب اینه که این روش کاملاً با Tailwind سازگاره!
به‌خصوص در نسخه‌های جدید تیلوند، شما می‌تونید خیلی راحت این متغیرها رو توی دایرکتیو @theme معرفی کنید تا کلاسهای داینامیکی مثل bg-primary و hover:bg-primary-hover رو در اختیارتون بذاره:
با این کار، تیلوند به طور خودکار متغیرهای بومی CSS شما رو میشناسه و بدون هیچ پکیج یا ابزار اضافی، قدرت OKLCH و color-mix رو مستقیم وارد کامپوننتهاتون می‌کنه.
جمع‌بندی
استفاده از OKLCH و color-mix دست شما رو برای نوشتن کدهای CSS تمیزتر، هوشمندتر و بهینه‌تر باز میذاره. با این روش، تغییر تم (Theme) سایت در آینده هم خیلی راحت میشه و دیگه نیازی به تعریف کردن چندین رنگ تکراری ندارید.
شما تا حالا از این قابلیت‌های مدرن CSS در پروژه‌هاتون استفاده کردید؟ تجربه یا سوالی دارید؟ در بخش کامنتها منتظرتون هستیم!
قطعی سرویس:
سایر مدل‌ها امن هستند: خبر خوب این است که دسترسی به بقیه مدل‌های قدیمیتر و استاندارد آنتروپیک (مثل نسخه‌های مختلف کلاود) هیچ تغییری نکرده و مثل قبل کار می‌کنند.
پافشاری بر حریم خصوصی: آنتروپیک پیش از این برای بررسی همین حملات، سیاست ذخیره ۳۰ روزه دادههای کاربران را وضع کرده بود که صدای خیلی‌ها را درآورد؛ حالا مشخص شد این کار برای دفاع چندلایه در برابر چنین روزهایی بوده است.
ویژگی‌های امنیتی Fable 5 از زبان آنتروپیک
آنتروپیک سفت و سخت پای لایه‌های امنیتی محصولش ایستاده و می‌گوید قبل از عرضه، هزاران ساعت تست نفوذ (Red-Teaming) با همکاری دولت آمریکا و سازمان امنیت هوش مصنوعی بریتانیا (UK AISI) انجام داده است. ویژگی‌های این سیستم عبارت بودند از:
سخت‌گیری شدید: لایه‌های حفاظتی این مدل آن‌قدر قوی طراحی شده بودند که بسیاری از کاربران عادی از محدودیت‌های زیاد آن شکایت داشتند.
نبود جیلبریک همه‌جانبه: تا این لحظه هیچ هکر یا تستر امنیتی نتوانسته یک «جیلبریک جهانی» (Universal Jailbreak) پیدا کند که تمام قفل‌های سیستم را یکجا باز کند.
استراتژی دفاع چندلایه (Defense in Depth): آنتروپیک معتقد است هوش مصنوعی بی‌نقص وجود ندارد؛ بنابراین استراتژی آن‌ها سخت کردن و گران کردن فرآیند هک برای نفوذگرها بوده، نه ادعای امنیت ۱۰۰ درصدی.
تحلیل کوتاه
این اقدام دولت آمریکا یک زنگ خطر جدی و یک نقطه عطف در تاریخ هوش مصنوعی است. تا پیش از این، دولت‌ها بیشتر در حد توصیه و بیانیه با شرکت‌های بزرگ فناوری تعامل می‌کردند، اما این «احضار و توقیف» ناگهانی نشان می‌دهد که کاخ سفید تعارفی با حوزه فناوری ندارد. نکته نگران‌کننده اینجاست: همان‌طور که آنتروپیک اشاره کرده، اگر استاندارد دولت برای توقیف یک مدل، پیدا شدن یک باگ یا جیلبریک جزیی و محدود باشد، از این به بعد باید منتظر توقف پی‌درپی و زنجیره‌ای تمام مدل‌های پیشرو (Frontier Models) در دنیا باشیم؛ اتفاقی که می‌تواند چرخ توسعه هوش مصنوعی را به شدت کند، یا حتی متوقف کند. آنتروپیک اعلام کرده که این یک سوءتفاهم بزرگ است و در حال رایزنی برای بازگرداندن این دو مدل است، اما بازی قدرت میان رگولاتورها و توسعه‌دهندگان تازه وارد فاز جدی خود شده است.
چرا ریورس پراکسی اینقدر مهم است؟
در یک محیط پروداکشن واقعی، ریورس پراکسی وظایف زیادی به عهده می‌گیرد:
SSL Termination: مدیریت گواهینامه HTTPS در یک جا متمرکز می‌شود. سرویس‌های پشتی می‌توانند بدون SSL روی شبکه داخلی کار کنند.
Load Balancing: ترافیک بین چند نمونه از یک سرویس تقسیم می‌شود تا هیچ کدام اشباع نشوند.
Caching: پاسخ‌های تکراری ذخیره می‌شوند تا سرور اصلی بار کمتری داشته باشد.
Static File Serving: فایل‌های CSS، JS و تصاویر مستقیم از ریورس پراکسی سرو می‌شوند بدون اینکه سرور برنامه اصلی درگیر شود.
Security: آدرس و پورت سرورهای اصلی از کاربر پنهان می‌ماند. می‌توان rate limiting و فیلتر IP را در این لایه اعمال کرد.
Logging: تمام درخواست‌ها در یک نقطه لاگ می‌شوند.
چرا Nginx؟
Nginx (تلفظ: انجین-ایکس) یک وب‌سرور با کارایی بالاست که به عنوان ریورس پراکسی هم استفاده می‌شود. در سال ۲۰۰۴ توسط Igor Sysoev ساخته شد و امروز بیش از ۳۴ درصد از وب‌سرورهای دنیا از آن استفاده می‌کنند.
دلیل محبوبیتش ساختار event-driven آن است. برخلاف Apache که برای هر درخواست یک thread جدید باز می‌کند، Nginx می‌تواند هزاران اتصال همزمان را با منابع کم مدیریت کند.
گزینه‌های دیگری مثل Apache، Caddy، Traefik و HAProxy هم وجود دارند که هرکدام کاربرد خودشان را دارند. اما Nginx به دلیل پرفورمنس بالا، مستندات غنی و جامعه بزرگ، رایج‌ترین انتخاب برای محیط‌های پروداکشن است.
راه‌اندازی عملی: از صفر تا پروداکشن
محیط ما
فرض می‌کنیم یک سرور Ubuntu 22.04 داریم و می‌خواهیم:
یک اپ Node.js روی پورت 3000 داریم
یک اپ Python/FastAPI روی پورت 8000 داریم
دامنه example.com را داریم
می‌خواهیم SSL داشته باشیم
می‌خواهیم استاتیک فایل‌ها بهینه سرو شوند
مرحله اول: نصب Nginx
sudo apt update
sudo apt install nginx -y
# بررسی وضعیت سرویس
sudo systemctl status nginx
# اگر اجرا نیست:
sudo systemctl start nginx
sudo systemctl enable nginx
بعد از نصب، با رفتن به آدرس IP سرور باید صفحه پیش‌فرض Nginx را ببینید.
مرحله دوم: آشنایی با ساختار فایل‌های Nginx
/etc/nginx/
├── nginx.conf ← فایل اصلی تنظیمات
├── sites-available/ ← تنظیمات سایت‌ها (غیرفعال)
├── sites-enabled/ ← تنظیمات فعال (لینک به sites-available)
├── conf.d/ ← فایل‌های تنظیمات اضافی
└── snippets/ ← قطعههای قابل استفاده مجدد
فلسفه کار این است که تنظیمات را در sites-available می‌نویسید و با یک symlink در sites-enabled فعالشان می‌کنید. این باعث می‌شود بتوانید سایت‌ها را راحت فعال و غیرفعال کنید.
مرحله سوم: اولین تنظیم ریورس پراکسی
یک فایل تنظیمات برای اپ Node.js بسازیم:
sudo nano /etc/nginx/sites-available/myapp
server {
listen80;
server_name example.com www.example.com;
# لاگ‌های اختصاصی این سایتaccess_log /var/log/nginx/myapp_access.log;
error_log /var/log/nginx/myapp_error.log;
location / {
proxy_pass http://localhost:3000;
proxy_http_version1.1;
# هدرهای ضروری برای ریورس پراکسیproxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# برای WebSocket اگر استفاده می‌کنیدproxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
}
حالا آن را فعال می‌کنیم:
sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
# بررسی صحت تنظیمات - این دستور را قبل از هر reload اجرا کنید
sudo nginx -t
# اعمال تغییرات
sudo systemctl reload nginx
چرا آن هدرها ضروری هستند؟
proxy_set_header Host $host: بدون این، سرور اصلی نمی‌داند درخواست برای کدام دامنه آمده.
X-Real-IP و X-Forwarded-For: چون ریورس پراکسی جلوی سرور است، IP کلاینت در سرور اصلی به درستی نمایش داده نشده است. این هدرها IP واقعی کاربر را انتقال می‌دهند.
X-Forwarded-Proto: به سرور اصلی می‌گوید کلاینت با HTTP آمده یا HTTPS. بدون این، اگر HTTPS داشته باشید و redirect تولید کنید، ممکن است loop ایجاد شود.
مرحله چهارم: مدیریت چند سرویس
حالا فرض کنید می‌خواهید هم اپ Node.js و هم اپ Python داشته باشید، هر کدام زیر یک مسیر مختلف:
یک نکته مهم: توجه به slash آخر در proxy_pass http://localhost:8000/ مهم است. وقتی slash دارد، مسیر /api/users به /users تبدیل می‌شود. اگر slash نباشد، به /api/users ارسال می‌شود.
تجدید خودکار گواهینامه هم از قبل تنظیم شده. می‌توانید با این دستور بررسی کنید:
sudo certbot renew --dry-run
تنظیمات پروداکشن که اغلب نادیده گرفته می‌شوند
بهینه‌سازی فایل اصلی nginx.conf
# /etc/nginx/nginx.confuser www-data;
# معمولاً برابر با تعداد هستههای CPUworker_processes auto;
events {
# حداکثر اتصال همزمان هر workerworker_connections1024;
useepoll;
multi_accepton;
}
http {
# پنهان کردن نسخه Nginx در هدرهاserver_tokensoff;
# بهینه‌سازی ارسال فایلsendfileon;
tcp_nopushon;
tcp_nodelayon;
# فشردهسازی پاسخهاgzipon;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length1000;
gzip_varyon;
# timeoutهای مناسبkeepalive_timeout65;
client_max_body_size10M;
# هدرهای امنیتیadd_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Rate Limiting
جلوگیری از درخواست‌های بیش از حد یک کلاینت:
http {
# تعریف zone برای rate limiting# zone=api: اسم zone# 10m: ۱۰ مگابایت حافظه برای ذخیره IPها# rate=10r/s: حداکثر ۱۰ درخواست در ثانیهlimit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
proxy_pass http://localhost:3000;
}
location /login {
limit_req zone=login burst=3;
proxy_pass http://localhost:3000;
}
}
}
burst=20 یعنی اگر ناگهان ۲۰ درخواست آمد قبول می‌شود، اما بعدش باید به نرخ عادی برگردد.
Load Balancing واقعی
http {
# تعریف upstream با چند سرورupstream nodejs_backend {
# روش پیش‌فرض: round robinserver localhost:3000;
server localhost:3001;
server localhost:3002;
# keepalive برای بهبود پرفورمنسkeepalive32;
}
# یا با وزندهی (اگر یک سرور قویتر است)upstream weighted_backend {
server server1.internal weight=3;
server server2.internal weight=1;
}
# ip_hash: هر کاربر همیشه به یک سرور می‌رود (مفید برای session)upstream sticky_backend {
ip_hash;
server server1.internal;
server server2.internal;
}
server {
location / {
proxy_pass http://nodejs_backend;
proxy_http_version1.1;
proxy_set_header Connection "";
}
}
}
Caching برای API
http {
# تعریف cache zoneproxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m
max_size=1g inactive=60m use_temp_path=off;
server {
location /api/public/ {
proxy_cache api_cache;
proxy_cache_valid20010m;
proxy_cache_valid4041m;
# هدری که نشان می‌دهد پاسخ از cache آمده یا نهadd_header X-Cache-Status $upstream_cache_status;
proxy_pass http://localhost:3000;
}
}
}
یک سناریوی کامل پروداکشن
بگذارید همه چیز را در یک تنظیم واقعی کنار هم بگذاریم. فرض می‌کنیم یک استارتاپ داریم با:
# بررسی صحت تنظیمات
sudo nginx -t
# reload بدون قطع اتصالات فعال
sudo systemctl reload nginx
# بررسی لاگ‌های خطا به صورت real-time
sudo tail -f /var/log/nginx/error.log
# بررسی اتصالات فعال
sudo nginx -s status
# نمایش تنظیمات کامل بعد از include
sudo nginx -T
# بررسی اینکه کدام فایل تنظیمات اعمال شده
sudo nginx -T | grep server_name
خطاهای رایج
502 Bad Gateway: سرور اصلی در دسترس نیست یا crash کرده. ابتدا بررسی کنید آیا سرویس روی پورت مورد نظر اجرا است:
504 Gateway Timeout: درخواست خیلی طول کشیده. proxy_read_timeout را افزایش دهید یا مشکل سرور اصلی را پیدا کنید.
413 Request Entity Too Large:client_max_body_size را افزایش دهید.
WebSocket کار نمی‌کند: هدرهای Upgrade و Connection را بررسی کنید.
Nginx در برابر رقبا
Nginx در برابر Apache
Apache مدل process-based دارد و برای هر اتصال یک thread باز می‌کند. این در ترافیک بالا منابع زیادی مصرف می‌کند. Nginx با مدل event-driven چندین هزار اتصال را با یک worker process مدیریت می‌کند. اما Apache مزیت‌هایی هم دارد: .htaccess که اجازه می‌دهد تنظیمات در سطح دایرکتوری تعریف شوند، و پشتیبانی بهتر از برخی فناوری‌های قدیمی مثل mod_php.
Nginx در برابر Caddy
Caddy یک رقیب جدیدتر است که SSL را به صورت خودکار مدیریت می‌کند. تنظیمات آن ساده‌تر است اما کانفیگ Nginx انعطاف و کنترل بیشتری می‌دهد. برای تیم‌های کوچک که می‌خواهند سریع راه بیافتند، Caddy گزینه خوبی است.
Nginx در برابر Traefik
Traefik برای محیط‌های container-native (Kubernetes، Docker Swarm) طراحی شده و کشف خودکار سرویس‌ها را پشتیبانی می‌کند. اگر با Kubernetes کار می‌کنید، Traefik یا ingress-nginx انتخاب‌های بهتری هستند.
مزایا و معایب این رویکرد
مزایا
ریورس پراکسی لایه‌ای از انتزاع بین کاربر و زیرساخت ایجاد می‌کند. می‌توانید سرورهای پشتی را بدون اطلاع کاربر تغییر دهید. SSL در یک جا مدیریت می‌شود. پرفورمنس بهتری برای فایل‌های استاتیک دارید. امنیت بیشتری دارید چون سرورهای اصلی مستقیم در معرض اینترنت نیستند.
معایب
یک لایه پیچیدگی اضافه می‌شود. دیباگ کردن مشکلات شبکه کمی سخت‌تر می‌شود چون باید مطمئن شوید مشکل از Nginx است یا سرویس پشتی. اگر Nginx crash کند، همه چیز از کار می‌افتد (که با high availability می‌توان حل کرد).
جمع‌بندی
ریورس پراکسی دیگر یک گزینه اختیاری نیست. هر اپلیکیشنی که می‌خواهد به شکل جدی در پروداکشن باشد، به آن نیاز دارد.
Nginx به خاطر پرفورمنس، انعطاف و جامعه بزرگ استانداردترین انتخاب برای این کار است. تنظیم‌هایی که در این مقاله دیدیم، پایه‌ای هستند که در اکثر محیط‌های واقعی استفاده می‌شوند.
نظر شخصی: اگر تازه شروع می‌کنید، با یک تنظیم ساده شروع کنید و کم‌کم گسترش دهید. سعی نکنید از ابتدا همه چیز را کامل کنید. اما حتماً از همان ابتدا SSL داشته باشید و هدرهای پراکسی را درست تنظیم کنید، این دو مورد را نمی‌توانید بعداً راحت اضافه کنید بدون اینکه کارها خراب شود.
سوالات متداول
آیا می‌توانم بدون Nginx هم اپلیکیشن را deploy کنم؟ بله، می‌توانید اپلیکیشن را مستقیم روی پورت 80 یا 443 اجرا کنید. اما در عمل این کار مشکلاتی دارد: SSL مدیریت کردن سخت‌تر است، نمی‌توانید چند سرویس روی یک IP داشته باشید، و پرفورمنس سرو فایل‌های استاتیک کمتر است.
تفاوت proxy_pass http://localhost:3000 و proxy_pass http://localhost:3000/ چیست؟ وقتی slash آخر هست، مسیر از URL حذف می‌شود. مثلاً location /api/ با proxy_pass http://localhost:3000/ یعنی /api/users به /users تبدیل می‌شود. بدون slash، مسیر کامل منتقل می‌شود.
چطور بفهمم Nginx درست کانفیگ شده؟ با دستور sudo nginx -t صحت syntax را بررسی کنید. بعد با ابزاری مثل curl -v هدرهای پاسخ را بررسی کنید و ببینید هدر Server چه می‌گوید و هدرهایی که تنظیم کرده‌اید وجود دارند یا نه.
آیا Nginx برای WebSocket مناسب است؟ بله، اما باید هدرهای Upgrade و Connection را تنظیم کنید و proxy_read_timeout را بالا ببرید چون اتصالات WebSocket طولانی‌مدت هستند.
چطور یک سرور Nginx را بدون downtime ریستارت کنم؟ از sudo systemctl reload nginx یا sudo nginx -s reload استفاده کنید. این دستورها کانفیگ جدید را بارگذاری می‌کنند بدون اینکه اتصالات فعال قطع شوند.
آیا Nginx می‌تواند جایگزین یک load balancer سخت‌افزاری شود؟ برای اکثر پروژه‌ها بله. Nginx در محیط‌هایی با صدها هزار درخواست در ثانیه هم به خوبی کار می‌کند. تنها در مقیاس‌های بسیار بزرگ (میلیون‌ها درخواست در ثانیه) ممکن است به راه‌حل‌های تخصصی‌تر نیاز باشد.
اما این قدرت بیشتر با یک مکانیزم امنیتی همراه شده است. Fable 5 از سیستمی به نام classifier استفاده می‌کند — مجموعه‌ای از مدل‌های هوش مصنوعی جداگانه که درخواست‌های بالقوه مخرب را شناسایی می‌کنند. هر بار که این سیستم یک درخواست را مشکل‌دار تشخیص دهد، پاسخ به‌طور خودکار توسط Claude Opus 4.8 داده می‌شود — به جای اینکه درخواست کاملاً رد شود. این رویکرد هوشمندانه‌ای است؛ چرا که کاربر یک پاسخ مفید دریافت می‌کند، اما از توانایی‌های پیشرفته‌تری که می‌توانند مورد سوءاستفاده قرار بگیرند، محافظت می‌شود.
این fallback در کمتر از ۵ درصد جلسات اتفاق می‌افتد. برای بقیه کاربران، عملکرد Fable 5 عملاً برابر با Mythos 5 است.
سه حوزه اصلی تحت پوشش classifier قرار دارند:
امنیت سایبری. Mythos-class در شناسایی و بهره‌برداری از آسیب‌پذیری‌های نرم‌افزاری فوق‌العاده عمل می‌کند. classifier های Fable 5 نه‌تنها بهره‌برداری از آسیب‌پذیری، بلکه طیف گسترده‌تری از وظایف تهاجمی سایبری — شامل شناسایی، حرکت جانبی و فرار از سیستم‌های دفاعی — را پوشش می‌دهند. یک آزمون خارجی با بیش از ۱۰۰۰ ساعت تست انجام شد و هیچ jailbreak جهانی پیدا نشد.
زیست‌شناسی و شیمی. Mythos 5 در پیش‌بینی خواص ویروس‌های پیچیده، عملکردی بهتر از مدل‌های اختصاصی پروتئین داشت — بدون اینکه برای این کار آموزش دیده باشد. این توانایی dual-use است: در دست محققان، ابزاری ارزشمند برای توسعه درمان‌های ژنی است؛ در دست افراد نادرست، می‌تواند خطرناک باشد. به همین دلیل، اکثر درخواست‌های مرتبط با زیست‌شناسی و شیمی فعلاً به Opus 4.8 ارجاع داده می‌شوند.
Distillation. این classifier از تلاش‌های مقیاس‌بزرگ برای استخراج توانایی‌های Claude و استفاده از آن‌ها برای آموزش مدل‌های رقیب جلوگیری می‌کند.
Claude Mythos 5 چیست؟
Claude Mythos 5 همان مدل پایه‌ای است که Fable 5 بر آن بنا شده، اما با یک تفاوت کلیدی: محدودیت‌های سایبری آن برداشته شده است.
نام‌گذاری این دو مدل نیز بامعناست. «Fable» از ریشه لاتین fabula به معنای «آنچه گفته می‌شود» می‌آید — هم‌ریشه با کلمه یونانی mythos. تنها چیزی که این دو مدل را از هم جدا می‌کند، وجود یا عدم وجود همان safeguardها است.
Mythos 5 در حال حاضر تنها برای شرکای Project Glasswing — شامل سازمان‌های امنیت سایبری و ارائه‌دهندگان زیرساخت‌های حیاتی — در دسترس است. Anthropic قصد دارد به زودی دسترسی را به محققان زیست‌پزشکی تأییدشده نیز گسترش دهد، با این تفاوت که برای آن‌ها safeguardهای زیست‌شناسی برداشته می‌شود، اما محدودیت‌های سایبری همچنان باقی می‌ماند.
قابلیت‌های اصلی این مدل‌ها
Fable 5 و Mythos 5 در چند حوزه به صورت خاص برجسته هستند.
برنامه‌نویسی. شرکت Stripe گزارش داده که Fable 5 یک migration در پایگاه کد ۵۰ میلیون خطی Ruby را در یک روز انجام داد — کاری که یک تیم کامل بیش از دو ماه نیاز داشت. در بنچمارک FrontierCode که کیفیت کد تولیدی در محیط‌های واقعی را ارزیابی می‌کند، Fable 5 بالاترین امتیاز را در بین مدل‌های frontier کسب کرد.
وظایف طولانی‌مدت. این مدل‌ها می‌توانند ساعت‌ها روی یک پروژه کار کنند، پیشرفت خود را ارزیابی کنند و مسیر را در صورت نیاز اصلاح کنند. هر دو مدل از پنجره context یک میلیون توکن با خروجی تا ۱۲۸ هزار توکن در هر درخواست پشتیبانی می‌کنند. آزمایش با بازی Slay the Spire نشان داد که استفاده از حافظه مبتنی بر فایل، عملکرد Fable 5 را سه برابر بیشتر از Opus 4.8 بهبود می‌دهد.
پردازش تصویر. Fable 5 جدیدترین مدل state-of-the-art در حوزه بینایی است. این مدل توانست بازی Pokémon FireRed را تنها با تماشای اسکرین‌شات‌های خام و بدون هیچ ابزار کمکی به پایان برساند — کاری که مدل‌های قبلی Claude حتی با harness های پیچیده هم به سختی از پس آن برمی‌آمدند.
تحقیقات علمی. Mythos 5 فرآیند طراحی دارو را تا ۱۰ برابر سریع‌تر کرده و در ۹ مورد از ۱۴ هدف پروتئینی مورد مطالعه، کاندیداهای قوی شناسایی کرده است. همچنین اولین مدل Anthropic است که به طور مستمر فرضیه‌های علمی نوآورانه تولید می‌کند؛ یکی از این فرضیه‌ها درباره یک پروتئین باکتریایی بعداً توسط یک آزمایشگاه مستقل تأیید شد.
تحلیل مالی و کاری. در Finance Benchmark شرکت Hebbia برای استدلال در سطح ارشد، Fable 5 بالاترین امتیاز را در بین تمام مدل‌های آزمایش‌شده کسب کرد. شرکت IMC نیز گزارش داد که این مدل در تقریباً تمام معیارهای ارزیابی تحلیل معاملاتی نتایج عالی داشت.
سیاست جدید نگهداری داده
یکی از تغییرات مهمی که با این مدل‌ها همراه شده، الزام نگهداری ۳۰ روزه داده برای تمام ترافیک روی مدل‌های Mythos-class است.
Anthropic تأکید می‌کند که این داده‌ها برای آموزش مدل‌های جدید استفاده نمی‌شوند و تمام دسترسی‌های انسانی به آن‌ها ثبت می‌شود. هدف اصلی شناسایی jailbreak های پیچیده‌ای است که ممکن است در طول زمان و در چند مکالمه مختلف طراحی شده باشند — حملاتی که بررسی تک‌به‌تک جلسات قادر به شناسایی آن‌ها نیست.
قیمت‌گذاری و دسترسی
هر دو مدل با قیمت یکسان عرضه شده‌اند: ۱۰ دلار به ازای هر میلیون توکن ورودی و ۵۰ دلار به ازای هر میلیون توکن خروجی. این قیمت کمتر از نصف قیمت Claude Mythos Preview است.
از نظر دسترسی:
Claude Fable 5 از ۹ ژوئن ۲۰۲۶ از طریق Claude API و پلن‌های Enterprise مصرفی کاملاً در دسترس است. برای کاربران اشتراکی (Pro، Max، Team و Enterprise)، این مدل تا ۲۲ ژوئن بدون هزینه اضافه در دسترس است. از ۲۳ ژوئن، استفاده از آن نیاز به usage credit خواهد داشت. Anthropic اعلام کرده که به محض کافی شدن ظرفیت، Fable 5 را دوباره به‌عنوان بخش استاندارد پلن‌های اشتراکی اضافه خواهد کرد.
Claude Mythos 5 فعلاً تنها در اختیار شرکای Project Glasswing است و به زودی برای محققان زیست‌پزشکی تأییدشده نیز باز خواهد شد.
جمع‌بندی
Claude Fable 5 و Mythos 5 را می‌توان مهم‌ترین معرفی Anthropic در سال ۲۰۲۶ دانست — نه فقط به خاطر قدرت بیشتر، بلکه به خاطر رویکردی که پشت آن‌هاست.
برای اولین بار، یک شرکت هوش مصنوعی به جای اینکه یک مدل را به خاطر نگرانی‌های امنیتی کنار بگذارد یا بدون هیچ محدودیتی آن را منتشر کند، مسیر سومی را انتخاب کرد: انتشار با safeguardهای دقیق، ارجاع هوشمند به جای رد کردن، آزمون‌های امنیتی گسترده، و گسترش تدریجی دسترسی بر اساس اعتماد.
این الگو نشان‌دهنده بلوغ صنعتی است — و احتمالاً در مدل‌های آینده نیز استاندارد خواهد شد.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
اینجا حواستون باشه نوع بیلدتون چیه توی Next Js، مثلا اگر standalone باشه باید از "node /server.js" برای شروع سرو کردن استفاده کنید:
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]
دلیل copy کردن package.json قبل از سورس: Docker لایه‌ها رو cache می‌کنه. اگر سورس کد عوض بشه ولی dependency عوض نشه، npm install مجدداً اجرا نمیشه و build سریع‌تره.
قبل از اجرا مطمئن شو DNS دامنه‌ات به IP سرور اشاره می‌کنه و پورت ۸۰ باز باشه.
همچنین اینجا بازم باید بگم که بخاطر شرایط اینترنت ایران، بهتره که ssl رو هم از روش های جایگذین ست کنید که renew بشه که توی devneeds (بخش SSL) مثلا توضیح داده شده به صورت رایگان گرفتن ssl.
۱۰. تنظیمات Production
در docker-compose.yml از restart: unless-stopped استفاده کن تا container بعد از ری‌استارت سرور هم بالا بیاد.
برای دیدن لاگ‌های دقیق‌تر:
docker logs -f node_app
docker inspect node_app
جمع‌بندی
ترکیب استاندارد برای یه دیپلوی حرفه‌ای:
Docker — اجرای ایزوله اپ
Docker Compose — مدیریت سرویس‌ها
Nginx — reverse proxy و ورودی ترافیک
SSL — امنیت ارتباط
میرور داخلی — پایداری در شرایط ایران
روش
مشکل اصلی
Node + PM2 مستقیم
وابستگی به سرور — هر تغییری می‌تونه محیط رو خراب کنه
نصب دستی
conflict dependency — قابل تکرار نیست
Docker + Compose
محیط ثابت — deploy یکسان روی همه سرورها
مشاهده وضعیت کانتینرهای در حال اجرا
خواندن لاگ‌های هر سرویس مستقیم از مرورگر
ورود به Shell کانتینر بدون نیاز به exec -it
ساخت، حذف و ری‌استارت کانتینرها
مدیریت Volume ها و Network ها
اجرای Docker Compose Stack ها
مدیریت چندین سرور Docker از یک پنل واحد
مدیریت Image ها و پاک‌سازی فضا
رایگان است یا پولی؟
Portainer Community Edition (CE) کاملاً رایگان و متن‌باز است و برای اکثر توسعه‌دهندگان بیش از کافی است.
نسخه
هزینه
مناسب برای
Community Edition (CE)
رایگان
توسعه‌دهندگان، VPS، پروژه‌های شخصی
Business Edition (BE)
رایگان تا ۳ Node، بعد پولی
تیم‌ها و شرکت‌ها با نیاز به RBAC، SSO، GitOps
اگر می‌خواهی کانتینر اجرا کنی، لاگ بخوانی، Docker Compose مدیریت کنی و اپلیکیشن Deploy کنی، نسخه CE کاملاً کافی است.
نصب روی VPS در کمتر از یک دقیقه
اگر Docker روی سرورت نصب است، با همین دستورات Portainer را راه‌اندازی کن:
نکته امنیتی: هرگز Portainer را مستقیم روی پورت عمومی اجرا نکن. حتماً پشت Nginx با HTTPS قرار بده و پورت ۹۴۴۳ را از Firewall مسدود کن.
برای چه کسانی مناسب است؟
توسعه‌دهندگانی که VPS یا سرور شخصی دارند
کسانی که سرویس‌هایی مثل PostgreSQL، Redis، MinIO یا Grafana را Self-host می‌کنند
تازه‌کارهایی که دارند Docker یاد می‌گیرند و می‌خواهند وضعیت کانتینرها را بصری ببینند
فریلنسرها و تیم‌های کوچکی که باید چند پروژه روی یک سرور مدیریت کنند
Portainer جایگزین CLI می‌شود؟
نه، و نباید باشد. Portainer یک ابزار مکمل است، نه جایگزین. برای مدیریت روزمره و مانیتورینگ عالی است، اما برای کارهای پیشرفته‌تر مثل دیباگ مشکلات شبکه، نوشتن Compose فایل‌های پیچیده یا Scripting، همچنان به CLI نیاز داری.
توصیه: هر دو را یاد بگیر. CLI برای تسلط واقعی ضروری است، Portainer برای مدیریت راحت‌تر روزانه.
جمع‌بندی
Portainer یک ابزار رایگان، سریع و کاربرپسند برای مدیریت Docker است. اگر سرور یا VPS داری، نصب Portainer یکی از اولین کارهایی است که باید انجام دهی. در کمتر از یک دقیقه نصب می‌شود و از همان لحظه مدیریت کانتینرهایت را متحول می‌کند.
به زبان ساده:
ChatGPT گفتگوهای قبلی را تحلیل می‌کند.
اطلاعات مهم و پایدار را استخراج می‌کند.
موارد قدیمی یا منقضی شده را به‌روزرسانی می‌کند.
هنگام پاسخ‌گویی، فقط اطلاعات مرتبط را وارد مکالمه می‌کند.
این فرآیند باعث می‌شود حافظه ChatGPT بیشتر شبیه حافظه انسان عمل کند تا یک پایگاه داده ساده.
مهم‌ترین مزایای Dreaming
1. حفظ بهتر اطلاعات مهم
دیگر لازم نیست بارها و بارها اطلاعات یکسان را تکرار کنید.
اگر ChatGPT بداند که شما:
برنامه‌نویس هستید
به توسعه Full Stack علاقه دارید
روی پروژه خاصی کار می‌کنید
می‌تواند در گفتگوهای بعدی پاسخ‌های دقیق‌تر و شخصی‌سازی‌شده‌تری ارائه دهد.
2. جلوگیری از قدیمی شدن حافظه
یکی از مشکلات سیستم‌های حافظه سنتی این بود که اطلاعات منسوخ را همچنان معتبر فرض می‌کردند.
برای مثال اگر ChatGPT بداند شما در ماه جولای به سنگاپور سفر می‌کنید، پس از پایان سفر این اطلاعات به‌روزرسانی می‌شود و دیگر تصور نمی‌کند همچنان در آن کشور حضور دارید.
3. شخصی‌سازی بسیار بهتر
Dreaming باعث می‌شود ChatGPT:
سبک نوشتاری شما را بهتر بشناسد
علایق شما را درک کند
پیشنهادهای مرتبط‌تری ارائه دهد
در پروژه‌های بلندمدت عملکرد بهتری داشته باشد
این موضوع به‌خصوص برای توسعه‌دهندگان، تولیدکنندگان محتوا، دانشجویان و مدیران پروژه اهمیت زیادی دارد.
4. مقیاس‌پذیری بیشتر
OpenAI اعلام کرده معماری جدید Dreaming نسبت به نسخه‌های قبلی بسیار بهینه‌تر شده و هزینه پردازشی آن تا حدود 5 برابر کاهش یافته است. این موضوع امکان ارائه حافظه پیشرفته را برای تعداد بسیار بیشتری از کاربران فراهم می‌کند.
آیا کاربران روی حافظه کنترل دارند؟
بله.
OpenAI تأکید کرده است که کاربران همچنان می‌توانند:
حافظه را مشاهده کنند
اطلاعات ذخیره‌شده را حذف کنند
حافظه را ویرایش کنند
قابلیت Memory را غیرفعال کنند
از Temporary Chat برای گفتگوهای بدون ذخیره‌سازی استفاده کنند.
آیا Dreaming نگرانی‌های حریم خصوصی ایجاد می‌کند؟
هر سیستم حافظه هوشمند طبیعتاً سوالاتی درباره حریم خصوصی ایجاد می‌کند.
هرچند OpenAI ابزارهای متعددی برای مدیریت حافظه در اختیار کاربران قرار داده است، اما برخی کاربران نسبت به خلاصه‌سازی خودکار اطلاعات شخصی و نحوه تفسیر آن‌ها توسط سیستم نگرانی‌هایی مطرح کرده‌اند. در برخی بحث‌های جامعه OpenAI نیز کاربران درباره نحوه تبدیل اطلاعات دقیق به خلاصه‌های کلی‌تر اظهار نظر کرده‌اند.
به همین دلیل آگاهی از تنظیمات Memory و مدیریت دوره‌ای اطلاعات ذخیره‌شده اهمیت زیادی خواهد داشت.
آینده ChatGPT با Dreaming
Dreaming فقط یک قابلیت جدید نیست؛ بلکه زیرساختی برای نسل آینده دستیارهای هوش مصنوعی محسوب می‌شود.
هدف OpenAI ساخت سیستمی است که بتواند در طول ماه‌ها و حتی سال‌ها همراه کاربران باشد، پروژه‌های آن‌ها را بشناسد، ترجیحاتشان را درک کند و با گذشت زمان مفیدتر شود.
اگر این مسیر موفق باشد، ChatGPT از یک چت‌بات ساده به یک دستیار دیجیتال واقعی تبدیل خواهد شد که نه‌تنها به سوالات پاسخ می‌دهد، بلکه شما، اهداف شما و شیوه کاری شما را نیز می‌شناسد.
جمع‌بندی
معرفی Dreaming یکی از مهم‌ترین به‌روزرسانی‌های تاریخ ChatGPT محسوب می‌شود. این فناوری با استفاده از حافظه پویا و خودبه‌روزرسان، مشکل فراموشی، کهنه شدن اطلاعات و شخصی‌سازی محدود را تا حد زیادی برطرف می‌کند.
در دنیایی که هوش مصنوعی به سمت دستیارهای دائمی و همراه حرکت می‌کند، حافظه هوشمند دیگر یک قابلیت جانبی نیست؛ بلکه یکی از مهم‌ترین ارکان تجربه کاربری خواهد بود. Dreaming دقیقاً در همین مسیر قرار گرفته است و می‌تواند آینده تعامل انسان و هوش مصنوعی را متحول کند.
اما همه راضی نیستند
برخی کاربران حرفه‌ای انتقادهای مهمی نیز مطرح کرده‌اند.
چندین توسعه‌دهنده گزارش کرده‌اند که تفاوت عملکرد روزمره میان Opus 4.7 و Opus 4.8 آن‌قدر زیاد نیست که بتوان آن را یک جهش بزرگ نامید. برخی دیگر معتقدند GPT-5.5 هنوز در بعضی وظایف ترمینالی، اتوماسیون و پروژه‌های بسیار بزرگ عملکرد بهتری دارد.
در حوزه خلاقیت نیز انتقادهایی مطرح شده است. برخی کاربران معتقدند Opus 4.6 هنوز در طراحی بازی، داستان‌نویسی و دنبال کردن جزئیات هنری عملکرد بهتری دارد.
همچنین حذف پارامترهای سنتی مانند temperature، top_p و top_k در API باعث شده برخی تیم‌ها برای مهاجرت به نسخه جدید نیاز به تغییر کدهای خود داشته باشند.
جمع‌بندی برای توسعه‌دهندگان
اگر از Claude Code استفاده می‌کنید و روی پروژه‌های واقعی، ریفکتورینگ، طراحی معماری، مهاجرت سیستم‌ها یا Agentic Coding کار می‌کنید، Opus 4.8 احتمالاً ارزش ارتقا دارد.
اما اگر انتظار دارید کیفیت آن دو یا سه برابر بهتر از Opus 4.7 باشد، احتمالاً ناامید خواهید شد. بیشتر کاربران حرفه‌ای آن را یک ارتقای باکیفیت و کاربردی می‌دانند، نه یک جهش انقلابی.
دسته دوم: نظر کاربران عادی
برای کاربران غیر فنی، وضعیت کمی متفاوت است.
بیشتر کاربران روزمره به این موارد اشاره کرده‌اند:
پاسخ‌های دقیق‌تر
قضاوت بهتر
مکالمات طبیعی‌تر
اعتراف بیشتر به ندانستن پاسخ
ثبات بالاتر در گفتگوهای طولانی
کلر وو، تحلیلگر AI، معتقد است Opus 4.8 نسبت به نسخه قبلی قضاوت بهتری دارد و می‌تواند مستقل‌تر از قبل کار کند.
برخی کاربران نیز آن را «پخته‌تر» توصیف کرده‌اند؛ مدلی که شاید الزاماً باهوش‌تر به نظر نرسد، اما کمتر دچار اشتباهات عجیب می‌شود.
با این حال بسیاری از کاربران عادی گفته‌اند که تفاوت آن در استفاده روزمره چندان چشمگیر نیست. اگر استفاده شما محدود به نوشتن متن، ایمیل، تولید محتوا یا گفتگوهای معمولی باشد، احتمالاً تفاوت بزرگی با مدل‌های ارزان‌تر احساس نخواهید کرد.
Dynamic Workflows چیست و چرا اینقدر درباره آن صحبت می‌شود؟
مهم‌ترین قابلیت جدید Opus 4.8 بدون شک Dynamic Workflows است.
در مدل‌های سنتی، یک درخواست وارد می‌شود و یک پاسخ خارج می‌شود. اما در Dynamic Workflows، Claude ابتدا مسئله را تحلیل می‌کند، سپس آن را به چندین بخش کوچک‌تر تقسیم می‌کند و برای هر بخش یک یا چند عامل مستقل (Subagent) ایجاد می‌کند. این عوامل به صورت موازی روی بخش‌های مختلف پروژه کار می‌کنند، نتایج یکدیگر را بررسی می‌کنند و در نهایت خروجی نهایی را تولید می‌کنند.
در عمل، این قابلیت برای پروژه‌هایی مانند:
مهاجرت پروژه‌های بزرگ
تحلیل چندصد هزار خط کد
ریفکتورینگ گسترده
تست و اعتبارسنجی سیستم‌ها
تحلیل همزمان چندین سرویس
بسیار قدرتمند است.
برخی توسعه‌دهندگان در Reddit گزارش کرده‌اند که وظایفی که قبلاً ۴۵ دقیقه زمان نیاز داشتند، اکنون در حدود ۱۰ تا ۱۵ دقیقه انجام می‌شوند.
اما این قابلیت یک نقطه ضعف مهم هم دارد: مصرف توکن.
چندین کاربر گزارش کرده‌اند که Workflowهای بزرگ می‌توانند هزینه استفاده را به شدت افزایش دهند و در صورت عدم مدیریت صحیح، صدها Agent موازی حجم زیادی از توکن مصرف می‌کنند.
تغییرات مهم برای برنامه‌نویسان
علاوه بر Dynamic Workflows، چند تغییر فنی مهم دیگر نیز وجود دارد:
Adaptive Thinking
مدل دیگر نیازی به تعیین دستی بودجه استدلال ندارد و خودش تصمیم می‌گیرد چه مقدار برای حل مسئله زمان و منابع صرف کند.
Effort Levels
سطوح جدید Low، Medium، High، Extra و Max به کاربران اجازه می‌دهد بین سرعت و کیفیت تعادل ایجاد کنند.
Fast Mode
نسخه Fast Mode اکنون چند برابر ارزان‌تر از گذشته است و برای بسیاری از تیم‌ها شاید مهم‌تر از خود بهبود هوش مدل باشد.
صداقت بیشتر
بزرگ‌ترین تغییر رفتاری Opus 4.8 همین موضوع است. مدل بیشتر از قبل اشتباهات خود را اعلام می‌کند و کمتر سعی می‌کند پاسخ‌های حدسی را به عنوان حقیقت ارائه دهد.
نتیجه نهایی: ارزش خرید دارد؟
برای توسعه‌دهندگان
بله.
اگر روی پروژه‌های واقعی، سیستم‌های بزرگ، Agentic Coding و Claude Code کار می‌کنید، Opus 4.8 یکی از بهترین مدل‌های فعلی بازار محسوب می‌شود. مزیت اصلی آن نه هوش بیشتر، بلکه قابلیت اطمینان و صداقت بیشتر است.
برای کاربران عادی
تا حدی.
اگر هم‌اکنون از Claude استفاده می‌کنید، تجربه بهتری خواهید داشت. اما اگر فقط برای گفتگو، تولید محتوا و استفاده روزمره به مدل نیاز دارید، تفاوت آن با بسیاری از مدل‌های ارزان‌تر آن‌قدر زیاد نیست که به تنهایی دلیل خرید باشد.
برای Dynamic Workflows و پروژه‌های سازمانی
اینجاست که Opus 4.8 واقعاً می‌درخشد.
برای تیم‌هایی که با مخازن بزرگ، مهاجرت سیستم‌ها و پروژه‌های پیچیده کار می‌کنند، Dynamic Workflows می‌تواند بهره‌وری را به شکل محسوسی افزایش دهد.
جمع‌بندی نهایی
Claude Opus 4.8 یک نسخه بالغ‌تر، صادق‌تر و قابل‌اعتمادتر از Opus 4.7 است. این مدل قرار نیست شما را با جهشی عظیم در هوش شگفت‌زده کند، اما احتمالاً کمتر اشتباه می‌کند، بهتر محدودیت‌های خود را می‌شناسد و در پروژه‌های بزرگ عملکرد پایدارتری ارائه می‌دهد. برای توسعه‌دهندگان حرفه‌ای ارزش ارتقا دارد؛ برای کاربران عادی، بیشتر یک بهبود تدریجی محسوب می‌شود تا یک تحول بزرگ.
✅ تست نصب
gcc --version
روی مک، gcc در واقع یک alias برای clang هست که کاملاً سازگار با کد C استاندارد است. اگه خروجی‌ای شبیه این دیدید، نصب موفق بوده:
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin23.0.0
روش دوم: نصب GCC اصلی با Homebrew
اگه میخواید نسخه اصلی GCC (نه clang) داشته باشید، ابتدا Homebrew رو نصب کنید:
