کدهالیک | codehalic

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

این چنل پروژه‌های Open Source، ابزارهای کاربردی و ریپازیتوری‌های جالب برنامه‌نویسی رو جمع‌آوری و معرفی میکنه. t.me/RepoFA دوست داشتید جوین بشید.❤️✌🏽

یکمی حس میکنم ادبیاتش شاید برای کسایی که تازه کار باشن ناآشنا و سخت باشه برای همین یکمی ساده ترش میکنم فرض کنید صفحه سایتتون مثل یه ساختمان بزرگه. اگه کلید برق یه اتاق رو توی پنل ورودی اصلی کل ساختمان بذارید، با هر بار زدن کلید، سیستم مجبور میشه وضعیت تک‌تک اتاق‌ها رو چک کنه ببینه تغییری کردن یا نه. تو این حالت خیلی از برنامه‌نویس‌ها برای حل کندی میرن روی در بقیه اتاق‌ها برچسب میزنن که نیازی به بررسی شما نیست، که این دقیقاً همون استفاده بی‌دلیل از ابزارهایی مثل useMemo هست که فقط کد رو پیچیده‌تر و حافظه رو درگیر میکنه. اما راه اصولی و ساده‌تر اینه که کلید برق رو از ورودی اصلی بردارید و دقیقاً بذاریدش داخل همون اتاق، تا موقع زدن کلید فقط همون بخش واکنش نشون بده و بقیه ساختمان اصلاً متوجه اتفاقی نشن. تو دنیای برنامه‌نویسی به این کار میگن انتقال استیت به پایین‌ترین سطح ممکن یا نزدیک‌ترین مصرف‌کننده. امیدوارم متوجهش شده باشید که منظور دقیقا از پست قبلی چی بود ! @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 | کدهالیک

انگولار ۲۲ با کلی تغییرات اساسی منتشر شده که مهم‌ترینش استیبل شدن Signal Forms به عنوان یه جایگزین یکپارچه و قوی برای فرم‌های قبلیه. تو این آپدیت، استراتژی تشخیص تغییرات کامپوننت‌های جدید به صورت دیفالت روی OnPush تنظیم شده و علاوه بر اجباری شدن مهاجرت به تایپ‌اسکریپت ۶، ابزارهای جدیدی هم برای تزریق وابستگی اضافه شده. یه بخش خیلی هیجان‌انگیز این نسخه، پشتیبانی آزمایشی از WebMCP هست که به ایجنت‌های هوش مصنوعی اجازه میده به جای خوندن ظاهر صفحه، مستقیم از طریق یه پروتکل با اپلیکیشنی که در حال اجراست تعامل داشته باشن. https://angular.dev/events/v22 @codehalics | کدهالیک۴

این لغت یعنی XP مخفف Extreme Programming هست. یه متدولوژی خیلی معروف تو توسعه نرم‌افزاره که همون کنت بک (نویسنده کتابی که تو مقاله بود) اواخر دهه نود معرفیش کرد. ایده اصلیش خیلی سادس: میگه بیاین پرکتیس‌های خوب مهندسی نرم‌افزار رو بگیریم و تا بالاترین حد ممکن (همون اکستریم) اجراشون کنیم. مثلا اگه معتقدیم کد ریویو کار خوبیه، پس بیایم کلا دو نفری پای یه سیستم کد بزنیم که میشه همون پیر پروگرمینگ (Pair Programming). یا اگه تست کردن جوابه، پس اول تست رو بنویسیم و بعد کدش رو بزنیم (TDD). هدف کلی XP اینه که با تکیه روی ارزش‌هایی مثل ارتباط مداوم تو تیم، سادگی تو معماری، و گرفتن فیدبک سریع، هم کیفیت خروجی بره بالا و هم تیم نرم‌افزاری بتونه خیلی راحت‌تر و با استرس کمتر با تغییرات کنار بیاد. @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 | کدهالیک

چرا یه هفتس رو این عدد ۳۹۹۷ گیر کردیم چرا ۴۰۰۰ تا نمیشیم ☹️

خیلی وقتا برای هماهنگ کردن تب‌های مرورگر (مثلا وقتی کاربر تو یه تب لاگ‌اوت میکنه یا سبد خریدش رو آپدیت میکنه) میایم سراغ هک 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 | کدهالیک

کدنویسی در سال ۲۰۲۶ :))) @codehalics | کدهالیک

درایو C برای ویندوز دشمن خونیه، همیشه سعی میکنه پرش کنه حتی اگر شما چیزی نصب نکنی! و نمیتونی خالیش کنی چون نمیدونی چی پرش کرده ولی WinDirStat میتونه! یه ابزار ساده که بهت نشون میده دقیقا چی پر کرده درایوت رو Zeth https://windirstat.net/download.html @codehalics | کدهالیک

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

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

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

برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه نتورک چقدره. برای اینکه دقیق متوجه بشیم، این ۱۰۰۰ تا ایونت ۱۱۷ بایتی رو تو شرایط کاملا یکسان با هر سه تا روش فرستادیم. نتیجه خیلی جالب بود. در ادامه این سری پست ها به بررسی نتایج این آزمایش میپردازیم ! https://theinfinity.dev/articles/websocket-vs-sse-vs-polling @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 | کدهالیک

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

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

‏یه مقایسه جالب بین کلاد کد و کدکس خوندم. ‏اومده سابسکریپشن های ۲۰ دلاری شون رو مقایسه کرده. ‏لیمیت هفتگی کدکس تقریبا اندازه لیمیت ۵ ساعته کلاده. ‏اگه به جای ساب بخوای از api هاشون استفاده کنی روی کدکس ۴۲ و روی کلاد ۱۲۰ برابر گرون‌تر در میاد! https://www.reddit.com/r/ClaudeAI/s/IOnCeQdFQb TripleM✍️ @codehalics | کدهالیک

سلام دوستان شرکت ما در حال استخدام یک نیروی کارآموز حضوری در تهران برای پوزیشن فرانت اند دولوپره اگر با فریم ورک های React/Next JS کار کردید رزومه هاتون رو برای این ایمیل بفرستید amirzahedi0@gmail.com #frontend ➖➖➖➖➖➖➖➖➖➖ 💬 @job_bashe | گروه کار باشه با دسته بندی شغلی 📢 @karbashe_ir | کانال کار باشه