Tech Stuff

تخصص و مهارتت رو الان بساز طرح جدید مکتبخونه با نام "ایران ماهر" فرصتی تازه در اختیار علاقه مندان به یادگیری گذاشت تا بتونیم در کنار هم یک مهارت جدید بیاموزیم و به ارتقای جمعی کمک کنیم. منم مثل همیشه دوره هایی که حس کردم می تونه به این موضوع کمک کنه رو توی این طرح قرار دادم تا دوستان بتونن نهایت استفاده رو از این طرح داشته باشن. به دوره های زیر می تونین با استفاده از راهنمای درج شده دسترسی داشته باشید: - جنگو مقدماتی 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

بستن تگ <script> در حملات XSS یکی از تکنیک‌های رایج XSS، بستن تگ <script> و خروج از کانتکست جاوااسکریپته. توی این پست با یه مثال ساده بررسی کردم چرا این تکنیک کار می‌کنه و نقش HTML Parser توی اون چیه. #cyber_security #xss #html @techstuff100

نزدیک ۳ سال داره میشه که توی لینکدین بطور مستمر دارم فعالیت می‌کنم (اگه قطعی‌های اینترنت وسطش رو در نظر نگیریم). از یجایی به بعد دوست داشتم این فعالیت رو توی جاهای دیگه مثل تلگرام و یوتوب هم ادامه بدم. برای ایجاد کانال تلگرام دودل بودم و هی عقب مینداختمش و حس می‌کردم اون موقع زمان مناسبی براش نیست. یکی از چیزهایی که باعث شد دیگه عقب نندازمش و کانال رو بزنم، این کامنت علیرضا بود. الان بعد حدود ۱ سال و نیم کانال 1000 تا عضو رو رد کرده و رشدش به یکی از چیزایی تبدیل شده که براش ذوق دارم؛ بخصوص الان که سربازیم رو می‌گذرونم. واقعا ازش ممنونم و دمش گرم❤️. دم همه شما هم گرم که اینجا بودین و پستا رو به اشتراک میذاشتین❤️. دم خودمم گرم که دیسیپلین داشتم و ادامه‌ش دادم 🫡. بریم برای ادامه. @techstuff100

