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

تا الان بیشتر تمرکز من روی امنیت در فضای ترکیبی بین امنیت و دوآپس بوده اما تو چند وقت گذشته به خاطر اینکه شروع به تحصیل در مقطع ارشد رایانش امن کردم خیلی بیشتر از گذشته با فضای ریسرچ امنیت درگیر شدم و احتمالا در ادامه بیشتر درباره امنیت صحبت کنم. پیش از اینکه به صحبت امشبم بپردازم باید بابت فعالیت کمم در اینجا عذرخواهی کنم و نبودم رو به گردن کار و دانشگاه که عمده وقتم رو صرف خودشون می‌کنن و انرژی زیادی برای نوشتن برام باقی نمی‌ذارن بندازم. چند روزی بود که قصد داشتم پست بعدیم رو درباره اینکه به نظرم جذابیت امنیت در اینه که به قول خارجیا یک Negative Goalهستش بنویسم اما امروز اتفاقی چشمم به چیزی خورد که نظرم رو عوض کرد و نوشتن درباره جذابیت امنیت رو به تعویق انداخت.
یکی از مشکلات دنیای واقعی پیچیده بودنشه،‌ فهم تمام متغیرهای درون دنیای واقعی و پاسخ دادن به تغییرهاشون تقریبا در هر زمان غیر ممکنه و این باعث می‌شه که به مدل‌ها رو بیاریم. مدل‌ها معمولا بخشی از دنیای واقعی که بیشتر از بقیه بخش‌ها با وضعیت ما مرتبط هستند رو در بر می‌گیرن و بقیه قسمت‌ها رو حذف می‌کنن. یک آماردان به اسم جرج باکس درباره این مسئله می‌گه "تمام مدل‌ها اشتباهند اما برخی از اون‌ها به درد می‌خورن".
با پذیرفتن اینکه برای پیاده‌سازی یک سیستم باید دنیا رو به شکلی مدل کنیم، نیاز پیدا می‌کنیم که بدون آسیب زدن به هدف اصلی سیستممون دنیا رو به شکلی ساده مدل کنیم. یعنی باید جزئیات بی‌ربط رو حذف کرده و جزئیات مرتبط رو نگه داریم. اما علاوه بر جزئیات بی‌ربط چیز دیگری هم هست که قابل حذفه. امروز داشتم مقاله‌ای نسبتا قدیمی به اسم Implementing Pushback: Router-Based Defense Against DDoS Attacks رو مطالعه می‌کردم. ایده اصلی مقاله درباره تشخیص حملاتیه که با هدف قطع دسترسی کاربران به یک سرویس، حجم زیادی از ترافیک رو به سمت اون سرویس ارسال می‌کنن (به چنین حملاتی DoS یا Denial of Service می‌گن و دفعشون مدت‌هاست که یک چالش باز در دنیای امنیته). مقاله برای دفع چنین حملاتی پیشنهاد می‌ده که مسیریاب‌های درون شبکه با بدست آوردن یک امضای خاص از بسته‌هایی که برای حمله ارسال می‌شن (برای مثال آدرس مقصدشون) اون بسته‌ها رو تشخیص بدن و اون‌ها رو منتقل نکنن و علاوه بر این کار پیام‌هایی رو برای انجام همین کار به مسیریاب‌هایی بفرستن که این بسته‌ها رو به سمتشون ارسال کردن. اگر به این مسئله و پاسخ مقاله بهش نگاه کنیم میبینیم که فرض‌های مختلفی درش وجود داره که با هم یک مدل از حملات DoS رو می‌سازن. اما قسمت جالب توجه برای من قسمتی بود که در اون مقاله داشت درباره پیام‌هایی که از مسیریاب به همسایه‌هاش ارسال میشه توضیح می‌داد و می‌گفت که اگر یک مهاجم بتونه چنین پیام‌هایی رو جعل کنه و برای بقیه مسیریاب‌ها بفرسته نگرانی‌های بزرگ‌تری نسبت به یک حمله DoS داریم‌ (جزئیات امکان و چگونگی جعل چنین پیامی بیشتره اما در اینجا هدف چیز دیگریه و به همین خاطر به این مسئله نمی‌پردازم). چیزی که توجه من رو جلب کرد این فرض بود که اگر یک اتفاق بزرگ‌تر در حال رخ دادن باشه می‌تونیم یک مسئله کوچک‌تر رو در نظر نگیریم تا پاسخ ساده‌تری به اون اتفاق بزرگ‌تر بدیم؛ این روش ساده‌سازی مدل چیزی رو حذف می‌کنه که لزوما بی‌ربط نیست اما اهمیت کمتری داره و به همین خاطر به نظرم با بقیه اشکال ساده‌سازی مدل‌ها متفاوته. مدت‌ها بود که این رفتار رو در مدل‌سازی‌هایی که برای حل مسائل به‌کار می‌بردیم در نظر می‌گرفتم اما تا به حال به این شکل بهش نگاه نکرده بودم اما دیدن اون در توضیحات این مقاله باعث شد که بیشتر بهش فکر کنم و جرقه نوشتن این مطلب زده شد.

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

