یچیزی وجود داره به اسم مغلطه‌‌ی هزینه هدررفته (Sunk Cost Fallacy).
گاهی توی یک پروژه می‌دونیم ادامه دادن یک تصمیم دیگه منطقی نیست، ولی چون براش کلی وقت، انرژی یا هزینه گذاشتیم، باز هم ادامه‌ش میدیم. مثلا ممکنه چند هفته روی یک تکنولوژی کار کرده باشیم و وسط کار بفهمیم انتخاب خوبی نبوده، ولی فقط به خاطر زمانی که گذاشتیم، حاضر نباشیم عوضش کنیم.
در تصمیم‌گیری بهتره هزینه‌هایی که تا الان انجام شدن رو کنار بذاریم و ببینیم از این لحظه به بعد، کدوم گزینه منطقی‌تره. چیزی که قبلا از دست رفته، با ادامه دادن لزوما برنمی‌گرده.
@techstuff100
Auditory Prompt Injection
یه چند روزی بود داشتم ویدئو های اینستا رو نگاه می کردم روی بعضی هاشون ۲ تا وویس صحبت بود انگار یکی پشت صحنه داشت یه چیزی می گفت ولی صدای جلویی مانع بود.
همینطوری ازش گذشتم تا به این تیتر رسیدم توی یه جایی که امکان تزریق دستور توی یک وویس دیگه از طریق فرکانس پایینتر و ... وجود داره و میشه یسری موسیقی ها رو طوری دستکاری کرد که این موضوع توش قرار بگیره و بشه اطلاعات و یا سلسله ای از دستورات رو از طریقش انجام داد.
حالا در کنار نوشته های مخفی توی تصویر و یا ویدئو و یا skills های آلوده و خیلی چیزای دیگه، به این فکر کنین دیگه چیا می تونن حامل یک عملیات مخرب بشن. 😐
دیگه به چی تقریبا میشه اعتماد کرد؟
@thealibigdeli_channel
#ai
بعضی وقت‌ها چیزی که به مدیرمون میگیم، بیشتر از خود جمله پیام منتقل می‌کنه. مثلا وقتی دیر می‌رسیم و شروع می‌کنیم به توضیح دادن که «دیشب مهمونی بودم»، شاید ناخواسته این برداشت ایجاد بشه که کار و تاثیرش روی تیم برامون خیلی مهم نبوده. یا وقتی باگ گزارش میشه و سریع میگیم «ما همیشه همینطوری انجامش می‌دادیم» یا «این باگ رندومه»، ممکنه نشون بده که قبل از بررسی کردن، داریم مشکل رو رد می‌کنیم. حتی جمله «تقصیر من نبود» هم وقتی یه مشکل برای تیم پیش اومده تصویر خوبی نمی‌سازه. لازم نیست مسئول همه‌چیز باشیم، ولی می‌تونیم برای پیدا کردن مشکل و حلش کمک کنیم.
همین موضوع درباره کارهای سخت یا خسته‌کننده هم هست. گفتن «این کار خیلی سخته» یا «حوصله‌م سر رفته، نمی‌دونم چیکار کنم» بیشتر از اینکه مشکلمون رو حل کنه، ممکنه نشون بده منتظریم یکی همیشه بهمون بگه قدم بعدی چیه. بهتره به‌جای این‌ها اگر کاری نداریم بگیم «کارم تموم شده، کار دیگه‌ای هست که بتونم بردارم؟» و اگر کاری سخته، قبول کنیم که بخشی از رشد کردن اینه که گاهی با چیزهایی روبه‌رو بشیم که بلد نیستیم.
#Skills_of_a_Successful_Software_Engineer
@techstuff100
طراحی سیستم: Consistent Hashing
تکنیک Consistent Hashing کمک می‌کنه موقع اضافه یا حذف شدن سرورها، فقط بخش کوچکی از داده‌ها جابه‌جا بشن و از ایجاد حجم زیادی Cache Miss جلوگیری بشه.
#system_design_interview_volume_1 #system_design
@techstuff100
رویداد استفاده از Wireshark در مهندسی معکوس
چطور می تونیم با بررسی ارتباط بین یک کلاینت و سرور رفتار مشابه رو شبیه سازی و مهندسی معکوس کنیم. این رفتار رو میشه با ضبط پکت های ارتباطی و باز نویسی و یا حتی ارسال مجدد باز طراحی کرد، که حتی برای موارد امنیتی هم در نظر گرفته میشه.
https://thealibigdeli.ir/r/wq2eQ6/@thealibigdeli_channel
#event
چه کسانی مهندسان ارشد ۲۰۳۵ خواهند بود؟
بعد از تعدیل‌های بعد از کرونا، استخدام توی همه بخش‌ها کند شده؛ چون شرکتا منتظرن ببینن نتیجه بهره‌وری حاصل از AI و وضعیت اقتصادی چطور بوده. همین موضوع روی تازه‌کارها هم تاثیر گذاشته و زمان سختی برای فارغ‌التحصیلی از علوم کامپیوتر شده.
این مقاله تاثیر AI روی مهندسای جونیور رو بررسی می‌کنه و در نهایت برای افراد توی سطحی که هستن (مهندس یا رهبر ارشد، مدیر و یا برنامه‌نویس تازه‌کار) پیشنهاداتی ارائه میده.
#recent_reads
@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
استراتژی‌های 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
همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه 👀
این داستان یکی از بچه‌ها توی هلند هست برام جالب بود:
مدتی هست که بخاطر هوش مصنوعی فشار کار فنی کمتر شده، سعی می‌کنم از فرصت پیش‌اومده استفاده کنم و یکم از نقش خودم بالاتر برم و کارهایی بکنم که در سال‌های قبل از هوش مصنوعی اصلاً به ذهنم هم خطور نمی‌کرد و کسی هم انتظار نداشت انجام بدم. مثلاً به تیم‌های دیگه مثل تیم فروش و بازاریابی سر می‌زنم و می‌ببینم محصولی که ساختیم از دیدگاه اونها یا مشتری‌ها چطوریه و آیا کم و کاستی داره یا نه
یکی از چیزهایی که جدیداً انجام دادم این بود که درخواست کردم دسترسی Search Console گوگل رو بهم بدن تا ببینم اپ توی سرچ گوگل وضعیتش چطوریه. و دیدم یه سری چیزها و آمارها بالا پایین هست 😄🙈 و گره‌های ریزی توی دشبرد وجود داره شاید از دید یک فرد غیر فنی پنهان بمونه. چیزهایی که وظیفه تیم فنی بود.
این کار پیش‌دستانه باعث شد دست به کار بشم و چندین فیکس انجام بدم. از جمله بهبود سئو و سرعت برنامه. نکات ریزی که شاید بدون دخالت من به من منتقل نمی‌شد. تجربه‌ای که از این اتفاق گرفتم این بود که بعضی وقت‌ها چیزهایی که به چشم یه فرد فنی میاد رو تیم‌ها و افراد دیگه ندارن
اگه مهندس نرم‌افزار هستید سعی کنید از این نکته‌ها و فعالیت‌ها غافل نشین. اینطور که من بازار و تغییرات مشاغل رو می‌بینم، شغل مهندسی نرم‌افزار کم‌کم داره از حالت کلاسیک خودش که ۸۰٪ کدنویسی بود فاصله میگیره و فعالیت‌‌هایی فراتر از اون یعنی تعاملات انسانی توی اون داره پررنگ‌تر میشه
یه مقاله هم جدیداً خوندم با عنوان «شغل‌های جدید مهندسی نرم‌افزار توی دوران هوش مصنوعی». یکی از این شغل‌ها که خیلی داره سر زبون‌ها میچرخه Forward Deployed Engineer هست که به مهندس نرم‌افزاری گفته میشه میره پیش مشتری‌ها، الگوهای پیدا و پنهان اون شرکت رو یاد بگیره (همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه) و از این تجربه یه محصول قابل استفاده برای همه مشتری‌های فعلی و بعدی بسازه
متود reduceRight در جاوااسکریپت
متود reduceRight شبیه به reduce عمل می‌کنه؛ با این تفاوت که reduceRight تابع کال بک reducer رو از راست به چپ (ایندکس نزولی) اعمال می‌کنه و مقدار نهایی رو بر می‌گردونه. پارامتر‌ها و مقدار بازگشتیش دقیقا مثل reduceه. مثال رو ببینید.
#javascript
@techstuff100
هدر Referer
یه سوالی که ممکنه باهاش مواجه شیم اینه که بازدیدکننده‌ها از کجا دارن میان به وبسایتمون. مثلا از گوگل ما رو پیدا کردن یا لینکدین. با هدر Referer می‌تونیم جواب این سوال رو بدیم.
این هدر آدرس URLی رو میده که کاربر از اونجا به سایت مقصد رسیده. مثلا توی گوگل وقتی یچیزی رو سرچ می‌کنیم و روی یه لینک کلیک می‌کنیم، مقدار این هدر مثل عکس میشه. ازش می‌تونیم برای analytics و logging استفاده کنیم. اما خیلی هم نمیشه بهش اعتماد کرد؛ چون میشه برای مثال با curl تغییرش داد.
یه نکته امنیتی هم داره. توی صفحات فراموشی رمز عبور، URL صفحه معمولا چنین چیزیه:
jalali[.]com/forgot-password?token=ABC
حالا اگه توی این صفحه، لینک به صفحات اجتماعی مثل اینستاگرام و لینکدین داشته باشیم و کاربر روش کلیک کنه، به مثلا اینستاگرام هدایت میشیم درحالی که Referer چنین مقداری گرفته:
jalali[.]com/forgot-password?token=ABC
و این یعنی که توکن کاربر لو رفته.
#cyber_security
@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
چطور به عنوان یه مهندس قابل‌اطمینان، اعتبار بسازیم؟
برای اینکه از دید مدیر یا سهام‌دارمون قابل‌اطمینان بنظر بیایم، باید سعی کنیم از دید اونها به مسائل نگاه کنیم و برای این هدف یسری کارها رو می‌تونیم انجام بدیم؛ مثل اعتراف به اشتباهات، کنسل کردن جلسات بیهوده، نه گفتن در غالب اوقات، مدیر رو در جریان تغییرات گذاشتن و ...
[لینک مقاله]
#recent_reads
@techstuff100
چطور ریموت کار کنیم
ریموت کار کردن فقط این نیست که لپ‌تاپمون رو برداریم و از خونه کار کنیم. وقتی ریموت کار می‌کنیم، هنوز عضوی از یه تیم هستیم و باید در زمان کاری در دسترس باشیم. البته این به معنی آنلاین بودن ۲۴ ساعته نیست. باید بتونیم بین زمان کار و زندگی شخصی یه مرز مشخص داشته باشیم و بعد از تموم شدن کار واقعا ازش فاصله بگیریم.
از طرف دیگه باید حواسمون به زمان بقیه هم باشه، مخصوصا وقتی اعضای تیم توی تایم‌زون‌های مختلف هستن. برای جلسه یا پیام دادن، ساعت کاری طرف مقابل رو در نظر بگیریم. محیط خونه هم می‌تونه پر از حواس‌پرتی باشه، پس باید یاد بگیریم تمرکزمون رو حفظ کنیم و یه روتین مشخص برای کار داشته باشیم. در کنارش رعایت قوانین امنیتی شرکت مثل آپدیت نگه داشتن سیستم‌عامل و رعایت سیاست‌های مربوط به پسورد هم بخشی از مسئولیت ماست. ریموت کار کردن آزادی بیشتری میده، ولی برای اینکه واقعا خوب پیش بره، نیاز به نظم و مسئولیت‌پذیری بیشتری داره.
#Skills_of_a_Successful_Software_Engineer
@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
با بزرگ شدن 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
قانون پارکینسون میگه کار اونقدر کش پیدا می‌کنه تا زمانی که برای تکمیلش داریم رو پر کنه. پروژه‌هایی که ددلاینی ندارن، بیشتر از اونچه که باید زمان می‌گیرن و ست کردن ددلاین‌های چالشی (منظور ددلاین غیرممکن نیست) باعث میشه نتایج بهتری بگیریم. اینجا مفهومی به اسم Iron Triangle میاد وسط که سه تا محدودیت کلیدی یه پروژه رو تعریف می‌کنه: اسکوپ، منابع و زمان. با تغییر یکی، دو تای دیگه تغییر می‌کنن.
[مقاله]
#recent_reads
@techstuff100