وقتی شما از Request دیتایی دریافت میکنی، معمولاً مقدار ورودی به صورت رشته string هستش.
اما گاهی لازم داری که مقدار ورودی رو به نوع خاصی مثل integer ، boolean، array, ،date یا enum تبدیل کنی.

قبلاً باید خودت دستی این تبدیل هارو انجام میدادی، مثلاً با استفاده از (int) یا boolval() یا کدهای مشابه. ولی توی نسخه جدید لاراول ، متودهایی مثل integer(), boolean(), array(), date(), و enum() بهت اجازه میدن که به سادگی و مستقیم ورودی رو به نوع مورد نظرت تبدیل کنی.

📌 یه مثال:

$age = $request->integer('age');     
  // مقدار 'age' رو به عدد صحیح تبدیل می‌کنه

$isActive = $request->boolean('active');
 // مقدار 'active' رو به true یا false تبدیل می‌کنه

$tags = $request->array('tags');   
    // مقدار 'tags' رو به آرایه تبدیل می‌کنه

بدون نیاز به تبدیل دستی، کد تمیزتر و خواناتری داری.
#Laravel

@GoldenCodeir

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1952304768493277191?s=35

نکته مهم برای کوئری‌های MySQL

اگه روی یک ستون دیتابیس ایندکس تعریف شده، استفاده از توابعی مثل YEAR(), MONTH() یا هر تابع دیگه ای روی همون ستون در شرط‌های WHERE باعث میشه MySQL نتونه از ایندکس استفاده کنه.

📌 چرا؟

چون وقتی تابعی روی ستون اعمال میشه، مقدار ستون تغییر میکنه و ایندکس روی مقدار اصلی ستونه، نه مقدار تبدیل‌شده توسط تابع.
در نتیجه MySQL مجبور میشه کل جدول رو اسکن کنه (Full Table Scan) که عملکرد کوئری رو به شدت کاهش میده.

مثال

فرض کنین روی ستون تاریخ paid_at ایندکس دارید و میخواید رکوردهای مربوط به سال 2023 رو بگیرید.

روش اشتباه:

WHERE YEAR(paid_at) = 2023

درین حالت، MySQL برای هر ردیف ابتدا تابع YEAR() رو اجرا میکنه و سپس مقایسه میکنه، که باعث غیرفعال شدن ایندکس میشه.

روش بهینه:

WHERE paid_at >= '2023-01-01' AND paid_at < '2024-01-01'

درین حالت شرط مستقیماً روی ستون paid_at اعمال میشه و MySQL میتونه از ایندکس استفاده کنه، بنابرین کوئری بسیار سریعتر اجرا میشود.
#SQL
#MySql

@GoldenCodeir

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1952704402038333586?s=35

نمایش فایل در مرورگر بجای دانلود( لاراول):

گاهی در پروژه‌ها لازم داری یک فایل (مثل PDF یا تصویر) مستقیما در مرورگر باز بشه و دانلود نشه!
لاراول برای این کار متود ساده و تمیز response()->file() رو داره.

📌 مثال:

Route::get('/manual', function () {
    $path = storage_path('app/public/manual.pdf');
    return response()->file($path);
});

با این کار، مرورگر سعی میکنه PDF رو inline نمایش بده.

حالا تفاوتش با download() چیه؟

file() → نمایش فایل در مرورگر (inline)
download() → دانلود اجباری فایل


📌 نکات مهم:

1. مرورگر فقط فایل‌های پشتیبانی‌شده (مثل PDF، JPG، PNG، TXT) رو نمایش میده.

2. بعضی تنظیمات مرورگر یا افزونه‌ها ممکنه باعث دانلود اجباری بشن.

3. مسیر فایل باید معتبر باشه (storage_path() یا public_path()).

4. میتونی MIME-Type رو خودت مشخص کنی:

return response()->file($path, [
    'Content-Type' => 'application/pdf'
]);

#Laravel

@GoldenCodeir

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1955203877453590922?s=35

وقتی در لاراول داده‌ها رو با Model::all() می‌گیریم، نتیجه همیشه یک Collection هست.
اما می‌تونیم برای هر مدل، یک کالکشن اختصاصی تعریف کنیم.

🔹 فایدش چیه؟

