مهندسی on امین رشیدبیگی

تک‌گراب برگشت، این‌بار بدون نیاز به من

Wed, 28 Oct 2026 16:24:55 +0000

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

بعد یک بات تلگرام نوشتم که خودش این مطالب رو برمی‌داشت، خلاصه می‌کرد و برام می‌فرستاد. در ادامه همین رو تبدیل به یک کانال کردم: هر روز بهترین مطلب رو انتخاب می‌کردم، می‌رفت توی صف انتشار و روزی یک پست ارسال می‌شد.

جلوگیری از اثر زنجیره‌ای در سرویس‌ها (Cascading Effect)

Fri, 14 Nov 2025 09:01:29 +0000

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

آسیب‌پذیری IDOR

Sun, 24 Aug 2025 22:38:18 +0200

آسیب‌پذیری IDOR چیه، چطوری اتفاق می‌افته و چطوری می‌شه جلوش رو گرفت؟ توی این نوشته با یک مثال ساده این آسیب‌پذیری کنترل دسترسی رو بررسی می‌کنیم.

انواع روش‌های تست نرم‌افزار: Test Doubles

Mon, 24 Mar 2025 21:15:33 +0100

در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از Test Doubleها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم.

فیک Fake

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

من اولین کسی هستم که پول ریکوستم رو ریویو می‌کنم

Sat, 15 Mar 2025 18:23:18 +0200

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

شاپیفای آماری از Black Friday امسال منتشر کرده…

Wed, 18 Dec 2024 16:43:29 +0000

شاپیفای آماری از Black Friday امسال منتشر کرده که اعدادش حیرت آوره 🤯

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

چه کاری رو می‌تونستیم متفاوت انجام بدیم تا…

Tue, 17 Dec 2024 16:09:03 +0000

چه کاری رو می‌تونستیم متفاوت انجام بدیم تا جلوی این اتفاق رو بگیریم؟

این سوالیه که بعد از رخ دادن یک باگ، یک دیپلوی اشتباه، پاک شدن اشتباهی داده‌ها یا حتی شکست خوردن یک پروژه از خودمون و از تیم می‌پرسیم. معمولاً خروجی این سوال تبدیل به تعدادی تسک و یا داکیومنت‌هایی مثلpost mortem می‌شه.

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

از صفحاتی جالبی که امروز به چشمم خورد…

Sun, 10 Nov 2024 19:37:46 +0000

از صفحاتی جالبی که امروز به چشمم خورد Write your Own Virtual Machine بود.

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

Tech Radar volume 31

Fri, 01 Nov 2024 17:12:48 +0000

گزارش تک رادار ۳۱ منتشر شد. این گزارش هر شش ماه یک بار توسط 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

Secret Rotation

Fri, 11 Oct 2024 15:16:03 +0000

سکرت روتیشن به این صورت تعریف می‌شه که در بازه‌های معینی، یکی از سکرت‌ها و یا همهٔ سکرت‌های سیستمتون رو عوض کنید. این سکرت می‌تونه پسورد‌ها، کلید APIها و یا هر دادهٔ حساس دیگری باشه.
هدف این کار کاهش بازهٔ زمانی معتبر بودن این سکرت‌ها و کاهش خسارت بعد از لیک شدن داده‌ها است.

بذارین چندتا حالت فرضی رو مثال بزنم.

فرض کنید کلید مهمی در بین افراد و پروژه‌های مختلف به اشتراک گذاشته شده. افراد از شرکت می‌رن ولی کماکان این کلید رو در اختیار دارن.
دولوپری پسورد سرویسی رو به اشتباه کامیت می‌کنه.
دولوپرها در لاگ کردن خطاها دقت کافی نداشتن و سکرت مهمی به اشتباه لاگ شده (چه در سرویس‌های داخلی، چه در پروایدرهای خارجی مثل Sentry).

اگر به هر کدوم از این موارد آگاه باشید احتمالاً سکرت رو عوض خواهید کرد. اما ممکنه به این مسئله آگاه نباشید و برای جلوگیری از لیک شدن داده‌ها تلاشی نکنید. سکرت روتیشن کمک می‌کنه که این تغییرات رو به یک پروسه تبدیل کنید و به اطلاع‌رسانی افراد وابسته نباشید.

دیروز برام ایمیل اومد که دامنهٔ expedition-diaries داره…

Mon, 23 Sep 2024 17:40:45 +0000

دیروز برام ایمیل اومد که دامنهٔ expedition-diaries داره منقضی میشه.

