مطالب
Vue.js - نحوه‌ی ایجاد یک Vue جدید و استفاده از معماری MVVM - قسمت دوم
در قسمت قبلی توضیحاتی جهت معرفی و نصب فریم‌ورک داده شد. در این قسمت قصد داریم کمی بیشتر با ساختار آن آشنا شویم و یک vue جدید را ایجاد کنیم. پس لازم است تا ابتدا درون تگ اسکریپتی که فراخوانی کردیم و آدرس فریم‌ورک در آن قرار داده شده‌است، به صورت زیر یک ویو جدید را ایجاد کنیم:
<html>
    <body>
       <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/1.0.27/vue.min.js">  
 new Vue({ 
               
            }); 
       </script>
    </body>
</html>
ساختار vue.js بدین صورت است که از شما می‌خواهد تعیین کنید این کدها محدود و مربوط به کدام صفحه می‌شوند.
اگر قصد داشته باشید تا درون تگی با یک مشخصه‌ی خاص، دستوری را اجرا کنید، باید تعیین کنید که آن تگ چه خواصی دارد. فرض می‌کنیم که تگ body درون پروژه لازم است مقداری را فراخوانی و اجرا کند. پس لازم است تا یک id، به تگ بادی اختصاص یابد. 
<html>
    <body id="dotnettips">
       <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/1.0.27/vue.min.js">  
 new Vue({ 
               
            }); 
       </script>
    </body>
</html>
در کد بالا یک آیدی با نام dotnettips، به تگ بادی داده شد. حال قصد داریم تا با استفاده از دستور new Vue، رشته یا مقداری مشخص را در خروجی قرار دهیم. پس باید یک مشخصه را برای آن تعریف کرد که ما طبق مستندات فریم‌ورک، مشخصه‌ای را با نام el فراخوانی می‌کنیم:
<html>
    <body id="dotnettips">
       <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/1.0.27/vue.min.js">  
       new Vue({ 
           el: '#dotnettips',
           data: {
                name: 'dotnettips'
               }
            });
       </script>
    </body>
</html>
با استفاده از مشخصه el تعیین کردیم که کدهای برنامه برای کدام id در نظر گرفته شده‌اند. حال با استفاده از مقدار خاصیت name، مقادیر ما در خروجی چاپ خواهند شد.


استفاده از MVVM درون پروژه
به زبان ساده در معماری MVVM، یک مدل، یک view و یک viewmodel داریم که در مدل، کدهای JS و اطلاعاتی که قصد نمایش آن را داریم، قرار می‌دهیم. در واقع viewmodel نقش data building را خواهد داشت.

برای شروع، یک مدل جدید را نیاز داریم که بدین شکل باید فراخوانی کنیم.
 //new model 
var SampleData =( 
        name: 'dotnettips' 
)
در کد بالا ما یک مدل جدید ساخته‌ایم و یک ویژگی را به آن نسبت دادیم. حال لازم است تا ویوی جدیدی را برای نمایش آن ایجاد کنیم.
  • برای نمایش اطلاعات درون ویو جی اس باید از {{ }} استفاده کنید، تا ویژگی ساخته و فراخوانی شده را نمایش دهد.
<div id="dotnettips"> 
 Hello  {{ name }} 
</div>
مثال بالا، ویوی ما خواهد بود که ویژگی مورد نظر را در خروجی نمایش می‌دهد. حال، باید هردو را با viewmodel بهم متصل کنیم.
یک ویوی جدید را ایجاد می‌کنیم و با مشخصه el، ویژگی تعیین شده را به مدل خود متصل می‌کنیم.
new Vue({
  el:'#dotnettips',
  data: SampleData
})
 .یک نمونه از این مثال را از اینجا می‌توانید مشاهده کنید  
.به نمونه کد کامل زیر دقت بفرمائید
<html>  
    <body id="dotnettips">  
          
        <h3 id="dotnettips"> 
            Hello  {{ name }} 
        </h3>  
      
        <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/1.0.27/vue.min.js">
            
        </script>  
        <script type="text/javascript"> 
            new Vue({  
            el: '#dotnettips',  
                data:{  
                    name: 'dotnettips'  
                }  
            });  
        </script>  
        </body>  