متودهای مخصوص لیست داده‌ها رو فقط یک‌بار تعریف میکنی.

منطق کار با لیست‌ها (مثل فیلترها) از مدل جدا میشه.

کدت خواناتر و دامین‌محورتر میشه.

نمونه عملی:

// کالکشن اختصاصی
class PostCollection extends Collection {
    public function published() {
        return $this->filter(fn($post) => $post->is_published);
    }
}

// اتصال به مدل
class Post extends Model {
    public function newCollection(array $models = []) {
        return new PostCollection($models);
    }
}

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

$posts = Post::all()->published();

حالا هر وقت Post::all() رو صدا بزنی، علاوه بر متودهای پیش فرض کالکشن، متد اختصاصی published() هم در دسترسه.

📌 نتیجه: دیگه نیاز نیست یک منطق رو بارها تکرار کنی یا دستی فیلتر بزنی.
#Laravel

@GoldenCodeir

(به منبع و مثالش دقت کنید👇🏾)
https://x.com/mmartin_joo/status/1955241116992741659?s=19

یکی از چالشای رایج در اپلیکیشن‌های تحت وب اینه که اجرای مکرر کوئری‌های دیتابیس باعث کندی برنامه و افزایش فشار روی سرور میشه.

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

نتیجه؟
سرعت بالاتر
کاهش بار روی دیتابیس
تجربه‌ی بهتر برای کاربر

📌 روش‌های اصلی کار با Cache در لاراول

1. ذخیره‌ی موقت دیتا (remember)

وقتی دیتا ای رو می‌خوایم برای مدت مشخصی نگه داریم:

$posts = Cache::remember('posts', 60, function () {
    return Post::all();
});

داده‌ی posts برای ۶۰ ثانیه در کش میمونه.
اگر وجود داشته باشه، دیگه کوئری اجرا نمیشه.
اگه وجود نداشته باشه، کوئری اجرا میشه و نتیجه ذخیره میشه.

2. ذخیره‌ی دائمی دیتا (forever)

برای داده‌هایی که به‌ندرت تغییر میکنن:

Cache::forever('settings', $settings);

این داده هیچ وقت منقضی نمی‌شه.
فقط وقتی با forget پاکش کنیم از کش حذف می‌شه.


3. ذخیره و دریافت مستقیم (put, get)

Cache::put('key', 'value', 300); // ذخیره به مدت 300 ثانیه
$value = Cache::get('key');      // دریافت داده

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


4. حذف داده‌های کش شده

Cache::forget('posts'); // حذف یک کلید خاص
Cache::flush();         // حذف همه داده‌های کش

🔹 و forget برای حذف داده‌ی مشخص استفاده میشه.
🔹و flush همه کش‌ها رو یک‌جا خالی میکنه (مثلاً در زمان توسعه).


5. کار با چندین استور کش

لاراول از استورهای مختلف مثل Redis, Memcached, Database یا File پشتیبانی میکنه:

Cache::store('redis')->put('bar', 'baz', 10);

این قابلیت انعطاف بالایی میده و میتونید بر اساس نیاز پروژه، استور مناسب انتخاب کنین.

6. گروه‌بندی کش با تگ‌ها (Tags)

وقتی بخواین چندین کش مرتبط رو مدیریت کنین:

Cache::tags(['people', 'authors'])->put('Anne', $anne, 120);
Cache::tags('authors')->flush();

🔹 با tags میتونین گروهی از کش‌ها رو حذف کنین بدون اینکه بقیه دیتاها پاک بشن.


7. استفاده از rememberForever

برای داده‌هایی که تقریبا ثابت هستن:

$setting = Cache::rememberForever('website_denoscription', function () {
    return App\Models\Setting::firstWhere('name', 'website_denoscription');
});

🔹 مثل forever کار میکنه ولی ترکیب با callback داره.
🔹 مناسب برای دیتاهایی که همیشه به یک شکل نیاز داریم.


📌 چه دیتا هایی رو بهتره کش کنیم؟

لیست مقالات یا محصولات پر بازدید
دسته‌بندی‌ها و منوهای سایت
تنظیمات عمومی سایت
نتایج کوئری‌های سنگین و پرتکرار

خلاصه:

