طراحی سیستم: Multipart Upload
این پست درباره Multipart Upload هست که برای آپلود فایلهای بزرگ استفاده میشه و باعث میشه هم در برابر قطعی شبکه مقاومتر باشیم، هم بتونیم با آپلود همزمان بخشهای مختلف، زمان آپلود رو کمتر کنیم.
#system_design_interview_volume_2
@techstuff100
این پست درباره Multipart Upload هست که برای آپلود فایلهای بزرگ استفاده میشه و باعث میشه هم در برابر قطعی شبکه مقاومتر باشیم، هم بتونیم با آپلود همزمان بخشهای مختلف، زمان آپلود رو کمتر کنیم.
#system_design_interview_volume_2
@techstuff100
❤9👍2
یه نکته کوچیک درباره XSS وجود داره که خیلیا موقع تست امنیت یادشون میره. بعضی وقتا context ای که ورودی کاربر توش قرار میگیره، یه اتریبیوت از تگ HTML هست. بخصوص اگه اون اتریبیوت خودش قابلیت اجرای کد داشته باشه. مثلا تگ a رو در نظر بگیرید. اگه بتونیم مقدار href رو کنترل کنیم، میتونیم به جای یه URL معمولی از پروتکل javascript استفاده کنیم.
وقتی کاربر روی این لینک کلیک کنه، به جای رفتن به یه صفحه، کد جاوااسکریپت داخل href اجرا میشه. تو دنیای واقعی به جای alert معمولا کدی میبینیم که کوکی سرقت میکنه، درخواست به یه سرور بیرونی میفرسته یا سشن کاربر رو هایجک میکنه.
نکته مهم اینه که فیلتر کردن فقط تگهای خطرناک مثل script کافی نیست. باید مراقب اتریبیوتهایی مثل href، src یا حتی event handlerها هم بود، چون هرکدوم میتونن یه مسیر جایگزین برای اجرای کد باز کنن.
#cyber_security #xss
@techstuff100
وقتی کاربر روی این لینک کلیک کنه، به جای رفتن به یه صفحه، کد جاوااسکریپت داخل href اجرا میشه. تو دنیای واقعی به جای alert معمولا کدی میبینیم که کوکی سرقت میکنه، درخواست به یه سرور بیرونی میفرسته یا سشن کاربر رو هایجک میکنه.
نکته مهم اینه که فیلتر کردن فقط تگهای خطرناک مثل script کافی نیست. باید مراقب اتریبیوتهایی مثل href، src یا حتی event handlerها هم بود، چون هرکدوم میتونن یه مسیر جایگزین برای اجرای کد باز کنن.
#cyber_security #xss
@techstuff100
❤6👏3
مقالاتی که اخیرا خوندم (قسمت اول)
🔺 XSS in hidden input fields [لینک]
🔺 How I Actually Prepare for Coding Interviews [لینک]
🔺Design Google Docs Like a Senior Engineer [لینک]
🔺 مسیر ساخت WAF در ترب [لینک]
🔺 رایتآپ تصاحب حساب کاربری از زیرِ بغلِ مار [لینک]
🔺 I Used Git Wrong for Years [لینک]
🔺 The Team Matching Round: The Interview Where You Should Be Doing the Interviewing [لینک]
#recent_reads
@techstuff100
🔺 XSS in hidden input fields [لینک]
🔺 How I Actually Prepare for Coding Interviews [لینک]
🔺Design Google Docs Like a Senior Engineer [لینک]
🔺 مسیر ساخت WAF در ترب [لینک]
🔺 رایتآپ تصاحب حساب کاربری از زیرِ بغلِ مار [لینک]
🔺 I Used Git Wrong for Years [لینک]
🔺 The Team Matching Round: The Interview Where You Should Be Doing the Interviewing [لینک]
#recent_reads
@techstuff100
👍9
هشتگهای مفید برای دسترسی راحتتر به مطالب
🔺 کتاب System Design Interview volume 1:
#system_design_interview_volume_1
🔺 کتاب System Design Interview volume 2:
#system_design_interview_volume_2
🔺 کتاب Skills of a Successful Software Engineer:
#Skills_of_a_Successful_Software_Engineer
🔺 کتاب Building Micro-Frontends:
#Building_Micro_Frontends
🔺 کتاب A Philosophy of Software Design:
#A_Philosophy_of_Software_Design
🔺 میکرفرانتاند:
#MicroFrontend
🔺 امنیت:
#cyber_security #xss
🔺 ا PWA:
#pwa
🔺 آخرین مقالاتی که خوندم:
#recent_reads
🔺 ریاکت:
#react
🔺 تایپاسکریپت:
#typescript
🔺 جاوااسکریپت:
#javascript
🔺 طراحی سیستم:
#system_design
🔺 ا HTML:
#html
🔺 ا CSS:
#css
🔺 گیت:
#git
🔺 ا NPM:
#npm
🔺 مهندسی نرمافزار
#software_engineering
@techstuff100
🔺 کتاب System Design Interview volume 1:
#system_design_interview_volume_1
🔺 کتاب System Design Interview volume 2:
#system_design_interview_volume_2
🔺 کتاب Skills of a Successful Software Engineer:
#Skills_of_a_Successful_Software_Engineer
🔺 کتاب Building Micro-Frontends:
#Building_Micro_Frontends
🔺 کتاب A Philosophy of Software Design:
#A_Philosophy_of_Software_Design
🔺 میکرفرانتاند:
#MicroFrontend
🔺 امنیت:
#cyber_security #xss
🔺 ا PWA:
#pwa
🔺 آخرین مقالاتی که خوندم:
#recent_reads
🔺 ریاکت:
#react
🔺 تایپاسکریپت:
#typescript
🔺 جاوااسکریپت:
#javascript
🔺 طراحی سیستم:
#system_design
🔺 ا HTML:
#html
🔺 ا CSS:
#css
🔺 گیت:
#git
🔺 ا NPM:
#npm
🔺 مهندسی نرمافزار
#software_engineering
@techstuff100
❤9
Tech Stuff pinned «هشتگهای مفید برای دسترسی راحتتر به مطالب 🔺 کتاب System Design Interview volume 1: #system_design_interview_volume_1 🔺 کتاب System Design Interview volume 2: #system_design_interview_volume_2 🔺 کتاب Skills of a Successful Software Engineer: #Skills_of…»
تو یک توسعهدهنده هستی!
یه چیزی هست که خیلی از ما خصوصا وقتی تازهکاریم یا فقط یه شرکت رو تجربه کردیم، بهش دقت نمیکنیم: تکنولوژیای که الان باهاش کار میکنیم، فقط یه ابزاره، نه هویت ما. خیلی وقتا شرکتها ما رو توی یه قالب میذارن، مثلا میگن تو frontend developer هستی، پس با جاوااسکریپت بمون و اگه این قالب رو باور کنیم، ناخودآگاه از یادگیری چیزای دیگه دور میشیم.
توی برنامهنویسی اگه فقط با React کار کرده باشی، فکر میکنی همهچی رو باید با reactive programming حل کرد. اگه فقط جاوا بلد باشی، حتی سادهترین مسئله رو هم پیچیده حل میکنی. مشکل از زبان نیست، از اینه که خودمون رو محدود به یه ابزار کردیم.
خود نویسنده هم همینطور بود. سالها با PHP کار کرد، بعد Ruby، بعد Python، بعد Node.js. وقتی از این زبان به اون زبان پرید، فهمید همهشون یه چیزای مشترک دارن. اونجا بود که فهمید قضیه سر زبان نیست، سر مفاهیم انتزاعی پشتشونه. هدف این نیست که یه Java developer محشر بشی، هدف اینه یه توسعهدهنده خوب بشی، بدون هیچ برچسبی.
(1/2)
#Skills_of_a_Successful_Software_Engineer
@techstuff100
یه چیزی هست که خیلی از ما خصوصا وقتی تازهکاریم یا فقط یه شرکت رو تجربه کردیم، بهش دقت نمیکنیم: تکنولوژیای که الان باهاش کار میکنیم، فقط یه ابزاره، نه هویت ما. خیلی وقتا شرکتها ما رو توی یه قالب میذارن، مثلا میگن تو frontend developer هستی، پس با جاوااسکریپت بمون و اگه این قالب رو باور کنیم، ناخودآگاه از یادگیری چیزای دیگه دور میشیم.
توی برنامهنویسی اگه فقط با React کار کرده باشی، فکر میکنی همهچی رو باید با reactive programming حل کرد. اگه فقط جاوا بلد باشی، حتی سادهترین مسئله رو هم پیچیده حل میکنی. مشکل از زبان نیست، از اینه که خودمون رو محدود به یه ابزار کردیم.
خود نویسنده هم همینطور بود. سالها با PHP کار کرد، بعد Ruby، بعد Python، بعد Node.js. وقتی از این زبان به اون زبان پرید، فهمید همهشون یه چیزای مشترک دارن. اونجا بود که فهمید قضیه سر زبان نیست، سر مفاهیم انتزاعی پشتشونه. هدف این نیست که یه Java developer محشر بشی، هدف اینه یه توسعهدهنده خوب بشی، بدون هیچ برچسبی.
(1/2)
#Skills_of_a_Successful_Software_Engineer
@techstuff100
❤8👍2🔥1
Tech Stuff
تو یک توسعهدهنده هستی! یه چیزی هست که خیلی از ما خصوصا وقتی تازهکاریم یا فقط یه شرکت رو تجربه کردیم، بهش دقت نمیکنیم: تکنولوژیای که الان باهاش کار میکنیم، فقط یه ابزاره، نه هویت ما. خیلی وقتا شرکتها ما رو توی یه قالب میذارن، مثلا میگن تو frontend developer…
همه زبانها loop دارن، همه شرط دارن، فقط شکل نشوندادنش فرق میکنه. وقتی متوجه این باشیم، دو تا فایده داره: راحتتر از یه زبان به زبان دیگه میپریم؛ چون paradigm رو بلدیم. همینطور میتونیم مفاهیم رو از یه زبان به زبان دیگه ترجمه کنیم.
توصیه همیشگی نویسنده اینه: از اون قالبی که کار روزمره برات ساخته بیا بیرون. اونجا comfort zone توئه و رشد فقط بیرون از اون اتفاق میافته. حتی توسعهدهندههای باتجربه هم گاهی فکر میکنن اگه رو یه تکنولوژی خاص متمرکز بشن استاد میشن؛ ولی همین باعث میشه از اون تنوع و خلاقیتی که از دیدن راهحلهای مختلف میاد محروم بمونن. کافیه یه توسعهدهنده COBOL پیدا کنی و بپرسی الان چقدر گزینه توی بازار داره.
در آخر کار اصلی یه توسعهدهنده حل مسئلهست، نه تسلط به یه زبان خاص. زبان فقط ابزاره و هر مسئله ابزار خودش رو میخواد. ابزارهای دیگهای هم هست که باید بلد باشی، مثل SOLID و DRY. یاد بگیر باهاشون دوست بشی، چون قراره مدت زیادی همراهت باشن.
(2/2)
#Skills_of_a_Successful_Software_Engineer
@techstuff100
توصیه همیشگی نویسنده اینه: از اون قالبی که کار روزمره برات ساخته بیا بیرون. اونجا comfort zone توئه و رشد فقط بیرون از اون اتفاق میافته. حتی توسعهدهندههای باتجربه هم گاهی فکر میکنن اگه رو یه تکنولوژی خاص متمرکز بشن استاد میشن؛ ولی همین باعث میشه از اون تنوع و خلاقیتی که از دیدن راهحلهای مختلف میاد محروم بمونن. کافیه یه توسعهدهنده COBOL پیدا کنی و بپرسی الان چقدر گزینه توی بازار داره.
در آخر کار اصلی یه توسعهدهنده حل مسئلهست، نه تسلط به یه زبان خاص. زبان فقط ابزاره و هر مسئله ابزار خودش رو میخواد. ابزارهای دیگهای هم هست که باید بلد باشی، مثل SOLID و DRY. یاد بگیر باهاشون دوست بشی، چون قراره مدت زیادی همراهت باشن.
(2/2)
#Skills_of_a_Successful_Software_Engineer
@techstuff100
❤9👍2🔥1
نزدیک ۳ سال داره میشه که توی لینکدین بطور مستمر دارم فعالیت میکنم (اگه قطعیهای اینترنت وسطش رو در نظر نگیریم). از یجایی به بعد دوست داشتم این فعالیت رو توی جاهای دیگه مثل تلگرام و یوتوب هم ادامه بدم. برای ایجاد کانال تلگرام دودل بودم و هی عقب مینداختمش و حس میکردم اون موقع زمان مناسبی براش نیست.
یکی از چیزهایی که باعث شد دیگه عقب نندازمش و کانال رو بزنم، این کامنت علیرضا بود. الان بعد حدود ۱ سال و نیم کانال 1000 تا عضو رو رد کرده و رشدش به یکی از چیزایی تبدیل شده که براش ذوق دارم؛ بخصوص الان که سربازیم رو میگذرونم. واقعا ازش ممنونم و دمش گرم❤️.
دم همه شما هم گرم که اینجا بودین و پستا رو به اشتراک میذاشتین❤️.
دم خودمم گرم که دیسیپلین داشتم و ادامهش دادم 🫡.
بریم برای ادامه.
@techstuff100
یکی از چیزهایی که باعث شد دیگه عقب نندازمش و کانال رو بزنم، این کامنت علیرضا بود. الان بعد حدود ۱ سال و نیم کانال 1000 تا عضو رو رد کرده و رشدش به یکی از چیزایی تبدیل شده که براش ذوق دارم؛ بخصوص الان که سربازیم رو میگذرونم. واقعا ازش ممنونم و دمش گرم❤️.
دم همه شما هم گرم که اینجا بودین و پستا رو به اشتراک میذاشتین❤️.
دم خودمم گرم که دیسیپلین داشتم و ادامهش دادم 🫡.
بریم برای ادامه.
@techstuff100
❤22👍3🔥3
بستن تگ <script> در حملات XSS
یکی از تکنیکهای رایج XSS، بستن تگ <script> و خروج از کانتکست جاوااسکریپته. توی این پست با یه مثال ساده بررسی کردم چرا این تکنیک کار میکنه و نقش HTML Parser توی اون چیه.
#cyber_security #xss #html
@techstuff100
یکی از تکنیکهای رایج XSS، بستن تگ <script> و خروج از کانتکست جاوااسکریپته. توی این پست با یه مثال ساده بررسی کردم چرا این تکنیک کار میکنه و نقش HTML Parser توی اون چیه.
#cyber_security #xss #html
@techstuff100
❤7
یکی از نشونههای رایج طراحی نهچندان خوب، متدهای Pass-through هست. یعنی متدی که تقریبا هیچ کاری نمیکنه و فقط ورودیها رو به متد کلاس دیگه پاس میده. اینجا getUser هیچ منطق جدیدی اضافه نکرده و فقط نقش واسطه رو داره.
مشکل اینجاست که این متدها فقط تعداد APIهای کلاس رو بیشتر میکنن، بدون اینکه قابلیت جدیدی به سیستم اضافه کنن. علاوه بر اون وابستگی هم ایجاد میکنن؛ مثلا اگر اینترفیس getUser داخل UserRepository تغییر کنه، این متد هم باید تغییر کنه.
وجود چنین متدهایی معمولا نشون میده مرز مسئولیت بین کلاسها شفاف نیست. اگر قابلیتی کاملا داخل یک کلاس پیادهسازی شده، بهتره متد مربوط به اون هم همونجا باشه، نه اینکه یک کلاس دیگه فقط درخواست رو فروارد کنه.
با برخورد به چنین کلاسهایی باید پرسید: دقیقا مسئولیت هر کدوم از این کلاسها چیه؟ جواب این سوال خیلی وقتها باعث میشه یکی از این کارها رو انجام بدید:
- کلاس سطح پایین رو مستقیما در اختیار استفادهکننده قرار بدید.
- مسئولیتها رو بین کلاسها دوباره تقسیم کنید.
- یا اگر عملا از هم جدا نیستن، اونها رو با هم ادغام کنید.
#A_Philosophy_of_Software_Design
@techstuff100
مشکل اینجاست که این متدها فقط تعداد APIهای کلاس رو بیشتر میکنن، بدون اینکه قابلیت جدیدی به سیستم اضافه کنن. علاوه بر اون وابستگی هم ایجاد میکنن؛ مثلا اگر اینترفیس getUser داخل UserRepository تغییر کنه، این متد هم باید تغییر کنه.
وجود چنین متدهایی معمولا نشون میده مرز مسئولیت بین کلاسها شفاف نیست. اگر قابلیتی کاملا داخل یک کلاس پیادهسازی شده، بهتره متد مربوط به اون هم همونجا باشه، نه اینکه یک کلاس دیگه فقط درخواست رو فروارد کنه.
با برخورد به چنین کلاسهایی باید پرسید: دقیقا مسئولیت هر کدوم از این کلاسها چیه؟ جواب این سوال خیلی وقتها باعث میشه یکی از این کارها رو انجام بدید:
- کلاس سطح پایین رو مستقیما در اختیار استفادهکننده قرار بدید.
- مسئولیتها رو بین کلاسها دوباره تقسیم کنید.
- یا اگر عملا از هم جدا نیستن، اونها رو با هم ادغام کنید.
#A_Philosophy_of_Software_Design
@techstuff100
❤7🤔2
جلوگیری از درخواستهای تکراری با Idempotency
یکی از مشکلات رایج در سیستمها اینه که ممکنه یک درخواست بیشتر از یک بار ارسال بشه. مثلا کاربر روی دکمه پرداخت دوبار کلیک کنه، یا پرداخت با موفقیت انجام بشه ولی پاسخ به خاطر مشکل شبکه به کلاینت نرسه و کاربر دوباره درخواست پرداخت بفرسته.
اینجا Idempotency کمک میکنه یک درخواست حتی اگر چند بار ارسال بشه، فقط یک بار پردازش بشه. برای این کار معمولا یک Idempotency Key همراه درخواست ارسال میکنیم. سرور این کلید رو ذخیره میکنه و اگر دوباره همون کلید رو ببینه، به جای پردازش مجدد نتیجه درخواست قبلی رو برمیگردونه.
یکی از راههای ساده برای پیادهسازی این موضوع استفاده از Unique Constraint دیتابیسه. درخواست اول با موفقیت رکورد مربوط به کلید رو ثبت میکنه. ولی اگر درخواست دوم با همون کلید برسه، ثبت رکورد به خاطر تکراری بودن کلید fail میشه و سرور میفهمه که این درخواست قبلا پردازش شده.
#system_design_interview_volume_2
@techstuff100
یکی از مشکلات رایج در سیستمها اینه که ممکنه یک درخواست بیشتر از یک بار ارسال بشه. مثلا کاربر روی دکمه پرداخت دوبار کلیک کنه، یا پرداخت با موفقیت انجام بشه ولی پاسخ به خاطر مشکل شبکه به کلاینت نرسه و کاربر دوباره درخواست پرداخت بفرسته.
اینجا Idempotency کمک میکنه یک درخواست حتی اگر چند بار ارسال بشه، فقط یک بار پردازش بشه. برای این کار معمولا یک Idempotency Key همراه درخواست ارسال میکنیم. سرور این کلید رو ذخیره میکنه و اگر دوباره همون کلید رو ببینه، به جای پردازش مجدد نتیجه درخواست قبلی رو برمیگردونه.
یکی از راههای ساده برای پیادهسازی این موضوع استفاده از Unique Constraint دیتابیسه. درخواست اول با موفقیت رکورد مربوط به کلید رو ثبت میکنه. ولی اگر درخواست دوم با همون کلید برسه، ثبت رکورد به خاطر تکراری بودن کلید fail میشه و سرور میفهمه که این درخواست قبلا پردازش شده.
#system_design_interview_volume_2
@techstuff100
❤7👏2