آیا تنظیم worker_processes در Nginx را انجام می‌دید؟ 🤔

اول از همه، worker_processes چیه ؟ 🤷‍♂️

بیاید از ابتدا شروع کنیم! وقتی شما از Nginx برای مدیریت وب‌سایتتون استفاده می‌کنید، یکی از اولین تنظیماتی که باید بهش توجه کنید، worker_processes هست.

این تنظیم مشخص می‌کنه که Nginx چقدر پردازش موازی برای مدیریت درخواست‌ها و ترافیک به وب‌سایت شما ایجاد کنه. به عبارت ساده‌تر، تعداد پردازش‌هایی که Nginx برای پاسخ به درخواست‌های کاربران راه می‌اندازه، به عهده همین تنظیمه.

حالا worker_processes در Nginx را چگونه پیکربندی کنیم ؟

در تنظیمات پیش‌فرض، Nginx معمولاً تعداد worker_processes رو روی ۲ تا ۴ تا تنظیم می‌کنه.

اما حالا فرض کنید که این مقدار رو به حالت auto تنظیم کنید. 🤖

وقتی worker_processes رو روی Auto بذارید چه اتفاقی می‌افته؟ 🔧

خب، وقتی این گزینه رو روی auto بذارید، Nginx خودش به‌طور خودکار تعداد پردازش‌ها رو مطابق با تعداد هسته‌های پردازنده سرور شما تنظیم می‌کنه. اینجوری Nginx به‌طور هوشمندانه از تمام منابع پردازشی سرور استفاده می‌کنه و عملکرد کلی بهتر می‌شه. 🚀

اما سوال اینجاست: آیا همیشه باید از Auto استفاده کنیم؟ 🤔

در حالی که حالت auto برای اکثر سناریوها انتخاب مناسبی است، در بعضی شرایط خاص، تنظیم دستی worker_processes می‌تواند مزایای بیشتری داشته باشد.

1. سرور با تعداد هسته‌های زیاد یا کم:

سرور با هسته‌های زیاد (مثلاً ۱۲ هسته و یا بیشتر): اگر سرور شما ۱۲ هسته دارد و ترافیک کمی دریافت می‌کند، حالت auto ممکن است منابع اضافی مصرف کند. در این صورت، تنظیم دستی تعداد پردازش‌ها (مثلاً روی ۴ یا ۶) می‌تواند مصرف منابع را بهینه‌تر کند.

سرور با هسته‌های کم (مثلاً ۴ هسته): اگر سرور شما ۴ هسته دارد و ترافیک زیادی می‌آید، حالت auto ممکن است باعث مصرف بی‌مورد منابع شود. تنظیم دستی تعداد پردازش‌ها (مثلاً روی ۳ یا ۴) می‌تواند عملکرد را بهبود دهد و از مصرف اضافی منابع جلوگیری کند.

2.پروژه‌های با پردازش‌های سنگین:

برای پروژه‌هایی با پردازش‌های سنگین مانند استریمینگ ویدئو یا بار پردازشی بالا، تنظیم دستی worker_processes کمک می‌کند تا منابع به‌طور دقیق‌تری اختصاص داده شوند و عملکرد بهینه شود. زمانی که تعداد درخواست‌ها زیاد و پردازش‌ها زمان‌بر هستند، تنظیم تعداد پردازش‌ها می‌تواند تاثیر زیادی داشته باشد.

مثال: برای سرویس ویدئو استریمینگ با درخواست‌های همزمان زیاد، تنظیم تعداد پردازش‌ها روی ۸ یا ۱۲ می‌تواند عملکرد و مدیریت منابع را بهبود دهد.

حالا نظر شما چیه؟ 🗣️

تا حالا از گزینه auto استفاده کردید؟ چطور بوده تجربه‌تون؟ خوشحال می‌شیم نظرات و تجربیات شما رو بشنویم! 💬

————————————————————

@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه ای php و لاراول

❓اگه هیچ روتی پیدا نشه، لاراول چی کار می‌کنه؟! 🤔

