وحید نصیری وحید نصیری
مطالب
وادار کردن خود به کامنت نوشتن

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

برای این تنظیم، ابتدا به برگه خواص پروژه مراجعه کنید. سپس در قسمت Build تنظیمات زیر را اعمال نمائید:
Treat warnings as errors را بر روی All قرار دهید.
در ذیل آن، در قسمت Output‌، گزینه‌ی XML Documentation file را تیک بزنید.

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

مطالب مرتبط:



‫۱۲ سال و ۱۰ ماه قبل، یکشنبه ۱۸ دی ۱۳۹۰، ساعت ۲۰:۵۵
علیرضا آرانی علیرضا آرانی
مطالب
دستیابی به HttpContext در Blazor Server
در Asp.net core توسط IHttpContextAccessor  می‌توان به‌راحتی به HttpContext در هرجای برنامه دسترسی داشت و اطلاعات مورد نیاز را از قبیل نام کاربری، کوکی‌ها، توکن‌ها و ... به دست آورد. اما در Blazor Server برای استفاده از این قبیل اطلاعات توصیه شده‌است که اکیدا از IHttpContextAccessor در هرجایی از برنامه استفاده نشود؛ زیرا هیچ تضمینی وجود ندارد که در حالت‌های مختلف، مقدار HttpContext معتبر باشد. برای کسب اطلاعات بیشتر در این باب می‌توانید به Blazor and shared state و Accessing HttpContext.Items fails on WebKit browsers مراجعه نمایید. درکل Blazor Server خارج از چارچوب خط لوله ASP.NET Core اجرا می‌شود. اما اگر به هر دلیلی به دنبال اطلاعات خاصی از HttpContext در کامپوننت‌ها باشیم چطور؟ آیا هیچ راهی وجود ندارد؟
برای دستیابی به HttpContext در Blazor Server فقط باید در زمان رندر شدن Host.cshtml_ مقدار(های) مدنظر را از HttpContext دریافت کرده و داخل متغیری ذخیره کنیم و در ادامه‌ی برنامه از آن متغیر در قالب Cascading Parameters در کامپوننت‌ها استفاده نماییم.
روش کار به اینصورت است که ابتدا فایل Host.cshtml_ را به شکل زیر اصلاح می‌کنیم. در اینجا ما به دنبال اطلاعات توکن access_token می‌باشیم.
 @{ 
        var token = await HttpContext.GetTokenAsync("access_token");
    }

 <component type="typeof(App)" render-mode="ServerPrerendered" param-AccessToken="token" />
همانطور که ملاحظه می‌نمایید اطلاعات توکن access_token را داخل متغیر token ریخته و آن‌را به param-AccessToken کامپوننت منتسب می‌کنیم.
سپس به فایل App.razor رفته و متغیر AccessToken را به عنوان یک Cascading Value تعریف می‌کنیم. به شکل زیر:
<CascadingValue Name="AccessToken" Value="AccessToken">
    <CascadingAuthenticationState>
        <Router AppAssembly="@typeof(Program).Assembly">
            <Found Context="routeData">
                <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
            </Found>
            <NotFound>
                <LayoutView Layout="@typeof(MainLayout)">
                    <p>Sorry, there's nothing at this address.</p>
                </LayoutView>
            </NotFound>
        </Router>
    </CascadingAuthenticationState>
</CascadingValue>
@code{
    [Parameter]
     public string AccessToken { get; set; }
}
در پایان، هر کامپوننتی که نیاز به مقدار AccessToken را داشته باشد فقط کافیست آن‌را به عنوان یک Cascade Parameter تعریف کند. برای مثال یک کامپوننت را به نام ShowToken.razor ایجاد می‌کنیم و کدهای آن‌را مانند زیر قرار می‌دهیم.
@page "/showtoken"

<p>This is part of the access token @(AccessToken != null ? AccessToken.Substring(0,30) : "(null)")</p>


@code {
    [CascadingParameter(Name = "AccessToken")] public string AccessToken { get; set; }
}
بدیهی است که اطلاعات دیگری نیز می‌توان از HttpContext استخراج کرد. برای مثال شاید شما بخواهید که در یک کامپوننت، بدون استفاده از <AuthorizeView> نام کاربری شخصی که لاگین کرده است را به دست آورید (برای زمانی که از اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity استفاده می‌کنید). تنها کافیست بخش Host.cshtml_ را مانند زیر تغییر دهید.
var userName = await HttpContext.User.Identity.Name;
یا برای مثال اگر به دنبال اطلاعات یک کوکی خاص می‌باشید:
var khasCookie = HttpContext.Request.Cookies["khas"];
‫۲ سال قبل، سه‌شنبه ۲۶ مهر ۱۴۰۱، ساعت ۲۲:۴۰
مهدی پایروند مهدی پایروند
نظرات اشتراک‌ها
10 فرمان مخصوص برنامه‌ نویس‌های بی‌ ادعا
10 فرمان برنامه نویسان(خلاصه)
  1. بفهم و متوجه شو که تو اشتباه خواهی کرد: نکته اینست که قبل از اینکه وارد محصولتان شوند باید پیدایشان کنی.
  2. تو خود کدت نیستی: بیاد داشته باش که نکته اصلی مرور کدها پیدا کردن مشکلات است.
  3. مهم نیست که چقدر "کاراته" میدونی، همیشه یکی بیشتر میدونه: چنین فردی در صورتیکه شما بخواهید چند حرکت جدید به شما میاموزد.
  4. بدون مشاوره کدهایتان را بازنویسی نکنید: بین حل مشکلات کد‌ها و بازنویسی کدها مرز مشخصی وجود دارد.
  5. راه حل افرادی که کمتر از شما میدانند تحمل، صبر و احترام است: افراد غیر فنی که با برنامه نویسان برخورد دارند فکر میکنند که بهترین نقش اول را در گروه پر از گریه کن دارند.
  6. تنها ثابت جهان تغییر است: آغوشتان را باز کنید و لبخند بزنید. به تغییرات در مقررات و یلتفرمها یا ابزارها مثل یک چالش نگاه کنید.
  7. تنها مرجع واقعی، دانش است نه موقعیت: دانش قدرت می‌آورد و قدرت احترام، پس اگر در محیطتان احترام میخواهید دانش بجوئید.
  8. برای چیزی که اعتقاد دارید بجنگید ولی شکست را به آرامش بپذیرید: بفهمید که بعضی وقتها ایده‌های شما رد میشوند. حتی اگر در آخر حق با شما بود، انتقام نگیرید و نگوئید"من که گفته بودم".
  9. "مردی در تاریکی"  نباشید: یک شخص کدنویس در یک دفتر تاریک نباشید که فقط برای خرید یک نوشابه ظاهر یشود. بدور از تماس، روشنایی، و بدون کنترل .
  10. از کدها نقد کنید نه از کدنویس، و با کدنویس مهربان باشید نه با کدها: تا حد زیادی نظرات سازنده و مثبت برای بهبود کدها ارائه بدهید. 
