سخنرانی مهران داودی در کنفرانس «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 فلسفه دیزاین

______

لطفا (اگه می‌تونید) از Span استفاده کنید!

یکی از متداول‌ترین کدهایی که نوشته می‌شه زمانیست که می‌خواهیم کاری را با تایپ immutable انجام دهیم.

مثلا زمانی که می‌خواهیم قسمتی از یک string را داخل متغیری بریزیم.

همانطور که می‌دانید این کار باعث می‌شود محلی از حافظه Heap اشغال شود.

[سمت راست تصویر]

روش بهتر به جای استفاده از یک متغیر از نوع string استفاده از یک متغییر از نوع Span است، چرا که در این حالت به خاطر استفاده از ref struct به جای استفاده از Heap از Stack استفاده می‌شود.

[سمت چپ تصویر]

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۱: توجه کنید که در اینجا اولین مقداری که داخل تایپی از نوع Span یا مشتقاتش (ReadOnlySpan و ...) می‌ریزید مثل قبل داخل Heap قرار دارند. اما از آن به بعد هر بلایی که سر اون متغیر بیاورید توی Stack ذخیره می‌شود.

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۲: استفاده از این تکنیک یکی از دلایلی ست که باعث افزایش سرعت و کاهش memory allocation در Kestrel شده است.

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۳: دلیل متن داخل پرانتر عنوان این پست (اگه می‌تونید) این است که از این تکنیک همه جا نمی‌شود استفاده کرد. مثلا در Class ها نمی‌توان متغیری از این نوع تعریف کرد. یا هنگام Boxing. یا در ساختار های await و yeild و ...

یک مثال از نحوه تعریف یک متغییر از این نوع:

public DateTime Span()
{
     ReadOnlySpan<char> dateSpan = "01 05 1991";
     var day = dateSpan.Slice(0, 2);
     var month = dateSpan.Slice(3, 2);
     var year = dateSpan.Slice(6);
     return new DateTime(int.Parse(year), 
                         int.Parse(month), 
                         int.Parse(day));
}

➖➖➖➖➖➖➖➖➖➖➖

✅ نتیجه: استفاده کردن از این امکان در صورتی که میسر باشد باعث افزایش سرعت و اختصاص بهینه حافظه می‌شود.

➖➖➖➖➖➖➖➖➖➖➖

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

نسخه ویدیویی همین پست

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

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

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

________

چگونه هوش مصنوعی بر طراحی UX تاثیر می‌گذارد؟

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

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

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

تقویت فرآیندهای UX از طریق هوش مصنوعی
دلیل اصلی استفاده از هوش مصنوعی کاهش نیاز به توجه انسان است. در زمینه طراحی UX، هوش مصنوعی یا یادگیری ماشین، اکنون می‌تواند فرآیندهای UX از جمله تجزیه و تحلیل داده‌ها، وایرفریمینگ و تست A/B را تقویت کند.

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

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

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

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

https://bit.ly/dxgn907

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

نویسنده: نیلوفر موجودی

#هوش_مصنوعی #طراحی_تجربه_کاربری

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

_______

کامپایل در انگولار

در انگولار دو نوع کامپایل وجود دارد:

• JIT (Just In Time)
• AOT (Ahead Of Time)

اگر بخواهیم تفاوت این دو نوع کامپایل را در یک جمله خلاصه کنیم، کامپایل از نوع JIT کد شما را در زمان اجرا در مرورگر کامپایل می‌کند ولی AOT کد شما را در زمان build کامپایل می‌کند.

اگر بخواهیم دقیقتر در مورد تفاوت دو مورد تو ضیح دهیم:

در کامپایل JIT دائما قسمتی از کد که نیاز است در لحظه اجرا شود، کامپایل می‌شود، دقیقا قبل از اینکه برنامه شما در مرورگر نمایش داده شود.

در کامپایل AOT کل کد شما در زمان build شدن کامپایل می‌شود و هر قسمتی از کد که برای انگولار قابل شناسایی ولی برای مرورگر نیست مثل directives یا pipe ها به فایل‌های جاوااسکریپت تبدیل می‌شوند و برای مثال خطاهای binding در تمام تمپلیت‌ها شناسایی می‌شود، در صورتی که این برای یک کامپوننت در کامپایل JIT زمانی اتفاق می‌افتد که شما آن کامپوننت یا فانکشن را مستقیما اجرا کنید.

ویژگی‌های دیگر این دو نوع کامپایل:

🔶 کامپایل JIT:

🔸سایز bundle در این نوع کامپایل زیاد است.

🔸سرعت لود شدن برنامه پایین است چون این کامپایل در زمان اجرا اتفاق می‌افتد.

🔸سورس کد شما در این نوع کامپایل قابل مشاهده‌ست و به همین دلیل برای development mode بسیار مناسب است.

🔶 کامپایل AOT:

🔸سایز bundle در این نوع کامپایل پایین است.

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

🔸سورس کد شما دیگر در دسترس نیست ولی در عوض از نظر امنیتی ریسک خیلی پایینی دارد.

🔸برای production mode بسیار مناسب است.

تا انگولار 8 کامپایل پیشفرض به صورت AOT بود ولی از انگولار 9 به بعد به صورت پیشفرض کامپایل JIT انجام می‌شود. هر چند که کامپایل به صورت AOT همچنان به راحتی قابل دسترس است.

❇️ کامندهای هر کامپایل:

JIT: ng build or ng serve

AOT: ng build --prod or ng build --aot

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

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

________

اگه می‌خواین بدونین فرق Blazor server و Blazor WASM تو چیه این مطلب رو بخونین:

