Panic Dev
داشتم تجربه کسی که داشته روی روش های توسعه نرم افزار ژاپنی ها مطالعه میکرده میخوندم به قدری ارزشمند و پر محتوا و قابل تعمل هستش که فک کردم به اشتراک گذاریش خالی از لطف نباشه . طولانی هست ولی ارزش داره ، سعی میکنم در طول روز چند تیکشو بزارم . امیدوارم…
فلسفهای که همهچیز را تغییر میدهد
مونوزوکوری (Monozukuri): هنر ساختن
در ژاپن مفهومی وجود دارد به نام مونوزوکوری — یعنی "هنر ساختن".
اما این فقط دربارهی تولید محصولات فیزیکی نیست؛ بلکه یک فلسفه است. فلسفهای که روی مهارت، بهبود مداوم، و افتخار به خود فرآیند ساخت تأکید دارد.
برنامهنویسهای ژاپنی فقط کد نمینویسن، اونو میسازن.
وقتی با هیروشی ناکامورا، یکی از مهندسهای ارشد یه شرکت بزرگ فناوری در ژاپن، مصاحبه کردم، اینطوری توضیح داد:
"در غرب، کد مینویسن که فیچر تحویل بدن. تو ژاپن، کد مینویسیم که دههها عمر کنه. اون فیچر فقط نقطهی شروعه."
این تغییر ذهنیت واقعاً عمیقه.
بهجای اینکه شعارشون "سریع حرکت کن و همهچی رو بشکن" باشه، برنامهنویسهای ژاپنی باور دارن به "آروم بساز و کاری نذار که خراب شه".
———————————————————————
کایزن (Kaizen): اصل ۱٪ بهتر شدن
احتمالاً اسم کایزن رو توی زمینهی بهبود کسبوکار شنیدی،
ولی برنامهنویسهای ژاپنی این مفهوم رو مستقیم روی کد پیاده میکنن.
بهجای بازنویسیهای سنگین یا ریفکتور کردن کل سیستم،
اونا بهبودهای کوچیک و مداوم انجام میدن — هر روز، با هر کامیت.
توی عمل یعنی چی؟ اینطوری: (در تصویر )
برنامهنویس ژاپنی منتظر مجوز برای بهبود کد نمیمونه،
واسه "اسپرینتِ بدهی فنی" برنامهریزی نمیکنه،
فقط هر روز یه ذره همهچی رو بهتر میکنه.
مونوزوکوری (Monozukuri): هنر ساختن
در ژاپن مفهومی وجود دارد به نام مونوزوکوری — یعنی "هنر ساختن".
اما این فقط دربارهی تولید محصولات فیزیکی نیست؛ بلکه یک فلسفه است. فلسفهای که روی مهارت، بهبود مداوم، و افتخار به خود فرآیند ساخت تأکید دارد.
برنامهنویسهای ژاپنی فقط کد نمینویسن، اونو میسازن.
وقتی با هیروشی ناکامورا، یکی از مهندسهای ارشد یه شرکت بزرگ فناوری در ژاپن، مصاحبه کردم، اینطوری توضیح داد:
"در غرب، کد مینویسن که فیچر تحویل بدن. تو ژاپن، کد مینویسیم که دههها عمر کنه. اون فیچر فقط نقطهی شروعه."
این تغییر ذهنیت واقعاً عمیقه.
بهجای اینکه شعارشون "سریع حرکت کن و همهچی رو بشکن" باشه، برنامهنویسهای ژاپنی باور دارن به "آروم بساز و کاری نذار که خراب شه".
———————————————————————
کایزن (Kaizen): اصل ۱٪ بهتر شدن
احتمالاً اسم کایزن رو توی زمینهی بهبود کسبوکار شنیدی،
ولی برنامهنویسهای ژاپنی این مفهوم رو مستقیم روی کد پیاده میکنن.
بهجای بازنویسیهای سنگین یا ریفکتور کردن کل سیستم،
اونا بهبودهای کوچیک و مداوم انجام میدن — هر روز، با هر کامیت.
توی عمل یعنی چی؟ اینطوری: (در تصویر )
برنامهنویس ژاپنی منتظر مجوز برای بهبود کد نمیمونه،
واسه "اسپرینتِ بدهی فنی" برنامهریزی نمیکنه،
فقط هر روز یه ذره همهچی رو بهتر میکنه.
👍8🔥1
توسعه بهموقع (Just-In-Time Development)
تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن.
یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست.
بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،
دقیقاً همون چیزی رو میسازن که الان لازمه — نه بیشتر، نه کمتر.
———————————————
جیدوکا (Jidoka): طرز فکر "خط تولید رو متوقف کن"
توی کارخانههای تویوتا، هر کارگری میتونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیمهای توسعه نرمافزار ژاپنی دقیقاً همین اصل رو پیاده میکنن:
اگه مشکلی وجود داشته باشه، همهچی متوقف میشه تا اون مشکل حل بشه.
نه از این حرفا که "تو اسپرینت بعدی درستش میکنیم"،
نه این که "فعلاً بفرستیم، بعداً یه پچ میدیم."
یه بار دیدم یه تیم ژاپنی دو روز وقت گذاشت تا یه باگ گوشهای رو دیباگ کنه که فقط روی ۰.۱٪ از کاربرا تأثیر داشت.
وقتی پرسیدم چرا فقط لاگش نکردن و رفتن سراغ بقیه کارا، مدیر تیم گفت:
«اگه یه اشکال کوچیک رو قبول کنیم، یعنی اشکال داشتن رو عادی کردیم. خیلی زود، پر از اشکال میشیم.»
شاید سختگیرانه بهنظر بیاد —
اما وقتی میبینی توی سیستمشون تقریباً هیچ باگ تولیدی وجود نداره، میفهمی چرا اینقدر جواب میده.
تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن.
یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست.
بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،
دقیقاً همون چیزی رو میسازن که الان لازمه — نه بیشتر، نه کمتر.
———————————————
جیدوکا (Jidoka): طرز فکر "خط تولید رو متوقف کن"
توی کارخانههای تویوتا، هر کارگری میتونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیمهای توسعه نرمافزار ژاپنی دقیقاً همین اصل رو پیاده میکنن:
اگه مشکلی وجود داشته باشه، همهچی متوقف میشه تا اون مشکل حل بشه.
نه از این حرفا که "تو اسپرینت بعدی درستش میکنیم"،
نه این که "فعلاً بفرستیم، بعداً یه پچ میدیم."
یه بار دیدم یه تیم ژاپنی دو روز وقت گذاشت تا یه باگ گوشهای رو دیباگ کنه که فقط روی ۰.۱٪ از کاربرا تأثیر داشت.
وقتی پرسیدم چرا فقط لاگش نکردن و رفتن سراغ بقیه کارا، مدیر تیم گفت:
«اگه یه اشکال کوچیک رو قبول کنیم، یعنی اشکال داشتن رو عادی کردیم. خیلی زود، پر از اشکال میشیم.»
شاید سختگیرانه بهنظر بیاد —
اما وقتی میبینی توی سیستمشون تقریباً هیچ باگ تولیدی وجود نداره، میفهمی چرا اینقدر جواب میده.
👍17🍓1
Panic Dev
توسعه بهموقع (Just-In-Time Development) تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن. یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست. بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،…
هفت نوع اتلاف در توسعه نرمافزار
(برگرفته از سیستم تولید تویوتا)
برنامهنویسهای ژاپنی با الهام از سیستم تولید تویوتا،
هفت نوع «اتلاف» یا Wastes در توسعه نرمافزار رو شناسایی کردن —
و هدفشون حذف یا کاهش این موارده:
۱. کارِ نیمهتمام
کدی که نوشته شده ولی تست نشده، بررسی نشده یا هنوز دیپلوی نشده.
تیمهای ژاپنی تا جای ممکن کار در جریان رو کم میکنن و تلاش میکنن کارهای کوچیک رو بهطور کامل و تموم انجام بدن.
۲. قابلیتهای اضافه
ساختن فیچرهایی که کاربر واقعاً نیاز نداره.
برنامهنویسهای ژاپنی استاد "نه گفتن" به رشد بیرویهی امکانات هستن.
۳. دوبارهیادگیری
وقتی زمان صرف میشه برای فهمیدن اینکه یه تکه کد چیکار میکنه — چون مستند نیست یا ساختار خوبی نداره.
برای همین، اونا روی نامگذاری واضح و کامنتنویسی دقیق خیلی تأکید دارن.
۴. تحویلهای دستبهدست
وقتی یه تیم کد رو فقط "پرتاب" میکنه سمت یه تیم دیگه.
ژاپنیها تیمهای چندمهارتهای رو ترجیح میدن که مسئولیت کامل یه فیچر رو از اول تا آخر به عهده بگیرن.
۵. تأخیرها
منتظر موندن برای تأیید، بررسی یا وابستگیها.
اونا تلاش میکنن بازخوردها رو سریعتر بگیرن و تیمهایی بسازن که مستقلتر عمل کنن.
۶. پرش بین کارها
مدام بین پروژهها یا فیچرهای مختلف جابهجا شدن.
برنامهنویسهای ژاپنی ترجیح میدن روی یک چیز تمرکز کنن و همون رو درست و کامل انجام بدن.
۷. باگها (نقصها)
خطاهایی که نیاز به اصلاح دارن و باعث نارضایتی کاربر میشن.
این بزرگترین اتلافه — و دلیلش هم اینه که ژاپنیها پیشگیری رو به تشخیص و اصلاح ترجیح میدن.
✨ نتیجه؟
سیستمی با کمترین اتلاف، تمرکز بالا، و کیفیتی که حتی بعد از سالها هم قابل اتکا باقی میمونه.
(برگرفته از سیستم تولید تویوتا)
برنامهنویسهای ژاپنی با الهام از سیستم تولید تویوتا،
هفت نوع «اتلاف» یا Wastes در توسعه نرمافزار رو شناسایی کردن —
و هدفشون حذف یا کاهش این موارده:
۱. کارِ نیمهتمام
کدی که نوشته شده ولی تست نشده، بررسی نشده یا هنوز دیپلوی نشده.
تیمهای ژاپنی تا جای ممکن کار در جریان رو کم میکنن و تلاش میکنن کارهای کوچیک رو بهطور کامل و تموم انجام بدن.
۲. قابلیتهای اضافه
ساختن فیچرهایی که کاربر واقعاً نیاز نداره.
برنامهنویسهای ژاپنی استاد "نه گفتن" به رشد بیرویهی امکانات هستن.
۳. دوبارهیادگیری
وقتی زمان صرف میشه برای فهمیدن اینکه یه تکه کد چیکار میکنه — چون مستند نیست یا ساختار خوبی نداره.
برای همین، اونا روی نامگذاری واضح و کامنتنویسی دقیق خیلی تأکید دارن.
۴. تحویلهای دستبهدست
وقتی یه تیم کد رو فقط "پرتاب" میکنه سمت یه تیم دیگه.
ژاپنیها تیمهای چندمهارتهای رو ترجیح میدن که مسئولیت کامل یه فیچر رو از اول تا آخر به عهده بگیرن.
۵. تأخیرها
منتظر موندن برای تأیید، بررسی یا وابستگیها.
اونا تلاش میکنن بازخوردها رو سریعتر بگیرن و تیمهایی بسازن که مستقلتر عمل کنن.
۶. پرش بین کارها
مدام بین پروژهها یا فیچرهای مختلف جابهجا شدن.
برنامهنویسهای ژاپنی ترجیح میدن روی یک چیز تمرکز کنن و همون رو درست و کامل انجام بدن.
۷. باگها (نقصها)
خطاهایی که نیاز به اصلاح دارن و باعث نارضایتی کاربر میشن.
این بزرگترین اتلافه — و دلیلش هم اینه که ژاپنیها پیشگیری رو به تشخیص و اصلاح ترجیح میدن.
✨ نتیجه؟
سیستمی با کمترین اتلاف، تمرکز بالا، و کیفیتی که حتی بعد از سالها هم قابل اتکا باقی میمونه.
👍3❤🔥2🔥1
داخل یک پروداکت، زمان پاسخگویی API هاشون به شدت بالا رفته بود.
بررسیها نشون داد که عامل اصلی، استفادهی زیاد از تابع
در هر درخواست، این تابع حدود 300 بار اجرا میشد. در نهایت دیدیم که فقط همین بخش باعث مصرف ۴۰٪ از کل زمان اجرای درخواست شده!
نتایج:
- میانگین زمان پاسخگویی از 700ms به 200ms رسید
- در 95٪ مواقع زمان پاسخ از 1.2s به 350ms کاهش پیدا کرد
- استفاده از CPU سرورها 35٪ کمتر شد
- تعداد درخواستهایی که تونستن در ثانیه پردازش کنند، تقریباً ۳ برابر شد!
-— دلیل اصلی این تفاوت اینه که isset():
- مستقیماً در سطح زبان PHP پیادهسازی شده
- هزینهی پردازش تابع نداره
- بسیار سریعتر اجرا میشه
—- در مقابل array_key_exists():
- باید پارامترها رو بررسی کنه
- نیاز به بررسی نوع داده داره
- زمان اجراش بیشتره
اما توجه:
اگر مقدار
در نسخههای جدید PHP (مثل PHP 8 به بعد)، استفاده از ?? (عملگر Null Coalescing) یک جایگزین بسیار سریع و تمیز برای هر دو هست:
منبع
#laravel #php
@panicdev
بررسیها نشون داد که عامل اصلی، استفادهی زیاد از تابع
array_key_exists() بود، اون هم در تابعی که برای هر محصول در API صدها بار اجرا میشد.در هر درخواست، این تابع حدود 300 بار اجرا میشد. در نهایت دیدیم که فقط همین بخش باعث مصرف ۴۰٪ از کل زمان اجرای درخواست شده!
نتایج:
- میانگین زمان پاسخگویی از 700ms به 200ms رسید
- در 95٪ مواقع زمان پاسخ از 1.2s به 350ms کاهش پیدا کرد
- استفاده از CPU سرورها 35٪ کمتر شد
- تعداد درخواستهایی که تونستن در ثانیه پردازش کنند، تقریباً ۳ برابر شد!
-— دلیل اصلی این تفاوت اینه که isset():
- مستقیماً در سطح زبان PHP پیادهسازی شده
- هزینهی پردازش تابع نداره
- بسیار سریعتر اجرا میشه
—- در مقابل array_key_exists():
- باید پارامترها رو بررسی کنه
- نیاز به بررسی نوع داده داره
- زمان اجراش بیشتره
اما توجه:
اگر مقدار
null برای شما معنیداره (مثلاً در تنظیمات یا اعتبارسنجی API)، باید همچنان از array_key_exists() استفاده کنید چون isset() برای مقادیر null مقدار false برمیگردونه و ممکنه کلید موجود باشه ولی مقدارش null باشه.در نسخههای جدید PHP (مثل PHP 8 به بعد)، استفاده از ?? (عملگر Null Coalescing) یک جایگزین بسیار سریع و تمیز برای هر دو هست:
$value = $array['key'] ?? 'default';منبع
#laravel #php
@panicdev
👍11👌2
1.4 میلیارد لاگ کاربر، بدون شاردینگ یا سیستمهای پیچیده – فقط با PostgreSQL 18!
سیستمی ستاپ کردن که :
بیش از 1.4 میلیارد لاگ فعالیت کاربر رو مدیریت میکنه
همزمانی بالا در خواندن و نوشتن رو پشتیبانی میکنه
درخواستهای مهم رو زیر 200ms پاسخ میده
❌ بدون شاردینگ
❌ بدون چند دیتابیس یا معماری پیچیده
✅ فقط PostgreSQL 18، با تنظیمات دقیق و بهینهسازی
لینک مقاله
#database #postgres
@panicdev
سیستمی ستاپ کردن که :
بیش از 1.4 میلیارد لاگ فعالیت کاربر رو مدیریت میکنه
همزمانی بالا در خواندن و نوشتن رو پشتیبانی میکنه
درخواستهای مهم رو زیر 200ms پاسخ میده
❌ بدون شاردینگ
❌ بدون چند دیتابیس یا معماری پیچیده
✅ فقط PostgreSQL 18، با تنظیمات دقیق و بهینهسازی
لینک مقاله
#database #postgres
@panicdev
Medium
How We Designed a 1 Billion Row System on PostgreSQL 18 (And Why It’s Blazing Fast)
When most engineers think of storing over a billion rows, they usually turn to distributed databases like Cassandra, Bigtable, or DynamoDB…
👍1
فیلامنت نسخه ۴ به صورت پایدار (stable) روز ۱۲ اگست ساعت ۱ بعد از ظهر (UTC) ریلیز و در دسترس میشه 🙌
به زمان ایران/تهران میشه سه شنبه هفته آینده (۲۱ مرداد) ساعت ۴:۳۰ بعد از ظهر🚀
به زمان ایران/تهران میشه سه شنبه هفته آینده (۲۱ مرداد) ساعت ۴:۳۰ بعد از ظهر
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍4🎉1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍1🤣1
وقتی پروژه PHP فقط روی سیستم خودت جواب میده و حس میکنی همه چیز اوکیه، تازه نصف راه رو رفتی! توی محیط واقعی (سرور)، داستان فرق میکنه.
اینجا سرعت، پایداری و مدیریت منابع حرف اول رو میزنن.
🛠 چند تا نکته مهم که باید رعایت کنی:
🔹 فعال کردن OPcache
وقتی این قابلیت روشن باشه، کدها فقط یه بار کامپایل میشن و داخل حافظه میمونن. این یعنی سرعت بالاتر و فشار کمتر روی CPU.
داخل php.ini این خطها رو اضافه یا اصلاح کن:
⚠️ یادت نره بعد از هر دیپلوی، PHP-FPM رو ریستارت کنی.
⚠️ یاد باشه که validate_timestamps روی ۱ نباشه ، اونوقت PHP شروع میکنه به چک کردن filesystem و بیشتر پتانسیل Opcache رو از دست میدی
🔹 تنظیم درست PHP-FPM
این سیستم چندتا «Worker» آماده نگه میداره تا درخواستها رو سریع جواب بدن. تعداد Worker ها باید با مقدار رم سرور هماهنگ باشه.
یه مثال:
چطور میتونی بفهمی هر ورکر چقدر مموری مصرف میکنه ؟
در این حالت روی سرور با ۸ گیگ رم و مصرف ۸۰ مگ برای هر php ورکر ، شما تقریبا میتونید ۶۰ عدد max_children داشته باشید .
🔹 استفاده از realpath cache
این کار باعث میشه مسیر فایلها رو PHP هی دوباره چک نکنه و سرعت بالاتر بره:
🔹 فعال کردن /status و slowlog
با /status میتونی ببینی چندتا کارگر فعاله و چندتا بیکار.
با slowlog هم میفهمی کدوم درخواستها طولانی اجرا میشن تا مشکل رو پیدا کنی.
📌 نتیجه نهایی:
اگر اوپکش فعال باشه، PHP-FPM درست تنظیم شده باشه، تایماوت بذاری، کش مسیرها فعال باشه و مانیتورینگ رو جدی بگیری، اپلیکیشن PHP توی سرور خیلی سریعتر، پایدارتر و قابل اعتمادتر کار میکنه.
@panicdev
#laravel #php
اینجا سرعت، پایداری و مدیریت منابع حرف اول رو میزنن.
🛠 چند تا نکته مهم که باید رعایت کنی:
🔹 فعال کردن OPcache
وقتی این قابلیت روشن باشه، کدها فقط یه بار کامپایل میشن و داخل حافظه میمونن. این یعنی سرعت بالاتر و فشار کمتر روی CPU.
داخل php.ini این خطها رو اضافه یا اصلاح کن:
opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
⚠️ یادت نره بعد از هر دیپلوی، PHP-FPM رو ریستارت کنی.
⚠️ یاد باشه که validate_timestamps روی ۱ نباشه ، اونوقت PHP شروع میکنه به چک کردن filesystem و بیشتر پتانسیل Opcache رو از دست میدی
🔹 تنظیم درست PHP-FPM
این سیستم چندتا «Worker» آماده نگه میداره تا درخواستها رو سریع جواب بدن. تعداد Worker ها باید با مقدار رم سرور هماهنگ باشه.
یه مثال:
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 1000
request_terminate_timeout = 30
چطور میتونی بفهمی هر ورکر چقدر مموری مصرف میکنه ؟
ps -o rss,cmd -C php-fpm | awk '{ sum+=$1 } END { print sum/NR/1024 " MB" }'در این حالت روی سرور با ۸ گیگ رم و مصرف ۸۰ مگ برای هر php ورکر ، شما تقریبا میتونید ۶۰ عدد max_children داشته باشید .
🔹 استفاده از realpath cache
این کار باعث میشه مسیر فایلها رو PHP هی دوباره چک نکنه و سرعت بالاتر بره:
realpath_cache_size = 4096k
realpath_cache_ttl = 600
🔹 فعال کردن /status و slowlog
با /status میتونی ببینی چندتا کارگر فعاله و چندتا بیکار.
با slowlog هم میفهمی کدوم درخواستها طولانی اجرا میشن تا مشکل رو پیدا کنی.
📌 نتیجه نهایی:
اگر اوپکش فعال باشه، PHP-FPM درست تنظیم شده باشه، تایماوت بذاری، کش مسیرها فعال باشه و مانیتورینگ رو جدی بگیری، اپلیکیشن PHP توی سرور خیلی سریعتر، پایدارتر و قابل اعتمادتر کار میکنه.
@panicdev
#laravel #php
🔥23👍7
Filament Modular V4
- Production Ready
- Enterprise Cache Layers
- Zero Config usage
- Ready to configure
https://github.com/panicdevs/modulite
- Production Ready
- Enterprise Cache Layers
- Zero Config usage
- Ready to configure
https://github.com/panicdevs/modulite
GitHub
GitHub - panicdevs/modulite: Effortless Filament integration for modular projects
Effortless Filament integration for modular projects - panicdevs/modulite
🔥7
Panic Dev
Filament Modular V4 - Production Ready - Enterprise Cache Layers - Zero Config usage - Ready to configure https://github.com/panicdevs/modulite
این پکیج فعلا توی نسخه 0.1 هست و تا ریلیز استیبل کمی فاصله داره - من بنا به نیاز خودم پکیج رو اپگرید کردم و با فیلامنت ورژن ۴ سازگارش کردم و همزمان با پیش بردن کارای خودم اگه به مسئلهای بربخورم توی روال توسعه و کار با این پکیج - اپدیتهای جدیدی رو روش اعمال میکنم - میتونید Changelog پکیج رو از این لینک دنبال کنید
- ضمن اینکه به زودی توی وبسایت فیلامنت هم در دسترس میشه.
https://modulite.panicdevs.agency/
- ضمن اینکه به زودی توی وبسایت فیلامنت هم در دسترس میشه.
https://modulite.panicdevs.agency/
modulite.panicdevs.agency
Modulite - Filament with Modular approach
Modulite streamlines Filament integration in modular Laravel by auto-discovering panels/components and accelerating boot with environment-aware, file-backed caching.
👌2🔥1
🚀 فرصت همکاری برای دولوپر PHP / Laravel
ما به دنبال یک دولوپر میدلول یا سنیور هستیم که هفتهای حداقل ۳۰ ساعت زمان برای همکاری داشته باشه.
🔹 مهارتها و تواناییهای مورد نیاز:
تسلط به Laravel و PHP
تجربه در توسعه وبسرویسها با رعایت استانداردها و Best Practices
توانایی مستندسازی وبسرویسها
توانایی تستنویسی برای وبسرویسها
آشنایی و توانایی توسعه پنل ادمین با Filament
مهارت کافی در MySQL و Redis
آشنایی نسبی با Docker
فردی مسئولیتپذیر با روحیه کار تیمی
📩 اگر زمان و توانایی لازم رو دارید، لطفاً هزینه ساعتی به همراه رزومه خودتون رو به دایرکت همین کانال ارسال کنید.
🏢 نحوه همکاری به صورت دورکار است
⚠️ فقط پیامهای ارسال شده به دایرکت همین کانال بررسی میشن.
با سپاس از همراهی شما ❤️
ما به دنبال یک دولوپر میدلول یا سنیور هستیم که هفتهای حداقل ۳۰ ساعت زمان برای همکاری داشته باشه.
🔹 مهارتها و تواناییهای مورد نیاز:
تسلط به Laravel و PHP
تجربه در توسعه وبسرویسها با رعایت استانداردها و Best Practices
توانایی مستندسازی وبسرویسها
توانایی تستنویسی برای وبسرویسها
آشنایی و توانایی توسعه پنل ادمین با Filament
مهارت کافی در MySQL و Redis
آشنایی نسبی با Docker
فردی مسئولیتپذیر با روحیه کار تیمی
📩 اگر زمان و توانایی لازم رو دارید، لطفاً هزینه ساعتی به همراه رزومه خودتون رو به دایرکت همین کانال ارسال کنید.
🏢 نحوه همکاری به صورت دورکار است
⚠️ فقط پیامهای ارسال شده به دایرکت همین کانال بررسی میشن.
با سپاس از همراهی شما ❤️
۱️⃣ محافظ نامرئی جلوی SQL Injection
اشتباه مرسوم: استفاده مستقیم از کوئری خام.
راهحل: همیشه از بایندینگ استفاده کن. اینطوری هم امنتره، هم سریعتر.
۲️⃣ لیست سیاه برای توکنهای Sanctum
توکنهای دزدیدهشده تا زمان انقضا معتبر میمونن.
با یه میانافزار ساده میتونی سریعاً توکنهای مشکوک رو باطل کنی.
اگه Redis هم بذاری وسط، سرعت چک کردن میشه لحظهای.
۳️⃣ دانلود استریمشده با cursor()
هیچوقت کل دیتابیس رو یهجا نیار بالا!
با cursor() و streamDownload میتونی میلیونها ردیف رو با مصرف رم خیلی کم استریم کنی.
۴️⃣ لیمیت هوشمند با اثرانگشت کاربر
محدود کردن فقط بر اساس آیپی سادهست و قابل دور زدن.
ترکیب آیپی + یوزر ایجنت رو هش کن، اون بشه کلید محدودیت. اینطوری حملات brute-force عملاً میریزه.
۵️⃣ گرم کردن روتها با Octane
لاراول به صورت پیشفرض روتها رو در لحظه بوت میکنه.
با route:cache و Octane میتونی استارت سرور رو تا چند برابر سریعتر کنی.
۶️⃣ محافظت از بلید جلوی XSS
وقتی HTML کاربر ذخیره میشه، {!! !!} خیلی خطرناکه.
راهحل: Purifier برای تمیز کردن کد + CSP nonce برای اسکریپتها.
۷️⃣ شاردینگ دیتابیس برای مقیاس بینهایت
وقتی ترافیک سنگین میشه، دیتابیس نفسش میگیره.
لاراول اجازه میده برای هر یوزر یا تننت یه کانکشن جدا تعریف کنی، بدون بازنویسی کل اپ.
۸️⃣ چرخش کلید رمزنگاری بدون داونتایم
عوض کردن APP_KEY قدیما یعنی همه لاگاوت بشن.
با نگه داشتن کلید قبلی و تعریف کلید جدید، میتونی بدون مشکل کلید رو بچرخونی.
📎منبع
@panicdev
#laravel #tips
اشتباه مرسوم: استفاده مستقیم از کوئری خام.
راهحل: همیشه از بایندینگ استفاده کن. اینطوری هم امنتره، هم سریعتر.
// ❌ Bad
DB::select("SELECT * FROM users WHERE email = '$email'");
// ✅ Secure
User::whereRaw("MATCH (bio) AGAINST (? IN BOOLEAN MODE)", [$searchTerm])
->where('is_public', true)
->get();php
۲️⃣ لیست سیاه برای توکنهای Sanctum
توکنهای دزدیدهشده تا زمان انقضا معتبر میمونن.
با یه میانافزار ساده میتونی سریعاً توکنهای مشکوک رو باطل کنی.
اگه Redis هم بذاری وسط، سرعت چک کردن میشه لحظهای.
public function handle($request, $next) {
if ($this->isCompromised($request)) {
$request->user()->currentAccessToken()->delete();
}
return $next($request);
}
۳️⃣ دانلود استریمشده با cursor()
هیچوقت کل دیتابیس رو یهجا نیار بالا!
با cursor() و streamDownload میتونی میلیونها ردیف رو با مصرف رم خیلی کم استریم کنی.
return response()->streamDownload(function () {
foreach (User::where('active', true)->cursor() as $user) {
echo json_encode($user) . "\n";
}
}, 'users.jsonl');
۴️⃣ لیمیت هوشمند با اثرانگشت کاربر
محدود کردن فقط بر اساس آیپی سادهست و قابل دور زدن.
ترکیب آیپی + یوزر ایجنت رو هش کن، اون بشه کلید محدودیت. اینطوری حملات brute-force عملاً میریزه.
RateLimiter::for('api', function (Request $request) {
$fingerprint = sha1($request->userAgent() . $request->ip());
return Limit::perMinute(100)->by($fingerprint);
});۵️⃣ گرم کردن روتها با Octane
لاراول به صورت پیشفرض روتها رو در لحظه بوت میکنه.
با route:cache و Octane میتونی استارت سرور رو تا چند برابر سریعتر کنی.
php artisan route:cache
php artisan octane:start --workers=8
۶️⃣ محافظت از بلید جلوی XSS
وقتی HTML کاربر ذخیره میشه، {!! !!} خیلی خطرناکه.
راهحل: Purifier برای تمیز کردن کد + CSP nonce برای اسکریپتها.
{!! Purifier::clean($html, ['HTML.Allowed' => 'a[href]']) !!}
<noscript nonce="{{ csp_nonce() }}">
var data = @json($safeData);
</noscript>۷️⃣ شاردینگ دیتابیس برای مقیاس بینهایت
وقتی ترافیک سنگین میشه، دیتابیس نفسش میگیره.
لاراول اجازه میده برای هر یوزر یا تننت یه کانکشن جدا تعریف کنی، بدون بازنویسی کل اپ.
User::on('user_shard')->find(15000);۸️⃣ چرخش کلید رمزنگاری بدون داونتایم
عوض کردن APP_KEY قدیما یعنی همه لاگاوت بشن.
با نگه داشتن کلید قبلی و تعریف کلید جدید، میتونی بدون مشکل کلید رو بچرخونی.
# .env
APP_KEY=new_key
PREVIOUS_APP_KEY=old_key
public function boot() {
Encrypter::rotate($this->app['config']['app.key'], 'new_key');
}
📎منبع
@panicdev
#laravel #tips
Medium
8 Laravel Secrets for a Secure, High-Performance API
Today, I’m sharing the 8 most powerful Laravel “secrets” I now consider non-negotiable in every backend I build. These tips are not just…
🔥10
Forwarded from Armin's Notes 🪴
پس از مدتها؛ برای همیشه از پکیج nwidart/laravel-modules دست کشیدم :))
توی این یادداشت دلایلش رو توضیح دادم - امیدوارم براتون جالب و مفید باشد 👀
https://www.arminnotes.com/notes/goodbye-nwidart-hello-panicdevs-modules
توی این یادداشت دلایلش رو توضیح دادم - امیدوارم براتون جالب و مفید باشد 👀
https://www.arminnotes.com/notes/goodbye-nwidart-hello-panicdevs-modules
یادداشتهای آرمین
خداحافظی با nwidart/laravel-modules؛ سلام به panicdevs/modules - یادداشتهای آرمین
بعد از سه سال توسعه بیش از ۱۵۰ ماژول با nwidart/laravel-modules، تصمیم گرفتم سراغ راهحل اختصاصی خودم برم: panicdevs/modules. تمرکز اصلی؟ پرفورمنس.
10❤🔥11👍3👌2