محصولی مانند BMW واقعا چگونه در ذهن ما به عنوان یک محصول با کیفیت شکل گرفته است؟ آیا ما تخصص بررسی عملکرد موتور و گیربکس آن را داریم؟ آیا مقایسه‌ای فنی روی آن انجام داده‌ایم تا بفهمیم ماشین BMW یک محصول با کیفیت است؟
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف می‌کند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه می‌کند. یک نقطه تماس می‌تواند لحظاتی باشد که مشتری با آن کار می‌کند، یا لحظاتی که مشتری پوستر محصول را می‌بیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن می‌شوند.

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

http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/

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

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

___

الگوی تلاش مجدد یا Retry Pattern

سامانه هایی که امروز توسعه داده می شوند، در بسیاری از موارد نیاز دارند تا بتوانند با سرویس ها و منابعِ خارجیِ دیگری از طریق شبکه و اینترنت و ... دسترسی داشته باشند. مثلا:

1. در ساده ترین حالت، سیستم ها نیاز دارند تا بتوانند از طریق لایه شبکه به پایگاه داده به عنوان یک منبع (Resource) خارجی دسترسی داشته باشند.
2. فرض کنید اپلیکیشن و یا وب سایتی دارید که قرار هست بخشی از محتوا و یا سرویسی که به کاربر ارائه می دهد را از طریق وب سرویس هایی که توسط شرکت های دیگری آماده شده اند، تهیه کند.
3. ممکن است سامانه ای داشته باشید که هر کدام از اجزای آن تفکیک شده هستند و از طریق وب سرویس ها با یکدیگر در ارتباط می باشند. مثلا فرض کنید سامانه ی بزرگی دارید که سیستمی مجزا برای امور مشتریان، سیستمی مجزا برای فروش و سیستم مجزا برای انبارداری دارد. به این نوع از معماری ها به اختصار Microservice هم گفته می شود. یعنی سامانه به سرویس های متعدد و تک منطوره شکسته می شود.

در این نوع از سیستم ها وقتی قرار هست درخواستی به یک منبع خارجی ارسال شود، به هر دلیلی ممکن هست که درخواست با خطا رو به رو شود. مثلا ممکن است ناپایداری در شبکه وجود داشته باشد و یا یک سرویس به طور موقت از گردانه خارج شده باشد.
برای افزایش پایداریِ سیستم ها در برابر اتفاق های اینچنین سیستم باید نوعی حالت ارتجاعی (Resiliency) داشته باشد تا در برابر حوادث گوناگون واکنش مناسبی را انجام دهد.
در اینجا است که الگوی Retry Pattern به کار می آید و یکی از الگوهایی است که باید در مواقعی که با سیستم های خارجی در تماس هستیم آن را در نظر داشته باشیم. وقتی سیستم توسط این الگو پیاده سازی شده باشد، در صورت وقوع برخی از خطا ها از کار نمی افتد و کاربران غافل گیر نخواهند شد. در این شرایط سامانه توسط یک سیاست مشخص مجددا تلاش خواهد کرد تا درخواست اش را برای سرویس خارجی مجددا ارسال کند.
در این الگو می توانید دفعات تلاش مجدد و یا فاصله بین هر تلاش را مشخص کنید.
یکی از کتابخانه های مهم دات نت که به بنیاد معتبر dotNet Foundation هم راه یافته، کتابخانه Polly می باشد که توسط آن به راحتی می توانید الگوی Retry و Circuit Breaker را پیاده سازی کنید.

1. کتابخانه Polly:
https://github.com/App-vNext/Polly

2. کتابخانه Hystrix که برای جاوا و توسط شرکت Netflix پیاده سازی شده تا بتوانند سیستم های پایداری را در معماری مایکروسرویس شان داشته باشند. (مشابه و الگوی Polly)
https://github.com/Netflix/Hystrix

3. مثالی از Polly:
https://alastaircrabtree.com/implementing-the-retry-pattern-using-polly/

4. تعریف الگوی Retry Pattern (حتما بخوانید):
https://msdn.microsoft.com/en-us/library/dn589788.aspx

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

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

