Tech Stuff

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

همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه 👀 این داستان یکی از بچه‌ها توی هلند هست برام جالب بود:

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

اگه مهندس نرم‌افزار هستید سعی کنید از این نکته‌ها و فعالیت‌ها غافل نشین. اینطور که من بازار و تغییرات مشاغل رو می‌بینم، شغل مهندسی نرم‌افزار کم‌کم داره از حالت کلاسیک خودش که ۸۰٪ کدنویسی بود فاصله می‌گیره و فعالیت‌‌هایی فراتر از اون یعنی تعاملات انسانی توی اون داره پررنگ‌تر میشه یه مقاله هم جدیداً خوندم با عنوان «شغل‌های جدید مهندسی نرم‌افزار توی دوران هوش مصنوعی». یکی از این شغل‌ها که خیلی داره سر زبون‌ها میچرخه Forward Deployed Engineer هست که به مهندس نرم‌افزاری گفته میشه میره پیش مشتری‌ها، الگوهای پیدا و پنهان اون شرکت رو یاد بگیره (همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه) و از این تجربه یه محصول قابل استفاده برای همه مشتری‌های فعلی و بعدی بسازه

استراتژی‌های Retry در سیستم‌های توزیع‌شده وقتی یه درخواست fail میشه، معمولا می‌تونیم Retry کنیم. چند تا از استراتژی‌های رایج: یک. Immediate Retry: بلافاصله دوباره درخواست می‌فرستیم. ساده و سریعه؛ ولی اگه مشکل همچنان وجود داشته باشه، می‌تونه باعث درخواست‌های پشت‌سرهم و فشار بیشتر بشه. دو. Fixed Interval: بعد از هر خطا مدت زمان ثابتی صبر می‌کنیم؛ مثلا هر ۵ ثانیه یک‌بار. ساده‌ست؛ ولی ممکنه فاصله انتخاب‌شده بیش از حد کوتاه یا طولانی باشه. سه. Incremental Interval: فاصله Retryها کم کم بیشتر میشه؛ مثلا ۱، ۲، ۳، ۴ ثانیه. چهار. Exponential Backoff: فاصله بین Retryها به‌صورت نمایی افزایش پیدا می‌کنه؛ مثلا ۱، ۲، ۴، ۸ ثانیه. برای خطاهایی که احتمال میدیم بعد از مدتی برطرف بشن معمولا انتخاب مناسبیه. بهتره تعداد Retry یا حداکثر زمان انتظار هم محدود بشه. پنج. Jitter: یک مقدار تصادفی به زمان انتظار اضافه می‌کنیم تا چندین کلاینت هم‌زمان Retry نکنن. شش. Circuit Breaker: وقتی تعداد خطاها از حد مشخصی بیشتر بشه، موقتا Retry و درخواست‌های جدید رو متوقف می‌کنیم تا سرویس مقصد فرصت ریکاوری داشته باشه. هفت. Adaptive Retry: استراتژی Retry رو بر اساس شرایط فعلی سیستم، مثل Load، Failure Rate و Response Time تغییر میدیم. هشت. Cancel: اگر خطا دائمی باشه یا Retry کردن احتمال موفقیت نداشته باشه، به‌جای ادامه دادن، درخواست رو کنسل می‌کنیم. در عمل معمولا یک ترکیب از این روش‌ها استفاده میشه؛ مثلا Exponential Backoff + Jitter + محدودیت تعداد Retry. همچنین برای درخواست‌هایی مثل پرداخت باید Idempotency رو هم در نظر گرفت تا Retry باعث اجرای چندباره یه عملیات نشه. #system_design @techstuff100

چرا Big O یکسان به معنی سرعت یکسان نیست؟ فرض کنید ۲ تا تابع داریم که هر دو پیچیدگی زمانی O(n) دارن. این لزوما به این معنی نیست که هر دو در عمل یک سرعت اجرا دارن. مثال رو در نظر بگیرین. print_items و print_items2 هر دو یکبار روی لیست حلقه می‌زنن. اما print_items سریع‌تره؛ چون یک ثانیه مکث برای پرینت هر آیتم رو نداره. وقتی که میگیم پیچیدگی زمانی O(n) هست، منظورمون اینه که زمان اجرای اون با رشد n به صورت خطی رشد می‌کنه. در اصل داریم میگیم c * n که این c یه مقدار زمان ثابته که الگوریتم ما میگیره. مثلا برای print_items ممکنه 10ms و برای print_items2 همون 1s باشه. اگر دو الگوریتم پیچیدگی زمانی big O متفاوتی داشته باشن، معمولا مقدار c رو نادیده می‌گیریم. مثلا بین جستجوی باینری و جستجوی خطی، مقدار c تاثیری نداره؛ چون در نهایت جستجوی باینری سریع‌تره. یه نمونه از زمانی که مقدار ثابت c اهمیت پیدا می‌کنه، quick sort در برابر merge sort ه. quick sort مقدار ثابت c کوچک‌تری از merge sort داره. پس اگه جفتشون O(n log n) باشن، quick sort سریع‌تره. #Grokking_Algorithms #algorithm @techstuff100