امشب یک متن کوتاه علوم کامپیوتری دارم که بیشتر در جهت آگاه‌سازیه تا توضیح مفصل (توضیحات و مقالات زیادی درباره این مسئله هست و اگر بخوام تکرارشون کنم ارزش خاصی نداره).
همزمانی و موازی بودن یکی نیستن! زمانی که می‌خواید کاری رو انجام بدید، احتمالا یکی از راه‌های سریع‌تر کردن اون کار تقسیمش به بخش‌های مختلف و همزمان انجام دادن اون بخش‌هاست. ایده‌ای نزدیک به این همزمانی وجود داره که خیلی از وقت‌ها با این مفهوم اشتباه گرفته می‌شه و اون‌هم موازی انجام دادن کارهاست. اگر بخوام از راب پایک نقل قول کنم: "همزمانی درباره سر و کله زدن با چیزهای زیاد در یک زمانه ولی موازی بودن درباره انجام چیزهای زیاد در یک زمان".
مثال ساده‌ای می‌زنم: وقتی که شما در حال انجام دو کار مختلف هستید و هر زمان که در یک کار به مشکلی برمی‌خورید سراغ کار دیگه می‌رید در حال انجام دو کار به صورت همزمان هستید. اما زمانی که شما و دوستتون هرکدوم مشغول به انجام کاری می‌شید، شما به صورت موازی در حال کار کردن هستید.
چیزی که احتمالا باعث اشتباه گرفته شدن این دو مفهوم می‌شه اینه که یکی از الگوهای همزمانی انجام موازی کارهای همزمانه اما باید به خوبی به این دقت کنید که روش‌های دیگری هم برای انجام چند کار به صورت همزمان وجود داره (به مثال چند خط گذشته توجه کنید).
چیز دیگری که خوبه در اینجا بهش اشاره کنم لزوم ارتباط بین فرایندهای همزمانه. معمولا زمانی که افراد برای اولین بار با این مفاهیم آشنا می‌شن تصور می‌کنن که فقط در صورتی که دو چیز به صورت موازی در حال اجرا باشن نیاز دارن که درباره کارهاشون با هم هماهنگ باشن (در اینجا تفاوتی در این راه هماهنگی قائل نمی‌شم و همه راه‌های مختلف مثل قفل‌ها و کانال‌های ارسال پیام و... رو در نظر دارم). اما هماهنگی فقط درباره فرایندهای موازی نیست و به صورت کلی‌تر اگر دو فرایند همزمان (برای مشخص شدن تفاوت همزمانی و موازی بودن در اینجا، ساختارهای Async و در مقابلش Threadهایی که بر روی چند هسته پردازنده اجرا می‌شن رو در نظر بگیرید) در جایی مشترک باشن باید به شکلی هماهنگ بشن (یعنی در حالت‌هایی ممکنه نیاز باشه دو تسک Async هم از میوتکس استفاده کنن).
در نهایت هم ارجاعتون می‌دم به صحبت‌های راب پایک، یکی از سازندگان زبان برنامه‌نویسی گو در این باره (برنامه درباره زبان گو هستش اما مفاهیمی که درش مطرح می‌شه در زبان‌های دیگه هم کاربرد داره):
Concurrency is not Parallelism by Rob Pike

