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
دنیای چابک
دنیای چابک – ماست مالی کردن یا از دست ندادن بازار
مدیر:”آقا پس این کی تموم میشه؟” برنامه نویس:”این کار می بره، باید رو طراحیش کار کنم…” مدیر: “همینجوری خوبه، بده بدیم مش
Forwarded from فلسفه دیزاین
بوم سفیدی برای تمام دنیا:
داستان شیرین یک همکاری معجزهآسا
خارجیها هم مثل دروغ سیزده ما، مفهومی به اسم April's Fool دارن که در روز اول آوریل خیلی از سرویسها و سایتها عمل مشابه دروغ سیزده انجام میدن و بعضی از شرکتها هم از این فرصت و بهانه استفاده میکنن تا ایدههای هیجانانگیزشون رو به دنیا معرفی کنن.
امسال هم مثل سالهای گذشته شرکتهای بزرگ زیادی در این رسم شرکت کردن. یکی از بهترینهای ایدههای اجرا شده، ایده سایت Reddit بود.
سایت Reddit یک سایت بحث و گفتگو و همینطور خبری است. یکی از ویژگیهای بارز سایت پرطرفدار Reddit اینه که خیلی از کاربرانش به شکل ناشناس (Anonymous) در اون فعالیت دارند.
امسال Reddit به بهانه April's Fool، یک صفحه به اسم Place راهاندازی کرد که یک بوم سفید بود و هر کاربر میتونست یک پیکسل از این بوم سفید رو با یکی از ۱۶ رنگی که در اختیارش قرار داره رنگ کنه. هر کاربری هرچند باری که میخواست میتونست این کار رو انجام بده، فقط باید چند دقیقه بین هر بار رنگ کردن یک پیسکل صبر میکرد.
قبل از خوندن ادامه به این ایده فکر کنید و تصور کنید که ساختن یک شکل واحد در اون ممکنه ماهها طول بکشه یا اصلا آیا با این تعداد کاربری که ممکنه این صفحه رو ببینن و روی پیکسلهای همدیگه رو رنگ کنن، اصلا ساختن یک طرح مشخص امکانپذیره یا نه؟
نتیجه کار حتی برای خود سازندگان سایت Reddit هم حیرتآور بود.
جامعهای جهانی متشکل از ۱ میلیون کاربر شکل گرفت و شروع کردن به رنگ کردن این بوم سفید، مثل تمامی جوامع واقعی بشری، برخی به دنبال ساختن شکلی در کل بوم بودن و برخی فقط برای یه تیکه از بوم برنامهریزی کرده بودن، گروههای خرابکاری شکل گرفت که مدام کارهای بقیه رو خراب میکردن. گروههای هکری دست به هک کردن تایمر زدن تا بتونن خارج از نوبت بوم رو رنگ کنن و …
باور کردن این داستان حتی از باور کردن نتیجه کار سختتره. من شخصا هربار به این اتفاق و روندی که اتفاق افتاده فکر میکنم شگفتزده میشم.
چندتا مورد خیلی جالب درباره این ایده که میشه بهشون اشاره کرد اینه که: طرح آخر روز اول آوریل توسط یک موزه در هلند پرینت شده و نگهداری خواهد شد. گروهی از کاربران یک دکمه Start ویندوز ۹۵ رو در گوشه پایین سمت چپ صفحه ساختن و تا آخر حفظش کردن. شوخی که برخی کاربران با ساختن پنجره سوم توی نوار Start ویندوز ۹۵ و مخفی کردن اسمش زیر یه پنجره دیگه، انجام دادن.
باقی رازهای این طرح رو خودتون کشف کنید.
در مقاله امروز جز به جز این اتفاق از دید یک شاهد عینی توضیح داده شده. بخونید و مثل من لذتش رو ببرید.
https://digitalculturist.com/when-pixels-collide-reddit-place-and-the-creation-of-art-3f9c15cc3d82
(زمان حدودی مطالعه، ۱۵ دقیقه)
پ. ن.
انیمیشن گیف زیر نحوه شکلگیری طرح نهایی رو از ابتدا نشون میده.
#ایده #هنر
@Dexign دیزاین
___
داستان شیرین یک همکاری معجزهآسا
خارجیها هم مثل دروغ سیزده ما، مفهومی به اسم April's Fool دارن که در روز اول آوریل خیلی از سرویسها و سایتها عمل مشابه دروغ سیزده انجام میدن و بعضی از شرکتها هم از این فرصت و بهانه استفاده میکنن تا ایدههای هیجانانگیزشون رو به دنیا معرفی کنن.
امسال هم مثل سالهای گذشته شرکتهای بزرگ زیادی در این رسم شرکت کردن. یکی از بهترینهای ایدههای اجرا شده، ایده سایت Reddit بود.
سایت Reddit یک سایت بحث و گفتگو و همینطور خبری است. یکی از ویژگیهای بارز سایت پرطرفدار Reddit اینه که خیلی از کاربرانش به شکل ناشناس (Anonymous) در اون فعالیت دارند.
امسال Reddit به بهانه April's Fool، یک صفحه به اسم Place راهاندازی کرد که یک بوم سفید بود و هر کاربر میتونست یک پیکسل از این بوم سفید رو با یکی از ۱۶ رنگی که در اختیارش قرار داره رنگ کنه. هر کاربری هرچند باری که میخواست میتونست این کار رو انجام بده، فقط باید چند دقیقه بین هر بار رنگ کردن یک پیسکل صبر میکرد.
قبل از خوندن ادامه به این ایده فکر کنید و تصور کنید که ساختن یک شکل واحد در اون ممکنه ماهها طول بکشه یا اصلا آیا با این تعداد کاربری که ممکنه این صفحه رو ببینن و روی پیکسلهای همدیگه رو رنگ کنن، اصلا ساختن یک طرح مشخص امکانپذیره یا نه؟
نتیجه کار حتی برای خود سازندگان سایت Reddit هم حیرتآور بود.
جامعهای جهانی متشکل از ۱ میلیون کاربر شکل گرفت و شروع کردن به رنگ کردن این بوم سفید، مثل تمامی جوامع واقعی بشری، برخی به دنبال ساختن شکلی در کل بوم بودن و برخی فقط برای یه تیکه از بوم برنامهریزی کرده بودن، گروههای خرابکاری شکل گرفت که مدام کارهای بقیه رو خراب میکردن. گروههای هکری دست به هک کردن تایمر زدن تا بتونن خارج از نوبت بوم رو رنگ کنن و …
باور کردن این داستان حتی از باور کردن نتیجه کار سختتره. من شخصا هربار به این اتفاق و روندی که اتفاق افتاده فکر میکنم شگفتزده میشم.
چندتا مورد خیلی جالب درباره این ایده که میشه بهشون اشاره کرد اینه که: طرح آخر روز اول آوریل توسط یک موزه در هلند پرینت شده و نگهداری خواهد شد. گروهی از کاربران یک دکمه Start ویندوز ۹۵ رو در گوشه پایین سمت چپ صفحه ساختن و تا آخر حفظش کردن. شوخی که برخی کاربران با ساختن پنجره سوم توی نوار Start ویندوز ۹۵ و مخفی کردن اسمش زیر یه پنجره دیگه، انجام دادن.
باقی رازهای این طرح رو خودتون کشف کنید.
در مقاله امروز جز به جز این اتفاق از دید یک شاهد عینی توضیح داده شده. بخونید و مثل من لذتش رو ببرید.
https://digitalculturist.com/when-pixels-collide-reddit-place-and-the-creation-of-art-3f9c15cc3d82
(زمان حدودی مطالعه، ۱۵ دقیقه)
پ. ن.
انیمیشن گیف زیر نحوه شکلگیری طرح نهایی رو از ابتدا نشون میده.
#ایده #هنر
@Dexign دیزاین
___
Medium
When Pixels Collide
How a million strangers on the Internet turned a blank canvas into art
مفهوم Concurrent Programming و تفاوت آن با Parallel Programming همیشه یکی از مباحث چالش برانگیز برای برنامه نویسان بوده است. مفهوم اجرای همزمان یا Concurrent حتی قابل اجرا روی یک نخ یا یک cpu است. در حالی که اجرای موازی یا Parallel نیاز به چند نخ دارد. مقاله زیر به زیبایی و بسیار خلاصه این دو مدل برنامهنویسی را توضیح دادهاست. همچنین نحوه استفاده از امکانات .net core را برای پیادهسازی این مفاهیم را به همراه مثالهایی خوانا شرح دادهاست.
مفاهیم TPL, PLINQ, Async, Immutable Collection و مفاهیم دیگر در این مقاله با ذکر مثالهایی جالب شرح داده شدهاند.
http://www.dotnetcurry.com/dotnet/1360/concurrent-programming-dotnet-core
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/xoWQ30bbJFn
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مفاهیم TPL, PLINQ, Async, Immutable Collection و مفاهیم دیگر در این مقاله با ذکر مثالهایی جالب شرح داده شدهاند.
http://www.dotnetcurry.com/dotnet/1360/concurrent-programming-dotnet-core
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/xoWQ30bbJFn
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dotnetcurry
Concurrent Programming in .NET Core | DotNetCurry
Learn approaches to concurrent programming in .NET Core, as well as potential issues to be aware of.
Forwarded from Iran Agile
✅ آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟
معمولا در اوایل پیاده سازی اسکرام، نقش اسکرام مستر پررنگ تر است، او مجبور است جلسات را برگزار کند، مطمئن شود فرآیندها به درستی اجرا می شوند و ... .
اما در ادامه و با توجه به بلوغ تیم، آیا ما نیازی به اسکرام مستر داریم؟ آیا با حذف این نقش میتوانیم به حیات چابک خود ادامه بدهیم؟
👇👇👇👇👇
https://goo.gl/JYXqfx
@iranagile
معمولا در اوایل پیاده سازی اسکرام، نقش اسکرام مستر پررنگ تر است، او مجبور است جلسات را برگزار کند، مطمئن شود فرآیندها به درستی اجرا می شوند و ... .
اما در ادامه و با توجه به بلوغ تیم، آیا ما نیازی به اسکرام مستر داریم؟ آیا با حذف این نقش میتوانیم به حیات چابک خود ادامه بدهیم؟
👇👇👇👇👇
https://goo.gl/JYXqfx
@iranagile
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. تنظیم محیط برنامهنویسی Linux روی Windows 10
https://news.1rj.ru/str/SoftwarePhilosophy/767
۲. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی
https://news.1rj.ru/str/SoftwarePhilosophy/768
۳. دلایل ایجاد Gold Plating و راه حلهای آن (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/769
۴. بوم سفید سایت Reddit برای کاربران (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/770
https://news.1rj.ru/str/SoftwarePhilosophy/771
۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection
https://news.1rj.ru/str/SoftwarePhilosophy/772
۶. آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟ (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/773
ـــــــــــ
@SoftwarePhilosophy
۱. تنظیم محیط برنامهنویسی Linux روی Windows 10
https://news.1rj.ru/str/SoftwarePhilosophy/767
۲. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی
https://news.1rj.ru/str/SoftwarePhilosophy/768
۳. دلایل ایجاد Gold Plating و راه حلهای آن (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/769
۴. بوم سفید سایت Reddit برای کاربران (دیزاین)
https://news.1rj.ru/str/SoftwarePhilosophy/770
https://news.1rj.ru/str/SoftwarePhilosophy/771
۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection
https://news.1rj.ru/str/SoftwarePhilosophy/772
۶. آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟ (Iran Agile)
https://news.1rj.ru/str/SoftwarePhilosophy/773
ـــــــــــ
@SoftwarePhilosophy
حذف حجم زیادی از سطرها از دیتابیس با اجرای دستور DELETE میتواند بسیار پر هزینه و زمانبر باشد. برای بهبود عملکرد و سرعت عملیات حذف باید Foreign Key ها، Index ها را هم بررسی کرد. ولی پس از بررسی و بهبود توسط این عوامل، راه بعدی استفاده از Delete Chunks است. شکستن DELETE های بزرگ به تکههای کوچکتر میتواند کمک زیادی به بهبود سرعت کند.
مقاله زیر ضمن آموزش این روش، نتایج اجرای این روش را با روشهای دیگر مقایسه کردهاست.
https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/CcQz30bhNiQ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر ضمن آموزش این روش، نتایج اجرای این روش را با روشهای دیگر مقایسه کردهاست.
https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/CcQz30bhNiQ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
SQLPerformance.com
Break large delete operations into chunks
Aaron Bertrand (@AaronBertrand) discusses ways to optimize large delete operations, both to make them faster, and to minimize impact on the transaction log.
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
الگوی Async Retry Pattern یکی از الگوهایی است که در برنامهنویسی برنامههای نسل جدید بسیار مهم است. بسیاری دستگاهها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شدهاند این امکان را میدهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);
RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);
کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.
مقاله زیر ضمن تشریح این الگو، توضیح دادهاست که چطور میتوان با استفاده از async/await الگوی retry pattern را پیادهسازی کرد.
https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);
RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);
کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.
مقاله زیر ضمن تشریح این الگو، توضیح دادهاست که چطور میتوان با استفاده از async/await الگوی retry pattern را پیادهسازی کرد.
https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Alastair Crabtree
Implementing the retry pattern for async tasks in c#
This post is a follow on from Implementing a simple retry pattern in c#
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
Forwarded from فلسفه دیزاین
مروری بر معماری اطلاعات:
فوت کوزهگری دیزاین
از سفر برگشتم و امروز با یه مطلب هیجانانگیز همراهتون هستم.
بنا به تجربهای که شخصا داشتم، جدای از هر روندی که برای ارائه بهترین و با کیفیتترین دیزاین طی میشه، اگر مرحله معماری اطلاعات به درستی انجام نشه، کار نهایی عالی نخواهد بود.
در واقع یکی از پلههای نردبانِ خوب به عالی در دیزاین، معماری اطلاعاتست. این مرحله از دیزاین بسیار بسیار لذتبخشه چراکه مجبور هستید تمام بخشهای سرویسی که دیزاین میکنید رو کاملا زیر و رو کرده و درکش کنید.
بطور ساده، معماری اطلاعات شامل مواردی از قبیل: اطلاعاتی که در اپلیکیشن در جریان هست، اطلاعاتی که در هر بخش باید نمایش داده بشه و اعمالی که هر کاربر میتونه درباره این اطلاعات انجام بده، میشه.
مقاله امروز به زبان ساده توضیح میده که چطور میتونیم شروع کنیم به گنجوندن معمار اطلاعات در مراحل دیزاین یک سرویس و مثالهایی کاربردی از اپلیکیشن Spotify میزنه که به فهم بیشتر موضوع کمک شایان توجهی میکنه.
پیشنهاد میکنم که خوندن این مقاله رو مقدمهای قرار داده و تحقیقات مفصلتری درباره مقوله معماری اطلاعات در دیزاین انجام بدید. قطعا تغییراتی که در طرز تفکرتون و نتیجه نهایی دیزاینتون ایجاد میشه، لذت خواهید برد.
https://blog.prototypr.io/information-architecture-the-most-important-part-of-design-youre-probably-overlooking-20372ade4fc0
(زمان حدودی مطالعه، ۷ دقیقه)
#معماری_اطلاعات #تجربه_کاربری #مفاهیم
@Dexign دیزاین
___
فوت کوزهگری دیزاین
از سفر برگشتم و امروز با یه مطلب هیجانانگیز همراهتون هستم.
بنا به تجربهای که شخصا داشتم، جدای از هر روندی که برای ارائه بهترین و با کیفیتترین دیزاین طی میشه، اگر مرحله معماری اطلاعات به درستی انجام نشه، کار نهایی عالی نخواهد بود.
در واقع یکی از پلههای نردبانِ خوب به عالی در دیزاین، معماری اطلاعاتست. این مرحله از دیزاین بسیار بسیار لذتبخشه چراکه مجبور هستید تمام بخشهای سرویسی که دیزاین میکنید رو کاملا زیر و رو کرده و درکش کنید.
بطور ساده، معماری اطلاعات شامل مواردی از قبیل: اطلاعاتی که در اپلیکیشن در جریان هست، اطلاعاتی که در هر بخش باید نمایش داده بشه و اعمالی که هر کاربر میتونه درباره این اطلاعات انجام بده، میشه.
مقاله امروز به زبان ساده توضیح میده که چطور میتونیم شروع کنیم به گنجوندن معمار اطلاعات در مراحل دیزاین یک سرویس و مثالهایی کاربردی از اپلیکیشن Spotify میزنه که به فهم بیشتر موضوع کمک شایان توجهی میکنه.
پیشنهاد میکنم که خوندن این مقاله رو مقدمهای قرار داده و تحقیقات مفصلتری درباره مقوله معماری اطلاعات در دیزاین انجام بدید. قطعا تغییراتی که در طرز تفکرتون و نتیجه نهایی دیزاینتون ایجاد میشه، لذت خواهید برد.
https://blog.prototypr.io/information-architecture-the-most-important-part-of-design-youre-probably-overlooking-20372ade4fc0
(زمان حدودی مطالعه، ۷ دقیقه)
#معماری_اطلاعات #تجربه_کاربری #مفاهیم
@Dexign دیزاین
___
Medium
Information Architecture. The Most Important Part of Design You’re Probably Overlooking.
What Is Information Architecture?
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرمافزار را به خود جلب کردهاست. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکههای کوچکتر شکسته شود. در این تیمها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوریهای باقیمانده استفاده میشود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کردهاست.
http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Innolution
Blog: To Estimate or Not to Estimate – That is the Controversy | Innolution
Blog that discusses the controversy of whether estimates are useful on agile development projects.
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.
https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints
#مریم_داودی
لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a
کانال تلگرام:
@SoftwarePhilosophy
___
ui.dev
Why you don’t need device specific breakpoints
With the ever growing number of different mobile, tablet, laptops, monitors, televisions, watches — and whatever else will communicate information to you visually — it’s finally time to put to rest those device specific breakpoints.
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نوشتن کوئریهای DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://news.1rj.ru/str/SoftwarePhilosophy/775
۲. چگونه با استفاده از async/await الگوی retry pattern را پیادهسازی کنیم
#csharp #async #designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/777
۳. مروری بر معماری اطلاعات یا فوت کوزهگری دیزاین (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/778
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://news.1rj.ru/str/SoftwarePhilosophy/780
۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://news.1rj.ru/str/SoftwarePhilosophy/782
ـــــــــــ
@SoftwarePhilosophy
۱. نوشتن کوئریهای DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://news.1rj.ru/str/SoftwarePhilosophy/775
۲. چگونه با استفاده از async/await الگوی retry pattern را پیادهسازی کنیم
#csharp #async #designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/777
۳. مروری بر معماری اطلاعات یا فوت کوزهگری دیزاین (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/778
۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://news.1rj.ru/str/SoftwarePhilosophy/780
۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://news.1rj.ru/str/SoftwarePhilosophy/782
ـــــــــــ
@SoftwarePhilosophy
Forwarded from فلسفه دیزاین
سوالاتی که هر دیزاینر جدیدی باید از تیمش بپرسد
در اکثر جاها صحبت از سوالاتی هست که باید در مصاحبه از دیزاینر جدیدتون بپرسید. اما این بار ما میخواهیم از زاویه دیگری به موضوع نگاه کنیم. میخواهیم سوالاتی رو بررسی کنیم که هر دیزاینر جدیدی که عضو یک تیم شده، باید از اعضای تیمش بپرسه.
اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای Jason Cashdollar به تازگی به عضویت تیم دیزاین اپلیکیشن Facebook Lite در فیسبوک در اومده. اولین تسک Jason بازطراحی روند عضویت در این اپلیکیشن هست و هدفی که براش تعیین شد عبارت بود از «کاهش سردرگمی کاربرانی که میخواهند ثبتنام کنند.». Jason مراحلی که هر دیزاینری برای دیزاین طی میکنه رو رفت و در نهایت پروپوزالی رو برای تیمش ارسال کرد.
انتظار Jason این بود که تمام اعضای تیم با پیشنهاد اون به وجد بیان و هیجانزده بشن. ولی بعد از اینکه عکسالعمل تیم رو دید متوجه شد که به قول خودش «مسابقه اشتباهی رو برنده شده بود.» و چیزی که طراحی کرده بود کارایی لازم رو نداشت.
یک لحظه همینجا صبر کنید. حدس میزنید دلیل این موضوع چی بود؟
دلیل این بود که اطلاعات قبلی رو که لازم بود درباره پروژه بدونه، از تیم درخواست نکرده و مسیری اشتباهی رو برای بازطراحی این محصول پیش رفته بود.
بعد از این تجربه، Jason سوالاتی رو برای خودش تعیین کرد به همه اعضای تازه تیمها بده که از تیمشون بپرسن تا تجربه مشابهی نداشته باشن.
پیشنهاد میکنم داستان کامل و سوالاتی که پرسیدنشون رو پیشنهاد میده، از زبان خود Jason بخونید.
https://medium.com/facebook-design/questions-to-ask-as-a-new-designer-on-the-team-7e3ace0c787f
(زمان حدودی مطالعه، ۷ دقیقه)
پ. ن.
داشتن پایگاه دانش (knowledge base) همیشه به روند ملحق شدن اعضای جدید به تیم کمک میکنه. لازم نیست حتما از سیستمهای پیچیده استفاده کنید، ما ۸ ماهیست که یه نسخه کوچیکش رو در قالب یک Board روی Trello راهاندازی کردیم و بچههای تیم خودشون بروزرسانیش میکنند و کاملا کارمون رو راه میاندازه.
#تیم #طراحی_محصول
@Dexign دیزاین
___
در اکثر جاها صحبت از سوالاتی هست که باید در مصاحبه از دیزاینر جدیدتون بپرسید. اما این بار ما میخواهیم از زاویه دیگری به موضوع نگاه کنیم. میخواهیم سوالاتی رو بررسی کنیم که هر دیزاینر جدیدی که عضو یک تیم شده، باید از اعضای تیمش بپرسه.
اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای Jason Cashdollar به تازگی به عضویت تیم دیزاین اپلیکیشن Facebook Lite در فیسبوک در اومده. اولین تسک Jason بازطراحی روند عضویت در این اپلیکیشن هست و هدفی که براش تعیین شد عبارت بود از «کاهش سردرگمی کاربرانی که میخواهند ثبتنام کنند.». Jason مراحلی که هر دیزاینری برای دیزاین طی میکنه رو رفت و در نهایت پروپوزالی رو برای تیمش ارسال کرد.
انتظار Jason این بود که تمام اعضای تیم با پیشنهاد اون به وجد بیان و هیجانزده بشن. ولی بعد از اینکه عکسالعمل تیم رو دید متوجه شد که به قول خودش «مسابقه اشتباهی رو برنده شده بود.» و چیزی که طراحی کرده بود کارایی لازم رو نداشت.
یک لحظه همینجا صبر کنید. حدس میزنید دلیل این موضوع چی بود؟
دلیل این بود که اطلاعات قبلی رو که لازم بود درباره پروژه بدونه، از تیم درخواست نکرده و مسیری اشتباهی رو برای بازطراحی این محصول پیش رفته بود.
بعد از این تجربه، Jason سوالاتی رو برای خودش تعیین کرد به همه اعضای تازه تیمها بده که از تیمشون بپرسن تا تجربه مشابهی نداشته باشن.
پیشنهاد میکنم داستان کامل و سوالاتی که پرسیدنشون رو پیشنهاد میده، از زبان خود Jason بخونید.
https://medium.com/facebook-design/questions-to-ask-as-a-new-designer-on-the-team-7e3ace0c787f
(زمان حدودی مطالعه، ۷ دقیقه)
پ. ن.
داشتن پایگاه دانش (knowledge base) همیشه به روند ملحق شدن اعضای جدید به تیم کمک میکنه. لازم نیست حتما از سیستمهای پیچیده استفاده کنید، ما ۸ ماهیست که یه نسخه کوچیکش رو در قالب یک Board روی Trello راهاندازی کردیم و بچههای تیم خودشون بروزرسانیش میکنند و کاملا کارمون رو راه میاندازه.
#تیم #طراحی_محصول
@Dexign دیزاین
___
Medium
Questions to ask as a new designer on the team
Last summer I switched teams at Facebook. My first project seemed simple enough: redesign the sign up flow for Facebook Lite, an app for…
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
استفاده از Mapper ها در برنامهنویسی جدید بسیار مرسوم است. از طرفی بار Performance ی که این فریمورکها روی نرمافزارها میگذارند در مواردی محسوس است. بنابراین در برخی موارد که این تاثیر سرعت محسوس است، انتخاب یک Mapper خاص با قابلیت سرعتی مناسب باید به دقت انجام شود.
در مقاله زیر فریمورکهای معروف Mapper از لحاظ عملکرد و سرعت با یکدیگر مقایسه شدهاند.
http://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
در مقاله زیر فریمورکهای معروف Mapper از لحاظ عملکرد و سرعت با یکدیگر مقایسه شدهاند.
http://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر می رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
آیا پردازندهای که با آن کار میکنیم میتواند سریعتر پردازش کند؟
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای جایگزین بهتری وجود دارد که یکی از آنها actor model میباشد.
اکتور یک مدل مفهومی ارائه شده برای محاسبات همزمان میباشد که کتابخانههایی برای زبانهای برنامهنویسی مختلف بر اساس این مدل ارائه شدهاند . ایدهای که در این مدل وجود دارد بسیار مشابه تعاریفی است که در زبان شیگرایی با آن آشنایی داریم به این صورت که یک شی، یک پیغام را دریافت میکند و عملیاتی بر اساس پیغام دریافتی روی آن انجام میدهد. اما ویژگیهای اصلی این مدل که آن را متمایز میکند جدا بودن هر اکتور از هم میباشد که هیچگاه مموری را با هم به اشتراک نمیگذارند. هر اکتور شامل یک صندوق پستی است و اکتورها با ارسال پیغام به یکدیگر , با نگه داشتن پیغام ها در صندوق پستی , عملیات لازم را روی پیغامها به صورت یکی یکی انجام میدهند.
مقاله زیر به شرح کامل نحوه عملکرد اکتورها و چگونگی ارتباط آنها میپردازد.
http://www.brianstorti.com/the-actor-model
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
برای افزایش سرعت پردازش اطلاعات نیاز به اجرای همزمان کدها داریم و همینطور پریشانی توسعه دهندگان از غیرقابل ردیابی بودن برخی باگها نشان داده که شاید thread ها راه مناسبی نباشند، ولی مدلهای جایگزین بهتری وجود دارد که یکی از آنها actor model میباشد.
اکتور یک مدل مفهومی ارائه شده برای محاسبات همزمان میباشد که کتابخانههایی برای زبانهای برنامهنویسی مختلف بر اساس این مدل ارائه شدهاند . ایدهای که در این مدل وجود دارد بسیار مشابه تعاریفی است که در زبان شیگرایی با آن آشنایی داریم به این صورت که یک شی، یک پیغام را دریافت میکند و عملیاتی بر اساس پیغام دریافتی روی آن انجام میدهد. اما ویژگیهای اصلی این مدل که آن را متمایز میکند جدا بودن هر اکتور از هم میباشد که هیچگاه مموری را با هم به اشتراک نمیگذارند. هر اکتور شامل یک صندوق پستی است و اکتورها با ارسال پیغام به یکدیگر , با نگه داشتن پیغام ها در صندوق پستی , عملیات لازم را روی پیغامها به صورت یکی یکی انجام میدهند.
مقاله زیر به شرح کامل نحوه عملکرد اکتورها و چگونگی ارتباط آنها میپردازد.
http://www.brianstorti.com/the-actor-model
#محمدرضا_جلیلوند
لینکدین:
http://ir.linkedin.com/in/mohammad-reza-jalilvand-0a5572b1
کانال تلگرام:
@SoftwarePhilosophy
___
Brianstorti
The actor model in 10 minutes
Forwarded from فلسفه دیزاین
نمونههای جالب اینتراکشن (شماره ۱)
هر محصولی، هرچقدر هم که رابط کاربری زیبایی داشته باشه، برای القای حس و تجربه بهتر، به اینتراکشن (Interaction) احتیاج داره.
اینتراکشنها همون عکسالعملهای اغلب انیمیشنی هستند که اپلیکیشنها در پاسخ به اعمال کاربر (زدن روی یک دکمه، Swipe کردن و یا منتظر بارگذاری موندن و …) انجام میدن.
مثال خوبی که میشه از اینتراکشن در اپلیکیشنهای ایرانی زد اینه که در اپلیکیشن اسنپ وقتی منتظر قبول درخواست سفرتون از طرف یکی از رانندهها هستید، صفحه انتظاری میبینید که ماشینی در اون در حال حرکت هست. اگر روی ماشین بزنید، بوق میزنه. از بازخوردهایی که از این ایده ساده ولی جذاب و خلاقانه از افراد مختلف گرفتم به عینه دیدم که باعث شده کاربرها حس بسیار بهتری نسبت به محصول در مقایسه با نمونههای مشابهش داشته باشند.
برای اینکه بتونید بهتر و با ایدههای جالبتری اینتراکشنهای محصولتون رو طراحی کنید، چند وقت یک بار نمونههای این شکلی در کانال ارسال میکنم که دیدنشون باعث جرقه ایده در ذهن میشه.
توجه کنید که صفحه مقاله امروز به خاطر وجود انیمیشنهای gif که در اون وجود داره، کمی سنگین هست ممکنه نمایشش کند باشه.
https://medium.muz.li/ui-interactions-of-the-week-72-65ea29a45c49
(زمان حدودی مطالعه، ۱۰ دقیقه)
#انیمیشن #طراحی_محصول #اینتراکشن #تجربه_کاربری
@Dexign دیزاین
___
هر محصولی، هرچقدر هم که رابط کاربری زیبایی داشته باشه، برای القای حس و تجربه بهتر، به اینتراکشن (Interaction) احتیاج داره.
اینتراکشنها همون عکسالعملهای اغلب انیمیشنی هستند که اپلیکیشنها در پاسخ به اعمال کاربر (زدن روی یک دکمه، Swipe کردن و یا منتظر بارگذاری موندن و …) انجام میدن.
مثال خوبی که میشه از اینتراکشن در اپلیکیشنهای ایرانی زد اینه که در اپلیکیشن اسنپ وقتی منتظر قبول درخواست سفرتون از طرف یکی از رانندهها هستید، صفحه انتظاری میبینید که ماشینی در اون در حال حرکت هست. اگر روی ماشین بزنید، بوق میزنه. از بازخوردهایی که از این ایده ساده ولی جذاب و خلاقانه از افراد مختلف گرفتم به عینه دیدم که باعث شده کاربرها حس بسیار بهتری نسبت به محصول در مقایسه با نمونههای مشابهش داشته باشند.
برای اینکه بتونید بهتر و با ایدههای جالبتری اینتراکشنهای محصولتون رو طراحی کنید، چند وقت یک بار نمونههای این شکلی در کانال ارسال میکنم که دیدنشون باعث جرقه ایده در ذهن میشه.
توجه کنید که صفحه مقاله امروز به خاطر وجود انیمیشنهای gif که در اون وجود داره، کمی سنگین هست ممکنه نمایشش کند باشه.
https://medium.muz.li/ui-interactions-of-the-week-72-65ea29a45c49
(زمان حدودی مطالعه، ۱۰ دقیقه)
#انیمیشن #طراحی_محصول #اینتراکشن #تجربه_کاربری
@Dexign دیزاین
___
Medium
UI Interactions of the week #72
via Muzli design inspiration