چرا از متد های async نمی توانیم در بدنه lock استفاده کنیم؟

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

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

موضوع به مبحثی تحت عنوان thread affinity مربوط می شود. در مسئله ما، این موضوع یعنی اینکه هر thread ایی که وارد بدنه lock شده است، همان thread هم فقط اجازه خروج از بدنه lock را خواهد داشت.

در متد های async، نکته حائز اهمیت آن می باشد که بدنه متد تا قبل از رسیدن به کلمه await، توسط یک thread اجرا می شود و پس از اجرای دستور await توسط thread دیگری (به احتمال خیلی زیاد) اجرا خواهد شد. این ویژگی عاملی مهمی در بالا رفتن کارایی برنامه ها (مخصوصا در پلتفرم وب) خواهد بود. اما به هر حال در مسئله ما بدین معنی است که :
1. Thread-A وارد lock خواهد شد.
2. Thread-A دستور await را اجرا کرده و اجرای دستور را به Thread-B واگذار می کند تا به صورت asynchronous فعالیت انجام شود.
3. پس از اتمام کار Thread-B، روند اجرای برنامه به دستورِ پس از await خواهد رسید. ولی این بار Thread-C فرمانِ اجرای کد را بر عهده خواهد داشت.
4. چون thread ایی که وارد بدنه lock شده است با thread ایی که می خواهد از آن خارج شود، متفاوت است، با خطا رو به رو خواهیم شد.

* در دات نت ابزارهای Synchronization ایی نظیر Monitor، Mutex و ReaderWriterLock دارای Thread Affinity می باشند. پس در حیطه کنترل این ها نمی توانیم از async استفاده کنیم.

* عبارت lock، در پس پرده از Monitor برای مدیریت همزمانی Thread ها استفاده می کند. به همین خاطر است که در بدنه lock نمی توانیم از متد های async استفاده کنیم.

* اما ابزارهای Semaphore و SemaphoreSlim دچار این مشکل نمی باشند و لازم نیست Thread ایی که وارد منطقه بحرانی می شود، همان Thread ایی باشد که از آن خارج می شود.

https://blog.cdemi.io/async-waiting-inside-c-sharp-locks/

https://msdn.microsoft.com/en-us/library/ms228964(v=vs.110).aspx


@irandotnet

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.

#پست_مجدد این پست تا به حال بیش از ۲۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

وجود یک «لکه» یا Blob در کد برنامه شما یک نمونه ضد الگوی برنامه نویسی (Anti Pattern) محسوب می‌شود. یکی از علائمی که نشان می‌دهد برنامه شما لکه دارد، زمانی است که از این جمله استفاده می‌کنید: «این قسمت از کد، قلب سیستم است»
وقتی از این جمله استفاده می‌کنید، یعنی قسمتی از کد شما وجود دارد که در آن حجم زیادی از منطق برنامه شما نوشته شده‌است و شکسته نشده‌است. لکه‌ها تمایل به بزرگ شدن دارند،‌ یعنی خیلی وقت‌ها برای نوشتن یک کد جدید، احساس‌ می‌کنید باید آن را به «قلب سیستم» اضافه کنید. خیلی وقت‌ها علت این مشکل معماری بد و یا حتی «نبود معماری» است.

لینک زیر بیشتر در مورد این Anti Pattern توضیح داده است.

https://sourcemaking.com/antipatterns/the-blob

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

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

http://uxmag.com/articles/the-price-of-not-using-ux-patterns

#مهران_داودی
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

یکی از مهمترین پارامترهای یک کد خوب، نامگذاری صحیح متغییر‌ها، متدها، کلاس‌ها و سایر اجزای برنامه‌نویسی است. در هر زبان برنامه نویسی معمولا Convention هایی وجود دارد که رعایت آنها باعث می‌شود کد شما برای سایر برنامه‌نویسان آن زبان نیز خوانا باشد. اگر شما با زبان‌هایی مانند C# یا VB.NET برنامه می‌نویسید، مستند زیر استاندارد نامگذاری رعایت شده در .NET Framework را نشان می‌دهد. این مستند که به FDG یا Framework Design Guidelines معروف است، مستند استانداردی است که قبل ساخته شدن .Net Framework توسط یک تیم خبره نوشته شد و تمام تیم‌های برنامه نویسی داخل شرکت مایکروسافت موظف به رعایت آن هستند. این مستند هم به صورت کتابی به همین نام منتشر شده و هم همیشه آخرین نسخه آن از طریق لینک زیر قابل مطالعه و دسترسی است.