چه کسانی مهندسان ارشد ۲۰۳۵ خواهند بود؟ بعد از تعدیل‌های بعد از کرونا، استخدام توی همه بخش‌ها کند شده؛ چون شرکتا منتظرن ببینن نتیجه بهره‌وری حاصل از AI و وضعیت اقتصادی چطور بوده. همین موضوع روی تازه‌کارها هم تاثیر گذاشته و زمان سختی برای فارغ‌التحصیلی از علوم کامپیوتر شده. این مقاله تاثیر AI روی مهندسای جونیور رو بررسی می‌کنه و در نهایت برای افراد توی سطحی که هستن (مهندس یا رهبر ارشد، مدیر و یا برنامه‌نویس تازه‌کار) پیشنهاداتی ارائه میده. #recent_reads @techstuff100

رویداد استفاده از Wireshark در مهندسی معکوس چطور می تونیم با بررسی ارتباط بین یک کلاینت و سرور رفتار مشابه رو شبیه سازی و مهندسی معکوس کنیم. این رفتار رو میشه با ضبط پکت های ارتباطی و باز نویسی و یا حتی ارسال مجدد باز طراحی کرد، که حتی برای موارد امنیتی هم در نظر گرفته میشه. https://thealibigdeli.ir/r/wq2eQ6/ @thealibigdeli_channel #event

طراحی سیستم: Consistent Hashing تکنیک Consistent Hashing کمک می‌کنه موقع اضافه یا حذف شدن سرورها، فقط بخش کوچکی از داده‌ها جابه‌جا بشن و از ایجاد حجم زیادی Cache Miss جلوگیری بشه. #system_design_interview_volume_1 #system_design @techstuff100

یه مسئله جالب برای تمرین dynamic programming، مثلث پاسکاله. توی این مثلث، هر عدد از جمع ۲ عددی که دقیقا بالای اون قرار دارن محاسبه میشه. لیتکد: https://leetcode.com/problems/pascals-triangle یه مسئله تکمیلی Pascal's Triangle II هم داره: https://leetcode.com/problems/pascals-triangle-ii/ #algorithm @techstuff100

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

Auditory Prompt Injection یه‌ چند روزی بود داشتم ویدئو های اینستا رو نگاه می کردم روی بعضی هاشون ۲ تا وویس صحبت بود انگار یکی پشت صحنه داشت یه چیزی می گفت ولی صدای جلویی مانع بود. همینطوری ازش گذشتم تا به این تیتر رسیدم توی یه جایی که امکان تزریق دستور توی یک وویس دیگه از طریق فرکانس پایینتر و ... وجود داره و میشه یسری موسیقی ها رو طوری دستکاری کرد که این موضوع توش قرار بگیره و بشه اطلاعات و یا سلسله ای از دستورات رو از طریقش انجام داد. حالا در کنار نوشته های مخفی توی تصویر و یا ویدئو و یا skills های آلوده و خیلی چیزای دیگه، به این فکر کنین دیگه چیا می تونن حامل یک عملیات مخرب بشن. 😐 دیگه به چی تقریبا میشه اعتماد کرد؟ @thealibigdeli_channel #ai

یچیزی وجود داره به اسم مغلطه‌‌ی هزینه هدررفته (Sunk Cost Fallacy). گاهی توی یک پروژه می‌دونیم ادامه دادن یک تصمیم دیگه منطقی نیست، ولی چون براش کلی وقت، انرژی یا هزینه گذاشتیم، باز هم ادامه‌ش میدیم. مثلا ممکنه چند هفته روی یک تکنولوژی کار کرده باشیم و وسط کار بفهمیم انتخاب خوبی نبوده، ولی فقط به خاطر زمانی که گذاشتیم، حاضر نباشیم عوضش کنیم. در تصمیم‌گیری بهتره هزینه‌هایی که تا الان انجام شدن رو کنار بذاریم و ببینیم از این لحظه به بعد، کدوم گزینه منطقی‌تره. چیزی که قبلا از دست رفته، با ادامه دادن لزوما برنمی‌گرده. @techstuff100