چند سال پیش چالشی برای خودم تعریف کردم که پروژه‌ای رو شروع کنم و همهٔ بخش‌های مختلفش مثل بکند و فرانت‌اند و زیرساخت رو خودم پیش ببرم. قبلاً در هر کدوم از این بخش‌ها تجربه‌های مستقلی داشتم اما هرگز فرصت توسعهٔ همهٔ این بخش‌ها در کنار هم و با هم رو نداشتم. از طرفی هم برای هر کدوم از این بخش‌ها اهداف متفاوتی داشتم:

چند وقت پیش فایل‌های Protocol Buffer پروژه‌ای رو…

Mon, 19 Aug 2024 19:33:13 +0000

چند وقت پیش فایل‌های Protocol Buffer پروژه‌ای رو مرتب‌ می‌کردم که دیدم این دو فیلد در بین چندین message پروژه تکرار شده:

message A {
    ...
    int64 seconds = n;
    int64 nano_seconds = m;
    ...
}

با توجه به این که این دو خط عیناً تکرار شده بود، یک message تعریف کردم و به جای اون دوتا فیلد از message جدید استفاده کردم:

message Timestamp {
    int64 seconds = 1;
    int64 nano_seconds = 2;
}
message A {
    ...
    Timestamp timestamp_utc = p;
    ...
}

بعداً متوجه شدم که Timestamp هم یکی از تایپ‌هاییه که به صورت استاندارد تعریف شده و نیازی نیست خودمون تعریف کنیم. به همین خاطر message‌ها رو به دوباره بازنویسی کردم:

How to create software quality.

Thu, 27 Jun 2024 18:04:16 +0000

کیفیت نرم‌افزار چیه دقیقاً؟ اگر برای توسعهٔ یک محصولی Automated Test خیلی خوبی توسعه بدیم می‌تونیم بگیم که کیفیت بهتر شده؟ یا این که اگر برای دیپلوی‌ها Automated Rollouts داشته باشیم می‌تونیم بگیم حتماً کیفیت رو بهبود دادیم؟

توی این نوشته Will Larson سعی کرده مشاهدات و تجربیاتش در مورد کیفیت نرم‌افزار رو جمع‌آوری کنه و خلاصه کنه.

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

Ten Years and Counting: My Affair with Microservices

Sat, 15 Jun 2024 15:04:51 +0000

چند هفته پیش همایون توی لینکداین این پست رو به اشتراک گذاشته بود و امروز فرصت کردم که بخونمش. یکی از مهندس‌های شرکت allegro که ده سال اخیر رو توی این شرکت بوده و تغییر و تکامل قسمت‌های مختلف فنی شرکت رو دیده این پست رو نوشته. نویسنده با لحن خیلی ساده و از نظر من فروتنانه‌ای از تغییرات معماری، زبان برنامه‌نویسی، دیتابیس‌ها، فرهنگ شرکت و … نوشته.

من این یک خط از متن پست رو خیلی دوست داشتم:

What is DDD - Eric Evans - DDD Europe 2019

Sat, 25 May 2024 14:03:19 +0000

آقای Eric Evans که پدیدآورندهٔ نگاه Domain-Driven Design هستش، توی این ویدیو سعی می‌کنه که خیلی سطح بالا اهمیت Domain و Model و تفاوت‌هاشون رو در طراحی‌های نرم‌افزاری توضح بدن.
برای این کار هم از چندین مثال واقعی استفاده می‌کنه تا تفاوت شیوه‌های مختلف Model کردن یک مسئله در دنیای واقعی به طراحی نرم‌افزاری رو نشون بده.

🔗 لینک ویدیو

Scaling to Count Billions - Canva Engineering Blog

Fri, 17 May 2024 14:19:46 +0000

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

نویسنده‌ از اینجا شروع کرده که در ابتدا طراحی رو خیلی ساده و ابتدایی پیش بردن و به مرور مقیاس بزرگ شده و باعث شده که کدها خیلی پیچیده بشن و دیباگ‌هم سخت‌تر شده. بعد نحوهٔ بازطراحی سیستم‌ها و تغییر تکنولوژی‌ها رو توضیح دادن. دوتا تغییر کلی که دادن به این شکل بوده:

Vector Search: An Introduction

Tue, 16 Apr 2024 07:35:28 +0000