‫۹ سال و ۸ ماه قبل، شنبه ۲۵ بهمن ۱۳۹۳، ساعت ۱۴:۴۲
مهدی سعیدی فر مهدی سعیدی فر
اشتراک‌ها
کتاب آموزش زبان برنامه نویسی Erlang

سخت افزارهای جدید به طور فزاینده ای همروند (parallel) شده اند، بنابراین زبان‌های برنامه نویسی باید از همزمانی پشتیبانی کنند یا محکوم به مرگ هستند. نقل قولی از استیو جابز: راهی که شرکت‌های ساخت پردازشگر در پیش گرفته اند این هست که هسته‌های بیشتر و بیشتر اضافه کنند، اما کسی نمی‌داند که چگونه برای آن‌ها برنامه بنویسید. منظورم دو، بله؛ چهار، نه واقعا؛ هشت؛ کلا فراموشش کنید.

خب استیو اشتباه می‌کرده است؛ الان ما می‌دانیم که چگونه برای پردازشگرهای چند هسته ای برنامه بنویسیم. ما برنامه هایمان را با Erlang می‌نویسیم و هرچقدر که بر تعداد هسته‌ها افزوده شود برنامه‌ی ما نیز سریع‌تر از قبل کار می‌کند.

Erlang از همان ابتدا برای برنامه نویسی سیستم‌های همزمان، توزیع پذیر، تحمل پذیر بودن خطا (fault-tolerant)، مقیاس پذیر (scalable)، نرم و بلادرنگ طراحی شده بود. سیستم‌های نرم بلادرنگ به مانند سیستم‌های ارتباطات تلفنی، سیستم‌های بانکی و ... که در آن‌ها تعدا دفعات پاسخ گویی سریع بسیار با اهمیت است. سیستم‌های مبتنی بر Erlang در مقیاس عظیمی مستقر شده اند و بخش‌های قابل توجهی از شبکه ارتباطات تلفن همراه دنیا را کنترل می‌کنند.

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

کتاب آموزش زبان برنامه نویسی Erlang
‫۱۰ سال و ۱۲ ماه قبل، جمعه ۲۴ آبان ۱۳۹۲، ساعت ۱۴:۳۸
احمد نواصری احمد نواصری
مطالب
اجرای سرویسهای NodeJS در ASP.NET Core
 این نوشتار در مورد نحوه اجرای سرویس‌های NodeJS در ASP.NET Core می‌باشد؛ زیرا تعداد زیادی از Package‌های سورس باز و با کیفیت بالا به فرم Node package manager یا به اصطلاح NPM موجود و قابل دریافت می‌باشند. NPM بزرگترین مخزن دنیا از لحاظ وجود بسته‌های نرم افزاری سورس باز است. به همین جهت بسته Microsoft.AspNetCore.NodeServices، جهت استفاده از این بسته‌ها در برنامه‌های ASP.NET Core ارائه شده‌است. برای استفاده از سرویسهای Node ابتدا باید ارجاعی را به بسته Microsoft.AspNetCore.NodeServices داشته باشید. برای این منظور میتوانید از دستور dotnet add package Microsoft.AspNetCore.NodeServices استفاده نمایید. البته اگر از آخرین نسخه NET Core. استفاده میکنید، لزومی به ارجاع به بسته فوق نمی‌باشد و به صورت پیشفرض در بسته Microsoft.AspNetCore.All موجود است.
سپس متد ()ConfigurationServices را جهت اضافه کردن میان افزار Node Services به خط لوله درخواستها (request pipeline) ویرایش میکنیم:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddNodeServices();
}

حال میتوانید به وهله‌ای از اینترفیس INodeServices، از طریق تزریق وابستگی‌ها دسترسی داشته باشید. اینترفیس INodeServices یک Api می‌باشد و مشخص می‌کند که کدام قطعه از کد NET. میتواند کد جاوااسکریپتی را که در محیط Node اجرا می‌شود، فراخوانی کند. همچنین میتوانید از خاصیت FromServices برای دریافت وهله‌ای از اینترفیس INodeServices در اکشن خود استفاده نمایید.
public async Task<IActionResult> Add([FromServices] INodeServices nodeServices)
{
    var num1 = 10;
    var num2 = 20;
    var result = await nodeServices.InvokeAsync<int>("AddModule.js", num1, num2);
    ViewData["ResultFromNode"] = $"Result of {num1} + {num2} is {result}";
    return View();
}

سپس کد جاوااسکریپتی متناظر با تابعی را که توسط متد InvokeAsync فراخوانی میشود، به صورت زیر می‌نویسیم:
module.exports = function(callback, num1, num2) { 
  var result = num1 + num2;
  callback(null, result); 
};
دقت کنید که نام فایل جاوااسکریپت باید همنام با پارامتر اول متد InvokeAsync و تعداد پارامترهای تابع باید مساوی با پارامترهایی باشد که به تابع فراخوانی شده جاوااسکریپت ارسال می‌شود.

