Tech Stuff

اگه یه مهارت باشه که لازمه به خودمون اضافه کنیم تا ریسک شغلی مون کمتر بشه مهارت بررسی و investigate کردن proactive محصول برای بهبودشه. یعنی صبر نکنیم تا یکی بهمون بگه چی بسازیم و خودمون دنبال مشکل ها و فرصت های بهبود محصول بگردیم. معمولا ما که سابقه کاری مون بیشتر مهندسی نرم افزار و برنامه نویسیه این یه زمین بازی کاملا جدیده و تجربه مون توش کمه. برای اینکه یاد بگیریم چطور این کارو بکنیم خوندن این مطالب میتونه مفید باشه 1. The Product-Minded Software Engineer - Gergely Orosz https://blog.pragmaticengineer.com/the-product-minded-engineer/ 2. Product Discovery - Marty Cagan https://www.svpg.com/product-discovery/ 3. Continuous Discovery Habits - Teresa Torres https://www.producttalk.org/continuous-discovery-habits/ @gocasts

توی backtracking جواب رو مرحله به مرحله می‌سازیم. الگوریتم هر وقت تشخیص بده که اون جواب جزئی نمی‌تونه منجر به یه جواب معتبر بشه، ازش backtrack می‌کنه. باهاش معمولا مسائل ترکیبیاتی مثل جایگشت‌ها (permutation) و ترکیب‌ها و پازل‌هایی مثل سودوکو رو حل می‌کنیم. مسئله Letter Combinations of a Phone Number لیتکد رو هم می‌تونین برای تمرین backtracking حل کنین. #algorithm @techstuff100

مفهومی وجود داره به اسم Chaos Engineering یا مهندسی آشوب. توش سعی می‌کنیم خرابی‌هایی رو که ممکنه توی دنیای واقعی اتفاق بیفتن، به‌صورت کنترل‌شده توی سیستم شبیه‌سازی کنیم. مثلا یکی از سرویس‌ها رو از دسترس خارج کنیم یا تاخیر شبکه رو بالا ببریم و ببینیم بقیه سیستم چه واکنشی نشون میده. هدف اینه که قبل از اینکه چنین اتفاق‌هایی واقعا بیفتن، بفهمیم کجای سیستم مشکل داره و چطور می‌تونیم در برابر خرابی‌ها مقاوم‌ترش کنیم. اینجا در موردش بیشتر بخونین. #system_design @techstuff100

طراحی یک Unique ID Generator در سیستم‌های توزیع‌شده این پست ۴ روش برای طراحی چنین سیستمی رو بررسی می‌کنه: - multi-master replication - UUID - ticket server - Twitter snowflake #system_design #system_design_interview_volume_1 @techstuff100

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

توی بحث rate limiting دو تا رویکرد داریم. hard rate limiting و soft rate limiting. توی hard limit وقتی تعداد درخواست‌ها از حد مجاز رد بشه، درخواست‌های اضافه رد میشن و معمولا 429 (Too Many Requests) می‌گیریم یا حتی ممکنه با هدر Retry-After به کلاینت بگیم چه زمانی دوباره درخواست بفرسته. این روش مثلا برای محدود کردن ترافیک کاربران رایگان یا محافظت از اندپوینت‌های پرهزینه جوابه. توی soft limit حتی بعد از رد شدن از سقف تعیین شده درخواست‌ها همچنان پردازش میشن. ولی در عوض می‌تونیم این رد شدن از محدودیت رو لاگ کنیم، هشدار بدیم یا اطلاعات مربوط به سهمیه مصرف‌شده رو توی response headerها برگردونیم. این روش بیشتر برای پلن‌های پولی و مشتری‌های سازمانی مناسبه که قطع شدن ناگهانی سرویس براشون مشکل‌سازه. البته که اگه همین مصرف اضافی هم درست کنترل نشه می‌تونه هزینه یا فشار زیادی به سیستم وارد کنه. #system_design @techstuff100

رویداد آشنایی با skill به همراه ساخت یک Skill شخصی در زمان کد نویسی با Ai مفاهیمی مثل Skill و تاثیرش در خروجی چی هستش؟ ساختار skill ها به چه صورته؟ چطور میشه یک skill طراحی کرد؟ و از دسته سوالاتی که در زمان انتخاب و استفاده ممکنه براتون پیش بیاد رو توی این رویداد بررسی کردیم. https://thealibigdeli.ir/r/hodrJn/ @thealibigdeli_channel #event