از کش برای داده‌های پر مصرف و کم تغییر استفاده کنید.
با remember داده رو موقت ذخیره کنین.
با forever یا rememberForever داده‌های ثابت رو نگه دارین.
با forget و flush داده‌ها رو بروز یا پاکسازی کنین.

در پروژه‌های بزرگ، از استورهای حرفه‌ای مثل Redis برای مدیریت کش استفاده کنین.

با مدیریت درست کش، اپلیکیشن لاراولی شما نه‌تنها سریع‌تر میشه، بلکه دیتابیس هم نفس راحتی می‌کشه!
#Laravel

@GoldenCodeir
(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/laravelbackpack/status/1957404629148611054?s=1

🔥 تفاوت جاوااسکریپت و تایپ‌اسکریپت

جاوااسکریپت یه زبان Dynamic هست یعنی تایپ داده‌ها رو موقع اجرا مشخص می‌کنه و این باعث میشه گاهی با خطاهای عجیب روبرو بشی
تایپ‌اسکریپت اومده تا این مشکل رو حل کنه و به جاوااسکریپت قدرت Static Typing بده یعنی از همون اول تایپ متغیرها رو مشخص کنی و قبل از اجرا خطاها رو ببینی
در واقع تایپ‌اسکریپت مثل یه لایه امن روی جاوااسکریپت عمل می‌کنه و کدتو تمیزتر و قابل پیش‌بینی‌تر می‌کنه
یه نکته مهم بدون تایپ‌اسکریپت تبدیل به جاوااسکریپت میشه پس برای اجرا همیشه به JS برمی‌گرده

#TypeScript #JavaScript

CODELAB | GpCodeLab

نکته امنیتی در لاراول

وقتی کاربر لاگینه، بصورت پیش‌فرض میتونه به همه‌ی Route هایی که با Middleware auth محافظت شدن دسترسی داشته باشه.
اما برای عملیات‌های حساس مثل:

حذف حساب کاربری،

تغییر رمز عبور یا ایمیل،

عمومی‌کردن یک ریپازیتوری،


بهتره مطمئن بشیم کاربر دوباره رمز عبور خودشو وارد کنه. این کار باعث میشه اگه کسی بطور موقت به سیستمش دسترسی داشت، نتونه تغییرات جدی ایجاد کنه.

برای این موضوع، لاراول میدلوری آماده‌ داره به نام:

->middleware(['auth', 'password.confirm'])

با افزودنش به Route موردنظر:

اگه کاربر اخیراً رمزو تأیید نکرده باشه (پیش‌فرض: ۳ ساعت گذشته باشه)، لاراول اونو به صفحه‌ی تأیید رمز هدایت میکنه.

پس از وارد کردن صحیح رمز، عملیات ادامه پیدا میکنه.

مثال:

Route::delete('/account', [AccountController::class, 'destroy'])
    ->middleware(['auth', 'password.confirm']);

📌 این روش، امنیت برنامه رو بالا میبره و مانع سوءاستفاده‌ی افراد غیرمجاز از Session کاربر میشه.
#Laravel

@GoldenCodeir

(به منبع و مثالش دقت کنین👇🏾)
https://x.com/PovilasKorop/status/1959190135313989925?t=5aL0dPVcclbcVOF4-4iMDA&s=19

فکت:
برنامه نویسی یاد گرفتن فقط ۳۰ درصد پول در آوردن از برنامه نویسیه.

۳۰ درصدش درست معرفی کردنه

۴۰ درصدش شبکه سازیه

از نسخه ۱۱ لاراول میتونی توی فایل bootstrap/app.php با متود withRouting() نحوه‌ی بارگذاری روت‌ها رو کاملاً شخصی‌سازیشون کنی.

کاربردهاش:

ساخت فایل‌های روت اختصاصی (مثلاً routes/admin.php)

تغییر prefix پیش‌فرض برای API

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


مثال:

return Application::configure(basePath: dirname(DIR))
    ->withRouting(
        web: DIR.'/../routes/web.php',
        api: DIR.'/../routes/api.php',
        then: function () {
            require base_path('routes/admin.php'); // روت‌های پنل ادمین
        }
    )
    ->withMiddleware()
    ->withExceptions()
    ->create();

با این قابلیت، نیازی به دستکاری RouteServiceProvider نداری و همه‌چیز خیلی تمیز و متمرکز میشه.
#Laravel

@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1961019184587969014?s=35

کوئری‌های دیتابیس که زمان زیادی میبرند باعث کندی برنامه میشن و بار اضافی روی سرور ایجاد میکنن. Laravel یک روش ساده برای شناسایی و لاگ کردن کوئری‌های کند داره.

🔹 لاگ کردن کوئری‌های طولانی

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

DB::listen(function ($query) {
    if ($query->time > 100) { // میلی‌ثانیه
        Log::warning("⏱ Slow Query: {$query->time}ms; SQL: {$query->sql}");
    }
});

این کد فقط کوئری‌های بیشتر از 100 میلی‌ثانیه رو ثبت میکنه و به راحتی میشه اونارو شناسایی کرد.
.

با شناسایی کوئری‌های کند و اجرای بهینه‌سازی‌های ساده، سرعت برنامه افزایش یافته و تجربه کاربر بهبود پیدا میکنه.

📌 نکته: حتی لاگ کردن کوئری‌های کمی طولانی‌تر از حد معمول میتونه مشکلات پنهان دیتابیس رو نشان بده.
#Laravel

@GoldenCodeir

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/laravelbackpack/status/1962840547317731790?s=35

نکته Boot Traits با Attribute ها

🔹 قبلاً وقتی توی لاراول میخواستیم داخل یک Trait متودی بذاریم که به صورت خودکار موقع Boot شدن مدل اجرا بشه، مجبور بودیم اسم متود رو دقیقاً طبق contract بنویسیم:

trait HasSomething {
    protected static function bootHasSomething()
    {
        // کد اجرا هنگام Boot
    }
}

مشکلش این بود که همیشه باید اسم متود رو boot + اسم Trait میذاشتیم. نه انعطاف داشت و نه خوانا بود.

✅ از لاراول 12.22 به بعد، این محدودیت برداشته شده.
یعنی میتونیم با استفاده از PHP Attributes هر متودی رو برای Boot علامت‌گذاری کنیم، بدون نیاز به نام‌گذاری اجباری:

use Illuminate\Database\Eloquent\Attributes\Booted;

trait HasSomething
{
    #[Booted]
    public static function initializeSomething()
    {
        // این متد هر وقت مدل Boot بشه اجرا میشه
    }
}

مهم نیست اسم متود چی باشه، کافیه Attribute #[Booted] رو اضافه کنی. لاراول خودش متوجه میشه که این متود باید هنگام Boot اجرا شه.
#Laravel #لاراول

@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/OussamaMater/status/1963339643140833741?t=wz9DcZRTw9IvVmbBBZ1_9g&s=35

🔶 مهندسان نرم‌افزار عزیز،

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

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

#توییت

@TheRaymondDev

گاهی در API یا فرم‌ها نیاز داری مطمئن بشی یک آرایه ورودی دقیقا شامل کلیدهایی باشه که انتظار داری. از لاراول 10.9 به بعد میتونی بهراحتی با rule جدید required_array_keys این کارو انجام بدی.

📌 مثال:

فرض کن ورودیه API به این شکل میاد:

{
  "user": {
    "name": "Ali",
    "email": "ali@example.com"
  }
}

برای اینکه مطمئن بشیم حتما کلیدهای name و email داخل user وجود دارن، کافیه اینطوری بنویسیم:

$request->validate([
    'user' => ['required', 'array', 'required_array_keys:name,email'],
]);

حالا اگه یکی از این کلیدها در ورودی نبود، لاراول خطا میده.

این روش خیلی تمیزتر و کوتاه‌تر از نوشتن چندین rule برای هر فیلده و مخصوصا در API ها بسیار کاربردیه.
#Laravel  #لاراول

@GoldenCodeir
(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1964988360193155402?s=35

مفهوم Trade-off در توسعه نرم‌افزار
(تعادل میان مزایا و معایب در تصمیم‌های فنی)

در توسعه نرم‌افزار، هیچ تصمیمی رایگان نیست. هر انتخابی، در کنار مزایا، هزینه‌ها و محدودیت‌هایی هم دارد. Trade-off یعنی برقراری تعادل میان این مزایا و معایب، و انتخاب بهترین گزینه متناسب با شرایط واقعی پروژه.

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

و در دنیای نرم‌افزار:

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

تفاوت در معیارهای سنجش
نکته مهم دیگر این است که معیارهای سنجش در هر پروژه متفاوت است:

- یک استارتاپ ممکن است سرعت رسیدن به بازار را مهم‌تر بداند.
- یک سیستم بانکی احتمالاً امنیت و پایداری بلندمدت را در اولویت قرار می‌دهد.
- یک پروژه تحقیقاتی شاید بیشتر به انعطاف‌پذیری و نوآوری اهمیت دهد.

بنابراین حتی اگر دو تیم روی یک زبان یا فریم‌ورک واحد بحث کنند، ممکن است از زاویه‌های متفاوتی آن را ارزیابی کنند و به نتایج متفاوتی برسند.


به همین دلیل، انتخاب زبان، ابزار یا فریم‌ورک هیچ‌وقت یک پاسخ مطلق «بهترین» ندارد.
سؤال درست این نیست که کدام بهترین است؟
بلکه این است که کدام گزینه با توجه به نیازهای فعلی پروژه و توان تیم، بهترین تعادل (Trade-off) را فراهم می‌کند؟

Source

#trade_off

@Syntax_fa

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

لاراول از نسخه‌های جدید متود Rule::anyOf() رو معرفی کرده که این نیاز رو خیلی تمیز حل میکنه.


📌 مثال :
کاربر میتونه برای تماس یا ایمیل بده یا شماره موبایل.

use Illuminate\Validation\Rule;

$request->validate([
    'contact' => [
        Rule::anyOf([
            ['email'],
            ['regex:/^09\d{9}$/'], // شماره موبایل ایران
        ])
    ]
]);

✅ اگه ایمیل معتبر وارد بشه → اوکی
✅ اگه شماره موبایل معتبر وارد بشه → اوکی
❌ اگه هیچکدوم درست نباشه → خطای ولیدیشن

مزیت‌هاش چیه؟

تمیزتر و قابل‌خواندن‌تر از شرط‌های پیچیده

کاربردی برای ورودی‌هایی که میتونن فرمت‌های متفاوت داشته باشن (مثل کد ملی یا پاسپورت، کارت بانکی یا شبا و …)

با Rule::anyOf() میتونی ولیدیشن‌های انعطاف‌پذیر بسازی، بدون نیاز به شرط‌گذاری‌های اضافی و کدهای شلوغ.

#Laravel #لاراول

@GoldenCodeir

(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/PovilasKorop/status/1966051846386012636?t=Erp47hWetRxKXZ7pKJ_GSA&s=3

به افتخار ذهن‌هایی که از دل صفر و یک، جهانی سرشار از امکان می‌سازند؛ روز برنامه‌نویس مبارک ❤️‍🔥 🫡 🙏🏽

یکی از قابلیت های جالبه لاراول اینه که میتونی خیلی ساده برای APIها محدودیت درخواست (Rate Limit) بذاری.
ولی جذابتر اینه که محدودیت میتونه بر اساس شرایط مختلف اعمال بشه،

مثلا:

🔹 اگه کاربر عضو تیم باشه → محدودیت بر اساس team_id

🔹 اگه کاربر پلن اشتراکی داشته باشه → محدودیت بر اساس نوع پلن

🔹 و اگه هیچکدوم نبودش → محدودیت پیش‌فرض بر اساس IP

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

📌 نمونه کد در RouteServiceProvider:

use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;

RateLimiter::for('api', function (Request $request) {
    if ($request->user()?->team_id) {
        // محدودیت مشترک برای کل تیم
        return Limit::perMinute(100)->by($request->user()->team_id);
    }

    if ($request->user()?->plan) {
        // محدودیت بر اساس پلن کاربر
        return Limit::perMinute(200)->by($request->user()->id);
    }

    // محدودیت پیش‌فرض برای آی‌پی
    return Limit::perMinute(60)->by($request->ip());
});

🔥 با همین چند خط کد، میتونی مدیریت مصرف API رو هوشمند و حرفه‌ای کنی، طوریکه هم کاربرا تجربه بهتری دارن، هم از تلاش های مخربه برخی کاربرا جلوگیری میشه.
#Laravel #لاراول

@GoldenCodeir

(به منبع و مثالش دقت کنید👇🏾)
https://x.com/wendell_adriel/status/1967552508647071760?s=35