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

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

خرافه‌ی اعجاز CV - بخش دوم

چطور می‌شه حد معقول رزومه‌نویسی رو درآورد؟ خیلی ساده‌ست. خیلی ساده‌تر از این که هی دنبال این و اون بیفتید که روی CV شما کامنت بدن. از کسی که تونسته با رزومه‌ش پوزیشنی بگیره یا آدم موجهی که قبولش دارید، نمونه بگیرید. البته اگر می‌شناسیدش و اون فرد مایله به این کار که احتمالاً کلی آدم هستند که این کار رو حتی بدون اینکه شما ازشون بخواید انجام می‌دن؛ چون رزومه‌هاشون رو توی وب‌سایت یا لینکدینشون گذاشتن. رزومه‌شون رو بذارید زیر دستتون و کپی بزنید! دبیرستان، معلم ریاضیمون جواب مسئله رو که روی تخته می‌نوشت، می‌نشست رو صندلیش و می‌گفت «شما که نمی‌فهمید، نقاشی بکشید!» :)))) ما هم از روی CV بقیه نقاشی بکشیم آقا، چه اشکالی داره؟ :)

وضعیت جوری شده که بیزینسی راه افتاده واسه این که از این خرافه‌ی ملت فرصتی بسازند برای فرو کردن حق‌اشتراک‌های واقعاً گرون تو پاچه‌ی ملت و پول کلفتی به جیب بزنن. کارجوی از همه‌جا مونده هم میاد و پول حروم این‌ها می‌کنه که چی؟ که نمره‌ی CV‌ش از ۴۰ بشه ۱۰۰، چون فکر می‌کنه الان اگه این ۱۰۰ بشه پس دیگه سیل مصاحبه‌ها به‌راه خواهد شد.

فکر می‌کنم واضح باشه منظورم از تمام این حرف‌ها، ولی اینجا جداگانه می‌گم. من نمی‌گم که رزومه‌ی بد ارائه بدین و این با کسی که رزومه‌ی درست و حسابی تحویل داده و براش وقت گذاشته فرقی نداره. نه! حرفم اینه که شما باید یک رزومه‌ی متعارف بسازید و ازش چیزی بیش از یک برگه که داره می‌گه شما کجاها چی‌کار کردین، انتظار نداشته باشید. برای اینکه شانسمون رو بیشتر کنیم، لازمه که کوله‌بارمون رو سنگین‌تر کنیم و باسوادتر بشیم. کانکشن‌هامون رو بیشتر کنیم و با آدم‌های بیشتری دوست باشیم، خودمون رو با عملکردمون نشون بدیم و امید داشته باشیم اون روزی که HR داره CVها رو چک می‌کنه، روز شانسمون باشه.حقیت تلخ اینه که ما برای خیلی چیزها نیاز به خیلی شانس داریم.

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

یه غری بزنم سر صبحی.

یادم میاد که اولین “مصاحبه‌ای” که رفتم، ازم پرسید که ترجیح میدی از جنریک‌ها استفاده کنی یا APIViewها یا ViewSetها برای پیاده کردن ویوها تو جنگو؟ خب من اون موقع به معنای واقعی کلمه هیچی هم بارم نبود و نمی‌دونستم واقعاً چی بگم. چون نمی‌دونستم اصلاً این چیزهایی که می‌گه چیه :)) یه APIView بلد بودم و بس. دیدم امن‌ترین جواب اینه که بگم: «هرکدوم به جای خودش خوبه.» اینو گفتم و اون‌قدری هم امن بود که کارو در بیاره.

ولی حالا بعد از این مدت، نسبت به یک چیز اطمینان دارم: استفاده از ViewSet واقعاً مثل سرطان می‌مونه. یک توده‌ی بزرگ کثافت که هی باید همه‌چیشو override کنی. هی این کلاس رو چاق و چاق‌تر می‌کنی با اضافه کردن انواع و اقسام actionها.

نمی‌فهمم این ترس از کمی بیشتر نوشتن رو! البته نه که درکش نکنم، ولی واقعاً کار پسندیده‌ای نیست دوستان! خیلی وقت‌ها میشه که شما از ViewSet استفاده می‌کنی، ولی این‌قدر متدها رو override می‌کنی که عملاً اگر همون ویو رو با جنریک پیاده می‌کردی، هم خروجی مرتب‌تر و انسانی‌تری داشتی، هم چه‌بسا کمتر کد می‌نوشتی.

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

