Codoloper

آموزش برنامه‌نویسی به فارسی

یاد بگیر، پیشرفت کن، بساز.

منبع آموزشی برنامه‌نویسی به زبان فارسی - مستندات، دوره‌ها و مطالب کاربردی برای همه سطوح.

داکیومنت ها:

JavascriptJetpack ComposeHTMLCSSبیشتر
1// برنامه‌نویسی به فارسی
2import { learn } from 'codoloper'
3
4const developer = learn({
5"lang": "فارسی"
6"level": "همه سطوح"
7free: true
8})
240+
صفحه مستندات
6+
زبان ها / فریمورک ها
رایگان
دسترسی کامل
چرا کدلپر؟

ارزش‌های ما

یادگیری برنامه‌نویسی نباید پیچیده باشد - ما مسیر را ساده می‌کنیم.

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

مطالب جدید

تازه‌ترین مطالب آموزشی و خبرهای مرتبط.

راهنمای جامع TypeScript؛ تفاوت Type و Interface چیست و چه زمانی از کدام استفاده کنیم؟ نوشته شده توسط Haleh Nakisa

راهنمای جامع TypeScript؛ تفاوت Type و Interface چیست و چه زمانی از کدام استفاده کنیم؟

اگر به تازگی وارد دنیای TypeScript شدید یا حتی مدتیه که از اون تو پروژه‌هاتون (مثل Next.js یا React) استفاده می‌کنید، احتمالاً این سوال برای شما هم پیش اومده: «بالاخره برای تعریف ساختار داده‌ها از type استفاده کنم یا interface؟»
در نگاه اول، این دو کلمه کلیدی شباهت‌های زیادی به هم دارن و در اکثر مواقع کار یکسانی رو انجام میدن. اما در لایه‌های پایین‌تر، تفاوت‌های ساختاری و عملکردی مهمی دارن که شناخت اون‌ها، قطعا تو پروژه کمک کننده‌ست.
در این مقاله می‌خوایم این تفاوت‌ها رو موشکافی کنیم و ببینیم در سناریوهای واقعی، کدوم‌یک انتخاب بهتریه.
شباهت‌ها: 
قبل از اینکه سراغ تفاوت‌ها بریم، بهتره بدونیم که هر دو ابزار می‌تونن شکل یک شیء (Object) رو به راحتی توصیف کنن و هر دو از قابلیت‌هایی مثل ارث‌بری پشتیبانی می‌کنن:

// تعریف یک شیء با استفاده از Interface
interface UserInterface {
  id: number;
  name: string;
}

// تعریف همان شیء با استفاده از Type
type UserType = {
  id: number;
  name: string;
};
در هر دو حالت بالا، خروجی و رفتار TypeScript در مواجهه با یک کامپوننت یا تابع کاملاً یکسان هستش. اما مشکل از جایی شروع میشه که نیازهای پیچیده‌تری داشته باشیم.
تفاوت‌ها: چرا به هر دو نیاز داریم؟
۱. قابلیت ادغام خودکار یا Declaration Merging (کدوم بهتره: Interface)
بزرگ‌ترین و مهم‌ترین تفاوت ساختاری این دو اینه که interfaceها باز (Open) هستن، اما typeها بسته (Closed). یعنی شما می‌تونید یک interface رو چند بار با یک نام یکسان تعریف کنید و TypeScript به صورت خودکار تمام فیلدهای اون‌ها رو با هم ادغام می‌کنه:
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، ویژگی‌های جدیدی به متغیرهای شما اضافه کنن و اون رو گسترش بدن.
چطور خطای Unknown at rule را در VS Code برطرف کنیم؟ نوشته شده توسط Haleh Nakisa

چطور خطای Unknown at rule را در VS Code برطرف کنیم؟