حال بیاییم مثالی دیگر را مرور کنیم. میخواهیم از صفحه وب درخواستی، عکسی را تهیه کنیم. بدین منظور از کتابخانه url-to-image استفاده میکنیم. برای نصب آن دستور npm install --save url-to-image را در خط فرمان تایپ میکنیم.

بعد از اتمام نصب این بسته، متدی را برای دریافت اطلاعات ارسالی این کتابخانه تدارک میبینیم.

 [HttpPost]
        public async Task<IActionResult> GenerateUrlPreview([FromServices] INodeServices nodeServices)
        {
            var url = Request.Form["Url"].ToString();
            var fileName = System.IO.Path.ChangeExtension(DateTime.UtcNow.Ticks.ToString(), "jpeg");
            var file = await nodeServices.InvokeAsync<string>("UrlPreviewModule.js", url, System.IO.Path.Combine("PreviewImages", fileName));
            return Content($"/Home/Download?img={fileName}");
        }

        public IActionResult Download()
        {
            var image = Request.Query["img"].ToString();
            var fileName = System.IO.Path.Combine("PreviewImages", image);
            var isExists = System.IO.File.Exists(fileName);

            if (isExists)
            {
                Response.Headers.Add($"Content-Disposition", "attachment; filename=\"" + image + "\"");
                var bytes = System.IO.File.ReadAllBytes(fileName);
                return File(bytes, "image/jpeg");
            }
            else
            {
                return NotFound();
            }
        }

سپس متد UrlPreviewModule.js را به صورت زیر مینویسیم:

var urlToImage = require('url-to-image');
module.exports = function (callback, url, imageName) {
    urlToImage(url, imageName).then(function () {
        callback(null, imageName);
    }).catch(function (err) {
        callback(err, imageName);
    });
};


سرویس‌های Node به توسعه دهندگان ASP.NET Core امکان استفاده از اکوسیستم NPM را که دارای قابلیتهای فراوانی می‌باشد، میدهد. 

‫۶ سال و ۷ ماه قبل، چهارشنبه ۲۳ اسفند ۱۳۹۶، ساعت ۱۶:۱۵
سالار ربال سالار ربال
مطالب
NET Just-In-Time Optimization.
هدف از توابع خطی(Inline)
استفاده از توابع، مقداری بر زمان اجرای برنامه می‌افزاید؛ هرچند که این زمان بسیار کم و در حد میلی ثانیه است، اما باری را بر روی برنامه قرار می‌دهد و علت این تاخیر زمانی این است که در فراخوانی و اعلان توابع، کامپایلر یک کپی از تابع مورد نظر را در حافظه قرار می‌دهد و در فراخوانی تابع، به آدرس مذکور مراجعه می‌کند و در عین حال آدرس موقعیت توقف دستورات در تابع main را نیز ذخیره می‌کند تا پس از پایان تابع، به آدرس قبل برگردد و ادامه‌ی دستورات را اجرا کند. در نتیجه این آدرس دهی‌ها و نقل و انتقالات بین آنها بار زمانی را در برنامه ایجاد می‌کند که در صورت زیاد بودن توابع در برنامه و تعداد فراخوانی‌های لازم، زمان قابل توجهی خواهد شد.
یکی از تکنیک‌های بهینه که برای کاهش زمان اجرای برنامه توسط  کامپایلر‌ها استفاده  می‌شود استفاده از  توابع خطی (inline) است. این امکان در زبان C با عنوان توابع ماکرو(Macro function) و در ++C با عنوان توابع خطی (inline function) وجود دارد.
در واقع توابع خطی به  کامپایلر پیشنهاد می‌دهند، زمانی که سربار فراخوانی تابع بیشتر از سربار بدنه خود متد باشد، برای کاهش هزینه و زمان اجرای برنامه از تابع به صورت خطی استفاده کند و یک کپی از بنده‌ی تابع را در قسمتی که تابع ما فراخوانی شده است، قرار دهد که مورد آدرس دهی از میان خواهد رفت!

نمونه ای از پیاده سازی این تکنیک در زبان ++C : 
inline type name(parameters) 
{
    ...
}

بررسی متدهای خطی در سی شارپ
به مثال زیر توجه کنید:
قسمت‌های getter و setter مربوط به پراپرتی‌ها سربار اضافی بر کلاس Vector می‌افزایند. این موضوع شاید آنچنان مسئله‌ی مهمی نباشد. ولی فرض کنید این پراپرتی‌ها به شکل زیر داخل حلقه‌ای طولانی قرار گیرند. اگر با استفاده از یک پروفایلر زمان اجرای برنامه را زیر نظر بگیرید، خواهید دید که بیش از 90 درصد آن صرف فراخوانی‌های متد‌های بخش‌های get , set پراپرتی‌ها است. برای این منظور باید مطمئن شویم که فراخوانی این متد‌ها، به صورت خطی صورت می‌گیرد!
 public class Vector
  {
    public double X { get; set; }
    public double Y { get; set; }
    public double Z { get; set; }

    // ...
  }
برای این منظور آزمایشی را انجام می‌دهیم. فرض کنید کلاسی را به شکل زیر داشته باشیم:
public class MyClass
  {
    public int A { get; set; }
    public int C;
  }
و برای استفاده از آن به شکل زیر عمل کنیم:
  static void Main()
{
    MyClass target = new MyClass();
    int a = target.A;
    Console.WriteLine("A = {0}", a);
    int c = target.C;
    Console.WriteLine("C = {0}", c);
  }