آیا تا حالا برات پیش اومده که کاربر آدرس اشتباهی رو وارد کنه و با صفحه‌ی خطای زشت 404 روبه‌رو بشه؟ 😩

اگه دوست داری توی چنین مواقعی یک صفحه‌ی اختصاصی، با ظاهر دلخواه خودت نمایش بدی، Route::fallback دقیقاً برای همینه! ✨

🧩می دونید Route::fallback چیه؟

تو لاراول، این روت آخرین تیر ترکش ماست!

وقتی هیچ‌کدوم از مسیرهایی که تعریف کردی با URL درخواستی کاربر جور درنیاد، لاراول میاد سراغ fallback.

✅ چطوری تعریفش کنیم؟

‍‍‍

use Illuminate\Support\Facades\Route;

Route::fallback(function () {
    return response()->view('errors.custom-404', [], 404);
});
‍‍‍

در این مثال، اگر مسیر درخواست‌شده پیدا نشه، ویوی errors.custom-404 نمایش داده می‌شه که می‌تونه شامل یه پیام دوستانه، لینک برگشت به صفحه اصلی یا هر چیز دیگه‌ای باشه.

🌟 نکات مهم:

🔹حواستون باشه Route::fallback فقط باید یک بار تعریف بشه و همیشه باید در انتهای فایل route بیاد.
🔹 می‌تونی از کنترلر هم استفاده کنی به‌جای Closure
🔹 و یکی دیگه از خوبی هاش اینه که میتونی تمام ۴۰۴ ها رو هم حتی برای خودت لاگ بندازی

Route::fallback([ErrorController::class, 'notFound']);
‍‍‍

💬 حالا شما بگید:

آیا تا حالا از fallback route استفاده کردید؟ یا همیشه صفحه‌ی 404 پیش‌فرض لاراول رو دیدید؟ 😄

———————————————————————————
@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه‌ای php و لاراول

در کانال تلگرامی CodeFuse من سعی میکنم چالش هایی که باهاش روبرو می شوم رو به اشتراک بگذارم برای این که در کنار ما باشید و به‌روز باشید، به ما بپیوندید! 👇👇

https://t.me/codefuse1

چالش لاراولی : ⏱️ ۳ دقیقه زمان داری! خروجی این کد Laravel چیه؟ (و چرا؟)

سلام رفقا حالتون چطوره ؟

من علیرضام اینجاییم که باهم رشد کنیم، چیزای جدید یادبگیریم، به روز باشیم ، برای این که دلم برای گفتگو با هاتون تنگ شده گفتم بیام یک چالش درست کنم که کمی باهم گپ بزنیم

🎯 بریم سراغ چالش امروز

Route::get('/challenge', function () {
    $data = collect([1, 2, 3, 4]);

    $result = $data->filter(function ($item) {
        return $item % 2 === 0;
    })->map(function ($item) {
        return $item * 2;
    })->reduce(function ($carry, $item) {
        return $carry + $item;
    });

    return $result;
});

✍️ خروجی این کد چیه؟ چرا؟ توی کامنت‌ها بنویس 👇

در کد فوق filter / map / reduce چه کاری رو انجام میدهند ؟

تحلیل این گونه کدها از پاسخ صحیح هم مهم تر است

———————————————————————————
@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه‌ای php و لاراول

🌍تا حالا با Asymmetric Visibility توی PHP 8.4 کار کردین؟

اگه با PHP کد می‌زنی، این قابلیت جدید توی نسخه 8.4 خیلی به کارت میاد!

یکی از قابلیت‌های جدید و دوست‌داشتنی در PHP 8.4 اینه که می‌تونی سطح دسترسی خواندن (read) و نوشتن (write) روی یک ویژگی (property) رو جدا جدا مشخص کنی.

⛔ توی نسخه‌های قبلی PHP فقط می‌تونستی بگی یه پراپرتی public باشه یا private یا protected. یعنی:

