نزدیک ۳ سال داره میشه که توی لینکدین بطور مستمر دارم فعالیت می‌کنم (اگه قطعی‌های اینترنت وسطش رو در نظر نگیریم). از یجایی به بعد دوست داشتم این فعالیت رو توی جاهای دیگه مثل تلگرام و یوتوب هم ادامه بدم. برای ایجاد کانال تلگرام دودل بودم و هی عقب مینداختمش و حس می‌کردم اون موقع زمان مناسبی براش نیست.

یکی از چیزهایی که باعث شد دیگه عقب نندازمش و کانال رو بزنم، این کامنت علیرضا بود. الان بعد حدود ۱ سال و نیم کانال 1000 تا عضو رو رد کرده و رشدش به یکی از چیزایی تبدیل شده که براش ذوق دارم؛ بخصوص الان که سربازیم رو می‌گذرونم. واقعا ازش ممنونم و دمش گرم❤️.

دم همه شما هم گرم که اینجا بودین و پستا رو به اشتراک میذاشتین❤️.

دم خودمم گرم که دیسیپلین داشتم و ادامه‌ش دادم 🫡.

بریم برای ادامه.

@techstuff100

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

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

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

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

#A_Philosophy_of_Software_Design

@techstuff100

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

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

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

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

#system_design_interview_volume_2

@techstuff100

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

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

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

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

#Skills_of_a_Successful_Software_Engineer

@techstuff100

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

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

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

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

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

#Skills_of_a_Successful_Software_Engineer

@techstuff100

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

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

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

@thealibigdeli_channel
#event

بعضی وقت‌ها توی 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

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

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

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

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

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

https://mktb.me/xmzu/

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

موفق باشید ❤️

@thealibigdeli_channel
#course
#free

سوال مصاحبه: طراحی سیستم رزرو Airbnb

توی این مقاله نویسنده تجربه مصاحبه طراحی سیستم برای سیستم رزرو شبیه Airbnb رو تعریف می‌کنه. سناریو این بود که دو کاربر هم‌زمان بخوان یک اقامتگاه رو برای تاریخ یکسان رزرو کنن. تمرکز مصاحبه روی تحلیل مسئله و تصمیم‌گیری‌ها بود؛ مثل این‌که کجا Strong Consistency و کجا Eventual Consistency نیاز داریم. مصاحبه بعد از حدود ۱۲ دقیقه متوقف شد، چون مصاحبه‌کننده به پاسخ مورد انتظارش رسیده بود.

یکی از بخش‌های مهم طراحی، استفاده از Idempotency برای جلوگیری از رزروهای تکراری در اثر Retry درخواست‌ها و جلوگیری از Conflict در لایه داده برای Double Booking بود؛ مثلا با Constraintهای دیتابیس.

سوال سخت‌تر این بود: اگر دو کاربر از دو Region مختلف هم‌زمان بخوان یک اقامتگاه رو رزرو کنن، چطور Conflict رو مدیریت می‌کنید؟

[لینک مقاله]

#system_design

@techstuff100

کتاب Skills of a Successful Software Engineer رو تموم کردم. کتاب جالبی بود. چند تا پست دیگه ازش دارم که کم کم میذارمشون.

بعد اون Grokking Algorithms رو شروع کردم.

#Grokking_Algorithms

@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

کلون ریپازیتوری بدون تاریخچه کامل

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

این روش یه shallow clone ایجاد می‌کنه و به همین دلیل کل تاریخچه گیت رو نداریم. اگر بعدا به تاریخچه کامل نیاز داشتیم، می‌تونیم با git fetch --unshallow کل تاریخچه رو دریافت کنیم.

#git

@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

جلسه قراره یه هدف مشخص داشته باشه و وقتی این هدف فراموش بشه، جلسه خیلی راحت تبدیل میشه به اتلاف وقت.

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

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

#Skills_of_a_Successful_Software_Engineer

@techstuff100

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

به نظرم خوندن این مقاله بخصوص برای کسی که داره برای مصاحبه آماده میشه خیلی مفیده.

[لینک مقاله]

@techstuff100