قبلا بخش زیادی از کار برنامه‌نویسی صرفا این بود که بتونیم چیزی رو بسازیم و به مرحله اجرا برسونیم. الان با کمک AI ساختن نرم‌افزار راحتتر شده و تقریبا هرکسی می‌تونه یه خروجی قابل‌قبول تولید کنه. برای همین چیزی که اهمیت بیشتری پیدا کرده taste یا همون قدرت تشخیص کیفیت و تصمیم‌گیریه؛ اینکه بتونیم بهترین راه‌حل رو انتخاب کنیم و به هر چیزی که صرفا کار کنه راضی نشیم. نویسنده میگه این مهارت از اشتباه کردن و یاد گرفتن از شکست‌ها بدست میاد. مشکل اینه که AI با حذف سختی‌های مسیر ممکنه فرصت یادگیری از همین اشتباهات رو هم ازمون بگیره. [مقاله] #recent_reads @techstuff100

چیزهایی که نباید در مصاحبه فنی بگیم در طول مصاحبه فرصت زیادی برای صحبت داریم؛ چه زمانی که داریم یه سوال مستقیم رو جواب میدیم یا زمانی که ازمون میخوان که درباره خودمون صحبت کنیم یا وقتی که میگن هر سوالی که داریم بپرسیم. توی چنین مواقعی قطعا باید خودمون باشیم ولی بعضی وقتا زیادی ریلکس بودن مشکل‌سازه. مثلا همه مصاحبه‌کننده‌ها شاید حس طنز ما رو نداشته باشن. برای اینکه تصویر خوبی از خودمون بسازیم، یسری چیزا رو بهتره نگیم: ۱. اینجا دقیقا چه کاری انجام میدید؟ نشون میده درباره شرکت، خوب تحقیق نکردیم. مثلا بهتره بگیم «اینجا چطور با نود کار می‌کنید؟». ۲. نمیدونم. تاحالا چنین کاری انجام ندادم. نشون میده که وقتی با مشکلات جدید مواجه میشیم، بلاک میشیم و نمی‌تونیم حلشون کنیم. بهتره بگیم «نمیدونم ولی امتحانش می‌کنم تا ...». ۳. از اون محل متنفر بودم. وقتی میپرسن که چرا از کار قبلیمون اومدیم بیرون، بهتره از اونجا (حداقل بطور رسمی) متنفر نباشیم؛ چون ممکنه باعث نشون دادن بدترین وجه خودمون بشه. بهتره روی چیزای مثبت و چیزایی که از اونجا یاد گرفتیم تمرکز کنیم. ۴. هیچ‌کس دیگه از اون استفاده نمی‌کنه. از عبارات قطعی استفاده نکنیم. چطور می‌تونیم با قاطعیت بگیم فلان چیز توی صنعت به این بزرگی دیگه استفاده نمیشه؟ اگه بگیم «تا جایی که من میدونم ...» بهتره. ۵. توی رزومه‌م گذاشتمش. توی مصاحبه ممکنه درباره چیزی که چیزایی که توی رزومه‌مون نوشتیم بپرسن. نگیم که توی رزومه‌م هستش. مصاحبه‌کننده تنبل نیست. ۶. نه، هیچ سوالی ندارم. مصاحبه فقط برای این نیست که اونا ما رو بشناسن. ما هم باید بشناسیمشون. پس سوالات مناسب داشته باشیم. ۷. من یه توسعه‌دهنده Reactم. با این جمله داریم خودمون رو محدود به React می‌کنیم. ما توسعه‌دهنده هستیم و اصول برنامه‌نویسی رو بلدیم. تکنولوژی‌ها میان و میرن. این نشون میده ما انعطاف‌پذیریم. ۸. لینوکس؟ ازش متنفرم. عاشق ویندوزم. متنفر بودن از تکنولوژی توی مصاحبه فنی یه چراغ قرمزه. ممکنه با یه چیزی حال نکنیم. ولی ابزار، ابزاره و باید با اونی که برای شرایط فعلیمون مناسبه پیش بریم. #Skills_of_a_Successful_Software_Engineer @techstuff100

با alias می‌تونیم توی شل برای یه دستور اسم کوتاه‌تری تعریف کنیم. مثلا بجای هربار بجای این دستور طولانی:

git log --oneline --graph --decorate

می‌تونیم یکبار این دستور رو اجرا کنیم:

alias gl='git log --oneline --graph --decorate'

از این به بعد با اجرای gl دستور کامل اجرا میشه. البته alias‍ بصورت پیش‌فرض فقط توی همون سشن ترمینال در دسترسه و با بستن ترمینال از بین میره. برای دائمی کردنش می‌تونیم به .bashrc اضافه‌ش کنیم:

echo "alias gl='git log --oneline --graph --decorate'" >> ~/.bashrc

@techstuff100

فاصله Levenshtein حداقل تعداد عملیات‌های ممکن (insertion، deletion و substitution) برای تبدیل یه رشته به یه رشته دیگه رو اندازه‌گیری می‌کنه. از کاربردهاش هم میشه به spell-checking و autocorrect و همینطور پیدا کردن اسم‌ها یا عبارت‌های مشابه بخصوص توی سرچ اشاره کرد. این مثال رو در نظر بگیرید. فاصله بین kitten و sitting سه هستش: kitten -> sitten -> sittin -> sitting برای محاسبه‌ش از dynamic programming استفاده می‌کنیم. grid پرشده مثال این شکلی میشه (1). مقدار هر سلول طبق فرمول (2) بدست اومده و عدد داخلش نشون میده حداقل فاصله ویرایشی بین دو prefix متناظر با اون سلول چقدره. مثلا سلول (3,2) مقدار 2 داره؛ این یعنی فاصله بین si و kit دو هستش. مقدار سلول پایین-راست هم جواب نهایی‌مونه. برای تمرینش می‌تونین مسئله لیتکد 72. Edit Distance رو حل کنین. #algorithm @techstuff100

خروجی کد بالا (1) چیه؟ شاید اینطور فکر کنیم که وقتی به return "try" می‌رسیم، اجرای تابع متوقف میشه و خروجی کد "try" میشه؛ اما "finally" چاپ میشه. برای درک بهتر این موضوع لازمه با Completion Record آشنا بشیم. ا Completion Record به آبجکتی گفته میشه که نتیجه اجرای یه دستور یا عبارت رو مشخص می‌کنه. js با اجرای هر statement یه Completion Record ایجاد می‌کنه و ۳ تا فیلد داره: یک. type برای نوع نتیجه که یکی از مقادیر normal (اجرای عادی)، break، continue، return و throw می‌تونه باشه. دو. value برای مقدار تولید شده. سه. target که مقصد رو برای break و continue مشخص می‌کنه. توی مثال وقتی return "try" اجرا میشه، یه Completion Record با مشخصات (2) ایجاد میشه. اما قبل از اینکه تابع واقعا return کنه، بلاک finally اجرا میشه. داخل finally هم یه return داریم که Completion Record (3) رو تولید می‌کنه و نتیجه قبلی جایگزین میشه. پس در نهایت مقدار "finally" برگردونده میشه. اگه finally به‌صورت normal تموم میشد و Completion جدیدی مثل return یا throw تولید نمی‌کرد، نتیجه قبلی حفظ میشد. #javascript @techstuff100

قانون پارکینسون میگه کار اونقدر کش پیدا می‌کنه تا زمانی که برای تکمیلش داریم رو پر کنه. پروژه‌هایی که ددلاینی ندارن، بیشتر از اونچه که باید زمان می‌گیرن و ست کردن ددلاین‌های چالشی (منظور ددلاین غیرممکن نیست) باعث میشه نتایج بهتری بگیریم. اینجا مفهومی به اسم Iron Triangle میاد وسط که سه تا محدودیت کلیدی یه پروژه رو تعریف می‌کنه: اسکوپ، منابع و زمان. با تغییر یکی، دو تای دیگه تغییر می‌کنن. [مقاله] #recent_reads @techstuff100

با بزرگ شدن LF باید slotهای بیشتری به hash tableمون اضافه کنیم که بهش میگن resizing. منطقیه که سایز آرایه رو دو برابر کنیم. بعدش تمام آیتم‌های موجود رو با hash function دوباره توی hash table جدید وارد می‌کنیم. هرچی LF کمتر، تعداد collisionها هم کمتر. قانون کلیش هم اینه که وقتی LF بزرگتر از 0.7 شد resize کنیم. resizing هم هزینه‌بره؛ اما اغلب اوقات لازم نمیشه که resize کنیم و بطور متوسط resizing هم پیچیدگی O(1) داره. یه hash function خوب هم مقادیر رو بطور مساوی داخل آرایه توزیع می‌کنه. (2/2) #Grokking_Algorithms #algorithm @techstuff100

