‫۸ سال و ۹ ماه قبل، سه‌شنبه ۱۵ دی ۱۳۹۴، ساعت ۰۳:۳۳
- دلایل تغییری که نام بردید به معنای نقض SRP نیست (چون در نهایت به نتیجه‌ی کلاس دقت می‌شود).
- کل دات نت و تمام کتابخانه‌های معتبر نوشته شده برای آن بر اساس اصل fail fast ایی که اینجا توضیح داده شد کار می‌کنند. حداقل بررسی کدهای ASP.NET MVC و EF موید این مساله هستند.
- روش‌های زیادی برای انجام اینکار هست. از صدور استثناء تا مباحث AOP تا Code contracts و غیره.
‫۸ سال و ۹ ماه قبل، دوشنبه ۱۴ دی ۱۳۹۴، ساعت ۲۱:۰۶
- دریافتی از کاربر به کمک textbox، یک رشته هست.
- تمام فریم ورک‌های درست و حسابی مثل EF یک چنین بررسی‌هایی رو در تمام متدهاشون دارند. برای مثال به سورس EF مراجعه کنید. یک کلاس Check دارند که همه‌جا از آن استفاده شده (البته اگر فکر می‌کنید throw new ArgumentNullException  یعنی تکرار کد).
- یک شیء مسئول اعتبار خودش هم هست و نباید بتوان آن‌را در حالت غیرمعتبر وهله سازی کرد. این مساله ناقض SRP نیست. SRP در مورد دلایل تغییر یک کلاس صحبت می‌کند. آیا کلاسی که بررسی می‌کند ورودی‌های دریافتی آن معتبر هستند یا خیر، چندین دلیل برای تغییر دارد؟ خیر.
‫۸ سال و ۹ ماه قبل، سه‌شنبه ۲۴ آذر ۱۳۹۴، ساعت ۱۳:۳۸
شما نیاز هست با نحوه‌ی دیباگ برنامه‌های وب آشنا بشی. بدون اون نمی‌تونی خطایابی کنی. کامنت‌ها رو هم از ابتدا بخون. بدون اون‌ها هم نمی‌تونی برنامه رو اجرا کنی. چون یک سری نکته‌ی خاص دارن که در متن اصلی نیست.
با دیدن سایت، کار خاصی نمی‌شه انجام داد. شاید حداکثر بشه با ابزارهای تزریق کور اس کیوال مثل ACUNETIX یک حدس‌هایی زد؛ ولی کافی نیست. کد شما باید سطر به سطر بررسی و آنالیز بشه.
خود مایکروسافت یک زمانی برای وب فرم‌ها، ابزاری رو به نام CAT.NET، درست کرده بود که کارش آنالیز استاتیک امنیتی کدهای برنامه است. نسخه‌ی 32 بیتی + نسخه‌ی 64 بیتی + ویدیوی آموزشی آن
‫۸ سال و ۱۰ ماه قبل، پنجشنبه ۲۸ آبان ۱۳۹۴، ساعت ۰۳:۴۵
چند نکته در اینجا حائز اهمیت هستند:
- متد jQuery live منسوخ و حذف شده معادل هست با اتصال تمام رخدادها در سطح document یا همان (document).on('event', 'selector', function) (+). 
- مشکلات متد live و خصوصا بحث انتشار رخدادها و بررسی هر باره‌ی انواع و اقسام آن‌ها و در نتیجه کند شدن صفحه، مهم‌تر هستند تا میزان مصرف حافظه (+).