</html>

مطالب
استفاده از bower در visual studio
اگر از آن دسته افرادی هستید که با پکیج‌های مختلف و پروژه‌های مختلف تحت کلاینت سر و کار دارید و همچنین اطلاعات چندانی نسبت به NodeJs ندارید (مثل خود من)، حتما به پروژه‌هایی در Github برخوردید که نیازمند نصب وابستگی‌ها از خط فرمان bower و یا npm هستند.
بعد از مطالعه‌ی مطلب آشنایی با bower این نیاز ایجاد شد تا در پروژه‌هایی که قرار است درون Visual Studio اجرا شوند، وابستگی‌های bower چگونه می‌توانند مدیریت شوند.
خوشبختانه Microsoft این امکان را ایجاد کرده تا شما بتوانید پروژه‌هایی را که وابستگی‌هایشان درون bower تعریف شده را نیز درون Visual Studio حل و فصل کنید. در ادامه تمامی این مراحل، قدم به قدم اضافه تشریح شده است.
قابل ذکر است که هر سه package manager معروف npm، bower و Nuget در ویژوال استدیو 2015 به صورت توکار موجود هستند. 
جزیات بیشتر در مستندات مایکروسافت


معرفی پکیج Bower

همانطور که در مقاله آشنایی با bower نیز اشاره شد، bower یک package manager برای تکنولوژی‌ها و کتابخانه‌های کلاینت است. این package manager بر روی Git اجرا می‌شود. همانطور که می‌دانید تمامی پکیج‌ها نیز از Git دریافت می‌شود.
اما حال اینکه چگونه می‌توان از این package manager در سمت Visual studio بدون نصب NodeJs و Git استفاده کرد، با پکیج توسعه داده شده Bower مایکروسافت رفع شده‌است.
جزئیات این پکیج را میتوانید در NuGet  مطالعه کنید.


شروع کار با Bower

برای آغاز، یک پروژه‌ی web Application ایجاد می‌کنیم. من Empty را انتخاب و ریسورس‌های MVC را هم اضافه کردم.
حال در بخش Package Manager Console دستور زیر را اجرا کنید:
Install-Package Bower
پس از نصب وابستگی‌ها و خود bower خروجی package manager console به صورت زیر خواهد بود:

مشاهده می‌کنید که فولدر .bin به پروژه‌ی شما اضافه شده است.

 حال درون صفحه‌ی cmd (توجه کنید cmd، نه package manager console) به آدرس پروژه (نه solution) با دستور زیر منتقل شوید:

cd <Project Location>

که به جای project location آدرس فایل پروژه را قرار می‌دهیم. شکل زیر نمایانگر این مسیر است:

با اجرای دستور زیر bower.json را به پروژه اضافه می‌کنیم:

bower init

مشاهده می‌کنید که پس از دستور bower init مواردی که قرار است درون bower قرار گیرد، مقدار دهی می‌شوند. من مقادیر را به صورت زیر (حالت‌های پیش فرض) تکمیل کردم:

حال باید تا اینجای کار یک فایل bower.json برای شما در روت پروژه ساخته شده باشد. حال بیایید اولین اسکریپت رفرنس را به پروژه اضافه نماییم. من قصد دارم تا با دستور زیر JQuery را به پروژه اضافه کنم:

bower install jquery

پکیج JQuery به صورت زیر دانلود می‌شود و در پوشه‌ی bower_component در روت پروژه قرار می‌گیرد.

به همین صورت شما می‌توانید تمامی نیازمندی‌های پروژه را از Git با استفاده از bower package manager دریافت کنید.

مطالب
نحوه استفاده از Text template ها در دات نت - قسمت اول
 یکی از امکانات کمتر شناخته شده در دات نت، امکان تولید اتوماتیک کد (Code Generator)، توسط فایلهایی به عنوان Text template می‌باشد. اگر چه فایلهای Text template با پسوند tt  از Visual Studio 2008 بطور آشکار به IDE اضافه گردیده‌اند، این امکان پیش از این نیز بصورت توکار در Visual Studio جهت تولید کد دات نت برای ابزارهایی مانند Dataset ، Report  و ... وجود داشته است. در حال حاضر Visual Studio بصورت توکار  از این امکان برای تولیدکلاسها و  کد‌های EntityFramework ( edmx ) ،dbml  ، Dataset  و ... استفاده می‌نماید. 
