پکیج های فیکر فارسی و ارسال پیامک لاراول برای PHP 8.5 بروزرسانی شدند!

البته این بروزرسانی فقط اضافه کردن PHP 8.5 به تست های GitHub Actions و پاس شدنشون بود اما چندتا نکنه مهم برام داشت:

1- چقدر GitHub Action باحال هست. فقط 30 ثانیه ادیت و روی 3 تا سیستم عامل، پکیج ها با PHP 8.2 تا 8.5 توی همه حالت ها تست میشن!

2- تست نویسی چقدر باحاله! با اینکه اول کار وقت زیادی رو در هنگام توسعه ازم گرفت و چون تجربه اولم برای تست نویسی بود، کلی over testing کردم، اما الان با اعتماد به نفس بالا خیالم راحته که هیچ مشکلی برای پکیج هام توی نسخه جدید نیست! (البته توی چیزهایی که تست کردم و همیشه جا برای باگ های ناشناخته هست)

3- اینکه دنیای برنامه نویسی یه بلوغ رسیده و اکثر زبان ها، فریم ورک ها و پکیج ها سعی دارن که breaking change نداشته باشن (مثلا لاراول 12، PHP 8.5) هم خیلی باحاله.

لینک پکیج هام اگر خواستید افتخار بدید و استفاده کنید
پکیج فیکر فارسی برای PHP
https://github.com/amyavari/persian-faker-php

پکیج ارسال پیامک لاراول با 12 ارائه دهنده ایرانی
https://github.com/amyavari/iran-sms-laravel

@DevTwitter | <Ali Mohammad Yavari/>

حدود دو سال پیش پکیج antd-jalali-v5 رو نوشتم برای اینکه تقویم AntD رو جلالی کنم.
در این مدت چند مورد عدم سازگاری با نسخه‌های جدید گزارش شده بود و بالاخره نسخه‌ی جدید رو منتشر کردم:
سازگار با React 19، سازگار با AntD 6 و با چند بهبود ریز.

https://www.npmjs.com/package/antd-jalali-v5

@DevTwitter | <Ali Mousavi/>

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

امروز صبح یه مقاله‌ خوندم درباره‌ی Micro-Frontends و حس کردم احتمالا این همون چیزیه که خیلی از تیم‌ها باهاش درگیرن: یک UI بزرگ، چند تا تیم، کلی هماهنگی اعصاب خورد کن… و در نهایت اسپرینت هایی که همیشه Faile میشن.

اینجا میکرو فرانت‌اند وارد میشه؛ اما نه به‌عنوان یک “Technical Trend”، بلکه به‌عنوان یک تغییر فرهنگی توی تیم.

چند نکته که به نظرم خیلی مهم بود:

- کامپوننت داشتن به معنی میکروفرانت‌اند نیست.
کامپوننت برای reuse خوبه؛
میکروفرانت‌اند برای استقلال تیم‌ها.
این دوتا رو نباید اشتباه گرفت.


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


- مهاجرت به میکروفرانت‌اند باید “تکه‌تکه و عمودی” باشه.
نه یک Big Bang.
یک بخش کامل از UI رو جدا کن و بذار یک تیم کامل مسئولش باشه. مشکلات واقعی اونجا خودشون رو نشون میدن.


- تکرار بعضی چیزها الزاماً بده نیست.
گاهی “duplicate کردن” یک ماژول ساده، خیلی عاقلانه‌تر از یکی کردنشون وسط چند تیمه.
سرعت مهم‌تر از وسواس بی‌جا روی DRY بودن کدهاست.


- سخت‌ترین بخش ماجرا تقسیم تکنیکال نیست؛ هماهنگی تیم‌هاست. routing، auth، UX ، قرارداد بین تیم‌ها…
این‌ها جاییه که معمولاً پروژه‌ها زمین می‌خورن.


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

https://www.infoq.com/articles/adopt-micro-frontends/

@DevTwitter | <Mansour Kalagar/>

وقتشه React رو با تمام وجود بغل کنیم: RSC کل قواعد بازی رو عوض کرد
به عنوان یک توسعه‌دهنده اگه از حجم سنگین جاوااسکریپت و کندی لودینگ‌ها خسته شدید این خبر برای شماست: React Server Components (RSC) اینجاست تا نجاتمون بده
جریان از چه قراره؟
به جای اینکه کل کد رو مثل یک بار سنگین بفرستیم به مرورگر کاربر RSC میگه:
کارهای سخت رو بده به سرور: کامپوننت‌هایی که فقط داده می‌خونن یا زیاد تغییر نمی‌کنن میرن سمت سرور اجرا میشن
چی میره برای کاربر؟ فقط خروجی نهایی و تمیز (مثل HTML/CSS) دیگه نیازی به جاوااسکریپت اون بخش توی کلاینت نیست
دنیای جدید: معماری هیبرید
سرور کامپوننت‌ها: برای لیست‌های بلندبالا و گزارش‌های تحلیلی (Performance)
کلاینت کامپوننت‌ها: برای دکمه‌ها، انیمیشن‌ها و هر چیزی که نیاز به تعامل لحظه‌ای داره (Interactivity)
چرا باید هیجان‌زده باشیم؟
سرعت، سرعت، سرعت: لودینگ اولیه فوق‌العاده سریع‌تر میشه
کد نویسی آسون‌تر: مستقیماً توی کامپوننت سرور به دیتابیس وصل شو خداحافظی با زنجیره‌ای از fetchها

