معرفی مفهوم Interaction Flows

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

ما پیشتر هم درباره این چالش صحبت کرده و ابزارهایی برای انتقال انیمیشن‌های تعاملی معرفی کرده‌ایم. امروز می‌خواهیم راه‌حل پیشنهادی خانم Havana Nguyen را درباره انتقال روندهای دیزاین بررسی کنیم.
ایشان پس از طرح مساله بالا، راه‌حل‌های مختلف ارائه شده را بررسی کرده و با ترکیب مفاهیم Wireflow و بنیان‌های ساخت Microinteractionها، یک Template جدید با نام IX Flows ارائه کردند.
این Template از دید من ترکیبی‌ست از Storyboard و Functional Specification، و مفهومی‌ست کارآمد برای مستندسازی یک دیزاین و انتقال تمام و کمال آن به تیم توسعه.

پیشنهاد می‌کنم همین حالا مقاله را بررسی کرده تا بتوانید آن را در محصولات خود به کار ببندید.

https://uxplanet.org/an-introduction-to-interaction-flows-a4f783402529


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

#معرفی #متد #اینتراکشن

@Dexign فلسفه دیزاین

ـــــــــ

🔴 مدیران را اخراج کنید!

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

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

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

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

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

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

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

https://goo.gl/2G14vC

@iranagile

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

تاکنون اتصال به دستگاه‌های بلوتوث تنها از طریق native apps امکان پذیر بود. Web Bluetooth API این امکان را برای web browser ها نیز فراهم آورده است. کتابخانه‌هایی برای کار با این API‌ ها در Node‌و Angular و Polymer نیز پیاده‌سازی شده است. لینک زیر توضیحاتی در مورد این API ها و کاربری آن ارايه می‌دهد.

https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/6Gq530efr9v

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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

___

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

از مسایل مهم در هر نرم افزار وب، علاوه بر زیرساخت‌های شبکه و سیستم عامل، ایمن‌سازی نرم افزار می‌باشد. NWebSec یک کتابخانه مبتنی بر .NET می‌باشد که قابل استفاده در ASP.NET و ASP.NET Core نیز بوده و با استفاده از Security Headers و سایر روش‌ها به امنیت بیشتر نرم افزارها کمک می‌کند.

https://docs.nwebsec.com/en/latest/nwebsec/getting-started.html

https://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/umRg30ehqWV


#علیرضا_وفی (https://ow.ly/Vna930dsUGr)

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

___

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

کارایی و سرعت EntityFramework از گذشته تا به امروز از معضلاتی است که در پروژه‌ها با آن مواجه می‌شویم. همه‌ی راحتی و سرعتی که در زمان توسعه نرم افزار با استفاده از EF CodeFirst به دست می‌آوریم کمابیش برای بهبود سرعت اجرای queryهای وحشتناکی که بعضا توسط EF تولید می‌شود صرف می‌کنیم. ابزارهایی از قبیل Rhino Entity Framework Profiler و LINQ Pad در این راه یاری رسان بوده‌اند.اما ZZZ Projects راه حل بهتری ارایه داده‌اند. آن‌ها کتابخانه‌هایی روی EF ارايه داده‌اند که امکان عملیات CRUD و Merge بصورت batch با سرعت بالا را فراهم می‌آورند. همچنین امکان به روز رسانی بدون بارگزاری موجودیت‌ها از دیتابیس و ارسال چند Query بصورت batch به دیتابیس و بسیاری امکانات دیگر که در لینکهای زیر توضیحات آن آمده است.

https://www.zzzprojects.com/

https://entityframework-extensions.net/

https://entityframework-plus.net/
همچنین از دیگر محدودیت های EF Codefirst عدم امکان استفاده از SQL Function ها و Stored Procedure هایی با خروجی‌های متفاوت است. لینک زیر کتابخانه EntityFramework.Functions را معرفی می‌کند که به کمک آن با این محدودیت EF Codefirst خداحافظی می‌کنید.

https://weblogs.asp.net/Dixin/EntityFramework.Functions

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/3nz630ejcU6

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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

___

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

۱. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/1041

۲. معرفی مفهوم Interaction Flows (فلسفه دیزاین)

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

۳. مدیران را اخراج کنید! (Iran Agile)

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

۴. اتصال به دستگاه‌های بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/1045

۵. ایمن‌سازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/1047

۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/1049

ـــــــــــ

@SoftwarePhilosophy

برنامه‌نویسان NASA یکی از چالشی‌ترین کارهای برنامه‌نویسی در جهان را دارند. عمده برنامه‌هایی که آنها می‌نویسند بسیار حساس و اصطلاحا Mission Critical هستند.
برنامه‌هایی که در ناسا نوشته می‌شوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه می‌شود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی می‌کنند می‌تواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامه‌نویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده می‌کنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شده‌اند ولی بیشتر آنها در همه زبان‌ها کاربرد دارند و خواندن این قوانین می‌تواند بسیار آموزنده باشد.

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

https://fossbytes.com/nasa-coding-programming-rules-critical/


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/UkMY30gO6Si

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

آیا محصول شما در جیب جا می‌شود؟