اگه public باشه => از بیرون کلاس هم می‌تونن بخونن و هم تغییرش بدن

اگه private باشه => فقط از داخل کلاس قابل دسترسه، حتی خوندنش هم از بیرون ممکن نیست

این موضوع باعث می‌شد اگه بخوای یه پراپرتی فقط قابل خوندن باشه، مجبوری بشی یه متد جداگانه مثل getVersion() بنویسی.

✅ ولی حالا توی PHP 8.4 می‌تونی:

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

و فقط از درون کلاس اجازه‌ی تغییرش وجود داشته باشه.

🧪بزارید با یک مثال واقعی - قبل از PHP 8.4 رو باهم ببینیم :

class PhpVersion

{
    private string $version = '8.3';

    public function getVersion(): string
    {

        return $this->version;
    }

    public function increment(): void

    {
        [$major, $minor] = explode('.', $this->version);
        $minor++;
        $this->version = "{$major}.{$minor}";
    }

}

که به این صورت هم استفاده میکردیم
‍‍‍

$php = new PhpVersion();

echo $php->getVersion();

و برای گرفتن مقدار version باید حتما از getVersion استفاده میکردیم

و ایجاد این Getter ها حجم کد مون رو زیاد تر میکرد و در php 8.4 یک ویژگی جدید اومده که کدهامون تمیز تر باشه


✅ حالا در PHP 8.4:

class PhpVersion

{

    public private(set) string $version = '8.4';

    public function increment(): void

    {
        [$major, $minor] = explode('.', $this->version);
        $minor++;
        $this->version = "{$major}.{$minor}";
    }

}

✅ اینجا داریم یه ویژگی به اسم version تعریف می‌کنیم که:

مقدار public یعنی: از بیرون کلاس دسترسیش باز هست و میتونی بخونیش و بهش دسترسی داشته باشی

و مقدار private(set) یعنی : از بیرون نمی‌تونی مقدارشو تغییر بدی، ولی از داخل کلاس قابل تغییر هست

مثال از استفاده آن :

$php = new PhpVersion();

echo $php->version;

ولی از داخل کلاس هنوز می‌تونه مقداردهی بشه مثل متد increment() بالا

بیرون کلاس اگر تلاش کنید مقدارش رو تغییر بدید مثل زیر :

‍‍‍

php
php
$php = new PhpVersion();
$php->version = 8
‍‍‍‍‍‍‍

خطا دریافت میکنید چون از بیرون کلاس امکان تغییر اون بسته شده است

📌 نتیجه: دیگه لازم نیست برای یه ویژگی فقط-خواندنی، متد getX() بنویسی. کدت هم تمیزتره، هم امن‌تره، هم خواناتر.

❤️ اگه این آموزش برات مفید بود: لایک کن، برای رفقات بفرست

و اگه سوالی داری همینجا بپرس، جواب می‌دم با کمال میل! ✌️

📣 آموزش‌های بیشتر در: @codefuse1 – کُدفیوز | نکات حرفه‌ای PHP و لاراول به زبان ساده

❓ آیا از ویژگی جدید #[\Deprecated] در PHP 8.4 خبر داری؟ 🚨

تو نسخه‌های قبل از PHP 8.4 فقط می‌تونستیم با کامنت @deprecated هشدار بدیم که یه تابع یا متد دیگه قدیمی شده. ولی هیچ اخطار واقعی موقع اجرا داده نمی‌شد 😐

اما حالا در PHP 8.4 با ویژگی #[\Deprecated] خود PHP این کارو به‌صورت واقعی و قابل اجرا انجام می‌ده 💥

بزارید بایک مثال این رو باهم بررسی کنیم:

فرض کن قبلاً تو یه پروژه‌ی فروشگاه آنلاین، از متدی به اسم applyDiscountManually() استفاده می‌کردی ولی حالا یه سیستم جدید و امن‌تر ساختی به اسم applyDiscountWithRules().

💡 حالا می‌خوای به بقیه‌ی برنامه‌نویس‌ها بفهمونی که متد قبلی منسوخ شده و نباید استفاده شه.

