Posts

آسیب‌پذیری IDOR چیه؟ آسیب‌پذیری IDOR یا Insecure Direct Object Reference که زیرمجموعه‌ای از آسیب‌پذیری‌های ، زمانی اتفاق می‌افته که یه API طوری طراحی شده باشه که با استفاده از شناسه‌های قابل حدس، مثل یوزرنیم یا عددهای افزایشی (مثلاً 123)، امکان دسترسی به اطلاعات رو بده. یعنی اگر من یوزر 123 هستم و به اطلاعات خودم دسترسی دارم، بتونم با تغییر عدد به 124، اطلاعات یوزر بعدی رو هم ببینم. حالا تصور کنید این مسئله فقط برای خوندن داده‌ها نباشه؛ یه متد update هم وجود داشته باشه که با گرفتن همون ID اطلاعات رو تغییر بده. این‌جوری مهاجم نه‌تنها می‌تونه اطلاعات بقیه رو ببینه، بلکه حتی می‌تونه تغییرشون هم بده. ...

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

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

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

در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از ها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم. فیک Fake این نوع Test Double به عنوان یک جایگزین ساده‌تر، کم‌هزینه‌تر و قابل آزمایش‌تر برای دیپندنسی مورد نظر استفاده می‌شه. Fakeها از همون interfaceهای دیپندنسی اصلی استفاده می‌کنه و اون‌ها رو پیاده‌سازی می‌کنه. مثلاً، فرض کنید می‌خوایم یک شیء رو در دیتابیس بنویسیم و بخونیم. به جای راه‌اندازی یک دیتابیس واقعی برای اجرای هربارهٔ تست‌ها، از یک دیکشنری in memory استفاده می‌کنیم تا وظیفه خوندن و نوشتن داده‌ها رو برامون انجام بده. توی این حالت این دیکشنری وظیفهٔ Fake کردن دیتابیس اصلی رو بر عهده داره. ...

من حدود ۱۰ سال پیش کارم رو به عنوان کارآموز بکند (Laravel) در شرکتی شروع کردم. محصول اصلی اون موقع تیم یک نرم‌افزار هتل‌داری چندزبانه بود. بعد از مدتی دیدن tutorial و تمرین کردن، مدیر فنی تیم به نظرش رسید که آمادهٔ کد زدن بر روی پروژهٔ اصلی شرکت هستم و وارد تیم شدم. وقتی اولین تسک رو انجام دادم، با استرس پول‌ریکوستی که ساخته بودم رو برای مدیرم فرستادم. قبل از این که بازش کنه ازم پرسید که خودت ریویو کردی؟ یکم تعجب کردم و گفتم نه. گفت پس برو اول خودت ریویو کن، کدت رو بر اساس کامنت‌هات درست کن و بعدش دوباره برای من بفرست. پیشنهاد هم کرد که این ریویوها رو قبل از کامیت کردن کد انجام بدم و همونجا رو هم بهم یاد داد. ...

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

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

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

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