تفاوت any و unknown توی TypeScript

توی TypeScript، وقتی نمی‌دونیم یه مقدار دقیقا چه نوعی داره، معمولا از any استفاده می‌کنیم. در کنارش یه گزینه دیگه هم داریم: unknown.

می‌تونیم اینطوری مقایسه‌شون کنیم: any یعنی «بی‌خیال تایپ شو و هر کاری دوست داری بکن» آزادی کامل میده، ولی ریسک کرش بالا میره. unknown یعنی «من نمی‌دونم تایپش چیه، ولی قبل از استفاده باید مطمئن بشی» یه جورایی جلوی اشتباهات رو می‌گیره و کد امن‌تر میشه.

مثال رو ببینید.

@techstuff100

آشنایی با Database Sharding: وقتی دیتابیس بزرگ میشه چیکار کنیم؟

وقتی اپلیکیشن‌مون رشد می‌کنه و تعداد کاربرها و حجم دیتا زیاد میشه، یه نقطه‌ای میرسه که دیتابیس دیگه نمی‌کشه و response time میره بالا. این دقیقا همون جاییه که Database Sharding به کمکمون میاد.

تو Sharding میایم دیتابیس رو به تیکه‌های کوچکتر (shard) تقسیم می‌کنیم و روی چند تا سرور پخششون می‌کنیم. این کار رو می‌تونیم به روش‌های مختلفی مثل Range-based، Hash-based یا حتی Geo-based انجام بدیم. این کار پیچیدگی‌های خودش رو داره؛ مثلا باید حواسمون باشه که دیتا به صورت متوازن بین سرورها توزیع بشه تا hotspot نداشته باشیم.

لینک مقاله:
https://aws.amazon.com/what-is/database-sharding/

@techstuff100

نکته حرفه‌ای React: چطور یک کامپوننت سنگین با children رو memoize کنیم؟

مموایز کردن کامپوننت‌های سنگین که children دارن، یه چالش جالبه که خیلی‌ها توش اشتباه می‌کنن. اکثرا فکر می‌کنن اگه هم برای children و هم کامپوننت سنگین از memo استفاده کنن کافیه. (کد ۱)

راه‌حل درست اینه که children رو با useMemo مموایز کنیم. چون children در نهایت یک آبجکته و با هر بار رندر، یک آبجکت جدید ساخته میشه. (کد ۲)

@techstuff100

مدیریت state در React: از useState تا useReducer

مدیریت stateها توی کامپوننت‌های React گاهی خیلی پیچیده میشه. مخصوصا وقتی از useStateهای متعدد برای state های مرتبط استفاده می‌کنیم. نتیجه‌ش میشه یه کامپوننت شلوغ که نگهداریش سخته. وقتی stateها به هم وابسته‌ن، آپدیت کردنشون با useStateهای جداگانه می‌تونه دردسرساز بشه. هر تغییر کوچیک نیاز به کلی کد داره و پیدا کردن باگ‌ها هم سخت‌تر میشه؛ چون trace کردن تغییرات state خیلی پیچیده‌ست.

توی همچین وضعیتی، useReducer خیلی بکارمون میاد. به جای اینکه state‌های مرتبط رو با useState‌های جدا مدیریت کنیم، می‌تونیم همه‌شون رو توی یه آبجکت بذاریم و با یه reducer مدیریتشون کنیم. حتی می‌تونیم یه قدم جلوتر بریم و یه custom hook بسازیم که جزئیات پیاده‌سازی reducer رو مخفی کنه و یه interface تمیز به کامپوننت‌هامون بده. این جوری کدمون هم تمیزتر میشه، هم نگهداریش راحت‌تر.

لینک مقاله:
https://thetshaped.dev/p/how-to-use-reducer-in-react-for-better-and-simpler-state-management

@techstuff100

ریاضی پشت پرده فیلترهای Blur

وقتی برای عکس‌هامون از فیلتر blur استفاده می‌کنیم، در واقع یک عملیات ریاضی پیچیده به اسم Convolution روی عکس انجام میشه. این عملیات با استفاده از یک ماتریس کوچیک به اسم kernel، برای هر پیکسل، مقدار پیکسل‌های اطرافش رو می‌خونه و با یک فرمول خاص ترکیبشون می‌کنه.