📌 کد قبل از PHP 8.4:

class OrderService {
    /**
     * @deprecated از applyDiscountWithRules استفاده کن
     */
    public function applyDiscountManually($amount) {
        // منسوخ شده
        return $amount - 10000;
    }

    public function applyDiscountWithRules($amount) {
        // منطقی و امن
        return $amount * 0.9;
    }
}
$order = new OrderService();
echo $order->applyDiscountManually(100000); // اخطاری نمی‌گیری!

📌 حالا در PHP 8.4:

class OrderService {
    #[\Deprecated(
        message: "از applyDiscountWithRules استفاده کن",
        since: "8.4"
    )]
    public function applyDiscountManually($amount) {
        return $amount - 10000;
    }

    public function applyDiscountWithRules($amount) {
        return $amount * 0.9;
    }
}
$order = new OrderService();
echo $order->applyDiscountManually(100000);
// ⚠️ Deprecated: Method applyDiscountManually is deprecated since 8.4...

✅ به همین راحتی با #[\Deprecated] هم مستندسازی می‌کنی، هم در زمان اجرا هشدار واقعی می‌دی. این یعنی کد حرفه‌ای‌تر، تیم منسجم‌تر، و کمتر شدن باگ‌هایی که از استفاده از توابع قدیمی به‌وجود میان! 👨‍💻✨

چطور جلوی Double Transaction یا Duplicate Payment رو میگیری؟

👀 خیلی کنجکاوم بدونم شما چه راهکاری برای این سناریو پیشنهاد میدید؟

✍🏻 نظرتون رو بنویسید...

💬 حالا تجربه خودم:

ابتدا بزارید یک سناریو رو باهم در نظر داشته باشیم

سناریو اینه که فرض کن توی یه اپلیکیشن کاربر میخواد کیف پول خودش رو شارژ کنه.

مثلاً میخواد ۵۰۰ هزار تومن شارژ کنه. ولی ممکنه این بلاها سر سیستم بیاد:

کاربر دو بار روی دکمه "پرداخت" کلیک کنه ، اینترنت قطع و وصل بشه و کاربر صفحه پرداخت رو دوباره لود کنه.

عمداً درخواست پرداخت رو تو چند تب یا ابزار Postman تکرار کنه.

اگه مراقب نباشیم، همون مبلغ چندبار به کیف پول اضافه میشه!

فاجعه چیه؟ کاربر ۵۰۰ هزار تومن پرداخت کرده ولی موجودیش ۱ میلیون شده! 😵

توی پروژه‌های واقعی که روشون کار کردم، برای جلوگیری از این مشکل معمولاً چند روش ترکیبی استفاده کردم:

ایجاد یک transaction_token یکتا برای هر پرداخت و چک کردن اینکه فقط یکبار مصرف بشه.

قفل کردن ردیف دیتابیس (Row Locking) با lockForUpdate هنگام آپدیت موجودیت حساس (مثل سفارش یا کیف پول).

استفاده از صف (Queue) برای پردازش پرداخت‌ها و جلوگیری از شرایط مسابقه (Race Condition).

و البته، غیرفعال کردن دکمه پرداخت در فرانت‌اند بلافاصله بعد از کلیک (که بیشتر جنبه کمکی داره).

✅ در نهایت همیشه حواسمون هست که هیچ وقت به کاربر اعتماد نکنیم و لایه‌های حفاظتی قوی سمت سرور پیاده کنیم.

یک نمونه کد ساده برای جلوگیری از این مشکل :

‍‍

php
public function rechargeWallet(Request $request)
{
    $transactionId = $request->input('transaction_id');
    $amount = $request->input('amount');

    DB::transaction(function () use ($transactionId, $amount) {
        if (WalletTransaction::where('transaction_id', $transactionId)->exists()) {
            throw new \Exception('Duplicate transaction detected.');
        }

        WalletTransaction::create([
            'user_id' => auth()->id(),
            'transaction_id' => $transactionId,
            'amount' => $amount,
            'type' => 'recharge',
        ]);

        $wallet = Wallet::where('user_id', auth()->id())
                        ->lockForUpdate()
                        ->firstOrFail();

        $wallet->balance += $amount;
        $wallet->save();
    });

    return response()->json(['success' => true]);
}