شما نیز با دانستن قواعد ساده کد نویسی برای Text template‌ها می‌توانید از این امکان برای تولید اتوماتیک کلاسها، HTML ، XML  و بطور کلی هر نوع فایل متنی استفاده نمایید. کاربردهای عملی Text template بیشتر برای تولید کد از روی دیتابیس و مثلا بر اساس فیلد‌های هر جدول و امثال آن می‌باشد. اما با کمی خلاقیت استفاده‌های بسیار زیاد و جالبی را می‌توانید از آن مشاهده نمایید.
کاربردهایی مانند : تولید خود کار فایل Config، تولید خودکار  Unit Test، تولید خودکار کلاسهای CRUD برای هر موجودیت در لایه Data، تولید خودکار SQL برای StoredProcedure ها، تولید خودکار Html و Js، تولید خودکار فرمهای ASPX و ... برای فرمهای ثابت و تکراری با فرآیند مشخص، تولید خودکار مستندات پروژه در قالب Word Document  , …  ،  تولید خودکار فایلهای Excel از اطلاعات خاص و تولید خودکار فرمهای xaml و .....

در این آموزش با قواعد اصلی نوشتن کد برای Text templateها آشنا می‌شویم و چند نمونه از کاربردهای آن را به عنوان مثال کاربردی مورد بررسی قرار خواهیم داد.
برای شروع قبل از توضیح در مورد قواعد کد نویسی Text template، یک فایل Text template ایجاد نمایید. برای ایجاد، از پنجره Add New Item  یک فایل Text template به پروژه اضافه نمایید:
 


توجه داشته باشید که نام فایل خروجی دقیقا هم نام با فایل tt مشخص شده خواهد بود. اما پسوند آن بسته به تنظیمات داخل آن متفاوت است. با اضافه کردن Text template داخل فایل، باید کد‌های زیر را مشاهده نمایید؛ در غیر این صورت آن را بنویسید:
 <#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".txt" #>
Language زبانی را مشخص می‌کند که می‌خواهید با آن داخل فایل Text template کد نویسی نمایید. تعیین آن برای کامپایل الزامی است.
Extension نیز پسوند فایل خروجی تولید شده را مشخص می‌نماید . 
اگر در ادامه متن Hello dotnettips را بنویسید و فایل را Save کنید، کنار فایل tt مذکور، یک فایل با همان نام و پسوند txt ایجاد خواهد شد که داخل آن نوشته است:
Hello dotnettips

برای ایجاد فایل خروجی همچنین میتوانید روی فایل tt  کلیک راست نموده و از منوی باز شده  Run Custom Tool  را انتخاب نمایید. توجه داشته باشید که در تنظیمات Custom Tool باید مقدار  TextTemplatingFileGenerator وجود داشته باشد:
 

خوب؛ برای ادامه، باید با قواعد کد نویسی در Text template آشنا شوید. جلسه بعدی قواعد کد نویسی T4  را بررسی خواهیم کرد.

مطالب
AOP و پردازش فراخوانی‌های تو در تو
هنگامی‌که از روش AOP استفاده می‌کنیم گاهی نیاز است متد تزیین‌شده را از متدی درون خود کلاس فراخوانی کنیم و می‌خواهیم aspectهای آن متد نیز فراخوانی شوند.

پیش‌نیازدوره‌ی AOP
(برای سادگی کار از تعریف attribute خودداری کردم. شما می‌توانید با توجه به آموزش، attributeهای دلخواه را به متدها بیافزایید).
Interface و کلاس پیاده‌سازی‌شده‌ی آن در لایه سرویس:
public interface IMyService 
{ 
  void foo();
  void bar();
}

public class MyService : IMyService
{
  public void foo()
  {
    Console.Write("foo");
    bar();
  }

  public void bar()
  {
    Console.Write("bar");
  }
}
نام متد در خروجی نوشته می‌شود. همچنین می‌خواهیم پیش از فراخوانی این متد‌ها، متنی در خروجی نوشته شود.

