نظرات مطالب
شروع به کار با AngularJS 2.0 و TypeScript - قسمت اول - نصب پیشنیازها
- شاید Angular 2 بهترین نباشد یا نشود، اما این مهم نیست. عوامل زیادی در انتخاب یک فریم ورک مؤثر هستند:

  • چه کسانی این فریم ورک را توسعه می‌دهند؟ گوگل. این مورد خیلی مهم است. در این بین شاید Aurelia مدرن‌تر به نظر برسد اما تیم آن سابقه‌ی خوبی در نگهداری محصولات قبلی آن ندارد. برای مثال Durandal آن‌ها به طور کامل رها شده و الان Aurelia را شروع کرده‌اند.
  • تیم Angular اینقدر شجاعت داشته که اقرار کند نگارش 1 آن مشکلات زیادی دارد و دست به یک بازنویسی کامل زده‌اند. باید دقت کرد که چقدر این‌کار برای یک تیم محبوب در وب مشکل است و قطعا نگارش 2 آن که با این حجم بالای اعتراضات عدم سازگاری با نگارش 1 آن تولید شده‌است، بسیاری از مشکلات نگارش قبلی را ندارد. همچنین همین مساله سازگاری آن‌را با نگارش‌های بعد از 2 نیز تضمین خواهد کرد. چون اینبار دست به یک طراحی مجدد زده‌اند و ... این طراحی مجدد خیلی برای آن‌ها گران تمام شده‌است (خصوصا از لحاظ حجم انتقادهای رسیده). بنابراین در آینده در زمینه سازگاری با نگارش‌های قبلی به شدت محتاط خواهند بود. این موردی است که استفاده کنندگان از ReactJS به زودی با آن مواجه خواهند شد.
  • گروه کاربری مصرف کنندگان آن. چه تعداد مقاله، ویدیوی آموزشی، انجمن رفع اشکال و امثال این‌ها را در مورد یک محصول می‌توانید پیدا کنید؟ قطعا AngularJS در این زمینه حرف اول را می‌زند.
  • Angular 2 بر مبنای استاندارد web component طراحی شده‌است که در دراز مدت نیز سبب برد AngularJS 2 خواهد شد و نیاز کمتر به بازنویسی‌های کلی.
  • Angular 2 برای کار با محصولات موبایل بهینه سازی شده‌است و مانند بوت استرپ 3 یک فریم ورک mobile first است.
  • استفاده‌ی از Type Script به عنوان زبان اول این پلتفرم (البته استفاده‌ی از آن اجباری نیست). این مساله در دراز مدت سبب تولید کدهایی با کیفیت بالاتر می‌شود. برای مثال الان ReactJS مخلوطی است از ES 5 و ES 6. اما AngularJS 2 تصمیم بهتری را اتخاذ کرده‌است. همین مساله سبب شده‌است که توسعه‌ی Type Script توسط مایکروسافت سرعت بیشتری پیدا کند.
  • داشتن امکانات توکار بیشتری نسبت به رقبا. برای مثال ReactJS یک کتابخانه است؛ اما AngularJS 2 یک فریم ورک کامل که تمام کتابخانه‌های جانبی رقبا را یکجا از روز اول دارد.

بنابراین آیا پس از ارائه‌ی نهایی Angular 2، ارزش یادگیری را دارد؟ بله؛ حتما. ابتدا (و هم اکنون) اعتراض‌های شدیدی در مورد عدم سازگاری آن با نگارش‌های قبلی وجود خواهد داشت و پس از مدتی همه آن‌را فراموش کرده و خودشان را وفق می‌دهند.  
مطالب
آموزش زبان Rust - قسمت 9 - Memory Management در Rust از طریق Ownership
Rust، یک زبان برنامه نویسی است که به دلیل ایمنی و عملکرد مشهور است و مفهوم مالکیت را برای مدیریت مؤثر حافظه معرفی می‌کند. با رعایت مجموعه‌ای از قوانین زمان کامپایل، توسعه دهندگان Rust می‌توانند مشکلات مربوط به حافظه را کاهش داده و کد خود را بهینه کنند. این مقاله، قوانین مالکیت، مشکلاتی را که حل می‌کند و مثال‌های مختلفی را برای نشان دادن کاربرد آن، بررسی می‌کند.


قوانین مالکیت  

  • هر مقدار در Rust دارای یک متغیر مرتبط به نام مالک آن است.
  • در هر لحظه فقط یک مالک می‌تواند وجود داشته باشد.
  • وقتی مالک از scope خارج می‌شود، مقدار مرتبط حذف می‌شود.

مالکیت در Rust به جلوگیری از چندین مشکل مدیریت حافظه کمک می‌کند، از جمله:
 
  • Memory/resource leaks
  • Double free
  • Use after free

هر مقدار در Rust دارای یک متغیر مرتبط به نام مالک آن است

به مثال زیر توجه کنید:
let s1 = String::from("Rust");
در این مورد، s1 یک اشاره‌گر است که در stack قرار دارد؛ در حالیکه مقدار "Rust" در heap قرار می‌گیرد.

 طبق قوانین مالکیت:
 
  • s1 مالک داده‌های ذخیره شده‌ی در heap است.
  • هنگامیکه s1 از scope خارج شود، داده‌های آن نیز پاک می‌شوند.

تلاش برای ارجاع به s1 پس از خارج شدن آن از scope، منجر به خطا می‌شود؛ زیرا مقدار آن از heap حذف شده و دیگر وجود ندارد.


مالکیت منحصر به‌فرد (در هر لحظه فقط یک مالک می‌تواند وجود داشته باشد)  


اگر برای انتقال s1 به s2 از کد زیر استفاده کنید:
let s2 = s1;
Rust به‌طور خودکار مقدار s1 را به s2 منتقل می‌کند و اطمینان حاصل می‌کند که تنها یک مالک در یک زمان حضور دارد.


Cloning Values