یکی از مراحل مهم در چرخه تولید نرم افزار، تست آن است که باعث بهبود نرم افزار و بالا رفتن قابلیت اطمینان آن می شود.
اهمیت این مرحله به قدری است که پیشنهاد می شود فرایند تست از همان مراحل ابتدایی چرخه تولید مشخص و اجرا شود تا نواقص و مشکلات از همان ابتدا نمایان و برای رفع آنها اقدام شود.
برای برنامه ریزی اینکه تست نرم افزار چگونه باید انجام شود تا تمام سیستم و تمام امکانات آن تست شود، test case هایی نوشته میشود که هر کدام روش تست یک قسمت خاص از سیستم را مشخص می کند. جهت تکمیل این test case ها و با توجه به توسعه روز به روز محصول و همچنین تعریف test plan ها برای تست دوره ای کامل سیستم، نیاز به مدیریت دقیق و کارآمد هست.
نرم افزار Microsoft Test Manager یکی از نرم افزارهای قدرتمند در این زمینه است که امکان ایجاد Test case و همچنین دسته بندی و مدیریت آسان test planها را فراهم می کند.
لینک زیر quick start guide برای این استفاده از این نرم افزار است.

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

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

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

___

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

اگر با Owin آشنایی داشته باشید، یکی از مهمترین تعاریف آن ساختار Middleware می باشد که این امکان را به ما می‌دهد تا requestو response که بین نرم افزار و سرور تبادل می‌شود را به صورت Pipeline و سریالی از این لایه های میانی عبور دهیم تا پردازش‌های مورد نظر خود مانند authentication، authorization و... را قبل از رسیدن request به سرور انجام دهیم.
در لینک زیر اضافه کردن middleware به Owin Pipeline آموزش داده شده است و در صورتی که با Owin آشنایی لازم را ندارید ، لینک زیر در مورد استاندارد Owin و پروژه Katana که بر اساس این استاندارد پیاده سازی شده است به صورت کامل توضیح داده است.

http://www.codeproject.com/Articles/864725/ASP-NET-Understanding-OWIN-Katana-and-the-Middlewa

#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1

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

___

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

در مقاله زیر فریم‌ورک‌های معروف Mapper از لحاظ عملکرد و سرعت با یکدیگر مقایسه شده‌اند.

http://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx

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

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

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مفهوم Touch Point و نقش آن در تعریف محصولات نرم افزاری
#servicedesign
https://telegram.me/SoftwarePhilosophy/628

۲. الگوی تلاش مجدد یا Retry Pattern (ایران دات نت)
#designpattern
https://telegram.me/SoftwarePhilosophy/629

۳. نرم افزار Microsoft Test Manager و نقش آن در اجرای تست موفق
#testing
https://telegram.me/SoftwarePhilosophy/632

۴.مفهوم اضافه کردن middleware به Owin Pipeline
#owin
https://telegram.me/SoftwarePhilosophy/634

۵. مقایسه عملکرد فریم‌ورک‌های مشهور Mapper از لحظا سرعت و عملکرد
#mapper #dotnet
https://telegram.me/SoftwarePhilosophy/635

ـــــــــــ
@SoftwarePhilosophy

آیا پردازنده‌ای که با آن کار می‌کنیم می‌تواند سریعتر پردازش کند؟

برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگ‌ها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدل‌های جایگزین بهتری وجود دارد که یکی از آنها actor model می‌باشد.
اکتور یک مدل مفهومی ارائه شده برای محاسبات همزمان می‌باشد که کتابخانه‌هایی برای زبان‌های برنامه‌نویسی مختلف بر اساس این مدل ارائه شده‌اند . ایده‌ای که در این مدل وجود دارد بسیار مشابه تعاریفی است که در زبان شی‌گرایی با آن آشنایی داریم به این صورت که یک شی، یک پیغام را دریافت می‌کند و عملیاتی بر اساس پیغام دریافتی روی آن انجام می‌دهد. اما ویژگی‌های اصلی این مدل که آن را متمایز می‌کند جدا بودن هر اکتور از هم می‌باشد که هیچ‌گاه مموری را با هم به اشتراک نمی‌گذارند. هر اکتور شامل یک صندوق پستی است و اکتورها با ارسال پیغام به یکدیگر , با نگه داشتن پیغام ها در صندوق پستی , عملیات لازم را روی پیغام‌ها به صورت یکی یکی انجام می‌دهند.

مقاله زیر به شرح کامل نحوه عملکرد اکتورها و چگونگی ارتباط آنها می‌پردازد.

http://www.brianstorti.com/the-actor-model


#محمدرضا_جلیلوند

لینکدین:

http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1

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

___

یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»

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

فرض کنید می‌خواهید شغل بعدی خود را انتخاب کنید و تصمیم به رفتن به یک شرکت جدید دارید. واقعا آیا این بهترین تصمیم است؟
• این تصمیم می‌تواند در حال حاضر (سال ۲۰۱۵) بهترین تصمیم شما باشد.
• در انتهای ماه ممکن است به این نتیجه برسید که این تصمیم، نسبتا خوب بوده‌است زیرا شغل پر استرسی است.
• در سال ۲۰۱۶ ممکن است به این نتیجه برسید که تصمیم بدی گرفته‌اید چون شغل بسیار سختی است.
• در سال ۲۰۱۷ ممکن است به این نتیجه برسید که بدترین تصمیم ممکن را گرفته‌اید زیرا علی‌رقم تمام زحماتتان شرکت ورشکست شده!
• و در نهایت در سال ۲۰۲۰ به این نتیجه برسید که بهترین تصمیم تمام عمرتان را گرفته‌اید، زیرا با استفاده از تجربه‌ای که از آن شرکت به دست آورده‌اید حالا مدیرعامل شرکت مایکروسافت شده‌اید!

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

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

http://mehrandvd.me/2016/12/12/good-enough-decision-towards-best-decision/

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

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

___

Good Enough Decisio

نسخه جدید asp.net core 1.1 به تازگی منتشر شده‌است. در این نسخه امکانات جدیدی به فریم‌ورک اضافه شده‌است. از جمله این امکانات می‌توان به Middleware as Filter, Rewrite Module, View Compilation و امکانات دیگر اشاره کرد. یکپارچگی بیشتر با Azure، سهولت بیشتر در 3rd Party Dependency Injection Containers و بهبودهای Performance از دیگر تغییرات مهم نسخه 1.1 هستند.
مقاله زیر این تغییرات را به همراه مثال‌هایی توضیح داده‌است.

http://www.dotnetcurry.com/aspnet/1329/aspnet-core-11-what-is-new

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

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

___

کارایی تیم ها و سلامت فرایند های موجود در توسعه نرم افزار را باید توسط تعدادی معیار (metric) تحت سنجش قرار دهیم.
سه تا از معروف ترین معیار ها که می توانند، کارایی تیم و رضایت مشتری را مشخص کنند، Lead Time و Cycle Time و Escaping Defects می باشند.

معیار Lead Time: فاصله زمانِ درخواست مشتری با زمانی است که درخواست او در نسخه بعدی نرم افزار پیاده سازی شده است. به طور دقیق تر یعنی چه مدت پس از قرار گرفتن درخواست در Backlog پروژه، تیم توانسته این قابلیت را به نحو کامل و بدون مشکل، در نسخه بعدی پیاده سازی کرده و رضایت مشتری را کسب کند.

معیار Cycle Time: فاصله زمانِ قرار گرفتن یک تسک در اختیار تیم توسعه، تا زمان پایانِ پیاده سازی و تست آن می باشد.

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


معیار Lead Time، معیاری است که باید سعی در کاستن آن داشته باشیم و معیاری است که توسط مشتری لمس خواهد شد. در طرف دیگر، معیار Cycle Time، معیاری است که کاملا کاربردی درون تیمی خواهد داشت و می تواند برای ارزیابی داخلی مورد استفاده قرار بگیرد.

آیا در پروژه های شما Lead Time اندازه گیری می شود؟ آیا زمان مطلوبی برای آن در نظر گرفته شده است؟ چگونه آن را اندازه می گیرید؟

1. https://www.agilealliance.org/glossary/lead-time/

2. http://kanbantool.com/kanban-library/analytics-and-metrics/kanban-definition-of-lead-time-and-cycle-time#.WHFCRPl95p8

3. اندازه گیری پارامتر های فوق در TFS:
https://www.visualstudio.com/en-us/docs/report/guidance/cumulative-flow

تست جعبه سفید در عمل

همیشه نوشتن تست در تئورى کار راحت و آسانى به نظر میرسد ولی اگر تجربه عملی در این خصوص داشته باشید حتما خواهید دانست که نداشتن استراتژی و تجربه این کار را سخت و دشوار خواهد کرد.
در این مقاله گام به گام در مورد نحوه نوشتن تست های جعبه سفید بحث شده است.


📰 📝

🌐 http://reqtest.com/testing-blog/white-box-testing/

@iranagile