آماده‌سازی Interceptor
یک interceptor ساده که نام متد را در خروجی می‌نویسد.
//using Castle.DynamicProxy;

public class Interceptor : IInterceptor 
{
  public void Intercept(IInvocation invocation)
  {
    Console.WriteLine("Intercepted: " + invocation.Method.Name);
    invocation.Proceed();
  }
}

معرفی Interceptor به سیستم
همانند قبل:
//using System;
//using Castle.DynamicProxy;
//using StructureMap;

class Program
    {
        static void Main(string[] args)
        {
            ObjectFactory.Initialize(x =>
            {
                var dynamicProxy = new ProxyGenerator();
                x.For<IMyService>()
                 .EnrichAllWith(myTypeInterface => 
                                     dynamicProxy.CreateInterfaceProxyWithTarget(myTypeInterface, new Intercept()))
                 .Use<MyService>();
            });
 
            var myService = ObjectFactory.GetInstance<IMyService>();
            myService.foo();
        }
    }

انتظار ما این است که خروجی زیر تولید شود:
Intercepted foo
foo
Intercepted bar
bar
اما نتیجه این می‌شود که دلخواه ما نیست:
Intercepted foo
foo
bar

راه‌حل
برای حل این مشکل دو کار باید انجام داد:
1- متد تزیین‌شده باید virtual باشد.
public class MyService : IMyService
{
  public virtual void foo()
  {
    Console.Write("foo");
    bar();
  }

  public virtual void bar()
  {
    Console.Write("foo");
    bar();
  }
}
2- شیوه معرفی متد به سیستم باید به روش زیر باشد:
// جایگزین روش پیشین در متد Main
x.For<IMyService>()
                    .EnrichAllWith(myTypeInterface  => dynamicProxy.CreateClassProxy<MyService>(new Intercept()))                    
                    .Use<MyService>();

دلیل این مسئله به دو روش proxy برمی‌گردد که برای اطلاع بیشتر به مستندات پروژه Castle مراجعه کنید.
در این‌جا روش Inheritance-based به کار رفته است. در این روش، تنها متدهای virtual را می‌توان intercept کرد. در روش پیشین(Composition-based) برای همه‌ی متدها عملیات intercept انجام می‌شد (کلاس proxy پیاده‌سازی‌شده‌ی interface ما بود) که در این‌جا این‌گونه نیست و می‌تواند به سرعت برنامه کمک کند.
مطالب
دنیای چابک-قسمت اول
داخل وبلاگها و وب سایتهای فارسی زبان(مربوط به برنامه نویسی) که جستجو میکنیم شاهد  کلمه ای هستیم که تازه به چشممان میخورد:Agile(چابک). البته لازم به ذکر است این کلمه چیز جدیدی نیست و سابقه ای در حدود 10 سال دارد(February 2001 ).که جمعی از برنامه نویسان بیانیه ای را تحت عنوان چابک (Agile ) تهیه کردند که متن آن به شرح زیر است:

 ما با توسعه نرم افزار و کمک به دیگران در انجام آن . در حال کشف راه‌های بهتری برای توسعه نرم افزار هستیم. از این طریق باید دست یابیم به ارزش :
  1. افراد و تعاملات بالاتر از فرآیندها و ابزارها 
  2. نرم افزار کارکننده بالاتر از مستندات جامع
  3. مشارکت مشتری در انجام کار بالاتر از قرارداد کار
  4. پاسخگویی به تغییرات بالاتر از پیروی یک طرح
با وجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم .
که این بیانیه بر پایه 12 اصل(Agile  principles)
  1. بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند می‌باشد 
  2. استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند‌های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند
  3. تحویل زود به زود نرم‌افزار قابل استفاده دو، سه هفته یک بار تا دو ، سه ماه یک بار با ترجیح بر فاصله‌های زمانی کوتاه‌تر
  4. ذی نفعان کسب و کار و توسعه دهنده‌ها می‌بایست به صورت روزانه در طول پروژه با هم کار کنند
  5. پروژه‌ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم رابه آنها بدهید و از نیازهای آن‌ها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند
  6. کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است
  7. نرم افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است 
  8. فرآیند‌های چابک توسعه پایدار را ترویج می‌دهندحامیان مالی , توسعه دهندگان و کاربران باید بتوانند سرعت پیشرفت ثابتی را برای مدت نامحدودی حفظ کنند
  9. توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می‌شود
  10. سادگی -- هنر به حداکثر رساندن مقدار کار انجام نشده -- ضروری است
  11. بهترین معماری‌ها , نیاز مندی‌ها و طراحی‌ها از تیم‌های خود سازمانده پدید آور می‌شود
  12. در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می‌نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می‌نماید
