#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. تنظیم محیط برنامهنویسی Linux روی Windows 10
https://news.1rj.ru/str/SoftwarePhilosophy/767
۲. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی
https://news.1rj.ru/str/SoftwarePhilosophy/768
۳. دلایل ایجاد Gold Plating و راه حلهای آن (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/769
۴. بوم سفید سایت Reddit برای کاربران (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/770
https://news.1rj.ru/str/SoftwarePhilosophy/771
۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection
https://news.1rj.ru/str/SoftwarePhilosophy/772
۶. آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟ (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/773
ـــــــــــ
@SoftwarePhilosophy
۱. تنظیم محیط برنامهنویسی Linux روی Windows 10
https://news.1rj.ru/str/SoftwarePhilosophy/767
۲. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی
https://news.1rj.ru/str/SoftwarePhilosophy/768
۳. دلایل ایجاد Gold Plating و راه حلهای آن (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/769
۴. بوم سفید سایت Reddit برای کاربران (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/770
https://news.1rj.ru/str/SoftwarePhilosophy/771
۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection
https://news.1rj.ru/str/SoftwarePhilosophy/772
۶. آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟ (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/773
ـــــــــــ
@SoftwarePhilosophy
حذف حجم زیادی از سطرها از دیتابیس با اجرای دستور DELETE میتواند بسیار پر هزینه و زمانبر باشد. برای بهبود عملکرد و سرعت عملیات حذف باید Foreign Key ها، Index ها را هم بررسی کرد. ولی پس از بررسی و بهبود توسط این عوامل، راه بعدی استفاده از Delete Chunks است. شکستن DELETE های بزرگ به تکههای کوچکتر میتواند کمک زیادی به بهبود سرعت کند.
مقاله زیر ضمن آموزش این روش، نتایج اجرای این روش را با روشهای دیگر مقایسه کردهاست.
https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/CcQz30bhNiQ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر ضمن آموزش این روش، نتایج اجرای این روش را با روشهای دیگر مقایسه کردهاست.
https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/CcQz30bhNiQ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
SQLPerformance.com
Break large delete operations into chunks
Aaron Bertrand (@AaronBertrand) discusses ways to optimize large delete operations, both to make them faster, and to minimize impact on the transaction log.
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
الگوی Async Retry Pattern یکی از الگوهایی است که در برنامهنویسی برنامههای نسل جدید بسیار مهم است. بسیاری دستگاهها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شدهاند این امکان را میدهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);
RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);
کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.
مقاله زیر ضمن تشریح این الگو، توضیح دادهاست که چطور میتوان با استفاده از async/await الگوی retry pattern را پیادهسازی کرد.
https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);
RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);
کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.
مقاله زیر ضمن تشریح این الگو، توضیح دادهاست که چطور میتوان با استفاده از async/await الگوی retry pattern را پیادهسازی کرد.
https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Alastair Crabtree
Implementing the retry pattern for async tasks in c#
This post is a follow on from Implementing a simple retry pattern in c#
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
Forwarded from فلسفه دیزاین
مروری بر معماری اطلاعات:
فوت کوزهگری دیزاین
از سفر برگشتم و امروز با یه مطلب هیجانانگیز همراهتون هستم.
بنا به تجربهای که شخصا داشتم، جدای از هر روندی که برای ارائه بهترین و با کیفیتترین دیزاین طی میشه، اگر مرحله معماری اطلاعات به درستی انجام نشه، کار نهایی عالی نخواهد بود.
در واقع یکی از پلههای نردبانِ خوب به عالی در دیزاین، معماری اطلاعاتست. این مرحله از دیزاین بسیار بسیار لذتبخشه چراکه مجبور هستید تمام بخشهای سرویسی که دیزاین میکنید رو کاملا زیر و رو کرده و درکش کنید.
بطور ساده، معماری اطلاعات شامل مواردی از قبیل: اطلاعاتی که در اپلیکیشن در جریان هست، اطلاعاتی که در هر بخش باید نمایش داده بشه و اعمالی که هر کاربر میتونه درباره این اطلاعات انجام بده، میشه.
مقاله امروز به زبان ساده توضیح میده که چطور میتونیم شروع کنیم به گنجوندن معمار اطلاعات در مراحل دیزاین یک سرویس و مثالهایی کاربردی از اپلیکیشن Spotify میزنه که به فهم بیشتر موضوع کمک شایان توجهی میکنه.
پیشنهاد میکنم که خوندن این مقاله رو مقدمهای قرار داده و تحقیقات مفصلتری درباره مقوله معماری اطلاعات در دیزاین انجام بدید. قطعا تغییراتی که در طرز تفکرتون و نتیجه نهایی دیزاینتون ایجاد میشه، لذت خواهید برد.
https://blog.prototypr.io/information-architecture-the-most-important-part-of-design-youre-probably-overlooking-20372ade4fc0
(زمان حدودی مطالعه، ۷ دقیقه)
#معماری_اطلاعات #تجربه_کاربری #مفاهیم
@Dexign دیزاین
___
فوت کوزهگری دیزاین
از سفر برگشتم و امروز با یه مطلب هیجانانگیز همراهتون هستم.
بنا به تجربهای که شخصا داشتم، جدای از هر روندی که برای ارائه بهترین و با کیفیتترین دیزاین طی میشه، اگر مرحله معماری اطلاعات به درستی انجام نشه، کار نهایی عالی نخواهد بود.
در واقع یکی از پلههای نردبانِ خوب به عالی در دیزاین، معماری اطلاعاتست. این مرحله از دیزاین بسیار بسیار لذتبخشه چراکه مجبور هستید تمام بخشهای سرویسی که دیزاین میکنید رو کاملا زیر و رو کرده و درکش کنید.
بطور ساده، معماری اطلاعات شامل مواردی از قبیل: اطلاعاتی که در اپلیکیشن در جریان هست، اطلاعاتی که در هر بخش باید نمایش داده بشه و اعمالی که هر کاربر میتونه درباره این اطلاعات انجام بده، میشه.
مقاله امروز به زبان ساده توضیح میده که چطور میتونیم شروع کنیم به گنجوندن معمار اطلاعات در مراحل دیزاین یک سرویس و مثالهایی کاربردی از اپلیکیشن Spotify میزنه که به فهم بیشتر موضوع کمک شایان توجهی میکنه.
پیشنهاد میکنم که خوندن این مقاله رو مقدمهای قرار داده و تحقیقات مفصلتری درباره مقوله معماری اطلاعات در دیزاین انجام بدید. قطعا تغییراتی که در طرز تفکرتون و نتیجه نهایی دیزاینتون ایجاد میشه، لذت خواهید برد.
https://blog.prototypr.io/information-architecture-the-most-important-part-of-design-youre-probably-overlooking-20372ade4fc0
(زمان حدودی مطالعه، ۷ دقیقه)
#معماری_اطلاعات #تجربه_کاربری #مفاهیم
@Dexign دیزاین
___
Medium
Information Architecture. The Most Important Part of Design You’re Probably Overlooking.
What Is Information Architecture?
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرمافزار را به خود جلب کردهاست. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکههای کوچکتر شکسته شود. در این تیمها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوریهای باقیمانده استفاده میشود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Innolution
Blog: To Estimate or Not to Estimate – That is the Controversy | Innolution
Blog that discusses the controversy of whether estimates are useful on agile development projects.
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
ui.dev
Why you don’t need device specific breakpoints
With the ever growing number of different mobile, tablet, laptops, monitors, televisions, watches — and whatever else will communicate information to you visually — it’s finally time to put to rest those device specific breakpoints.
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نوشتن کوئریهای DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://news.1rj.ru/str/SoftwarePhilosophy/775
۲. چگونه با استفاده از async/await الگوی retry pattern را پیادهسازی کنیم
#csharp #async #designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/777
۳. مروری بر معماری اطلاعات یا فوت کوزهگری دیزاین (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/778
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://news.1rj.ru/str/SoftwarePhilosophy/780
۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://news.1rj.ru/str/SoftwarePhilosophy/782
ـــــــــــ
@SoftwarePhilosophy
۱. نوشتن کوئریهای DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://news.1rj.ru/str/SoftwarePhilosophy/775
۲. چگونه با استفاده از async/await الگوی retry pattern را پیادهسازی کنیم
#csharp #async #designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/777
۳. مروری بر معماری اطلاعات یا فوت کوزهگری دیزاین (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/778
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://news.1rj.ru/str/SoftwarePhilosophy/780
۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://news.1rj.ru/str/SoftwarePhilosophy/782
ـــــــــــ
@SoftwarePhilosophy
Forwarded from فلسفه دیزاین
سوالاتی که هر دیزاینر جدیدی باید از تیمش بپرسد
در اکثر جاها صحبت از سوالاتی هست که باید در مصاحبه از دیزاینر جدیدتون بپرسید. اما این بار ما میخواهیم از زاویه دیگری به موضوع نگاه کنیم. میخواهیم سوالاتی رو بررسی کنیم که هر دیزاینر جدیدی که عضو یک تیم شده، باید از اعضای تیمش بپرسه.
اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای Jason Cashdollar به تازگی به عضویت تیم دیزاین اپلیکیشن Facebook Lite در فیسبوک در اومده. اولین تسک Jason بازطراحی روند عضویت در این اپلیکیشن هست و هدفی که براش تعیین شد عبارت بود از «کاهش سردرگمی کاربرانی که میخواهند ثبتنام کنند.». Jason مراحلی که هر دیزاینری برای دیزاین طی میکنه رو رفت و در نهایت پروپوزالی رو برای تیمش ارسال کرد.
انتظار Jason این بود که تمام اعضای تیم با پیشنهاد اون به وجد بیان و هیجانزده بشن. ولی بعد از اینکه عکسالعمل تیم رو دید متوجه شد که به قول خودش «مسابقه اشتباهی رو برنده شده بود.» و چیزی که طراحی کرده بود کارایی لازم رو نداشت.
یک لحظه همینجا صبر کنید. حدس میزنید دلیل این موضوع چی بود؟
دلیل این بود که اطلاعات قبلی رو که لازم بود درباره پروژه بدونه، از تیم درخواست نکرده و مسیری اشتباهی رو برای بازطراحی این محصول پیش رفته بود.
بعد از این تجربه، Jason سوالاتی رو برای خودش تعیین کرد به همه اعضای تازه تیمها بده که از تیمشون بپرسن تا تجربه مشابهی نداشته باشن.
پیشنهاد میکنم داستان کامل و سوالاتی که پرسیدنشون رو پیشنهاد میده، از زبان خود Jason بخونید.
https://medium.com/facebook-design/questions-to-ask-as-a-new-designer-on-the-team-7e3ace0c787f
(زمان حدودی مطالعه، ۷ دقیقه)
پ. ن.
داشتن پایگاه دانش (knowledge base) همیشه به روند ملحق شدن اعضای جدید به تیم کمک میکنه. لازم نیست حتما از سیستمهای پیچیده استفاده کنید، ما ۸ ماهیست که یه نسخه کوچیکش رو در قالب یک Board روی Trello راهاندازی کردیم و بچههای تیم خودشون بروزرسانیش میکنند و کاملا کارمون رو راه میاندازه.
#تیم #طراحی_محصول
@Dexign دیزاین
___
در اکثر جاها صحبت از سوالاتی هست که باید در مصاحبه از دیزاینر جدیدتون بپرسید. اما این بار ما میخواهیم از زاویه دیگری به موضوع نگاه کنیم. میخواهیم سوالاتی رو بررسی کنیم که هر دیزاینر جدیدی که عضو یک تیم شده، باید از اعضای تیمش بپرسه.
اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای Jason Cashdollar به تازگی به عضویت تیم دیزاین اپلیکیشن Facebook Lite در فیسبوک در اومده. اولین تسک Jason بازطراحی روند عضویت در این اپلیکیشن هست و هدفی که براش تعیین شد عبارت بود از «کاهش سردرگمی کاربرانی که میخواهند ثبتنام کنند.». Jason مراحلی که هر دیزاینری برای دیزاین طی میکنه رو رفت و در نهایت پروپوزالی رو برای تیمش ارسال کرد.
انتظار Jason این بود که تمام اعضای تیم با پیشنهاد اون به وجد بیان و هیجانزده بشن. ولی بعد از اینکه عکسالعمل تیم رو دید متوجه شد که به قول خودش «مسابقه اشتباهی رو برنده شده بود.» و چیزی که طراحی کرده بود کارایی لازم رو نداشت.
یک لحظه همینجا صبر کنید. حدس میزنید دلیل این موضوع چی بود؟
دلیل این بود که اطلاعات قبلی رو که لازم بود درباره پروژه بدونه، از تیم درخواست نکرده و مسیری اشتباهی رو برای بازطراحی این محصول پیش رفته بود.
بعد از این تجربه، Jason سوالاتی رو برای خودش تعیین کرد به همه اعضای تازه تیمها بده که از تیمشون بپرسن تا تجربه مشابهی نداشته باشن.
پیشنهاد میکنم داستان کامل و سوالاتی که پرسیدنشون رو پیشنهاد میده، از زبان خود Jason بخونید.
https://medium.com/facebook-design/questions-to-ask-as-a-new-designer-on-the-team-7e3ace0c787f
(زمان حدودی مطالعه، ۷ دقیقه)
پ. ن.
داشتن پایگاه دانش (knowledge base) همیشه به روند ملحق شدن اعضای جدید به تیم کمک میکنه. لازم نیست حتما از سیستمهای پیچیده استفاده کنید، ما ۸ ماهیست که یه نسخه کوچیکش رو در قالب یک Board روی Trello راهاندازی کردیم و بچههای تیم خودشون بروزرسانیش میکنند و کاملا کارمون رو راه میاندازه.
#تیم #طراحی_محصول
@Dexign دیزاین
___
Medium
Questions to ask as a new designer on the team
Last summer I switched teams at Facebook. My first project seemed simple enough: redesign the sign up flow for Facebook Lite, an app for…
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
استفاده از 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
___
در مقاله زیر فریمورکهای معروف Mapper از لحاظ عملکرد و سرعت با یکدیگر مقایسه شدهاند.
http://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای جایگزین بهتری وجود دارد که یکی از آنها actor model میباشد.
اکتور یک مدل مفهومی ارائه شده برای محاسبات همزمان میباشد که کتابخانههایی برای زبانهای برنامهنویسی مختلف بر اساس این مدل ارائه شدهاند . ایدهای که در این مدل وجود دارد بسیار مشابه تعاریفی است که در زبان شیگرایی با آن آشنایی داریم به این صورت که یک شی، یک پیغام را دریافت میکند و عملیاتی بر اساس پیغام دریافتی روی آن انجام میدهد. اما ویژگیهای اصلی این مدل که آن را متمایز میکند جدا بودن هر اکتور از هم میباشد که هیچگاه مموری را با هم به اشتراک نمیگذارند. هر اکتور شامل یک صندوق پستی است و اکتورها با ارسال پیغام به یکدیگر , با نگه داشتن پیغام ها در صندوق پستی , عملیات لازم را روی پیغامها به صورت یکی یکی انجام میدهند.
مقاله زیر به شرح کامل نحوه عملکرد اکتورها و چگونگی ارتباط آنها میپردازد.
http://www.brianstorti.com/the-actor-model
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای جایگزین بهتری وجود دارد که یکی از آنها actor model میباشد.
اکتور یک مدل مفهومی ارائه شده برای محاسبات همزمان میباشد که کتابخانههایی برای زبانهای برنامهنویسی مختلف بر اساس این مدل ارائه شدهاند . ایدهای که در این مدل وجود دارد بسیار مشابه تعاریفی است که در زبان شیگرایی با آن آشنایی داریم به این صورت که یک شی، یک پیغام را دریافت میکند و عملیاتی بر اساس پیغام دریافتی روی آن انجام میدهد. اما ویژگیهای اصلی این مدل که آن را متمایز میکند جدا بودن هر اکتور از هم میباشد که هیچگاه مموری را با هم به اشتراک نمیگذارند. هر اکتور شامل یک صندوق پستی است و اکتورها با ارسال پیغام به یکدیگر , با نگه داشتن پیغام ها در صندوق پستی , عملیات لازم را روی پیغامها به صورت یکی یکی انجام میدهند.
مقاله زیر به شرح کامل نحوه عملکرد اکتورها و چگونگی ارتباط آنها میپردازد.
http://www.brianstorti.com/the-actor-model
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
Brianstorti
The actor model in 10 minutes
Forwarded from فلسفه دیزاین
نمونههای جالب اینتراکشن (شماره ۱)
هر محصولی، هرچقدر هم که رابط کاربری زیبایی داشته باشه، برای القای حس و تجربه بهتر، به اینتراکشن (Interaction) احتیاج داره.
اینتراکشنها همون عکسالعملهای اغلب انیمیشنی هستند که اپلیکیشنها در پاسخ به اعمال کاربر (زدن روی یک دکمه، Swipe کردن و یا منتظر بارگذاری موندن و …) انجام میدن.
مثال خوبی که میشه از اینتراکشن در اپلیکیشنهای ایرانی زد اینه که در اپلیکیشن اسنپ وقتی منتظر قبول درخواست سفرتون از طرف یکی از رانندهها هستید، صفحه انتظاری میبینید که ماشینی در اون در حال حرکت هست. اگر روی ماشین بزنید، بوق میزنه. از بازخوردهایی که از این ایده ساده ولی جذاب و خلاقانه از افراد مختلف گرفتم به عینه دیدم که باعث شده کاربرها حس بسیار بهتری نسبت به محصول در مقایسه با نمونههای مشابهش داشته باشند.
برای اینکه بتونید بهتر و با ایدههای جالبتری اینتراکشنهای محصولتون رو طراحی کنید، چند وقت یک بار نمونههای این شکلی در کانال ارسال میکنم که دیدنشون باعث جرقه ایده در ذهن میشه.
توجه کنید که صفحه مقاله امروز به خاطر وجود انیمیشنهای gif که در اون وجود داره، کمی سنگین هست ممکنه نمایشش کند باشه.
https://medium.muz.li/ui-interactions-of-the-week-72-65ea29a45c49
(زمان حدودی مطالعه، ۱۰ دقیقه)
#انیمیشن #طراحی_محصول #اینتراکشن #تجربه_کاربری
@Dexign دیزاین
___
هر محصولی، هرچقدر هم که رابط کاربری زیبایی داشته باشه، برای القای حس و تجربه بهتر، به اینتراکشن (Interaction) احتیاج داره.
اینتراکشنها همون عکسالعملهای اغلب انیمیشنی هستند که اپلیکیشنها در پاسخ به اعمال کاربر (زدن روی یک دکمه، Swipe کردن و یا منتظر بارگذاری موندن و …) انجام میدن.
مثال خوبی که میشه از اینتراکشن در اپلیکیشنهای ایرانی زد اینه که در اپلیکیشن اسنپ وقتی منتظر قبول درخواست سفرتون از طرف یکی از رانندهها هستید، صفحه انتظاری میبینید که ماشینی در اون در حال حرکت هست. اگر روی ماشین بزنید، بوق میزنه. از بازخوردهایی که از این ایده ساده ولی جذاب و خلاقانه از افراد مختلف گرفتم به عینه دیدم که باعث شده کاربرها حس بسیار بهتری نسبت به محصول در مقایسه با نمونههای مشابهش داشته باشند.
برای اینکه بتونید بهتر و با ایدههای جالبتری اینتراکشنهای محصولتون رو طراحی کنید، چند وقت یک بار نمونههای این شکلی در کانال ارسال میکنم که دیدنشون باعث جرقه ایده در ذهن میشه.
توجه کنید که صفحه مقاله امروز به خاطر وجود انیمیشنهای gif که در اون وجود داره، کمی سنگین هست ممکنه نمایشش کند باشه.
https://medium.muz.li/ui-interactions-of-the-week-72-65ea29a45c49
(زمان حدودی مطالعه، ۱۰ دقیقه)
#انیمیشن #طراحی_محصول #اینتراکشن #تجربه_کاربری
@Dexign دیزاین
___
Medium
UI Interactions of the week #72
via Muzli design inspiration
#پست_مجدد این پست تا به حال بیش از ۱۷۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
در بسیاری از موقعیتهای زندگی و کاری، کار ما تصمیم گرفتن است و طبیعتا دوست داریم بهترین تصمیم ممکن را در این موقعیتها بگیریم. تصمیم در انتخاب محل کار آینده، تصمیم در انتخاب یک تکنولوژی یا زبان مناسب و هزاران تصمیم دیگر که سعی در رسیدن به «بهترین تصمیم» برای آنها را داریم. اما در مقابل این مفهوم، مفهوم جذاب دیگری به نام «تصمیم به اندازه کافی خوب» وجود دارد که بسیار در تصمیمگیریها میتواند کارساز باشد.
فرض کنید میخواهید شغل بعدی خود را انتخاب کنید و تصمیم به رفتن به یک شرکت جدید دارید. واقعا آیا این بهترین تصمیم است؟
• این تصمیم میتواند در حال حاضر (سال ۲۰۱۵) بهترین تصمیم شما باشد.
• در انتهای ماه ممکن است به این نتیجه برسید که این تصمیم، نسبتا خوب بودهاست زیرا شغل پر استرسی است.
• در سال ۲۰۱۶ ممکن است به این نتیجه برسید که تصمیم بدی گرفتهاید چون شغل بسیار سختی است.
• در سال ۲۰۱۷ ممکن است به این نتیجه برسید که بدترین تصمیم ممکن را گرفتهاید زیرا علیرقم تمام زحماتتان شرکت ورشکست شده!
• و در نهایت در سال ۲۰۲۰ به این نتیجه برسید که بهترین تصمیم تمام عمرتان را گرفتهاید، زیرا با استفاده از تجربهای که از آن شرکت به دست آوردهاید حالا مدیرعامل شرکت مایکروسافت شدهاید!
همانطور که میبینید ارزیابی بهترین بودن یک تصمیم نسبت به زمان نتایج متفاوتی میدهد. در طرف مقابل، یک «تصمیم به اندازه کافی خوب»، تصمیمی است که «فقط در زمان گرفتن تصمیم» به اندازه کافی خوب بودهاست. ممکن است در زمان تصمیمگیری چند انتخاب وجود داشته باشد که همه به اندازه کافی خوب هستند. در این شرایط کار سخت پیدا کردن بهترین آنها است. در اکثر مواقع میتوان این کار سخت را انجام نداد و صرفا «یک تصمیم به اندازه خوب» گرفت.
در مقاله زیر توضیح دادهشدهاست که چگونه «تصمیمهای به اندازه کافی خوب» در طول زمان میتوانند به یک «بهترین تصمیم» تبدیل شوند.
http://mehrandvd.me/2016/12/12/good-enough-decision-towards-best-decision/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Good Enough Decisio
در بسیاری از موقعیتهای زندگی و کاری، کار ما تصمیم گرفتن است و طبیعتا دوست داریم بهترین تصمیم ممکن را در این موقعیتها بگیریم. تصمیم در انتخاب محل کار آینده، تصمیم در انتخاب یک تکنولوژی یا زبان مناسب و هزاران تصمیم دیگر که سعی در رسیدن به «بهترین تصمیم» برای آنها را داریم. اما در مقابل این مفهوم، مفهوم جذاب دیگری به نام «تصمیم به اندازه کافی خوب» وجود دارد که بسیار در تصمیمگیریها میتواند کارساز باشد.
فرض کنید میخواهید شغل بعدی خود را انتخاب کنید و تصمیم به رفتن به یک شرکت جدید دارید. واقعا آیا این بهترین تصمیم است؟
• این تصمیم میتواند در حال حاضر (سال ۲۰۱۵) بهترین تصمیم شما باشد.
• در انتهای ماه ممکن است به این نتیجه برسید که این تصمیم، نسبتا خوب بودهاست زیرا شغل پر استرسی است.
• در سال ۲۰۱۶ ممکن است به این نتیجه برسید که تصمیم بدی گرفتهاید چون شغل بسیار سختی است.
• در سال ۲۰۱۷ ممکن است به این نتیجه برسید که بدترین تصمیم ممکن را گرفتهاید زیرا علیرقم تمام زحماتتان شرکت ورشکست شده!
• و در نهایت در سال ۲۰۲۰ به این نتیجه برسید که بهترین تصمیم تمام عمرتان را گرفتهاید، زیرا با استفاده از تجربهای که از آن شرکت به دست آوردهاید حالا مدیرعامل شرکت مایکروسافت شدهاید!
همانطور که میبینید ارزیابی بهترین بودن یک تصمیم نسبت به زمان نتایج متفاوتی میدهد. در طرف مقابل، یک «تصمیم به اندازه کافی خوب»، تصمیمی است که «فقط در زمان گرفتن تصمیم» به اندازه کافی خوب بودهاست. ممکن است در زمان تصمیمگیری چند انتخاب وجود داشته باشد که همه به اندازه کافی خوب هستند. در این شرایط کار سخت پیدا کردن بهترین آنها است. در اکثر مواقع میتوان این کار سخت را انجام نداد و صرفا «یک تصمیم به اندازه خوب» گرفت.
در مقاله زیر توضیح دادهشدهاست که چگونه «تصمیمهای به اندازه کافی خوب» در طول زمان میتوانند به یک «بهترین تصمیم» تبدیل شوند.
http://mehrandvd.me/2016/12/12/good-enough-decision-towards-best-decision/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Good Enough Decisio
Dot Philosophy
Good Enough Decision towards Best Decision - Dot Philosophy
As our life goes, we are continuously making decisions. Making decisions about our business, about our career or even about our life. Having the power to make decisions is good news, but the bad news is that we are being judged on our decisions, even worse…
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. سوالاتی که هر دیزاینر جدیدی باید از تیمش بپرسد (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/784
۲. مقایسه عملکرد فریمورکهای مشهور Mapper از لحظا سرعت و عملکرد
#mapper #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/786
۳. آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
#parallel
https://news.1rj.ru/str/SoftwarePhilosophy/788
۴. نمونههای جالبی از اینتراکشن (دیزاین)
#designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/789
۵. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
#management #decisionmaking
https://news.1rj.ru/str/SoftwarePhilosophy/791
ـــــــــــ
@SoftwarePhilosophy
۱. سوالاتی که هر دیزاینر جدیدی باید از تیمش بپرسد (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/784
۲. مقایسه عملکرد فریمورکهای مشهور Mapper از لحظا سرعت و عملکرد
#mapper #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/786
۳. آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
#parallel
https://news.1rj.ru/str/SoftwarePhilosophy/788
۴. نمونههای جالبی از اینتراکشن (دیزاین)
#designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/789
۵. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
#management #decisionmaking
https://news.1rj.ru/str/SoftwarePhilosophy/791
ـــــــــــ
@SoftwarePhilosophy
Forwarded from فلسفه دیزاین
مروری کامل بر درباره دکمه اکشن شناور
یا Floating Action Button
اگر با Material Design آشنایی داشته باشید، حتما به این دکمه برخوردید. همون دکمه با رنگ Accent که در خیلی از اپلیکیشنهای اندرویدی و بعضا محصولات گوگل در iOS استفاده شده.
استفاده از اکثر المانها و ابزارها در اکثر مواقع سادهست ولی در اندک مواقعی لازمه اطلاعات خوب و دقیقی درباره اون ابزار یا المان داشته باشید تا بتونید به بهترین شکل ازش استفاده کنید. در غیر اینصورت در این اندک موارد به اشتباه از المانها استفاده خواهید کرد که تاثیر بدی روی تجربه کاربری کل محصول شما میگذاره. این دکمه Floating Action هم از این قاعده مستثنی نیست و در بسیاری از اپلیکیشنها به اشتباه بکار برده شده یا صرفا از اپلیکیلیکشنهای بزرگ دنیا، بدون درکِ اهمیتِ حضورش کپیبرداری شده. امروز میخوایم با کسب اطلاعاتی کامل درباره این دکمه، تصمیمات بهتر و آگاهانهای حول استفاده از این المان دیزاین رابط کاربری بگیریم.
مقاله امروز از آقای Nick Babich هست که بطور مفصل به بررسی کاربردهای این دکمه پرداخته و کمک میکنه که در نهایت شما بتونید به سه سوال مهم زیر جواب بدید:
• چه زمانی میشود از این دکمه استفاده کرد؟
• چه نمونههای خوبی در بکارگیری این دکمه در اپلیکیشنها میتوان نام برد؟
• چطور میتوان با بکارگیری انیمیشن در کارکرد این دکمه، تجربه کاربری محصول را ارتقا داد؟
همچنین در خلال این مقاله با اصطلاح Mystery Meat Navigation هم آشنا میشید که میتونه به عنوان یه سنگ محک در تصمیمگیریهای دیزاینی همراهیتون کنه.
پیشنهاد میکنم این مقاله جذاب و روشنگر رو از دست ندید و همین حالا مطالعهش کنید.
https://uxplanet.org/floating-action-button-in-ux-design-7dd06e49144e
(زمان حدودی مطالعه، ۸ دقیقه)
پ. ن.
در کنار مواردی که آقای Babich در بکارگیری این دکمه گفتن، استفاده همزمان از این دکمه و Bottom Navigation (که پیشتر بهش اشاره کوتاهی داشتیم)، هنوز محل بحث هست.
#رابط_کاربری #تجربه_کاربری #طراحی_محصول #متریال_دیزاین
@Dexign دیزاین
___
یا Floating Action Button
اگر با Material Design آشنایی داشته باشید، حتما به این دکمه برخوردید. همون دکمه با رنگ Accent که در خیلی از اپلیکیشنهای اندرویدی و بعضا محصولات گوگل در iOS استفاده شده.
استفاده از اکثر المانها و ابزارها در اکثر مواقع سادهست ولی در اندک مواقعی لازمه اطلاعات خوب و دقیقی درباره اون ابزار یا المان داشته باشید تا بتونید به بهترین شکل ازش استفاده کنید. در غیر اینصورت در این اندک موارد به اشتباه از المانها استفاده خواهید کرد که تاثیر بدی روی تجربه کاربری کل محصول شما میگذاره. این دکمه Floating Action هم از این قاعده مستثنی نیست و در بسیاری از اپلیکیشنها به اشتباه بکار برده شده یا صرفا از اپلیکیلیکشنهای بزرگ دنیا، بدون درکِ اهمیتِ حضورش کپیبرداری شده. امروز میخوایم با کسب اطلاعاتی کامل درباره این دکمه، تصمیمات بهتر و آگاهانهای حول استفاده از این المان دیزاین رابط کاربری بگیریم.
مقاله امروز از آقای Nick Babich هست که بطور مفصل به بررسی کاربردهای این دکمه پرداخته و کمک میکنه که در نهایت شما بتونید به سه سوال مهم زیر جواب بدید:
• چه زمانی میشود از این دکمه استفاده کرد؟
• چه نمونههای خوبی در بکارگیری این دکمه در اپلیکیشنها میتوان نام برد؟
• چطور میتوان با بکارگیری انیمیشن در کارکرد این دکمه، تجربه کاربری محصول را ارتقا داد؟
همچنین در خلال این مقاله با اصطلاح Mystery Meat Navigation هم آشنا میشید که میتونه به عنوان یه سنگ محک در تصمیمگیریهای دیزاینی همراهیتون کنه.
پیشنهاد میکنم این مقاله جذاب و روشنگر رو از دست ندید و همین حالا مطالعهش کنید.
https://uxplanet.org/floating-action-button-in-ux-design-7dd06e49144e
(زمان حدودی مطالعه، ۸ دقیقه)
پ. ن.
در کنار مواردی که آقای Babich در بکارگیری این دکمه گفتن، استفاده همزمان از این دکمه و Bottom Navigation (که پیشتر بهش اشاره کوتاهی داشتیم)، هنوز محل بحث هست.
#رابط_کاربری #تجربه_کاربری #طراحی_محصول #متریال_دیزاین
@Dexign دیزاین
___
Medium
Floating Action Button in UX Design
by Nick Babich
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.