اگر تو پروژه‌هاتون از فریم‌ورک‌های مدرن CSS مثل Tailwind CSS استفاده می‌کنید، احتمالاً این هشدار رو دیدید: وقتی میخواید از دایرکتیوهایی مثل @apply، @theme یا @tailwind، استفاده کنید ویرایشگر VS Code زیر اونهاخط زرد یا قرمز می‌کشه و خطای Unknown at rule css(unknownAtRules) رو نمایش میده.
این اتفاق به این دلیل میفته که لینتر (Linter) پیش‌فرض VS Code، دایرکتیوهای اختصاصی فریم‌ورک‌ها رو به عنوان کدهای استاندارد CSS نمی‌شناسه. اگرچه این هشدار هیچ اختلالی تو کامپایل و اجرای پروژه ایجاد نمی‌کنه، اما در فایل‌های استایل، ظاهر کدها رو آشفته می‌کنه و تمرکز توسعه‌دهنده رو به هم می‌زنه.
در این آموزش کوتاه، یاد می‌گیریم چطوری تو کمتر از یک دقیقه این مشکل رو برای همیشه تو ادیتورمون برطرف کنیم.
اگر از فایل‌های استاندارد .css استفاده می‌کنید
برای غیرفعال کردن این هشدار و نادیده گرفتن دایرکتیوهای ناشناخته توسط VS Code، این مرحله‌ها رو دنبال کنید:
۱. کلیدهای ترکیبی Ctrl + Shift + P (در مک Cmd + Shift + P) رو فشار بدید تا منوی دستوراهای (Command Palette) باز شه.
۲. عبارت settings.json رو تایپ کنید. بین گزینه‌های پیشنهادی، معمولاً سه فایل زیر رو می‌بینید:
Open User Settings (JSON)
Open Default Settings (JSON)
Open Workspace Settings (JSON)
۳. گزینه اول(ممکنه برای شما گزینه اول نباشه)، Open User Settings (JSON) رو انتخاب کنید تا فایل تنظیمات کاربریتون باز شه.
۴. خط کد زیر رو به انتهای این فایل (قبل از بستن آکاردئون اصلی {}) اضافه کنید:

"css.lint.unknownAtRules": "ignore"
۵. فایل رو با کلیدهای Ctrl + S (در مک Cmd + S) ذخیره کنید. بلافاصله بعد از ذخیره، همه هشدارهای مربوط به این بخش ناپدید میشن.
اگر از فایل‌های .scss استفاده می‌کنید
اگر تو پروژهاتون در کنار فریم‌ورک‌هایی مثل تیلوند، از پیش‌پردازنده‌ی ساس (Sass) استفاده می‌کنید و پسوند فایل‌های استایل شما .scss هستش، باید تنظیمات مربوط به این فرمت رو تغییر بدید. به جای کد قبل، کافیه کد زیر رو به همون فایل settings.json اضافه کنید:
"scss.lint.unknownAtRules": "ignore"
نکته: اگر تو پروژه‌های مختلفتون هم از CSS معمولی و هم از SCSS استفاده می‌کنید، می‌تونید هر دو خط کد رو در فایل تنظیمات قرار بدید تا این خطا تو هیچ‌کدوم از فایل‌ها تکرار نشه.

جمع‌بندی
گاهی اوقات هشدارهای پیش‌فرضِ ابزارهای توسعه، برای کدهای مدرن بهینه‌سازی نشدن و باعث شلوغی محیط کدنویسی می‌شن. با انجام این تغییر ساده، ادیتورتون رو جوری شخصی‌سازی کردید که تنها خطاهای واقعی و ساختاری کد رو به شما نشون میده.
شما برای حل این مشکل از چه روشی استفاده می‌کردید؟
چطور با OKLCH و color-mix در CSS، کدهای رنگی هوشمندتر بنویسیم و حجم پروژه رو کم کنیم؟ نوشته شده توسط Haleh Nakisa

چطور با OKLCH و color-mix در CSS، کدهای رنگی هوشمندتر بنویسیم و حجم پروژه رو کم کنیم؟

سلام به همه کادولوپری‌های عزیز!

به عنوان یک فرانت‌اند دولوپر، حتماً برای شما هم پیش اومده که در پروژه‌های بزرگ با انبوهی از متغیرهای رنگی برای حالت‌های مختلف مثل Hover، Active یا Disabled سردرگم شید. تعریف کردن ده‌ها کد Hex یا HSL نه تنها فایل‌های CSS ما رو شلوغ و شلخته می‌کنه، بلکه مدیریت اون‌ها در آینده رو هم سخت می‌کنه.

امروز می‌خوایم با هم بررسی کنیم که چطور فضای رنگی مدرن OKLCH به همراه تابع فوق‌العاده کاربردی color-mix در CSS، می‌تونن این مشکل رو به راحتی حل کنن و حتی حجم باندل (Bundle Size) پروژه‌های بزرگمون رو پایین بیارن.

