سیلو یه جایگزین کاملا مشابه برای MinIO هست که بعد از تغییر لایسنس اون، توسط کامیونیتی فورک و ایجاد شده. این پروژه که قبلا با اسم pgsty/minio شناخته میشد الان یه گزینه عالی برای ذخیره‌سازی S3 به حساب میاد و امکانات مهمی مثل پنل ادمین و داکیومنت‌ها رو دوباره برگردونده. اولین نسخه از این پروژه تو تاریخ ۶ آگوست ۲۰۲۶ منتشر شد و همونطور که تو هکرنیوز هم مطرح شده، کاملا آماده است تا به عنوان یه جانشین قوی، جای خالی MinIO رو برای کاربرا پر کنه.

پ.ن : نسخه جدید minio کلا لایسنسی شده و باید پول بابتش پرداخت کنین !

https://www.ssp.sh/brain/silo/

@codehalics | کدهالیک

فیگما قابلیت جدیدی معرفی کرد که ساخت و استفاده از اسکیل‌ها را مستقیماً داخل محیط فیگما ممکن می‌کند. از این پس کاربران می‌توانند با استفاده از Figma Agent یک اسکیل جدید بسازند، آن را در بخش Community منتشر کنند و اسکیل‌های منتشر شده توسط دیگران را ذخیره کرده و با دستور «/» اجرا نمایند. این تغییر بخش قابل توجهی از فرآیندهای طراحی و اتوماسیون را به درون خود فیگما منتقل می‌کند.

@codehalics | کدهالیک

تا حالا پیش اومده یه اپلیکیشن رو باز کنید و فقط به آیکون در حال چرخش لودینگ خیره بشید؟ این مشکل اعصاب خردکن معمولا به خاطر گیر کردن تو تله Request Waterfall به وجود میاد. یعنی یه درخواست برای گرفتن اطلاعات باید حتما صبر کنه تا درخواست قبلی تموم بشه و همین باعث کندی شدید میشه.

اما راه حل چیه؟ تو این مقاله یاد میگیریم چطور با ترکیب سه تا قابلیت عالی تو Next.js، یعنی React Suspense و Promise.all و Promise.allSettled، دیتاها رو به صورت موازی دریافت کنیم تا سرعت برنامه چند برابر بشه.

به طور خلاصه:

از Suspense استفاده میکنیم تا وقتی دیتا داره لود میشه، یه رابط کاربری موقت (مثل اسکلتون) نشون بدیم و صفحه سفید نمونه.

از Promise.all برای وقتایی استفاده میکنیم که همه دیتاها ضروری هستن و باید با هم لود بشن.

و از Promise.allSettled برای زمانی که میخوایم برنامه مقاوم باشه. یعنی حتی اگه یکی از API ها هم قطع بشه، کل برنامه از کار نمیفته و بقیه دیتاها به کاربر نشون داده میشن.

یه تیکه کد از این روش موازی رو اینجا ببینید:

const getSpellsPromise = fetch('https://api.example.com/spells').then(res => res.json());
const getBooksPromise = fetch('https://api.example.com/books').then(res => res.json());

// دریافت موازی اطلاعات بدون معطلی برای همدیگه
const [spellsResult, booksResult] = await Promise.allSettled([
  getSpellsPromise,
  getBooksPromise,
]);

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

اگه میخواید با جزئیات دقیق تر این روش ها آشنا بشید و کدهای کاملش رو ببینید، پیشنهاد میکنم حتما ادامه این آموزش جذاب رو تو مدیوم بخونید:

https://medium.com/@fufudsby/mastering-parallel-data-fetching-in-next-js-5d5c30be26b3

@codehalics | کدهالیک

مقایسه بین SSE , وب سوکت و Long polling !

برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه نتورک چقدره. برای اینکه دقیق متوجه بشیم، این ۱۰۰۰ تا ایونت ۱۱۷ بایتی رو تو شرایط کاملا یکسان با هر سه تا روش فرستادیم. نتیجه خیلی جالب بود.
در ادامه این سری پست ها به بررسی نتایج این آزمایش میپردازیم !