رویداد پیاده سازی و انواع Pagination در طراحی API بررسی انواع مدل های پیاده سازی pagination به همراه بررسی نقاط ضعف و قدرت در عملکرد هریک از این ساختار ها در صفحه بندی جداول و اطلاعات https://thealibigdeli.ir/r/TJRgHi/ @thealibigdeli_channel #event

هدر Cache-Control این هدر مشخص می‌کنه یه ریکوئست یا ریسپانس چطور و برای چه مدتی می‌تونه کش بشه. توی مثال اگر سرور این هدر رو برگردونه، یعنی ریسپانس می‌تونه توسط کش‌های عمومی ذخیره بشه و تا ۳۶۰۰ ثانیه از کش استفاده بشه و لازم نباشه هر بار از سرور گرفته بشه. توی ریسپانس، public یعنی ریسپانس می‌تونه توسط کش‌های عمومی مثل CDN ذخیره بشه، در حالی که private معمولا برای ریسپانس‌هایی استفاده میشه که مخصوص یک کاربر هستن و نباید توسط کش‌های عمومی ذخیره بشن. دایرکتیو no-store یعنی اصلا ریسپانس رو ذخیره نکن و همیشه مقدار جدید رو دانلود کن که برای اطلاعات حساس مناسبه. no-cache برخلاف اسمش نمیگه کش نکن؛ میگه قبل از استفاده مجدد از نسخه کش‌شده باید با سرور اعتبارسنجی بشه. استفاده از no-cache روی ریسپانس باعث میشه هر بار قبل از استفاده از نسخه کش‌شده با سرور revalidation انجام بشه. در نتیجه یا یه ریسپانس جدید دریافت میشه، یا اگر نسخه موجود معتبر باشه، سرور می‌تونه 304 Not Modified برگردونه. بنابراین no-cache هزینه داره، چون مرورگر رو مجبور می‌کنه برای هر بار استفاده یک درخواست اضافی به سرور بزنه. @techstuff100

این مقاله سوال‌های رفتاری که نویسنده توی مصاحبه شرکت‌هایی مثل آمازون، گوگل، کانوا و ... ازش پرسیدن رو بررسی کرده. سوال‌هایی مثل: - تا حالا با هم‌تیمیت به مشکل خوردی؟ - یه اشتباه مهمی که کردی چی بوده؟ - تا حالا شده با یه تغییر مخالف باشی؟ به نظرم خوندن این مقاله بخصوص برای کسی که داره برای مصاحبه آماده میشه خیلی مفیده. [لینک مقاله] @techstuff100

جلسه قراره یه هدف مشخص داشته باشه و وقتی این هدف فراموش بشه، جلسه خیلی راحت تبدیل میشه به اتلاف وقت. یکی از چیزهای ساده‌ای که خیلی روی کیفیت جلسه تاثیر داره اینه که چند دقیقه زودتر وارد جلسه بشیم، نه دقیقا سر ساعت. اینطوری جلسه از همون اول با «سلام، خوبی؟» و وصل شدن افراد مختلف چند دقیقه عقب نمیفته. بهتره وسط جلسه هم وارد بحث‌های متفرقه نشیم و قبل از جلسه برای چیزی که قراره مطرح کنیم آماده باشیم. مثلا سوال‌هامون رو از قبل بنویسیم یا اگر قراره چیزی رو دمو کنیم، قبلش مطمئن بشیم همه‌چیز درست کار می‌کنه. از طرف دیگه خوبه جلسه با مشخص بودن قدم بعدی تموم بشه. اگر کسی قراره کاری انجام بده، بهتره همون موقع مشخص بشه چه کاری و توسط چه کسی انجام میشه. بعد از جلسه هم یه خلاصه کوتاه از مباحث، تصمیم‌ها و Action Itemها برای همه ارسال بشه. این کار کمک می‌کنه برداشت همه از جلسه یکی باشه و اگر سوءتفاهمی وجود داشته همون موقع مشخص بشه. در نهایت رعایت همین چیزهای ساده نشون میده که برای وقت بقیه احترام قائلیم، منظم هستیم و جلسه رو صرفا برای جلسه برگزار نمی‌کنیم. #Skills_of_a_Successful_Software_Engineer @techstuff100