متاسفانه در ایران حالا یا به علت سواد کم و یا به هر علتی از این بیانیه برداشتهایی متفاوت و غلط عده ای اونو به بازی تشبیه کردن و عده ای هم با اون کار میکنن ولی هیچکدوم از اصل‌های اونو رعایت نمیکنن و بعد که پروژه شکست خورد میگن:متدولوژی خوب نبود و ... .
وقتی کتاب Agile Principles, Patterns, and Practices in C# رو مطالعه میکنید به این نتیجه میرسید که بیشترین چیزی که تاکید داره روی ارتباطات هستش.
قصد دارم در قالب چند پست به شما این اصول رو معرفی کنم.
مطالب
قبل از رفع باگ، برای آن تست بنویسید

از دقت کردن در نحوه اداره پروژه‌های خوب و بزرگ در سطح دنیا، می‌توان به نکات آموزنده‌ای رسید. برای مثال NHibernate را درنظر بگیرید. این پروژه شاید روز اول کپی مطابق اصل نمونه جاوای آن بوده، اما الان از خیلی از جهات یک سر و گردن از آن بالاتر است. پشتیبانی LINQ را اضافه کرده، خودش Syntax جدیدی را به نام QueryOver ارائه داده و همچنین معادلی را جهت حذف فایل‌های XML به کمک امکانات جدید زبان‌های دات نتی مانند lambda expressions ارائه کرده. خلاصه این تیم، فقط یک کپی کار نیست. پایه رو از یک جایی گرفته اما سبب تحول در آن شده. از اهداف پروژه‌های سورس باز هم همین است: برای هر کاری چرخ را از صفر ابداع نکنید.

اگر به نحوه اداره کلی پروژه NHibernate‌ دقت کنید یک مورد مشهود است:
  • تمام گزارش‌های باگ بدون Unit test ندید گرفته می‌شوند.
  • از کلیه بهبودهای ارائه شده (وصله‌ها یا patch ها) بدون Unit test صرفنظر می‌شود.
  • از کلیه موارد جدید ارائه شده بدون Unit test هم صرفنظر خواهد شد.

بنابراین اگر در issue tracker این تیم رفتید و گفتید: «سلام، اینجا این مشکل هست»، خیالتان راحت باشد که ندید گرفته خواهید شد.

سؤال : چرا این‌ها اینطور رفتار می‌کنند؟!
- وجود Unit test دقیقا مشخص می‌کند که چه قسمت یا قسمت‌هایی به گزارش باگ شما مرتبط هستند. نیازی نیست حتما بتوانید یک خطا را با جملات ساده شرح دهید. این مساله خصوصا در پروژه‌های بین المللی حائز اهمیت است. ضعف زبان انگلیسی همه جا هست. همینقدر که توانسته‌اید برای آن یک Unit test بنویسید که مثلا در این عملیات با این ورودی،‌ نتیجه قرار بوده بشود 10 و مثلا شده 5 یا حتی این Exception صادر شده که باید کنترل شود، یعنی مشکل را کاملا مشخص کرده‌اید.
- وجود Unit tests ، انجام Code review و همچنین Refactoring را تسهیل می‌بخشند. در هر دو حالت یاد شده، هدف تغییر کارکرد سیستم نیست؛ هدف بهبود کیفیت کدهای موجود است. بنابراین دست به یک سری تغییرات زده خواهد شد. اما سؤال اینجا است که از کجا باید مطمئن شد که این تغییرات، سیستم را به هم نریخته‌اند. پروژه‌ی جاری چند سال است که در حال توسعه است. قسمت‌های زیادی به آن اضافه شده. با نبود Unit tests ممکن است بعضی از قسمت‌ها زاید یا احمقانه به نظر برسند.
- بهترین مستندات کدهای تهیه شده، Unit tests آن هستند. برای مثال علاقمند هستید که NHibernate را یاد بگیرید؟ هرچه می‌گردید مثال‌های کمی را در اینترنت در این زمینه پیدا می‌کنید؟ وقت خودتان را تلف نکنید! این پروژه بالای 2000 آزمون واحد دارد. هر کدام از این آزمون‌ها نحوه‌ی بکارگیری قسمت‌های مختلف را به نحوی کاربردی بیان می‌کنند.
- وجود Unit tests از پیدایش مجدد باگ‌ها جلوگیری می‌کنند. اگر آزمون واحدی وجود نداشته باشد، امروز کدی اضافه می‌شود. فردا همین کد توسط عده‌ای دیگر زاید تشخیص داده شده و حذف می‌شود! بنابراین احتمال بروز مجدد این خطا در آینده وجود خواهد داشت. با وجود Unit tests، فلسفه وجودی هر قسمتی از کدهای موجود پروژه دقیقا مشخص می‌شود و در صورت حذف آن‌، با اجرای آزمون‌های خودکار سریعا می‌توان به کمبودهای حاصل پی‌برد.

