کلاسهامون رو چقدر 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
تجربه مصاحبه Backend Engineer در Canva استرالیا
مصاحبهشونده از طریق لینکدین برای موقعیت Backend Engineer در دفتر سیدنی Canva اپلای کرد. چالش اصلی براش پروسه فشرده مصاحبهها بود:
۱. مصاحبه با ریکروتر (۳۰ دقیقه): تمرکز روی تجربهها و انگیزه.
۲. مصاحبه تکنیکال (۶۰ دقیقه): شبیهسازی یک دیتابیس با توابع create/get/list روی HashMap.
دور نهایی در روز دوم:
۳. بررسی کد (۴۵ دقیقه): review کد تایپاسکریپت در یک فایل گوگل داک و بحث thread safety/performance.
۴. طراحی سیستم (۴۵ دقیقه): طراحی سیستم پرداخت subscription با تمرکز روی کامپوننتها و APIها در Google Doc.
۵. تسلط به زبان برنامهنویسی (۴۵ دقیقه): ساخت in-memory cache با استفاده از primitiveهای جاوا، مدیریت collision و نوشتن تست.
۶. رهبری، ارتباطات و استراتژی (۴۵ دقیقه): سناریوهای رفتاری مثل کانفلیکتها و شکستها با جزئیات فنی.
۷. تیممچینگ (۶۰ دقیقه): معرفی تیم، چالشها، KPIها و سؤال از tech stack مثل AWS.
در نهایت offer رقابتی بعد چند تماس. مصاحبهشونده اشاره میکنه که توی این فرایند recruiterها انعطافپذیر و پاسخگو بودن.
لینک مقاله
@techstuff100
مصاحبهشونده از طریق لینکدین برای موقعیت Backend Engineer در دفتر سیدنی Canva اپلای کرد. چالش اصلی براش پروسه فشرده مصاحبهها بود:
۱. مصاحبه با ریکروتر (۳۰ دقیقه): تمرکز روی تجربهها و انگیزه.
۲. مصاحبه تکنیکال (۶۰ دقیقه): شبیهسازی یک دیتابیس با توابع create/get/list روی HashMap.
دور نهایی در روز دوم:
۳. بررسی کد (۴۵ دقیقه): review کد تایپاسکریپت در یک فایل گوگل داک و بحث thread safety/performance.
۴. طراحی سیستم (۴۵ دقیقه): طراحی سیستم پرداخت subscription با تمرکز روی کامپوننتها و APIها در Google Doc.
۵. تسلط به زبان برنامهنویسی (۴۵ دقیقه): ساخت in-memory cache با استفاده از primitiveهای جاوا، مدیریت collision و نوشتن تست.
۶. رهبری، ارتباطات و استراتژی (۴۵ دقیقه): سناریوهای رفتاری مثل کانفلیکتها و شکستها با جزئیات فنی.
۷. تیممچینگ (۶۰ دقیقه): معرفی تیم، چالشها، KPIها و سؤال از tech stack مثل AWS.
در نهایت offer رقابتی بعد چند تماس. مصاحبهشونده اشاره میکنه که توی این فرایند recruiterها انعطافپذیر و پاسخگو بودن.
لینک مقاله
@techstuff100
❤5👍1
ماژولهای Shallow و Deep
توی این پست درباره تفاوت نگاه کتابهای Clean Code و A Philosophy of Software Design به shallow یا deep بودن ماژولها صحبت کردم. این مقایسه کمک میکنه بفهمیم همیشه خرد کردن کد به معنی سادهتر شدن سیستم نیست؛ یه trade off بین «خوانایی کد» و «پیچیدگی کل سیستم» هستش.
#A_Philosophy_of_Software_Design
#Clean_Code
@techstuff100
توی این پست درباره تفاوت نگاه کتابهای Clean Code و A Philosophy of Software Design به shallow یا deep بودن ماژولها صحبت کردم. این مقایسه کمک میکنه بفهمیم همیشه خرد کردن کد به معنی سادهتر شدن سیستم نیست؛ یه trade off بین «خوانایی کد» و «پیچیدگی کل سیستم» هستش.
#A_Philosophy_of_Software_Design
#Clean_Code
@techstuff100
❤7🔥1