پرفورمنس hash table پرفورمنس hash tableها بطور متوسط (average case) پیچیدگی زمانی O(1) داره. هم توی سرچ، هم insert و هم حذف. اما توی worst case به O(n) می‌رسه که اصلا چیز خوبی نیست. یعنی توی بدترین حالت مثل آرایه‌ست توی insert و delete و مثل linked list توی سرچ. برای اینکه به worst case نخوریم باید از collisionها جلوگیری کنیم و برای این کار به load factor (LF) و hash function خوب نیاز داریم. برای ذخیره آیتم‌های hash table از آرایه استفاده می‌کنیم. LF اینطور محاسبه میشه: تعداد آیتم‌های ذخیره شده در hash table تقسیم بر تعداد کل slotها. برای مثال اگه آرایه‌مون ۵ تا slot داشته باشه و ۲ تا آیتم ذخیره کرده باشه، LFمون میشه 0.4. (1/2) #Grokking_Algorithms #algorithm @techstuff100

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

چطور به عنوان یه مهندس قابل‌اطمینان، اعتبار بسازیم؟ برای اینکه از دید مدیر یا سهام‌دارمون قابل‌اطمینان بنظر بیایم، باید سعی کنیم از دید اونها به مسائل نگاه کنیم و برای این هدف یسری کارها رو می‌تونیم انجام بدیم؛ مثل اعتراف به اشتباهات، کنسل کردن جلسات بیهوده، نه گفتن در غالب اوقات، مدیر رو در جریان تغییرات گذاشتن و ... [لینک مقاله] #recent_reads @techstuff100

۱۲ ماه از خدمتم گذشت... یسری روزاش رو واقعا خسته بودم و حوصله خودم رو هم نداشتم؛ ولی سعی کردم که حتی توی چنین روزایی بازم یادگیری رو ادامه بدم. شده در حدی که مثلا ۵ دقیقه صرفا کتاب رو باز کنم و همینجوری به نوشته‌هاش نگاه کنم. در نهایت بقول یکی از کادری‌ها هر موقع خیلی ناراحت بودین به اون حلزونی فکر کنین که داشته بی‌خبر از همه جا از جلوی آبدارخونه رد می‌شده و فلانی با ۱۴۰ کیلو وزن لگدش می‌کنه. توی این ۱ سال دنبال کردم: کتاب‌ها: - Leaders Eat Last - A Philosophy of Software Design - System Design Interview Volume 1 - System Design Interview Volume 2 - Skills of a Successful Software Engineer - Grokking Algorithms (در حال مطالعه) کتاب‌های صوتی: - The Subtle Art of Not Giving a F*ck - The Old Man and the Sea - Rich Dad Poor Dad - The Hacker Mindset پادکست‌ها: - طبقه ۱۶ - کار نکن - رختکن بازنده‌ها - رادیو‌ جادی - رادیو راه - هک و گپ - امیفر - خداحافظ آفریقا - بنفش - عصر حجر - جافکری - آسوی روناکی - دورادور - کوشیار عظیمیان - رخ - اکسپت - فیوز - موموتاک - بی‌پلاس - کوزی کرنر - BigDeal #سربازی @techstuff100

هدر Referer یه سوالی که ممکنه باهاش مواجه شیم اینه که بازدیدکننده‌ها از کجا دارن میان به وبسایتمون. مثلا از گوگل ما رو پیدا کردن یا لینکدین. با هدر Referer می‌تونیم جواب این سوال رو بدیم. این هدر آدرس URLی رو میده که کاربر از اونجا به سایت مقصد رسیده. مثلا توی گوگل وقتی یچیزی رو سرچ می‌کنیم و روی یه لینک کلیک می‌کنیم، مقدار این هدر مثل عکس میشه. ازش می‌تونیم برای analytics و logging استفاده کنیم. اما خیلی هم نمیشه بهش اعتماد کرد؛ چون میشه برای مثال با curl تغییرش داد. یه نکته امنیتی هم داره. توی صفحات فراموشی رمز عبور، URL صفحه معمولا چنین چیزیه: jalali[.]com/forgot-password?token=ABC حالا اگه توی این صفحه، لینک به صفحات اجتماعی مثل اینستاگرام و لینکدین داشته باشیم و کاربر روش کلیک کنه، به مثلا اینستاگرام هدایت میشیم درحالی که Referer چنین مقداری گرفته: jalali[.]com/forgot-password?token=ABC و این یعنی که توکن کاربر لو رفته. #cyber_security @techstuff100

متود reduceRight در جاوااسکریپت متود reduceRight شبیه به reduce عمل می‌کنه؛ با این تفاوت که reduceRight تابع کال بک reducer رو از راست به چپ (ایندکس نزولی) اعمال می‌کنه و مقدار نهایی رو بر می‌گردونه. پارامتر‌ها و مقدار بازگشتیش دقیقا مثل reduceه. مثال رو ببینید. #javascript @techstuff100