یکی از چیزهایی که به نظر نمیاد اینطور باشه اما سخت یاد میگیریم اینه که معمولا هیچ سوالی جواب قطعی نداره. (البته بجز سوال "آیا PHP زبان برنامه‌نویسی خوبی است؟")
معمولا ریاضی جزو اولین چیزهاییه که با شنیدن کلمه مهندسی به ذهنمون میرسه و گاهی اوقات این ارتباط ذهنی که بین ریاضی و مهندسی برقرار شده باعث میشه که فکر کنیم تصمیمات مهندسی همواره از طریق یک ساختار مشخص و خاص گرفته میشن و هر سوالی درباره خوب یا بد بودن یک راه حل به یک جواب بله یا خیر دقیق ختم میشه. اما خیلی از وقت‌ها اینطور نگاه کردن به مسائل ما رو داخل یک چارچوب محدود حبس میکنه و باعث میشه که راه‌حل‌های نسبتا خوبی که لزوما در یک ساختار مشخص قرار نمیگیرن رو نادیده بگیریم.
اما دیدن مسائل از یک لنز سیال بیشتر از اینکه در حل مسائل مهندسی به ما کمک کنه در زندگی شخصی کمک کننده‌ست. محیط اطراف ما همواره در حال تغییره و تلاش برای قطعی و مشخص فرض کردن اون فقط فریب دادن خودمونه. پذیرش اینکه مسائل بیشتر از اینکه سیاه یا سفید باشن خاکستری هستن در نهایت به خود ما کمک میکنه که ساده‌تر اتفاقات رو درک کنیم و بتونیم خودمون رو با شرایط تطبیق بدیم.
در نهایت عدم قطعیت و بودن در شرایطی که نشه بر روش یک برچسب مشخص گذاشت برای ما خسته کننده‌ست و بعید میدونم که بشه کاملا از تمایل به قطعی بودن چیزها دست کشید. اما تحمل و بعد از اون همراه شدن با عدم قطعیت و دیدن دنیا بدون دسته بندی کردن هرچیز میتونه به بهتر زندگی کردن کمک کنه.

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

تجربه بهترین دوست و کمالگرایی بدترین دشمن یک مهندس نرم‌افزاره
در محل کار قبلیم بر روی نرم‌افزاری کار می‌کردم که چند سالی از شروع ساختش می‌گذشت، معمولا با گذشت زمان و بزرگ شدن نرم‌افزارها و پیچیده شدن کدبیس اون‌ها، نگهداری اون‌ها سخت‌تر شده و با رفتن افرادی که کد رو به خوبی می‌شناختن، و درباره معماری کلانش تصمیم گرفته بودن، تغییر دادن بخش‌هایی از کد احتمالا به کاری غیر ممکن یا در بهترین حالت ترسناک و "پروداکشن پایین بیار" تبدیل می‌شه. به چنین کدبیسی، یا حداقل قسمت‌هایی از اون که قدیمی هستن کد Legacy می‌گن.
در مقابل، در محل کار جدیدم بر روی نرم‌افزاری کار می‌کنم که مدت کمی از شروعش می‌گذره و در کار زیرساختش هنوز نیاز به تصمیمات بنیادی و طراحی معماری وجود داره.
در مدتی که بر روی اون نرم‌افزار Legacy کار می‌کردم به خاطر پیچیدگی و قدیمی بودن ساختار تغییرات سخت بودن و همیشه فکر می‌کردم که اگر یک تصمیمی در فلان زمان گرفته نشده بود الان می‌تونستیم بهمان کار که در کتابی گفته کار خوبیه رو انجام بدیم و دیگه مشکلی نخواهیم داشت. اما زمانی که با این کدبیس جدید مواجه شدم و در جایی قرار گرفتم که نیاز بود به همراه باقی اعضای تیم درباره یک تصمیم فکر کنیم، و مجبور شدیم در زمان‌هایی به‌روش‌ها (معادل فارسی Best practice که به نظرم دوست داشتنیه) رو کنار بذاریم و به دلایلی که معمولا در کتاب‌ها بهشون اشاره نمی‌شه یک کار کمتر بهینه اما مناسب‌تر رو انجام بدیم، متوجه شدم که کمالگرا بودن و همیشه به دنبال بهترین روش رفتن بدون توجه به ملاحظاتی مثل سرعت پاسخ به مسئله، خوب نیست و علاوه بر این، دیدن اون ملاحظات علاوه بر دانشی که از کتاب‌های تئوری بدست می‌یاریم نیاز به تجربه، کار با ساختارهای مختلف و حل چالش‌های متنوع داره.
در نهایت احتمالا بشه گفت وظیفه یک مهندس نرم‌افزار انتخاب بهترین روش‌های مهندسی در یک فضای آرمانی نیست بلکه یک مهندس نرم‌افزار باید به‌روش‌ها رو بشناسه و با توجه به پیش‌زمینه مسئله و منابعی که در اختیارشه یک پاسخ خوب، که حتی شاید در فضای آرمانی پاسخ بدی باشه، به مسئله بده.

این رو هم میخواستم بفرستم ولی فراموش کردم.???

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