همه زبان‌ها loop دارن، همه شرط دارن، فقط شکل نشون‌دادنش فرق می‌کنه. وقتی متوجه این باشیم، دو تا فایده داره: راحت‌تر از یه زبان به زبان دیگه می‌پریم؛ چون paradigm رو بلدیم. همینطور می‌تونیم مفاهیم رو از یه زبان به زبان دیگه ترجمه کنیم. توصیه همیشگی نویسنده اینه: از اون قالبی که کار روزمره برات ساخته بیا بیرون. اونجا comfort zone توئه و رشد فقط بیرون از اون اتفاق می‌افته. حتی توسعه‌دهنده‌های باتجربه هم گاهی فکر می‌کنن اگه رو یه تکنولوژی خاص متمرکز بشن استاد میشن؛ ولی همین باعث میشه از اون تنوع و خلاقیتی که از دیدن راه‌حل‌های مختلف میاد محروم بمونن. کافیه یه توسعه‌دهنده COBOL پیدا کنی و بپرسی الان چقدر گزینه توی بازار داره. در آخر کار اصلی یه توسعه‌دهنده حل مسئله‌ست، نه تسلط به یه زبان خاص. زبان فقط ابزاره و هر مسئله ابزار خودش رو می‌خواد. ابزارهای دیگه‌ای هم هست که باید بلد باشی، مثل SOLID و DRY. یاد بگیر باهاشون دوست بشی، چون قراره مدت زیادی همراهت باشن. (2/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

هشتگ‌های مفید برای دسترسی راحت‌تر به مطالب 🔺 کتاب 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 🔺 کتاب Grokking Algorithms: #Grokking_Algorithms #algorithm 🔺 میکرفرانت‌اند: #MicroFrontend 🔺 الگوریتم: #algorithm 🔺 امنیت: #cyber_security #xss 🔺 ا PWA: #pwa 🔺 آخرین مقالاتی که خوندم: #recent_reads 🔺 ری‌اکت: #react 🔺 تایپ‌اسکریپت: #typescript 🔺 جاوا‌اسکریپت: #javascript 🔺 طراحی سیستم: #system_design 🔺 ا HTML: #html 🔺 ا CSS: #css 🔺 گیت: #git 🔺 ا NPM: #npm 🔺 مهندسی نرم‌افزار #software_engineering @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

یه نکته کوچیک درباره XSS وجود داره که خیلیا موقع تست امنیت یادشون میره. بعضی وقتا context ای که ورودی کاربر توش قرار می‌گیره، یه اتریبیوت از تگ HTML هست. بخصوص اگه اون اتریبیوت خودش قابلیت اجرای کد داشته باشه. مثلا تگ a رو در نظر بگیرید. اگه بتونیم مقدار href رو کنترل کنیم، می‌تونیم به جای یه URL معمولی از پروتکل javascript استفاده کنیم. وقتی کاربر روی این لینک کلیک کنه، به جای رفتن به یه صفحه، کد جاوااسکریپت داخل href اجرا میشه. تو دنیای واقعی به جای alert معمولا کدی می‌بینیم که کوکی سرقت می‌کنه، درخواست به یه سرور بیرونی می‌فرسته یا سشن کاربر رو هایجک می‌کنه. نکته مهم اینه که فیلتر کردن فقط تگ‌های خطرناک مثل script کافی نیست. باید مراقب اتریبیوت‌هایی مثل href، src یا حتی event handlerها هم بود، چون هرکدوم می‌تونن یه مسیر جایگزین برای اجرای کد باز کنن. #cyber_security #xss @techstuff100

طراحی سیستم: Multipart Upload این پست درباره Multipart Upload هست که برای آپلود فایل‌های بزرگ استفاده میشه و باعث میشه هم در برابر قطعی شبکه مقاوم‌تر باشیم، هم بتونیم با آپلود همزمان بخش‌های مختلف، زمان آپلود رو کمتر کنیم. #system_design_interview_volume_2 @techstuff100

همه چیز درباره پکیج Module Federation توی این ویدیو، به‌صورت کامل با پکیج Module Federation آشنا میشیم و یاد می‌گیریم چطور یه پروژه کامل باهاش بسازیم. این ویدیو کمکتون می‌کنه با معماری میکروفرانت‌اند هم آشنا بشین و ببینین چطور اپلیکیشن‌های مختلف می‌تونن به‌صورت مستقل توسعه داده بشن و در نهایت توی یه اپلیکیشن روت (host) کنار هم لود و نمایش داده بشن. ویدئوی یوتوب: https://www.youtube.com/watch?v=bhUZVxr4mP0&list=PL1bBcWODwsLMYe8Gor4PDwT5U5CK_S36x&index=7 اگه می‌خواین درباره میکروفرانت‌اند بیشتر بدونین، این پلی‌لیست می‌تونه کمک‌کننده باشه: https://www.youtube.com/playlist?list=PL1bBcWODwsLMYe8Gor4PDwT5U5CK_S36x #MicroFrontend @techstuff100

پذیرش بازخورد در برنامه‌نویسی معمولا تنها کار نمی‌کنیم و بخش زیادی از رشد ما از تعامل با بقیه اعضای تیم اتفاق میفته. یکی از مهم‌ترین جاهایی که این موضوع رو می‌بینیم Code Review هست. وقتی کسی کدی که نوشتیم رو بررسی می‌کنه، هدفش پیدا کردن ایراد، بهتر کردن کیفیت کد و انتقال تجربه است؛ نه اینکه توانایی ما رو زیر سوال ببره. البته دریافت بازخورد همیشه راحت نیست. وقتی چند نفر کدی که نوشتیم رو بررسی می‌کنن، ممکنه حس کنیم دارن از کار ما ایراد می‌گیرن، ولی باید یادمون باشه که این بازخورد درباره کد ماست، نه درباره خود ما. حتی بازخوردهای منفی هم معمولا نکته‌ای برای یاد گرفتن دارن؛ مهم اینه که بخش مفیدش رو پیدا کنیم و از قسمت‌هایی که فقط باعث ناراحتی میشن عبور کنیم. اگر هر بازخوردی رو به چشم یک حمله ببینیم، کم‌کم از تصمیم‌گیری می‌ترسیم و فرصت رشد رو از دست میدیم. یاد گرفتن از نقدها و استفاده از تجربه دیگران یکی از چیزهایی هست که باعث میشه به مرور مهندس بهتری بشیم. متن از کتاب Skills of a Successful Software Engineer نوشته Fernando Doglio گرفته شده. #Skills_of_a_Successful_Software_Engineer @techstuff100

نتفلیکس چطور ۲۶۰ میلیلون استریم همزمان رو بدون Buffering مدیریت می‌کنه؟ نتفلیکس فقط به افزایش تعداد سرورها متکی نیست؛ بخش بزرگی از موفقیتش به معماری توزیع محتوا برمی‌گرده. ویدیوها قبل از اینکه کاربری درخواستشون رو بده، روی هزاران سرور CDN اختصاصی به اسم Open Connect که داخل شبکه ISPها قرار دارن توزیع میشن تا درخواست‌ها از نزدیک‌ترین نقطه پاسخ داده بشن. از طرف دیگه هر کاربر با استفاده از Adaptive Bitrate (ABR) کیفیت مناسب با شرایط لحظه‌ای شبکه خودش رو دریافت می‌کنه و همین باعث میشه در بیشتر مواقع پخش ویدیو بدون Buffering ادامه پیدا کنه. مقاله همچنین توضیح میده که مدیریت میلیون‌ها استریم همزمان فقط مسئله زیرساخت نیست؛ بلکه مجموعه‌ای از تصمیم‌های مهندسی مثل انتخاب نزدیک‌ترین CDN، کش کردن محتوا، توزیع هوشمند ترافیک، مانیتورینگ مداوم و Failover خودکار باعث میشن حتی در زمان اوج مصرف هم سرویس پایدار باقی بمونه. لینک مقاله @techstuff100

حمله SSL Stripping و روش‌های دفاع این پست درباره SSL Stripping و مکانیزم HSTS هست. HSTS یک Response Header ساده است که باعث میشه مرورگر فقط از HTTPS برای یک دامنه استفاده کنه. همچنین می‌بینیم چرا HSTS به تنهایی کافی نبود و مرورگرها برای حل مشکل اولین بازدید، HSTS Preload List رو معرفی کردن. #cyber_security @techstuff100

کتابی که اخیرا شروعش کردم. #Skills_of_a_Successful_Software_Engineer @techstuff100