Tech Stuff

یه مسئله جالب برای تمرین 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

تخصص و مهارتت رو الان بساز

طرح جدید مکتبخونه با نام "ایران ماهر" فرصتی تازه در اختیار علاقه مندان به یادگیری گذاشت تا بتونیم در کنار هم یک مهارت جدید بیاموزیم و به ارتقای جمعی کمک کنیم.

منم مثل همیشه دوره هایی که حس کردم می تونه به این موضوع کمک کنه رو توی این طرح قرار دادم تا دوستان بتونن نهایت استفاده رو از این طرح داشته باشن.

به دوره های زیر می تونین با استفاده از راهنمای درج شده دسترسی داشته باشید:
- جنگو مقدماتی django
- طراحی سرویس با fastapi
- طراحی ربات تلگرام با پایتون
- مستر کلاس پایتون

لینک دسترسی به دوره های این طرح و راهنمای استفاده:

https://mktb.me/xmzu/

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

موفق باشید ❤️

@thealibigdeli_channel
#course
#free

بعضی وقت‌ها توی XSS با فیلترهایی روبه‌رو میشیم که کاراکترهایی مثل () ; رو بلاک می‌کنن. یکی از تکنیک‌های جالب اینه که از throw و onerror استفاده کنیم.

ایده کلی اینه که وقتی یک Exception رخ میده، مرورگر تابعی که داخل window.onerror قرار دادیم رو اجرا می‌کنه. اگر onerror رو برابر alert قرار بدیم، مقدار Exception به عنوان آرگومان به alert ارسال میشه.

مثال ‍۱: داخل بلوک {} مقدار onerror روی alert تنظیم میشه و بعد با throw مقدار 1337 به عنوان Exception پرتاب میشه. در نهایت alert(1337) اجرا میشه.

مثال ۲: شاید در نگاه اول عجیب باشه که throw قبل از onerror=alert نوشته شده. اما جاوااسکریپت قبل از اینکه چیزی رو throw کنه، اول کل عبارت جلوی throw رو محاسبه می‌کنه. به خاطر عملگر کاما , عبارت‌ها از چپ به راست اجرا میشن؛ یعنی اول onerror روی alert تنظیم میشه، بعد مقادیر 'some string' و 123 نادیده گرفته میشن و در نهایت 'haha' به عنوان Exception پرتاب میشه. بنابراین وقتی خطا رخ میده، onerror از قبل روی alert تنظیم شده و مقدار "haha" داخل alert نمایش داده میشه.

[منبع پست]

#xss #cyber_security #javascript

@techstuff100

رویداد بررسی معماری چند لایه یا layered architecture

بررسی معماری layered architecture و نمایش یک نمونه سورس پیاده سازی شده با fastapi و بررسی بخش های مختلف در عملکرد

https://thealibigdeli.ir/r/9PLVq4/

@thealibigdeli_channel
#event

همیشه Refactor کردن کد کار درستی نیست

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

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

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

در نهایت قبل از شروع هر ریفکتور، سه سوال ساده می‌تونه کمکمون کنه:
- این تغییر چه ارزشی ایجاد می‌کنه؟
- چه اثری روی بقیه سیستم و تیم‌ها داره؟
- آیا زمان و ظرفیت انجامش رو داریم؟

#Skills_of_a_Successful_Software_Engineer

@techstuff100

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

تست‌ها هم توی ریفکتور نقش مهمی دارن. طبیعیه که بعد از یک ریفکتور بزرگ بعضی تست‌ها fail بشن، چون کد تغییر کرده. در کنار تست‌های اتوماتیک، نباید QA رو هم از فرایند حذف کنیم.

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

تا جای ممکن بهتره کارهای تکراری رو به ابزارها بسپاریم. IDE و linterها خیلی از ریفکتور‌های ساده مثل rename کردن رو با خطای کمتری نسبت به تغییر دستی انجام میدن. ریفکتور دستی رو بیشتر برای جاهایی نگه داریم که نیاز به تصمیم طراحی یا تغییرات بزرگ‌تر دارن.

#Skills_of_a_Successful_Software_Engineer

@techstuff100

جلوگیری از درخواست‌های تکراری با Idempotency

یکی از مشکلات رایج در سیستم‌ها اینه که ممکنه یک درخواست بیشتر از یک بار ارسال بشه. مثلا کاربر روی دکمه پرداخت دوبار کلیک کنه، یا پرداخت با موفقیت انجام بشه ولی پاسخ به خاطر مشکل شبکه به کلاینت نرسه و کاربر دوباره درخواست پرداخت بفرسته.

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

یکی از راه‌های ساده برای پیاده‌سازی این موضوع استفاده از Unique Constraint دیتابیسه. درخواست اول با موفقیت رکورد مربوط به کلید رو ثبت می‌کنه. ولی اگر درخواست دوم با همون کلید برسه، ثبت رکورد به خاطر تکراری بودن کلید fail میشه و سرور می‌فهمه که این درخواست قبلا پردازش شده.

#system_design_interview_volume_2

@techstuff100

یکی از نشونه‌های رایج طراحی نه‌چندان خوب، متد‌های Pass-through هست. یعنی متدی که تقریبا هیچ کاری نمی‌کنه و فقط ورودی‌ها رو به متد کلاس دیگه پاس میده. اینجا getUser هیچ منطق جدیدی اضافه نکرده و فقط نقش واسطه رو داره.

مشکل اینجاست که این متدها فقط تعداد APIهای کلاس رو بیشتر می‌کنن، بدون اینکه قابلیت جدیدی به سیستم اضافه کنن. علاوه بر اون وابستگی هم ایجاد می‌کنن؛ مثلا اگر اینترفیس getUser داخل UserRepository تغییر کنه، این متد هم باید تغییر کنه.

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

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

#A_Philosophy_of_Software_Design

@techstuff100