🖌 بالاخره SQL Server 2022 اومد (البته الان حالت Private Preview است)

✅1- SQL Database ledger with blockchain

این گزینه نقش امنیتی دارد. دیتایی که می‌خواهید را می‌توانید در قالب Blockchange ذخیره سازی کنید. در نتیجه این ساختار Blockchange ای که به داده‌هایتان و نحوه ذخیره سازی آن‌ها می‌دهید، داده‌ای به خودی خود حذف نمی‌شود و کسی نمی‌تواند آن را تغییر دهد...

✅2- Azure failover

شما می‌توانید بین دیتابیس‌های on-premises و دیتابیس Azure و ... failover کنید. حتی می‌توانید به عنوان مثال از روی دیتابیس Azure بک آپ بگیرید ...

✅3 - Intelligent Query Processing for a parameterized query (IQP)

این امکان را می‌دهد تا برای کوئری‌ها بر اساس پارامترهای یک کوئری، پلن‌های متعدد و مختلفی داشت که باعث بهبود پرفورمنس می‌شود.

یکی از معضل های SQL بحث ضعف پرفرمنسی بود که در Parameter sniffing وجود داشت. در این ورژن با Parameter sniffing خداحافظی می‌کنیم :)


✅4 - Azure Synapse link

این فیچر افراد ETL کار یا افرادی که با BI کار می‌کنند را بسیار خوش حال خواهد کرد :)
به واسطه این ویژگی شما می‌توانید داده‌ها را بدون استفاده از ETL از سیستم‌های OLTP, RealTime و ... به سیستم‌های Warehouse ببرید.

یعنی بدون تغییرات در کد و به صورت RealTime می‌توانید تغییرات را Detect کنید و انتقال دهید.

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

نکته: همانطور که گفتیم این نسخه Private Preview است. یعنی باید درخواست بدید و اگه موافقت شد می‌تونید از این نسخه استفاده کنید.

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (لینکدین)

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

________

کامپوننت‌بندی در صفحات وب

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

اما نگرانی که عموما وجود دارد این است که انتقال داده از کامپوننت فرزند به کامپوننت‌های فرزند به خودی خود پیچیدگی به کد اضافه می‌کنند. به طوری که عموما تا دو یا نهایتا سه لایه در یک کامپوننت منطقی بنظر می‌رسد.
اما در Blazor با وجود Cascading values و Attribute Splatting این نگرانی رفع شده و به راحتی می‌توان از کامپوننت‌ها به صورت تودرتو استفاده کرد.

این ویدیو خیلی خلاصه و خوب این مسئله رو تشریح می‌کنه:

https://www.youtube.com/watch?v=IgJ8zN9Yc6w

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#مریم_داودی (لینکدین)

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

_______

سند نیازمندی‌های محصول (PRD)

برای دهه‌ها، سند نیازمندی‌های محصول (PRD) مهمترین سندی بود که مدیران محصول در فرآیند تولید محصولات ایجاد می‌کردند. در این سند، تمام آن چیزهایی که برای ریلیز یک محصول خاص لازم است، با دقت فهرست شده و کل فرآیند ریلیز محصول بر اساس آن انجام می‌شود. همچنین از آن به عنوان سندی راهنما در روند ریلیزهای بعدی محصول استفاده می‌گردد.

این نوع سندها در فرآیند توسعه محصولات مورد استفاده قرار می‌گیرند تا تیم‌های توسعه و تست از طریق مراجعه به آنها بتواند از قابلیت‌هایی که محصول باید در هنگام ریلیز داشته باشد اطلاع پیدا نمایند. عمده کاربری این قبیل سندها معمولاً در متدهای توسعه محصول آبشاری می‌باشد که در آنها سه مرحله تعریف، دیزاین و تحویل محصول به طور متوالی اتفاق می‌افتد. اما گاهی ممکن است از این سندها در محیط Agile نیز استفاده شود.

از مزایای اصلی استفاده از سند نیازمندی‌های محصول (PRD) می‌توان به مواردی همچون درک مشترک از نیازهای محصول، صرفه‌جویی در زمان، جلوگیری از سوتفاهم و کاهش ریسک در پروژه اشاره کرد.

در نوشتن سند نیازمندی‌های محصول، معمولا در گام نخست یک طرح کلی از آنچه باید در PRD گنجانده شود با توجه به موارد ذیل تدوین می‌شود:

- هدف از ساخت محصول
- امکانات محصول
- جریان تجربه کاربری UX Flow و یادداشت‌های طراحی
- نیازهای سیستم و محیط
- پیش‌فرض‌ها، محدودیت‌ها و وابستگی‌ها


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

http://bit.ly/dxgn771

(زمان مورد نیاز برای مطالعه: ۷ دقیقه)

نویسنده: نیما‌ حکیم‌رابط

#سندنیازمندی‌های‌محصول #مدیریت‌محصول #متدآبشاری

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

______

چطور بلاک‌چین رو برای مادربزرگ‌هامون توضیح بدیم!؟

امروز قرار هست یه ورک‌شاپ داخلی برای بچه‌های Melk Radar (ملک رادار) داشته باشم در مورد بلاک‌چین (بیشتر با دید بیزنسی). این ورک‌شاپ آنلاینه و روی تیمز برگزار می‌شه.

اگه براتون جالبه خوشحال می‌شیم به ما اضافه شین☺️
این ارائه به زبان ساده بیان میشه،
اینقدر ساده که می‌تونید برای مادربزرگتون هم تعریف کنید! 👵

امروز (یکشنبه ۲۸ آذر) ساعت ۶ تا ۸
لینک ورک‌شاپ ساعت ۶ تو این گروه تلگرامی فرستاده می‌شه:
https://news.1rj.ru/str/+F_BVG6HYLx5mNTNi

چطور بلاک‌چین رو برای مادربزرگمون توضیح بدیم!؟
(یک ورک‌شاپ داخلی برای بچه‌های MelkRadar در مورد بلاک‌چین بیشتر با دید بیزنسی)

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

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

لینک ویدئوی این ورک‌شاپ:
https://www.youtube.com/watch?v=BlOKBEpxnO8


#مهران_داودی (لینکدین - بلاگ)

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

امکانات LINQ در NET 6.

✅ ۱- امکان مشخص کردن مقدار پیش‌فرض در OrDefault*

var item1 = list1.FirstOrDefault(i => i == 4, -1);
// -1

var item2 = list2.SingleOrDefault(i => i == "Item2", "Not found");
// Not found

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۲- متدهای جدید با مدل By*:

- MinBy
- MaxBy
- DistinctBy
- ExceptBy
- IntersectBy
- UnionBy

List<Product> products = new()
{
    new() { Name = "Product1", Price = 100 },
    new() { Name = "Product2", Price = 5 },
    new() { Name = "Product3", Price = 50 },
};

Product theCheapestProduct = products.MinBy(x => x.Price);
Product theMostExpensiveProduct = products.MaxBy(x => x.Price);
Console.WriteLine(theCheapestProduct);
// Output: Product { Name = Product2, Price = 5 }
Console.WriteLine(theMostExpensiveProduct);
// Output: Product { Name = Product1, Price = 100 }
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۳- متد کاربردی Chunk :

IEnumerable<int> numbers = Enumerable.Range(1, 505);
IEnumerable<int[]> chunks = numbers.Chunk(100);

foreach (int[] chunk in chunks)
{
    Console.WriteLine($"{chunk.First()}...{chunk.Last()}");
}

//  Output:
//  1...100
//  101...200
//  201...300
//  301...400
//  401...500
//  501...505
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۴- تابع Zip

int[] numbers = { 1, 2, 3, 4, };
string[] months = { "Jan", "Feb", "Mar" };
string[] seasons = { "Winter", "Winter", "Spring" };

var test = numbers.Zip(months).Zip(seasons);

foreach ((int, string, string) zipped in numbers.Zip(months, seasons))
{
    Console.WriteLine($"{zipped.Item1} {zipped.Item2} {zipped.Item3}");
}
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۵- پشتیبانی از Index در تابع ElementAt :

IEnumerable<int> numbers = new int[] { 1, 2, 3, 4, 5 };
int last = numbers.ElementAt(^0);
Console.WriteLine(last); // 5
➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۶- پشتیبانی از Range در تابع Take :

var taken1 = numbers.Take(2..4);

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

✅۷- جلوگیری از شمارش تایپ‌های غیر Enumerable:

numbers.TryGetNonEnumeratedCount(out int count)

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

https://raygun.com/blog/linq-net-6-improvements/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (لینکدین)

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

________

فونت‌هایی از جنس تصویر
درباره فونت آیکن بیشتر بدانیم

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

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