چطور تصمیم‌های فنی و معماری رو مدیریت کنیم؟ توی این ویدیو با RFC و ADR و نقش اون‌ها در بهبود ارتباط و هماهنگی بین تیم‌های فنی آشنا میشیم. با بررسی دو نمونه واقعی، روند پیشنهاد و بررسی یک تغییر در RFC و ثبت تصمیم‌های معماری در ADR رو می‌بینیم. همچنین تفاوت کاربرد RFC و ADR و اهمیت ثبت context تصمیم‌ها رو بررسی می‌کنیم. ویدئوی یوتوب: https://www.youtube.com/watch?v=0zLf2Nl4jv8&list=PLOpUynAWw-VY&index=1&pp=iAQBsAgC #software_engineering @techstuff100

کلون ریپازیتوری بدون تاریخچه کامل وقتی یه ریپازیتوری گیت تاریخچه خیلی طولانی داشته باشه، git clone ممکنه زمان و حجم زیادی مصرف کنه؛ در حالی که شاید فقط به آخرین نسخه کد نیاز داشته باشیم. اینجا می‌تونیم از --depth استفاده کنیم. توی مثال فقط آخرین کامیت رو دریافت می‌کنیم و به همین خاطر clone سریع‌تر و کم‌حجم‌تر میشه. این روش یه shallow clone ایجاد می‌کنه و به همین دلیل کل تاریخچه گیت رو نداریم. اگر بعدا به تاریخچه کامل نیاز داشتیم، می‌تونیم با git fetch --unshallow کل تاریخچه رو دریافت کنیم. #git @techstuff100

داشتم LeetCode 290 رو حل می‌کردم که راه حلم روی یه تست کیس خاص fail میشد. یه آبجکت تعریف کرده بودم:

const map = {};

و در ادامه چنین شرطی داشتم:

if (word in map) {
  // 
}

توی اون تست کیس خاص word مقدار "constructor" داشت. بنابراین شرط من میشد:

"constructor" in map // true

و شرط داشت true برمی‌گردوند؛ در حالی که من هیچ‌وقت "constructor" رو به map اضافه نکردم. دلیلش این بود که آبجکت‌هایی که با {} ساخته میشن، از Object.prototype ارث‌بری می‌کنن و constructor یکی از propertyهای اونجاست. عملگر in هم فقط پراپرتی‌های خود آبجکت رو بررسی نمی‌کنه و زنجیره prototype رو هم بررسی می‌کنه. برای اینکه فقط پراپرتی‌های خود آبجکت بررسی بشن، می‌تونیم از Object.hasOwn استفاده کنیم:

Object.hasOwn(map, word)

یا اگر یک map کاملا خالی می‌خوایم که prototype نداشته باشه:

const map = Object.create(null);

#javascript @techstuff100

کتاب Skills of a Successful Software Engineer رو تموم کردم. کتاب جالبی بود. چند تا پست دیگه ازش دارم که کم کم میذارمشون. بعد اون Grokking Algorithms رو شروع کردم. #Grokking_Algorithms @techstuff100

سوال مصاحبه: طراحی سیستم رزرو Airbnb توی این مقاله نویسنده تجربه مصاحبه طراحی سیستم برای سیستم رزرو شبیه Airbnb رو تعریف می‌کنه. سناریو این بود که دو کاربر هم‌زمان بخوان یک اقامتگاه رو برای تاریخ یکسان رزرو کنن. تمرکز مصاحبه روی تحلیل مسئله و تصمیم‌گیری‌ها بود؛ مثل این‌که کجا Strong Consistency و کجا Eventual Consistency نیاز داریم. مصاحبه بعد از حدود ۱۲ دقیقه متوقف شد، چون مصاحبه‌کننده به پاسخ مورد انتظارش رسیده بود. یکی از بخش‌های مهم طراحی، استفاده از Idempotency برای جلوگیری از رزروهای تکراری در اثر Retry درخواست‌ها و جلوگیری از Conflict در لایه داده برای Double Booking بود؛ مثلا با Constraintهای دیتابیس. سوال سخت‌تر این بود: اگر دو کاربر از دو Region مختلف هم‌زمان بخوان یک اقامتگاه رو رزرو کنن، چطور Conflict رو مدیریت می‌کنید؟ [لینک مقاله] #system_design @techstuff100