بعد از دیباگ برنامه و مشاهده‌ی کدهای ماشین مربوط به آن خواهیم دید که متد مربوط به getter پراپرتی A به صورت خطی فراخوانی نشده است: 
            int a = target.A;
  0000003e  mov         ecx,edi
  00000040  cmp         dword ptr [ecx],ecx
  00000042  call        dword ptr ds:[05FA29A8h]
  00000048  mov         esi,eax
  0000004a  mov         dword ptr [esp+4],esi
             int c = target.C;
  00000098  mov         edi,dword ptr [edi+4]
    MyClass.get_A() looks like this:
  00000000  push        esi
  00000001  mov         esi,ecx
  00000003  cmp         dword ptr ds:[03B701DCh],0
  0000000a  je          00000011
  0000000c  call        76BA6BA7
  00000011  mov         eax,dword ptr [esi+0Ch]
  00000014  pop         esi
  00000015  ret

چه اتفاقی افتاده است؟
 کامپایلر سی شارپ در زمان کامپایل، کد‌های برنامه را به کد‌های IL تبدیل می‌کند و JITکامپایلر، این کد‌های IL را گرفته و  کد ساده‌ی ماشین را تولید می‌کند. لذا به دلیل اینکه JIT با معماری پردازنده آشنایی کافی دارد، مسئولیت تصمیم گیری اینکه کدام متد به صورت خطی فراخوانی شود برعهده‌ی آن است. در واقع این JIT است که تشخیص می‌دهد که آیا فراخونی متد به صورت خطی مناسب است یا نه و به صورت یک معاوضه کار بین خط لوله دستورالعمل‌ها و کش است.
اگر شما برنامه‌ی خود را با  (F5) و همگام با دیباگ اجرا کنید، تمام بهینه سازی‌های JIT که Inline Method هم یکی از آنهاست، از کار خواهند افتاد. برای مشاهده‌ی کد بهینه شده باید با بدون دیباگ (CTRL+F5) برنامه خود را اجرا کنید که در آن صورت مشاهده خواهید کرد، متد getter  مربوط به پراپرتی A به صورت خطی استفاده شده است.
  int a = target.A;  
00000024  mov         ebx,dword ptr [edi+0Ch]


JIT محدودیت هایی برای فراخونی به صورت خطی متد‌ها دارد :
  1.  متد هایی که حجم کد IL آنها بیشتر از 32 بایت است.
  2. متد‌های بازگشتی.
  3. متدهایی که با اتریبیوت MethodImpl علامتگذاری شدند و MethodImplOptions.NoInlining  اعمال شده بر آن
  4. متدهای virtual
  5. متدهایی که دارای کد مدیریت خطا هستند
  6. Methods that take a large value type as a parameter 
  7. Methods with complicated flowgraphs 
برای اینکه در سی شارپ به کامپایلر اعلام کنیم تا متد مورد نظر به صورت خطی مورد استفاده قرار گیرد، در دات نت 4.5 توسط اتریبیوت MethodImpl و  اعمال  MethodImplOptions.AggressiveInlining که یک نوع شمارشی است می‌توان این کار را انجام داد. مثال:
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
class Program
{
    const int _max = 10000000;
    static void Main()
    {
         // ... Compile the methods.
        Method1();
        Method2();  
        int sum = 0;
        var s1 = Stopwatch.StartNew();
        for (int i = 0; i < _max; i++)
           {
              sum += Method1();
           }
         s1.Stop();
         var s2 = Stopwatch.StartNew();
         for (int i = 0; i < _max; i++)
             {
                sum += Method2();
             }
         s2.Stop();
         Console.WriteLine(((double)(s1.Elapsed.TotalMilliseconds * 1000000) /
        _max).ToString("0.00 ns"));
        Console.WriteLine(((double)(s2.Elapsed.TotalMilliseconds * 1000000) /
      _max).ToString("0.00 ns"));
        Console.Read();
      }
      static int Method1()
      {
         // ... No inlining suggestion.
         return "one".Length + "two".Length + "three".Length +
              "four".Length + "five".Length + "six".Length +
              "seven".Length + "eight".Length + "nine".Length +
               "ten".Length;
    }
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    static int Method2()
    {
        // ... Aggressive inlining.
        return "one".Length + "two".Length + "three".Length +
           "four".Length + "five".Length + "six".Length +
           "seven".Length + "eight".Length + "nine".Length +
            "ten".Length;
    }
}
Output
7.34 ns    No options
0.32 ns    MethodImplOptions.AggressiveInlining
در واقع با اعمال این اتریبیوت، محدودیت شماره یک مبنی بر محدودیت حجم کد IL مربوط به متد، در نظر گرفته نخواهد شد .

 مطالعه بیشتر:
‫۹ سال و ۷ ماه قبل، چهارشنبه ۵ فروردین ۱۳۹۴، ساعت ۱۵:۰۰
آرمان فرقانی آرمان فرقانی
مطالب
مفاهیم برنامه نویسی ـ مروری بر کلاس و شیء
من قصد دارم در قالب چند مطلب برخی از مفاهیم پایه و مهم برنامه نویسی را که پیش نیازی برای درک اکثر مطالب موجود در وب سایت است به زبان ساده بیان کنم تا دایره افرادی که می‌توانند از مطالب ارزشمند این وب سایت استفاده کنند وسعت بیشتری پیدا کند. لازم به توضیح است از آنجا که علاقه ندارم اینجا تبدیل به نسخه فارسی MSDN یا کتاب آنلاین آموزش برنامه نویسی شود این سری آموزش‌ها بیشتر شامل مفاهیم کلیدی خواهند بود.
این مطلب به عنوان اولین بخش از این سری مطالب منتشر می‌شود.

هدف این نوشته بررسی جزییات برنامه نویسی در رابطه با کلاس و شیء نیست. بلکه دریافتن چگونگی شکل گرفتن ایده شیء گرایی و علت مفید بودن آن است.

مشاهده مفاهیم شیء گرایی در پیرامون خود