@DevTwitter | <Mojtaba Vahedi/>

امروز داشتم یکم ریکت یاد میگرفتم ک یهو با سایت usehooks.com روبرو شدم.
منبع جالب و خوب برای اموزش و استفاده از هوک های آماده react هست.

طبق بررسی ک انجام دادم کدهای موجود در سایت ساده و قابل فهم هستن و کاربردی میتونه باشه ،
امیدوارم ک بدردتون بخوره

@DevTwitter | <Ali Adinehpour/>

یکی از خروجی‌های دوره‌ی LLMی که برگزار کردم این بود که PHP کار ها واقعا اذیت میشن! پکیج درست حسابی که حداقل‌های کار با LLM رو ندارن.

برای همین مشابه پکیج goai-kit که قبلا زده بودم، یه ورژن PHP هم زدم:
https://github.com/mhrlife/phpai-kit

تاثیرش: اسکیما و تول خودکار + اتصال به OTEL لنگفیوز

@DevTwitter | <The Big Rad/>

خبر داغ
اُپِن اِی‌آی همین الان «Prompt Pack» برای همهٔ شغل‌ها منتشر کرد!
دیگه لازم نیست ساعت‌ها وقت بزاری پرامپت بنویسی.
دوره‌های موجود:
- فناوری اطلاعات (IT)
- فروش (Sales)
- محصول (Product)
- مدیران (Managers)
- بازاریابی (Marketing)
- مدیران اجرایی (Executives)
- موفقیت مشتری (Customer Success)
- مهندسی (Engineering)
- منابع انسانی (HR & People Ops)
- رهبران (Leaders)
- فناوری اطلاعات دولتی(Government IT)

https://academy.openai.com/public/tags/prompt-packs-6849a0f98c613939acef841c

@DevTwitter | <Alireza Anbari/>

دیگه از du -sh استفاده نکنید!
سال‌هاست خیلی‌هامون برای پیدا کردن فایل‌ها و فولدرهای حجیم روی سرورها از دستورهایی مثل du -sh استفاده می‌کنیم.
اما واقعیت اینه که این روش چندتا مشکل جدی داره.
مشکلات du -sh:
سرعت پایین روی مسیرهای بزرگ
نداشتن رابط تعاملی برای مرور زیرشاخه‌ها
سخت بودن مقایسه حجم فولدرها
نیاز به اجرای چندباره برای دیدن عمق‌های مختلف
عملاً روی سرورهای شلوغ وقت‌گیر و اعصاب‌خوردکنه.

اینجاست که ابزار حرفه‌ای‌تر و کارآمدتر وارد میشه:
ابزار ncdu؛ ابزار سریع، تعاملی و دقیق برای تحلیل فضای دیسک
درواقع نسخه بهینه و امروزی دستور du هست
نه‌ فقط سریع‌ تر، بلکه با یک UI داخل ترمینال کار رو چند برابر ساده‌تر می‌کنه.

مزیت‌های ncdu:
سرعت فوق‌العاده بالا در اسکن مسیرها
محیط تعاملی برای بالا/پایین رفتن بین فولدرها
مرتب‌سازی اتوماتیک بر اساس حجم
پیدا کردن خیلی سریع بزرگ‌ترین مصرف‌کننده‌های دیسک
در ضمن نصبش هم خیلی راحته:
Debian base:
apt install ncdu
RHEL base:
yum install ncdu
macOs:
brew install ncdu
برای استفاده از ncdu هم فقط کافیه بزنید مسیر مورد نظر ncdu مثل ncdu /var/log.

@DevTwitter | <Erfan Darbani/>

یه system prompt نوشتم برای audit کردن پرامپت‌ها.
از وقتی GPT-5 اومده و نسبت به تناقض‌ها حساس‌تر شده، ازش استفاده می‌کنم و خیلی کمکم کرده.

