اگه دوس دارید با مفهوم اسکوپ و کوئری رجیستری توی لاراول عمیقا آشنا بشید و بتونید مثل یه Pro Player ازشون استفاده کنید این مقاله زیبا و کامل رو از دست 👀

https://laravel-news.com/query-scopes

🚀 متد Dispatch در Laravel یعنی چی؟ پشت صحنه‌اش چیه؟

وقتی توی لاراول می‌نویسی:

MyJob::dispatch($data);

داری یه job رو می‌فرستی به صف (queue)، ولی پشت پرده کلی داستان اتفاق می‌افته که فهمیدنش می‌تونه کمکت کنه حرفه‌ای‌تر کار کنی 👇

🔹 اولین مرحله:
لاراول با dispatch()، Bus::dispatch() یا helper با نام dispatch() شروع می‌کنه. این‌ها همه از کامپوننت Bus استفاده می‌کنن تا job رو آماده‌ی ارسال کنن.

🔹 چطوری آماده می‌کنه؟

بسته به نوع job، یکی از این ۳ شیء ساخته می‌شه:

متد PendingDispatch —> برای job معمولی

متد PendingChain —> برای job‌های زنجیره‌ای

متد PendingBatch —> برای batch‌ها

🔐 جاب یکتا (Unique):
اگه job از ShouldBeUnique استفاده کنه، لاراول بررسی می‌کنه که توی صف، همین job با همون شناسه (ID) وجود داره یا نه.
اگه باشه و هنوز پردازش نشده، job جدید ارسال نمی‌شه.

✅ فقط برای job معمولی فعاله، نه chain یا batch.

🔄 وقتی از chain یا batch استفاده می‌کنی:

Bus::chain([...]);
Bus::batch([...]);

توی chain همه jobها به اولین job چسبید‌ان.
توی batch اطلاعاتشون توی دیتابیس ذخیره می‌شه.

💾 بعد از این آماده‌سازی‌ها، اگه dispatch بعد از commit تنظیم شده باشه:
لاراول صبر می‌کنه تا همه تراکنش‌های دیتابیس تموم شن (موفقیت‌آمیز).
اگه rollback شه، job هم اصلاً فرستاده نمی‌شه.

🧬 تبدیل job به payload:

لاراول باید یه payload بسازه که شامل اینا می‌شه:

تنظیمات مثل maxTries, timeout, retryUntil

سریالایز کردن job با serialize() (و تبدیل مدل‌ها با trait مخصوص)

رمزنگاری job اگه از ShouldBeEncrypted استفاده کرده باشه

اجرای hook‌ها مثل Queue::createPayloadUsing()

در نهایت تبدیل به JSON و ارسال به صف (database, Redis, SQS و...)

📬 برای event listener، mail, notification و broadcastها:
اگه ShouldQueue رو پیاده‌سازی کرده باشن، مستقیم میان توی queue (و نه Bus).
یعنی قابلیت‌هایی مثل unique، chain یا batch اینجا اعمال نمی‌شن.

🧠 و اما closure؟
اگه بخوای یه closure رو بفرستی به صف، Laravel با SerializableClosure سریالایزش می‌کنه، رمزنگاری‌ش می‌کنه و با job مخصوصش (CallQueuedClosure) می‌فرسته صف.

🎯 جمع‌بندی:
دستور Job dispatch فقط یه خط نیست! یه مکانیزم کامل پشتشه که با قدرت و امنیت بالا job رو آماده می‌کنه، serialize و encrypt می‌کنه، و با دقت می‌فرسته صف. یاد گرفتنش کمک می‌کنه کدت تمیزتر و قابل کنترل‌تر باشه 💪


🔗 منبع : مقاله

@panicdev

تجربه کسی که راه زیادی رو رفته تا گلوگاه های یک زیرساخت و شناسایی کنه برای اینکه بتونه پاسخگوئه یک میلیون یوزر باشه .


https://medium.com/@kanishks772/scaling-to-1-million-users-the-architecture-i-wish-i-knew-sooner-39c688ded2f1

اگه شما هم براتون سواله که مدل های Max توی Cursor چقدر هزینه برمیدارن دعوتتون میکنم به دیدن این اسکرین شات :))


من از Claude 4 Opus Thinking Max استفاده کردم و خروجی این شده!

یک prompt = مصرف ۱۰۳.۶ تا فست ریکوئست و ۵ دلار هزینه مازاد 👀