ما به عنوان یک طراح برای نمایش بهتر مفاهیم و در برخی موارد برای بخشیدن جلوه بیشتر به طرح‌هایمان از آیکن‌ها استفاده می‌کنیم. این آیکن‌ها بسته به نظر طراح به صورت SVG و گاهی PNG در طرح‌ها قرار می‌گیرد و اشکال متفاوتی دارد. حالا تصور کنید که این آیکن‌ها به‌جای یک تصویر مجزا به فونت تبدیل شوند و بتوان به آسانی تایپ کردن به‌ کار برد یا ابعاد و اندازه‌هایشان را تغییر داد، این دقیقا کاری است که با تبدیل آیکن‌ها به فونت آیکن (Font icon) امکان‌پذیر می‌شود.

فونت‌ها معمولا از حروف و اعداد تشکیل می‌شوند و به ما این امکان را می‌دهند تا با استفاده از آن‌ها متن مورد نظر خود را بنویسیم. فونت آیکن‌ها فونت‌هایی هستند که به‌جای حروف و اعداد از تصاویر تشکیل شده‌اند، اندازه و رنگ آن‌ها قابل تغییر است و امکان اصلاح آن با استفاده از CSS وجود دارد.

استفاده از فونت آیکن‌برای توسعه دهندگان از آیکن‌های عادی بسیار راحت‌تر است چون همه این تغییرات با CSS انجام می‌شود و دیگر نیازی نیست که برای هر آیکن تصویر منحصر به فردی ایجاد شود و این مساله در کم‌کردن حجم وب‌سایت و کدها تاثیر زیادی دارد.

با اینکه ساخت فونت آیکن‌ها چندان کار پیچیده‌ای نیست، اما لازم نیست که خودتان آن‌ها را ایجاد کنید چرا که آن‌ها در سراسر اینترنت وجود دارند. محبوب‌ترین و شناخته شده‌ترین کتابخانه فونت آیکن Font Awesome است. برای بیش از 100 میلیون وب‌سایت استفاده می شود و شامل مجموعه ای قدرتمند از انواع آیکن‌هاست که با تمام ابزارهای محبوب کار می‌کند.

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

http://bit.ly/dxgn774

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

نویسنده: فیروزه ایمانی

#طراحی #رابط_کاربری #آیکن #فونت_آیکن

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

_____

آیکون‌های رایگان برای استفاده در محصول

اگر به دنبال آیکون‌های متنوعی می‌گردید که رایگان باشه، علاوه بر fontawesome، useiconic رو پیشنهاد می‌کنم.

https://useiconic.com/


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#مریم_داودی (لینکدین)

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

_______

استفاده از کامپوننت‌های تودرتو در Blazor

یکی عادت‌های خوب در پیاده‌سازی صفحات وب‌سایت،‌ کامپوننت‌بندی مناسب صفحات است.
به این معنی که هر پیج شامل یک کامپوننت اصلی و چندین کامپوننت (حاوی قسمت‌های اصلی و مجزای صفحه) باشد.

این معماری به خوانایی کد کمک کرده و با بزرگ شدن پروژه، نگهداری آن را راحت‌تر می‌کند.

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

اما در Blazor با وجود Cascading values و Attribute Splatting این نگرانی رفع شده و به راحتی می‌توان از کامپوننت‌ها به صورت تودرتو استفاده کرد.

این ویدیو خیلی خلاصه و خوب این مسئله را تشریح می‌کند:

https://www.youtube.com/watch?v=IgJ8zN9Yc6w

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#مریم_داودی (لینکدین)

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

_______

سخنرانی مهران داودی در کنفرانس «NET Conf Philippines»
با موضوع «معماری نرم‌افزار از طریق مفهوم Space»

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

🎈 این کنفرانس پنجشنبه ۲۳ دی (فردا) از ساعت ۱۴:۳۰ به صورت آنلاین برگزار می‌شود. لینک رویداد:
https://www.meetup.com/phinug/events/281400629/

🎥 همچنین کنفرانس به صورت آنلاین از طریق لینک یوتیوب زیر استریم می‌شود:
https://www.youtube.com/watch?v=zGvCiC6U32U



کانال فلسفه نرم‌افزار: @SoftwarePhilosophy

لینک لایو سخنرانی همین الان:
https://www.youtube.com/watch?v=zGvCiC6U32U

تصمیم‌گیری و تفکر به روش مرتبه‌ دوم

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

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