می‌دانستید تعریف Mark Zuckerberg از Facebook چیست؟
«چیزی که شما می‌تواند اسم کسی را در آن جستجو کرده و کلی اطلاعات درباره آن فرد بفهمید.»
یا تعریف Travis Kalanick، از Uber (سرویسی که اسنپ مشابه آن است)؟
«شما دکمه‌ای را فشار می‌دهید و ۵ دقیقه بعد یک مرسدس میاد و شما رو به هرکجا بخواهید می‌بره.»

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

مقاله امروز راهنمایی‌ست استراتژیک برای این بتوانید به این توضیح یک جمله‌ای از محصول خود برسید.
این مقاله را از دست ندهید

https://medium.dave-bailey.com/the-magic-formula-to-describe-a-product-in-one-sentence-175ce38619c7

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

#بررسی #استراتژی #محصول
@Dexign فلسفه دیزاین

ــــــ

⭕ چک‌لیست دراکر برای ارزیابی سازمان

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

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

شرکت شما دراکر-گونه است اگر شما:

ماموریتی مشخص و قوی دارید و پاسخی قانع کننده به این سوال دشوار که: “ما در چه کسب و کاری هستیم؟”

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

مسئولیت و پاسخگویی را تا جایی که می شود در عمق سازمان به پایین می برید. به این استراتژی پایه ی ارتباطی عمل می کنید: به پایین گوش کن، با بالا صحبت کن.

این حقیقت را در آغوش می کشید که سازمان اشخاص را می سازد (یه به آنها کمک می کند که رشد کنند و یا آنها را از رشد باز می دارد) و بنابراین شما از هرچه می توانید برای کمک به رشد آنها دریغ نمی کنید.

نوآوری را (که یعنی تغییری که بعد جدیدی از کارایی را ایجاد می کند) به عنوان مسئولیت هر کسی در سازمان می دانید، نه فقط واحد تحقیق و توسعه.

به طور منظم چیزهایی را رها می کنید (محصولات، سیاست ها، روشها) که یا دیگر موثر نیستند و یا نسبت به فرصت های آینده، منابع زیادی را مصرف می کنند.

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

افق بلند مدت را در نظر دارید (نه فقط کوتاه مدت را) و به خاطر می سپارید که “تحلیلگران بازار سرمایه اعتقاد دارند شرکت ها پول می ساند، در حالی که شرکت ها کفش می سازند”.

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

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

@iranagile

https://goo.gl/v3iTxv

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

قانون Conways در استفاده از مایکروسرویس‌ها در معماری نرم‌افزار بسیار قانون جالبی است. این روز‌ها در بسیاری از تیم‌های نرم‌افزاری بحث استفاده یا عدم استفاده از مایکروسرویس‌ها در معماری آینده تیم مطرح است. قانون Conways به طور کلی در مورد سیستم‌ها صحبت می‌کند. این قانون می‌گوید:
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»

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

این قانون گرچه اثبات نشده، ولی به طور ضمنی می‌گوید اگر می‌خواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.

https://www.thoughtworks.com/insights/blog/demystifying-conways-law

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/8byp30emn9u


#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

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

شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

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

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/958i30erVZs

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

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

۱. آشنایی با قانون حیاتی که تیم برنامه‌نویسی «آزمایشگاه نیروی متحرکه جت» ناسا

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

۲. آیا محصول شما در جیب جا می‌شود؟ (فلسفه دیزاین)

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

۳. چک‌لیست دراکر برای ارزیابی سازمان (Iran Agile)

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

۴. قانون Conways در استفاده از مایکروسرویس‌ها در معماری نرم‌افزار

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

۵. شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

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

ـــــــــــ

@SoftwarePhilosophy

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

آیا ترکیب WebAssembly و .Net آینده برنامه‌نویسی front-end است؟ این نام مقاله جدید اسکات هانسلمن است که در آن توضیح می‌دهد چطور .NET Core 2.0 این ایده را امکان پذیر کرده‌است که کدهای front-end را با c# نوشت و به WebAssembly کامپیال کرد. در این مقاله توضیح داده شده که چطور Steve Sanderson (برنامه نویس اصلی فریم‌ورک knockout) در یک پروژه آزمایشی به نام Blazor دقیقا مانند Angular, Knockout و Ember کد نوشته، با این تفاوت که این کد با C# نوشته شده.

مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح داده‌است.

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

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/KVCh30ewRvs

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

دیزاین برای حافظه، دیزاین برای انسان‌ها

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

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

پیشنهاد می‌کنم این مقاله جالب را همین حالا مطالعه کنید.

https://uxplanet.org/designing-for-human-memory-a2cdc0b6a75a

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

#بررسی #استراتژی #طراحی
@Dexign فلسفه دیزاین

____

🔴 اسکرام روزانه و «هادل»های ورزشی

در دنیای ورزش به اقدام افراد یک تیم برای تشکیل یک حلقه فشرده جهت مرور استراتژی، برنامه‌ریزی کوتاه‌مدت، انگیزه گیری و یا جشن، «هادل» (Huddle) گفته می‌شود.

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

این هادل‌ها به‌مرورزمان به نوعی عرف ورزشی تبدیل شده و دارای خصوصیات مشترکی شامل موارد زیر هستند:

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

https://goo.gl/mjFbDk

@IranAgile