https://msdn.microsoft.com/en-us/library/ms229002%28v=vs.110%29.aspx

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

پروفایل کردن برنامه‌ها در نرم‌افزارهای بزرگ و سازمانی معمولا بسیار مهم است. منظور از Profiling بررسی برنامه از لحاظ «سرعت» و «مصرف حافظه» است. این کار معمولا توسط Profiler ها انجام می‌شود. این ابزارها کمک می‌کنند تا بتوان هنگام اجرای برنامه خط به خط و متد به متد برنامه‌تان را از لحاظ مقدار زمان مصرف شده بررسی کرد و نقاطی را که باعث کندی می‌شود، شناسایی کرد. برای این منظور ابزارهای زیادی وجود دارد. اما به تازگی مقدار زیادی از این امکانات به ادیتور خود Visual Studio در نسخه 2015 اضافه شده‌است که این امکان را می‌دهد بتوانید برنامه‌ها را بسیار راحت، جذاب و با کارایی بالا پروفایل کنید.
لینک زیر در مورد نحوه استفاده از این امکانات در VS 2015 شرح می‌دهد.

http://www.codeguru.com/csharp/.net/net_debugging/asp.net-performance-improvements-and-vs2015-profiler.html

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy



___

#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

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

http://blog.scrum.ir/2016/03/report-of-an-agile-project-simplydesk/

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

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

http://searchsoftwarequality.techtarget.com/feature/How-to-choose-cross-platform-app-development-tools

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

کانال تلگرام:
@SoftwarePhilosophy


___

در سایت بسیار خوب dotnettips.info آقای خلیلی زحمت نگارش مطلبی را تحت عنوان "پیاده سازی Row Level Security در Entity Framerwork" را کشیده اند.

http://www.dotnettips.info/post/2474/%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-row-level-security-%D8%AF%D8%B1-entity-framework

در این مقاله سعی شده است روشی برای توسعه نرم افزار های Multi Tenant معرفی شود و برای اینکار از الگوی Repository استفاده کرده اند.
پیاده سازی Multi Tenant توسط repository ها امری شایع می باشد و فکر می کنم سورس کدهای برخی محصولات شرکت های معتبری نظیر همکاران سیستم هم از این روش استفاده می کنند.
اما این روش دارای نقاط ضعفی می باشد.
1. اینکه اصولا استفاده از Repository ها بر سر Entity Framework روش مناسبی نمی باشد. در اینباره پیشتر مطالبی در کانال آورده شده بود. جز موارد بسیار معدود، استفاده از Repository فقط موجب ایجاد افزونگی در ساختار کد شده و هیچ ارزشی به سیستم اضافه نمی کند.
2. در روش آقای خلیلی نمی توانیم موجودیت ها را به روش Eager Loading و یا Lazy Loading بارگذاری کنیم. چرا که در این روش ها فیلترینگی به طور خودکار اعمال نمی شود و موجب نشت اطلاعات خواهد شد. پس این قابلیت کاربردی را به راحتی از دست خواهیم داد.
3. با وجود قابلیت Interceptor ها و کتابخانه هایی نظیر DynamicFilters به نظر می رسد هر روش دیگری برای پیاده سازی Multi Tenancy موجب پیچیده شدن بیش از حد ساختار کد خواهد شد.
4. در آینده هم خواهیم دید با معرفی شدن Row Level Security در نسخه SQL Server 2016، پیاده سازی Multi Tenancy قطعا به درون ساختار SQL Server هدایت خواهد شد.

در دو پست قبلی می توانید مطالب بیشتری را در این مورد ببینید.

@irandotnet

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

«چگونه استراتژی (و نه تکنولوژی) عامل اصلی تحول دیجیتالی سازمان شماست» این عنوان مقاله‌ زیر است که توضیح می‌دهد چگونه استراتژی تاثیرگذاری زیادی در فرایند دیجیتالی شدن یک سازمان دارد.

https://datafloq.com/read/how-strategy-not-technology-driver-transformation/2105?ref=quuu&utm_content=buffer6b7ab&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy


___

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

https://yalantis.com/blog/how-much-does-it-cost-to-develop-an-app/

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

کانال تلگرام:
@SoftwarePhilosophy


___

استفاده از تاریخ و زمان در زبان‌های برنامه‌نویسی همواره برای برنامه نویسان دردسر ساز بوده است. این مشکل به ویژه برای برنامه نویسان ایرانی مشهود است زیرا همیشه درگیر تبدیل تاریخ‌های میلادی و شمسی به یکدیگرند.
اما واقعا چرا مفهوم تاریخ در علم کامپیوتر و متعاقبا زبان‌های برنامه‌نویسی دردسر سازند؟
در مورد یک عدد عبارت ۱۰۰ تا بعد از ۳۰۰ چند می‌شود معنی دقیقی دارد و جواب ۴۰۰ است. ولی در مورد تاریخ عبارت «یک ماه» بعد از ۱۶ شهریور چه روزی است جواب دقیقی ندارد. آیا منظور از یک ماه ۳۰ روز است یا ۳۱ روز؟ با هر کدام از این فرضیه‌ها جواب ممکن است ۱۵ شهریور یا ۱۶ شهریور باشد.
مقاله زیر به صورت کامل‌تری پیچیدگی‌هایی را که تاریخ و زمان با خود به دنیای برنامه‌نویسی آورده‌اند را توضیح داده‌است.

http://mehrandvd.me/2016/07/26/datetime-complexities-programming-languages/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy


___

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارند «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید و این پیغام را برای آنها Forward کنید.

#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.

در کنفرانس BUILD 2016 امکان اجرای کامندهای Bash و باینری‌های Ubuntu Linux روی ویندوز ۱۰ نمایش داده شد. طبق مطالب گفته شده در کنفرانس که توسط Kevin Gall ارائه شد، این کامندها مستقیما روی سیستم عامل اجرا خواهد شد و ماشین مجازی (VM) در میان نخواهد بود.
کامندهای Bash ابزاری معادل Command یا PowerShell در سیستم عامل لینوکس است که بسیار قدرتمند و محبوب است. لینک توضیحات بیشتری را در مورد این قابلیت می‌دهد.

http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUsermodeUbuntuLinuxBinariesOnWindows10.aspx

#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd


کانال تلگرام:
@SoftwarePhilosophy


___

فریم‌ورک Aurelia یکی از فریم‌ورک‌هایی است که به نظر می‌رسد آینده خیلی خوبی در بازار داشته باشد. معماری این فریم‌ورک بسیار با رویکردهای جدید معماری فریم‌ورک‌های کلاینت‌ساید تطابق دارد. یکی از نقاط قوت این فریم‌ورک نسبت به Angular 2 سر راست بودن مفاهیم در آن و خوانایی بسیار زیاد Binding Syntax در آن است.
مقاله زیر از Aurelia HUB کمک می‌کند در زمان بسیار کوتاهی یک برنامه To Do List با این زیرساخت بنویسید و با امکانات قدرتمند و در عین حال ساده آن آشنا شوید.

http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/quick-start/6

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy


___

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

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

یکی از ساده ترین مصداق های این موضوع انتخاب بین Entity Framework، ADO.NET و Dapper می باشد. همه ما می دانیم که قطعا Entity Framework از دیگر روش ها کارایی پایین تری خواهد داشت، حتی با به کار بستن ترفند های خاصِ خودش. پس انتخاب Entity Framework چه مزیتی خواهد داشت؟

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

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

https://www.exceptionnotfound.net/dapper-vs-entity-framework-vs-ado-net-performance-benchmarking/