مهندسی

احتمالاً می‌دونید که سال پیش کانال @TechGrub رو راه انداختم. ایده این بود که هر روز یک پست دربارهٔ مهندسی نرم‌افزار، مدیریت یا هوش مصنوعی توش منتشر بشه. ایدهٔ ابتدایی هم از اینجا شروع شده بود که من قبلاً یک لیست طولانی از وبلاگ‌های افراد فعال حوزهٔ تک و شرکت‌ها داشتم و هر روز با یک RSS Reader نوشته‌های جدیدشون رو می‌خوندم. بعد یک بات تلگرام نوشتم که خودش این مطالب رو برمی‌داشت، خلاصه می‌کرد و برام می‌فرستاد. در ادامه همین رو تبدیل به یک کانال کردم: هر روز بهترین مطلب رو انتخاب می‌کردم، می‌رفت توی صف انتشار و روزی یک پست ارسال می‌شد. ...

هر محصول از چندین برنامهٔ قابل‌اجرا تشکیل شده که با رشد تیم و وسعت محصول، تعدادشون کم‌کم به ده‌ها یا حتی صدها برنامه می‌رسه. سازمان‌ها معمولاً سرویس‌ها رو بر اساس اهمیت به چند سطح تقسیم می‌کنن: tier1، tier2، … تا برای هر سطح SLA، آن‌کال، و ظرفیت منابع متفاوتی تعریف کنن. به عنوان نمونه در مثال دیجیکالا، اپلیکیشن ثبت سفارش می‌تونه tier1 باشه چون مستقیم روی درآمد و تجربه‌ی کاربر اثر می‌ذاره، اما بخش لایو اینفلونسرها tier کم‌اولویت‌تری داره و اگر چند دقیقه هم از دسترس خارج بشه، اثرات خیلی کمتری داره. ...

آسیب‌پذیری IDOR چیه؟ آسیب‌پذیری IDOR یا Insecure Direct Object Reference که زیرمجموعه‌ای از آسیب‌پذیری‌های کنترل دسترسیه، زمانی اتفاق می‌افته که یه API طوری طراحی شده باشه که با استفاده از شناسه‌های قابل حدس، مثل یوزرنیم یا عددهای افزایشی (مثلاً 123)، امکان دسترسی به اطلاعات رو بده. یعنی اگر من یوزر 123 هستم و به اطلاعات خودم دسترسی دارم، بتونم با تغییر عدد به 124، اطلاعات یوزر بعدی رو هم ببینم. ...

در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از Test Doubleها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم. فیک Fake این نوع Test Double به عنوان یک جایگزین ساده‌تر، کم‌هزینه‌تر و قابل آزمایش‌تر برای دیپندنسی مورد نظر استفاده می‌شه. Fakeها از همون interfaceهای دیپندنسی اصلی استفاده می‌کنه و اون‌ها رو پیاده‌سازی می‌کنه. مثلاً، فرض کنید می‌خوایم یک شیء رو در دیتابیس بنویسیم و بخونیم. به جای راه‌اندازی یک دیتابیس واقعی برای اجرای هربارهٔ تست‌ها، از یک دیکشنری in memory استفاده می‌کنیم تا وظیفه خوندن و نوشتن داده‌ها رو برامون انجام بده. توی این حالت این دیکشنری وظیفهٔ Fake کردن دیتابیس اصلی رو بر عهده داره. ...

من حدود ۱۰ سال پیش کارم رو به عنوان کارآموز بکند (Laravel) در شرکتی شروع کردم. محصول اصلی اون موقع تیم یک نرم‌افزار هتل‌داری چندزبانه بود. بعد از مدتی دیدن tutorial و تمرین کردن، مدیر فنی تیم به نظرش رسید که آمادهٔ کد زدن بر روی پروژهٔ اصلی شرکت هستم و وارد تیم شدم. وقتی اولین تسک رو انجام دادم، با استرس پول‌ریکوستی که ساخته بودم رو برای مدیرم فرستادم. قبل از این که بازش کنه ازم پرسید که خودت ریویو کردی؟ یکم تعجب کردم و گفتم نه. گفت پس برو اول خودت ریویو کن، کدت رو بر اساس کامنت‌هات درست کن و بعدش دوباره برای من بفرست. پیشنهاد هم کرد که این ریویوها رو قبل از کامیت کردن کد انجام بدم و همونجا git diff رو هم بهم یاد داد. ...