مقاله اصلی :
https://theinfinity.dev/articles/websocket-vs-sse-vs-polling


@codehalics | کدهالیک

مقایسه هزینه واقعی تو لایه نتورک

رو بستر وب سوکت این هزار تا ایونت کلا ۱۱۹ کیلوبایت ترافیک مصرف کرد. با اس اس ای این عدد شد ۱۳۱ کیلوبایت. اما لانگ پولینگ روی اچ تی تی پی وان (HTTP/1.1) یه فاجعه واقعی بود و ۸۸۴ کیلوبایت ترافیک ساخت. دلیل این اختلاف عجیب و غریب هم هدرهای ریکوئست‌های اچ تی تی پی هست. تو لانگ پولینگ حجم زیادی از هدرها و کوکی‌های سشن برای تک تک این هزار تا ایونت مدام ارسال میشن که فقط ۵۶۹ کیلوبایتش مربوط به همین هدرها بود.

@codehalics | کدهالیک

تاثیر پروتکل‌های جدید و تست سرعت

حالا دو تا سوال مهم پیش میاد. اول اینکه اگه بریم سمت اچ تی تی پی تو (HTTP/2) مشکل لانگ پولینگ حل میشه؟ دوم اینکه آیا وب سوکت تو واقعیت سریعتر پیام‌ها رو میرسونه؟

در مورد سوال اول باید بگم که اچ تی تی پی 2 با فشرده کردن هدرها حجم مصرفی لانگ پولینگ رو از ۸۸۴ به ۱۸۲ کیلوبایت میرسونه و اونو از یه انتخاب افتضاح به یه گزینه معمولی تبدیل میکنه. در مورد سرعت هم وقتی تو یه نتورک با دیلی ۵۰ میلی ثانیه تست کردیم، هر سه تا تکنولوژی پیام‌ها رو تو حدود ۲۶.۵ میلی ثانیه تحویل دادن و اختلافشون حتی به نیم میلی ثانیه هم نرسید. باگ لانگ پولینگ فقط اونجایی خودش رو نشون میده که سرعت تولید ایونت‌ها از زمان رفت و برگشت شبکه بیشتر باشه و پیام‌ها تو صف بمونن. از نظر مصرف مموری سرور هم هر سه تا روش تقریبا تو یه سطح هستن و باز نگه داشتن کانکشن‌ها فرق چندانی تو مصرف منابع سرور نداره.

@codehalics | کدهالیک

بالاخره کدوم رو انتخاب کنیم؟

خب با این تستایی که روی این ۱۰۰۰ تا ایونت زدیم، معماری نهایی رو چطور بچینیم؟ خیلی از تیم‌ها دیفالت میرن سراغ وب سوکت در حالی که همیشه بهترین گزینه نیست.

برای استریم دیتای یه طرفه از سرور به کلاینت، اس اس ای قطعا بهترین انتخابه.( مثل Chatgpt و هوش مصنوعی ها که باهاشون چت میکنین ) درسته که ۱۰ درصد بیشتر از وب سوکت ترافیک مصرف میکنه، اما در عوض قابلیت ریکانکت شدن خودکار رو تو خود مرورگر داره. یعنی دیگه نیازی نیست تو سمت کلاینت کلی کد پیچیده برای هندل کردن قطعی نتورک بنویسید. پس به عنوان یه قانون کلی، معماری سیستمتون رو بر پایه اس اس ای بچینید. فقط زمانی برید سراغ وب سوکت که سیستمتون نیاز داره دیتای ریل تایم با ریت بالا از کلاینت به سرور بفرسته یا اینکه دیتاتون باینری باشه. استفاده از وب سوکت برای یه فید یه طرفه فقط الکی سیستم رو پیچیده میکنه.


@codehalics | کدهالیک