خب، اول بریم بررسی کنیم OKLCH چیه؟

فضای رنگی OKLCH یک روش جدید و به‌شدت جذاب برای تعریف رنگ در CSS هستش که دقیقاً بر اساس درک چشم انسان از رنگ‌ها طراحی شده. این متد از ۴ مؤلفه تشکیل شده:

  • Lightness (L): میزان روشنایی رنگ رو مشخص می‌کنه (از 0% تا 100%).

  • Chroma (C): میزان خلوص، زنده بودن یا شدت رنگ هستش. مثلاً رنگ قرمزِ جیغ Chroma بالایی داره. هرچی Chroma رو کمتر کنیم، رنگمون کدرتر و به خاکستری نزدیک‌تر می‌شه.

  • Hue (H): زاویه رنگ روی چرخه رنگ میشه؛ یک عدد بین 0 تا 360 درجه که خودِ رنگ (قرمز، آبی، سبز و...) رو تعیین می‌کنه.

  • Alpha (A): همون میزان شفافیت یا transparency هستش (بین 0 تا 1 یا به صورت درصد).

یک نکته خیلی جالب: در OKLCH، این مؤلفه‌ها به شکل هوشمندانه‌ای به هم متصل هستن؛ یعنی با تغییر یکی، بقیه هم طوری تغییر می‌کنن که رنگ در دنیای واقعی کاملاً طبیعی و چشم‌نواز به نظر برسن. پیشنهاد می‌کنم حتماً به سایت oklch.com سر بزنید و خودتون اهرم‌های مختلف رو جا به جا کنید تا بیشتر این مبحث رو درک کنید!

داستان واقعی: از طرح دیزاینر تا دکمه‌های Hover