شاپیفای آماری از Black Friday امسال منتشر کرده که اعدادش حیرت آوره 🤯 پردازش 7TB خط لاگ در دقیقه پاسخ دادن به ۱۷۰ میلیون درخواست در دقیقه (2M rps) استفاده از ۲.۴ میلیون CPU Core بر روی کوبرنتیز پاسخ دادن به ۴۵ میلیون کوئری بر ثانیه با MySQL (!) پردازش ۶۶ میلیون پیام کافکا در ثانیه

چه کاری رو می‌تونستیم متفاوت انجام بدیم تا جلوی این اتفاق رو بگیریم؟ این سوالیه که بعد از رخ دادن یک باگ، یک دیپلوی اشتباه، پاک شدن اشتباهی داده‌ها یا حتی شکست خوردن یک پروژه از خودمون و از تیم می‌پرسیم. معمولاً خروجی این سوال تبدیل به تعدادی تسک و یا داکیومنت‌هایی مثلpost mortem می‌شه. دیروز این توییت رو از Lorin Hochstein خوندم که معتقد بود که این سوال، سوال خوبی نیست و ممکنه ریشهٔ اصلی مشکل رو نشون نده و از آماده شدن برای رخ دادن مجدد مشکل جلوگیری کنه. پیشنهاد داده‌ بود که به جاش سعی کنیم که لحظهٔ به وجود اومدن مشکل رو از زاویه دید افراد درگیر در اون بازهٔ زمانی ببینیم. ای پرسش رو مطرح کنیم که اون‌ها در اون زمان چی می‌دیدن و چه داده‌هایی در دست داشتن که به تصمیم‌گیری اشتباه منتج شده. با جواب دادن به این سوال‌ها شاید دقیق‌تر متوجه ریشهٔ تصمیم‌های اشتباه بشیم. ...

از صفحاتی جالبی که امروز به چشمم خورد Write your Own Virtual Machine بود. این صفحه به صورت خیلی ساده و قدم به قدم ساختن یک VM رو توضیح می‌ده و با خوندنش گذاری به معماری کامپیوتر، مدیریت حافظه و اسمبلی می‌زنید.

گزارش تک رادار ۳۱ منتشر شد. این گزارش هر شش ماه یک بار توسط Thoughtworks و به قلم تعدادی از لیدرهای شرکت‌های مهندسی منتشر میشه. در هر نسخهٔ گزارش، تغییرات دنیای نرم‌افزار در چهار زمینهٔ Techniques, Tools, Platforms, and Languages & Frameworks بررسی میشه. محورهای اصلی گزارش این نسخه به این صورته: — Coding assistance antipatterns — Rust is anything but rusty — The gradual rise of WASM (Web Assembly) — The Cambrian explosion of generative AI tools ...

سکرت روتیشن به این صورت تعریف می‌شه که در بازه‌های معینی، یکی از سکرت‌ها و یا همهٔ سکرت‌های سیستمتون رو عوض کنید. این سکرت می‌تونه پسورد‌ها، کلید APIها و یا هر دادهٔ حساس دیگری باشه. هدف این کار کاهش بازهٔ زمانی معتبر بودن این سکرت‌ها و کاهش خسارت بعد از لیک شدن داده‌ها است. بذارین چندتا حالت فرضی رو مثال بزنم. فرض کنید کلید مهمی در بین افراد و پروژه‌های مختلف به اشتراک گذاشته شده. افراد از شرکت می‌رن ولی کماکان این کلید رو در اختیار دارن. دولوپری پسورد سرویسی رو به اشتباه کامیت می‌کنه. دولوپرها در لاگ کردن خطاها دقت کافی نداشتن و سکرت مهمی به اشتباه لاگ شده (چه در سرویس‌های داخلی، چه در پروایدرهای خارجی مثل Sentry). اگر به هر کدوم از این موارد آگاه باشید احتمالاً سکرت رو عوض خواهید کرد. اما ممکنه به این مسئله آگاه نباشید و برای جلوگیری از لیک شدن داده‌ها تلاشی نکنید. سکرت روتیشن کمک می‌کنه که این تغییرات رو به یک پروسه تبدیل کنید و به اطلاع‌رسانی افراد وابسته نباشید. ...