من در بازهٔ اخیر زمان قابل توجهی بر روی مسئلهٔ‌ جستجوی برداری یا vector search گذاشتم. این شیوهٔ جستجو که چند سالیه که بیشتر باب شده و در شرکت‌های بزرگی مثل Netflix و Pinterest به کار گرفته میشه، این امکان رو میده که بر روی مدیاهای غیر متنی مثل صوت، تصویر و ویدیو هم جستجو کنیم. جدا از این مدیاهای غیرمتنی، می‌تونه کمک کنه که جستجوی متنی بهتری رو هم داشته باشیم و به کمکش بر روی اطلاعات استنباط شده از متن جستجو کنیم.

Popular git config options - Julia Evans

Thu, 28 Mar 2024 16:41:49 +0000

تنظیمات و کانفیگ‌های git در یک فایل به آدرس ~/.gitconfig ذخیره شده. شما می‌تونین تنظیمات دیفالت گیت رو با تغییر این فایل و یا داخل پروژه و به صورت locally تغییر بدین. Julia Evans توی این پست از git configهایی نوشته که احتمالاً شما هم مثل من از خیلی‌هاشون خبر نداشتین که اتفاقاً می‌تونن خیلی هم کاربردی باشن.

چند تا از configهایی که خودم بعد از خوندن این نوشته اعمال کردم:

در قسمت نظرهای پست قبلی مهدی خوشنودی موضوع…

Tue, 05 Mar 2024 18:25:43 +0000

در قسمت نظرهای پست قبلی مهدی خوشنودی موضوع «تخمین زدن» رو از زاویه‌ای بررسی کرد که از نظرم جالب و ارزشمندی بود و گفتم اینجا هم به اشتراک بذارم.
فقط متن طولانی بود و نمی‌شد از قابلیت نقل قول تلگرام استفاده کرد و من متن رو کپی می‌کنم.

مهدی:
“زوایه‌ای از موضوع که خیلی برای من جالبه و همیشه بهش فکر می‌کنم خود ایدهٔ «تخمین زدن» هست.
در اولین پاراگراف هم از این پیش‌فرض این که تخمین زدن یه مهارته مهم و تاثیرگذاره صحبت می‌کنی و به نظرم این کمی جای تأمل داره. من یه درگیری ذهنی سر این با خودم دارم که تلاش می‌کنم همیشه خودم رو سر اینکه خود «تخمین زدن» چقدر ارزش داره به چالش بکشم. به نظرم خیلی ساده‌تره که چارچوب ملموسی برای کار تعریف کنیم و بگیم کار X در مدت زمان Y انجام میشه و همه خیالشون راحته که ذهنشون لازم نیست با پیچدگی و گنگی اینکه مشخص نیست یک کار چقدر طول خواهد کشید دست و پنجه نرم کنن ولی واقعیت دنیا اینه که این‌ها بیشتر حدس و گمانن و در نهایت باید این گنگی رو بپذیریم.

Go v1.22

Thu, 15 Feb 2024 17:48:38 +0000

در روزهای اخیر Go v1.22 عرضه شد. از مهمترین تغییرات این نسخه، اضافه شدن امکان loop زدن بر روی یک integer هستش. مثل کد زیر:


package main

import "fmt"

func main() {
 for i := range 10 {
 fmt.Println(10 - i)
 }
}

یک بهبود مهم دیگری که توی این نسخه دادن اینه که تغییراتی روی Garbage Collector صورت گرفته که باعث می‌شه که ۱ تا ۳ درصد در مصرف CPU و حدود ۱ درصد در مصرف مموری صرفه‌جویی بشه.

Error categories and category errors

Fri, 09 Feb 2024 13:29:21 +0000

خطاها عضو جداناشدنی نرم‌افزارها هستن. تصور این که کدی داشته باشیم که هرگز هیچ خطایی براش پیش نیاد غیرواقعی و آرمانی به نظر می‌رسه.
اما خطاها می‌تونن گسترهٔ تبعات خیلی وسیعی داشته باشن. یک ارور شاید باعث بشه که کاربرها فقط چند دقیقه بیشتر منتظر ثبت سفارششون بمونن، یا این که ممکنه باعث خطا در لانچ یک ماهواره و شکست خوردن پروژه و میلیون‌ها دلار ضرر و زیان بشه.

نویسنده ارورها رو به چند دسته تقسیم می‌کنه و در مورد هر کدومشون توضیح می‌ده:
- ارورهایی که قابل پیشبینی هستن و ما می‌تونیم هندلشون کنیم.
- ارورهایی که قابل پیشبینی هستن و ما نمی‌تونیم (یا نمی‌خوایم) هندلشون کنیم.
- ارورهایی که نمی‌تونیم پیشبینی کنیم (همون باگ‌ها).