درایو C برای ویندوز دشمن خونیه، همیشه سعی میکنه پرش کنه حتی اگر شما چیزی نصب نکنی!
و نمیتونی خالیش کنی چون نمیدونی چی پرش کرده
ولی WinDirStat میتونه!
یه ابزار ساده که بهت نشون میده دقیقا چی پر کرده درایوت رو

Zeth

https://windirstat.net/download.html

@codehalics | کدهالیک

کدنویسی در سال ۲۰۲۶ :)))

@codehalics | کدهالیک

خیلی وقتا برای هماهنگ کردن تب‌های مرورگر (مثلا وقتی کاربر تو یه تب لاگ‌اوت میکنه یا سبد خریدش رو آپدیت میکنه) میایم سراغ هک localStorage. یعنی یه دیتا مینویسیم و فورا پاک میکنیم تا ایونت storage صدا زده بشه. این روش پر از دردسره، کدهای اضافه زیادی می‌طلبه و کلا از پایه برای این کار ساخته نشده.

راه‌حل نیتیو و اصولی چیه؟ استفاده از BroadcastChannel این API دقیقا برای ارتباط مستقیم بین تب‌ها ساخته شده. نه نیازی به JSON.stringify داره، نه لازم هست ایونت‌های اضافه رو فیلتر کنید و دیتای ساختاریافته رو خیلی راحت منتقل میکنه. فقط یه کانال با اسم مشخص باز میکنید و پیامتون رو می‌فرستید:

توی تب فرستنده:

const channel = new BroadcastChannel('app-sync');
channel.postMessage({ type: 'LOGOUT' });

توی تب‌های گیرنده:

const channel = new BroadcastChannel('app-sync');
channel.onmessage = (event) => {
  console.log(event.data); // { type: 'LOGOUT' }
};

به همین راحتی و تمیزی! فقط یادتون باشه وقتی کارتون تموم شد channel.close() رو صدا بزنید تا ریسورس‌ها آزاد بشن.

@codehalics | کدهالیک

امروز یه مقاله خیلی خوب خوندم که نویسنده مقاله میگه وسط این بلبشوی هوش مصنوعی و توقعات فضایی مدیرها، بازخوانی کتاب ۲۷ ساله «اکستریم پروگرمینگ» کنت بک بدجور جواب میده. خیلیا فکر می‌کنن XP فقط یعنی پیر پروگرمنگ (کد زدن دونفره) و TDD، اما این کتاب ۲۶ تا روش عملی و ۵ تا ارزش کلیدی داره که دقیقاً درمان درد امروز ماست. الان که همه با ابزارهای AI پی‌آرهای غول‌آسا باز می‌کنن و کیفیت کد داره فدای سرعت میشه، اصول XP مثل سادگی، جلوگیری از معماری‌های پیچیده و بی‌خود، بازخورد سریع و احترام به وقت همدیگه یادمون میاره چطور کار کنیم. دلیل پیشنهاد این کتاب همینه که یاد بگیریم چطور وسط این سرعت دیوانه‌وار، کنترل کیفیت پروژه رو دستمون بگیریم و به عنوان یه مهندس زیر فشار ابزارها له نشیم.

لینک کتاب برای مطالعه :
https://refhub.ir/fa/refrence_detail/extreme-programming-explained-embrace-change/

لینک مقاله :
https://managerdotdev.beehiiv.com/p/extreme-programming-1999-2026

@codehalics | کدهالیک

این لغت یعنی XP مخفف Extreme Programming هست. یه متدولوژی خیلی معروف تو توسعه نرم‌افزاره که همون کنت بک (نویسنده کتابی که تو مقاله بود) اواخر دهه نود معرفیش کرد.

ایده اصلیش خیلی سادس: میگه بیاین پرکتیس‌های خوب مهندسی نرم‌افزار رو بگیریم و تا بالاترین حد ممکن (همون اکستریم) اجراشون کنیم. مثلا اگه معتقدیم کد ریویو کار خوبیه، پس بیایم کلا دو نفری پای یه سیستم کد بزنیم که میشه همون پیر پروگرمینگ (Pair Programming). یا اگه تست کردن جوابه، پس اول تست رو بنویسیم و بعد کدش رو بزنیم (TDD).