مطالب
سطح دوم cache در NHibernate

عموما دو الگوی اصلی caching در برنامه‌ها وجود دارند: cache aside و cache trough .
در الگوی cache trough ، سیستم caching داخل DAL (که در اینجا همان NHibernate است)، تعبیه می‌شود؛ مانند سطح اول caching که پیشتر در مورد آن صحبت شد. در این حالت cache از دید سایر قسمت‌های برنامه مخفی است و DAL به صورت خودکار آن‌را مدیریت می‌کند.
در الگوی cache aside ، کار مدیریت سیستم caching دستی است و خارج از NHibernate قرار می‌گیرد و DAL هیچگونه اطلاعی از وجود آن ندارد. در این حالت لایه caching موظف است تا هنگام به روز شدن بانک اطلاعاتی، اطلاعات خود را نیز به روز نماید. این لایه عموما توسط سایر شرکت‌ها یا گروه‌ها برنامه نویسی تهیه می‌شود.
NHibernate جهت سهولت کار با این نوع cache providers خارجی، نقاط تزریق ویژه‌ای را تدارک دیده است که به second level cache معروف است. هدف از second level cache فراهم آوردن دیدی کش شده از بانک اطلاعاتی است تا فراخوانی‌های کوئری‌ها به سرعت و بدون تماس با بانک اطلاعاتی صورت گیرد.
در حال حاضر (زمان نگارش این مطلب)، entity framework این لایه‌ی دوم caching یا به عبارتی دیگر، امکان تزریق ساده‌تر cache providers خارجی را به صورت توکار ارائه نمی‌دهد.
در NHibernate طول عمر second level cache در سطح session factory (یا به عبارتی طول عمر تمام برنامه) تعریف می‌شود و برخلاف سطح اولیه caching محدود به یک سشن نیست. در این حالت هر زمانیکه یک موجودیت به همراه ID منحصربفرد آن تحت نظر NHibernate قرارگیرد و همچنین سطح دوم caching نیز فعال باشد، این موجودیت در تمام سشن‌های برنامه بدون نیاز به مراجعه به بانک اطلاعاتی در دسترس خواهد بود (بنابراین باید دقت داشت که هدف از این سیستم، کار سریعتر با اطلاعاتی است که سطح دسترسی عمومی دارند).

در ادامه لیستی از cache providers خارجی مهیا جهت استفاده در سطح دوم caching را ملاحظه می‌نمائید:

  • AppFabric Caching Services : بر اساس Microsoft's AppFabric Caching Services که یک پلتفرم caching محسوب می‌شود (+). (این پروژه پیشتر به نام Velocity معروف شده بود و قرار بود تنها برای ASP.NET ارائه شود که سیاست آن به گونه‌ای جامع‌تر تغییر کرده است)
  • MemCache : بر اساس سیستم معروف MemCached تهیه شده است (+).
  • NCache : (+)
  • ScaleOut : (+)
  • Prevalence : (+)
  • SysCache : بر اساس همان روش آشنای متداول در برنامه‌های ASP.NET به کمک System.Web.Caching.Cache کار می‌کند؛ یا به قولی همان IIS caching
  • SysCache2 : همانند SysCache است با این تفاوت که SQL dependencies ویژه SQL Server را نیز پشتیبانی می‌کند.
  • SharedCache : یک سیستم distributed caching نوشته شده برای دات نت است (+).