Useful tradeoffs are multi-dimensional.

Fri, 02 Feb 2024 13:11:42 +0000

اخیراً می‌خواستیم فیچر بزرگی رو به محصولمون اضافه کنیم. فیچر جدید ابعاد زیادی داشت که بعد از چندین اکسپریمنت و لود تست هنوز بخش‌های گنگی داشت. سوال‌هایی از قبیل اینکه می‌تونه همهٔ ریکوست‌های کاربران رو در ساعات مختلف روز جواب بده؟ اینکه owner سرویس‌های درگیر با این تغییرات عمده موافق هستن؟ این که کاربرها می‌تونن از این فیچر استفاده کنن؟ و …
برای ریلیز کردن این فیچر دو راه کلی پیش رومون داشتیم. یکی این که سریع‌ ریلیز کنیم و فیدبک بگیریم (ریسک زیاد، گرفتن فیدبک سریع) یا این که بیایم قبل از ریلیز همهٔ پیشفرض‌هامون رو تست کنیم (ریسک پایین، گرفتن فیدبک کند). اما اومدیم یک راه میانی رو انتخاب کردیم که مزایای هردوی این روش‌ها رو به ارث برده باشه. به این شکل که با تعیین feature flag و ترشولدهای خیلی سخت‌گیرانه محصول رو «دیپلوی» کردیم، اما همزمان فرضیاتمون رو تحلیل می‌کردیم و بعد از مدتی محصول نهاییمون رو «ریلیز» کردیم.
با این کار، عملاً بُعد دیگری به ترید‌آف‌هامون اضافه کردیم؛ همزمان که دیپلوی سریعی داشتیم، ریلیز کم‌ریسکی هم داشتیم.

Twitch Tech Blog - Go memory ballast: How I learnt to stop worrying and love the heap

Fri, 26 Jan 2024 16:22:59 +0000

این نوشته از بلاگ فنی Twitch می‌گه که در بازه‌هایی از زمان ممکنه تعداد ریکوست‌های کاربرها به ۲۰ برابر حالت عادی برسه! مثلاً کانکشن اینترنت یک استریمر پربیننده‌ به مشکل می‌خوره و همهٔ بیننده‌هاش شروع می‌کنن به رفرش کردن. مثل اینه که هر روز باید برای هندل کردن load یک black friday آماده باشن 🙂

در این مواقع، سرویسی که این APIهارو هندل می‌کنه که با Go نوشته شده به مشکل می‌خوره و کند می‌شه. یک راه اینه که به صورت همیشگی اسکیل کنن که خب خیلی پرهزینه و غیربهینه است. حالا اومدن توی این نوشته توضیح دادن که فقط با اضافه کردن یک خط کد به تابع main برنامه، 30% مصرف CPU و 45% لیتنسی رو کاهش دادن! من در ادامه یکم توضیح می‌دم.

Go Test Doubles by Example

Wed, 03 Jan 2024 07:11:43 +0000

چند هفته پیش در مورد روش‌های مختلف تست کردن dependency در کد با استفاده از test-doubleها (mock، stub، و fake) نوشتم. غیر از این سه مورد، test-doubleهای دیگری مثل spy و dummy هم هستن که کاربردهای خاص خودشون رو دارن.

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

پیشنهاد می‌کنم اگر کدی دارید که به یک dependency وابسته است و براش تست می‌نویسید، این نوشته رو بخونید؛ به خصوص اگر با زبان Go کد می‌زنید.
https://aminrb.me/blog/go-test-double/

در هنگام نوشتن Automation Test برای یک نرم‌افزار…

Tue, 19 Dec 2023 08:00:25 +0000

در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از Test Doubleها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ٔ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم.

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

Enhancing the security of WhatsApp calls

Wed, 13 Dec 2023 08:00:55 +0000

تیم فنی واتس‌اپ توی این بلاگ پست توضیح داده که برای افزایش امنیت تماس‌های صوتی چه تغییراتی در طراحی‌هاشون دادن.

برای این کار دوتا امکان به اپلیکیشن اضافه کردن. یکی Silence Unknown Callers است که جلوی مزاحمت و البته حمله‌های مختلف رو به گیرنده می‌گیره. همچنین Protect IP Address in Calls رو اضافه کرده که باعث می‌شه به جای برقراری ارتباط به صورت P2P، سرورهای واتس‌اپ واسط تماس صوتی باشن و طرفین از IP همدیگه اطلاع نداشته باشن تا مواردی از جنس privacy کاربر مثل موقعیت جغرافیایی و پرودایدر اینترنت پنهان بمونه.