معروف‌ترین نوع blur یعنی Gaussian Blur، از تابع گوسی استفاده می‌کنه. این فیلتر به جای اینکه همه پیکسل‌های اطراف رو یکسان در نظر بگیره، به پیکسل‌های نزدیک‌تر وزن بیشتری میده و همین باعث میشه blur طبیعی‌تری ایجاد بشه. این فیلتر علاوه بر ویرایش عکس و شبکه‌های اجتماعی، توی حوزه‌های بازی‌سازی (برای Motion Blur)، عکاسی حرفه‌ای (برای ایجاد عمق میدان)، و حتی رمزنگاری و حریم خصوصی داده‌ها هم کاربرد داره.

لینک مقاله:
https://readmedium.com/en/https:/medium.com/puzzle-sphere/math-behind-image-blur-instagram-snapchat-gaussian-function-quantum-mechanics-convolution-kernel-average-45757b744e83

@techstuff100

آشنایی با Rate Limiting

این مسئله وجود داره که یه سری کاربر یا سرویس، منابع سیستم رو به خودشون اختصاص میدن و بقیه کاربرها نمی‌تونن درست از سرویس استفاده کنن. مثلا یه API داریم که یهو یه کاربر شروع می‌کنه به ارسال درخواست‌های زیاد و کل سیستم رو کند می‌کنه. یا بدتر از اون، ممکنه با DoS attack روبرو بشیم که عملا سرویس‌مون رو از دسترس خارج کنه.

یکی از راه‌حل‌ها می‌تونه Rate Limiting باشه. با استفاده از الگوریتم‌هایی مثل Token Bucket یا Sliding Window می‌تونیم تعداد درخواست‌ها رو محدود و کنترل کنیم. مثلا می‌تونیم بگیم هر کاربر در هر دقیقه فقط ۱۰۰ تا درخواست می‌تونه بفرسته. یا می‌تونیم برای هر endpoint مشخص کنیم چقدر traffic قبول می‌کنه. این‌جوری هم جلوی سوءاستفاده رو می‌گیریم، هم تجربه کاربری بهتر میشه و هم هزینه‌های سرور رو می‌تونیم کنترل کنیم.

لینک مقاله:
https://www.solo.io/topics/rate-limiting

@techstuff100

الگوی BUILD-OPERATE-CHECK در تست‌نویسی

توی تست‌نویسی، خیلی وقت‌ها تست‌هامون شلوغ و نامنظم میشن و فهمیدن اینکه چی به چیه سخت میشه. الگوی BUILD-OPERATE-CHECK که توی کتاب Clean Code هم بهش اشاره شده، یه راه حل ساده‌ست که به تست‌هامون ساختار میده. این الگو تست‌های ما رو به سه بخش تقسیم می‌کنه:

۱. قسمت BUILD (ساخت): در این مرحله داده‌های ورودی و مورد نیاز برای تست رو آماده می‌کنیم.

۲. قسمت OPERATE (اجرا): عملیات اصلی که می‌خوایم تست کنیم رو اجرا می‌کنیم.

۳. قسمت CHECK (بررسی): نتایج به دست آومده رو با نتایج مورد انتظار مقایسه می‌کنیم.

فرض کنید توی React می‌خوایم یک دکمه Toggle ساده رو تست کنیم. کد رو در نظر بگیرید.

@techstuff100

نحوه عملکرد CDN و تاثیرش در بهبود عملکرد پروژه‌های وب

شبکه توزیع محتوا یا CDN، سیستمی از سرورهای توزیع‌شده هست که محتوای وب رو به کاربران نزدیک‌تر (از نظر جغرافیایی) ارائه می‌کنن و سرعت لود سایت رو افزایش میدن.

عملکرد اصلی CDN ذخیره و ارائه محتوای استاتیک و داینامیک به کاربرانه. این کار با استفاده از Origin Server (سرور اصلی که همه محتوا اونجا نگهداری میشه)، Edge Servers (سرورهای توزیع شده در مناطق مختلف جغرافیایی)، Caching (ذخیره‌سازی محتوا روی سرورهای لبه برای کاهش درخواست‌های مکرر) و DNS Routing (هدایت کاربران به نزدیک‌ترین سرور لبه) انجام میشه.

سه روش استفاده از CDN برای پروژه‌مون داریم. Remote hosting که ساده و سریعه و از caching جهانی بهره می‌بره، Local hosting که کنترل کامل و امنیت بیشتری داره و Hybrid hosting که ترکیبی از این دو روشه. برای سایت‌های با مخاطب جهانی، Remote CDN گزینه بهتریه، اما اگه امنیت یا سفارشی‌سازی براتون مهمه، Local hosting مناسب‌تره.

لینک مقاله:
https://www.freecodecamp.org/news/how-cdns-improve-performance-in-front-end-projects

@techstuff100