دوتا پکیج زیبا ببینیم ، هم کاراییشون زیباست هم سورس کدشون

https://prismphp.com

https://laragent.ai

خودم به شخصه prism پسندیدم ، ولی خوب laragent هم تحت توسعست ، احتمالا به زودی چیزای بهتری و بیشتری ساپورت کنه .

@panicdev

🔥 حافظه رم Redis پر شد؟ باید چه کار کنیم؟

همون طور که میدونید Redis یه پایگاه داده‌ سریع و درون‌حافظه‌ایه که خیلی وقتا به‌عنوان کش (Cache) استفاده می‌شه.

اما سؤال مهم: وقتی حافظه Redis پر شد، چه اتفاقی می‌افته؟ 🤔

📦 ردیس چندین پالسی حذف داده (Eviction Policy) داره که می‌تونی با maxmemory-policy تنظیمشون کنی.
بیا با هم این سیاست‌ها رو مرور کنیم:

🔒 1. پالسی noeviction (بدون حذف):

✅ هیچ داده‌ای حذف نمی‌شه.

❌ اگه حافظه پر باشه، خطا می‌ده و کلید جدیدی نمی‌ذاره.

📌 مناسب برای مواقعی که حذف داده اصلاً مجاز نیست.

🧠 2. پالسی volatile-lru:

✅ فقط کلیدهایی که expire دارن و کمتر استفاده شدن حذف می‌شن.

📌 خوب برای داده‌های موقتی و نه چندان مهم.

📊 3. پالسی allkeys-lru:

✅ کلیدهایی که کمتر استفاده شدن حذف می‌شن، فرقی نداره expire دارن یا نه.

📌 ایده‌آل برای کش‌هایی که دسترسی بهشون الگوی مشخصی نداره.

🎲 4. پالسی volatile-random:

✅ یه کلید رندوم که expire داره حذف می‌شه.

📌 ساده، ولی شاید کلید مهمی رو حذف کنه.

🎲 5. پالسی allkeys-random:

✅ هر کلیدی ممکنه رندوم حذف شه، چه expire داشته باشه چه نه.

📌 برای سیستم‌های خیلی حساس توصیه نمی‌شه.

⏳ 6.پالسی volatile-ttl:

✅ کلیدی که زودتر expire می‌شه اول حذف می‌شه.

📌 منطقی برای داده‌هایی که زمان مصرفشون مهمه.

📉 7. پالسی volatile-lfu:

✅ کلیدهایی با expire که کم استفاده شدن حذف می‌شن.

📌 خوب برای حفظ داده‌های پرکاربرد و حذف داده‌های کم‌مصرف.

📉 8. پالسی allkeys-lfu:

✅ هر کلیدی (با یا بدون expire) که کم استفاده شده باشه حذف می‌شه.

📌 برای کش‌هایی که رفتار مصرف داده‌هاش مدام تغییر می‌کنه عالیه.


@panicdev

استخدام برنامه‌نویس ارشد (Full-Stack (PHP

شرط بررسی رزومه:
حداقل ۵ سال سابقه کار حرفه‌ای در حوزه توسعه نرم‌افزار و برنامه‌نویسی

حقوق:
+۵۰ میلیون تومان
* طبیعتا بسته به تخصص و رزومه میتونید عدد مدنظرتون رو پیشنهاد بدید و محدودیتی وجود نداره)

مهارت‌های فنی مورد نیاز:
تسلط کامل به PHP
آشنایی عمیق با معماری نرم‌افزار (Software Architecture)
آشنایی با Redis
تجربه در طراحی و توسعه API
آشنایی با Docker
و ...

https://jobinja.ir/1370018

خلاصه کتاب نردبان شکسته از آقای علی بندی

برای من جالب بود ،‌ گفتم به اشتراک بزارم .
نابرابری چی هست
نابرابری لازم هست ؟ اگر بله ! چقدر لازم هست
تفاوت فقر با نابرابری چی هست
اینکه نابرابری و فقر چقدر تاثیر دار روی تصمیماتتون،‌ روی تفکراتتون

دوستان کسی تاحالا کورس سافت اسکیل از جایی شرکت کرده؟ نتیجه‌ش چی بوده؟
کلا چطوری سافت اسکیل هاتون رو بهبود میدید؟

این سه تا وصله فعلا

https://news.1rj.ru/str/proxy?server=151.244.85.30&port=70&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D

https://news.1rj.ru/str/proxy?server=151.244.85.66&port=85&secret=ee00ff000fffff00fff5555ffffffffff56D656469612E737465616D706F77657265642E636F6D

https://news.1rj.ru/str/proxy?server=151.244.85.48&port=443&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D

⚠️ Update: #Iran has now been disconnected from the global internet for 36 hours; live metrics show national connectivity remains in the low few percent of ordinary levels with only a handful of users able to connect via multi-hop VPNs 📉

🔗 NetBlocks (@netblocks)

به زووودی 🤩
حدس میزنید چی باشه؟ :))