حتماً در دنیای برنامه نویسی شیء گرا بارها با کلمات کلاس و شیء روبرو شده اید. درک صحیح از این مفاهیم بسیار مهم و البته بسیار ساده است. کار را با یک مثال شروع می‌کنیم. به تصویر زیر نگاه کنید.
 



در سمت راست بخشی از نقشه یک ساختمان و در سمت چپ ساختمان ساخته شده بر اساس این نقشه را می‌بینید. ساختمان همان شیء است. و نقشه ساختمان کلاس آن است چراکه امکان ایجاد اشیائی که تحت عنوان ساختمان طبقه بندی (کلاس بندی) می‌شوند را فراهم می‌کند. به همین سادگی. کلاس‌ها طرح اولیه، نقشه یا قالبی هستند که جزییات یک شی را توصیف می‌کنند.
حتماً با من موافق هستید اگر بگویم:
  • در نقشه ساختمان نمی‌توانید زندگی کنید اما در خود ساختمان می‌توانید.
  • از روی یک نقشه می‌توان به تعداد دلخواه ساختمان ساخت.
  • هنگامی که در یک ساختمان زندگی می‌کنید نیازی نیست تا دقیقاً بدانید چگونه ساخته شده و مثلاً سیم کشی یا لوله کشی‌های آن چگونه است! تنها کافیست بدانید برای روشن شدن لامپ باید کلید آن را بزنید.
  • ساختمان دارای ویژگی هایی مانند متراژ، ضخامت دیوار، تعداد پنجره و ابعاد هر یک و ... است که در هنگام ساخت و بر اساس اطلاعات موجود در نقشه تعیین شده اند.
  • ساختمان دارای کارکرد هایی است. مانند بالا و پایین رفتن آسانسور و یا باز و بسته شدن درب پارکینگ. هر یک از این کارکرد‌ها نیز بر اساس اطلاعات موجود در نقشه پیاده سازی و ساخته شده اند.
  • ساختمان تمام اجزای لازم برای اینکه از آن بتوانیم استفاده کنیم و به عبارتی در آن بتوانیم زندگی کنیم را در خود دارد.
در محیط پیرامون ما تقریباً هر چیزی را می‌توان در یک دیدگاه شیء تصور کرد. به عبارتی هر چیزی که بتوانید به صورت مستقل در ذهن بیاورید و سپس برخی ویژگی‌ها و رفتارها یا کارکردهای آن‌را برشمارید تا آن چیز را قابل شناسایی کند شیء است. مثلاً من به شما می‌گویم موجودی چهار پا دارد، مو... مو... می‌کند و شیر می‌دهد و ... . شما خواهید گفت گاو! و نمی‌گویید گربه. چرا؟ چون توانستید در ذهن خود موجودیتی را به صورت مستقل تصور کنید و از روی ویژگی‌ها و رفتارش آن‌را دقیقاً شناسایی کنید.
سوال: کلاس یا نقشه ایجاد گاو چیست؟ اگر از من بپرسید خواهم گفت طرح اولیه گاو هم ممکن است وجود داشته باشد البته در اختیار خداوند و با سطح دسترسی ملکوت!
اتومبیل، تلویزیون و ... همگی مثال هایی از اشیاء پیرامون ما در دنیای واقعی هستند که حتماً می‌توانید کلاس یا نقشه ایجاد آن‌ها را نیز بدست آورید و یا ویژگی‌ها و کارکرد‌های آن‌ها را برشمارید.

مفاهیم شیء گرایی در مهندسی نرم افزار