اما lockForUpdate چی کار میکنه ؟

وقتی توی لاراول (یا کلاً دیتابیس) از lockForUpdate استفاده می‌کنی، داری به دیتابیس میگی:

«این رکوردی که الان دارم میخونم، تا وقتی تراکنشم کامل نشده، هیچ کس دیگه حق نداره تغییرش بده یا حتی بخونه و تغییر بده.»

———————————————————————————
@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه‌ای php و لاراول

در کانال تلگرامی CodeFuse من سعی میکنم چالش هایی که باهاش روبرو می شوم رو به اشتراک بگذارم برای این که در کنار ما باشید و به‌روز باشید، به ما بپیوندید! 👇👇

https://t.me/codefuse1

🚀 چطور با terminable middleware در لاراول فعالیت‌های کاربران را پیگیری کنیم؟ 🚀


تا حالا با متد terminate در middleware کار کردید ؟ ، اگر کار کردید خوشحال میشوم بگید کجا و چه کاربرد هایی برایتان داشته تا بقیه هم استفاده کنند اما اگر آشنا نیستید با من همراه باشید

فرض کنید در یک وب‌سایت یا برنامه، نیاز دارید که آخرین فعالیت هر کاربر (مثلاً ورود یا خروج از سیستم، بازدید از صفحات خاص و ...) را ذخیره کنید تا بتوانید گزارشاتی از رفتار کاربران در طول روز ایجاد کنید. در این حالت می‌توانیم از terminable middleware برای ثبت فعالیت‌های کاربران پس از هر درخواست استفاده کنیم.

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Log;

class TrackUserActivity
{
    public function handle(Request $request, Closure $next)
    {
        return $next($request);
    }

    public function terminate(Request $request, $response)
    {
        if (Auth::check()) {
            $user = Auth::user();
            $user->last_activity_at = now();
            $user->save();

            Log::info("User {$user->id} activity recorded at {$user->last_activity_at}");
        }
    }
}

در این مثال، ما یک middleware به نام TrackUserActivity داریم که پس از هر درخواست، آخرین زمان فعالیت کاربر را در دیتابیس به‌روز می‌کند. این کار به شما این امکان را می‌دهد که آخرین زمان فعالیت هر کاربر را ذخیره کنید و از آن برای نمایش گزارشات فعالیت یا مدیریت وضعیت کاربران استفاده کنید.

و بعد میتونید کاری کنید که به صورت عمومی در تمامی route ها اعمال بشه یا این که در route هایی که میخواهید دستی اعمال کنید

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

———————————————————————————
@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه‌ای php و لاراول

در کانال تلگرامی CodeFuse من سعی میکنم چالش هایی که باهاش روبرو می شوم رو به اشتراک بگذارم برای این که در کنار ما باشید و به‌روز باشید، به ما بپیوندید! 👇👇

https://t.me/codefuse1

🧠 وقتی هوش مصنوعی بهتر از من کد می‌نویسه، من باید چیکار کنم؟

📌 تجربه‌ی من از Vibe Coding با Laravel 👇

چند وقتیه با ابزارهایی مثل GPT، Copilot و Cloud.ai کار می‌کنم، و راستش بعضی وقتا حس می‌کنم دارم به یه دستیار خیلی حرفه‌ای تکیه می‌کنم 😅

👨‍💻 یه مثال واقعی از تجربه‌م:

لازم داشتم یه سیستم لاگ‌گیری ساده برای تغییر وضعیت محصولات توی پروژه‌ای با Laravel بنویسم.

📝 فقط اینو برای Cloud.ai نوشتم:

"In Laravel, create a service that logs changes to the is_active field of a product. Include the user ID, previous value, new value, and timestamp."