چیزایی که چک می‌کنه:
• تناقض‌ها و دستورات متضاد
• ابهام و واژه‌های چندمعنایی
• زبان منفی (don't → do)
و ...

https://gist.github.com/mhrlife/9cdf593604e7d1bda80c3d87a9478a8e

@DevTwitter | <The Big Rad/>

خداحافظ گیت‌هاب، سلام کدبرگ: کوچ بزرگ ریپازیتوری اصلی زیگ

زبان برنامه‌نویسی زیگ (Zig) رسماً ریپازیتوری اصلی خود را از گیت‌هاب به کدبرگ (Codeberg) منتقل کرد. این تصمیم که از مدت‌ها قبل مورد بحث بود، نشان‌دهنده تعهد زیگ به تمرکززدایی، متن‌باز بودن واقعی و دوری از وابستگی به پلتفرم‌های متمرکز تحت مالکیت شرکت‌های بزرگ است. کدبرگ یک پلتفرم غیرانتفاعی مبتنی بر جامعه است که بر اساس Gitea (یک فورک متن‌باز از گیت‌هاب) ساخته شده و بر ارزش‌های آزادی نرم‌افزار و حریم خصوصی کاربران تاکید دارد.

انتقال شامل ریپازیتوری اصلی زیگ (ziglang/zig) و همچنین سایر ریپازیتوری‌های مرتبط با اکوسیستم زیگ است. این اقدام با هدف تقویت کنترل جامعه بر توسعه زیگ و کاهش خطرات ناشی از تغییرات سیاستی یا مالکیت گیت‌هاب انجام شده است. اندرو کلی، رهبر پروژه زیگ، در بیانیه‌ای اعلام کرد که این انتقال گامی حیاتی برای تضمین آینده‌ای پایدار و مستقل برای زیگ است.

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

فرآیند انتقال به تدریج انجام شده و شامل انتقال کد، تاریخچه، مسائل (issues) و درخواست‌های ادغام (pull requests) است. تیم زیگ ابزارهایی را برای تسهیل انتقال برای توسعه‌دهندگانی که در این پروژه مشارکت دارند، ارائه کرده است. این انتقال ممکن است در کوتاه‌مدت باعث ایجاد اختلالاتی شود، اما انتظار می‌رود در بلندمدت به نفع پایداری و استقلال زیگ باشد.

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

چرا این مطلب مهم است؟
انتقال ریپازیتوری زیگ از گیت‌هاب به کدبرگ نشان‌دهنده یک تغییر پارادایم در دنیای متن‌باز است. این حرکت نه تنها استقلال و پایداری زیگ را تضمین می‌کند، بلکه الگویی برای سایر پروژه‌ها ارائه می‌دهد که به دنبال کنترل بیشتر بر سرنوشت خود هستند. این تصمیم می‌تواند تاثیر قابل توجهی بر آینده توسعه نرم‌افزار متن‌باز و توزیع قدرت در اکوسیستم فناوری داشته باشد. این رویداد نشان می‌دهد که جامعه متن‌باز به طور فزاینده‌ای نسبت به تمرکز و کنترل شرکت‌های بزرگ حساس است و به دنبال جایگزین‌های مستقل‌تر و پایدارتر است.

مطلب در ویرگول:
https://vrgl.ir/2aNZB

@DevTwitter | <Alireza DavoodiNia/>

تجربه ی آشنایی با Gateway و معماری Microservices :
توی چند روز اخیر موقعیتی پیش اومد که با گیت وی و معماری میکرو سرویس آشنا شدم و با خودم گفتم یه خلاصه ای ازش رو اینجا بذارم.

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

گیت وی چیه؟
گیت وی نقطه ورودی تمام درخواست‌های کلاینت به سمت سرویس‌هاست.
یعنی به‌جای اینکه مستقیماً به چند سرویس مختلف API بزنیم، همه‌چیز از یک “دروازه” عبور می‌کنه.

++ گیت وی مسئول کارهایی مثل:
- روت کردن درخواست‌ها به سرویس درست
- مدیریت احراز هویت و توکن
- محدودیت سرعت، لاگ‌گیری و امنیت
- ساده‌سازی ارتباط فرانت با پشت‌صحنه

مزایای Gateway :
- یک ورودی مشترک برای همه سرویس‌ها => ساده‌تر شدن ارتباط
- مدیریت یکپارچه امنیت، توکن‌ها و قوانین
- امکان ورژن‌بندی و روتینگ هوشمند
- جمع شدن لاگ‌ها و مانیتورینگ در یک نقطه

️ معایب / چالش‌ها:
- اگر Gateway مشکل داشته باشه، کل سیستم تحت‌تأثیره
- دیباگ سخت‌تره چون درخواست‌ها قبل از رسیدن به سرویس تغییر می‌کنن
- پیچیدگی در تنظیم و قوانین روتینگ (با تمام وجودم این موضوع رو درک کردم (: )
- وابستگی زیاد سیستم به این نقطه‌ی مرکزی

در کل برای منی که هیچ تجربه و دانشی از بک اند نداشتم ،‌ درسته یکم سخت بود برام ولی یادگیری این چیز ها باعث شد دید بهتری داشته باشم.

@DevTwitter | <Ali Joshany/>

کمپانی OpenAi یک دایکیومنت بسیار ارزنده معرفی کرده به عنوان Building an AI-native engineering team

در این سند، راهکارهای قابل اجرا ارائه شده است تا رهبران مهندسی بتوانند از همین امروز فرایند ساخت تیم‌ها و فرآیندهای بومی هوش مصنوعی (AI-native) را آغاز کنند

نسخه فارسی :
https://xpoury4.github.io/ai-native-engineering-persian/
نسخه اصلی :
https://cdn.openai.com/business-guides-and-resources/building-an-ai-native-engineering-team.pdf

لینک گیتهاب برای دانلود :
https://github.com/xPOURY4/ai-native-engineering-persian

@DevTwitter | <POURYA/>

نسخه جدید Docker Engine 29 منتشر شد!
حالا containerd به‌صورت پیش‌فرض نقش «image store» داره
و پشتیبانی آزمایشی از nftables برای فایروال/شبکه لینوکس اضافه شده
یک گام بزرگ به سمت مدرنیته!

@DevTwitter | <MehrdadLinux/>

خیلی وقت بود می‌خواستم ترمینالم رو اون‌طوری که می‌خوام بسازم؛ واسه همین TermForge رو شروع کردم که ترمینال رو با Ansible و پشتیبانی از مک و ابزارهای کوبرنتیز برات می‌سازه.
اگه دنبال یه ترمینال کامل و آماده‌این پیشنهاد می‌کنم امتحانش کنید

https://github.com/Mazafard/TermForge

@DevTwitter | <Maza/>

#میم_شبانگاهی

تیپیکال مشکلات فنی دوستام

@DevTwitter | <Mahdi Hazrati/>

چهار استراتژی کلیدی برای مقیاس‌پذیری مؤثر پایگاه داده

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

۱) استراتژی Vertical Scaling (افزایش ظرفیت سخت‌افزاری)
ساده‌ترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سخت‌افزاری نظیر CPU، RAM و فضای ذخیره‌سازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرم‌افزار انجام می‌شود و در بسیاری از سیستم‌ها، اولین گام منطقی برای افزایش ظرفیت به شمار می‌آید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.

۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخه‌های متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم می‌سازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال می‌شود، Leader تغییرات را به نودهای Follower منتقل می‌کند، عملیات خواندن می‌تواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواست‌های خواندن است.

۳) استراتژی Caching (افزایش سرعت با ذخیره‌سازی موقت)
استفاده از Cache، از تکرار درخواست‌های غیرضروری به پایگاه داده جلوگیری می‌کند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره می‌شود.
درخواست‌های بعدی، در صورت وجود داده در Cache، به‌سرعت پاسخ داده می‌شوند.
این روش علاوه بر کاهش بار پایگاه داده، به‌طور چشمگیری سرعت پاسخ‌گویی را نیز افزایش می‌دهد.