این موارد و پروایدرها جزو پروژه‌ی nhcontrib در سایت سورس فورج هستند (+).


مطالب تکمیلی:



مطالب
banned.h

مطالبی توسط تیم Security Development Lifecycle مایکروسافت منتشر شده مبنی بر اینکه آن‌ها هم یک سری از توابع استاندارد زبان C را در کدهای جدید خود ممنوع کرده‌اند. مستندات آن‌را در مقاله زیر می‌توانید مشاهده نمائید:


اخیرا فایل header آن نیز مطابق آخرین به روز رسانی‌های مورد استفاده منتشر شده است:


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

جدیدترین تابعی که به این لیست اضافه شده ، تابع memcpy است که سر منشاء نقایص امنیتی زیر بوده است:
MS03-030 (DirectX)
MS03-043 (Messenger Service)
MS03-044 (Help and Support)
MS05-039 (PnP)
MS04-011 (PCT)
MS05-030 (Outlook Express)
CVE-2007-3999 (MIT Kerberos v5)
CVE-2007-4000 (MIT Kerberos v5)
...!

#pragma deprecated (memcpy, RtlCopyMemory, CopyMemory)
در این حالت زمانیکه کد خود را کامپایل نمائید با اخطار زیر مواجه خواهید شد:
warning C4995: 'memcpy': name was marked as #pragma deprecated
جایگزین آن تابع memcpy_s معرفی شده است و در این حالت کد قدیمی:
char dst[32];
memcpy(dst,src,len);
باید به کد زیر تبدیل گردد:
char dst[32];
memcpy_s(dst,sizeof(dst), src,len);
که یک آرگومان بیشتر دارد و آن هم اندازه‌ی بافر مقصد مورد نظر است.

برای مطالعه بیشتر
Please Join me in welcoming memcpy() to the SDL Rogues Gallery
Unsafe at any speed: Memcpy() banished in Redmond
Good hygiene and Banned APIs
A Look Inside the Security Development Lifecycle at Microsoft

مطالب
برنامه نویسی امن به زبان C

اگر سخنان بزرگان برنامه نویسی را مطالعه کرده باشید، یکی از موارد این بود:
" هیچگاه از gets و sprintf استفاده نکنید، در غیر اینصورت شیاطین به زودی به سراغ شما خواهند آمد! (FreeBSD Secure Programming Guidelines) "
به عبارت دیگر استفاده از توابع کتابخانه‌های استاندارد زبان C ، بدون ملاحظات لازم (یا همان برنامه نویسی کلاسیک به زبان C )، منشاء بسیاری از حملات Buffer overrun است، زیرا اکثر این توابع اندازه‌ی بافر یا رشته‌ی ورودی را بررسی نمی‌کنند.
برای رفع این مشکلات که هنوز که هنوز است قربانی می‌گیرد! ، The Safe C Library پدید آمده است. این کتابخانه بر اساس استاندارد ISO TR24731 تهیه گردیده و در آن یک سری توابع مکمل، جهت بالا بردن امنیت‌ برنامه‌های تهیه شده به زبان C مطابق استاندارد ISO/IEC 9899:1999 معرفی شده است.

برای مثال مطابق استاندارد ISO/IEC JTC1 SC22 WG14 N1172 ، تابع نا امن memcpy با تابع امن زیر باید جایگزین شود:
errno_t  memcpy_s(void *dest, rsize_t dmax, const void *src, rsize_t smax)

مستندات آن‌را در فایل safe_lib_html.tar پس از دریافت کتابخانه می‌توانید مشاهده نمائید.

همچنین اخیرا به عنوان مکمل این مجموعه، یک کتابخانه‌ی ریاضی امن نیز تهیه شده است.

