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

جاوااسکریپت یه زبان 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

یکی از دغدغه‌های مهم در طراحی API اینه که اطلاعات اضافی نفرستیم.

چون:

حجم ریسپانس ها زیاد میشه و حجم منابع سرور افزایش پیدا میکنه و...

لاراول یه راهکار خیلی تمیز برای این موضوع داره: استفاده از API Resource‌ها.

🔹 مشکل رایج

فرض کنید می‌خوایم اطلاعات یک کاربر رو همراه با پست‌هاش برگردونیم.
معمولا شاید اینطوری عمل کنیم:

return [
    'id' => $this->id,
    'name' => $this->name,
    'posts' => PostResource::collection($this->posts),
];

اینجا یه مشکل هست: حتی اگر posts رو لود نکرده باشیم، باز هم کلید posts توی JSON میاد (و معمولا query اضافه اجرا میشه).

لاراول متودی به اسم whenLoaded داره. این متود بررسی میکنه که آیا relation مورد نظر واقعاً لود شده یا نه.

return [
    'id' => $this->id,
    'name' => $this->name,
    'posts' => PostResource::collection($this->whenLoaded('posts')),
];

✅ نتیجه:

اگر توی query نوشتیم:

User::with('posts')->get();

اون موقع posts داخل JSON میاد.

اگر with('posts') رو ننوشتیم، اصلا posts توی خروجی دیده نمیشه.


📌 مزایا

شماره ۱ : API سبک‌تر → فقط دیتاهایی که لازم داری ارسال میشن.


شماره ۲: کد تمیزتر → دیگه خبری از if/else‌ های شلوغ داخل Resource نیست.


شماره۳: کنترل کامل → هر relation فقط وقتی لود شده باشه به خروجی اضافه میشه.

خلاصه که:

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

@GoldenCodeir

#Laravel #لاراول

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

مفهوم D (Durability) در ACID

وقتی یک transaction در دیتابیس COMMIT میشه، باید مطمئن باشیم تغییراتش برای همیشه ذخیره شدن و حتی در صورت قطع برق یا crash سیستم از بین نمیرن. این همون Durability (ماندگاری) هستش.

💡یه مثال :
وقتی پول از حساب بانکیت به حسابه دوستت منتقل میشه و پیام "انتقال موفق بود" میگیری، حتی اگه برق دیتاسنتر قطع بشه، دیتابیس تضمین میکنه که تراکنش انجام شده . این همون Durability هستش.


📌 روش‌های اصلی برای تضمین Durability:

شماره ۱. Write-Ahead Logging (WAL)

تغییرات ابتدا در WAL ثبت میشن و بعدش روی داده‌های اصلی اعمال میشن.
تا زمانیکه تغییرات در WAL ثبت نشده باشن، هیچ تضمینی برای ماندگاری داده‌ها وجود نداره.
✅ در صورت crash، تراکنش های commit شده با WAL قابل بازیابی هستنن.


شماره ۲. Redo / Undo Logs

بخش Redo: مکانیزمی برای بازگرداندن تغییرات تراکنش‌های commit شده پس از crash

بخش Undo: مکانیزمی برای rollback تراکنش‌های ناقص یا aborted

📌 رایج در Oracle و SQL Server و بخش مهمی از Crash Recovery هستش.


شماره ۳. fsync / Force-write

بعده هر COMMIT، داده‌ها از حافظه کش و OS به دیسک واقعی منتقل میشن.
این کار امنیت داده‌ها رو بالا میبره، اما سرعت transaction هارو کمی کاهش میده.


شماره ۴. Replication & Backup

تغییرات میتونن روی سرورهای دیگه کپی بشن یا snapshot گرفته بشن.

📌 این روش‌ها به تنهایی Durability رو تضمین نمیکنن و بیشتر برای Disaster Recovery کاربرد دارن.

Trade-off بین سرعت و ماندگاری (Performance vs Durability)

حالت strict: بعده هر transaction، همه تغییرات حتما روی دیسک نوشته میشن. درین حالت Durability بالاست، اما سرعت transaction ها کمتر خواهد بود.