مفاهیمی که تاکنون در مورد دنیای واقعی مرور کردیم همان چیزی است که در دنیای برنامه نویسی ـ به عقیده من دنیای واقعی‌تر از دنیای واقعی ـ با آن سر و کار داریم. علت این امر آن است که اصولاً ایده روش برنامه نویسی شیء گرا با مشاهده محیط پیرامون ما به وجود آمده است.
برای نوشتن برنامه جهت حل یک مسئله بزرگ باید بتوان آن مسئله را به بخش‌های کوچکتری تقسیم نمود. در این رابطه مفهوم شیء و کلاس با همان کیفیتی که در محیط پیرامون ما وجود دارد به صورت مناسبی امکان تقسیم یه مسئله بزرگ به بخش‌های کوچکتر را فراهم می‌کند. و سبب می‌شود هماهنگی و تقارن و تناظر خاصی بین اشیاء برنامه و دنیای واقعی بوجود آید که یکی از مزایای اصلی روش شیء گراست.
از آنجا که در یک برنامه اصولاً همه چیز و همه مفاهیم در قالب کدها و دستورات برنامه معنا دارد، کلاس و شیء نیز چیزی بیش از قطعاتی کد نیستند. قطعه کد هایی که بسته بندی شده اند تا تمام کار مربوط به هدفی که برای آن‌ها در نظر گرفته شده است را انجام دهند.
همان طور که در هر زبان برنامه نویسی دستوراتی برای کارهای مختلف مانند تعریف یک متغیر یا ایجاد یک حلقه و ... در نظر گرفته شده است، در زبان‌های برنامه نویسی شیء گرا نیز دستوراتی وجود دارد تا بتوان قطعه کدی را بر اساس مفهوم کلاس بسته بندی کرد.
به طور مثال قطعه کد زیر را در زبان برنامه نویسی سی شارپ در نظر بگیرید.
class Player
{
   public string Name;
   public int Age;
   public void Walk()
   {
      // کدهای مربوط به پیاده سازی راه رفتن
   }
   public void Run()
   {
      // کدهای مربوط به پیاده سازی دویدن
   }
}
در این قطعه کد با استفاده از کلمه کلیدی class در زبان سی شارپ کلاسی ایجاد شده است که دارای دو ویژگی نام و سن و دو رفتار راه رفتن و دویدن است.
این کلاس به چه دردی می‌خورد؟ کجا می‌توانیم از این کلاس استفاده کنیم؟
پاسخ این است که این کلاس ممکن است برای ما هیچ سودی نداشته باشد و هیچ کجا نتوانیم از آن استفاده کنیم. اما بیایید فرض کنیم برنامه نویسی هستیم که قصد داریم یک بازی فوتبال بنویسیم. به جای آنکه قطعات کد مجزایی برای هر یک از بازیکنان و کنترل رفتار و ویژگی‌های آنان بنویسیم با اندکی تفکر به این نکته پی می‌بریم که همه بازیکنان مشترکات بسیاری دارند و به عبارتی در یک گروه یا کلاس قابل دسته بندی هستند. پس سعی می‌کنیم نقشه یا قالبی برای بازیکن‌ها ایجاد کنیم که دربردارنده ویژگی‌ها و رفتارهای آن‌ها باشد.
همان طور که در نقشه ساختمان نمی‌توانیم زندگی کنیم این کلاس هم هنوز آماده انجام کارهای واقعی نیست. چراکه برخی مقادیر هنوز برای آن تنظیم نشده است. مانند نام بازیکن و سن و ....
و همان طور که برای سکونت لازم است ابتدا یک ساختمان از روی نقشه ساختمان بسازیم برای استفاده واقعی از کلاس یاد شده نیز باید از روی آن شیء بسازیم. به این فرآیند وهله سازی یا نمونه سازی نیز می‌گویند. یک زبان برنامه نویسی شیء گرا دستوراتی را برای وهله سازی نیز در نظر گرفته است. در C# کلمه کلیدی new این وظیفه را به عهده دارد.
Player objPlayer = new Player();
objPlayer.Name = “Ali Karimi”;
objPlayer.Age = 30;
objPlayer.Run();
وقتی فرآیند وهله سازی صورت می‌گیرد یک نمونه یا شیء از آن کلاس در حافظه ساخته می‌شود که در حقیقت می‌توانید آنرا همان کدهای کلاس تصور کنید با این تفاوت که مقداردهی‌های لازم صورت گرفته است. به دلیل تعیین مقادیر لازم، حال شیء تولید شده می‌تواند به خوبی اعمال پیش بینی شده را انجام دهد. توجه نمایید در اینجا پیاده سازی داخلی رفتار دویدن و اینکه مثلاً در هنگام فراخوانی آن چه کدی باید اجرا شود تا تصویر یک بازیکن در حال دویدن در بازی نمایش یابد مد نظر و موضوع بحث ما نیست. بحث ما چگونگی سازماندهی کد‌ها توسط مفهوم کلاس و شیء است. همان طور که مشاهده می‌کنید ما تمام جزییات بازیکن‌ها را یکبار در کلاس پیاده سازی کرده ایم اما به تعداد دلخواه می‌توانیم از روی آن بازیکن‌های مختلف را ایجاد کنیم. همچنین به راحتی رفتار دویدن یک بازیکن را فراخوانی میکنیم بدون آنکه پیاده سازی کامل آن در اختیار و جلوی چشم ما باشد.
تمام آنچه که بازیکن برای انجام امور مربوط به خود نیاز دارد در کلاس بازیکن کپسوله می‌شود. بدیهی است در یک برنامه واقعی ویژگی‌ها و رفتارهای بسیار بیشتری باید برای کلاس بازیکن در نظر گرفته شود. مانند پاس دادن، شوت زدن و غیره.
به این ترتیب ما برای هر برنامه می‌توانیم مسئله اصلی را به تعدادی مسئله کوچکتر تقسیم کنیم و وظیفه حل هر یک از مسائل کوچک را به یک شیء واگذار کنیم. و بر اساس اشیاء تشخیص داده شده کلاس‌های مربوطه را بنویسیم. برنامه نویسی شیء گرا سبب می‌شود تا مسئله توسط تعدادی شیء که دارای نمونه‌های متناظری در دنیای واقعی هستند حل شود که این امر زیبایی و خوانایی و قابلیت نگهداری و توسعه برنامه را بهبود می‌دهد.
احتمالاً تاکنون متوجه شده اید که برای نگهداری ویژگی‌های اشیاء از متغیر‌ها و برای پیاده سازی رفتارها یا کارکرد‌های اشیاء از توابع استفاده میکنیم.
با توجه به این که هدف این مطلب بررسی مفهوم شیء گرائی بود و نه جزییات برنامه نویسی، بنابراین بیان برخی مفاهیم در این رابطه را که بیشتر در مهندسی نرم افزار معنا دارند تا در دنیای واقعی در مطالب بعدی بررسی می‌کنیم.
‫۱۱ سال و ۷ ماه قبل، سه‌شنبه ۲۰ فروردین ۱۳۹۲، ساعت ۰۲:۰۵
وحید نصیری وحید نصیری
مطالب
آشنایی با M.A.F - قسمت دوم

قسمت قبل بیشتر آشنایی با یک سری از اصطلاحات مرتبط با فریم ورک MAF بود و همچنین نحوه‌ی کلی استفاده از آن. در این قسمت یک مثال ساده را با آن پیاده سازی خواهیم کرد و فرض قسمت دوم بر این است که افزونه‌ی Visual Studio Pipeline Builder را نیز نصب کرده‌اید.

یک نکته پیش از شروع:
- اگر افزونه‌ی Visual Studio Pipeline Builder پس از نصب به منوی Tools اضافه نشده است، یک پوشه‌ی جدید را به نام Addins در مسیر Documents\Visual Studio 2008 ایجاد کرده و سپس فایل‌های آن‌را در این مسیر کپی کنید.

ساختار اولیه یک پروژه MAF

- پروژ‌ه‌هایی که از MAF استفاده می‌کنند، نیاز به ارجاعاتی به دو اسمبلی استاندارد System.AddIn.dll و System.AddIn.Contract.dll دارند (مطابق شکل زیر):