نحوه استفاده تفکر مرتبه دوم
استفاده از تفکر مرتبه دوم می‌تواند یک تمرین کاملا ذهنی باشد یا می توانید آن را روی کاغذ بنویسید.

تصمیمی که باید بگیرید را مجسم کنید. با بررسی فوری‌ترین تأثیرات این تصمیم‌گیری شروع کنید - مرتبه اول

سپس برای هر یک از تأثیرات از خود بپرسید: «خب بعدش چی؟» به این ترتیب شما مرتبه دوم پیامدهای این تصمیم را بررسی می‌کنید. می‌توانید این کار را تا هر اندازه که نیاز می‌بینید در مراتب بعدی نیز تکرار کنید.

از سوی دیگر، در مورد تصمیمتان در زمان‌های مختلف فکر کنید. از خود بپرسید:

۰ این تصمیم در ۱۰ دقیقه آینده چه تأثیری خواهد داشت؟
۰ ۱۰ ماه دیگر نتیجه چیست؟
۰ عاقبت در ۱۰ سال آینده چگونه خواهد بود؟

به این ترتیب می‌توانید به عواقب کوتاه‌مدت، میان‌مدت و بلند‌مدت تصمیم خود فکر کنید.

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

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

اثرات فوری آن ممکن است به داشتن یک باغ، فضای بیشتر برای خانواده‌ی شما، و همچنین ۱ ساعت رانندگی تا محل کار شما باشد.

اکنون به پیامدهای مرتبه‌ی بالاتر آن نگاه می‌کنیم:

۰ داشتن یک باغ ← قادر به تولید محصولات خود هستید ← از سبزیجات و گیاهان تازه استفاده می‌کنید
۰ فضای بیشتری برای خانواده ← اتاق‌های بیشتری برای تمیز کردن ← استرس بیشتر از یک خانه نامرتب
۰ یک ساعت رانندگی برای رسیدن به محل کار ← نیاز به خرید اتوموبیل ← گذراندن دو ساعت از هر روز در اتومبیل

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

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

http://bit.ly/dxgn777

(زمان حدودی مطالعه‌‌ی مقاله‌: ۴ دقیقه)

نویسنده: حسین میرزاده

#تصمیم_گیری #تفکر #مرتبه_دوم #عواقب #دوراندیشی

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

______

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

1. Everything in one module
2. One module per component(SCAM)
3. One module per feature/view (Lazy Load)

استراتژی اول یعنی «همه چیز در یک ماژول» به این صورت که تمام کامپوننت‌هارا به صورت فله‌ای داخل یک ماژول ایجاد کنیم.

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

و استراتژی سوم که احتمالا مرسوم‌ترین استراتژی است بر اساس فیچرهایی که داریم، می‌بایست ماژول‌هایی داشته باشیم که شامل چند کامپوننت مرتبط به هم هستند و نیز یک ماژول مشترک برای فیچر‌های مشترک بین کامپوننت‌ها.

برای اطلاعات بیشتر در مورد ابعاد مثبت و منفی هر کدام از این استراتژی‌ها می‌توانید به لینک زیر سر بزنید.

https://dev.to/this-is-angular/angular-modules-best-practices-2021-3lo5

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حسن_یوسفی (لینکدین)

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

________

مفهوم Async Enumerable، جادوی خفته!

همه می‌دانیم بعد از معرفی شدن مفهوم async/await انقلابی در مدل‌های برنامه‌نویسی و زبان‌های برنامه‌نویسی ایجاد شد. به دنبال C#، زبان‌های دیگر نیز شروع به اضافه کردن این امکان کردند و کتابخانه‌های نوشته شده به سرعت شروع به پشتیبانی از این امکان کردند.
از لحاظ فلسفی این سبک برنامه‌نویسی امکانی را ایجاد می‌کند تا بتوانیم برنامه‌های asynchronous بنویسیم بدون اینکه لازم باشد سبک کدنویسی و مایندست قبلی تغییر زیادی کند.

فرض کنید متد DoTasks را می‌خواهیم بنویسیم. بیاید مایندست‌های مختلف را با هم بررسی کنیم.

مایندست synchronous:

void DoTasks()
{
  DoTaskA();
  DoTaskB();
}

در این روش کسی که DoTasks را فراخوانی می‌کند باید منتظر تمام شدن کارش بماند تا بتواند کارهای بعدی خود را انجام دهد.


مایندست asynchronous:

Task DoTasks()
{
  return Task.Run(()=>DoTaskA())
      .ContinueWith((t)=>DoTaskB());
}

