امضا کنندگان مانیفست Agile امضایشان را پس گرفتند. مارتین فاولر نیز از امضای این مانیفست اعلام ندامت کرد. مشکل از آنجا شروع شده که پروژههایی که تحت این مانیفست اجرا میشدهاند با مشکلات عمدهای روبرو شدند و ۸۳.۶٪ آنها شکست خوردند.
این درحالی است که شرکتهای بزرگی مانند Microsoft و Atlassian سرمایهگذاری زیادی روی این مانیفست در محصولات خود مانند TFS و JIRA کردهاند. همچنین شرکتهای نرمافزاری زیادی در حال استفاده از این محصولات هستند که این تغییر باعث افت شدید سهام آنها میشود.
یکی از امضا کنندگانی که امضایش را پس گرفته در مصاحبهای خشم خود را در مورد سو استفاده از این مانیفست برای پولشویی ابراز کردهاست.
سیزده به در مبارک!!
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
این درحالی است که شرکتهای بزرگی مانند Microsoft و Atlassian سرمایهگذاری زیادی روی این مانیفست در محصولات خود مانند TFS و JIRA کردهاند. همچنین شرکتهای نرمافزاری زیادی در حال استفاده از این محصولات هستند که این تغییر باعث افت شدید سهام آنها میشود.
یکی از امضا کنندگانی که امضایش را پس گرفته در مصاحبهای خشم خود را در مورد سو استفاده از این مانیفست برای پولشویی ابراز کردهاست.
سیزده به در مبارک!!
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
نسخه ۴.۰ فریمورک Angular!؟ مدتها بود برنامهنویسان منتظر نسخه ۲.۰ این فریمورک محبوب بودند که ناگهان صحبت از نسخه ۴.۰ این فریمورک شدهاست.
علت این تغییر نسخه سریع و عجیب در حقیقت هماهنگ شدن این محصول با Semantic Versioning است. تیم Angular برای هماهنگی با استاندارد Semantic Versioning و اطلاعرسانی بهتر در مورد محتوای هر ریلیز، این استاندارد را پیادهسازی کردهاست. در این روش از هر نسخه میتوان موارد زیر را فهمید:
- Signaling content of releases
- Time-based release cycles
- Deprecation Policy
- Distinction between stable and experimental releases
برای توضیحات بیشتر میتوانید پست زیر از Igor Minar را در بلاگ رسمی تیم Angular بخوانید.
http://angularjs.blogspot.com/2016/10/versioning-and-releasing-angular.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/tiQx30avyhr
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
علت این تغییر نسخه سریع و عجیب در حقیقت هماهنگ شدن این محصول با Semantic Versioning است. تیم Angular برای هماهنگی با استاندارد Semantic Versioning و اطلاعرسانی بهتر در مورد محتوای هر ریلیز، این استاندارد را پیادهسازی کردهاست. در این روش از هر نسخه میتوان موارد زیر را فهمید:
- Signaling content of releases
- Time-based release cycles
- Deprecation Policy
- Distinction between stable and experimental releases
برای توضیحات بیشتر میتوانید پست زیر از Igor Minar را در بلاگ رسمی تیم Angular بخوانید.
http://angularjs.blogspot.com/2016/10/versioning-and-releasing-angular.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/tiQx30avyhr
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
blog.angularjs.org
Versioning and Releasing Angular
In order for the ecosystem around Angular to thrive, developers need stability from the Angular framework so that reusable components and li...
امکانات اضافه شده در C# 7.0 در نسخه Visual Studio 2017 قابل استفاده شدند. از جمله این امکانات میتوان به موارد زیر اشاره کرد.
- Pattern Matching
- Out Variables
- Locals and Ref Returns
- Generalized Async Return Types
بیشتر این مفاهیم قبلا هم معرفی شدهبودند ولی در این میان مفهوم Generalized Async Return Types از بقیه جدیدتر به نظر میرسد. در لینک زیر با استفاده از این مفهوم به جای Task<T> از یک تایپ جدید با نام ValueTask<T> استفاده شده که کاربردهای بسیار زیادی میتواند داشته باشد. همچنین برنامهنویسان میتوانند خودشان تایپهای جدیدی را به این منظور طراحی کنند.
لینک زیر امکانات جدید اضافه شده را به همراه مثال توضیح دادهاست.
https://docs.microsoft.com/en-us/dotnet/articles/csharp/csharp-7
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3bpp30ay2f3
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
- Pattern Matching
- Out Variables
- Locals and Ref Returns
- Generalized Async Return Types
بیشتر این مفاهیم قبلا هم معرفی شدهبودند ولی در این میان مفهوم Generalized Async Return Types از بقیه جدیدتر به نظر میرسد. در لینک زیر با استفاده از این مفهوم به جای Task<T> از یک تایپ جدید با نام ValueTask<T> استفاده شده که کاربردهای بسیار زیادی میتواند داشته باشد. همچنین برنامهنویسان میتوانند خودشان تایپهای جدیدی را به این منظور طراحی کنند.
لینک زیر امکانات جدید اضافه شده را به همراه مثال توضیح دادهاست.
https://docs.microsoft.com/en-us/dotnet/articles/csharp/csharp-7
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3bpp30ay2f3
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Docs
What's New in C# 7 - C# Guide
Get an overview of the new features coming in the upcoming version 7 of the C# language.
پیشبینی ۱۰ ترند اصلی Web Design در سال ۲۰۱۷ عنوان مقالهای است که توسط Grace Jia نوشته شدهاست. او در سالهای قبل هم پیشبینیهایی را برای دنیای UX ارائه داده بود. ترندهای اصلی از دید این نویسنده در لیست زیر آمدهاند:
1. Bold Typography
2. Bright Gradient
3. Vivid Color Layer
4. Conversation Interface
5. Virtual Reality
6. Micro Interaction
7. Emotional Intelligence Design
8. Better Collaboration with Design and Development
9. Merging of UX and Service Design
10. Credibility is the King
https://www.linkedin.com/pulse/top-10-web-design-trend-predictions-2017-grace-jia
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/qNGe30aArnm
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
1. Bold Typography
2. Bright Gradient
3. Vivid Color Layer
4. Conversation Interface
5. Virtual Reality
6. Micro Interaction
7. Emotional Intelligence Design
8. Better Collaboration with Design and Development
9. Merging of UX and Service Design
10. Credibility is the King
https://www.linkedin.com/pulse/top-10-web-design-trend-predictions-2017-grace-jia
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/qNGe30aArnm
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from فلسفه دیزاین
خداحافظی با یک مفهوم اصیل:
بدرود منوی برگر
احتمالا همگی با منوی برگر (Burger Menu) یا همون سه خط افقیِ موازی که در خیلی از اپلیکیشنها و وبسایتها به عنوان آیکن منو استفاده میشه آشنایی دارید. این نوع منو تقریبا اولین نوع منویی بوده که به طراحی راه پیدا کرده. این آیکن توسط آقای Norm Cox در سال ۱۹۸۱، برای Xerox Star، اولین رابط کاربری گرافیکی برای کامپیوترها، طراحی شده. بعدها با گسترش رابطهای کاربری گرافیکی، این آیکن و نوع تفکر دیزاین پشتش به وفور در اپلیکیشنهای بزرگی مثل Spotify، Youtube و Facebook استفاده شد.
پلتفرم iOS از ابتدا راهنماها و Guidelineهایی برای طراحی رابط کاربری تعیین کرد و با اپلیکیشنهایی که در خود سیستمعامل بصورت Embed نصب بود، نشون داد که ترجیح میده اپلیکیشنها با منوی راهبری در قسمت پایین اپلیکیشن (Tab Bar Navigation) طراحی و پیادهسازی بشن ولی در Android به خاطر نبود سیستم طراحی منسجم و مشخص، و البته امکان تغییر طراحی برای نسخههای مختلف این سیستمعامل روی گوشیهای مختلف، طراحی اکثر اپلیکیشنها به سمت منوی برگر میرفت.
یکی از عمدهترین دلایلی که iOS برای اصرار به استفاده از Tab Bar در اصول طراحیش ذکر کرده اینه که وقتی کاربر بطور مداوم امکانات موجود در اپلیکیشن و آیتمهای موجود در منو رو نبینه (که در منوی برگر آیتمها تا قبل از لمس کردن آیکن برگر، مخفی هستند)، نمیتونه به راحتی با اپلیکیشن کار کنه و در دراز مدت به تمامی بخشهای اون تسلط پیدا کنه.
خیلی از طراحان اپلیکیشنهای iOS هم به خاطر راحتی استفاده از منوی برگر و سختی طراحی Bottom Navigation، از اون استفاده کردند. البته ناگفته نمونه که در همون زمان هم اپلیکیشنهایی مثل Instagram منوی برگر رو استفاده نکردند و حتی در نسخه Android خودشون، از Guidelineهای طراحی در iOS استفاده کردند که همین موضوع انتقادهای زیادی رو بهمراه داشت و خیلی معتقد بودند باید طراحی Android، به چیزی که در سایر اپلیکیشنهای این پلتفرم معمول هست، تغییر کنه.
خلاصه این منوی برگر همینطور بیشتر و بیشتر مورد استفاده قرار میگرفت تا اینکه چندی قبل گوگل در اصول Material Design، مفهوم Bottom Navigation رو معرفی کرد و چالشهای طراحان اپلیکیشنهای Android رو کمی کاهش داد.
با اینکه منوی برگر بهترین راه حلی نبود که میشد برای Navigation در محصولات ارائه کرد و در خیلی از موارد باعث سردرگمی کاربران شده، ولی در ۳۶ سالی که از معرفی این منو میگذره، سالهای زیادی به کاربران محصولات خدمت کرده و به نوعی از اصیلترین مفاهیم طراحی رابط کاربری محسوب میشه.
حالا بعد از ۳۶ سال و معرفی Bottom Navigation در Material Design، میتونه کمکم از طراحی Navigation اصلی اپلیکیشنها کنار بره و در بخشهای دیگهای به خدمت خودش ادامه بده.
با این مقدمه میخوام ازتون دعوت کنم که نوشته آقای Sebastian Lindemann رو درباره تجربه تیمشون در تغییر منوی برگر به Bottom Navigation مطالعه کنید.
اگر شما هم در طراحیهاتون از منوی برگر استفاده کردید، شاید این نوشته بتونه در تغییر و بهبود طراحی، کمکیتون کنه.
https://medium.com/startup-grind/bye-bye-burger-5bd963806015
(زمان حدودی مطالعه، ۱۰ دقیقه)
#مفاهیم #طراحی_محصول #برگر_منو
@Dexign دیزاین
بدرود منوی برگر
احتمالا همگی با منوی برگر (Burger Menu) یا همون سه خط افقیِ موازی که در خیلی از اپلیکیشنها و وبسایتها به عنوان آیکن منو استفاده میشه آشنایی دارید. این نوع منو تقریبا اولین نوع منویی بوده که به طراحی راه پیدا کرده. این آیکن توسط آقای Norm Cox در سال ۱۹۸۱، برای Xerox Star، اولین رابط کاربری گرافیکی برای کامپیوترها، طراحی شده. بعدها با گسترش رابطهای کاربری گرافیکی، این آیکن و نوع تفکر دیزاین پشتش به وفور در اپلیکیشنهای بزرگی مثل Spotify، Youtube و Facebook استفاده شد.
پلتفرم iOS از ابتدا راهنماها و Guidelineهایی برای طراحی رابط کاربری تعیین کرد و با اپلیکیشنهایی که در خود سیستمعامل بصورت Embed نصب بود، نشون داد که ترجیح میده اپلیکیشنها با منوی راهبری در قسمت پایین اپلیکیشن (Tab Bar Navigation) طراحی و پیادهسازی بشن ولی در Android به خاطر نبود سیستم طراحی منسجم و مشخص، و البته امکان تغییر طراحی برای نسخههای مختلف این سیستمعامل روی گوشیهای مختلف، طراحی اکثر اپلیکیشنها به سمت منوی برگر میرفت.
یکی از عمدهترین دلایلی که iOS برای اصرار به استفاده از Tab Bar در اصول طراحیش ذکر کرده اینه که وقتی کاربر بطور مداوم امکانات موجود در اپلیکیشن و آیتمهای موجود در منو رو نبینه (که در منوی برگر آیتمها تا قبل از لمس کردن آیکن برگر، مخفی هستند)، نمیتونه به راحتی با اپلیکیشن کار کنه و در دراز مدت به تمامی بخشهای اون تسلط پیدا کنه.
خیلی از طراحان اپلیکیشنهای iOS هم به خاطر راحتی استفاده از منوی برگر و سختی طراحی Bottom Navigation، از اون استفاده کردند. البته ناگفته نمونه که در همون زمان هم اپلیکیشنهایی مثل Instagram منوی برگر رو استفاده نکردند و حتی در نسخه Android خودشون، از Guidelineهای طراحی در iOS استفاده کردند که همین موضوع انتقادهای زیادی رو بهمراه داشت و خیلی معتقد بودند باید طراحی Android، به چیزی که در سایر اپلیکیشنهای این پلتفرم معمول هست، تغییر کنه.
خلاصه این منوی برگر همینطور بیشتر و بیشتر مورد استفاده قرار میگرفت تا اینکه چندی قبل گوگل در اصول Material Design، مفهوم Bottom Navigation رو معرفی کرد و چالشهای طراحان اپلیکیشنهای Android رو کمی کاهش داد.
با اینکه منوی برگر بهترین راه حلی نبود که میشد برای Navigation در محصولات ارائه کرد و در خیلی از موارد باعث سردرگمی کاربران شده، ولی در ۳۶ سالی که از معرفی این منو میگذره، سالهای زیادی به کاربران محصولات خدمت کرده و به نوعی از اصیلترین مفاهیم طراحی رابط کاربری محسوب میشه.
حالا بعد از ۳۶ سال و معرفی Bottom Navigation در Material Design، میتونه کمکم از طراحی Navigation اصلی اپلیکیشنها کنار بره و در بخشهای دیگهای به خدمت خودش ادامه بده.
با این مقدمه میخوام ازتون دعوت کنم که نوشته آقای Sebastian Lindemann رو درباره تجربه تیمشون در تغییر منوی برگر به Bottom Navigation مطالعه کنید.
اگر شما هم در طراحیهاتون از منوی برگر استفاده کردید، شاید این نوشته بتونه در تغییر و بهبود طراحی، کمکیتون کنه.
https://medium.com/startup-grind/bye-bye-burger-5bd963806015
(زمان حدودی مطالعه، ۱۰ دقیقه)
#مفاهیم #طراحی_محصول #برگر_منو
@Dexign دیزاین
Medium
Bye, Bye Burger!
What we learned from implementing the new Android Bottom Navigation
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. امضا کنندگان مانیفست Agile امضایشان را پس گرفتند.
#agile #aprilfool
https://news.1rj.ru/str/SoftwarePhilosophy/749
۲. نسخه ۴.۰ فریمورک Angular!؟
#angularjs
https://news.1rj.ru/str/SoftwarePhilosophy/750
۳. امکانات اضافه شده در C# 7.0 در نسخه Visual Studio 2017 قابل استفاده شدند.
#csharp #visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/751
۴. پیشبینی ۱۰ ترند اصلی Web Design در سال ۲۰۱۷
#ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/752
۵. خداحافظی با یک مفهوم اصیل: بدرود منوی برگر (دیزاین)
#ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/753
ـــــــــــ
@SoftwarePhilosophy
۱. امضا کنندگان مانیفست Agile امضایشان را پس گرفتند.
#agile #aprilfool
https://news.1rj.ru/str/SoftwarePhilosophy/749
۲. نسخه ۴.۰ فریمورک Angular!؟
#angularjs
https://news.1rj.ru/str/SoftwarePhilosophy/750
۳. امکانات اضافه شده در C# 7.0 در نسخه Visual Studio 2017 قابل استفاده شدند.
#csharp #visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/751
۴. پیشبینی ۱۰ ترند اصلی Web Design در سال ۲۰۱۷
#ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/752
۵. خداحافظی با یک مفهوم اصیل: بدرود منوی برگر (دیزاین)
#ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/753
ـــــــــــ
@SoftwarePhilosophy
یک فیچر کوچک، ولی بسیار بزرگ در Visual Studio 2017 که طرفداران زیادی پیدا کرده نحوه برخورد با NullReferenceException است. این فیچر در نحوه نمایش این نوع خطا در IDE خود را نشان میدهد. به این صورت که اگر برای مثال در عبارت person.Parent.FirstName مقدار Parent برابر با null باشد و باعث خطای NullReferenceException شود، در خطایی که نمایش داده میشود دقیقا اشاره میشود کدام قسمت null بوده. برای مثال دقیقا گفته میشود که person.Parent برابر null بوده و باعث بروز خطا شدهاست.
در لینک زیر به طور خلاصه نحوه استفاده از این ویژگی نمایش داده شده است.
https://blogs.msdn.microsoft.com/devux/2017/03/18/the-small-big-feature-in-visual-studio-2017/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/dnIZ30aGM7L
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
در لینک زیر به طور خلاصه نحوه استفاده از این ویژگی نمایش داده شده است.
https://blogs.msdn.microsoft.com/devux/2017/03/18/the-small-big-feature-in-visual-studio-2017/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/dnIZ30aGM7L
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
درک ساختار فایل web.config معمولا کمک زیادی به برنامهنویسان میکند. اغلب برنامهنویسان فقط با قسمتهای خاصی از این فایل کار میکنند و نیازی به تغییر سایر قسمتها ندارند. ولی با این حال، درک درست معماری این فایل کمک زیادی به نحوه تنظیم آن میکند. ساختار سلسله مراتبی این فایل و اینکه هر فایل web.config معمولا ویژگیهایی را از فایلهای دیگر به ارث میبرد معمولا مغفول واقع میشود. دانستن این نکته که میتوان با ایجاد چند فایل web.config در فولدرها از ویژگی ارثبری آن استفاده کرد میتواند کمک زیادی به طراحی این فایلها کند.
مقاله زیر ۱۰ نکته مهمی که برنامه نویسان باید در مورد این فایل بدانند را شرح دادهاست.
https://weblogs.asp.net/jongalloway/10-things-asp-net-developers-should-know-about-web-config-inheritance-and-overrides
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/Ojts30aISN8
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر ۱۰ نکته مهمی که برنامه نویسان باید در مورد این فایل بدانند را شرح دادهاست.
https://weblogs.asp.net/jongalloway/10-things-asp-net-developers-should-know-about-web-config-inheritance-and-overrides
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/Ojts30aISN8
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
weblogs.asp.net
10 Things ASP.NET Developers Should Know About Web.config Inheritance and Overrides
The ASP.NET configuration system is build around the idea of inheritance: Each Web.config file applies configuration settings to the directory that it is in and to all of the child directories …
Forwarded from فلسفه دیزاین
دیزاینرها، دیزاینر بدنیا نمیآیند
یکی از باگهای ما انسانها اینه که وقتی به موضوعی نگاه میکنیم، روند رو نمیبینیم و صرفا نتیجه رو در نظر میگیریم.
وقتی انسان موفقی رو میبینیم، به این فکر نمیکنیم که برای رسیدن به این جایگاه چه مسیری طی شده. وقتی یک دیزاین موفقی از یک اپلیکیشن یا وبسایت میبینیم، به این فکر نمیکنیم که چند نسخه دیزاین شده تا به این دیزاین رسیده.
برای مثال اپلیکیشن معروف QuizUp، بیش از ۱۲ نسخه دیزاین مختلف داشته تا به دیزاین فعلیش دست پیدا کرده.
در روند موفق شدن در هر موضوعی، اولین قدم یادگیری پایههای اون موضوع است. اگر این مسیر با یادگیری پایهها و قدم به قدم طی نشه، بعضا باعث نمود نمونهکارهای ضعیف و تحمیل هزینه به تیم برای اعمال تغییرات جدید میشه.
مقاله امروز به صحبت درباره این موضوع پرداخته و به موارد بسیار مهم و بنیادینی از قبیل تایپوگرافی، سلسلهمراتب، رنگ و فضاهای مثبت و منفی اشاره کرده.
پیشنهاد میکنم حتما این مقاله رو مطالعه کرده و هر موضوع رو در کارهاتون برسی کنید.
https://medium.freecodecamp.com/before-you-can-master-design-you-must-first-master-the-fundamentals-1981a2af1fda?gi=51152dd3035d
(زمان حدودی مطالعه، ۸ دقیقه)
#مفاهیم #طراحی_محصول #رابط_کاربری
@Dexign دیزاین
___
یکی از باگهای ما انسانها اینه که وقتی به موضوعی نگاه میکنیم، روند رو نمیبینیم و صرفا نتیجه رو در نظر میگیریم.
وقتی انسان موفقی رو میبینیم، به این فکر نمیکنیم که برای رسیدن به این جایگاه چه مسیری طی شده. وقتی یک دیزاین موفقی از یک اپلیکیشن یا وبسایت میبینیم، به این فکر نمیکنیم که چند نسخه دیزاین شده تا به این دیزاین رسیده.
برای مثال اپلیکیشن معروف QuizUp، بیش از ۱۲ نسخه دیزاین مختلف داشته تا به دیزاین فعلیش دست پیدا کرده.
در روند موفق شدن در هر موضوعی، اولین قدم یادگیری پایههای اون موضوع است. اگر این مسیر با یادگیری پایهها و قدم به قدم طی نشه، بعضا باعث نمود نمونهکارهای ضعیف و تحمیل هزینه به تیم برای اعمال تغییرات جدید میشه.
مقاله امروز به صحبت درباره این موضوع پرداخته و به موارد بسیار مهم و بنیادینی از قبیل تایپوگرافی، سلسلهمراتب، رنگ و فضاهای مثبت و منفی اشاره کرده.
پیشنهاد میکنم حتما این مقاله رو مطالعه کرده و هر موضوع رو در کارهاتون برسی کنید.
https://medium.freecodecamp.com/before-you-can-master-design-you-must-first-master-the-fundamentals-1981a2af1fda?gi=51152dd3035d
(زمان حدودی مطالعه، ۸ دقیقه)
#مفاهیم #طراحی_محصول #رابط_کاربری
@Dexign دیزاین
___
freeCodeCamp
Before you can master design, you must first master the fundamentals
Last week, one of my readers sent in a question: How do I become a better visual designer?
یک کد خوب نیاز به مستندسازی قوی دارد. در C#، برای این کار میتوانید از XML Documentation استفاده کنید که با سه اسلش ///، درست قبل از بلاک کد مربوطه شروع می شود.
شما می توانید خودتان نیز تگ های مورد نیاز خود را ایجاد کنید یا از لیست تگهای پیشنهادی موجود استفاده کنید.
پرکاربردترین تگ های پیشنهادی شامل موارد زیر است:
/// <summary>
/// Class or Method or Property or… summary documentation goes
///here.</summary>
/// <remarks>
/// Longer comments can be associated with a type or member through
/// the remarks tag.</remarks>
/// <value>
/// A value tag is used to describe the property value.</value>
/// <param name="s"> Parameter denoscription for s goes here.</param>
/// <seealso cref="System.String">
/// You can use the cref attribute on any tag to reference a type or member
/// and the compiler will check that the reference exists. </seealso>
/// <returns>
/// Return results are described through the returns tag.</returns>
زمانی که با آپشن /doc کامپایل کنید، کامپایلر از روی تمام تگهای xml موجود در کد فایل داکیومنت XML را می سازد.
لینک زیر شرح کاملی از xml documentation و نحوه استفاده آن ارایه می دهد.
https://msdn.microsoft.com/en-us/library/z04awywx.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/Pzau30aN6fd
#مریم_داودی (http://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
شما می توانید خودتان نیز تگ های مورد نیاز خود را ایجاد کنید یا از لیست تگهای پیشنهادی موجود استفاده کنید.
پرکاربردترین تگ های پیشنهادی شامل موارد زیر است:
/// <summary>
/// Class or Method or Property or… summary documentation goes
///here.</summary>
/// <remarks>
/// Longer comments can be associated with a type or member through
/// the remarks tag.</remarks>
/// <value>
/// A value tag is used to describe the property value.</value>
/// <param name="s"> Parameter denoscription for s goes here.</param>
/// <seealso cref="System.String">
/// You can use the cref attribute on any tag to reference a type or member
/// and the compiler will check that the reference exists. </seealso>
/// <returns>
/// Return results are described through the returns tag.</returns>
زمانی که با آپشن /doc کامپایل کنید، کامپایلر از روی تمام تگهای xml موجود در کد فایل داکیومنت XML را می سازد.
لینک زیر شرح کاملی از xml documentation و نحوه استفاده آن ارایه می دهد.
https://msdn.microsoft.com/en-us/library/z04awywx.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/Pzau30aN6fd
#مریم_داودی (http://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
نسخه جدید کتابخانه Json.NET منتشر شد. مهمترین ویژگی جدید نسخه Json.NET 10.0 پشتیبانی آن از عملیات async است. این امکان کمک میکند هنگام تبدیل فایلهای بزرگ Json، پروسس نخ به خاطر I/O بلاک نمیشود. به این صورت برنامههای Client بسیار Responsive تر میشوند و Web Application ها نیز بسیار scalable تر میشوند.
برای آشنایی با نحوه استفاده از ویژگی async این کتابخانه میتوانید توضیحات و مثالهای آن را در لینک زیر مطالعه کنید.
http://james.newtonking.com/archive/2017/03/21/json-net-10-0-release-1-async-performance-documentation-and-more
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/WUU030aPV1A
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
برای آشنایی با نحوه استفاده از ویژگی async این کتابخانه میتوانید توضیحات و مثالهای آن را در لینک زیر مطالعه کنید.
http://james.newtonking.com/archive/2017/03/21/json-net-10-0-release-1-async-performance-documentation-and-more
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/WUU030aPV1A
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نحوه برخورد با NullReferenceException در Visual Studio 2017
#visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/755
۲. ده نکته مهم در رابطه با فایل web.config
#aspnet
https://news.1rj.ru/str/SoftwarePhilosophy/756
۳. دیزاینرها، دیزاینر بدنیا نمیآیند (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/757
۴. نحوه استفاده از XML Documentation برای مستندسازی در C#
#csharp #documentation
https://news.1rj.ru/str/SoftwarePhilosophy/758
۵. آشنایی با نحوه استفاده از ویژگی async در نسخه جدید کتابخانه Json.NET
#dotnet #json #async
https://news.1rj.ru/str/SoftwarePhilosophy/759
ـــــــــــ
@SoftwarePhilosophy
۱. نحوه برخورد با NullReferenceException در Visual Studio 2017
#visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/755
۲. ده نکته مهم در رابطه با فایل web.config
#aspnet
https://news.1rj.ru/str/SoftwarePhilosophy/756
۳. دیزاینرها، دیزاینر بدنیا نمیآیند (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/757
۴. نحوه استفاده از XML Documentation برای مستندسازی در C#
#csharp #documentation
https://news.1rj.ru/str/SoftwarePhilosophy/758
۵. آشنایی با نحوه استفاده از ویژگی async در نسخه جدید کتابخانه Json.NET
#dotnet #json #async
https://news.1rj.ru/str/SoftwarePhilosophy/759
ـــــــــــ
@SoftwarePhilosophy
استفاده از هوش مصنوعی اخیرا جاذبه زیادی را در نرمافزارها ایجاد کردهاست. یکی از ابزارهایی که میتوانید در برنامهنویسی برنامههای خود از آن استفاده کنید Microsoft Cognitive Services (که قبلا به اسم پروژه آکسفورد معروف بود) است. شما با استفاده از این API میتوانید احساساتی که در یک عکس وجود دارد را تشخصی دهید. برای مثال در لینک زیر با استفاده از این سرویس یک برنامه موبایل نوشته شده است که میتواند میزان رضایت کاربر از برنامه شما را از طریق عکس او تخشیص دهد.
نحوه نوشتن این برنامه برای سه پلتفرم Android, iOS, Windows 10 در لینک توضیح داده شدهاست.
https://github.com/Microsoft/XamarinAzure_ShoppingDemoApp/wiki/Cognitive-Services
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/ziQd30aSGEe
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
نحوه نوشتن این برنامه برای سه پلتفرم Android, iOS, Windows 10 در لینک توضیح داده شدهاست.
https://github.com/Microsoft/XamarinAzure_ShoppingDemoApp/wiki/Cognitive-Services
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/ziQd30aSGEe
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
GitHub
Cognitive Services
Xamarin and Azure Better Together demo app team. Contribute to microsoft/XamarinAzure_ShoppingDemoApp development by creating an account on GitHub.
آیا مهاجرت به ASP.NET Core لازم است؟ نه لزوما! این جواب اولیهای است که معمار ارشد مایکروسافت Dino Esposito به این سوال دادهاست. جمله جالب دیگر او این است که «کافیست که شما بدانید چطور یک نرمافزار وب بنویسید، و همین بس است». او در ادامه یک جمله از یک رمان را نقل قول کرده: «اگر ما بخواهیم چیزها همانطور که هستند بمانند، آنها مجبور به تغییر خواهد شد!»
بنابرین او اعتقاد دارد نسل آینده نرمافزارها به این سمت میرود و اگر میخواهید در آینده هنوز نرمافزار تحت وب بنویسید، بالاخره روزی خواهد رسید که باید ابزارهای قدیمی خود را کنار بگذارید و به سمت جلو حرکت کنید.
در پست زیر Dino نظر خود در باره فلسفه مهاجرت به ASP.NET Core را توضیح میدهد. نحوه نگارش او طوری است که خواندن آن بسیار آموزنده است.
https://www.linkedin.com/pulse/me-aspnet-core-you-dino-esposito
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/8Aqo30aTBEs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
بنابرین او اعتقاد دارد نسل آینده نرمافزارها به این سمت میرود و اگر میخواهید در آینده هنوز نرمافزار تحت وب بنویسید، بالاخره روزی خواهد رسید که باید ابزارهای قدیمی خود را کنار بگذارید و به سمت جلو حرکت کنید.
در پست زیر Dino نظر خود در باره فلسفه مهاجرت به ASP.NET Core را توضیح میدهد. نحوه نگارش او طوری است که خواندن آن بسیار آموزنده است.
https://www.linkedin.com/pulse/me-aspnet-core-you-dino-esposito
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/8Aqo30aTBEs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from فلسفه دیزاین
دراپباکس دوستداشتنی و
روند هیجانانگیز بازطراحی آن
امروز با یه مقاله بسیار بسیار خواندنی همراهتون هستم.
اگر حتی یکبار بازطراحی (redesign) یک سرویس رو انجام داده باشید، میدونید که کار نسبتا مشکلی هست، مخصوصا برای سرویسهایی که Live هستند و کلی کاربر دارند. چراکه کاربرها به محیط عادت کردند و تغییر بنیادین اون باعث میشه کاربران مجبور بشن روندهایی که برای انجام کارها از قبل یادگرفته بودند رو فراموش کرده و روندهای جدید رو یادبگیرن.
اما سختتر از انجام روند بازطراحی، قانع کردن مدیران سیستم برای تن دادن به بازطراحی است. چراکه زمان خیلی از متخصصان رو گرفته و بسیار هزینهبر است.
سرویس بینظیر و بسیار کاربردی Dropbox رو همگی میشناسیم. این سرویس اخیرا بازطراحی کاملی روی وب انجام داده که محیطش رو بسیار تمیزتر، راحتتر و کاربردیتر کرده.
امروز میخوایم از زبان یکی از دیزاینرهای این سرویس بشنویم که در انجام روند بازطراحی با چه مشکلاتی روبرو بودند و چطور اونها رو حل کرده و پشت سر گذاشتن.
در مقاله امروز، آقای Ed Chao با تمرکزی بر روند قانع کردن مدیران سیستم برای انجام بازطراحی، برامون توضیح میده که در Dropbox چه روندی طی شده. در واقع از این روند، یک سیستم دیزاین تولید میکنه که از ۶ مرحله کلی تشکیل شده و شامل موارد زیر است:
- برقراری ارتباط با مشکلات موجود در سیستم
- ارائه راه حل مناسب
- ارائه شواهدی آزمایش شده برای مناسب بودن راه حل
- گسترش ایده بازطراحی در سازمان
- ثبات قدم در این مسیر
- گرفتن بازخورد
این مقاله به قدری هیجانانگیزه که توصیه میکنم آب دستتونه بذارید زمین و همین حالا مطالعهش کنید.
https://medium.com/dropbox-design/influencing-redes-85844706fbe4
(زمان حدودی مطالعه، ۸ دقیقه)
پ. ن.
در طول این مقاله یک سرویس جالب و متنباز به اسم Cactus از سازنده سرویس Framer، آقای Koen Bok معرفی میشه که خیلی کاربردیه.
#روند #طراحی_محصول #بازطراحی #تجربه_کاربری #مدیریت_طراحی
@Dexign دیزاین
___
روند هیجانانگیز بازطراحی آن
امروز با یه مقاله بسیار بسیار خواندنی همراهتون هستم.
اگر حتی یکبار بازطراحی (redesign) یک سرویس رو انجام داده باشید، میدونید که کار نسبتا مشکلی هست، مخصوصا برای سرویسهایی که Live هستند و کلی کاربر دارند. چراکه کاربرها به محیط عادت کردند و تغییر بنیادین اون باعث میشه کاربران مجبور بشن روندهایی که برای انجام کارها از قبل یادگرفته بودند رو فراموش کرده و روندهای جدید رو یادبگیرن.
اما سختتر از انجام روند بازطراحی، قانع کردن مدیران سیستم برای تن دادن به بازطراحی است. چراکه زمان خیلی از متخصصان رو گرفته و بسیار هزینهبر است.
سرویس بینظیر و بسیار کاربردی Dropbox رو همگی میشناسیم. این سرویس اخیرا بازطراحی کاملی روی وب انجام داده که محیطش رو بسیار تمیزتر، راحتتر و کاربردیتر کرده.
امروز میخوایم از زبان یکی از دیزاینرهای این سرویس بشنویم که در انجام روند بازطراحی با چه مشکلاتی روبرو بودند و چطور اونها رو حل کرده و پشت سر گذاشتن.
در مقاله امروز، آقای Ed Chao با تمرکزی بر روند قانع کردن مدیران سیستم برای انجام بازطراحی، برامون توضیح میده که در Dropbox چه روندی طی شده. در واقع از این روند، یک سیستم دیزاین تولید میکنه که از ۶ مرحله کلی تشکیل شده و شامل موارد زیر است:
- برقراری ارتباط با مشکلات موجود در سیستم
- ارائه راه حل مناسب
- ارائه شواهدی آزمایش شده برای مناسب بودن راه حل
- گسترش ایده بازطراحی در سازمان
- ثبات قدم در این مسیر
- گرفتن بازخورد
این مقاله به قدری هیجانانگیزه که توصیه میکنم آب دستتونه بذارید زمین و همین حالا مطالعهش کنید.
https://medium.com/dropbox-design/influencing-redes-85844706fbe4
(زمان حدودی مطالعه، ۸ دقیقه)
پ. ن.
در طول این مقاله یک سرویس جالب و متنباز به اسم Cactus از سازنده سرویس Framer، آقای Koen Bok معرفی میشه که خیلی کاربردیه.
#روند #طراحی_محصول #بازطراحی #تجربه_کاربری #مدیریت_طراحی
@Dexign دیزاین
___
Medium
Influencing redesign
How to convince your company to do a redesign
با اینکه قوانین CSS بسیار قابل فهم است و به راحتی میتوان آن را آموخت اما خیلی زود با برزگ شدن فایل CSS، همه چیز دچار بهم ریختگی و سردرگمی میشود. این مشکل مخصوصا زمانی نمایان میشود که افراد مختلفی از تیم روی فایلهای CSS کار میکنند و هر کدام رویه مختص به خود را دارند. اینجاست این که این سوال پیش می آید که چطور می توان کد CSS را بطور ساختار یافته تنظیم کرد تا در هر سایزی، نگهداری آن آسان و خوانایی بیشتری داشته باشد.
لینک زیر راه های ساده و کارآمدی را برای داشتن کد مرتب CSS معرفی میکند که استفاده از آنها توصیه میشود.
http://cssguidelin.es/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/IdOy30aYW4S
#مریم_داودی (http://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
لینک زیر راه های ساده و کارآمدی را برای داشتن کد مرتب CSS معرفی میکند که استفاده از آنها توصیه میشود.
http://cssguidelin.es/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/IdOy30aYW4S
#مریم_داودی (http://ow.ly/HGkG309B7de)
کانال تلگرام:
@SoftwarePhilosophy
___
cssguidelin.es
CSS Guidelines
High-level advice and guidelines for writing sane, manageable, scalable CSS
Forwarded from Iran Agile
🔴 راهنمای عملی پروتوتایپ برای مدیران محصول
به عنوان مدیر محصول اطمینان دارم که شما از اهمیت ساخت پروتوتایپ محصول برای مصور ساختن نیازمندیها و شناسایی ریسکهای پنهان محصول با خبر هستید. ۵۰ صفحه مستندات نیازمندی راه مطمئنی برای انتقال تمامی پیچیدگیهای خاص یک محصول دیجیتال نیست. بنابر تجربه این مستندات باعث سر رفتن حوصله خوانندگان و یا حتی بدتر از آن برداشت اشتباه خواهد شد. اما با استفاده از یک نمونه اولیه شما هر داستان کاربر را به بخشی از یک محصول قابل لمس تبدیل خواهید کرد.
http://blog.scrum.ir/2017/04/prototyping-for-product- managers
به عنوان مدیر محصول اطمینان دارم که شما از اهمیت ساخت پروتوتایپ محصول برای مصور ساختن نیازمندیها و شناسایی ریسکهای پنهان محصول با خبر هستید. ۵۰ صفحه مستندات نیازمندی راه مطمئنی برای انتقال تمامی پیچیدگیهای خاص یک محصول دیجیتال نیست. بنابر تجربه این مستندات باعث سر رفتن حوصله خوانندگان و یا حتی بدتر از آن برداشت اشتباه خواهد شد. اما با استفاده از یک نمونه اولیه شما هر داستان کاربر را به بخشی از یک محصول قابل لمس تبدیل خواهید کرد.
http://blog.scrum.ir/2017/04/prototyping-for-product- managers
دنیای چابک
دنیای چابک – راهنمای عملی پروتوتایپ برای مدیران محصول
ترجمه و ویراستاری: آیدین ضیاپور به عنوان مدیر محصول اطمینان دارم که شما از اهمیت ساخت پروتوتایپ محصول برای مصور سازی نیازمندیها و شناسایی ریسکهای پنهان م
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نحوه استفاده از هوش مصنوعی Microsoft Cognitive Services در سه پلتفرم Android, iOS, Windows 10
#ai #cognitiveservices #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/761
۲. نظر Dino Esposito در مورد زمان مهاجرت به ASP.NET Core
#aspnetcore #dotnetcore
https://news.1rj.ru/str/SoftwarePhilosophy/762
۳. دراپباکس دوستداشتنی و روند هیجانانگیز بازطراحی آن (دیزاین)
#design #ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/763
۴. راه های ساده و کارآمد برای داشتن کد مرتب CSS
#css #cleancode
https://news.1rj.ru/str/SoftwarePhilosophy/764
۵. راهنمای عملی پروتوتایپ برای مدیران محصول (Iran Agile)
#prototype
ـــــــــــ
@SoftwarePhilosophy
۱. نحوه استفاده از هوش مصنوعی Microsoft Cognitive Services در سه پلتفرم Android, iOS, Windows 10
#ai #cognitiveservices #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/761
۲. نظر Dino Esposito در مورد زمان مهاجرت به ASP.NET Core
#aspnetcore #dotnetcore
https://news.1rj.ru/str/SoftwarePhilosophy/762
۳. دراپباکس دوستداشتنی و روند هیجانانگیز بازطراحی آن (دیزاین)
#design #ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/763
۴. راه های ساده و کارآمد برای داشتن کد مرتب CSS
#css #cleancode
https://news.1rj.ru/str/SoftwarePhilosophy/764
۵. راهنمای عملی پروتوتایپ برای مدیران محصول (Iran Agile)
#prototype
ـــــــــــ
@SoftwarePhilosophy
تنظیم محیط برنامهنویسی Linux روی Windows 10 عنوان مقالهای است که اسکات هانسلمن در بلاگش در مورد آن توضیح دادهاست. یکی از نکات جالب مورد اشاره او در این پست این جمله بود: «بعضیها دوست دارند با ماوس و کلیک کار کنند، بعضیها ترجیح میدهند با کیبورد و تایپ کردن کار کنند، اشکال ندارد برای همه جا هست!»
دو عادت کاملا متفاوت برنامهنویسان، محیطهای کارمندی و محیطهای گرافیکی است. در این مقاله نحوه استفاده از bash روی linux که روی windows 10 بالا آمدهاست توضیح داده شده.
با مطالعه این مقاله با امکانات زیادی که برای تیپ برنامهنویسان کیبوردی طراحی شده آشنا میشوید.
https://www.hanselman.com/blog/SettingUpAShinyDevelopmentEnvironmentWithinLinuxOnWindows10.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/FD3X30b4Kyd
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
دو عادت کاملا متفاوت برنامهنویسان، محیطهای کارمندی و محیطهای گرافیکی است. در این مقاله نحوه استفاده از bash روی linux که روی windows 10 بالا آمدهاست توضیح داده شده.
با مطالعه این مقاله با امکانات زیادی که برای تیپ برنامهنویسان کیبوردی طراحی شده آشنا میشوید.
https://www.hanselman.com/blog/SettingUpAShinyDevelopmentEnvironmentWithinLinuxOnWindows10.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/FD3X30b4Kyd
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Hanselman
Setting up a Shiny Development Environment within Linux on Windows 10
While I was getting Ruby on Rails to work nicely under Ubuntu on Windows 10 I took the opportunity to set up my *nix ...
استفاده از امکانات Azure و TFS برای تیمهای برنامهنویسی بسیار جذاب است. بسیاری از مشکلاتی که در تیمهای نرمافزاری پیش میآید به علت نبود فرایندهای درست و ابزارهای مناسب است. یکی از دغدغههای تیمهای برنامهنویسی، نحوه تعامل و همکاری اعضای تیم در ساخت نیازمندیهای نرمافزار به صورت با کیفیت است. نیازها باید طوری شفاف تعریف شوند که قابل تست باشند. اصولا اگر یک نیازمندی به اندازهای واضح تعریف نشده که بتوان آن را تست کرد، احتمالا کد آن هم خیلی واضح به آن هدف نخواهد رسید!
در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی میشوند. سپس این Feature ها به Backlog Item ها شکسته میشوند. یک Backlog Item در حقیقت یک نیازمندیاست است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.
در مقاله زیر به طور خلاصه توضیح داده شدهاست که چگونه Sprint ها انجام میشوند.
http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3NGm30b5IjZ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی میشوند. سپس این Feature ها به Backlog Item ها شکسته میشوند. یک Backlog Item در حقیقت یک نیازمندیاست است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.
در مقاله زیر به طور خلاصه توضیح داده شدهاست که چگونه Sprint ها انجام میشوند.
http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3NGm30b5IjZ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
My Azure Experience: Handling the Requirements - Dot Philosophy
It is been a while I am doing some projects totally based on Azure ecosystem. As we are not working in a same place, it is a completely new experience for me because everything is different with working together in a company like place. I've recently started…
Forwarded from Iran Agile
دو مورد کلی باعث Gold Plating می شود:
1- عطش یادگیری در نیروهای فنی : چه دوست داشته باشیم یا نه، این ویژگی بارز نیروهای فنی است و آنها همیشه دوست دارند تکنولوژی های جدید را تجربه کنند و یاد بگیرند و دوباره یاد بگیرند. البته نیروی فنی با دیدن فیلم آموزشی یا کلاس چیزی یاد نمی گیرد، او زمانی یاد می گیرد که در پروژه (واقعی) تجربه کرده باشد. اما بعضی وقت ها هزینه یادگیری، یک پروژه شکست خورده می شود (یکی از دوستان می گفت؛ خوب چی مهم تر از این (: )
2- بزرگ جلوه دادن پروژه از سمت مدیران محصول: بعضی وقت ها مدیران محصول بدلیل عدم آشنایی با کسب کار، پروژه را بزرگ جلوه می دهند. مثلا برنامه نویس می پرسد چند نفر قرار است با این سیستم همزمان کار کنند، جواب "خیلی زیاد مثلا 500 هزار نفر". یا "آیا قرار است بعدا این قوانین کسب کار توسط خود مشتری عوض شوند؟" جواب: "بله". شاید یک جواب بله، باعث بشود که تیم به سراغ Workflow engine - فرم ساز و ... بروند و این یعنی هزینه خیلی زیاد.
👍 راه حل :
1- عطش یادگیری را نمی توان از بین برد، ولی شرکت هایی مثل گوگل که 20 درصد زمان را به خود نفرات می دهند، شاید یکی از دلایل همین یادگیری در حین کار باشد.
2- اصلا YAGNI در مورد این است که به چیزی که نیاز ندارید و مطئمن نیستید زیاد فکر نکنید، You are not gonna need it. یکی از هنرهای مدیریت محصول این است که تیم را به سمت ایجاد یک راه حل بزرگ نکشاند و سعی کند مشکل کسب کار را با کوچکترین راه حل ممکن حل کند.
3- هنر تیم هم این است که با تکیه بر اصول Keep it simple و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.
https://goo.gl/U4LLN0
1- عطش یادگیری در نیروهای فنی : چه دوست داشته باشیم یا نه، این ویژگی بارز نیروهای فنی است و آنها همیشه دوست دارند تکنولوژی های جدید را تجربه کنند و یاد بگیرند و دوباره یاد بگیرند. البته نیروی فنی با دیدن فیلم آموزشی یا کلاس چیزی یاد نمی گیرد، او زمانی یاد می گیرد که در پروژه (واقعی) تجربه کرده باشد. اما بعضی وقت ها هزینه یادگیری، یک پروژه شکست خورده می شود (یکی از دوستان می گفت؛ خوب چی مهم تر از این (: )
2- بزرگ جلوه دادن پروژه از سمت مدیران محصول: بعضی وقت ها مدیران محصول بدلیل عدم آشنایی با کسب کار، پروژه را بزرگ جلوه می دهند. مثلا برنامه نویس می پرسد چند نفر قرار است با این سیستم همزمان کار کنند، جواب "خیلی زیاد مثلا 500 هزار نفر". یا "آیا قرار است بعدا این قوانین کسب کار توسط خود مشتری عوض شوند؟" جواب: "بله". شاید یک جواب بله، باعث بشود که تیم به سراغ Workflow engine - فرم ساز و ... بروند و این یعنی هزینه خیلی زیاد.
👍 راه حل :
1- عطش یادگیری را نمی توان از بین برد، ولی شرکت هایی مثل گوگل که 20 درصد زمان را به خود نفرات می دهند، شاید یکی از دلایل همین یادگیری در حین کار باشد.
2- اصلا YAGNI در مورد این است که به چیزی که نیاز ندارید و مطئمن نیستید زیاد فکر نکنید، You are not gonna need it. یکی از هنرهای مدیریت محصول این است که تیم را به سمت ایجاد یک راه حل بزرگ نکشاند و سعی کند مشکل کسب کار را با کوچکترین راه حل ممکن حل کند.
3- هنر تیم هم این است که با تکیه بر اصول Keep it simple و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.
https://goo.gl/U4LLN0
دنیای چابک
دنیای چابک – ماست مالی کردن یا از دست ندادن بازار
مدیر:”آقا پس این کی تموم میشه؟” برنامه نویس:”این کار می بره، باید رو طراحیش کار کنم…” مدیر: “همینجوری خوبه، بده بدیم مش