هدف کلی XP اینه که با تکیه روی ارزش‌هایی مثل ارتباط مداوم تو تیم، سادگی تو معماری، و گرفتن فیدبک سریع، هم کیفیت خروجی بره بالا و هم تیم نرم‌افزاری بتونه خیلی راحت‌تر و با استرس کمتر با تغییرات کنار بیاد.

@codehalics | کدهالیک

انگولار ۲۲ با کلی تغییرات اساسی منتشر شده که مهم‌ترینش استیبل شدن Signal Forms به عنوان یه جایگزین یکپارچه و قوی برای فرم‌های قبلیه. تو این آپدیت، استراتژی تشخیص تغییرات کامپوننت‌های جدید به صورت دیفالت روی OnPush تنظیم شده و علاوه بر اجباری شدن مهاجرت به تایپ‌اسکریپت ۶، ابزارهای جدیدی هم برای تزریق وابستگی اضافه شده. یه بخش خیلی هیجان‌انگیز این نسخه، پشتیبانی آزمایشی از WebMCP هست که به ایجنت‌های هوش مصنوعی اجازه میده به جای خوندن ظاهر صفحه، مستقیم از طریق یه پروتکل با اپلیکیشنی که در حال اجراست تعامل داشته باشن.

https://angular.dev/events/v22

@codehalics | کدهالیک

یه نکته فرانتی خفن برای کسایی که خیلی از useMemo و React.memo استفاده میکنن

استفاده بی‌رویه از useMemo و React.memo بدون پروفایلینگ فقط هزینه‌ی نگهداری کد رو بالا می‌بره، چون ری‌رندر تو ری‌اکت صرفاً اجرا شدن مجدد تابع کامپوننت و ساخت ابجکت‌های جدید JSX هست و تا زمانی که فرآیند Commit و تغییرات فیزیکی DOM اتفاق نیفته، پردازش سنگینی محسوب نمیشه.

چرخه ری‌رندر کلاً سه تا تریگر داره: تغییر استیت داخلی، تغییر مقادیر context، یا دریافت ابجکت المنت جدید از والد؛ بنابراین تغییر Props به‌خودی‌خود تریگر نیست مگر اینکه کامپوننت با React.memo رپ شده باشه تا مقایسه سطحی یا Shallow Compare رو پراپس انجام بده.

برای حل مشکلات کارایی، بهینه‌سازی اول از اصلاح ساختار شروع میشه: پایین بردن محل قرارگیری استیت تا نزدیک‌ترین مصرف‌کننده و استفاده از الگوی ترکیب با children prop که باعث میشه ری‌اکت به دلیل یکسان بودن رفرنس ابجکت، کلاً فاز محاسبه زیردرخت رو Bypass کنه.

در نهایت اگه بعد از سنجش با ابزارهایی مثل Profiler یا React Scan محاسبه سنگینی دیدید، اونوقت تثبیت رفرنس با useMemo یا جداسازی با useDeferredValue معنا پیدا می‌کنه، چرا که حتی React Compiler هم فقط فرآیند ممیوایز کردن رفرنس‌های JSX رو خودکار می‌کنه و توانایی جابه‌جایی استیت یا اصلاح ساختار درخت کامپوننت رو نداره.

https://thetshaped.dev/p/react-rendering-demystified-your-usememo-probably-isnt-doing-anything

@codehalics | کدهالیک

یکمی حس میکنم ادبیاتش شاید برای کسایی که تازه کار باشن ناآشنا و سخت باشه برای همین یکمی ساده ترش میکنم :

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

امیدوارم متوجهش شده باشید که منظور دقیقا از پست قبلی چی بود !

@codehalics | کدهالیک

در یک حرکت انتحاری برای مقابله با BUZZ جک دورسی اسلک هم از فیچر جدید اسلک کد رونمایی کرده !

