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

مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرم‌افزار را به خود جلب کرده‌است. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکه‌های کوچکتر شکسته شود. در این تیم‌ها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوری‌های باقیمانده استفاده می‌شود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کرده‌است.

https://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy

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

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

___

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

خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.

https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints

#مریم_داودی

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

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


___

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

۱. نوشتن کوئری‌های DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://t.iss.one/SoftwarePhilosophy/775

۲. چگونه با استفاده از async/await الگوی retry pattern را پیاده‌سازی کنیم
#csharp #async #designpattern
https://t.iss.one/SoftwarePhilosophy/777

۳. مروری بر معماری اطلاعات یا فوت کوزه‌گری دیزاین (دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/778

۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://t.iss.one/SoftwarePhilosophy/780

۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://t.iss.one/SoftwarePhilosophy/782

ـــــــــــ

@SoftwarePhilosophy

سوالاتی که هر دیزاینر جدیدی باید از تیم‌ش بپرسد

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

اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای 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 دیزاین

___

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

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

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

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

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

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

___

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

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

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

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

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


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

لینکدین:

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

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

___

نمونه‌های جالب اینتراکشن (شماره ۱)

هر محصولی، هرچقدر هم که رابط کاربری زیبایی داشته باشه، برای القای حس و تجربه بهتر، به اینتراکشن (Interaction) احتیاج داره.
اینتراکشن‌ها همون عکس‌العمل‌های اغلب انیمیشنی هستند که اپلیکیشن‌ها در پاسخ به اعمال کاربر (زدن روی یک دکمه، Swipe کردن و یا منتظر بارگذاری موندن و …) انجام میدن.

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

برای اینکه بتونید بهتر و با ایده‌های جالب‌تری اینتراکشن‌های محصول‌تون رو طراحی کنید، چند وقت یک بار نمونه‌های این شکلی در کانال ارسال می‌کنم که دیدن‌شون باعث جرقه ایده در ذهن میشه.

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

https://medium.muz.li/ui-interactions-of-the-week-72-65ea29a45c49

(زمان حدودی مطالعه، ۱۰ دقیقه)

#انیمیشن #طراحی_محصول #اینتراکشن #تجربه_کاربری
@Dexign دیزاین

___

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

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

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

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

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

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

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

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

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

___

Good Enough Decisio

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

۱. سوالاتی که هر دیزاینر جدیدی باید از تیم‌ش بپرسد (دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/784

۲. مقایسه عملکرد فریم‌ورک‌های مشهور Mapper از لحظا سرعت و عملکرد
#mapper #dotnet

https://t.iss.one/SoftwarePhilosophy/786

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

https://t.iss.one/SoftwarePhilosophy/788

۴. نمونه‌های جالبی از اینتراکشن (دیزاین)
#designpattern
https://t.iss.one/SoftwarePhilosophy/789

۵. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
#management #decisionmaking

https://t.iss.one/SoftwarePhilosophy/791

ـــــــــــ

@SoftwarePhilosophy

مروری کامل بر درباره دکمه اکشن شناور
یا 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 دیزاین

___

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

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

___

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

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

www.cbi.ir/simplelist/3484.aspx

همچنین مقاله زیر از «دکتر نیلی» به مقایسه عملکرد دولت‌ها در ۳۰ سال گذشته پرداخته‌است.

https://ow.ly/D1J930bLdt3


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


___

یه همچین تاثیری داره بر بازار نرم افزار

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


___

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

من می‌دانم درصد زیادی از اعضای این کانال «Senior Developer» ها و یا «CTO» های شرکت‌های معتبر نرم‌افزاری ایرانی بوده و هر یک افراد بسیار تاثیر گذاری در اکو سیستم خود هستند.

🔹ظاهرا به دلیل ممنوع‌التصویر بودن آقای خاتمی به صاحبان کانال‌های بالای ۵۰۰۰ نفر دستور داده شده تا تصویر او را حذف کنند، من از این فرصت کمتر از ۵۰۰۰ نفر بودن استفاده می‌کنیم و ویدئوی درخواست آقای خاتمی و جمله معروف «شما تَکرار کنید» ایشان را می‌فرستیم.

ظاهرا به دلیل ممنوع‌التصویر بودن آقای خاتمی به صاحبان کانال‌های بالای ۵۰۰۰ نفر دستور داده شده تا تصویر او را حذف کنند، من از این فرصت کمتر از ۵۰۰۰ نفر بودن استفاده می‌کنم و می‌فرستم!