فلسفه‌ای که همه‌چیز را تغییر می‌دهد
مونو‌زوکوری (Monozukuri): هنر ساختن

در ژاپن مفهومی وجود دارد به نام مونو‌زوکوری — یعنی "هنر ساختن".
اما این فقط درباره‌ی تولید محصولات فیزیکی نیست؛ بلکه یک فلسفه است. فلسفه‌ای که روی مهارت، بهبود مداوم، و افتخار به خود فرآیند ساخت تأکید دارد.

برنامه‌نویس‌های ژاپنی فقط کد نمی‌نویسن، اونو می‌سازن.

وقتی با هیروشی ناکامورا، یکی از مهندس‌های ارشد یه شرکت بزرگ فناوری در ژاپن، مصاحبه کردم، این‌طوری توضیح داد:
"در غرب، کد می‌نویسن که فیچر تحویل بدن. تو ژاپن، کد می‌نویسیم که دهه‌ها عمر کنه. اون فیچر فقط نقطه‌ی شروعه."

این تغییر ذهنیت واقعاً عمیقه.
به‌جای اینکه شعارشون "سریع حرکت کن و همه‌چی رو بشکن" باشه، برنامه‌نویس‌های ژاپنی باور دارن به "آروم بساز و کاری نذار که خراب شه".

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

کایزن (Kaizen): اصل ۱٪ بهتر شدن

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

به‌جای بازنویسی‌های سنگین یا ریفکتور کردن کل سیستم،
اونا بهبودهای کوچیک و مداوم انجام می‌دن — هر روز، با هر کامیت.

توی عمل یعنی چی؟ اینطوری: (در تصویر )

برنامه‌نویس ژاپنی منتظر مجوز برای بهبود کد نمی‌مونه،
واسه "اسپرینتِ بدهی فنی" برنامه‌ریزی نمی‌کنه،
فقط هر روز یه ذره همه‌چی رو بهتر می‌کنه.

توسعه به‌موقع (Just-In-Time Development)

تیم‌های نرم‌افزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعه‌ی نرم‌افزار بومی‌سازی کردن.
یکی از مفاهیم قدرتمند این سیستم، توسعه به‌موقع (Just-In-Time) هست.

به‌جای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،
دقیقاً همون چیزی رو می‌سازن که الان لازمه — نه بیشتر، نه کمتر.


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

جیدوکا (Jidoka): طرز فکر "خط تولید رو متوقف کن"
توی کارخانه‌های تویوتا، هر کارگری می‌تونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیم‌های توسعه نرم‌افزار ژاپنی دقیقاً همین اصل رو پیاده می‌کنن:
اگه مشکلی وجود داشته باشه، همه‌چی متوقف می‌شه تا اون مشکل حل بشه.

نه از این حرفا که "تو اسپرینت بعدی درستش می‌کنیم"،
نه این که "فعلاً بفرستیم، بعداً یه پچ می‌دیم."

یه بار دیدم یه تیم ژاپنی دو روز وقت گذاشت تا یه باگ گوشه‌ای رو دیباگ کنه که فقط روی ۰.۱٪ از کاربرا تأثیر داشت.
وقتی پرسیدم چرا فقط لاگش نکردن و رفتن سراغ بقیه کارا، مدیر تیم گفت:
«اگه یه اشکال کوچیک رو قبول کنیم، یعنی اشکال داشتن رو عادی کردیم. خیلی زود، پر از اشکال می‌شیم.»

شاید سخت‌گیرانه به‌نظر بیاد —
اما وقتی می‌بینی توی سیستمشون تقریباً هیچ باگ تولیدی وجود نداره، می‌فهمی چرا این‌قدر جواب می‌ده.