اگر بخواهیم بجای جابجایی مقدار، آن را تولید/نمونه‌سازی مجدد (cloning) کنیم، می‌توانیم با فراخوانی متد ()clone این‌کار را انجام دهیم:
let s2 = s1.clone();
اکنون s2 کپی خود را از مقدار s1 دارد.


Primitive Data و Cloning

در Rust، داده‌های اولیه به‌طور کامل در stack ذخیره می‌شوند و به‌طور پیش فرض clone می‌شوند. نمونه سازی مجدد این انواع، ارزان است و تفاوتی بین clone و moving وجود ندارد.


پاس دادن Variables به Functions

ارسال یک متغیر به یک تابع، همان تأثیری را دارد که یک متغیر را به متغیر دیگری اختصاص می‌دهیم. به عنوان مثال، اگر s1 را به یک تابع ارسال کنیم، مالک جدید رشته p1 است ( p1 نام آرگومان تابع است). برای رفع هرگونه خطایی که ممکن است به این دلیل  ایجاد شود، می‌توانیم s1 را clone کرده و به تابع ارسال کنیم.
سیستم مالکیت Rust، یک راه قدرتمند را برای مدیریت حافظه‌ی در زمان کامپایل فراهم می‌کند و از مشکلات رایج مرتبط با حافظه جلوگیری می‌کند. با درک و پیروی از قوانین مالکیت، می‌توانید کد ایمن‌تر و کارآمدتری را در Rust بنویسید. 
مطالب
مقدمه‌ای بر بازسازی کد (Refactoring)
بازسازی کد یا  Refactoring، یکی از روال‌های بسیار مهم در حفظ کیفیت نرم افزار است. انجام به موقع و مداوم این روال در یک پروژه نرم افزاری، اثرات بلند مدت بسیار مثبتی را برای آن خواهد داشت. این نوشتار مقدمه کوتاهی بر مفاهیم ابتدایی و سوالاتی مهم در این زمینه است. 

تعریف بازسازی کد

از نظر لغوی Refactoring به معنی «بازسازی» است و در منابع مهندسی نرم افزار، بازسازی کد به صورت زیر تعریف شده است: 
بازسازی ساختار درونی یک نرم افزار که باعث سهولت در درک آن و سادگی نگهداری آن می‌شود، بدون تغییر رفتار بیرونی آن  
چند نکته در تعریف بالا قابل توجه است: 
  • Refactoring بازسازی است، نه بازنویسی
  • بازسازی مربوط به ساختار درونی یک نرم افزار است؛ نه رفتاری که مشتریان از یک نرم افزار یا کامپوننت انتظار دارند
  • حاصل بازسازی باید سهولت درک کد و سادگی نگهداری آن باشد 


چرا کد را بازسازی کنیم؟ 

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

1-  طراحی نرم افزار را بهبود می‌بخشد 

زمانیکه کد به طور منظم بازسازی نشود، طراحی کلی آن رو به زوال خواهد رفت. هنگام ایجاد تغییر در بخشی از کد، ممکن است تنها هدف کوتاه مدت درست کار کردن آن بخش، مد نظر برنامه نویس باشد و به دلایل مختلفی مانند کمبود زمان، به نتایج بلند مدت آن تغییر توجه نشود. یکی از مزایای بازسازی کد، ایجاد تعادل بین تاثیرات کوتاه مدت و تاثیرات بلند مدت اعمال تغییرات بر روی کد است؛ به طوری که طراحی و تفکر کلی کد نویسی یک سیستم نرم افزاری، رو به بهبود برود. بهبود طراحی نرم افزار به درک کدهای آن، ایجاد آسان‌تر تغییرات و افزودن امکانات جدید، کمک بسیاری خواهد کرد. 

2-  درک کد را آسان‌تر می‌کند 

یکی از مزیت‌های کد خوب، درک آسان آن توسط سایر افراد است. هنگام بازسازی کد، با کدی مواجه هستیم که کار می‌کند، ولی نظم و طراحی درستی ندارد. درک آسان کد، یکی از کلیدی‌ترین نکات جهت سهولت نگهداری یک نرم افزار است.

 3- به یافتن خطاها کمک می‌کند 

یافتن تمامی باگ‌ها در زمان نوشتن یک کد، به نظر می‌رسد غیر ممکن باشد. اما اقدام به بازسازی کد می‌تواند قدمی باشد برای بازنگری و بهبود ساختار آن. زمانیکه ساختار کد خواناتر و منظم‌تر شد، یافتن برخی باگ‌ها نیز آسان‌تر خواهند شد. 

4-  سرعت توسعه را بالا می‌برد 

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

چه زمانی کد را بازسازی کنیم؟ 

روش‌های مختلفی برای زمان بندی انجام بازسازی کد مطرح است. یکی از پرکاربردترین زمان بندی‌ها برای انجام بازسازی کد به صورت زیر می‌باشد: 
  • زمانیکه امکان جدیدی اضافه می شود 
  • زمانیکه باگ یا اشکالی، رفع می شود 
  • زمان بازبینی کد یا Code review 
مطالب
کار با اسکنر در برنامه های تحت وب (قسمت اول)
در اکثر برنامه‌های سازمانی، مثل برنامه‌های مدیریت آرشیو اسناد، همواره این نیاز جزو خواسته‌های کاربران بوده که بتوانند به صورت مستقیم و از طریق تنها یک کلیک، تصویر مورد نظر را اسکن کرده و به صورت خودکار در برنامه وارد کنند؛ یعنی بدون اینکه نیاز باشد با استفاده از یک برنامه دیگر ابتدا تصویر را اسکن کرده و سپس در فرم وب، فایل اسکن شده را Browse کنند.
این نیاز اساسا به معنی دسترسی به سخت افزار کاربر از طریق مرورگر می‌باشد که به دلایل متعددی امکان پذیر نیست! مشکلات امنیتی ایجاد شده در این راه بسیار جدی است. اما خوشبختانه راههایی برای رسیدن به این هدف وجود دارند:

1- ActiveX : که به صورت native فقط در IE پشتیبانی می‌شود (در نسخه‌های جدیدتر IE نیاز به بروز رسانی پلاگین ActiveX controls می‌باشد) و برای استفاده‌ی از آن در مرورگر‌های Firefox و Chrome هم باید از پلاگین‌های جانبی روی هر مرورگر استفاده کرد که مثلا برای اجرای بر روی Firefox، باید افزونه‌ی IE Tab را نصب کرد که تنها کارش این است که سایت را از طریق موتور IE در پنجره‌ی فایرفاکس اجرا کند! که البته این مورد مثل این می‌ماند که سایت در IE باز شده باشد که ممکن است زیاد خوشایند نباشد؛ در غیر اینصورت باید پروژه را از اول بر مبنای اجرای بر روی IE طراحی و پیاده سازی کرد. در ضمن از مشکلات اجرای پلاگین نوشته شده توسط برنامه نویس در IE و نسخه‌های مختلف آن هم چشم پوشی می‌کنیم. یکی از مزیت‌های این روش نسبت به بقیه این هست که دانلود و نصب پلاگین مورد نیاز به صورت خودکار و توسط مرورگر انجام می‌شود.

2- استفاده از یک کامپوننت جانبی : مثل کامپوننت‌های LEADTOOLS که ابزارهای متنوع و SDK‌های بسیار قدرتمندی را برای اینکار و کارهای دیگر، مانند کار با اسکن تصاویر مغزی، پردازش تصویر، بارکد خوان‌ها، مدیریت اسناد و ...  فراهم کرده است. قیمت این ابزار بسیار زیاد است و در برخی موارد امکانات فراهم آورده بسیار بیشتر است از خواسته‌ی ما. این ابزار، هم در HTML & Javascript و هم در DotNet قابل استفاده است و مستندات نسبتا خوبی هم در این زمینه ارائه کرده است. همچنین کامپوننت Dynamsoft که باز هم غیر رایگان هست و قیمت بالایی نیز دارد.

اگر روال کار کامپوننت‌های بالا را مورد بررسی قرار دهید (از طریق اجرای Demo ها، اینجا و اینجا) متوجه خواهید شد که هر دو نیاز به نصب یک سرویس یا App سمت کلاینت جهت اجرای دستورات خود دارند. پس می‌شود اینطور نتیجه گرفت که انجام اینکار بدون اینکه چیزی سمت کاربر نصب شود، ممکن نیست و در هر دو، لینک نصب فایل exe سرویس برای دانلود قرار داده شده است. بر این اساس به راه حل سومی خواهیم رسید که خودمان این سرویس را جهت تعامل با اسکنر سمت کاربر طراحی و پیاده سازی نماییم.

اما چطور ممکن است که با اجرای یک فایل exe سمت کاربر (با این فرض که کاربر در یک دامین مطمئن قرار دارد و می‌شود درخواست نصب سرویس را نمود) این امکان را برای کاربر فراهم نمود که با یک کلیک در مرورگر، اسکنر به صورت خودکار اسکن را آغاز کرده و سپس تصویر حاصل را به یکی از کنترلر‌های ما در سمت سرور ارسال نماید؟

برای اینکار ما با دو صورت مساله مواجه هستیم؛ اول اینکه چطور تصویر را سمت کاربر اسکن کنیم و دوم اینکه چطور این تصویر را به سرور ارسال نماییم!
برای مساله‌ی اول از کتابخانه Windows Image Acquisition (WIA) استفاده خواهیم نمود که این کتابخانه به ما این امکان را میدهد تا با سخت افزارهایی که از TWAIN پشتیبانی می‌کنند، بتوانیم ارتباط برقرار نماییم.

برای مساله‌ی دوم هم نیاز به پیاده سازی یک WCF Service و اجرای آن (هاست کردن) در سمت کلاینت داریم. در واقع با صدا زدن متدهای این سرویس، از کتابخانه‌ی بالا استفاده کرده و اسکن را انجام می‌دهیم.

ادامه دارد...
مطالب
قابلیت های جدید VisualStudio.NET 2012 - قسمت سوم
اگر شما در زمینه طراحی وب سایت و برنامه‌های کاربردی تحت وب فعالیت دارید حتماً با ابزارهایی مانند Firebug آشنا هستید. معمولاً فرآیند بررسی مشکلات رابط کاربری و موضوعات مشابه آن بصورت زیر بوده است:
 
 