- ساختار آغازین یک پروژه MAF از سه پروژه تشکیل می‌شود که توسط افزونه‌ی Visual Studio Pipeline Builder به 7 پروژه بسط خواهد یافت.
این سه پروژه استاندارد آغازین شامل موارد زیر هستند:



- هاست: همان برنامه‌ی اصلی که قرار است از افزونه استفاده کند.
- قرار داد: نحو‌ه‌ی تعامل هاست و افزونه در این پروژه تعریف می‌شود. (یک پروژه از نوع class library)
- افزونه: کار پیاده سازی قرار داد را عهده دار خواهد شد. (یک پروژه از نوع class library)

- همچنین مرسوم است جهت مدیریت بهتر خروجی‌های حاصل شده یک پوشه Output را نیز به این solution اضافه کنند:



اکنون با توجه به این محل خروجی، به خواص Build سه پروژه موجود مراجعه کرده و مسیر Build را اندکی اصلاح خواهیم کرد (هر سه مورد بهتر است اصلاح شوند)، برای مثال:



نکته‌ی مهم هم اینجا است که خروجی host باید به ریشه این پوشه تنظیم شود و سایر پروژه‌ها هر کدام خروجی خاص خود را در پوشه‌ای داخل این ریشه باید ایجاد کنند.



تا اینجا قالب اصلی کار آماده شده است. قرارداد ما هم به شکل زیر است (ویژگی AddInContract آن نیز نباید فراموش شود):

using System.AddIn.Pipeline;
using System.AddIn.Contract;

namespace CalculatorConract
{
  [AddInContract]
  public interface ICalculatorContract : IContract
  {
      double Operate(string operation, double a, double b);
  }
}

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

ایجاد pipeline

اگر قسمت قبل را مطالعه کرده باشید، یک راه حل مبتنی بر MAF از 7 پروژه تشکیل می‌شود که عمده‌ترین خاصیت آن‌ها مقاوم کردن سیستم در مقابل تغییرات نگارش قرارداد است. در این حالت اگر قرار داد تغییر کند، نه هاست و نه افزونه‌ی قدیمی، نیازی به تغییر در کدهای خود نخواهند داشت و این پروژه‌های میانی هستند که کار وفق دادن (adapters) نهایی را برعهده می‌گیرند.


برای ایجاد خودکار View ها و همچنین Adapters ، از افزونه‌ی Visual Studio Pipeline Builder که پیشتر معرفی شد استفاده خواهیم کرد.



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


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



پیاده سازی افزونه

قالب کاری استفاده از این فریم ورک آماده است. اکنون نوبت به پیاده سازی یک افزونه می‌باشد. به پروژه AddIn مراجعه کرده و ارجاعی را به اسمبلی AddInView خواهیم افزود. به این صورت افزونه‌ی ما به صورت مستقیم با قرارداد سروکار نداشته و ارتباطات، در راستای همان pipeline تعریف شده، جهت مقاوم شدن در برابر تغییرات صورت می‌گیرد:
using System;
using CalculatorConract.AddInViews;
using System.AddIn;

namespace CalculatorAddIn
{
   [AddIn]
  public class MyCalculatorAddIn : ICalculator
  {
      public double Operate(string operation, double a, double b)
      {
          throw new NotImplementedException();
      }
  }
}

در اینجا افزونه‌ی ما باید اینترفیس ICalculator مربوط به AddInView را پیاده سازی نماید که برای مثال خواهیم داشت:

using System;
using CalculatorConract.AddInViews;
using System.AddIn;

namespace CalculatorAddIn
{
  [AddIn("افزونه یک", Description = "توضیحات", Publisher = "نویسنده", Version = "نگارش یک")]
  public class MyCalculatorAddIn : ICalculator
  {
      public double Operate(string operation, double a, double b)
      {
          switch (operation)
          {
              case "+":
                  return a + b;
              case "-":
                  return a - b;
              case "*":
                  return a * b;
              default:
                  throw new NotSupportedException("عملیات مورد نظر توسط این افزونه پشتیبانی نمی‌شود");
          }
      }
  }
}

همانطور که در قسمت قبل نیز ذکر شد، این کلاس باید با ویژگی AddIn مزین شود که توسط آن می‌توان توضیحاتی در مورد نام ، نویسنده و نگارش افزونه ارائه داد.


استفاده از افزونه‌ی تولید شده

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

نکته‌ی مهم!
در هر دو ارجاع به HostView و یا AddInView باید خاصیت Copy to local به false تنظیم شود، در غیر اینصورت افزونه‌ی شما بارگذاری نخواهد شد.



پس از افزودن ارجاعی به HostView، نمونه‌ای از استفاده از افزونه‌ی تولید شده به صورت زیر می‌تواند باشد که توضیحات مربوطه به صورت کامنت آورده شده است:

using System;
using System.AddIn.Hosting;
using CalculatorConract.HostViews;

namespace Calculator
{
  class Program
  {
      private static ICalculator _calculator;

      static void doOperation()
      {
          Console.WriteLine("1+2: {0}", _calculator.Operate("+", 1, 2));
      }

      static void Main(string[] args)
      {
          //مسیر پوشه ریشه مربوطه به خط لوله افزونه‌ها
          string path = Environment.CurrentDirectory;

          //مشخص سازی مسیر خواندن و کش کردن افزونه‌ها
          AddInStore.Update(path);

          //یافتن افزونه‌هایی سازگار با شرایط قرارداد پروژه
          //در اینجا هیچ افزونه‌ای بارگذاری نمی‌شود
          var addIns = AddInStore.FindAddIns(typeof(ICalculator), path);

          //اگر افزونه‌ای یافت شد
          if (addIns.Count > 0)
          {
              var addIn = addIns[0]; //استفاده از اولین افزونه
              Console.WriteLine("1st addIn: {0}", addIn.Name);

              //فعال سازی افزونه و همچنین مشخص سازی سطح دسترسی آن
              _calculator = addIn.Activate<ICalculator>(AddInSecurityLevel.Intranet);

              //یک نمونه از استفاده آن
              doOperation();
          }

          Console.WriteLine("Press a key...");
          Console.ReadKey();
      }
  }
}