تصور کنید طراح پروژه، یک رنگ اصلی (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 رو در اختیارتون بذاره:

@theme {
  --color-primary: var(--color-primary);
  --color-primary-hover: var(--primary-hover);
}

با این کار، تیلوند به طور خودکار متغیرهای بومی CSS شما رو می‌شناسه و بدون هیچ پکیج یا ابزار اضافی، قدرت OKLCH و color-mix رو مستقیم وارد کامپوننت‌هاتون می‌کنه.

جمع‌بندی

استفاده از OKLCH و color-mix دست شما رو برای نوشتن کدهای CSS تمیزتر، هوشمندتر و بهینه‌تر باز می‌ذاره. با این روش، تغییر تم (Theme) سایت در آینده هم خیلی راحت میشه و دیگه نیازی به تعریف کردن چندین رنگ تکراری ندارید.

شما تا حالا از این قابلیت‌های مدرن CSS در پروژه‌هاتون استفاده کردید؟ تجربه‌ یا سوالی دارید؟ در بخش کامنت‌ها منتظرتون هستیم!

دولت آمریکا دسترسی به Fable 5 و Mythos 5 را مسدود کرد! نوشته شده توسط عرفان دهقانی

دولت آمریکا دسترسی به Fable 5 و Mythos 5 را مسدود کرد!

دولت آمریکا به دلیل نگرانی‌های امنیتی، دستور توقف فوری و کامل دسترسی به مدل‌های قدرتمند Fable 5 و Mythos 5 شرکت آنتروپیک (Anthropic) را صادر کرد؛ تصمیمی که با مخالفت شدید این کمپانی روبه‌رو شده است.

داستان از روز گذشته و دقیقاً در ساعت ۵:۲۱ عصر به‌وقت شرقی آمریکا شروع شد؛ زمانی که یک دستور ناگهانی و شوکه‌کننده از سمت دولت ایالات متحده به دفتر شرکت آنتروپیک رسید. واشنگتن با استناد به اختیارات کنترل صادرات و امنیت ملی، دستور داده که دسترسی تمام کاربران خارجی (چه داخل آمریکا و چه خارج از آن) و حتی کارمندان غیرآمریکایی خودِ شرکت آنتروپیک به دو مدل پیشرفته Fable 5 و Mythos 5 قطع شود. نتیجه؟ آنتروپیک برای پایبندی به قانون مجبور شد این دو مدل را به‌طور کامل برای همه کاربران در سراسر جهان غیرفعال کند.

ماجرا چیست؟ داستان یک جیلبریک (Jailbreak) جنجالی بر اساس اطلاعات منتشر شده، به نظر می‌رسد دولت آمریکا مدعی شده که یک روش نفوذ یا همان «جیلبریک» پیدا کرده که می‌تواند لایه‌های امنیتی Fable 5 را دور بزند. اما آنتروپیک اصلاً با این تصمیم موافق نیست! این شرکت می‌گوید چیزی که دولت به عنوان نقطه ضعف پیدا کرده، صرفاً یک باگ جزیی و محدود است؛ در واقع سیستم فقط یک سری کد را خوانده و باگ‌های نرم‌افزاری آن را اصلاح کرده است؛ کاری که مدل‌های رقیب مثل GPT-5.5 شرکت OpenAI نیز هر روز برای متخصصان امنیت شبکه‌ انجام می‌دهند و هیچ قابلیت خطرناکی محسوب نمی‌شود.

سود و زیان این اتفاق برای کاربر نهایی چیست؟ اگر از کاربران خدمات آنتروپیک هستید، این تصمیم مستقیماً روی کار شما تاثیر می‌گذارد:

  • قطعی سرویس: متأسفانه در حال حاضر دسترسی شما به قوی‌ترین و جدیدترین مدل‌های این شرکت یعنی Fable 5 و Mythos 5 کاملاً قطع شده است.

  • سایر مدل‌ها امن هستند: خبر خوب این است که دسترسی به بقیه مدل‌های قدیمی‌تر و استاندارد آنتروپیک (مثل نسخه‌های مختلف کلاود) هیچ تغییری نکرده و مثل قبل کار می‌کنند.

  • پافشاری بر حریم خصوصی: آنتروپیک پیش از این برای بررسی همین حملات، سیاست ذخیره ۳۰ روزه داده‌های کاربران را وضع کرده بود که صدای خیلی‌ها را درآورد؛ حالا مشخص شد این کار برای دفاع چندلایه در برابر چنین روزهایی بوده است.

ویژگی‌های امنیتی Fable 5 از زبان آنتروپیک

آنتروپیک سفت و سخت پای لایه‌های امنیتی محصولش ایستاده و می‌گوید قبل از عرضه، هزاران ساعت تست نفوذ (Red-Teaming) با همکاری دولت آمریکا و سازمان امنیت هوش مصنوعی بریتانیا (UK AISI) انجام داده است. ویژگی‌های این سیستم عبارت بودند از:

  • سخت‌گیری شدید: لایه‌های حفاظتی این مدل آن‌قدر قوی طراحی شده بودند که بسیاری از کاربران عادی از محدودیت‌های زیاد آن شکایت داشتند.

  • نبود جیلبریک همه‌جانبه: تا این لحظه هیچ هکر یا تستر امنیتی نتوانسته یک «جیلبریک جهانی» (Universal Jailbreak) پیدا کند که تمام قفل‌های سیستم را یک‌جا باز کند.

  • استراتژی دفاع چندلایه (Defense in Depth): آنتروپیک معتقد است هوش مصنوعی بی‌نقص وجود ندارد؛ بنابراین استراتژی آن‌ها سخت کردن و گران کردن فرآیند هک برای نفوذگرها بوده، نه ادعای امنیت ۱۰۰ درصدی.

تحلیل کوتاه

این اقدام دولت آمریکا یک زنگ خطر جدی و یک نقطه عطف در تاریخ هوش مصنوعی است. تا پیش از این، دولت‌ها بیشتر در حد توصیه و بیانیه با شرکت‌های بزرگ فناوری تعامل می‌کردند، اما این «احضار و توقیف» ناگهانی نشان می‌دهد که کاخ سفید تعارفی با حوزه فناوری ندارد. نکته نگران‌کننده اینجاست: همان‌طور که آنتروپیک اشاره کرده، اگر استاندارد دولت برای توقیف یک مدل، پیدا شدن یک باگ یا جیلبریک جزیی و محدود باشد، از این به بعد باید منتظر توقف پی‌درپی و زنجیره‌ای تمام مدل‌های پیشرو (Frontier Models) در دنیا باشیم؛ اتفاقی که می‌تواند چرخ توسعه هوش مصنوعی را به شدت کند، یا حتی متوقف کند. آنتروپیک اعلام کرده که این یک سوءتفاهم بزرگ است و در حال رایزنی برای بازگرداندن این دو مدل است، اما بازی قدرت میان رگولاتورها و توسعه‌دهندگان تازه وارد فاز جدی خود شده است.