توجه داشته باشید که یک صفحه وب که در مرورگر به نمایش در می‌آید، برآیند فایل‌های جاوا اسکریپت، شیوه نامه ها، User control ها، صفحات ASPX و Master Page‌ها و ... است. افزون بر این آنچه در مرورگر نمایش داده می‌شود با چیزی که ما در محیط طراحی (Visual Studio.NET (Design View  می‌بینیم متفاوت است.
تمام مشکلات و سختی‌های بالا دست به دست هم دادند تا در نسخه جدید نرم افزار Visual Studio.NET شاهد ابزار جادویی با عنوان Page Inspector باشیم.
این ابزار بصورت Real-time امکان نگاشت (mapping) عناصر موجود در نتیجه نهایی برنامه وب را با سورس کد مهیا می‌کند. بدین معنا توسط Page Inspector با حرکت ماوس روی عناصر صفحه در مرورگر، Visual Studio.NET بخشی را که آن عنصر را تولید کرده است (User Control, Master Page, View, و ...) نمایش می‌دهد و شما می‌توانید بلافاصله پس از اعمال تغییرات جدید بر روی سورس کد، نتیجه را روی مرورگر ببنید. البته عکس این موضوع نیز صادق است و شما می‌توانید با حرکت در سورس کد، نتیجه بصری و عناصر HTML ی که در نتیجه تولید می‌شوند را مشاهده کنید. (عناصر متناظر به حالت Select در می‌آیند.)
 

 
از دیگر قابلیت‌های این ابزار نمایش CSS‌های متناظر هر عنصر است. شما می‌توانید هر یک از قوانینی که در Style هر عنصر تعریف کرده اید را فعال و یا غیر فعال کنید. همچنین امکان ویرایش آن‌ها وحود دارد.
همچنین از طریق گزینه File می‌توان لیست تمام فایل‌های سورس صفحه را مشاهده کرد.
 

 
با وجود چنین ابزاری یقیناً داشتن دو مانیتور برای برنامه نویسان و توسعه دهندگان وب کاملاً حیاتی است. چراکه Visual Studio.NET به شما این امکان را می‌دهد تا Page Inspector را در یک مانیتور و نمای سورس را در مانیتور دیگر به نمایش در آورید.
 
نکته:
جهت استفاده از تمام امکانات این ابزار باید دستور زیر را در تگ appsettings فایل web.config اضافه کنید:
 <add key="VisualStudioDesignTime:Enabled" value="true" />
پیشنهاد می‌کنم برای درک بهتر این ابزار و آشنایی با آن ویدئو مربوطه در کانال 9  را از دست ندهید.
 
مطالب دوره‌ها
دریافت قالب WpfFramework.vsix و نحوه نصب و راه اندازی آن
فایل قالب پروژه دوره جاری را از آدرس ذیل می‌توانید دریافت کنید:

نصب ابتدایی آن بسیار ساده است و نکته خاصی ندارد.
پس از نصب، یکبار VS.NET را بسته و سپس باز کنید. این قالب جدید، ذیل قسمت پروژه‌های ویندوز مرتبط با ویژوال سی شارپ، ظاهر خواهد شد:


در این حال اگر یک پروژه جدید را آغاز کنید، این قالب تدارک دیده شده، لایه‌ها و قسمت‌های مختلف را به صورت خودکار اضافه خواهد کرد:



نکته مهم! برنامه کامپایل نمی‌شود!

به عمد، جهت کاهش حجم قالب دریافتی فوق، فایل‌های باینری آن پیوست نشده‌اند. وگرنه باید بالای 30 مگابایت را دریافت می‌کردید که واقعا نیازی نیست.
اما اگر به هر پروژه داخل Solution دقت کنید، فایل متنی packages.config آن نیز پیوست شده است. به کمک این فایل‌ها به سادگی می‌توان تمام وابستگی‌ها را از طریق NuGet بازیابی کرد.
برای این منظور ابتدا به اینترنت متصل شده (مهم) و سپس بر روی Solution کلیک راست کرده و گزینه فعال سازی Restore کلیه بسته‌های نیوگت را انتخاب کنید.


پس از اینکار، آخرین نگارش NuGet.exe از اینترنت دریافت و به پروژه اضافه می‌شود:


اکنون اگر Solution را Build کنید، اولین کاری که صورت خواهد گرفت، دریافت کلیه وابستگی‌ها از سایت NuGet است. اندکی تامل کنید تا اینکار تمام شود.
پس از پایان کار دریافت، پوشه packages در کنار فایل sln پروژه ایجاد شده، تشکیل می‌شود.
یکبار وجود آن‌را بررسی کنید.


اکنون اگر برنامه را Build کنید احتمالا پیغام می‌دهد که Fody را نمی‌تواند پیدا کند با اینکه دریافت شده و در پوشه packages موجود است. هر زمان، هر پیغام خطایی در مورد Fody مشاهده کردید، فقط یکبار VS.NET را بسته و باز کنید. مشکل حل می‌شود!

تنها کاری که پس از بازسازی پوشه packages بهتر است صورت گیرد (اختیاری است البته)، صدور دستور ذیل در خط فرمان پاور شل است:
 PM> Update-Package
با این دستور، دریافت کامل مجددی از اینترنت صورت نمی‌گیرد؛ مگر اینکه به روز رسانی جدیدی را یافت کند. در سایر حالات از کش داخل سیستم اطلاعات را دریافت می‌کند.
پس از اینکار، نیاز است یکبار VS.NET را بسته و مجددا باز کنید (مهم) تا تمام وابستگی‌ها به درستی بارگذاری شوند. خصوصا بسته Fody که کار AOP را انجام می‌دهد. در غیر اینصورت موفق به Build پروژه نخواهید شد.

بنابراین به صورت خلاصه:
الف) یکبار گزینه فعال سازی Restore کلیه بسته‌های نیوگت را انتخاب کنید.
ب) پروژه را Build کنید تا وابستگی‌ها را از سایت NuGet دریافت کند.
ج) دستور Update-Package را اجرا نمائید (اختیاری).
ج) VS.NET را پس از سه مرحله فوق، یکبار بسته و باز کنید.

در کل بسته‌های مورد استفاده به این شرح هستند:
PM> Install-Package MahApps.Metro -Pre 
PM> Install-Package MahApps.Metro.Resources 
PM> Install-Package EntityFramework
PM> Install-Package structuremap
PM> Install-Package PropertyChanged.Fody
PM> Install-Package MvvmLight 
PM> Install-Package Microsoft.SqlServer.Compact

یک نکته جانبی
فید NuGet در VS.NET به Https تنظیم شده است. اگر دسترسی به Https برای شما به کندی صورت می‌گیرد فقط کافی است مسیر فید آن‌را در منوی Tools، گزینه‌ی Options، ذیل قسمت Package manager یافته و به http://nuget.org/api/v2 تغییر دهید؛ یعنی به Http خالی، بجای Https؛ تا سرعت دریافت بسته‌های NuGet مورد نظر افزایش یابند.



اجرای پروژه و برنامه

پس از این مراحل و Build موفقیت آمیز پروژه، برنامه را اجرا کنید. در اولین بار اجرای برنامه به صورت خودکار بانک اطلاعاتی به همراه ساختار جداول تشکیل می‌شوند. اما ... با خطای زیر مواجه خواهید شد:
 The path is not valid. Check the directory for the database. [ Path = D:\...\bin\Debug\Db\db.sdf ]
علت این است که در فایل app.config پروژه ریشه برنامه :
<connectionStrings>
    <clear/>
    <add name="MyWpfFrameworkContext"
         connectionString="Data Source=|DataDirectory|\Db\db.sdf;Max Buffer Size=30720;File Mode=Read Write;"
         providerName="System.Data.SqlServerCE.4.0" />
  </connectionStrings>