چند نکته جالب توجه در مورد قابلیت‌های ارائه شده:
- مدیریت load و unload پویا
- امکان تعریف سطح دسترسی و ویژگی‌های امنیتی اجرای یک افزونه
- امکان ایزوله سازی پروسه اجرای افزونه از هاست (در ادامه توضیح داده خواهد شد)
- مقاوم بودن پروژه به نگارش‌های مختلف قرارداد


اجرای افزونه در یک پروسه مجزا

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

//فعال سازی افزونه و همچنین مشخص سازی سطح دسترسی آن
//همچنین جدا سازی پروسه اجرایی افزونه از هاست
   _calculator = addIn.Activate<ICalculator>(
                  new AddInProcess(),
                  AddInSecurityLevel.Intranet);

در این حالت اگر پس از فعال شدن افزونه، یک break point قرار دهیم و به task manager ویندوز مراجعه نمائیم، پروسه‌ی مجزای افزونه قابل مشاهده است.



برای مطالعه بیشتر + ، + ، + و +

‫۱۴ سال و ۱۱ ماه قبل، چهارشنبه ۲ دی ۱۳۸۸، ساعت ۱۹:۴۷
مهمان مهمان
نظرات مطالب
هزینه استفاده از دات نت فریم ورک چقدر است؟
سلام دوست عزیز بنده قصد تخریب یا نفی گفته های شما رو ندارم فقط نکاتی که به نظرم میرسه بیان می کنم:

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

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

این موارد رو فقط برای این گفتم که با دید بازتری به مساله نگاه کنیم نه این که حرف های شما رو نقض کنم. ولی باید این مورد هم در نظر داشت که با وجود این که سری رایگان  محصولات express مایکروسافت و پروژه مونو وجود دارن آیا در یک محیط کاری و تجاری میشه از اون ها استفاده کرد یا خیر. چیزی که تو تقریبا تمام شرکت ها مشاهده می کنیم که که عملا همه از نسخه های پولی ویژوال استودیو و SQL server استفاده می کنن و خبری هم از مونو نیست.

حرف آخرم اینه منظورم این نیست که بگیم باید از مایکروسافت دوری کرد. مایکروسافت یه پلتفرم درست کرده برای یه عده از توسعه دهنده ها که تونسته موفق هم باشه و خیلی ها هم جذب کنه. اتفاقا خیلی هم خوبه که در دات نت توی ایران پر بار هستیم. ولی آیا زبان ها و پلتفرم های دیگه هم به اون جایگاهی که دارن در ایران رسیدن؟ بازار کار دات نت در ایران خوبه اما آیا این تک قطبی شدن بازار به نفع توسعه دهنده یا مشتری هست؟ منابع غیر دات نت در ایران کم هست اما این دلیل میشه که زبان های دیگرو نفی کنیم و همه منابع انگلیسی و دیگر اون ها رو نادیده بگیرم؟ اگه فقط بخوایم به چیزی که جا افتاده هست مهر تایید بزنیم و بقیه رو نادیده بگیریم خب حرفی باقی نمی مونه اما اگه می خوایم دانش کامپیوتر رو گسترش بدیم به بقیه هم باید همون قدر بها بدیم.
با احترام
‫۱۳ سال و ۲ ماه قبل، چهارشنبه ۱۶ شهریور ۱۳۹۰، ساعت ۱۸:۳۸
مهمان مهمان
نظرات مطالب
هزینه استفاده از دات نت فریم ورک چقدر است؟
سلام دوست عزیز بنده قصد تخریب یا نفی گفته های شما رو ندارم فقط نکاتی که به نظرم میرسه بیان می کنم:

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

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

این موارد رو فقط برای این گفتم که با دید بازتری به مساله نگاه کنیم نه این که حرف های شما رو نقض کنم. ولی باید این مورد هم در نظر داشت که با وجود این که سری رایگان  محصولات express مایکروسافت و پروژه مونو وجود دارن آیا در یک محیط کاری و تجاری میشه از اون ها استفاده کرد یا خیر. چیزی که تو تقریبا تمام شرکت ها مشاهده می کنیم که که عملا همه از نسخه های پولی ویژوال استودیو و SQL server استفاده می کنن و خبری هم از مونو نیست.

حرف آخرم اینه منظورم این نیست که بگیم باید از مایکروسافت دوری کرد. مایکروسافت یه پلتفرم درست کرده برای یه عده از توسعه دهنده ها که تونسته موفق هم باشه و خیلی ها هم جذب کنه. اتفاقا خیلی هم خوبه که در دات نت توی ایران پر بار هستیم. ولی آیا زبان ها و پلتفرم های دیگه هم به اون جایگاهی که دارن در ایران رسیدن؟ بازار کار دات نت در ایران خوبه اما آیا این تک قطبی شدن بازار به نفع توسعه دهنده یا مشتری هست؟ منابع غیر دات نت در ایران کم هست اما این دلیل میشه که زبان های دیگرو نفی کنیم و همه منابع انگلیسی و دیگر اون ها رو نادیده بگیرم؟ اگه فقط بخوایم به چیزی که جا افتاده هست مهر تایید بزنیم و بقیه رو نادیده بگیریم خب حرفی باقی نمی مونه اما اگه می خوایم دانش کامپیوتر رو گسترش بدیم به بقیه هم باید همون قدر بها بدیم.
با احترام
‫۱۳ سال و ۲ ماه قبل، چهارشنبه ۱۶ شهریور ۱۳۹۰، ساعت ۱۸:۳۸