Forwarded from Iran .Net
الگوی 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
این الگو، یکی از الگوهای اصلی در سیستم های غیرمتمرکز (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
martinfowler.com
bliki: Circuit Breaker
You use software circuit breakers on connections to remote services. These breakers trip when the supplier becomes unresponsive, once tripped the breaker no longer calls the supplier until reset.
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
#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
۱. آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
#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
Telegram
Software Philosophy
آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای…
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای…
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
___
یک 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
___
ولی در کنار قدرتی که به توسعه دهندگان میدهد برخی مشکلات را هم به همراه دارد که باعث شد غولهای تکنولوژی مانند فیسبوک و گوگل شروع به تولید 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
___
Scotch
Yarn Package Manager: An Improvement over npm
Yarn is the newest package manager on the block with speed and improvements over npm.
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مفهوم CQRS Pattern به عنوانی یکی از الگوهای رایجی است که نام آن در معماریهای جدید نرمافزار زیاد شنیده میشود. به طور خلاصه، این الگو جدا کردن معماری «خواندن» اطلاعات از معماری «نوشتن» اطلاعات است. هر عمل خواندن در نرمافزار توسط یک Query انجام میشود که هیچ تغییری در سیستم نمیدهد و فقط نتیجه خواندن را بر میگرداند. هر عمل نوشتن در سیستم از طریق یک Command انجام میشود که فقط تغییر را در سیستم اعمای میکند و هیچ اطلاعاتی بر نمیگرداند (به جز وضعیت موفق بودن عمل و یا پیغام خطا). این الگو بسیار کاربردی و قدرتمند است، ولی استفاده از آن در هر شرایطی مناسب نمیباشد.
مقاله زیر این الگو را به سادگی توضیح دادهاست و کاربرد آن را در معماریهای مختلف شرح دادهاست.
https://msdn.microsoft.com/en-us/library/jj591573.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر این الگو را به سادگی توضیح دادهاست و کاربرد آن را در معماریهای مختلف شرح دادهاست.
https://msdn.microsoft.com/en-us/library/jj591573.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
اثری که Body language بر خود فرد میگذارد، اگر بیشتر از اثری که بر مخاطب میگذارد نباشد، کمتر هم نیست.
استاد دانشگاه هاروارد Amy Cuddy تحقیقی انجام داده است و در آن به این نتیجه رسیده است که فرم و حالت بدن میتواند بر «ذهن» و «فیزیولوژی» اثر گذارد، بدین صورت که اگر شما ۲ دقیقه ژست یک فرد پیروز را به خود بگیرید میزان تستوسترون افزایش و کورتیزول کاهش میابد. میزان این هورمونها اثر مستقیمی بر مغر گذاشته و میتواند باعث افزایش قدرت ریسکپذیری و موفقیت شود.
https://www.ted.com/talks/amy_cuddy_your_body_language_shapes_who_you_are
#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati
کانال تلگرام:
@SoftwarePhilosophy
___
استاد دانشگاه هاروارد Amy Cuddy تحقیقی انجام داده است و در آن به این نتیجه رسیده است که فرم و حالت بدن میتواند بر «ذهن» و «فیزیولوژی» اثر گذارد، بدین صورت که اگر شما ۲ دقیقه ژست یک فرد پیروز را به خود بگیرید میزان تستوسترون افزایش و کورتیزول کاهش میابد. میزان این هورمونها اثر مستقیمی بر مغر گذاشته و میتواند باعث افزایش قدرت ریسکپذیری و موفقیت شود.
https://www.ted.com/talks/amy_cuddy_your_body_language_shapes_who_you_are
#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati
کانال تلگرام:
@SoftwarePhilosophy
___
مدل Actor به عنوان یک مدل messaging برای برنامهنویسی توزیع شده و همزمان در مقابل استفاده از thread ها به حساب میآید. زبانهای برنامهنویسی Erlang و Elixir بر پایه این مدل ارئه شده است. همچنین فریمورکهایی برای استفاده از این مدل قدرتمند در زبانهای برنامهنویسی دیگر نیز ارائه شدهاند که از آن جمله میتوان به Akka اشاره کرد.
آکا پروژهای open source میباشد که با استفاده از مدل Actor فریمورکی را در اختیار برنامهنویسان دیگر زبانها از جمله جاوا و اسکالا گذاشته تا به کمک آن سیستمهای concurrent و scalable تولید کنند و همچنین برای برنامهنویسان .net نیز فریم ورک Akka.net ارائه شده که بوسیله هر دو زبان C# و F# قابل استفاده است.
در مقاله زیر علاوه بر مقایسه دقیقتر بین دو مفهوم Multi Thread و Actor Model به صورت کامل به نحوه پیادهسازی و استفاده از Akka.net پرداخته شده است.
https://www.codeproject.com/articles/1007161/a-look-at-akka-net
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
آکا پروژهای open source میباشد که با استفاده از مدل Actor فریمورکی را در اختیار برنامهنویسان دیگر زبانها از جمله جاوا و اسکالا گذاشته تا به کمک آن سیستمهای concurrent و scalable تولید کنند و همچنین برای برنامهنویسان .net نیز فریم ورک Akka.net ارائه شده که بوسیله هر دو زبان C# و F# قابل استفاده است.
در مقاله زیر علاوه بر مقایسه دقیقتر بین دو مفهوم Multi Thread و Actor Model به صورت کامل به نحوه پیادهسازی و استفاده از Akka.net پرداخته شده است.
https://www.codeproject.com/articles/1007161/a-look-at-akka-net
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
Codeproject
A Look At Akka.NET - CodeProject
A brief look at using the .NET Akka framework (Akka.NET); Author: Sacha Barber; Updated: 6 Jul 2015; Section: C#; Chapter: Languages; Updated: 6 Jul 2015
Forwarded from Iran Agile
چگونه به مشتری نه بگوییم?
مسلما اگر بخواهیم محصول خوبی بسازیم، باید در "نه" گفتن مهارت خوبی بدست آوریم. اما چگونه باید نه گفت?
📰 📝
🌐 https://blog.intercom.com/say-no-to-customers/
@iranagile
مسلما اگر بخواهیم محصول خوبی بسازیم، باید در "نه" گفتن مهارت خوبی بدست آوریم. اما چگونه باید نه گفت?
📰 📝
🌐 https://blog.intercom.com/say-no-to-customers/
@iranagile
The Intercom Blog
How do you say no to customers?
As much as you'd like to, you can't always give customers what they want. Here's how to say no in a positive, personal way.
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. به جواب درست میرسید، اگر سوال درست بپرسید
#management #communication
https://news.1rj.ru/str/SoftwarePhilosophy/644
۲. آشنایی با Yarn و نحوه شروع به کار با آن
#javanoscript
https://news.1rj.ru/str/SoftwarePhilosophy/645
۳. توضیحاتی در مورد CQRS Pattern و کاربرد آن در معماریهای مختلف
#designpattern #CQRS
https://news.1rj.ru/str/SoftwarePhilosophy/647
۴. تاثیرات «زبان بدن» بر خود فرد: Fake it until you Make it
#management
https://news.1rj.ru/str/SoftwarePhilosophy/648
https://news.1rj.ru/str/SoftwarePhilosophy/649
۵. فریمورک Akka.net برای برنامهنویسی توزیعشده
#dotnet #parallel #framework
https://news.1rj.ru/str/SoftwarePhilosophy/650
۶. چگونه به مشتری نه بگوییم (Iran Agile)
#management #communication
https://news.1rj.ru/str/SoftwarePhilosophy/651
ـــــــــــ
@SoftwarePhilosophy
۱. به جواب درست میرسید، اگر سوال درست بپرسید
#management #communication
https://news.1rj.ru/str/SoftwarePhilosophy/644
۲. آشنایی با Yarn و نحوه شروع به کار با آن
#javanoscript
https://news.1rj.ru/str/SoftwarePhilosophy/645
۳. توضیحاتی در مورد CQRS Pattern و کاربرد آن در معماریهای مختلف
#designpattern #CQRS
https://news.1rj.ru/str/SoftwarePhilosophy/647
۴. تاثیرات «زبان بدن» بر خود فرد: Fake it until you Make it
#management
https://news.1rj.ru/str/SoftwarePhilosophy/648
https://news.1rj.ru/str/SoftwarePhilosophy/649
۵. فریمورک Akka.net برای برنامهنویسی توزیعشده
#dotnet #parallel #framework
https://news.1rj.ru/str/SoftwarePhilosophy/650
۶. چگونه به مشتری نه بگوییم (Iran Agile)
#management #communication
https://news.1rj.ru/str/SoftwarePhilosophy/651
ـــــــــــ
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
دنیای AR یا Augmented Reality باعث ایجاد مفاهیم جدیدی در UI/UX شدهاست. توان خلق موجودیتها در فضای اطراف کاربر امکانی است که قبلا وجود نداشته و به همین دلیل ظهور AR باعث ایجاد تجربیات جدیدی در دنیای UX شدهاست.
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح میدهد که در نسخههای اولیه نرمافزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی میکرد (مثلا طراحی یک اسباببازی). پس از تستهای UX متوجه شدند چهارگوش بودن میز باعث میشود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی میکنند بچرخند. به همین دلیل در نسخههای بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمیایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را میبینند.
در مقاله زیر طراح ارشد تجربیات خود و درسهایی که تا به حال از انجام پروژههای هولوگرافیک کسب کرده را توضیح داده و چند مثال جذاب دیگر را هم بیان کرده است.
https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح میدهد که در نسخههای اولیه نرمافزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی میکرد (مثلا طراحی یک اسباببازی). پس از تستهای UX متوجه شدند چهارگوش بودن میز باعث میشود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی میکنند بچرخند. به همین دلیل در نسخههای بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمیایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را میبینند.
در مقاله زیر طراح ارشد تجربیات خود و درسهایی که تا به حال از انجام پروژههای هولوگرافیک کسب کرده را توضیح داده و چند مثال جذاب دیگر را هم بیان کرده است.
https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from Iran .Net
اصل پیشاهنگی یا The Boy Scout Principle
این اصل، از یک اصلِ فلسفی بریتانیایی برداشت شده است: "سعی کنیم جهان را - به نسبت آنچه که پیش تر یافته ایم - جای بهتری کنیم".
در کتاب خواندنی "97 نکته ای که هر برنامه نویس باید بداند"، Uncle Bob با استفاده از این اصل، اصلی دیگر را در حوزه نرم افزار بیان می کند: "هر بار کدی را دیدیم، به نسبت قبل آن را بهتر کنیم." در این میان مهم نیست که کدام یک از اعضای تیم قبلا این کد را زده و یا مقدار بهبود چه حد کوچک باشد. این بهبود می تواند به کوچکی تغییر نام متغیر ها، کم کردن تکرار (duplication) ، کوتاه کردن یک متد طولانی و خواناتر کردن کد و ... باشد.
در جهان، همه هستی (اعم از نرم افزار) به طور طبیعی به ویرانی و آشوب و فرسودگی میل می کند و برای جلوگیری از این امر ما باید انرژی مصرف کنیم و تعهد داشته باشیم. در نرم افزار هم وقتی همه اعضای تیم به این اصل متعهد باشند، ساختار کد به جای هرز رفتن در گذر زمان، روز به روز و به تدریج بهتر خواهد شد.
همانطور که آشغال ریختن در طبیعت، عملی خلاف شعور و فرهنگ می باشد، این اصل بیان می کند که اصلاح نکردن کد در صورت مشاهده ایراد و ضعف به همان میزان دور از فرهنگ و تعهد و حرفه ای گری است. قرار نیست فقط به کد های خودمان اهمیت بدهیم و نسبت به آن ها حساس باشیم. هر کدام از اعضای تیم باید نسبت به کیفیت کار کل تیم حساس بوده و سعی در بهبود داشته باشند.
1. یادداشت عمو باب در مورد اصل پیشاهنگی
http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
2. در مقاله "ریفکتورینگ فرصت طلبانه"، مارتین فاولر توضیح می دهد که چطور علی رغم وجود دوره هایی برای اصلاح ساختاری سیستم، باید تیم همواره و هر جا و هر زمانی نسبت به ریفکتورینگ و اصلاح کد تعهد داشته باشد. در اینجا فاولر فرصت های متعددی را که در حین کار با کد های سیستم پیش می آید، مطرح می کند و هر کدام را به عنوان فرصتی برای ریفکتورینگ مغتنم می شمارد. فاولر معتقد است ریفکتورینگ یک امر و اصل همیشگی و جاری در سیستم باید باشد.اگر با تیمی مواجه هستیم که همیشه برای اصلاح کد ها نیاز به برنامه ریزی و جلسات متعدد دارد، یک جای کار می لنگد!.
https://martinfowler.com/bliki/OpportunisticRefactoring.html
این اصل، از یک اصلِ فلسفی بریتانیایی برداشت شده است: "سعی کنیم جهان را - به نسبت آنچه که پیش تر یافته ایم - جای بهتری کنیم".
در کتاب خواندنی "97 نکته ای که هر برنامه نویس باید بداند"، Uncle Bob با استفاده از این اصل، اصلی دیگر را در حوزه نرم افزار بیان می کند: "هر بار کدی را دیدیم، به نسبت قبل آن را بهتر کنیم." در این میان مهم نیست که کدام یک از اعضای تیم قبلا این کد را زده و یا مقدار بهبود چه حد کوچک باشد. این بهبود می تواند به کوچکی تغییر نام متغیر ها، کم کردن تکرار (duplication) ، کوتاه کردن یک متد طولانی و خواناتر کردن کد و ... باشد.
در جهان، همه هستی (اعم از نرم افزار) به طور طبیعی به ویرانی و آشوب و فرسودگی میل می کند و برای جلوگیری از این امر ما باید انرژی مصرف کنیم و تعهد داشته باشیم. در نرم افزار هم وقتی همه اعضای تیم به این اصل متعهد باشند، ساختار کد به جای هرز رفتن در گذر زمان، روز به روز و به تدریج بهتر خواهد شد.
همانطور که آشغال ریختن در طبیعت، عملی خلاف شعور و فرهنگ می باشد، این اصل بیان می کند که اصلاح نکردن کد در صورت مشاهده ایراد و ضعف به همان میزان دور از فرهنگ و تعهد و حرفه ای گری است. قرار نیست فقط به کد های خودمان اهمیت بدهیم و نسبت به آن ها حساس باشیم. هر کدام از اعضای تیم باید نسبت به کیفیت کار کل تیم حساس بوده و سعی در بهبود داشته باشند.
1. یادداشت عمو باب در مورد اصل پیشاهنگی
http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
2. در مقاله "ریفکتورینگ فرصت طلبانه"، مارتین فاولر توضیح می دهد که چطور علی رغم وجود دوره هایی برای اصلاح ساختاری سیستم، باید تیم همواره و هر جا و هر زمانی نسبت به ریفکتورینگ و اصلاح کد تعهد داشته باشد. در اینجا فاولر فرصت های متعددی را که در حین کار با کد های سیستم پیش می آید، مطرح می کند و هر کدام را به عنوان فرصتی برای ریفکتورینگ مغتنم می شمارد. فاولر معتقد است ریفکتورینگ یک امر و اصل همیشگی و جاری در سیستم باید باشد.اگر با تیمی مواجه هستیم که همیشه برای اصلاح کد ها نیاز به برنامه ریزی و جلسات متعدد دارد، یک جای کار می لنگد!.
https://martinfowler.com/bliki/OpportunisticRefactoring.html
martinfowler.com
bliki: Opportunistic Refactoring
Refactoring does not need to be planned out, mostly it is done opportunistically, to fix problems while working on another task.
Forwarded from Software Philosophy
اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارند «مهندس نرمافزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید و این پیغام را برای آنها Forward کنید.
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
سازگاری با مرورگرهای مختلف از ابتدا برای طراحان مشکلاتی را در بر داشته و مشکل از جایی عمیقتر میشود که این مرورگرها نسخههای متفاوتی دارند و شما نمیتوانید همه آنها را کنار هم داشته باشید، بخصوص که این روزها استفاده از مروگرهای تلفن همراه و تبلتها نیز بالا رفته است. پس وبسایت شما باید با همه مرورگرها سازگار و یا اصطلاحا cross-browser باشد .
از بین سرویسدهندگانی که این تستها را انجام میدهند شاید یکی از بهترین سرویسدهندگان، BrowserStack باشد. با استفاده از این سرویس میتوانید سایت خود را در بیشتر از 1000 نسخهی از مرورگرهای مختلف تست کنید. این تنوع شامل دستگاهها و حتی سیستم عاملهای مختلف میشود. همینطور این امکان را به شما میدهد تا بتوانید نسخهی اجرای شدهی سایت خود را در نسخههای مختلف مرورگرها، حتی دستگاههای مختلف توسط اسکرین شات ببنید. مهمترین قابلیت آن تست سایتهای local و خصوصی به اکثر زبانهای برنامه نویسی میباشد.
میتوانید به کمک لینک زیر از سایت خود روی مرورگرهای مختلف اسکرین شات بگیرید.
https://www.browserstack.com/screenshots
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
از بین سرویسدهندگانی که این تستها را انجام میدهند شاید یکی از بهترین سرویسدهندگان، BrowserStack باشد. با استفاده از این سرویس میتوانید سایت خود را در بیشتر از 1000 نسخهی از مرورگرهای مختلف تست کنید. این تنوع شامل دستگاهها و حتی سیستم عاملهای مختلف میشود. همینطور این امکان را به شما میدهد تا بتوانید نسخهی اجرای شدهی سایت خود را در نسخههای مختلف مرورگرها، حتی دستگاههای مختلف توسط اسکرین شات ببنید. مهمترین قابلیت آن تست سایتهای local و خصوصی به اکثر زبانهای برنامه نویسی میباشد.
میتوانید به کمک لینک زیر از سایت خود روی مرورگرهای مختلف اسکرین شات بگیرید.
https://www.browserstack.com/screenshots
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
Browserstack
Browser Screenshots For Quick Testing On 3000+ Real Browsers | BrowserStack
Generate Screenshots of your Website on Chrome, IE, Firefox and Safari to test for Cross Browser compatibility on desktop browsers and real mobile devices.
Forwarded from Iran Agile
چگونه محصولی کاملا متمایز از رقبا ارایه دهید
با افزایش رقابت، ایجاد تمایز در محصولها کار بسیار سختی است و واقعیت این است که محصول شما بدون رقیب نیست. در نتیجه باید از این مسئله اطمینان حاصل کنید که محصول دارای ویژگیهای متمایزی بوده و دلیل قانع کننده ای به مشتری برای استفاده از آن به جای محصولات مشابه می دهد. Strategy Canvas یک ابزار بسیار مناسب برای رسیدن و سنجیدن این مسئله است. بوم استراتژی توسط کیم و مابورگن خالقان تئوری اقیانوس آبی معرفی شد.
📰 📝
🌐 http://blog.scrum.ir/2017/01/strategy-canvas/
@iranagile
با افزایش رقابت، ایجاد تمایز در محصولها کار بسیار سختی است و واقعیت این است که محصول شما بدون رقیب نیست. در نتیجه باید از این مسئله اطمینان حاصل کنید که محصول دارای ویژگیهای متمایزی بوده و دلیل قانع کننده ای به مشتری برای استفاده از آن به جای محصولات مشابه می دهد. Strategy Canvas یک ابزار بسیار مناسب برای رسیدن و سنجیدن این مسئله است. بوم استراتژی توسط کیم و مابورگن خالقان تئوری اقیانوس آبی معرفی شد.
📰 📝
🌐 http://blog.scrum.ir/2017/01/strategy-canvas/
@iranagile
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مفهوم «Saga» در معماری نرمافزار مفهومی است که اخیرا در مقالههای مربوط به CQRS Pattern بسیار زیاد از آن صحبت میشود.
با این که مفهوم بیشتر از طریق CQRS شناخته شدهاست ولی در حقیقت این مفهوم از قبل وجود داشتهاست. مفهوم Saga اولین بار در مقالهای با نام «Sagas» توسط «هکتور گارسیا» و «کنت سالم» در سال سال ۱۹۸۷ معرفی شد. لینک زیر این مفهوم را با نام «Process Manager» معرفی کرده و این نام را نام بهتری برای این مفهوم دانسته.
مطلب زیر یکی از بهترین منابع برای آشنایی با مفهوم Saga است که به سادگی آن را توضیح داده است. در این مقاله مفهوم Saga با یک مثال ساده بیزنسی شرح داده شده و کاربرد آن در مقایسه با سایر روشها بررسی شدهآست.
https://msdn.microsoft.com/en-us/library/jj591569.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
با این که مفهوم بیشتر از طریق CQRS شناخته شدهاست ولی در حقیقت این مفهوم از قبل وجود داشتهاست. مفهوم Saga اولین بار در مقالهای با نام «Sagas» توسط «هکتور گارسیا» و «کنت سالم» در سال سال ۱۹۸۷ معرفی شد. لینک زیر این مفهوم را با نام «Process Manager» معرفی کرده و این نام را نام بهتری برای این مفهوم دانسته.
مطلب زیر یکی از بهترین منابع برای آشنایی با مفهوم Saga است که به سادگی آن را توضیح داده است. در این مقاله مفهوم Saga با یک مثال ساده بیزنسی شرح داده شده و کاربرد آن در مقایسه با سایر روشها بررسی شدهآست.
https://msdn.microsoft.com/en-us/library/jj591569.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
اگر قصد انتخاب فریم ورکی برای ساخت برنامههای تک صفحهای سمت کاربر را دارید حتما میدانید که انتخابهای زیادی پیش روی شما قرار دارد که از آن جمله میتوان به Angular 1 , Durandal , React یا Ember اشاره کرد. اما فریم ورکهای جدیدتر Angular2 و Aurelia که توجه زیادی را به خود جلب کردهاند میتوانند جزو اولویتهای شما قرار بگیرد، ولی "کدام یک بهتر است؟" این سوالی است که همه با آن مواجه میشوند و افرادی که تجربه کار با Angular1 را دارند شاید بر این باور باشند که مطمئنا Angular2 انتخاب مناسبتری است ولی در واقع این دو فرم ورک فقط در نام Angular با هم مشترک هستند و در Angular2 شاهد بازنویسی کامل ساختار فریم ورک میباشیم.
تصمیم گیری بین این دو میتواند شما را با چالش مواجه کند زیرا هر دو دارای طراحی فوق العاده و قدرتمندی میباشند که تمام نیازها برای ساخت برنامههای تک صفحهای را برآورده میکنند و همینطور پشتوانه تجاری خوب آنها از دیگر ویژگیهای این دو به شمار میرود. به همین دلیل میتوان گفت بین این دو فریم ورک قدرتمند برندهای وجود ندارد ولی تفاوت های زیادی از قبیل معماری یا Data binding با هم دارند. مقایسه این موارد میتواند در تصمیم گیری به شما کمک کند تا از میان فریم ورکها راحتتر انتخاب کنید.
لینک زیر به شرح مقایسه بین فریم ورک های Aurelia و Angular2 می پردازد.
https://www.pluralsight.com/blog/software-development/angular-2-vs-aurelia
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
تصمیم گیری بین این دو میتواند شما را با چالش مواجه کند زیرا هر دو دارای طراحی فوق العاده و قدرتمندی میباشند که تمام نیازها برای ساخت برنامههای تک صفحهای را برآورده میکنند و همینطور پشتوانه تجاری خوب آنها از دیگر ویژگیهای این دو به شمار میرود. به همین دلیل میتوان گفت بین این دو فریم ورک قدرتمند برندهای وجود ندارد ولی تفاوت های زیادی از قبیل معماری یا Data binding با هم دارند. مقایسه این موارد میتواند در تصمیم گیری به شما کمک کند تا از میان فریم ورکها راحتتر انتخاب کنید.
لینک زیر به شرح مقایسه بین فریم ورک های Aurelia و Angular2 می پردازد.
https://www.pluralsight.com/blog/software-development/angular-2-vs-aurelia
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
Pluralsight
Aurelia vs. Angular 2
Learn the differences between Aurelia and Angular 2 and decide which SPA framework is right for you.