بهبود پرفورمنس با will-change در CSS
توی این پست درباره will-change در CSS صحبت کردم. این پراپرتی کمک میکنه مرورگر از قبل برای تغییرات سنگین آماده بشه و رندر روانتری داشته باشیم. بیشتر به درد انیمیشنها، transitionها و تعاملات UI میخوره. پست درباره اینه که کِی و چطوری ازش استفاده کنیم که واقعا به پرفورمنس کمک کنه، نه اینکه برعکس دردسر درست کنه.
#css
@techstuff100
توی این پست درباره will-change در CSS صحبت کردم. این پراپرتی کمک میکنه مرورگر از قبل برای تغییرات سنگین آماده بشه و رندر روانتری داشته باشیم. بیشتر به درد انیمیشنها، transitionها و تعاملات UI میخوره. پست درباره اینه که کِی و چطوری ازش استفاده کنیم که واقعا به پرفورمنس کمک کنه، نه اینکه برعکس دردسر درست کنه.
#css
@techstuff100
❤7👍2👏1🤔1
کلاسهامون رو چقدر General-Purpose طراحی کنیم؟
کلاسها رو نباید بیشازحد تخصصی طراحی کرد. طراحیِ تا حدی general-purpose کمک میکنه API سادهتر، reusableتر و قابل نگهداریتر بشه. این مفهوم مخصوصا وقتی پروژه بزرگ میشه یا feature جدید اضافه میکنیم خیلی به کار میاد.
#A_Philosophy_of_Software_Design
@techstuff100
کلاسها رو نباید بیشازحد تخصصی طراحی کرد. طراحیِ تا حدی general-purpose کمک میکنه API سادهتر، reusableتر و قابل نگهداریتر بشه. این مفهوم مخصوصا وقتی پروژه بزرگ میشه یا feature جدید اضافه میکنیم خیلی به کار میاد.
#A_Philosophy_of_Software_Design
@techstuff100
❤10👍1
استراتژیهای Caching در معماری سیستم
مشکل اصلی caching معمولا خود اضافه کردن cache نیست، بلکه انتخاب روش درست استفاده از اونه. این مقاله توضیح میده اگر بدون توجه به نوع استفاده سیستم از دادهها cache اضافه کنیم، ممکنه با ناسازگاری دادهها، پیچیدگی در sync دادهها، یا حتی فشار بیشتر روی دیتابیس مواجه بشیم. هر سیستم رفتار متفاوتی داره؛ بعضی بیشتر read دارن، بعضی write زیاد دارن و بعضی هم به درستبودن لحظهای داده خیلی حساسن. برای همین caching در واقع یک انتخاب بین سرعت، دقت داده و پیچیدگی پیادهسازی محسوب میشه.
مقاله چندتا الگوی رایج مثل Cache-Aside، Read-Through، Write-Through، Write-Back و Write-Around رو بررسی میکنه و نشون میده هرکدوم دقیقا کجا کاربرد دارن. مثلا Cache-Aside برای سناریوهایی که read زیاد دارن خیلی رایجه و Write-Through کمک میکنه دادهها sync بمونن. نکته مهم اینه که در سیستمهای واقعی معمولا ترکیبی از چند مدل، بسته به الگوی دسترسی داده و نرخ تغییرات، استفاده میشه.
مقاله:
https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
@techstuff100
مشکل اصلی caching معمولا خود اضافه کردن cache نیست، بلکه انتخاب روش درست استفاده از اونه. این مقاله توضیح میده اگر بدون توجه به نوع استفاده سیستم از دادهها cache اضافه کنیم، ممکنه با ناسازگاری دادهها، پیچیدگی در sync دادهها، یا حتی فشار بیشتر روی دیتابیس مواجه بشیم. هر سیستم رفتار متفاوتی داره؛ بعضی بیشتر read دارن، بعضی write زیاد دارن و بعضی هم به درستبودن لحظهای داده خیلی حساسن. برای همین caching در واقع یک انتخاب بین سرعت، دقت داده و پیچیدگی پیادهسازی محسوب میشه.
مقاله چندتا الگوی رایج مثل Cache-Aside، Read-Through، Write-Through، Write-Back و Write-Around رو بررسی میکنه و نشون میده هرکدوم دقیقا کجا کاربرد دارن. مثلا Cache-Aside برای سناریوهایی که read زیاد دارن خیلی رایجه و Write-Through کمک میکنه دادهها sync بمونن. نکته مهم اینه که در سیستمهای واقعی معمولا ترکیبی از چند مدل، بسته به الگوی دسترسی داده و نرخ تغییرات، استفاده میشه.
مقاله:
https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
@techstuff100
❤6🔥2
عدد جادویی (Magic Number)
عدد جادویی (Magic number) به اون عددهایی میگن که بطور مستقیم توی کد hard code میشن، بدون اینکه توضیح یا نام مشخصی داشته باشند. برنامه باهاشون کار میکنه، ولی آدمی که کد رو میخونه معمولا باید حدس بزنه این عدد از کجا اومده و چرا این مقدار انتخاب شده.
دوری کردن از magic numbers خیلی به تمیز شدن کد کمک میکنه. وقتی عددها رو داخل یه متغیر با اسم درست و حسابی میذاریم، هم کد خواناتر میشه، هم نگهداریش راحتتر. مخصوصا چند ماه بعد که خودمون یا بقیه همکارامون برمیگردیم به پروژه، دیگه لازم نیست حدس بزنیم این 42 یا 300 واقعا برای چی بوده.
@techstuff100
عدد جادویی (Magic number) به اون عددهایی میگن که بطور مستقیم توی کد hard code میشن، بدون اینکه توضیح یا نام مشخصی داشته باشند. برنامه باهاشون کار میکنه، ولی آدمی که کد رو میخونه معمولا باید حدس بزنه این عدد از کجا اومده و چرا این مقدار انتخاب شده.
دوری کردن از magic numbers خیلی به تمیز شدن کد کمک میکنه. وقتی عددها رو داخل یه متغیر با اسم درست و حسابی میذاریم، هم کد خواناتر میشه، هم نگهداریش راحتتر. مخصوصا چند ماه بعد که خودمون یا بقیه همکارامون برمیگردیم به پروژه، دیگه لازم نیست حدس بزنیم این 42 یا 300 واقعا برای چی بوده.
@techstuff100
❤15👍5
نقش CORB در جلوگیری از نشت ریسپانسهای Cross‑Origin
توی این پست در مورد دو تا مکانیزم امنیتی مرورگر صحبت کردم: اولی
جزئیات CORB رو از اینجا میتونید بخونید:
https://www.chromium.org/Home/chromium-security/corb-for-developers/
@techstuff100
توی این پست در مورد دو تا مکانیزم امنیتی مرورگر صحبت کردم: اولی
nosniff که جلوی اشتباه گرفتن نوع فایل رو میگیره و مانع اجرای کد مخرب میشه. دومی CORB که وقتی یه سایت مخرب با تگهایی مثل <img> سعی میکنه اطلاعات حساس یه سایت دیگه (مثل JSON یا HTML) رو دانلود کنه، کل ریسپانس رو خالی میکنه و نمیذاره اون داده اصلا به مرورگر برسه. جزئیات CORB رو از اینجا میتونید بخونید:
https://www.chromium.org/Home/chromium-security/corb-for-developers/
@techstuff100
❤6