الگوی Circuit Breaker (قطع کننده جریان)

این الگو، یکی از الگوهای اصلی در سیستم های غیرمتمرکز (Distributed) و ابری می باشد. البته این نکته را مد نظر داشته باشید که حتی اگر محل استقرار پایگاه داده شما، از وب اپلیکیشن شما جدا است و یا در وب اپلیکیشن تان از وب سرویس های سایرین استفاده می کنید، این الگو برای تان قابل استفاده است.

این الگو کمک می کند تا پایداری کل سیستم در مواقعی یکی از سیستم ها دچار مشکل و یا کندی می شود، افزایش پیدا کند. شرکت Netflix مقاله ها و تجربه های عملی گرانبهایی را با بهره گیری از این الگو گردآوری کرده است.

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

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

در تجربه ای که اخیرا در سیستمِ توزیع شده طرح ترافیک تهران داشتیم، کند شدن یکی از سرویس ها (مثلا A) موجب شده بود تا درخواست ها را در زمانی بیشتر از 5 ثانیه پاسخ بدهد. از طرفی چون حجم درخواست های کاربران بالا بود، تعداد بسیاری درخواست در سرویس دیگری (مثلا B) که به سرویس A وابسته بود، تلنبار می شد و معطل می شدند. این انباشتگی موجب می شد تا سرویس B دچار مصرف بیش از حد حافظه و Thread ها و پایگاه داده ... شده و در نهایت پایین برود. در واقع سیستم B در تجربه ای که ما داشتیم، پس از دو دقیقه Down می شد و مجبور بودیم سیستم را مجددا ریست کنیم و این موضوع مدام تکرار می شد. در واقع نقص در یک سرویس موجب می شود، همه سرویس های دیگر به ترتیب دچار مشکل شوند.

در صورتی که از الگوی Circuit Breaker استفاده می شد،سرویس B به طور هوشمند می بایست ارسال درخواست ها به سرویس A را متوقف می کرد و جریان بین شان قطع می شد. در این صورت درخواست ها در B تلنبار نمی شدند.

همچنین Circuit Breaker در هنگامی که در وضعیت بسته قرار دارد، به طور خودکار گه گاه درخواست هایی را از خود عبور خواهد داد تا اگر مشکل برطرف شده، مجددا باز شود و جریان برقرار گردد.

1. مقاله فاولر در پاراگراف ابتدایی و انتهایی به صورت خلاصه مطالب خوبی در این زمینه دارد:
https://martinfowler.com/bliki/CircuitBreaker.html

2. مقاله مایکروسافت:
https://msdn.microsoft.com/en-us/library/dn589784.aspx

3. پیاده سازی این الگو به راحتی توسط کتابخانه معتبر Polly:
http://blog.jaywayco.co.uk/circuit-breaking-with-polly/

4. تجربه Netflix در نگهداری سیستم های توزیع شده اش و استفاده از این الگو:
http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html

http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html

@irandotnet

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. آیا پردازنده‌ای که با آن کار می‌کنیم می‌تواند سریعتر پردازش کند؟
#parallel
https://news.1rj.ru/str/SoftwarePhilosophy/637

۲. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
#management #decisionmaking
https://news.1rj.ru/str/SoftwarePhilosophy/638

۳. تغییرات در نسخه جدید asp.net core 1.1
#dotnet #dotnetcore
https://news.1rj.ru/str/SoftwarePhilosophy/639

۴. سه معیار Lead Time و Cycle Time و Escaping Defects برای اندازه‌گیری کارایی تیم و رضایت مشتری (ایران دان نت)
#teamefficiency
https://news.1rj.ru/str/SoftwarePhilosophy/640

۵. تست جعبه سفید در عمل (Iran Agile)

https://news.1rj.ru/str/SoftwarePhilosophy/641

۶. الگوی Circuit Breaker (قطع کننده جریان) (ایران دات نت)
#robustness #performance
https://news.1rj.ru/str/SoftwarePhilosophy/642

ـــــــــــ
@SoftwarePhilosophy

Asking the right question is at the heart of effective communications and information exchange.
یک functionوقتی جواب درست را برمی‌گرداند که ورودی‌ صحیح به آن داده شود. در یک ارتباط هم این قانون صادق است. شما وقتی از مخاطب جواب درست را می‌گیرد که سوال درستی بپرسید.
بسته به موقعیت باید از «نوع» درستی از سوال استفاده کرد.