⏱ کمتر از ۳۰ ثانیه بعد بهم تحویل داد:

✅ Service class کامل با dependency injection
✅ Event/Listener برای ProductUpdated
✅ ثبت دقیق تغییرات در یک جدول جداگانه
✅ migration + مدل + حتی تست اولیه با pest!

و حالا سوالی که ذهنم رو درگیر کرد:
❓ اگه AI داره این‌قدر سریع و دقیق کد می‌نویسه، من قراره چه نقشی داشته باشم؟

🧩 جواب من:

من هنوزم اون کسی‌ام که باید منطق مسئله رو بفهمه، تصمیم بگیره چی لازمه، معماری رو بچینه، و خروجی رو validate کنه.

🛠 کدی که AI می‌نویسه، مثل آجره. اما ساختن خونه هنوز با منه.

🎯 الان تمرکز من روی:
– نوشتن Promptهای دقیق و واضح
– Refactor و بهینه‌سازی کدها
– طراحی درست سرویس‌ها و کنترل کیفیت

❓تو چی فکر می‌کنی؟
🤖 Cloud.ai یا ابزار های هوش مصنوعی کدوم رو تست کردی و نتیجه اش چی بوده؟
🤯 شده یه بار نتیجه‌ای بگیری که خودت باورش نشه؟

منتظرم نظرتو بدونم 👇

(اگه مفید بود بفرست واسه یکی دیگه از رفقا 👨‍💻)

———————————————————————————
@codefuse1 | کُدفیوز :‌ آموزش و نکات حرفه‌ای php و لاراول

در کانال تلگرامی CodeFuse من سعی میکنم چالش هایی که باهاش روبرو می شوم رو به اشتراک بگذارم برای این که در کنار ما باشید و به‌روز باشید، به ما بپیوندید! 👇👇

https://t.me/codefuse1

🔥 چرا یکی با هوش مصنوعی چند برابر جلو می‌افته و یکی آخرش میگه «به درد نمی‌خوره»؟

حدود یک سال و نیمه که هوش مصنوعی رو جدی وارد کار روزمره‌م کردم؛ از کدنویسی و دیباگ گرفته تا تحقیق، بازنویسی کد، مستندسازی و کار روی پروژه‌های واقعی.

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

بعضی چیزها رو از مستندات یاد گرفتم،
بعضی‌ها رو از تجربه،
و بعضی‌ها رو هم از صورتحساب API! 😅

یکی از مهم‌ترین چیزهایی که فهمیدم اینه:

📌 داشتن بهترین هوش مصنوعی، لزوماً به معنی گرفتن بهترین نتیجه نیست.

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

«هوش مصنوعی هنوز به درد کار واقعی نمی‌خوره.»

در حالی که شاید مشکل اصلاً پرامپت نبوده.

شاید از اول مدل اشتباهی رو برای اون کار انتخاب کرده.

پرامپت هنوز مهمه، ولی دیگه تمام بازی نیست.

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

برای همین من این روزها بیشتر از اینکه دنبال «پرامپت جادویی» باشم، به این سؤال‌ها فکر می‌کنم:

🔹 برای این کار چه مدلی مناسبه؟

🔹 چه میزان توان استدلالی یا Effort لازم داره؟

🔹 واقعاً چقدر Context باید در اختیارش بذارم؟

🔹 چه ابزارهایی باید در اختیارش باشه؟

🔹 چه Skillهایی واقعاً لازمه؟

🔹 و اصلاً این کار نیاز به Agent داره یا نه؟

اینجاست که تفاوت نتیجه‌ها شروع میشه.

گاهی یه مدل سبک‌تر همون کیفیتی رو که نیاز داری، سریع‌تر و خیلی ارزون‌تر می‌ده.

از اون طرف، ارزون‌ترین مدل هم همیشه اقتصادی‌ترین انتخاب نیست.

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

من خودم بخشی از این موضوع رو با تست مدل‌های مختلف و البته سوزوندن چندصد دلار API یاد گرفتم. 😅