مسیر تشکیل بانک اطلاعاتی به پوشه db کنار فایل اجرایی برنامه تنظیم شده است. این پوشه db را در پوشه bin\debug ایجاد کرده و سپس برنامه را اجرا کنید.


برای ورود به برنامه از نام کاربری Admin و کلمه عبور 123456 استفاده نمائید.
این کاربر پیش فرض در کلاس MyWpfFrameworkMigrations لایه داده‌های برنامه، توسط متد addRolesAndAdmin اضافه شده است.


خوب! تا اینجا با نحوه نصب و راه اندازی این قالب جدید آشنا شدیم. در قسمت‌های بعد، به جزئیات ارتباطات و نحوه استفاده از آن به عنوان پایه یک کار و پروژه جدید، خواهیم پرداخت.




به روز رسانی 1.1
جهت سازگاری با EF 6 ، StructureMap 3 و همچنین VS 2013، پروژه به روز شد: WpfFrmwork_1.1.zip

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

کامنت‌های اضافی یا توضیح واضحات   

کامنت‌هایی که بالای متد‌ها یا کلاس‌ها مشاهده می‌شوند و توصیف کننده کاری هستند که آن کلاس یا عضو آن انجام می‌دهد. هنگام توصیف یک کلاس یا عضوی از آن حتما باید توجه داشت که توضیح واضحات انجام نشود. به طور مثال کد زیر را در نظر بگیرید:  
// Computes the employee salary  
public int CalculateSalary(int emplyeeId)  
{  
      return int.MaxValue;  
}
امضای متد به اندازه کافی نشان دهنده این است که چه کاری را انجام می‌دهد. پس نیازی به کامنت بالای آن وجود نخواهد داشت. در این مثال، کامنت معمولی بالای متد استفاده شده است. در مثال مذکور این امکان وجود داشت که  از مدل xml documentation استفاده شود؛ ولی در اصل موضوع تفاوتی ایجاد نمی‌کرد.   

زمانیکه می‌توان از متغیر یا متد استفاده کرد 

زمانیکه در بدنه متدها با محاسبه یا چک‌هایی روبرو هستیم که به اندازه کافی واضح نیستند، یکی از اولین راهکارهایی که به نظر می‌رسد، نوشتن کامنت برای آنها است. به طور مثال در متدی که مسئول پاک کردن یک حساب، در یک نرم افزار حسابداری است، چکی به صورت زیر داشته باشیم:  
// checks that an account is used or not and checks that an account has childs or not  
if (voucherLineRepository.Any(dd => dd.PostingAccountId == accountId)   
                || accountRepository.Any(dd => dd.ParentId == accountId]))  
{  
       return;  
}
یک راه بهتر برای انجام این کار، ایجاد دو متد است که نشان دهنده موضوع مورد چک باشند. به صورت زیر:  
if (UsedInVouchers(accountId) || HasChilds(accountId))  
{  
      return;  
}
حتی می‌توان یک قدم جلوتر رفت و به طور کلی منطق بررسی این که حساب قابل حذف هست یا نه را هم به متد دیگری منتقل کرد. مانند کد زیر:  
if (!CanDeleteAccount(accountId)) {  
    return;  
}  
...
public bool CanDeleteAccount(int accountId)  
{  
    if (UsedInVouchers(accountId) || HasChilds(accountId))  
    {  
        return false;  
    }  
    return true;  
}


کدهای کامنت شده  

کدهای کامنت شده حسی از ترس و عدم اطمینان را به مشاهده کننده انتقال می‌دهند. کسی که با کد کامنت شده مواجه شده نمی‌تواند اطمینان داشته باشد که کد به طور کلی حذف شده، یا موقتا حذف شده و یا باید از حالت کامنت در بیاید یا خیر؟ 
کسی که آن را کامنت کرده نیز از کار خود اطمینان نداشته! اگر اطمینان داشت که کامنت شدن کد مورد نظر هیچ اختلالی را ایجاد نخواهد کرد و کسی نیازی به آن نمی‌داشت و حتما آن را به طور کلی حذف می‌کرد.   


کامنت‌های اجباری 

در بعضی پروژه‌ها، تیم برنامه نویسی تصمیم می‌گیرد که به صورت اجباری بالای هر متد و عضوی از کلاسها کامنت‌هایی برای روشن‌تر شدن موضوع ایجاد کنند. نتیجه‌ای که این کار خواهد داشت، ایجاد یک سری کامنت‌های تکراری و اضافه است. کامنت‌هایی که در خیلی مواقع حتی کپی نام عضو مورد نظر هستند. در بعضی از پروژه‌هایی که به صورت فریم ورک هستند، به دلیل ذات پروژه شاید نوشتن توضیحات اضافه تصمیم خوبی باشد. ولی در بیشتر موارد نوشتن کامنت‌های اجباری نتیجه خوبی نخواهد داشت.  


لاگ تغییرات  

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

کامنت در زبان‌های برنامه نویسی امکان خوبی است؛ به شرطی که به خوبی مورد استفاده قرار گیرد. 
مطالب
Reflection در ES6
در زبان‌های برنامه‌نویسی مانند سی‌شارپ و یا جاوا می‌توانیم از Reflection جهت خواندن متادیتاها استفاده کنیم. به عنوان مثال امکان تعریف پراپرتی و یا متدها و حتی تایپ‌هایی در زمان اجرا را در اختیارمان قرار می‌دهد. اما از آنجائیکه جاوا اسکریپت یک زبان داینامیک است، این قابلیت کمتر مورد توجه قرار گرفته است. در جاوا اسکریپت حین کار با کلاس‌ها و اشیاء، ممکن است نیاز داشته باشید تا از اعضای یک کلاس کوئری بگیرید و یا اینکه یک سری پراپرتی و متدهایی را در زمان اجرا به اشیاء‌تان اضافه کنید و یا مواردی از این دست.
تا قبل از ES 6 می‌توانستیم به این صورت به اعضای یک کلاس دسترسی داشته باشیم:
var person = {
    name: 'Sirwan',
    family: 'Afifi',
    doWork: function () {
        //....
    }
};