انواع سوال‌های متدوال عبارتند از:

• Close Questions
• Open Question
• Funnel Question
• Probing Question
• Leading Question

Close Questions یا سوال‌های بسته به سوال‌هایی گفته می‌شود که جواب‌شان در حد «یک کلمه» یا «خیلی کوتاه» است.
از کاربرد‌های این نوع سوال میتوان به این موارد اشاره کرد.
۱- وقتی که در آخر یک جلسه نیاز به یک جمع‌بندی و نتیجه گیری دارید.
۲- وقتی که می‌خواهید اطمینان حاصل کنید که منظور طرف مقابل را درست متوجه شده‌اید.
برای این کار باید هر چیزی را که متوجه شدید به گونه‌ای بپرسید که جواب آن «بله» یا «خیر» باشد (یا در حد یک کلمه یا خیلی کوتاه). مثلا «اگر منظور شما رو درست متوجه شده باشم، من باید یک متد بنویسم که یک فایل ورد را به عنوان ورودی بگیرد و آن را تبدیل به پی‌دی‌اف کند؟»

در لینک زیر انواع سوال‌ها، همراه با موقعیت‌های که می‌شود از آن استفاده کرد، توضیح داده شده است.

https://www.mindtools.com/pages/article/newTMC_88.htm

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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

___

فراوانی پکیج‌های جاوا اسکریپت به گونه‌ای است که ما هر هفته شاهد پکیج‌های جدید متعددی هستیم و زمانی که NPM برای رفع وابستگی‌های پروژه به این پکیج‌ها معرفی شد، خیلی سریع به عنوان پیشفرض برای مدیریت پکیج‌های Node.js درآمد و بخشی از زندگی توسعه‌دهندگان شد.
ولی در کنار قدرتی که به توسعه دهندگان می‌دهد برخی مشکلات را هم به همراه دارد که باعث شد غول‌های تکنولوژی مانند فیسبوک و گوگل شروع به تولید package management بهتری با شعار "Fast, Reliable and Secure" با نام Yarn کردند که در آن مشکلاتی که توسعه دهندگان با npm داشتند رفع گردید. یکی از نکات جالب این است که Yarn مخزن خود را ندارد و در عوض از مخزن‌های دیگر از جمله npm و bower استفاده می‌کند. شاید مهمترین ویژگی Yarn که برای همه‌ی توسعه دهندگان اهمیت دارد، دو تا هفت برابر سریعتر بودن نصب پکیج‌ها نسبت به npm می‌باشد. Yarn پس از نصب هر پکیج آن را cache می‌کند و در هنگام نصب پکیج‌ها ابتدا از cache خود برای پیدا کردن پکیج مورد نظر استفاده می‌کند که علاوه بر افزایش سرعت نصب، امکان نصب پکیج‌ها بدون نیاز به اینترنت را نیز فراهم می‌کند و در صورت عدم وجود در cache آن را دانلود می‌کند. حتی برای نصب سریعتر پکیج‌ها , Yarn به صورت موازی پکیج‌ها را دانلود و نصب می‌کند.
در لینک زیر خصوصیات دیگر Yarn و همینطور شروع به استفاده از این ابزار قدرتمند بیان شده است.

https://scotch.io/tutorials/yarn-package-manager-an-improvement-over-npm

#محمدرضا_جلیلوند

لینکدین:

http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1

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

___

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

مفهوم CQRS Pattern به عنوانی یکی از الگوهای رایجی است که نام آن در معماری‌های جدید نرم‌افزار زیاد شنیده می‌شود. به طور خلاصه، این الگو جدا کردن معماری «خواندن» اطلاعات از معماری «نوشتن» اطلاعات است. هر عمل خواندن در نرم‌افزار توسط یک Query انجام می‌شود که هیچ تغییری در سیستم نمی‌دهد و فقط نتیجه خواندن را بر می‌گرداند. هر عمل نوشتن در سیستم از طریق یک Command انجام می‌شود که فقط تغییر را در سیستم اعمای می‌کند و هیچ اطلاعاتی بر نمی‌گرداند (به جز وضعیت موفق بودن عمل و یا پیغام خطا). این الگو بسیار کاربردی و قدرتمند است، ولی استفاده از آن در هر شرایطی مناسب نمی‌باشد.

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

https://msdn.microsoft.com/en-us/library/jj591573.aspx

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

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

___