Upgrading GitHub.com to MySQL 8.0

Fri, 08 Dec 2023 19:20:29 +0000

بروزرسانی نسخهٔ دیتابیس در خیلی از پروژه‌ها و شرکت‌ها کار پیچیده‌ای نیست و شاید چند ساعت بیشتر زمان نیاز نداشته باشه. اما برای شرکتی مثل Github که +۳۰۰ ترابایت داده رو بر روی بیشتر از ۵۰ کلاستر دیتابیس نگهداری می‌کنه و +۵ میلیون کوئری بر ثانیه رو تحمل می‌کنه، پروژه‌ای بزرگ و پر هزینه است.

در گیتهاب چندین تیم بیشتر از یک سال برای ارتقای mysql 5.7 به 8 بر روی برنامه‌ریزی، تست و اجرای این فرآیند زمان گذاشتن تا بتونن بدون داون‌تایم خاصی، این ارتقا رو صورت بدن.

How Meta built Threads in 5 months

Thu, 30 Nov 2023 19:14:25 +0000

سال پیش شرکت متا محصول Threads رو عرضه کرد. این محصول جدا از سر و صدایی که به خاطر رقابت با توییتر درست کرد، یک شاهکار مهندسی در دنیای نرم‌افزار بود. پیاده‌سازی یک محصول کامل در ۵ ماه، رسیدن به ۱۰۰ میلیون یوزر در یک هفته و بدون هیچ داون‌تایم خاصی!

من خیلی کنجکاو بودم ببینم چطوری محصولی با این کیفیت رو در این مدت زمان کوتاه پیاده‌سازی و عرضه کردن. توی این قسمت از پادکست مهندسی متا، با سه نفر از مهندس‌های Threads در مورد همین موضوع صحبت کردن. یک Android Engineer، یک iOS Engineer و یک Product Backend Engineer.

TechnicalDebtQuadrant

Tue, 07 Nov 2023 08:32:23 +0000

بدهی‌های فنی عضو جدا ناپذیر توسعهٔ یک محصول هستن. با وجود این که عموماً بار معنایی منفی دارن، اما به وجود آوردنش لزوماً تصمیم معیوبی نیست؛ بلکه همونطور که از اسمش پیداست، یک چیزی رو قرض می‌گیریم که در آینده و در فرصت بهتری بهاش رو پرداخت کنیم.

مارتین فالر بدهی‌های فنی رو به چند دسته تقسیم می‌کنه. بدهی‌های فنی می‌تونن بی‌ملاحظه (reckless) باشن و یا محتاطانه (prudent) به وجود اومده باشن. این که بیایم دیزاین یک قسمتی از کد رو به خاطر چند روز از برنامه جلو افتادن بد پیش ببریم، بیشتر ساختن یک بدهی بی‌ملاحظه است تا محتاطانه. یا این یک بدهی تولید کنیم و برنامه‌ای بهبودش در آینده نداشته باشیم بی ملاحظه است.

Experimentation at Spotify: Three Lessons for Maximizing Impact in Innovation

Thu, 02 Nov 2023 08:56:32 +0000

در محصول‌های بالغ، اکسپریمنت کردن روش خوبی برای تغییر و بهبوده؛ ولی خیلی مهمه که بدونیم به کمک یک اکسپریمنت خاص به چه نتیجه‌ای می‌خوایم برسیم، چه یوزرهایی رو درگیر می‌کنیم و چه نیازهایی برای این
اکسپریمنت داریم.

به طور دقیق‌تر، وقتی می‌خوایم یک تغییری رو آزمایش کنیم، خوبه که قبلش برای این دو سوال جواب داشته باشیم:

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

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

You Cannot Have Exactly-Once Delivery

Mon, 30 Oct 2023 22:27:41 +0000

نویسنده می‌گه که توی دنیای سیستم‌های توزیع‌شده، این که تضمین کنیم یک پیام دقیقاً یک بار به دست گیرنده برسه افسانه‌ای بیش نیست. چون از طرفی برای این که مطمئن باشیم پیام به دست گیرنده رسیده، باید acknowledge بگیریم. حالا اگر ack نگیریم احتمالاً باید فرض کنیم که پیام نرسیده و پس میایم retry می‌کنیم. از طرف دیگه ممکنه واقعا رسیده باشه و ack به دست ما نرسیده باشه. در این حالت با retry کردن پیام چند بار به دست گیرنده می‌رسه.