پ.ن.
شبیه به همین مورد در اینترفیس پلاگین‌های IDA-Pro در نگارش‌های اخیر آن اعمال شده است و برنامه نویس را وادار می‌کند که از نمونه‌های معادل امن در آن محیط استفاده کند.
//pro.h
// We forbid using dangerous functions in IDA Pro
#ifndef USE_DANGEROUS_FUNCTIONS
#if defined(__BORLANDC__) && (__BORLANDC__ < 0x560 || __BORLANDC__ >= 0x580) // for BCB5 (YH)
#include <stdio.h>
#endif
#undef strcpy
#define strcpy dont_use_strcpy // use qstrncpy
#define stpcpy dont_use_stpcpy // use qstpncpy
#define strncpy dont_use_strncpy // use qstrncpy
#define strcat dont_use_strcat // use qstrncat
#define strncat dont_use_strncat // use qstrncat
#define gets dont_use_gets // use fgets
#define sprintf dont_use_sprintf // use qsnprintf
#define snprintf dont_use_snprintf // use qsnprintf
#define wsprintfA dont_use_wsprintf // use qsnprintf
#endif
برای مطالعه بیشتر: The Safe C Library

مطالب
اهمیت ارائه‌ی برنامه‌های دات نت به صورت release

یکی از مواردی که بعضی از همکاران هنگام ارائه برنامه‌های خود رعایت نمی‌کنند، تفاوت قائل نشدن بین حالت release و debug در زمان کامپایل پروژه، برای ارائه نهایی است.
هنگام استفاده از حالت release ، گزینه‌های بهینه سازی کامپایلر فعال شده و همچنین debug symbols از اسمبلی نهایی تولید شده حذف می‌گردد (بنابراین حجم اسمبلی نهایی نیز کمتر خواهد شد). لازم به ذکر است در حالت release ، میزان مصرف حافظه برنامه تولید شده نیز کمتر از حالت debug خواهد بود. گاهی از اوقات سرعت اجرای این دو حالت تا چندین برابر در بعضی از الگوریتم‌ها می‌توانند متفاوت باشند.
مطابق مستندات موجود، وجود debug symbols هیچگونه تاثیری بر روی کارآیی یک برنامه دات نت ندارند.
لازم به ذکر است که عمده بهینه‌سازی‌ها در دات نت توسط JIT compiler صورت می‌گیرد (تا 99 درصد) و نه توسط کامپایلر زبان مورد استفاده (به همین جهت است که عده‌ای اعتقاد دارند در نهایت و هنگام اجرا تفاوتی مابین زبان‌های مختلف دات نت وجود نخواهد داشت). بر روی JIT compiler نیز می‌توان تاثیر گذاشت و نحوه عملکرد آنرا تغییر داد (حتی بر روی یک اسمبلی کامپایل شده). برای مثال یک فایل ini کنار اسمبلی پروژه خود ایجاد کنید (xyz.ini که در اینجا xyz.exe نام فایل اجرایی برنامه است). محتویات این فایل می‌تواند به صورت زیر باشد:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

در اینجا می‌توان بهینه سازی را فعال و غیر فعال کرد و یا مطابق تنظیمات فوق برنامه را جهت دیباگ آماده نمود. (این روش با اسمبلی‌های ASP.Net کار نمی‌کند)
در دات نت فریم ورک 2 ، TrackingInfo مربوط به JIT compiler همواره تولید خواهد شد اما می‌توان بر روی بهینه سازی نهایی به صورت فوق نیز تاثیرگذار بود.

نکته:
اگر می‌خواهید هنگام مشاهده گزارش خطا، شماره سطر مورد نظر نیز در کدهای شما گوشزد ‌شود فایلهای pdb - program database تولید شده را هم ارائه دهید. حال شاید بخواهید هم برنامه را در حالت release ارائه دهید و هم pdb آن تولید شود، در این حالت باید خط فرمان کامپایل برنامه، با سوئیچ debug:pdbonly/ اجرا شود.
این مورد را در قسمت خواص پروژه، گزینه build و با کلیک بر روی دکمه advanced نیز می‌توان تنظیم نمود. (حالت پیش فرض release در VS.Net است)

خلاصه‌ی کلام: لطفا هنگام ارائه نهایی، گزینه release را از بالای صفحه در VS.Net انتخاب کنید. با تشکر!