احتمالاً خوندن این تجربه خیلی ارزون‌تر از تکرار کردنشه!

⚙️ بعد از انتخاب مدل، بحث Effort میاد وسط.

یه تغییر ساده توی کد با بررسی معماری یک سیستم بزرگ یکی نیست.

قرار نیست برای هر دو، مدل رو با یک تنظیم و یک میزان استدلال اجرا کنیم.

گاهی کیفیت مهم‌تره، گاهی سرعت و گاهی هزینه.

به نظرم انتخاب درست بین این‌ها خودش تبدیل شده به بخشی از مهارت کار با هوش مصنوعی.

🧩 بعد می‌رسیم به Skillها.

به‌جای اینکه هر بار از صفر توضیح بدی:

«این فایل‌ها رو بخون، این استانداردها رو رعایت کن، تست بزن و خروجی رو این شکلی بده...»

می‌تونی روش انجام اون کار رو تبدیل کنی به یه Skill که دوباره قابل استفاده باشه.

مثلاً برای بازبینی کد، تست، مستندسازی، ساخت API یا حتی قوانین اختصاصی پروژه خودت.

حتی لازم نیست همه‌شون رو از صفر بسازی؛ می‌تونی از Skillهای آماده شروع کنی، تغییرشون بدی و کم‌کم نسخه مخصوص خودت رو بسازی.

اما اینجا یه دام وجود داره:

❓ هرچی Skill بیشتر، بهتر؟

به نظرم نه.

وقتی تعداد Skillها زیادی میشه، یه جایی شبیه وابستگی‌های پروژه میشن؛ اول همه‌شون مفید به نظر می‌رسن، چند ماه بعد هیچ‌کس مطمئن نیست حذف کدوم یکی قراره چه چیزی رو منفجر کنه. 😄

هنر اصلی داشتن Skill زیاد نیست؛ داشتن Skill درست برای کار درسته.

و تازه بعد از این می‌رسیم به قسمت‌های جذاب‌تر:

🤖 عامل‌های هوش مصنوعی (AI Agents)
🧠 حافظه (Memory)
🛠 ابزارها (Tools)
⏰ زمان‌بندی (Schedule)
🔄 گردش‌کارهای هوشمند و تصمیم‌گیر (Agentic Workflows)

اینجا دیگه هوش مصنوعی فقط جواب سؤال نمی‌ده؛ می‌تونه کار رو جلو ببره، نتیجه رو بررسی کنه و برای مرحله بعد تصمیم بگیره.

و دقیقاً از همین‌جا سؤال‌های جدی‌تر شروع میشن:

🔹 تفاوت Skill، Agent و Memory دقیقاً چیه؟

🔹 آیا Context بیشتر همیشه نتیجه بهتری می‌ده؟

🔹 عامل هوش مصنوعی چه زمانی واقعاً مفیده و چه زمانی فقط داره توکن مصرف می‌کنه؟ 😅

🔹 وقتی سیستم خودش می‌تونه تصمیم بگیره، ابزارهایی مثل n8n کجای داستان قرار می‌گیرن؟

این سری قراره بیشتر از جنس تجربه باشه تا ترجمه مستندات.

📌 توی قسمت‌های بعد می‌ریم سراغ:

🔹 انتخاب مدل مناسب برای هر کار

🔹 تنظیم درست Effort و کنترل هزینه

🔹 ساخت و انتخاب Skillهای خوب

🔹 تفاوت Skill، Agent و Memory

🔹 مدیریت درست Context

🔹 اینکه Agent دقیقاً کجا ارزش استفاده داره

🔹 مقایسه n8n با گردش‌کارهای Agentic

🔹 و در نهایت ترکیبی که خودم برای کارهای مختلف استفاده می‌کنم

و شاید سؤال اصلی کل این سری همین باشه:

👀 چرا دو نفر که به یک هوش مصنوعی دسترسی دارن، می‌تونن دو نتیجه کاملاً متفاوت بگیرن؟