اسلک قابلیت Slack Code را معرفی کرده که به تیم‌ها اجازه می‌دهد ایجنت‌های هوش مصنوعی را در کانال‌های اختصاصی برای نوشتن، بررسی و انتشار کد به کار بگیرند. این قابلیت با حضور ایجنت‌هایی از جمله کلاد، چت‌جی‌پی‌تی، Devin، کوپایلوت و دیگر سرویس‌ها ارائه شده و روند کدنویسی، بازبینی و پیش‌نمایش را داخل اسلک انجام می‌دهد.

https://slack.com/features/code-channels

دیجیاتو ✍️

@codehalics | کدهالیک

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

خوشبختانه یا متأسفانه، هوش مصنوعی این فاصله ایده تا اجرا رو خیلی کم کرده. فرض کن یه ایده ناب داری؛ اما شرکتی مثل اسلک می‌تونه به لطف AI خیلی سریع کد بزنه و ابزار مشابهش رو بده بیرون. تا تو بخوای یوزربیس جمع کنی و فرهنگش رو بسازی، اسلک از قبل اون همه کاربر فعال رو داره.

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

@codehalics | کدهالیک

چند ماه قطعی‌های اینترنت ایران رو یادتونه؟

وسط همون روزا، یه پروژه‌ی NestJS + Prisma داشتیم که باید دیپلوی می‌شد ولی همه چی خاموش بود !

روی سیستم لوکال همه‌چی عادی بود. ولی همین که npx prisma generate رو تو Container زدیم، گیر کردیم !!
چون Prisma برای Generate کردن Client، یه Engine باینری از سرور خودش (نه npm) دانلود می‌کنه. و اون سرور رو اصلاً دسترسی نداشتیم.

یعنی یه دستور که همیشه چند ثانیه طول می‌کشید، تبدیل شد به یه مشکل واقعی که باید حلش می‌کردیم اونم بدون اینکه اینترنت بین المللی داشته باشیم.

تو این پست کامل نوشتم چطور با پیدا کردن Environment Variable درست، و آوردن Engine باینری سازگار از ریپوی خود Prisma، مشکل رو بدون نیاز به اینترنت حل کردیم:

لینک پست

@codehalics | کدهالیک

اگه این روزا استک پروژه تون NextJs هست و نمیدونین چه مدلی مناسب تره برای کد زدن بهتره که این بنچ مارک که توسط تیمشون انجام شده رو بهش یه نگاه بندازین اینطوری خیلی سیف تر و مطمئن تر روی مدل هایی که استفاده می کنید سرمایه گذاری می‌کنید!
بنچ مارک این موارد رو براتون به نسبت مدل شفاف میکنه:
-امتیازدهی‌ بر اساس نرخ موفقیت
-میانگین مدت‌زمان
-میانگین هزینه

https://nextjs.org/evals

Javad

@codehalics | کدهالیک

زبان G# یا همون جی‌شارپ یه زبان برنامه‌نویسی جدید و متن‌باز برای اکوسیستم دات‌نت هست که ساختارش رو از زبان گو الهام گرفته و می‌خواد برنامه‌نویسی سیستم و موبایل رو با کدهای سبک و امن راحت‌تر کنه. این زبان بهت اجازه میده سادگی و قابلیت‌های همزمانیِ گو مثل کانال‌ها رو در کنار مدل async و await دات‌نت داشته باشی و خیلی راحت از کتابخونه‌ها و پکیج‌های نوگت هم استفاده کنی. چون با دات‌نت ۸ تا ۱۰ سازگاره و خروجی‌های بسیار سبکی میده، هم برای کارهای ابری و وب‌اسمبلی عالیه و هم یه مسیر یادگیری خیلی خوب برای کساییه که می‌خوان از گو، سوئیفت یا کاتلین وارد دنیای دات‌نت بشن.

https://github.com/DavidObando/gsharp

@codehalics | کدهالیک