در Blazor Wasm:
‌ وب اسمبلی بلیزر روی بروزر کلاینت اجرا می‌کنه و مثل انگولار و ری اکت تو اولین ریکوست CLR, Assemblies, JavaScript, CSS رو دانلود می‌کنه. تو این حالت blazor JavaScript Handler به DOM دسترسی داره و می‌تونه تغییرات رو اعمال کنه.

در Blazor Server:
کد سی شارپ نوشته شده سمت سرور ران می‌شه و javaScript hookهایی هستن که به DOM دسترسی دارن و می‌تونن تغییر ایجاد کنن. تو این حالت باینری مسیج‌هایی وجود داره که اطلاعات رو بین سرور و کلاینت با استفاده از SignalR رد و بدل میکنن. این کار رو فایلblazor.server.js که تو فایل _layout.cshtml قرار داره، انجام می‌ده. در واقع اگر تغییری لازمه باشه، این تغییر با یه update message به دست کلاینت می‌رسه و DOM با توجه به اون بروز می‌کنه.

معایب و مزایای هرکدوم از این دو حالت رو می‌تونید تو این لینک بخونید.

⁉️ سوالات و نکات خود را در قسمت کامنت با ما در میان بگذارید.

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

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

@SoftwarePhilosophy

_______

معماری نرم‌افزار مانند معماری ساختمان یک هنر است

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

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

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

توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را می‌توانید در لینک زیر بخوانید.


http://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/


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

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

_____

📽 اگه دوست دارید مسیر دیزاینر شدن رو بشناسید، در لایو اینستاگرامی آکادمی دیزاین که برگزار می‌شه شرکت کنید.

چهارشنبه ۲۲ تیر
ساعت ۲۰ الی ۲۱:۳۰

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

https://instagram.com/dexignacademy

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

___

دلایل بیزنسی مهاجرت به Blazor، خوش شانسی دات‌نتی‌ها

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

تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیم‌هایی با زبان‌های هر یک از محیطهای بالا نیاز دارید:

Backend: Java, Node.js, PHP, ASP.NET (C#), Python
Frontend: Angular, React, Vue
Android: Java, Kotlin
IOS: Objective-C, Swift
Job: Java, C#
IoT: C++

اگر هر تیم قرار باشد از یک تکنولوژی با زبان متفاوت کار کند شما تقریبا به ۶ تیم نیاز دارید. همچنین اگر بخواهید تیم نسبت به رفت و آمد نیرو امن باشد باید برای هر کاری حداقل ۳ نفر در تیم‌تان داشته باشید. یک نفر با تسلط ۱۰۰٪، یک نفر با تسلط ۷۰٪ و یک نفر با تسلط ۵۰٪.

بنابراین برای داشتن یک تیم امن شما به حدوده ۱۸ نفر نیرو نیاز خواهید داشت تا بتوانید دیسیپلین‌های بالا را پوشش دهید.

شاخص «تحمل‌پذیری» یک تیم نرم‌افزاری

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

مهاجرت به Blazor

زبان سی‌شارپ در چند سال اخیر در همه پلتفرم‌ها قابل استفاده بود به غیر از وب. خوشبختانه با ظهور Blazor که یک فریم‌ورک فوق‌العاده است برنامه‌نویسان سی‌شارپ می‌توانند سیستم‌های بسیار با کیفیت و با پرفورمنس بالایی را روی بستر WebAssembly روی بروزرها بنویسند.

بنابراین اگر تیم شما یک تیم دات‌نتی است، پیشنهاد می‌کنم برای مهاجرت و آموزش نیروهای خود را برای حرکت به سمت Cross-Platform شدن و رسیدن به Full Stack های واقعی، از همین الان برنامه‌ریزی کنید. خبر خوبتر این است که این مسیر کماکان ادامه دارد و با ظهور NET MAUI داستان قرار است بسیار جذاب‌تر و شیرین‌تر هم شود.

توضیحات و دلایل دقیق‌تر را می‌توانید در اینجا مطالعه کنید.

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


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

________

درنگ کردن: مهمترین ابزار برای مدیران محصول

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

درنگی برای اولویت‌بندی مجدد

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

درنگی برای هماهنگی مجدد با گروه

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

درنگی برای بررسی

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


درنگی برای تجلیل کردن

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

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

مقاله کامل را در لینک زیر مطالعه کنید:

https://bit.ly/dxgn946

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

نویسنده: عاطفه صفری

#مدیر_محصول #PM

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

_______

ببخشید، ولی شما مدیر محصول نیستید!

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

۱. اگر اجازه می‌دهید ذی‌نفعان کسب و کار به شما دیکته کنند که فیچر چطور ساخته شود.

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

۲. اگر راه حل را بیشتر از مشکل دوست دارید.

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

۳. اگر از دیتا برای تصمیم گیری استفاده نمی‌کنید.

یک مدیر محصول نباید زیاد تصمیمات شهودی بگیرد. در مورد هر تصمیم، از خودتان سوال کنید چرا و در صورتی که یک پاسخ دیتامحور ندارید، به تحقیق ادامه بدهید. حتی گاهی باید در مورد دیتا پارانویید باشید!

۴. اگر نمی‌توانید حداقل یک وایرفریم لوفیدیلیتی بسازید.

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

۵. اگر برای تعریف معیارهای موفقیت تا بعد از لانچ محصول صبر می‌کنید.

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

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

https://bit.ly/dxgn948

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

نویسنده: عاطفه صفری

#مدیر_محصول #PM

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

_______