MPTCP یا Multipath TCP
سال ۲۰۰۹ بود که اولین بار این پروتکل معرفی شد و در سال ۲۰۱۳، اولین RFC برای نسخه‌ی آزمایشی اون منتشر شد. در نهایت حدوداً ۴ سال پیش، RFC نسخه‌ی اول و استاندارد اون با شماره‌ی RFC 8684 منتشر شد که به تفصیل به شرح پروتکل پرداخته. به رسم همیشه، چون برای خودم جذاب بود خوندنش، اینجا میخوام که با استناد به وب‌سایت خود MPTCP یک شرح خیلی مختصر از این پروتکل و کاربردش بدم.

پروتکل Multipath TCP یا به اختصار MPTCP یک افزونه‌س برای پروتکل TCP که همه‌ی ما احتمالا اگر تا حدی راجع‌بهش توی درس شبکه نخونده‌ باشیم، قطعاً به گوشمون آشناست. این پروتکل این امکان رو به دستگاه میده که بتونه با یک logical کانکشن MPTCP از چند interface به صورت‌ یک‌جا برای انتقال پکت‌ها استفاده کنه. به عبارت بهتر، MPTCP پهنای‌باند چند اینترفیس رو باهم تجمیع کنه یا از بین‌ اون ها بهترین (وقتی راجع‌به بهتر بودن صحبت میکنیم، منظور درنظر گرفتن شاخص‌های مختلفه. از latencyپایین گرفته تا losses و الخ) مسیر رو برای انتقال پکت‌ها انتخاب کنه.

سناریویی رو در نظر بگیرید که روی موبایلتون، بخوایید به اینترنت وصل بشید و کار‌های متداولتون رو انجام بدین. اگر فرض کنیم که برای برنامه‌ای وجود داره که برای انتقال پکت‌هاش از پروتکل TCP استفاده میکنه علی‌رغم این که گوشی شما هم به دیتا وصله و از شبکه‌ی سلولی میتونه استفاده کنه، به WiFi هم متصله. ولی خب در نهایت با ایجاد کانکشن معمول TCP، فقط یکی از این interfaceها برای انتقال پکت‌ها استفاده میشه. این درحالیه که،در صورتی که هم سیستم‌عامل گوشی شما هم سرور اون اپلکیشن (فرض میکنیم که چیزی بین سرور و کلاینت‌ ما نیست) از MPTCP پشتیبانی کنند، این امکان برای نرم‌افزار شما فراهم میشه که بتونه با ایجاد کانکشن MPTCP به طور همزمان از شبکه‌ی سلولی و وای‌فای استفاده کنه.

پس به طور خلاصه، از کاربرد‌های MPTCP، میشه به این موارد اشاره کرد:

۱- این امکان وجود داره که بین‌ اینترفیس‌های مختلف سوئیچ کرد بدون این که ارتباط قطع بشه (این دقیقا علت اصلی استفاده از MPTCP در دستگاه‌های اپله که از iOS نسخه ۷ و از اواخر سال ۲۰۱۳ داره از این پروتکل استفاده میکنه).

۲- بهترین شبکه با درنظر گرفتن شاخص‌های مختلف برای ارتباط انتخاب بشه.

۳- ادغام پهنای‌ باند اینترفیس‌های دستگاه و افزایش throughput.

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

از چالش‌های اساسی مطرح در طراحی MPTCP طراحانش این بود که این پروتکل رو بتونن backward compatible طراحی کنند. یعنی درصورتی که امکان استفاده از MPTCP توی سرور یا هر middleboxی که در بین مسیر ارتباطی کلاینت و سرور بودند وجود نداشت، باید این امکان در پروتکل تعریف میشد که به TCP برگرده یا به اصطلاح، downgrade بشه. تا به این صورت بتونند شانس استفاده و deployment این پروتکل رو بیشتر کنن.

نکته‌ی بعدی، مفاهیم path و subflow هستند. این دو، در ترمینولوژی MPTCP به این شکل تعریف میشند:

Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address⁠/port pairs.

Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similarly to a regular TCP connection.

و البته برای روشن‌تر شدن ماجرا نیازه که تعریفی داشته باشیم از MPTCP Connection:

(MPTCP) Connection: A set of one or more subflows, over which an application can communicate between two hosts. There is a one‑to‑one mapping between a connection and an application socket.

تعریف مسیر یا path فکر میکنم واضح باشه. توی سناریویی که بالاتر تعریف کردم، این که از شبکه‌ی سلولی استفاده بشه یا وای‌فایل، هر کدوم از این ها یک مسیر هستند برای انتقال پکت‌ها. اما subflow درواقع یک شکلی از انتقال دیتاست که از مسیرها برای انتقال اون‌ها استفاده میکنه. درواقع با پخش کردن دیتا و بخش-بخش کردن اون در subflowهای متعدد، میشه هرکدوم از subflowها رو از طریق مسیر‌های تعریف شده به شکل همزمان انتقال داد.

www.rfc-editor.org

RFC 8684: TCP Extensions for Multipath Operation with Multiple Addresses

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve…