برای چک کردن برابری در Java، از متد equals() كلاس Object استفاده مى‌شود که برای هر کلاس می‌تواند تعریف متفاوتی داشته باشد. از این متد در collection ها نیز استفاده می شود.
زمانى كه قرار است چک شود كه يك collection شامل شئ خاصى هست يا نه، collection بر روى تمام شئ‌ها equality را با شئ مورد نظر چك مى كند.
در Hash-based collection ها براى جستجوی یک شئ روش سریع تری دارد. در زمان ذخیره شئ، متد hashCode() بر اساس key داده شده، يك hash code توليد مى كند كه مشخص مى كند آن را در كدام area ذخيره كند و در زمان بازیابی به همین شکل مشخص می کند که شی در کدام area ذخیره شده است. از آنجا که اين متد ممكن است براى آبجكت هاى نابرابر، hash code هاى يكسان توليد كند، بنابراين لازم است كه equality براى آبجكت هايى كه در يك area هستند نیز چك شود.
بعد از خواندن اين مقاله به خوبى متوجه خواهيد شد كه چرا:
١.هر دو آبجكتى كه hash code يكسان دارند لزوما برابر نيستند.
٢.هر دو آبجكتى كه با هم برابرند حتما hash code يكسانى باید داشته باشند. (به همین دلیل نیز بهتر است که در صورت تعریف متد equals() در یک کلاس، متدhashCode() آن را نیز مجددا تعریف کرد).

https://tutorials.jenkov.com/java-collections/hashcode-equals.html

#زهره_مرادی

لینکدین:
https://ir.linkedin.com/in/zohre-moradi

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



___

پیاده سازیِ سیاست دسترسی به داده ها توسط ویژگی RLS در SQL Server 2016

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

در EF6 قابلیتی به نام Interception وجود دارد که با استفاده از آن می توان سیاست دسترسی به داده را در لایه های پایینی طراحی کرد. در این روش برنامه نویس لایه هایی بالا، بدون آنکه درگیر مفاهیمی مانند Tenant و سیاست ها بشود، می تواند به راحتی کوئری هایش را تولید کند. سپس EF به طور خودکار تغییری در کوئری ها خواهد داد تا دسترسی های لازم رعایت کرده باشد. برای اینکار می توانید از کتابخانه EntityFramework.DynamicFilters استفاده کنید.

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

در SQL Server 2016 قابلیتی به نام Row Level Security وجود دارد، که به ما اجازه می دهد سیاست های دسترسی با داده را در لایه پایگاه داده متمرکز کنیم. در این صورت اپلیکشن ها هیچگونه آگاهی ایی نسبت به سیاست ها نخواهند داشت و درگیر این مفاهیم در سطح کد نخواهیم بود. همچنین در صورت لزوم به تغییر سیاست ها، فقط لازم است تغییراتی را در پایگاه داده بدهیم. با این روش، به هر طریقی و از هر ابزاری که به پایگاه داده کوئری هایمان را ارسال کنیم، سیاست های دسترسی به داده اعمال خواهند شد و امنیت بالا و البته ریزدانه ای (granular) را خواهیم داشت.

در مثال زیر خواهیم دید که چگونه می توان با استفاده از EF6 از ویژگی RLS بهره برد. این مثال یکی دیگر از کاربرد های Interception را نیز توضیح می دهد.

https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-entity-framework-row-level-security/

چرا از متد های 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 ممکن است محصول شما را با ریسک شکست مواجه کند.
مقاله زیر توضیح می‌دهد که استفاده نکردن از الگوهایی که کاربران از قبل به آنها عادت کرده‌اند چطور می‌تواند باعث خستگی کاربران شود و در نتیجه محصول شما را رها کنند.

https://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 شرح می‌دهد.

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

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

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



___

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

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

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

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


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


___

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

https://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" را کشیده اند.

https://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


___

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

https://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 در سیستم عامل لینوکس است که بسیار قدرتمند و محبوب است. لینک توضیحات بیشتری را در مورد این قابلیت می‌دهد.

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

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


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


___