for (var prop in person) {
    console.log(prop); 
}
همانطور که مشاهده می‌کنید، توسط سینتکس for...in می‌توانیم به اعضای person دسترسی داشته باشیم. همچنین برای دسترسی به مقادیر هر کدام از اعضای آن می‌توانستیم از bracket syntax استفاده کنیم:
for (var prop in person) {
    console.log(person[prop]); 
}
لازم به ذکر است می‌توانستیم از متدهایی همانند Array.isArray, Object.getOwnPropertyDescriptor و حتی Object.keys نیز جهت دسترسی به اعضای پنهان یک شیء استفاده کنیم. اکنون قابلیت توکاری با نام Reflect این امکان را به ES 6 اضافه کرده است تا تمام اعمال فوق را به راحتی انجام داد.

Reflect
همانطور که عنوان شد توسط API جدیدی با نام Reflect، می‌توانیم به سادگی اعمال مربوط به Reflection را انجام دهیم. به عنوان مثال برای دسترسی به اعضای شیء person با استفاده از این API می‌توانیم به این صورت عمل کنیم:
var person = {
    name: 'Sirwan',
    family: 'Afifi',
    doWork: function () {
        //....
    }
};

for (let prop of Reflect.enumerate(person)) {
    console.log(`the value for ${prop} is ${person[prop]}`); 
  
}
در کد فوق از متد enumerate استفاده شده است، این متد یک پارامتر target را از ورودی می‌پذیرد. در واقع target همان شیءایی است که می‌خواهید پراپرتی‌های آن را پیمایش کنید. همچنین مقدار بازگشتی این متد یک iterator می‌باشد. مفهوم iterator نیز خیلی ساده است. به زبان ساده، امکان پیمایش درون یک کالکشن را در اختیارمان قرار می‌دهد. نکته‌ی دیگری که در کد فوق وجود دارد، استفاده از سینتکس for..of است، این سینتکس شبیه به for...in عمل می‌کند، با این تفاوت که در اینجا به جای پیمایش درون یکسری keys، درون values پیمایش می‌کنیم. در نتیجه برای پیمایش iterators باید از این سینتکس استفاده شود.

متدهای شیء Reflect
در ادامه تعدادی از متدهای شیء Reflect را مشاهده می‌کنید:
Reflect.get(target, name, [receiver])

Reflect.set(target, name, value, [receiver])

Reflect.has(target, name)

Reflect.apply(target, receiver, args)

Reflect.construct(target, args)

Reflect.getOwnPropertyDescriptor(target, name)

Reflect.defineProperty(target, name, desc)

Reflect.getPrototypeOf(target)

Reflect.setPrototypeOf(target, newProto)

Reflect.deleteProperty(target, name)

Reflect.enumerate(target)

Reflect.preventExtensions(target)

Reflect.isExtensible(target)

Reflect.ownKeys(target)
تعدادی از متدهای فوق خیلی مشابه متدهای Object هستند؛ با این تفاوت که متدهای فوق اطلاعات بهتری را بر می‌گردانند. به عنوان مثال متد Reflect.defineProperty در صورت ایجاد شدن یک پراپرتی جدید، مقدار true را برمی‌گرداند:
var yay = Reflect.defineProperty(target, 'foo', { value: 'bar' })
if (yay) {
  // yay!
} else {
  // oops.
}
اگر همین کار را با استفاده از متد Object.defineProperty انجام می‌دادیم می‌بایست کد را درون بلاک try/catch می‌نوشتیم:
try {
  Object.defineProperty(target, 'foo', { value: 'bar' })
  // yay!
} catch (e) {
  // oops.
}
به عنوان یک مثال دیگر، قبلاً برای حذف یک پراپرتی از یک شیء از کلمه کلیدی delete به اینصورت استفاده می‌کردیم:
var target = { foo: 'bar', baz: 'wat' }
delete target.foo
console.log(target)
// <- { baz: 'wat' }
اما با کمک متد Reflect.deleteProperty به راحتی می‌توانیم یک پراپرتی را حذف کنیم:
var target = { foo: 'bar', baz: 'wat' }
let isDeleted = Reflect.deleteProperty(target, 'foo')
console.log(isDeleted );
// true
در این‌حالت همانند متد Reflect.defineProperty، در صورت موفقیت‌آمیز بودن عمل حذف، مقدار true برگردانده می‌شود.
برای مشاهده‌ی لیست کامل متدهای فوق می‌توانید به اینجا مراجعه کنید. همچنین می‌توان با مراجعه به قسمت Browser compatibility وضعیت پشتیبانی هر کدام را در مرورگرهای مختلف مشاهده کرد.

نکاتی که در حین کار کردن با Reflect باید در نظر بگیرید:
  • این شیء فاقد متد [[Construct]] می‌باشد. یعنی نمی‌تواند همراه با کلمه‌ی کلیدی new مورد استفاده قرار گیرد.
  • همچنین نمی‌توان آن را همانند یک تابع فراخوانی کرد.
  • تمام متدهای آن به صورت استاتیک تعریف شده‌اند (همانند شیء Math).
مطالب
CoffeeScript #15

قسمت‌های اصلاح نشده

در ادامه‌ی مطالب قسمت قبل، به برخی دیگر از معایب طراحی در جاوااسکریپت که در CoffeeScript نیز اصلاح نشده‌اند می‌پردازیم.

استفاده از parseInt

تابع ()parseInt در جاوااسکریپت، در صورتیکه یک مقدار رشته‌ای را به آن ارسال کنید و پایه‌ی مناسب آن را تعیین نکنید، نتایج غیره منتظره‌ای (unexpected) را باز می‌گرداند . برای مثال:

# Returns 8, not 10!
parseInt('010') is 8
البته ممکن است شما این کد را در مرورگر خود تست کنید و مقدار 10 را باز گرداند؛ اما این برای همه‌ی مرورگرها یکسان نیست. برای اطمینان از مقدار بازگشتی صحیح، همیشه پایه‌ی آن را تعیین کنید.
# Use base 10 for the correct result
parseInt('010', 10) is 10
دقت کنید این چیزی نیست که CoffeeScript بتواند برای شما انجام دهد؛ شما فقط یادتان باشد که همیشه پایه‌ی صحیح را در موقع استفاده‌ی از ()parseInt تعریف کنید.

Strict mode


Strict mode یکی از قابلیت‌های ECMAScript 5 است که به شما اجازه می‌دهد تا یک برنامه یا تابع جاوااسکریپت را در محیطی محدود اجرا کنید. این محدودیت موجب نمایش بیشتر خطاها و هشدارها نسبت به حالت نرمال می‌شود و به توسعه دهندگان این امکان را می‌دهد تا از نوشتن کدهای غیر قابل بهینه سازی برای اشتباهات رایج جلوگیری کنند.
به عبارت دیگر Strict mode باعث کاهش اشکالات، افزایش امنیت، بهبود عملکرد و حذف برخی از سختی‌های استفاده از ویژگی‌های زبان می‌شود.
در حال حاضر Strict mode، در مرورگرهای زیر پشتیبانی می‌شود:

  • Chrome >= 13.0
  • Safari >= 5.0
  • Opera >= 12.0
  • Firefox >= 4.0
  • IE >= 10.0

با این حال، Strict mode به طور کامل با مرورگرهای قدیمی سازگار است.


تغییرات Strict mode

بیشتر تغییرات Strict mode مربوط به syntax جاوااسکریپت بوده است:

  • خطا در پروپرتی‌ها و نام آرگومان‌های تابع تکراری
  • خطا در عدم استفاده‌ی صحیح از delete
  • خطا در زمان دسترسی به arguments.caller و arguments.callee (به دلایل عملکرد)
  • استفاده از عمگر with سبب بروز خطای نحوی می‌شود
  • متغیرهای خاص مانند undefined که قابل نوشتن نیستند
  • معرفی کلمات کلیدی رزرو شده مانند implements, interface, let, package, private, protected, public, static و yield.

با این حال، برخی از رفتارهای زمان اجرای Strict mode نیز تغییر کرده است:

  • متغییرهای سراسری به صورت صریح و روشن هستند (کلمه کلیدی var نیاز است). مقدار سراسری this نیز به صورت undefined است.
  • eval نمی‌تواند متغیر جدیدی را در حوزه‌ی محلی خود تعریف کند.
  • بدنه‌ی هر تابع باید قبل از استفاده تعریف شده باشد (قبلا گفتم که در جاوااسکریپت شما می‌توانید قبل از تعریف تابع آن را فراخوانی کنید).
  • آرگومان‌ها تغییر ناپذیر هستند.

CoffeeScript در حال حاضر بسیاری از الزامات Strict mode را پیاده سازی کرده‌است مانند: همیشه از کلمه کلیدی var برای تعریف متغیر استفاده می‌کند؛ اما فعال کردن Strict mode در برنامه‌های CoffeeScript نیز بسیار مفید خواهد بود. در واقع CoffeeScript بر روی انطباق برنامه‌ها با Strict mode در زمان کامپایل را، در برنامه‌های آینده خود دارد.


استفاده از Strict mode

برای فعال کردن بررسی محدودیت، کد و توابع خود را با این رشته شروع کنید:
->
  "use strict"

  # ... your code ...
فقط با استفاده از رشته "use strict". به مثال زیر توجه کنید:
do ->
  "use strict"
  console.log(arguments.callee)
اجرای قطعه کد بالا درحالت strict mode، سبب بروز خطای syntax می‌شود؛ در حالیکه در حالت معمول این کد به خوبی اجرا می‌شود.
Strict mode دسترسی به arguments.callee و arguments.caller، که تاثیر بدی را بر روی عملکرد کد شما دارند، حذف می‌کند و استفاده‌ی از آنها سبب بروز خطا می‌شود.

در مثال زیر در حالت strict mode سبب بروز خطای TypeError می‌شود، اما در حالت نرمال به خوبی اجرا شده و یک متغیر سراسری را ایجاد می‌کند.
do ->
  "use strict"
  class @Spine
دلیل این رفتار این است که در Strict mode متغیر this به صورت undefined است؛ در حالیکه در حالت نرمال، this به شیء window اشاره می‌کند. راه حل این مشکل تعریف متغیرهای سراسری به صورت صریح به شیء window است.
do ->
  "use strict"
  class window.Spine
در حالیکه توصیه می‌شود که همیشه Strict mode فعال باشد، اما Strict mode هیچ یک از ویژگی‌های جدید جاوااسکریپت را که هنوز آماده نیست، فعال نمی‌کند و در واقع به علت بررسی بیشتر کدهای شما در زمان اجرا، باعث کاهش سرعت می‌شود.
شما می‌توانید در زمان توسعه برنامه جاوااسکریپت خود Strict mode را فعال کنید و در زمان انتشار، بدون Strict mode برنامه‌ی خود را منتشر کنید.

JavaScript Lint 

JavaScript Lint یک ابزار بررسی کیفیت کدهای جاوااسکریپت است و اجرای برنامه‌ی شما از طریق این راه عالی باعث بهبود کیفیت و بهترین شیوه‌ی کد نویسی می‌شود. این پروژه براساس ابزار JSLint است. شما می‌توانید چک لیست سایت JSLint را که شامل موضوعاتی است که باید آن‌ها در نظر داشته باشید، مانند متغیرهای سراسری، فراموش کردن نوشتن سمی کالن، کیفیت ضعیف عمل مقایسه را نام برد.

خبر خوب این است که CoffeeScript تمام موارد گفته شده‌ی در چک لیست را انجام می‌دهد. بنابراین کد تولیدی CoffeeScript با JavaScript Lint کاملا سازگار است. در واقع ابزار coffee از lint ،option پشتیبانی می‌کند.

