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

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

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

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

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): طرز فکر "خط تولید رو متوقف کن"
توی کارخانه‌های تویوتا، هر کارگری می‌تونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیم‌های توسعه نرم‌افزار ژاپنی دقیقاً همین اصل رو پیاده می‌کنن:
اگه مشکلی وجود داشته باشه، همه‌چی متوقف می‌شه تا اون مشکل حل بشه.

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

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

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

1.4 میلیارد لاگ کاربر، بدون شاردینگ یا سیستم‌های پیچیده – فقط با PostgreSQL 18!

سیستمی ستاپ کردن که :

بیش از 1.4 میلیارد لاگ فعالیت کاربر رو مدیریت می‌کنه
همزمانی بالا در خواندن و نوشتن رو پشتیبانی می‌کنه
درخواست‌های مهم رو زیر 200ms پاسخ می‌ده

❌ بدون شاردینگ
❌ بدون چند دیتابیس یا معماری پیچیده
✅ فقط PostgreSQL 18، با تنظیمات دقیق و بهینه‌سازی


لینک مقاله
#database #postgres

@panicdev

وقتی پروژه 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

Filament Modular V4
- Production Ready
- Enterprise Cache Layers
- Zero Config usage
- Ready to configure

https://github.com/panicdevs/modulite