تفاوت بازگشت متد از نوع List و IList در اینجا چیست؟
- چه تعداد SDK را نصب کردید؟ اگر لیست dotnet --list-sdks طولانی است، بهتر است به کنترل پنل مراجعه کرده و قدیمی‌ها را حذف کنید؛ چون دیگر پشتیبانی نمی‌شوند؛ خصوصا نگارش‌های پیش از 3.1.
- همیشه هنگام کار با قالب‌های ایجاد شده، امکان ذکر target framework هم هست:
dotnet new somename --framework net5.0
برای ادیت این قالب‌ها شما باید به CSS کاملا مسلط باشید یا توصیه من این است که لطفا به آدرس زیر مراجعه کرده و از یکی از قالب‌های آماده آن استفاده کنید (تقریبا همه همین کار را میکنند):
http://themes.blogger-fa.com
برای تاریخ هم از این روش استفاده کنید:
http://docs.blogger-fa.com/2008/09/blogger-persian-date.html
http://themes.blogger-fa.com
برای تاریخ هم از این روش استفاده کنید:
http://docs.blogger-fa.com/2008/09/blogger-persian-date.html
در مورد معرفی WPF Extended toolkit چندی قبل مطلبی منتشر شد. در ادامه این بی مهری‌ها (!) می‌توان به عدم به روز رسانی قالب‌های ارائه شده برای WPF اشاره کرد. در WPF4 ، کنترل DataGrid از WPF toolkit به مجموعه‌ی کنترل‌های اصلی WPF منتقل شده است، اما قالب‌های منتشر شده‌ی آن جهت لحاظ کردن این مورد به روز نشده‌اند. یعنی اگر برای مثال یکی از قالب‌های موجود را به برنامه خود اعمال کنید و سپس DataGrid را بر روی فرم قرار دهید، وصله‌ی ناهماهنگی را مشاهده خواهید نمود. این مشکلات در Silverlight وجود ندارند و قالب‌های ارائه شده‌ی برای آن به روز بوده و همچنین روز به روز هم تعدادشان بیشتر می‌شوند.
اما باز هم نمی‌توان ایراد گرفت چون کار ارائه شده سورس باز است. به عبارتی اگر مایکروسافت این قالب‌ها را به روز نکرده، خوب، لطفا خود شما وقت بگذارید و این کار را انجام داده و سپس یک patch ارائه دهید. ایرادی دارد؟!
برای این منظور پروژه‌ای در سایت CodePlex ایجاد شده است و تنها به پوشش دات نت سه و نیم و دیتاگرید متعلق به WPF Toolkit پرداخته است :
اگر علاقمند باشید که از دیتاگرید بومی دات نت 4 استفاده کنید می‌توانید از این patch استفاده کنید.
از نحوه‌ی عملکرد قالب پیش فرض نمایشی یک سلول خشنود نیستید؟ سفارشی‌اش کنید:
«ایجاد قالب‌های سفارشی ستون‌ها و فرمت شرطی اطلاعات در PdfReport»
یک مثال دیگر: نمایش مبلغ به صورت سفارشی
«ایجاد قالب‌های سفارشی ستون‌ها و فرمت شرطی اطلاعات در PdfReport»
یک مثال دیگر: نمایش مبلغ به صورت سفارشی
- استفاده همزمان از jQuery و ASP.NET AJAX UpdatePanel | مصطفی دیندار | anotherdeveloper.net
- تناقضات و نقایص طرح اداره صدا و سیما | www.ictna.ir
- گزارشی از وضعیت آموزشگاه‌های خصوصی IT در کشور | www.ictna.ir
- Auditing in SQL server | Alpesh Patel | beyondrelational.com
- SharpDevelop 4.2 و ساده سازی ایجاد خواص | community.sharpdevelop.net
- حجم بانک اطلاعاتی مدل در نگارش‌های مختلف اس کیوال سرور | blogs.msdn.com
- حجم دات نت 4.5، 40 درصد کاهش یافته است | channel9.msdn.com
- کتاب رایگان Getting Results the Agile Way | blogs.msdn.com
- نمونه‌ای از کاربرد دات نت Micro Framework | 10rem.net
- CRMهای ایرانی | blog.fardapardaz.com
- Mocking با استفاده از Moq | (Afshar Mohebbi) | blog.afsharm.com
- شروع به کار Qt Project | آرش | azadrah.net
- منتشر شد! Roslyn پیش نمایش سرویس کامپایلر سی شارپ و ویژوال بیسیک | www.persiadevelopers.com
- نرم افزار مدیریت بایگانی نامه های وارده و صادره | mojtabasahraei | mojtabasahraei.blogfa.com
- Extended WPF Toolkit–the updated PropertyGrid | elegantcode.com
- HTTP Pipelining In Chrome 17 | www.conceivablytech.com
- Microsoft® Visual Studio® Agents 11 Developer Preview (ISO) | www.microsoft.com
- Scaled Agile Framework | scalingsoftwareagility.wordpress.com
- 5 مانع مهم حین انطباق با سیستمهای سورس باز | brainslink.com
- گروه بندی story cards بر اساس رنگ | www.tinypm.com
- مجموعه‌های کمتر شناخته شده دات نت | www.simple-talk.com
داخل وبلاگها و وب سایتهای فارسی زبان(مربوط به برنامه نویسی) که جستجو میکنیم شاهد کلمه ای هستیم که تازه به چشممان میخورد:Agile(چابک). البته لازم به ذکر است این کلمه چیز جدیدی نیست و سابقه ای در حدود 10 سال دارد(February 2001 ).که جمعی از برنامه نویسان بیانیه ای را تحت عنوان چابک (Agile ) تهیه کردند که متن آن به شرح زیر است:
ما با توسعه نرم افزار و کمک به دیگران در انجام آن . در حال کشف راه‌های بهتری برای توسعه نرم افزار هستیم. از این طریق باید دست یابیم به ارزش :
- افراد و تعاملات بالاتر از فرآیندها و ابزارها
- نرم افزار کارکننده بالاتر از مستندات جامع
- مشارکت مشتری در انجام کار بالاتر از قرارداد کار
- پاسخگویی به تغییرات بالاتر از پیروی یک طرح
با وجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم .
که این بیانیه بر پایه 12 اصل(Agile principles)
- بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند می‌باشد
- استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند‌های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند
- تحویل زود به زود نرم‌افزار قابل استفاده دو، سه هفته یک بار تا دو ، سه ماه یک بار با ترجیح بر فاصله‌های زمانی کوتاه‌تر
- ذی نفعان کسب و کار و توسعه دهنده‌ها می‌بایست به صورت روزانه در طول پروژه با هم کار کنند
- پروژه‌ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم رابه آنها بدهید و از نیازهای آنها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند
- کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است
- نرم افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است
- فرآیند‌های چابک توسعه پایدار را ترویج می‌دهندحامیان مالی , توسعه دهندگان و کاربران باید بتوانند سرعت پیشرفت ثابتی را برای مدت نامحدودی حفظ کنند
- توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می‌شود
- سادگی -- هنر به حداکثر رساندن مقدار کار انجام نشده -- ضروری است
- بهترین معماری‌ها , نیاز مندی‌ها و طراحی‌ها از تیم‌های خود سازمانده پدید آور می‌شود
- در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می‌نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می‌نماید
متاسفانه در ایران حالا یا به علت سواد کم و یا به هر علتی از این بیانیه برداشتهایی متفاوت و غلط عده ای اونو به بازی تشبیه کردن و عده ای هم با اون کار میکنن ولی هیچکدوم از اصل‌های اونو رعایت نمیکنن و بعد که پروژه شکست خورد میگن:متدولوژی خوب نبود و ... .
وقتی کتاب Agile Principles, Patterns, and Practices in C# رو مطالعه میکنید به این نتیجه میرسید که بیشترین چیزی که تاکید داره روی ارتباطات هستش.
قصد دارم در قالب چند پست به شما این اصول رو معرفی کنم.
تست نرم افزار یکی از راه‌های اطمینان بیشتر به نرم افزار، برای ارائه نهایی آن به بازار است. تست نرم افزار از بخش‌ها و قسمت‌های مختلفی تشکیل شده است که به ترتیب خاصی مورد توجه قرار می‌گیرند. در این مقاله قصد داریم به بررسی روند تست و از همه مهمتر تست‌های آلفا و بتا بپردازیم.
طبق نوشته‌ی ویکی پدیا یک تست از مراحل زیر تشکیل می‌شود:
تست واحد : تست واحد در این سایت، به طور مکرر توسط فریمورک‌های مختلفی مورد توجه قرار گرفته است و هدف آن تست برنامه به صورت قطعات کوچک است تا اطمینان پیدا کنیم آن تکه کد طبق انتظار ما جلو می‌رود. این تست حتی در آینده هم برای دنبال کردن باگ‌ها، کار ما را ساده‌تر میکند.
تست یکپارچه: هدف تست یکپارچه، بررسی عملکرد برنامه بعد از قرار گرفتن همه‌ی تکه‌ها در کنار هم هستند و این اطمینان را می‌دهد که برنامه عملکرد مثبتی دارد.
تست رابط جز: هدف این تست بررسی ارتباط و داده‌های بین قسمت‌ها و اجزای مختلف یک سیستم یا ارتباط زیر سیستم‌ها با یکدیگر در یک سیستم بزرگتر است.
تست سیستم: تست سیستم برای بررسی عملکرد برنامه در سیستمهای مختلف است. اینکه برنامه در محیط‌های اجرایی مختلف چگونه عمل میکند و در این شیوه باید قابلیت‌های مختلف برنامه را در محیط‌ها و ابزارهای مختلفی که برنامه استفاده میکند سنجید.
تست پذیرش عملکرد: یا اصطلاحا OAT، جهت اطمینان از عملکرد سیستم، برای ارائه نهایی به کار می‌رود که در اینجا دو آزمون آلفا و بتا صورت می‌گیرند.
تست آلفا Alpha در داخل خود سازمان توسط توسعه دهندگان که مسئول بررسی و تست نرم افزار هستند اتفاق می‌افتد. شکل زیر به خوبی جایگاه تست آلفا را در میان تست‌ها توضیح می‌دهد.
فاز اول: فاز اول داخل تیم اصلی، توسط توسعه دهندگان هست تا اصلی‌ترین باگ‌ها به سرعت رفع و حل شوند.
در فاز دوم برنامه به دست توسعه دهندگان واحد تضمین کیفیت Quality Assurance - QA مورد تست و ارزیابی قرار میگیرد.
تست آلفا قبل از عرضه عمومی اصطلاحا Commercial Off-the Shelf-COTS صورت میگیرد و قبل از تست بتا می‌باشد.
تست بتا Beta توسط کاربران نهایی نرم افزار و گاها کاربران شناخته شده‌ی محصول انجام میگیرد. این تست به منظور بررسی و ارزیابی عملکرد نرم افزار ، پایداری ، سازگاری ، میزان اطمینان به نرم افزار صورت میگیرد. تست بتا این ارزش را برای نرم افزار می‌آورد تا توسط کاربران اصلی و در محیط‌های واقعی به طور وسیع‌تری مورد بررسی قرار گیرد تا بتواند چرخه تست نرم افزار را با موفقیت به اتمام برساند. همچین به توسعه دهنده کمک میکند تا حجم ورودی‌های عظیمی را جمع آوری تا در آینده برای نسخه‌ها و پشتیبانی‌های آتی استفاده کند.
تصویر زیر جایگاه تست بتا را در روند تست نشان می‌دهد:
هزینه تست
تعداد شرکت کنندگان در این تست
نحوه ارسال به کاربر ( که امروزه بیشتر از طریق اینترنت صورت میگیرد)
مدت زمان تست
از نکات مهم در این تست می‌توان گفت که طول دوره تست آلفا، بیشتر از تست بتاست که به طور متوسط 3 تا 5 برابر تست بتا طول می‌کشد و خود تست بتا، عموما در حد چند هفته و گاها تا چند ماه می‌باشد.
در صورتیکه تست آلفا با موفقیت بیرون داده شود، وارد نسخه بتا می‌شود و بعد از اتمام تست بتا وارد ریلیز نهایی می‌شود. تست آلفا با توجه COTS گفته شده می‌تواند کاربران خاص و محیط خاص خود را داشته باشد.
طبق نوشته‌ی ویکی پدیا یک تست از مراحل زیر تشکیل می‌شود:
تست واحد : تست واحد در این سایت، به طور مکرر توسط فریمورک‌های مختلفی مورد توجه قرار گرفته است و هدف آن تست برنامه به صورت قطعات کوچک است تا اطمینان پیدا کنیم آن تکه کد طبق انتظار ما جلو می‌رود. این تست حتی در آینده هم برای دنبال کردن باگ‌ها، کار ما را ساده‌تر میکند.
تست یکپارچه: هدف تست یکپارچه، بررسی عملکرد برنامه بعد از قرار گرفتن همه‌ی تکه‌ها در کنار هم هستند و این اطمینان را می‌دهد که برنامه عملکرد مثبتی دارد.
تست رابط جز: هدف این تست بررسی ارتباط و داده‌های بین قسمت‌ها و اجزای مختلف یک سیستم یا ارتباط زیر سیستم‌ها با یکدیگر در یک سیستم بزرگتر است.
تست سیستم: تست سیستم برای بررسی عملکرد برنامه در سیستمهای مختلف است. اینکه برنامه در محیط‌های اجرایی مختلف چگونه عمل میکند و در این شیوه باید قابلیت‌های مختلف برنامه را در محیط‌ها و ابزارهای مختلفی که برنامه استفاده میکند سنجید.
تست پذیرش عملکرد: یا اصطلاحا OAT، جهت اطمینان از عملکرد سیستم، برای ارائه نهایی به کار می‌رود که در اینجا دو آزمون آلفا و بتا صورت می‌گیرند.
تست آلفا Alpha در داخل خود سازمان توسط توسعه دهندگان که مسئول بررسی و تست نرم افزار هستند اتفاق می‌افتد. شکل زیر به خوبی جایگاه تست آلفا را در میان تست‌ها توضیح می‌دهد.
فاز اول: فاز اول داخل تیم اصلی، توسط توسعه دهندگان هست تا اصلی‌ترین باگ‌ها به سرعت رفع و حل شوند.
در فاز دوم برنامه به دست توسعه دهندگان واحد تضمین کیفیت Quality Assurance - QA مورد تست و ارزیابی قرار میگیرد.
تست آلفا قبل از عرضه عمومی اصطلاحا Commercial Off-the Shelf-COTS صورت میگیرد و قبل از تست بتا می‌باشد.
تست بتا Beta توسط کاربران نهایی نرم افزار و گاها کاربران شناخته شده‌ی محصول انجام میگیرد. این تست به منظور بررسی و ارزیابی عملکرد نرم افزار ، پایداری ، سازگاری ، میزان اطمینان به نرم افزار صورت میگیرد. تست بتا این ارزش را برای نرم افزار می‌آورد تا توسط کاربران اصلی و در محیط‌های واقعی به طور وسیع‌تری مورد بررسی قرار گیرد تا بتواند چرخه تست نرم افزار را با موفقیت به اتمام برساند. همچین به توسعه دهنده کمک میکند تا حجم ورودی‌های عظیمی را جمع آوری تا در آینده برای نسخه‌ها و پشتیبانی‌های آتی استفاده کند.
تصویر زیر جایگاه تست بتا را در روند تست نشان می‌دهد:
هزینه تست
تعداد شرکت کنندگان در این تست
نحوه ارسال به کاربر ( که امروزه بیشتر از طریق اینترنت صورت میگیرد)
مدت زمان تست
از نکات مهم در این تست می‌توان گفت که طول دوره تست آلفا، بیشتر از تست بتاست که به طور متوسط 3 تا 5 برابر تست بتا طول می‌کشد و خود تست بتا، عموما در حد چند هفته و گاها تا چند ماه می‌باشد.
در صورتیکه تست آلفا با موفقیت بیرون داده شود، وارد نسخه بتا می‌شود و بعد از اتمام تست بتا وارد ریلیز نهایی می‌شود. تست آلفا با توجه COTS گفته شده می‌تواند کاربران خاص و محیط خاص خود را داشته باشد.
Starting from Team Foundation Server 2017, the Code Search feature that was available for a while in VSTS, gets an on-premise equivalent.
The feature is built on top of a customized version of ElasticSearch. However the integration between the 2 products(TFS and ElasticSearch) is rather limited right now.
