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

یک تجربه
سالها پیش یکی از همکاران تعریف می‌کردند که یک شرکت نرم افزاری برای مشاوره معماری نرم افزار از ایشان دعوت به همکاری کرده است. پس از مراجعه به شرکت متوجه شدند که تیم اصلی برنامه نویسان درگیر تولید ORM ای برای پروژه جدید شرکت هستند که برای تولید این ابزار بیش از 4 ماه را وقت صرف کرده‌اند؛ اما در مراحل نهایی کار دچار مشکلات زیادی شده اند. به نحوی که از ایشان برای کمک به رفع مشکل ORM ( به جای تولید نرم افزار مشتری) دعوت کرده‌اند.
 
در آن زمان یادم هست که EF 5 (که تقریبا نسخه سوم  بعد از 3.5 و 4 می‌باشد - جزئیات در اینجا) توسط مایکروسافت ارائه شده بود. همچنین NHibernate هم همزمان با EFها (تاریخچه نسخه‌ها در اینجا) قابل دسترسی بوده‌است. با این حال تیم فنی به این دلیل که کوئری‌های تولیدی توسط EF کند هستند، اقدام به ساخت ORM کرده بودند. جالب اینکه با بررسی بیشتر مشخص شده‌است که حجم داده‌های پروژه در بدترین حالت در یک جدول به 5 هزار رکورد می‌رسد.

4 ماه صرف وقت و هزینه تیم 2 نفره برای طراحی و پیاده سازی و تست ORM ای که در نهایت به دلیل مشکلات Performance کنار گذاشته شد و از EF استفاده کردند. شاید در این 4 ماه می‌توانستند 30 درصد پروژه اصلی را پیاده سازی کنند.

شاید بتوان 3 دلیل عمده «فنی» شکست برخی از پروژه‌های نرم افزاری در ایران را به شرح زیر عنوان کرد:
- عدم استفاده مناسب از ابزارها و راهکار‌های موجود و انجام دوباره کاری
- استفاده غیر ضروری و عجولانه از تکنولوژی‌های جدید (بدون داشتن نیروی کار مسلط)
- پایین بودن سطح فنی و به‌روز نبودن برخی از برنامه نویسان ایرانی


متن باز (Open Source)
با پیشرفت توسعه نرم افزار و تمایل شرکت‌های بزرگ دنیا به تولید کامپوننت‌های متن باز (Open Source) ریسک استفاده از این نوع ابزار‌ها نیز کمتر شده است. بطوریکه درصورت نیاز می‌توان کامپوننت را برای پروژه‌ها سفارش سازی کرد.
شاید کمتر کسی باور می‌کرد که روزی شرکت مایکروسافت محصولات خود را Open Source کند. اما امروز، در سال 2017 میلادی، شرکت مایکروسافت اقدامات مهمی را در این زمینه انجام داده است که می‌توانید جزئیات پروژه‌های متن باز این غول کامپیوتری دنیا را در اینجا و همچنین اینجا ملاحظه کنید.

 
یک سناریو
فرض کنید یک پروژه تحت وب را شروع کرده اید. بدون در نظر گرفتن جزئیات پروژه می‌توان گفت به ابزارهای زیر نیاز خواهید داشت:

ابزار
مثال
  ORM   EF , NHibernate , Dapper , LLBLGEN 
 IOC COntainer   Unity , StructureMap , Autofac , Castle.Windsor, LightInject , Ninject 
 Report Tools   CrsytalReport , Stimusoft , DevExpress Report, Telerik Report Tools, EasyReport 
 UI Component   Telerik , JqueryUI , Bootsrap ,CompnentArt, ComponentOne 
 Error Logger   ELMAH , NLog , log4net 
 Mapper Tools   AutoMapper , ValueInjecter 
همانطور که ملاحظه می‌کنید برای همه‌ی موارد فوق ابزارهای مناسبی وجود دارند که برای پیاده سازی هر کدام، سالها وقت و هزینه صرف شده‌است. همچنین قابلیت اطمینان این ابزار‌ها به مراتب بالاتر از ابزارهای دست ساز خواهد بود. شاید برای ساده‌ترین ابزار فوق 3 ماه زمان لازم باشد تا یک نسخه  باگ دار تهیه شود!


ملاحظات استفاده از ابزارها
توجه به چند نکته در استفاده از ابزارها و کتابخانه‌های آماده ضروری می‌باشد، بدین شرح:
- ابزار مورد نیاز را با R&D (تحقیق و توسعه) انتخاب کنید. ابزارهایی که در پروژه‌های واقعی استفاده شده‌اند، بسیار مناسب می‌باشند.
- توجه داشته باشیدکه استفاده از چندین ابزار باعث ایجاد تداخل در پروژه نشود (این مورد معمولا در کامپوننت‌های UI مانند JqueryUI و Bootsrtap اتفاق می‌افتد)
- مستندات مربوط به ابزار‌ها را حتما مطالعه کنید. لطفا بدون تسلط از ابزاری استفاده نکنید.

گاهی پیش می‌آید که یک برنامه نویس بدون مطالعه مستندات مربوط به یک IOC Container از آن ابزار استفاده میکند و در Register اولیه ویژگی LifeCycle مربوط به Context  را با حالت Singleton مقداردهی میکند. بدین ترتیب پس از نیم ساعت، پروژه به دلیل آنچه که می‌توان "چاقی Context" نامید، DONE یا حداقل کند می‌شود که رفع این مشکل ساعت‌ها زمان می‌برد.

درصورت امکان از ابزارها بصورت مستقیم استفاده نکنید. یک لایه واسط مخصوص خودتان را برای تنظیمات کلی ابزار‌ها تهیه کنید که در آینده به دردتان خواهد خورد! (بیشتر در سمت سرور)

فرض کنید در پروژه WPF از کامپوننت‌های زیبای DevExpress استفاده میکنید. به ازای هر کامپوننت یک کلاس به پروژه اضافه کنید که از کلاس اصلی آن کامپوننت Devexspress ارث می‌برد و در لایه UI خود از کلاس جدید خود استفاده کنید. با این کار می‌توانید ویژگی‌های عمومی کامپوننت‌ها را یکبار برای کل پروژه اعمال کنید.


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

میشل دلافورس سخنگوی اتحادیه کارگری البته گفت این بدان معنا نیست که راس ساعت 6 بعد ازظهر همگی موبایل‌های خود را خاموش کنند! و کسی‎‌که این حرف‌ها را می‌زند موافقتنامه را به درستی نخوانده است. اما روزنامه‌ها همچنان تاکید دارند که آی‌تی کاران حق چنین کاری را دارند. 
ظاهرا آی‌تی کارانی که در معرض فرسودگی شغلی قرار دارند می‌توانند خود را از حالت اتصال دائم در بیاورند اما ساعت کاری 35ساعت در هفته آنها تغییر نخواهد کرد. 
تفسیر میشل دلافورس از این توافقنامه جالب است که می‌گوید سلامت شاغلان آی‌تی برایشان مهم بوده و اگر سلامت شاغلی به خطر بیفتد می‌تواند به کارفرمای خود بگوید: "نه! و این بدان معنا هم نیست که شاغلی با ریختن اطلاعات کاری روی یو‌اس‌بی بگوید: اوکی من از خانه کارهایم را انجام می‌دهم! 
آی‌تی کاران فرانسوی بردند/ هر وقت خواستید خود را علیه کارفرما unplug کنید
بازخوردهای دوره
تزریق وابستگی‌ها در فیلترهای ASP.NET MVC
ضمن تشکر ویژه از توجه شما، بله، از فایلهای همین مخزن استفاده کردم. در اینجا هم همان Attribute کامنت شده است. با حذف آن، مجددا همان پیام را دریافت می‌کنم. مگر مطابق با این قطعه کد:
        public LogAttribute(IContainer container)
        {
            _container = container;
        }
استفاده از این Attribute نیازمند پارامتر ورودی IContainer نیست؟
لطف می‌کنید راهنمایی بفرمایید.
بازخوردهای دوره
تزریق خودکار وابستگی‌ها در برنامه‌های ASP.NET Web forms
در مطلب « بایدها و نبایدهای استفاده از IoC Containers  » عنوان شد که تا حد ممکن نباید کدهای مرتبط با یک IoC Container داخل کدهای متداول ما ظاهر شوند. کار کلاس StructureMapModule تمیز کردن فایل‌های code behind از وجود IoC Container مورد نظر است.
نظرات مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 6 - سرویس‌ها و تزریق وابستگی‌ها
یک نکته‌ی تکمیلی
یک populate اضافی در اینجا باید حذف شود:
private IServiceProvider IocConfig(IServiceCollection services)
        {
            var container = new Container();
            container.Configure(config =>
            {
                //config.Populate(services); ---> اضافی است
            });
            container.Populate(services);
            return container.GetInstance<IServiceProvider>();
        }
نظرات مطالب
دریافت زمانبندی شده به روز رسانی‌های آنتی ویروس Symantec به کمک کتابخانه‌های Quartz.NET و Html Agility Pack
زمانیکه از یک IoC Container استفاده می‌کنید، بجای new MyClass می‌توانید بنویسید:
SmObjectFactory.Container.GetInstance<MyClass>()
در حالت اول، تمام وابستگی‌ها را هم خودتان باید به همراه new ارائه کنید. در حالت دوم تا n سطح وابستگی هم بر اساس تنظیمات اولیه‌ی IoC Container به صورت خودکار وهله سازی می‌شوند.
نظرات مطالب
فعال سازی عملیات CRUD در Kendo UI Grid
$("#grid").kendoGrid({
// ...
    columns:
    [
        {
            field: "Your Field",
            title: "Your Field Name",
            width: "20%",
            editor: function (container, options) {
                $('<textarea cols="20" rows="4" data-bind="value: ' + options.field + '"></textarea>').appendTo(container);
            }
        },
        // ...   
   ]
// ...
});
نظرات مطالب
EF Code First #12
باتوجه به توضیح شما، پیاده سازی صحیح‌تر بصورت زیر است؟
Program.cs:

Application.Run(ObjectFactory.GetInstance<frmMain>());

frmMain:
       private IContainer _container;
       private IUnitOfWork _uow;
 
       public frmMain(IUnitOfWork uow, IContainer container)
       {
           InitializeComponent();
 
           _container = container;
           _uow = uow;
       }
نظرات مطالب
توسعه سیستم مدیریت محتوای DNTCms - قسمت دوم
یکی از بهبودهای خوب در کار مدل سازی code first می‌تونه تعیین صریح اندازه‌ی رشته‌ها باشه. چون اگر به صورت پیش فرض مشخص نشوند، گاهی max خواهند بود و گاهی هم خیر (^ و ^).