Tech Stuff

پذیرش بازخورد

در برنامه‌نویسی معمولا تنها کار نمی‌کنیم و بخش زیادی از رشد ما از تعامل با بقیه اعضای تیم اتفاق میفته. یکی از مهم‌ترین جاهایی که این موضوع رو می‌بینیم Code Review هست. وقتی کسی کدی که نوشتیم رو بررسی می‌کنه، هدفش پیدا کردن ایراد، بهتر کردن کیفیت کد و انتقال تجربه است؛ نه اینکه توانایی ما رو زیر سوال ببره.

البته دریافت بازخورد همیشه راحت نیست. وقتی چند نفر کدی که نوشتیم رو بررسی می‌کنن، ممکنه حس کنیم دارن از کار ما ایراد می‌گیرن، ولی باید یادمون باشه که این بازخورد درباره کد ماست، نه درباره خود ما. حتی بازخوردهای منفی هم معمولا نکته‌ای برای یاد گرفتن دارن؛ مهم اینه که بخش مفیدش رو پیدا کنیم و از قسمت‌هایی که فقط باعث ناراحتی میشن عبور کنیم.

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

متن از کتاب Skills of a Successful Software Engineer نوشته Fernando Doglio گرفته شده.

#Skills_of_a_Successful_Software_Engineer

@techstuff100

نتفلیکس چطور ۲۶۰ میلیلون استریم همزمان رو بدون Buffering مدیریت می‌کنه؟

نتفلیکس فقط به افزایش تعداد سرورها متکی نیست؛ بخش بزرگی از موفقیتش به معماری توزیع محتوا برمی‌گرده. ویدیوها قبل از اینکه کاربری درخواستشون رو بده، روی هزاران سرور CDN اختصاصی به اسم Open Connect که داخل شبکه ISPها قرار دارن توزیع میشن تا درخواست‌ها از نزدیک‌ترین نقطه پاسخ داده بشن. از طرف دیگه هر کاربر با استفاده از Adaptive Bitrate (ABR) کیفیت مناسب با شرایط لحظه‌ای شبکه خودش رو دریافت می‌کنه و همین باعث میشه در بیشتر مواقع پخش ویدیو بدون Buffering ادامه پیدا کنه.

مقاله همچنین توضیح میده که مدیریت میلیون‌ها استریم همزمان فقط مسئله زیرساخت نیست؛ بلکه مجموعه‌ای از تصمیم‌های مهندسی مثل انتخاب نزدیک‌ترین CDN، کش کردن محتوا، توزیع هوشمند ترافیک، مانیتورینگ مداوم و Failover خودکار باعث میشن حتی در زمان اوج مصرف هم سرویس پایدار باقی بمونه.

لینک مقاله

@techstuff100

حمله SSL Stripping و روش‌های دفاع

این پست درباره SSL Stripping و مکانیزم HSTS هست. HSTS یک Response Header ساده است که باعث میشه مرورگر فقط از HTTPS برای یک دامنه استفاده کنه. همچنین می‌بینیم چرا HSTS به تنهایی کافی نبود و مرورگرها برای حل مشکل اولین بازدید، HSTS Preload List رو معرفی کردن.

#cyber_security

@techstuff100

کتابی که اخیرا شروعش کردم.

#Skills_of_a_Successful_Software_Engineer

@techstuff100

مفهوم Downsampling در داده‌های متریک

توی این پست درباره downsampling در داده‌های متریک و استفاده ازش در طراحی سیستم‌های مانیتورینگ صحبت کردم. این موضوع کمک می‌کنه حجم داده‌های time-series کنترل بشه و هزینه ذخیره‌سازی و کوئری‌ها کمتر بشه.

پ.ن: منبع این پست کتاب System Design Interview – An Insider's Guide: Volume 2 هست.

#system_design_interview_volume_2

@techstuff100

هدر Content Security Policy

این هدر مشخص می‌کنه مرورگر اجازه داره فایل‌های جاوااسکریپت، CSS، تصویر و بقیه منابع رو از چه جاهایی بارگذاری کنه. این کار باعث میشه حتی اگه یه مهاجم موفق بشه کد مخرب رو مثلا از طریق XSS داخل صفحه inject کنه، مرورگر در خیلی از مواقع اجازه اجرای اون کد رو نده.

برای فعال کردنش کافیه هدر CSP رو توی responseهای HTTP قرار بدید و مشخص کنید هر نوع منبع از کجا مجازه لود بشه. مثال (1)، قانون اول (default-src 'self') میگه به طور پیش‌فرض همه منابع فقط از همون دامنه‌ای که خود سایت روی اون اجرا شده (same origin) بارگذاری بشن، مگر اینکه برای نوع خاصی از منابع قانون جداگانه‌ای تعریف شده باشه. قانون دوم (script-src) میگه اسکریپت‌ها فقط از همون دامنه سایت ('self') یا از https://cdn.example.com مجاز به بارگذاری هستن.

فرض کنید سایت شما از https://cdn.example.com برای فایل‌های جاوااسکریپت استفاده می‌کنه. اگر مهاجم بتونه کد (2) رو داخل صفحه تزریق کنه، مرورگر قبل از دانلود فایل، CSP رو بررسی می‌کنه. چون evil.com داخل script-src قرار نداره، درخواست رو بلاک می‌کنه و اسکریپت اجرا نمیشه(3).

@techstuff100

مصاحبه System Design اوبر

توی یکی از مقاله‌هایی که اخیرا خوندم، نویسنده تجربه رد شدنش در مصاحبه طراحی سیستم Uber رو توضیح داده بود. مسئله‌ای که بهش داده بودن طراحی یک Real-time Surge Pricing Engine بود؛ سیستمی که باید میلیون‌ها GPS Ping رو پردازش کنه، نسبت عرضه و تقاضا رو برای هر ناحیه محاسبه کنه و هر چند ثانیه ضریب Surge رو به‌روزرسانی کنه. بخش اصلی مصاحبه صرفا طراحی معماری نبود. از همون ابتدا انتظار داشتن قبل از کشیدن هر چیزی، درباره Requirements، SLA، Failure Mode، Latency، Scale و Trade-offها سوال بپرسه.

نکته‌ای که به نظرم جالب بود اینه که مصاحبه‌کننده بیشتر از اینکه دنبال اسم ابزارها یا الگوهای معماری باشه، دنبال منطق پشت تصمیم‌ها بود. سؤال‌هایی مثل «اگر سیستم از کار بیفته چه اتفاقی می‌افته؟»، «دقت مهم‌تره یا سرعت؟»، «چرا این راهکار رو انتخاب کردی؟» و «اولین Bottleneck سیستم کجاست؟» بخش اصلی مصاحبه رو تشکیل می‌دادن. در نهایت هم بازخوردی که نویسنده گرفت این بود که دانش فنی خوبی داشته، اما عمق کافی در تحلیل Edge Caseها و Trade-offها رو نشون نداده بود.

لینک مقاله

@techstuff100

آسیب‌پذیری Path Traversal؛ دسترسی به فایل‌های غیرمجاز

توی این پست درباره آسیب‌پذیری Path Traversal صحبت کردم. این آسیب‌پذیری زمانی اتفاق میفته که ورودی کاربر روی مسیر فایل‌های سرور تاثیر بذاره و اعتبارسنجی درستی انجام نشه.

#cyber_security

@techstuff100