در این روش کسی که DoTasks را فراخونی می‌کند می‌تواند انتخاب کند که منتظر اتمام کار DoTasks بماند یا به کارهای خود ادامه دهد. ولی همانطور که می‌بینید سبک کدنویسی پیچیده‌تر شده‌است.


کد asynchronous با مایندست synchronous:

async Task DoTasks()
{
  await DoTaskA();
  await DoTaskB();
}

در این روش نیز کسی که DoTasks را فراخونی می‌کند می‌تواند انتخاب کند که منتظر اتمام کار DoTasks بماند یا به کارهای خود ادامه دهد. ولی سبک کد نویسی تغییر زیادی نکرده و به خاطر اینکه شبیه مدل synchronous است بسیار قابل فهم‌تر است.

و اما از نسخه C# 8.0 امکانی به نام Async Enumerable به این زبان اضافه شده که از نظر من امکان بسیار هیجان انگیزی است و می‌تواند باعث تغییرات بسیار جذابی در مدل‌های برنامه‌نویسی async ایجاد کند و کمک کند کدهای بسیار پیچیده با سادگی بیشتری پیاده شوند.

این فیچر با ترکیب زیبایی از مفاهیم yield و async/await پیاده‌سازی شده و امکان نوشتن کدی مانند زیر را فراهم کرده:

await foreach (var item in list) { }

به نظر من در آینده کتابخانه‌های زیادی از این امکان پشتیبانی خواهند کرد و کار کردن با آنها بسیار جذاب‌تر می‌شود.

برای فهم کامل این روش پیشنهاد می‌کنم مقاله جذاب Stepeh Toub مطالعه کنید.


#مهران_داودی (لینکدین - بلاگ)


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

________

🎛️ اسکرام برای پروژه‌های سخت‌افزاری

در این پادکست در مورد استفاده از نسخه اصلاح شده اسکرام برای پروژه های سخت افزاری صحبت شده است. بسیاری از تیم‌ها سعی کرده‌اند از اسکرام برای توسعه محصولات سخت‌افزاری استفاده کنند، اما همیشه موفق نبوده‌اند. با گسترش محصولات سخت‌افزاری این موضوع نیز مهم شده است. در این پادکست ما نه یک بلکه دو مهمان داریم که به ما در این خصوص همین مشکل کمک خواهند کرد - دوریان سیمپسون و گری هینکل. آنها فکر می‌کنند که پاسخی برای استفاده اصول چابک در پروژه های سخت افزاری دارند و آن را چارچوب اصلاح شده برای توسعه سخت افزار (MAHD) می‌نامند.
👇👇👇

https://productmasterynow.com/blog/366-this-is-modified-agile-for-hardware-development-with-dorian-simpson-and-gary-hinkle/

@iranagile

بازی سرعت و کیفیت هنگام ساخت محصول

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

چگونه از آن استفاده کنیم؟
تصمیم شما برای اولویت‌بندی سرعت یا کیفیت، باید براساس اعتماد شما به موارد زیر باشد:

۱. اهمیت مسئله‌ای که مشغول حل آن هستید
۲. صحت و درستی راه‌‌حلِ مسئله

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

سه نتیجه اساسی وجود دارد:

۰ آیا اعتماد شما در اهمیت مسئله کم است؟ ← بر سرعت تمرکز کنید.
۰ آیا اعتماد شما به مشکل و راه‌حل آن بالاست؟ ← روی کیفیت تمرکز کنید.
۰ آیا اعتماد شما در اهمیت مسئله زیاد است ولی در راه‌‌حل آن کم است؟ ← هم سرعت و هم کیفیت را متعادل کنید.

البته که اعتماد مثل یک کلید عمل نمی‌کند، ولی می‌تواند به عنوان یک مقیاس کار کند. که در آخر نتیجه، بسیار دقیق و ظریف‌تر خواهد بود.

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

http://bit.ly/dxgn781

(زمان حدودی مطالعه‌‌ی کامل مقاله‌: ۱۴ دقیقه)

نویسنده: حسین میرزاده

#تصمیم_گیری #مدیریت_محصول #سرعت #کیفیت #توسعه_محصول

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

_____

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

https://www.scrum.org/resources/blog/how-introduce-work-progress-wip-limits-team-real-life-example

@iranagile

کتاب آنلاین تکنیک های مدرن یادگیری عمیق در پردازش زبان طبیعی