۴) استراتژی Partitioning / Sharding (مقیاس‌پذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخش‌های مستقل (Partitions یا Shards) و توزیع آن‌ها در چندین سرور، امکان افزایش ظرفیت‌پذیری عملیات نوشتن را فراهم می‌کند.
در این مدل:
هر شارد بخشی از داده را مدیریت می‌کند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال می‌شود،
بار نوشتن میان چندین ماشین تقسیم می‌گردد.
این رویکرد برای سامانه‌هایی که حجم عملیات نوشتن آن‌ها بالا است، روشی پایدار و قابل اعتماد به حساب می‌آید.

ارتباط Replication و Sharding
در معماری‌های بزرگ، Sharding و Replication معمولاً به‌صورت ترکیبی مورد استفاده قرار می‌گیرند.
هر شارد روی چندین نود Replicate می‌شود تا در صورت خرابی یک نود، دسترس‌پذیری داده حفظ گردد.

جمع‌بندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستون‌های اصلی مقیاس‌پذیری پایگاه داده در معماری‌های مدرن محسوب می‌شوند.
انتخاب مناسب میان این روش‌ها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیت‌های معماری هر سیستم بستگی دارد.
به‌کارگیری درست و ترکیبی این استراتژی‌ها، امکان ساخت سامانه‌هایی پایدار، سریع و قابل‌اتکا را فراهم می‌کند.

@DevTwitter | <Amir Rahimi Nejad/>