coffee --lint index.coffee
  index.coffee: 0 error(s), 0 warning(s)

مطالب
آشنایی با CLR: قسمت هشتم
در قسمت پنجم در مورد ابزار Ngen کمی صحبت کردیم و در این قسمت هم در مورد آن صحبت هایی خواهیم کرد. گفتیم که این ابزار در زمان نصب، اسمبلی‌ها را کامپایل می‌کند تا در زمان اجرا JIT وقتی برای آن نگذارد. این کار دو مزیت به همراه دارد:
  1. بهینه سازی زمان آغاز به کار برنامه
  2. کاهش صفحات کاری برنامه: از آنجا که برنامه از قبل کامپایل شده، فراهم کردن صفحه بندی از ابتدای کار امر چندان دشواری نخواهد بود؛ لذا در این حالت صفحه بندی حافظه به صورت پویاتری انجام می‌گردد. شیوه‌ی کار به این صورت است که اسمبلی‌ها به چندین پروسه‌ی کاری کوچک‌تر تبدیل شده تا صفحه بندی هر کدام جدا صورت گیرد و محدوده‌ی صفحه بندی کوچکتر می‌شود. در نتیجه کمتر نقصی در صفحه بندی دیده شده یا کلا دیده نخواهد شد. نتیجه‌ی کار هم در یک فایل ذخیره می‌گردد که این فایل می‌تواند نگاشت به حافظه شود تا این قسمت از حافظه به طور اشتراکی مورد استفاده قرار گیرد و بدین صورت نیست که هر پروسه‌ای برای خودش قسمتی را گرفته باشد.
موقعی که اسمبلی، کد IL آن به کد بومی تبدیل می‌شود، یک اسمبلی جدید ایجاد شده که این فایل جدید در مسیر زیر قرار می‌گیرد:
%SystemRoot%\Assembly\NativeImages_v4.0.#####_64
نام دایرکتوری اطلاعاتی شامل نسخه CLR و اطلاعاتی مثل اینکه برنامه بر اساس چه نسخه‌ای 32 یا 64 بیت کامپایل شده است.

معایب
احتمالا شما پیش خود می‌گویید این مورد فوق العاده امکان جالبی هست. کدها از قبل تبدیل شده‌اند و دیگر فرآیند جیت صورت نمی‌گیرد. در صورتیکه ما تمامی امکانات یک CLR مثل مدیریت استثناءها و GC و ... را داریم، ولی غیر از این یک مشکلاتی هم به کارمان اضافه می‌شود که در زیر به آنها اشاره می‌کنیم:

عدم محافظت از کد در برابر بیگانگان: بعضی‌ها تصور می‌کنند که این کد را می‌توانند روی ماشین شخصی خود کامپایل کرده و فایل ngen را همراه با آن ارسال کنند. در این صورت کد IL نخواهد بود ولی موضوع این هست اینکار غیر ممکن است و هنوز استفاده از اطلاعات متادیتا‌ها پابرجاست به خصوص در مورد اطلاعات چون reflection و serialization‌ها . پس کد IL کماکان همراهش هست. نکته‌ی بعدی اینکه انتقال هم ممکن نیست؛ بنا به شرایطی که در مورد بعدی دلیل آن را متوجه خواهید شد.

از سینک با سیستم خارج میشوند: موقعیکه CLR، اسمبلی‌ها را به داخل حافظه بار می‌کند، یک سری خصوصیات محیط فعلی را با زمانیکه عملیات تبدیل IL به کد ماشین صورت گرفته است، چک می‌کند. اگر این خصوصیات هیچ تطابقی نداشته باشند، عملیات JIT همانند سابق انجام می‌گردد. خصوصیات و ویژگی‌هایی که چک می‌شوند به شرح زیر هستند:
  • ورژن CLR: در صورت تغییر، حتی با پچ‌ها و سرویس پک ها.
  • نوع پردازنده: در صورت تغییر پردازنده یا ارتقا سخت افزاری.
  • نسخه سیستم عامل : ارتقاء با سرویس پک ها.
  • MVID یا Assemblies Identity module Version Id: در صورت کامپایل مجدد تغییر می‌کند.
  • Referenced Assembly's version ID: در صورت کامپایل مجدد اسمبلی ارجاع شده.
  • تغییر مجوزها: در صورتی که تغییری نسبت به اولین بار رخ دهد؛ مثلا در قسمت قبلی در مورد اجازه نامه اجرای کدهای ناامن صحبت کردیم. برای نمونه اگر در همین اجازه نامه تغییری رخ دهد، یا هر نوع اجازه نامه دیگری، برنامه مثل سابق (جیت) اجرا خواهد شد.
پی نوشت: در آپدیت‌های دات نت فریم ورک به طور خودکار ابزار ngen صدا زده شده و اسمبلی‌ها مجددا کمپایل و دخیره میشوند و برنامه سینک و آپدیت باقی خواهد ماند. 

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

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

برای بسیاری از برنامه‌های کلاینت که تجربه‌ی startup طولانی دارند، مایکروسافت ابزاری را به نام Managed Profile Guided Optimization Tool یا MPGO .exe دارد. این ابزار به تحلیل اجرای برنامه شما پرداخته و بررسی می‌کند که در زمان آغازین برنامه چه چیزهایی نیاز است. اطلاعات به دست آمده از تحلیل به سمت ngen فرستاده شده تا کد بومی بهینه‌تری تولید گردد. موقعیکه شما آماده ارائه برنامه خود هستید، برنامه را از طریق این تحلیل و اجرا کرده و با قسمت‌های اساسی برنامه کار کنید. با این کار اطلاعاتی در مورد اجرای برنامه در داخل یک پروفایل embed شده در اسمبلی، قرار گرفته و ngen موقع تولید کد، این پروفایل را جهت تولید کد بهینه مطالعه خواهد کرد.

در مقاله‌ی بعدی در مورد FCL صحبت‌هایی خواهیم کرد.