#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://news.1rj.ru/str/SoftwarePhilosophy/895
۲. ایجاد هدر برای وبسایتهای چند صفحهای به منظور سرعت بخشی به لود شدن صفحات
#web
https://news.1rj.ru/str/SoftwarePhilosophy/896
۳. آشنایی با Code Map در Visual Studio
#visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/897
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://news.1rj.ru/str/SoftwarePhilosophy/898
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/899
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://news.1rj.ru/str/SoftwarePhilosophy/900
ـــــــــــ
@SoftwarePhilosophy
۱. مزایای Server Sent Events برای پروژههای تحت وب
#dotnet #web
https://news.1rj.ru/str/SoftwarePhilosophy/895
۲. ایجاد هدر برای وبسایتهای چند صفحهای به منظور سرعت بخشی به لود شدن صفحات
#web
https://news.1rj.ru/str/SoftwarePhilosophy/896
۳. آشنایی با Code Map در Visual Studio
#visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/897
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://news.1rj.ru/str/SoftwarePhilosophy/898
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/899
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://news.1rj.ru/str/SoftwarePhilosophy/900
ـــــــــــ
@SoftwarePhilosophy
قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار بسیار قانون جالبی است. این روزها در بسیاری از تیمهای نرمافزاری بحث استفاده یا عدم استفاده از مایکروسرویسها در معماری آینده تیم مطرح است. قانون Conways به طور کلی در مورد سیستمها صحبت میکند. این قانون میگوید:
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»
برای مثال اگر تیم برنامهنویسی در مکانهای فیزیکی مختلف، مثلا شهرهای مختلف، یا حتی زیر-تیمهای جدا کار میکند احتمالا معماری نرمافزارشان نیز بیشتر شبیه معماری مایکروسرویس است. در مقابل اگر یک تیم بزرگ برنامهنویسی هستید که همه در یک تیم کار میکنید احتمالا نرمافزارتان بیشتر شبیه یک مونولیت است.
این قانون گرچه اثبات نشده، ولی به طور ضمنی میگوید اگر میخواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.
https://www.thoughtworks.com/insights/blog/demystifying-conways-law
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/8byp30emn9u
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»
برای مثال اگر تیم برنامهنویسی در مکانهای فیزیکی مختلف، مثلا شهرهای مختلف، یا حتی زیر-تیمهای جدا کار میکند احتمالا معماری نرمافزارشان نیز بیشتر شبیه معماری مایکروسرویس است. در مقابل اگر یک تیم بزرگ برنامهنویسی هستید که همه در یک تیم کار میکنید احتمالا نرمافزارتان بیشتر شبیه یک مونولیت است.
این قانون گرچه اثبات نشده، ولی به طور ضمنی میگوید اگر میخواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.
https://www.thoughtworks.com/insights/blog/demystifying-conways-law
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/8byp30emn9u
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Thoughtworks
Demystifying Conway's Law | Thoughtworks
Many years ago, Melvin Conway had observed that how organizations were structured would have a strong impact on any systems they created. His observation has become known as Conway’s Law, and the collective experiences of both my colleagues and myself have…
Forwarded from Iran Agile
برگزاری جلسات بازنگری اسپرینت به شیوه ای نو
یکی از شکایتهای افراد تیم، تکراری شدن جلسات بازنگری اسپرینت است، "دائم چی خوب بود - چی بد بود و ... خوب که چی؟!"
یکی از هنرهای اسکرام مستر خوب پیدا کردن پرکتیسهای مناسب برای تیم خود است.
یکی از این منابع سایت زیر است :
🛠 http://www.funretrospectives.com
این سایت حاوی شیوه های جدید و تازه برای برگزاری جلسات بازنگری اسپرینت است.
@iranagile
یکی از شکایتهای افراد تیم، تکراری شدن جلسات بازنگری اسپرینت است، "دائم چی خوب بود - چی بد بود و ... خوب که چی؟!"
یکی از هنرهای اسکرام مستر خوب پیدا کردن پرکتیسهای مناسب برای تیم خود است.
یکی از این منابع سایت زیر است :
🛠 http://www.funretrospectives.com
این سایت حاوی شیوه های جدید و تازه برای برگزاری جلسات بازنگری اسپرینت است.
@iranagile
Forwarded from فلسفه دیزاین (Ramin Khatibi)
پنجمین نسخه از Swarm دوستداشتنی
احتمالا اپلیکیشن Foursquare همچنین Swarm را میشناسید. برای من Foursquare نمونه یک محصول بسیار موفقست (حتی بالاتر از Instagram و Facebook) که پیشرفت و پا گرفتنش را در ایران، لحظه به لحظه پیگیری کردهام. هوشمندی بینظیری که در Gamification داشت و روشهای اغواگرانهای که برای وادار کردن کاربر به فعالیت استفاده میکرد از مهمترین دلایلی بود که من را به این محصول علاقمند میکرد.
بعدها که اپلیکیشن Swarm با هدف جدا کردن تکهی شبکه اجتماعی Foursquare معرفی شد، فعالیت و پیگیریهای من هم کمی کمتر شد ولی این تیم همیشه تاثیر خود را در کار حرفهای من داشتهست. بطوریکه وقتی خواندم که اپلیکیشن جدید Foursquare بطور کامل در Sketch App طراحی شده، مهاجرت به این ابزار را برای خود یک الزام میدیدم.
تیم دیزاین این مجموعه، هماکنون نسخه 5.0 از اپلیکیشن Swarm را منتشر کردند که دستخوش تغییراتی بسیاری شدهاست.
مقاله امروز، داستانیست از زبان یکی از طراحان محصول این تیم که به بررسی روند این بازطراحی میپردازد و نکات جالبی در آن نهفتهست:
- میتوان متوجه دید و دغدغههای یک تیم دیزاین در این سطح، در روند بازطراحی محصول شد.
- میتوانید نمونهای از Style Guideهایی را که در تیمهای دیزاین دیگر ساخته میشود، ببینید.
- متوجه میشوید که یکی از وظایف شما به عنوان دیزاینر، به اشتراکگذاری ایدهها و طرحها و گرفتن بازخوردهاست. در هر سطحی که باشید.
و …
پیشنهاد میکنم همین حالا این داستان زیبا را مطالعه کنید.
https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f
(زمان حدودی مطالعه، ۱۰ دقیقه)
#تیم #بازطراحی #محصول #Swarm
@Dexign دیزاین
___
احتمالا اپلیکیشن Foursquare همچنین Swarm را میشناسید. برای من Foursquare نمونه یک محصول بسیار موفقست (حتی بالاتر از Instagram و Facebook) که پیشرفت و پا گرفتنش را در ایران، لحظه به لحظه پیگیری کردهام. هوشمندی بینظیری که در Gamification داشت و روشهای اغواگرانهای که برای وادار کردن کاربر به فعالیت استفاده میکرد از مهمترین دلایلی بود که من را به این محصول علاقمند میکرد.
بعدها که اپلیکیشن Swarm با هدف جدا کردن تکهی شبکه اجتماعی Foursquare معرفی شد، فعالیت و پیگیریهای من هم کمی کمتر شد ولی این تیم همیشه تاثیر خود را در کار حرفهای من داشتهست. بطوریکه وقتی خواندم که اپلیکیشن جدید Foursquare بطور کامل در Sketch App طراحی شده، مهاجرت به این ابزار را برای خود یک الزام میدیدم.
تیم دیزاین این مجموعه، هماکنون نسخه 5.0 از اپلیکیشن Swarm را منتشر کردند که دستخوش تغییراتی بسیاری شدهاست.
مقاله امروز، داستانیست از زبان یکی از طراحان محصول این تیم که به بررسی روند این بازطراحی میپردازد و نکات جالبی در آن نهفتهست:
- میتوان متوجه دید و دغدغههای یک تیم دیزاین در این سطح، در روند بازطراحی محصول شد.
- میتوانید نمونهای از Style Guideهایی را که در تیمهای دیزاین دیگر ساخته میشود، ببینید.
- متوجه میشوید که یکی از وظایف شما به عنوان دیزاینر، به اشتراکگذاری ایدهها و طرحها و گرفتن بازخوردهاست. در هر سطحی که باشید.
و …
پیشنهاد میکنم همین حالا این داستان زیبا را مطالعه کنید.
https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f
(زمان حدودی مطالعه، ۱۰ دقیقه)
#تیم #بازطراحی #محصول #Swarm
@Dexign دیزاین
___
Medium
How we designed Foursquare Swarm 5.0
Revamping our lifelog app
Forwarded from Software Philosophy
اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرمافزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.
این پیغام را برای آنها Forward کنید.
#پست_مجدد این پست تا به حال بیش از ۳۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
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…
شایعترین دلیل تخمین زمان اشتباه یک پروژه
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/958i30erVZs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/958i30erVZs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Effort vs. Time Estimation - Dot Philosophy
Estimating the required time for a task, is not an easy job to do, if you want to be precise! The main problem with estimating is that, most of the time it is wrong! Being wrong is not too bad for an estimation. But, being too wrong is a disaster for a project.…
Forwarded from راه پرداخت
راز تولید چابک در دل بزرگترین بانک ایران
اسد صفری؛ ماهنامه عصر تراکنش
بام یکی از بهترین و متفاوتترین اینترنتبانکهای ایرانی است که بهصورت چابک تولید شده است. صحبت از ۶۰ میلیون حساب در بانک ملی ایران است، از ۱۷۰۰ نفر نیروی شرکت سداد، حدود ۲۰۰ پروژهٔ تعریفشدهٔ همزمان در این شرکت و همکاری بیش از ۲۲ برنامهنویس و طراح روی یک پروژه، همهٔ این اعداد نشان از بزرگی موجودیتی دارد که میخواهد حرکت کند اما حرکت در آن بهمراتب کندتر از حرکت در شرکتهای کوچک و پویا است.
http://way2pay.ir/73221
اسد صفری؛ ماهنامه عصر تراکنش
بام یکی از بهترین و متفاوتترین اینترنتبانکهای ایرانی است که بهصورت چابک تولید شده است. صحبت از ۶۰ میلیون حساب در بانک ملی ایران است، از ۱۷۰۰ نفر نیروی شرکت سداد، حدود ۲۰۰ پروژهٔ تعریفشدهٔ همزمان در این شرکت و همکاری بیش از ۲۲ برنامهنویس و طراح روی یک پروژه، همهٔ این اعداد نشان از بزرگی موجودیتی دارد که میخواهد حرکت کند اما حرکت در آن بهمراتب کندتر از حرکت در شرکتهای کوچک و پویا است.
http://way2pay.ir/73221
راه پرداخت
راز تولید چابک در دل بزرگترین بانک ایران
راز تولید چابک در دل بزرگترین بانک ایران بام نسل جدید سامانه «بانک اول من» یا همان بانکداری اینترنتی بانک ملی است که به مشتریان بانک ملی سرویس میدهد
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار
https://news.1rj.ru/str/SoftwarePhilosophy/902
۲. برگزاری جلسات بازنگری اسپرینت به شیوه ای نو (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/903
۳. پنجمین نسخه از Swarm (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/904
۴. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
https://news.1rj.ru/str/SoftwarePhilosophy/907
۵. شایعترین دلیل تخمین زمان اشتباه یک پروژه
https://news.1rj.ru/str/SoftwarePhilosophy/908
۶. راز تولید چابک در دل بزرگترین بانک ایران (راه پرداخت)
https://news.1rj.ru/str/SoftwarePhilosophy/909
ـــــــــــ
@SoftwarePhilosophy
۱. قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار
https://news.1rj.ru/str/SoftwarePhilosophy/902
۲. برگزاری جلسات بازنگری اسپرینت به شیوه ای نو (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/903
۳. پنجمین نسخه از Swarm (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/904
۴. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»
https://news.1rj.ru/str/SoftwarePhilosophy/907
۵. شایعترین دلیل تخمین زمان اشتباه یک پروژه
https://news.1rj.ru/str/SoftwarePhilosophy/908
۶. راز تولید چابک در دل بزرگترین بانک ایران (راه پرداخت)
https://news.1rj.ru/str/SoftwarePhilosophy/909
ـــــــــــ
@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
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/KVCh30ewRvs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح دادهاست.
https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/KVCh30ewRvs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Hanselman
.NET and WebAssembly - Is this the future of the front-end?
6 years ago Erik Meijer and I were talking about how JavaScript is/was an assembly language. It turned into an ...
#پست_مجدد این پست تا به حال بیش از ۴۸۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
محصولی مانند BMW واقعا چگونه در ذهن ما به عنوان یک محصول با کیفیت شکل گرفته است؟ آیا ما تخصص بررسی عملکرد موتور و گیربکس آن را داریم؟ آیا مقایسهای فنی روی آن انجام دادهایم تا بفهمیم ماشین BMW یک محصول با کیفیت است؟
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف میکند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه میکند. یک نقطه تماس میتواند لحظاتی باشد که مشتری با آن کار میکند، یا لحظاتی که مشتری پوستر محصول را میبیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن میشوند.
ما برنامه نویسها عادت کردیم برنامه بنویسیم! و البته دوست داریم مشتریان برای این عادت ما ارزش قائل شوند و برای آن پول پرداخت کنند. اما حقیقت این است که مشتریان چیزی از زیبایی معماری نرمافزار ما نمیبینند همانطور که چیزی از جزئیات گیربکس یک BMW نمیدانند.
در حقیقت بهترین معماری و برنامهنویسی زمانی اتفاق میافتد که آنقدر همه چیز درست کار کند که مشتری اصلا نفهمد برنامه نویسی انجام شده، همانطور که یک گیربکس عالی گیربکسی است که مشتری هیچوقت متوجه وجودش نشود و فقط مطمئن باشد که دنده به درستی عمل میکند.
بنابر این در اکثر مواقع توضیح اینکه برنامه چقدر خوب نوشته شده ارزشی برای مشتریان ندارد.
مقاله زیر به طور خلاصه مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری را شرح دادهاست.
http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف میکند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه میکند. یک نقطه تماس میتواند لحظاتی باشد که مشتری با آن کار میکند، یا لحظاتی که مشتری پوستر محصول را میبیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن میشوند.
ما برنامه نویسها عادت کردیم برنامه بنویسیم! و البته دوست داریم مشتریان برای این عادت ما ارزش قائل شوند و برای آن پول پرداخت کنند. اما حقیقت این است که مشتریان چیزی از زیبایی معماری نرمافزار ما نمیبینند همانطور که چیزی از جزئیات گیربکس یک BMW نمیدانند.
در حقیقت بهترین معماری و برنامهنویسی زمانی اتفاق میافتد که آنقدر همه چیز درست کار کند که مشتری اصلا نفهمد برنامه نویسی انجام شده، همانطور که یک گیربکس عالی گیربکسی است که مشتری هیچوقت متوجه وجودش نشود و فقط مطمئن باشد که دنده به درستی عمل میکند.
بنابر این در اکثر مواقع توضیح اینکه برنامه چقدر خوب نوشته شده ارزشی برای مشتریان ندارد.
مقاله زیر به طور خلاصه مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری را شرح دادهاست.
http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Touch Point: The Real Percepction of a Product - Dot Philosophy
Recently I've participated in a great workshop about Service Design. It was a totally new concept to me. The course was designed surprisingly great by Joannes Vandermeulen from Namahn. If you ask me about the most important keyword I've learned in the course…
Forwarded from Iran Agile
☕ وقتی فرهنگ استراتژی را بعنوان صبحانه میبلعد
شاید بدون شک بتوان گفت که امروز اساسی ترین مشکل کسب وکارها در دنیا، نیروی کار است، در صنعت IT که بشدت وابسته به نیروی متخصص بوده و بخصوص در ایران که کمبود نیروی متخصص و پایین بودن بهره وری (بدلایل مختلف مثل علاقه به کارآفرین شدن، اقتصادی، سیاسی، محیط زیستی، تحریم و…) بشدت محسوس است. بدلیل همین مشکل بزرگ شرکتها دائم در پی راهی هستند تا بهره وری نیروی انسانی خود را بالا ببرند. اما راه اساسی برای این کار چیست؟
وقتی شرکت هایی مثل گوگل، مایکروسافت رو می بینیم، اولین چیزی که جلب نظر میکند سرسره ها، میزهای پینگ پنگ، سالن نهار خوری و پلی استیشن آنها است، به عنوان مدیر یک شرکت فکر می کنم با فراهم کردن چنین محیط و ابزارهایی بتوانم باعث افزایش بهره وری بشوم، افزایش بهره وری یعنی اینکه “رفتارهایی که باب میل کسب و کار هست بیشتر دیده شود، مثلا رفتار کارمندها با مشتریان بهتر شود یا کارمندها با علاقه بیشتر در سر کار حاضر شوند” همه این رفتارها را در یک قالبی با عنوان “فرهنگ” شناخت می شود.
پس با ده میلیون می خواهیم برای شرکت و سازمان فرهنگ بخریم.
سوال اساسی این است که آیا می شود فرهنگ را خرید؟
اما شاید یکسری دوستان به من ایراد بگیرن، “آقا ما نتیجش رو دیدیم”، یا مثلا “این شرکت های خارجی که خیلی بیشتر از ما حالیشون هست”.
جواب این می تواند باشد که، “تا حالا شده بخواهید چیزی رو بخرید و کلی هیجان داشته باشید و فکر کنید اگر این رو بخرم دیگه تمومه، دیگه آخرشه، مثل یک ماشین، خونه، یا حتی سی دی آهنگ، ولی به احتمال زیاد بعد از مدتی براتون خیلی عادی شده، یا مثلا حقوق شما تا یکماه قبل یک میلیون بوده، الان شده سه میلیون، این احتمالا تا دو سه ماه برای شما هیجان خواهد داشت، پس خیلی از این اسباب و وسایل برای کاتالیز کردن هستند، یا اصظلاحا بهشون میگن نوشابه انرژی زا، یک ذره تکون میده شما رو ولی خیلی کوتاه مدت.”
فرهنگ چیست؟ کیست؟ چطوری است؟
فرهنگ یعنی “آنگونه که ما در عمل رفتار می کنیم” نه آنچیزی که تظاهر یا فکر می کنیم. پس این منشور اخلاقی و یا سخنرانی هایی که داریم؛ “ما یک شرکت مشتری مدار هستیم، ما به نیروهامون اعتماد کامل داریم” اسمش فرهنگ نیست، آنچیزی که در عمل می بینیم فرهنگ واقعی است “مثلا وقتی یک مشتری عصبانی زنگ میزنه و رفتاری که ما می کنیم، یا وقتی در شرکت زیر آب هم رو میزنیم و می گوییم بهم خیلی اعتماد داریم”
فرهنگ، استراتژی رو به عنوان صبحانه میخوره، یعنی چی؟
فرهنگ نه تنها استراتژی، بلکه همه چیز را به عنوان صبحانه می بلعد، “طرح، برنامه، پروژه، استارتاپ، شرکت، سازمان”. این یعنی اینکه شما اگر برنامه خیلی خوبی داشته باشید، ایده عالی داشته باشین برای اجرا، اگر فرهنگ شما هم راستا با این ایده شما نباشد آن را نابود خواهد کرد.
افسانه هایی در مورد فرهنگ
یکی از کارهای مشاورین این هست که مسائل را سخت جلوه بدهند تا بگویند ما فقط می توانیم به شما کمک کنیم، در مورد فرهنگ نیز چنین چیزهایی هست، مثلا برای تغییر فرهنگ دو نسل باید عوض شود یا تغییر فرهنگ بازه 25 ساله نیاز دارد، خیلی از این موارد درست است ولی یک ذره هم اغراق در آنها دیده می شود، اگر فرهنگ قابل عوض شدن نبود چطور در عرض چند سال گوشیهای هوشمند زندگی ما را عوض کردند؟ چگونه پدران و مادران ما کاربر هر روزه اینترنت شدند؟ چگونه دید و بازدید عید در عرض چند سال در حال از بین رفتن است؟ چگونه قبل از غذا خوردن باید از آن عکس بگیریم و در اینستاگرام بگذاریم “من و سوشی یهویی …”.
فرهنگ یک شب ایجاد نمی شود و البته یک شبه هم از بین نمی رود
خوبی یا بدی فرهنگ این است، نه یک شب ایجاد می شود و نه یک شب از بین می رود، تغییر فرهنگ نیاز به یک فرآیند چند مرحله ای دارد، که به مرور باید اجرا شود. تغییر فرهنگ چیزی نیست که شما از اول برنامه ریزی کنید و آن را اجرا کنید، بلکه باید برنامه های کوچکی داشته باشید، آن را اجرا کنید، نتیجه را بسنجید، دوباره برنامه ریزی کنید و دوباره اجرا کنید و … .
ادامه در لینک زیر 👇👇
https://goo.gl/dHHycC
@iranagile
شاید بدون شک بتوان گفت که امروز اساسی ترین مشکل کسب وکارها در دنیا، نیروی کار است، در صنعت IT که بشدت وابسته به نیروی متخصص بوده و بخصوص در ایران که کمبود نیروی متخصص و پایین بودن بهره وری (بدلایل مختلف مثل علاقه به کارآفرین شدن، اقتصادی، سیاسی، محیط زیستی، تحریم و…) بشدت محسوس است. بدلیل همین مشکل بزرگ شرکتها دائم در پی راهی هستند تا بهره وری نیروی انسانی خود را بالا ببرند. اما راه اساسی برای این کار چیست؟
وقتی شرکت هایی مثل گوگل، مایکروسافت رو می بینیم، اولین چیزی که جلب نظر میکند سرسره ها، میزهای پینگ پنگ، سالن نهار خوری و پلی استیشن آنها است، به عنوان مدیر یک شرکت فکر می کنم با فراهم کردن چنین محیط و ابزارهایی بتوانم باعث افزایش بهره وری بشوم، افزایش بهره وری یعنی اینکه “رفتارهایی که باب میل کسب و کار هست بیشتر دیده شود، مثلا رفتار کارمندها با مشتریان بهتر شود یا کارمندها با علاقه بیشتر در سر کار حاضر شوند” همه این رفتارها را در یک قالبی با عنوان “فرهنگ” شناخت می شود.
پس با ده میلیون می خواهیم برای شرکت و سازمان فرهنگ بخریم.
سوال اساسی این است که آیا می شود فرهنگ را خرید؟
اما شاید یکسری دوستان به من ایراد بگیرن، “آقا ما نتیجش رو دیدیم”، یا مثلا “این شرکت های خارجی که خیلی بیشتر از ما حالیشون هست”.
جواب این می تواند باشد که، “تا حالا شده بخواهید چیزی رو بخرید و کلی هیجان داشته باشید و فکر کنید اگر این رو بخرم دیگه تمومه، دیگه آخرشه، مثل یک ماشین، خونه، یا حتی سی دی آهنگ، ولی به احتمال زیاد بعد از مدتی براتون خیلی عادی شده، یا مثلا حقوق شما تا یکماه قبل یک میلیون بوده، الان شده سه میلیون، این احتمالا تا دو سه ماه برای شما هیجان خواهد داشت، پس خیلی از این اسباب و وسایل برای کاتالیز کردن هستند، یا اصظلاحا بهشون میگن نوشابه انرژی زا، یک ذره تکون میده شما رو ولی خیلی کوتاه مدت.”
فرهنگ چیست؟ کیست؟ چطوری است؟
فرهنگ یعنی “آنگونه که ما در عمل رفتار می کنیم” نه آنچیزی که تظاهر یا فکر می کنیم. پس این منشور اخلاقی و یا سخنرانی هایی که داریم؛ “ما یک شرکت مشتری مدار هستیم، ما به نیروهامون اعتماد کامل داریم” اسمش فرهنگ نیست، آنچیزی که در عمل می بینیم فرهنگ واقعی است “مثلا وقتی یک مشتری عصبانی زنگ میزنه و رفتاری که ما می کنیم، یا وقتی در شرکت زیر آب هم رو میزنیم و می گوییم بهم خیلی اعتماد داریم”
فرهنگ، استراتژی رو به عنوان صبحانه میخوره، یعنی چی؟
فرهنگ نه تنها استراتژی، بلکه همه چیز را به عنوان صبحانه می بلعد، “طرح، برنامه، پروژه، استارتاپ، شرکت، سازمان”. این یعنی اینکه شما اگر برنامه خیلی خوبی داشته باشید، ایده عالی داشته باشین برای اجرا، اگر فرهنگ شما هم راستا با این ایده شما نباشد آن را نابود خواهد کرد.
افسانه هایی در مورد فرهنگ
یکی از کارهای مشاورین این هست که مسائل را سخت جلوه بدهند تا بگویند ما فقط می توانیم به شما کمک کنیم، در مورد فرهنگ نیز چنین چیزهایی هست، مثلا برای تغییر فرهنگ دو نسل باید عوض شود یا تغییر فرهنگ بازه 25 ساله نیاز دارد، خیلی از این موارد درست است ولی یک ذره هم اغراق در آنها دیده می شود، اگر فرهنگ قابل عوض شدن نبود چطور در عرض چند سال گوشیهای هوشمند زندگی ما را عوض کردند؟ چگونه پدران و مادران ما کاربر هر روزه اینترنت شدند؟ چگونه دید و بازدید عید در عرض چند سال در حال از بین رفتن است؟ چگونه قبل از غذا خوردن باید از آن عکس بگیریم و در اینستاگرام بگذاریم “من و سوشی یهویی …”.
فرهنگ یک شب ایجاد نمی شود و البته یک شبه هم از بین نمی رود
خوبی یا بدی فرهنگ این است، نه یک شب ایجاد می شود و نه یک شب از بین می رود، تغییر فرهنگ نیاز به یک فرآیند چند مرحله ای دارد، که به مرور باید اجرا شود. تغییر فرهنگ چیزی نیست که شما از اول برنامه ریزی کنید و آن را اجرا کنید، بلکه باید برنامه های کوچکی داشته باشید، آن را اجرا کنید، نتیجه را بسنجید، دوباره برنامه ریزی کنید و دوباره اجرا کنید و … .
ادامه در لینک زیر 👇👇
https://goo.gl/dHHycC
@iranagile
Forwarded from فلسفه دیزاین (Ramin Khatibi)
سرویس Figma 2.0: ابزاری برای تمام فصول
وقتی ابزار Sketch معرفی شد، من کاربر Photoshop بودم و به خاطر سالها کار با این رفیق قدیمیام و حفظ بودن تمام میانبرها، ضعفها و قوتهایش، دلم نمیخواست به سمت ابزار جدیدی بروم. کمی گذشت و Sketch با بروزرسانیهایش، همه را شگفتزده کرد و تیمهای دیزاین قوی مثل Foursquare به سمت آن رفته و اپلیکیشن خود را با آن بازطراحی کردند.
طلسم را شکستم و استفاده از Sketch را آغاز کردم. این اتفاق به قدری لذتبخش بود که به نقطه عطفی از زندگی کاریام بدل شد و از آن پس هر ابزار جدیدی را امتحان میکنم.
چندی قبل، خبر انتشار یک ابزار Collaborative طراحی رابط کاربری به اسم Figma را خواندم و زمانی را برای تیم دیزاین شرکت خالی کردم تا این ابزار را تست کنیم. چند صفحه از یک اپلیکیشن آشپزی را طراحی کردیم که نتایج آن روی Behance تیممان قابل مشاهدهست:
https://www.behance.net/gallery/49456671/COOKY-APP
بعد از تجربه خوب کار با Figma، اخبار آن را مشتاقانهتر دنبال میکردم. تیم پرشور و هیجان این ابزار کاربردی، حالا نسخه دوم از ابزار خود را معرفی کردند که امکان Prototyping و همچنین امکانی به اسم Developer Handoff را برای کاربران خود به ارمغان آورده است. Developer Handoff ویژگیست که به دیزاینرها اجازه میدهد یک نسخه از فایل دیزاین خود را بصورت View Only و غیرقابل ویرایش با توسعهدهنده پروژه به اشتراک بگذارند. توسعهدهنده با کلیک روی هر لایه میتواند ویژگیهای آن را بصورت غیرقابل ویرایشی ببیند و حتی آیکنها و سایر Assetهای مورد نظر خود را مستقیما از همان فایل، با اندازه و فرمت مد نظرش، خروجی بگیرد.
ابزار Figma، بصورت کامل از فرمتهای گرافیک بُرداری (Vector) پشتیبانی میکند و به راحتی میتوانید از آنها در طراحیهای خود استفاده کنید.
مقاله امروز، معرفی ویژگیهای جدید Figma، از زبان بنیانگذار و مدیرعامل این سرویس، Dylan Field است.
به نظر من آینده از آنِ ابزارهای Collaborative بوده و Figma تا کنون بینظیر عمل کرده است.
مقاله امروز را از دست ندهید:
https://blog.figma.com/figma-2-0-now-with-prototyping-and-developer-handoff-1b309a5d025c
(زمان حدودی مطالعه، ۸ دقیقه)
#معرفی #ابزار #Figma
@Dexign دیزاین
___
وقتی ابزار Sketch معرفی شد، من کاربر Photoshop بودم و به خاطر سالها کار با این رفیق قدیمیام و حفظ بودن تمام میانبرها، ضعفها و قوتهایش، دلم نمیخواست به سمت ابزار جدیدی بروم. کمی گذشت و Sketch با بروزرسانیهایش، همه را شگفتزده کرد و تیمهای دیزاین قوی مثل Foursquare به سمت آن رفته و اپلیکیشن خود را با آن بازطراحی کردند.
طلسم را شکستم و استفاده از Sketch را آغاز کردم. این اتفاق به قدری لذتبخش بود که به نقطه عطفی از زندگی کاریام بدل شد و از آن پس هر ابزار جدیدی را امتحان میکنم.
چندی قبل، خبر انتشار یک ابزار Collaborative طراحی رابط کاربری به اسم Figma را خواندم و زمانی را برای تیم دیزاین شرکت خالی کردم تا این ابزار را تست کنیم. چند صفحه از یک اپلیکیشن آشپزی را طراحی کردیم که نتایج آن روی Behance تیممان قابل مشاهدهست:
https://www.behance.net/gallery/49456671/COOKY-APP
بعد از تجربه خوب کار با Figma، اخبار آن را مشتاقانهتر دنبال میکردم. تیم پرشور و هیجان این ابزار کاربردی، حالا نسخه دوم از ابزار خود را معرفی کردند که امکان Prototyping و همچنین امکانی به اسم Developer Handoff را برای کاربران خود به ارمغان آورده است. Developer Handoff ویژگیست که به دیزاینرها اجازه میدهد یک نسخه از فایل دیزاین خود را بصورت View Only و غیرقابل ویرایش با توسعهدهنده پروژه به اشتراک بگذارند. توسعهدهنده با کلیک روی هر لایه میتواند ویژگیهای آن را بصورت غیرقابل ویرایشی ببیند و حتی آیکنها و سایر Assetهای مورد نظر خود را مستقیما از همان فایل، با اندازه و فرمت مد نظرش، خروجی بگیرد.
ابزار Figma، بصورت کامل از فرمتهای گرافیک بُرداری (Vector) پشتیبانی میکند و به راحتی میتوانید از آنها در طراحیهای خود استفاده کنید.
مقاله امروز، معرفی ویژگیهای جدید Figma، از زبان بنیانگذار و مدیرعامل این سرویس، Dylan Field است.
به نظر من آینده از آنِ ابزارهای Collaborative بوده و Figma تا کنون بینظیر عمل کرده است.
مقاله امروز را از دست ندهید:
https://blog.figma.com/figma-2-0-now-with-prototyping-and-developer-handoff-1b309a5d025c
(زمان حدودی مطالعه، ۸ دقیقه)
#معرفی #ابزار #Figma
@Dexign دیزاین
___
Behance
COOKY APP
This is a delicious result of our team working with Figma.com.It was a joyful experience. Viva Figma team.Hope your enjoy it.
ممکن است در فرایند توسعهی برنامههای SPA که UI آنها با screenهای با اندازههای متفاوت موبایل تا دسکتاپ سازگار است٬ نیاز به تست برنامه روی Device ها داشته باشید. Browsersync ابزاری قدرتمند است که در ترکیب با Webpack و Hot Reloading این امکان را به شما میدهد تا به جای تست app روی شبیه ساز های device بتوانید مستقیما روی device تست و debug را انجام دهید.
برای توضیحات بیشتر به لینک زیر مراجعه کنید.
https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3dge30eCtwT
#شراره_لطفی (http://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
برای توضیحات بیشتر به لینک زیر مراجعه کنید.
https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3dge30eCtwT
#شراره_لطفی (http://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
Manav Sehgal
Browsersync and Webpack For Testing Web Apps Across Multiple Devices
Your single page app is mobile-web friendly. It responds to smaller or larger screen sizes and adapts the UI accordingly. As you continue…
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
با اینکه قوانین 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
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آیا ترکیب WebAssembly و .Net آینده برنامهنویسی front-end است؟
https://news.1rj.ru/str/SoftwarePhilosophy/911
۲. مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری
https://news.1rj.ru/str/SoftwarePhilosophy/913
۳. وقتی فرهنگ استراتژی را بعنوان صبحانه میبلعد (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/914
۴. سرویس Figma 2.0: ابزاری برای تمام فصول (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/915
۵. آشنایی با Browsersync
https://news.1rj.ru/str/SoftwarePhilosophy/916
۶. راه های ساده و کارآمد برای داشتن کد مرتب CSS
#css #cleancode
https://news.1rj.ru/str/SoftwarePhilosophy/918
@SoftwarePhilosophy
____
۱. آیا ترکیب WebAssembly و .Net آینده برنامهنویسی front-end است؟
https://news.1rj.ru/str/SoftwarePhilosophy/911
۲. مفهوم Touch Point و نقش آن در تعریف محصولات نرمافزاری
https://news.1rj.ru/str/SoftwarePhilosophy/913
۳. وقتی فرهنگ استراتژی را بعنوان صبحانه میبلعد (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/914
۴. سرویس Figma 2.0: ابزاری برای تمام فصول (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/915
۵. آشنایی با Browsersync
https://news.1rj.ru/str/SoftwarePhilosophy/916
۶. راه های ساده و کارآمد برای داشتن کد مرتب CSS
#css #cleancode
https://news.1rj.ru/str/SoftwarePhilosophy/918
@SoftwarePhilosophy
____
Forwarded from Iran Agile
📈 پروژه مدیریت مستردیتا به روش چابک
اطلاعات موجود در دنیای دیجیتال تا سال 2020 به 44 زتابایت یا 44 تریلیون گیگابایت خواهد رسید (الان تقریبا 5 زتابایت است)، این حجم دیتا باعث می شود که سازمانها به فکر پروژه های مدیریت مستردیتا یا Master Data Management بیفتند. زیرا MDM نقش بسزایی در تحلیل یا گزارش یا حتی سیستم های تراکنشی دارد.
خروجی پروژه های MDM ایجاد دیتابیس مستر خواهد بود که توسط سیستمهای دیگر استفاده می شود.
اما پروژه های MDM میل بشدت زیادی به شکست دارند. دلیل اصلی این اتفاق سرعت است. ماهها و یا سالها بخش IT شرکت مشغول تحلیل و مدل سازی می شود و مدت های خروجی یا فایل مستری ایجاد نمی شود که مصرف کنندگان از آن استفاده کنند و به مرور با از طولانی شدن این فرآیند حمایت مدیران ارشد از بین خواهد رفت و این نوع پروژه بدون حمایت مدیران ارشد به هیچ وجه به پیش نخواهد رفت.
شاید دلیل اصلی، کندی انجام پروژه ها یا به ثمر نرسیدن پروژه "دید ایده آل گرایانه یا رکورد کامل و بینقص است".
@iranagile
گویند شخصی با کاسهای ماست در کنار دریا نشسته بود و با قاشقی ماست را به دریا میریخت.
از او پرسیدند چه کار میکنی، گفت دارم دوغ درست میکنم. به او گفتند با این کاسه ماست که نمیشود آب دریا را دوغ کرد. باز پاسخ داد که میدانم نمیشود اما اگه بشود چه میشود.
اما پروژه MDM به سبک چابک، به جای ایجاد رکورد کامل، دنبال پیروزی های کوچک در راستای رسیدن به اهداف تجاری است. اگر داده های مشتریان مهمتر است، ابتدا تمرکز پروژه بر روی این داده ها خواهد بود.
به جای رکورد کامل، تاکید بر روی رکورد طلایی است، داده هایی که مهمتر هستند و دائم در حال آپدیت شدن هستند.
در این مورد بیشتر بخوانید:
https://goo.gl/azSP4x
@iranagile
اطلاعات موجود در دنیای دیجیتال تا سال 2020 به 44 زتابایت یا 44 تریلیون گیگابایت خواهد رسید (الان تقریبا 5 زتابایت است)، این حجم دیتا باعث می شود که سازمانها به فکر پروژه های مدیریت مستردیتا یا Master Data Management بیفتند. زیرا MDM نقش بسزایی در تحلیل یا گزارش یا حتی سیستم های تراکنشی دارد.
خروجی پروژه های MDM ایجاد دیتابیس مستر خواهد بود که توسط سیستمهای دیگر استفاده می شود.
اما پروژه های MDM میل بشدت زیادی به شکست دارند. دلیل اصلی این اتفاق سرعت است. ماهها و یا سالها بخش IT شرکت مشغول تحلیل و مدل سازی می شود و مدت های خروجی یا فایل مستری ایجاد نمی شود که مصرف کنندگان از آن استفاده کنند و به مرور با از طولانی شدن این فرآیند حمایت مدیران ارشد از بین خواهد رفت و این نوع پروژه بدون حمایت مدیران ارشد به هیچ وجه به پیش نخواهد رفت.
شاید دلیل اصلی، کندی انجام پروژه ها یا به ثمر نرسیدن پروژه "دید ایده آل گرایانه یا رکورد کامل و بینقص است".
@iranagile
گویند شخصی با کاسهای ماست در کنار دریا نشسته بود و با قاشقی ماست را به دریا میریخت.
از او پرسیدند چه کار میکنی، گفت دارم دوغ درست میکنم. به او گفتند با این کاسه ماست که نمیشود آب دریا را دوغ کرد. باز پاسخ داد که میدانم نمیشود اما اگه بشود چه میشود.
اما پروژه MDM به سبک چابک، به جای ایجاد رکورد کامل، دنبال پیروزی های کوچک در راستای رسیدن به اهداف تجاری است. اگر داده های مشتریان مهمتر است، ابتدا تمرکز پروژه بر روی این داده ها خواهد بود.
به جای رکورد کامل، تاکید بر روی رکورد طلایی است، داده هایی که مهمتر هستند و دائم در حال آپدیت شدن هستند.
در این مورد بیشتر بخوانید:
https://goo.gl/azSP4x
@iranagile
Forwarded from فلسفه دیزاین (Ramin Khatibi)
جادوی سیاهی به نام نوتیفیکیشن
سالیان زیادیست که نوتیفیکیشنها به انسانها کمک میکنند. وقتی زنگ در و یا زنگ تلفن به صدا در میآید و یا حتی وقتی کسی نام ما را صدا میکند، در حال دریافت اعلان یا Notification هستیم.
این روزها شنیدن واژه نوتیفیکیشن ما را به یاد نقطه قرمز در اپلیکیشنهای Instagram یا Facebook میاندازد. نقطههایی که با تغییر مغزهای ما در گذر زمان، حالا مجبورمان میکنند که آن بخش را چک کنیم.
تمامی ما روزانه تعداد زیادی نوتیفیکیشن دریافت میکنیم که به ما یادآوری میکنند که سربازهایمان در Clash of Clans آمادهاند، یا رکورد تعداد قدمهای روزانه خود را رد کردهایم؛ و البته به دریافت آنهای عادت کردهایم.
گاهی این ابزار، در دستان کسبوکارهای مختلف به قدرت جادویی سیاهی تبدیل میشود که از آن برای کشاندن کاربران به داخل اپلیکیشنها و وبسایتها خودشان استفاده میکنند.
با شکلگیری فضاهایی مانند شبکههای مجازی آزاد، روز به روز سوالاتی مانند اینکه حد و مرز و قانون استفاده از یک شبکه مجازی کجاست؟ بیشتر مطرح میشود.
به نظر شما چه حد و حدودی در استفاده از نوتیفیکیشنها وجود دارد؟
نویسنده مقاله امروز، آقای Andrew Wilshere به این سوال میپردازد و با بررسی معروفترین سرویسهای دنیا مانند Instagram، Facebook و یا Twitter به ما نشان میدهد که هر کسبوکار و هر سرویسی، حدی متفاوت از استفاده از نوتیفیکیشن را برای خود تعریف کردهاست.
سوال مهم این است که سرویس طراحی شده توسط شما در کجای این مرز قرار میگیرد؟
http://trydesignlab.com/blog/are-notifications-a-dark-pattern-ux-ui/
(زمان حدودی مطالعه، ۱۰ دقیقه)
پ. ن.
در این مقاله مفهومی به اسم Dark Patterns توضیح داده شده است که به معنای کلی برای گول زدن کاربر برای انجام کاری که تمایلی به آن ندارد است. نمونههای جالبی هم معرفی شدهاست.
#مفاهیم #چالش #اعلان #نوتیفیکیشن
@Dexign دیزاین
___
سالیان زیادیست که نوتیفیکیشنها به انسانها کمک میکنند. وقتی زنگ در و یا زنگ تلفن به صدا در میآید و یا حتی وقتی کسی نام ما را صدا میکند، در حال دریافت اعلان یا Notification هستیم.
این روزها شنیدن واژه نوتیفیکیشن ما را به یاد نقطه قرمز در اپلیکیشنهای Instagram یا Facebook میاندازد. نقطههایی که با تغییر مغزهای ما در گذر زمان، حالا مجبورمان میکنند که آن بخش را چک کنیم.
تمامی ما روزانه تعداد زیادی نوتیفیکیشن دریافت میکنیم که به ما یادآوری میکنند که سربازهایمان در Clash of Clans آمادهاند، یا رکورد تعداد قدمهای روزانه خود را رد کردهایم؛ و البته به دریافت آنهای عادت کردهایم.
گاهی این ابزار، در دستان کسبوکارهای مختلف به قدرت جادویی سیاهی تبدیل میشود که از آن برای کشاندن کاربران به داخل اپلیکیشنها و وبسایتها خودشان استفاده میکنند.
با شکلگیری فضاهایی مانند شبکههای مجازی آزاد، روز به روز سوالاتی مانند اینکه حد و مرز و قانون استفاده از یک شبکه مجازی کجاست؟ بیشتر مطرح میشود.
به نظر شما چه حد و حدودی در استفاده از نوتیفیکیشنها وجود دارد؟
نویسنده مقاله امروز، آقای Andrew Wilshere به این سوال میپردازد و با بررسی معروفترین سرویسهای دنیا مانند Instagram، Facebook و یا Twitter به ما نشان میدهد که هر کسبوکار و هر سرویسی، حدی متفاوت از استفاده از نوتیفیکیشن را برای خود تعریف کردهاست.
سوال مهم این است که سرویس طراحی شده توسط شما در کجای این مرز قرار میگیرد؟
http://trydesignlab.com/blog/are-notifications-a-dark-pattern-ux-ui/
(زمان حدودی مطالعه، ۱۰ دقیقه)
پ. ن.
در این مقاله مفهومی به اسم Dark Patterns توضیح داده شده است که به معنای کلی برای گول زدن کاربر برای انجام کاری که تمایلی به آن ندارد است. نمونههای جالبی هم معرفی شدهاست.
#مفاهیم #چالش #اعلان #نوتیفیکیشن
@Dexign دیزاین
___
Designlab
Are Notifications A Dark Pattern?
Have you ever had a nightmare where you were literally drowning in little red notification badges? I did once, and it got me thinking: what actually are notifi…