این #کتاب آنلاین مباحث زیادی را پوشش داده که برای علاقه مندان و حوزه #NLP مطالعه کتاب پیشنهاد می شود.
در تصویر بالا فهرست مطالب پوشش داده شده در این کتاب را مشاهده می کنید.
لینک کتاب: nlpoverview.com

@silicon_brain

مالک محصول کیست و چه کاری انجام می دهد؟

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

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

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

اینجاست که اهمیت نقش مالک محصول مشخص می‌‌شود. مالک محصول نقشی است که در اسکرام (scrum) معنی پیدا می‌کند و با مدیر محصول (Product Manager) متفاوت است. مالک محصول کمک می‌کند تا مسیر طراحی و بازطراحی محصول در جهت مقصد مورد نظر قرار گیرد. برخی از نکات اصلی در مورد نقش مالک محصول عبارتند از:

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

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

مالک محصول باید توانایی این را داشته باشد که با اقتدار در مورد هر یک از ویژگی‌های محصول، ارزشی که محصول ارائه می‌دهد و قوانین کسب‌و‌کار آن صحبت کند. همچنین نیاز است که درک گسترده‌ای از فناوری و فرصت‌ها یا چالش‌هایی که برای محصول ایجاد می‌کند داشته باشد.

برخی از کارهای مالک محصول عبارتند از:
- همدلی با مشتری
- تعیین چشم انداز و هدف برای تیم
- تعیین اولویت‌ها
- مدیریت ذینفعان
- برنامه ریزی برای نقشه راه

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

http://bit.ly/dxgn786

زمان حدودی مطالعه: ۷ دقیقه

نویسنده: فیروزه ایمانی

#طراحی_محصول #رابط_کاربری #مالک_محصول #اسکرام

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

______

بالاخره golang هم generic دار شد!

طبق این پروپوزال، امکان استفاده از generic به نسخه Go 1.18 اضافه می‌شود و در سال 2022 منتشر خواهد شد. اما نکته جالب در مورد تغییر این است بر خلاف بیشتر زبان‌ها که مفهوم جنریک با
Foo<T>
نماش داده می‌شود، در Go این مفهوم به صورت
Foo[T]

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

نکته جالب‌تر این است که این چالش هنگامی که Generic به زبان C# در نسخه 2.0 هم اضافه شد وجود داشت و باعث ایجاد یک Breaking Change از نسخه 1.0 به نسخه 2.0 شد. در این پست سعی می‌کنم این مشکل را با یک مثال از توییتی که Eric Lippert در این مورد زده توضیح بدم.

عبارت زیر را در نظر بگیرید:
A(B<C,D>E())

این عبارت در نسخه 1.0 و در نسخه 2.0 به دو طریق مختلف ترجمه می‌شود. که در کد زیر سعی کردم با فاصله‌گذاری‌های متفاوت آن را نشان دهم.

// C# 1.0
A( B<C , D>E() )

// C# 2.0
A( B<C,D> E() )

همانطور که می‌بینید در نسخه 1.0، فراخوانی متد A با دو پارامتر ورودی انجام شده و علامت < و > به عنوان علامت‌های کوچکتری و بزرگتری تفسیر شده‌اند، اما در نسخه 2.0 این عبارت فراخوانی متد A با یک ورودی جنریک است.

نکته جالب دیگر این است که generics به عنوان یک ویژگی بسیار مهم، تقریبا در سال 2002 به C# اضافه شد و پس از ۲۰ سال قرار است به زبان Go اضافه شود.

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

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

#مهران_داودی (لینکدین - بلاگ)


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

________

مدل انتخاب سخت؛
چه نوع تصمیمی می‌گیرم؟

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

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

۰ چقدر تأثیرگذار است؟
۰ مقایسه‌ی گزینه‌هایی که وجود دارد چقدر آسان است؟

چهار نوع تصمیم وجود دارد که می‌توانید بگیرید. این مدل، آن‌ها را بر اساس این دو عامل تقسیم می‌کند:

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

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

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

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

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

مطلب بالا برگرفته شده از لینک زیر است، می‌توانید در این لینک اسکرول کنید و مدل‌های ذهنی دیگری که برای دیزاینر‌ها مفید است را نیز مطالعه کنید.

http://bit.ly/dxgn787

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

نویسنده: حسین میرزاده

#تصمیم_گیری #مدل_انتخاب_سخت #تصمیم

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

______