حالت lazy: تغییرات ممکنه کمی دیرتر روی دیسک نوشته بشن. درین حالت سرعت transaction هابالاتره، اما Durability کمی پایینتر خواهد بود.

📌 مثال در دیتابیس‌ها

PostgreSQL – synchronous_commit:

وقتی این تنظیم فعال باشه، بعده هر transaction، تغییرات حتما روی دیسک نوشته میشن تا Durability تضمین بشه. اگه غیرفعال باشه، transaction سریعتر انجام میشه ولی ممکنه تغییرات کمی دیرتر روی دیسک ذخیره بشن.

MySQL – innodb_flush_log_at_trx_commit:

اگه مقدار این پارامتر روی 1 باشه، بعده هر transaction، تغییرات فورا روی دیسک نوشته میشن (Durability بالا، سرعت کمتر). اگه مقدار روی 2 یا 0 باشه، سرعت بالاتره ولی ممکنه در صورت crash، آخرین transaction ها از دست برن.

#ACID #دیتابیس

@GoldenCodeir 🔥

خیلی مواقع بعده گرفتنه داده از دیتابیس، نیاز داریم سریع و تمیز به اطلاعات دسترسی داشته باشیم.
تابع array_column در PHP دقیقا برای همین ساخته شده!

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

میتونه از یک آرایه چندبعدی، فقط یک ستون رو جداکنه.

حتی میتونه آرایه رو با کلید دلخواهتون reindex کنه.

این یعنی: دیگه لازم نیست هر بار روی آرایه حلقه بزنی و جستجو کنی، دسترسی مستقیم داری.

📌 یه مثال:

$users = [
    ['id' => 1, 'name' => 'Ali',  'email' => 'ali@example.com'],
    ['id' => 2, 'name' => 'Sara', 'email' => 'sara@example.com'],
    ['id' => 3, 'name' => 'Reza', 'email' => 'reza@example.com'],
];

// Reindex بر اساس id
$indexed = array_column($users, null, 'id');

✅ حالا $indexed[2] مستقیما اطلاعات Sara رو برمیگردونه،
بدون هیچ حلقه یا جستجوی اضافه.


کاربردهاش؟

ساخت lookup table سریع

کدنویسی تمیزتر و کوتاه‌تر

عالی برای caching و join کردن دیتاست‌ها

خلاصه که : با array_column میتونیم از یک آرایه ساده، یک ساختار قوی برای دسترسی مستقیم بسازیم.
یک ترفند کوچیک، اما تاثیره بزرگ در سرعت و خوانایی کد.
#php #اموزش_php #php_tip

@GoldenCodeir

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

یکی از قابلیت‌های جذاب کش در لاراول، Cache Tags هست.
با Tag میتونی چند داده کش شده رو زیر یک تگ مشخص گروه‌بندی کنی. اینطوری مدیریت اونا (پاک‌کردن یا بروزرسانی) خیلی راحتتر میشه.


📌 چرا به درد میخوره؟

فرض کن اپلیکیشن چند تیمی (multi-tenant) داری. هر تیم تنظیمات خودشو داره که توی کش ذخیره میکنی.
حالا اگه بخوای همه کش‌های مربوط به یک تیم خاص رو پاک کنی، با Tag خیلی ساده میشه:

// ذخیره داده‌ها با تگ team-1
Cache::tags(['team-1'])->put('settings', ['lang' => 'fa', 'timezone' => 'Asia/Tehran'], 3600);

// ذخیره داده دیگه با همون تگ
Cache::tags(['team-1'])->put('members', ['Ali', 'Sara'], 3600);

// پاک کردن همه کش‌های team-1
Cache::tags(['team-1'])->flush();

⚠️ یه نکته مهم

این Cache Tags فقط روی درایورهای Redis و Memcached پشتیبانی میشن.
روی file، database یا dynamodb کار نمیکنه.


خلاصه که:

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

#Laravel #Laravel_tip #لاراول

@GoldenCodeir 🔥

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