Software Philosophy – Telegram
Software Philosophy
3.45K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
Forwarded from فلسفه دیزاین
مدل تفکر سازنده

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

نحوه استفاده از آن
این ابزار یک چارچوب ۶ مرحله‌ای برای حل مسئله به شما می‌دهد. شش مرحله عبارتند از:

۱. بپرسید «چه خبره؟»
۲. بپرسید «موفقیت چیست؟»
۳. بپرسید «سؤال چیه؟»
۴. پاسخ‌ پرسش‌ها را بدهید.
۵. راه‌حل را بسازید.
۶. منابع را تراز کنید.

بیایید هر مرحله را با جزئیات بیشتری بررسی کنیم.

۱. بپرسید «چه خبره؟»
اولین قدم در مورد درک بهتر مسئله است. می‌توانید از این سؤالات راهنما برای کمک به خود استفاده کنید:

- مشکل دقیقاً چیست؟
- تأثیر این مشکل چیست؟
- من از قبل چه می‌دانم؟ چه اطلاعاتی دارم؟
- چه کسی در این ماجرا دخیل است؟
- با حل این مشکل چشم انداز آینده چیست؟ (این همان چیزی است که هرسون آن را "آینده هدف" می‌نامد)

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

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

- می‌خواهید که راه‌حل شما چه کار بکند؟
- محدودیت‌ها چیست؟ چه کاری نباید انجام شود؟
- چه منابعی را می‌توانیم در این امر سرمایه‌گذاری کنیم؟
- راه حل باید چه ارزش‌هایی داشته باشد؟
- نتایج اصلی و ضروری چیست؟

تا زمانی که چشم‌انداز روشنی از موفقیت در پیش روی خود به دست نیاورده‌اید، این سؤالات را مدام از خود بپرسید.

۳. بپرسید «سؤال چیه؟»
اکنون زمان تولید سؤالاتی است که برای دستیابی به چشم‌انداز شما (آینده هدف)، باید پاسخ داده شود. هرسون این‌ها را «سؤالات کاتالیزوری» می‌نامد.
از اطلاعاتی که در مراحل قبلی جمع‌آوری کرده‌اید استفاده کنید. عباراتی مانند «چگونه ممکن است ما ...؟» یا «چگونه می‌توانم ...؟» به شما در فرمول‌بندی سؤالات کمک می‌کند.

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

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

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

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

کتاب Think Better:

http://bit.ly/dxgn766-Book

خلاصه‌ی کتاب و توضیحات این روش:

http://bit.ly/dxgn766-Summary

ویدئو او در TEDxMaastricht با عنوان The shock of the possible:

http://bit.ly/dxgn766-Video

(زمان حدودی مطالعه‌ خلاصه‌ی کتاب: ۱۳ دقیقه
زمان ویدئو: ۱۸:۱۱)

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

#مدل_ذهنی #تعریف_مسئله #روش_حل_مشکل #مدل_تفکر_سازنده #تیم_هرسون #پرسش

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

______
اضافه شدن قابلیت Temporal Table به EF Core 6

مایکروسافت در سال 2016 قابلیت Temporal Table که با نام System-Versioned نیز شناخته می‌شود را به SQL Server اضافه کرد.

این قابلیت امکان این را فراهم می‌کند که تغییرات مربوط به دیتا‌های هر جدول را ذخیره سازی کنیم.

این امکان برای مانیتورینگ و همچنین برگرداندن داده‌های حذف شده مفید است ولی باید در نظر داشت که این امکان باعث بالارفتن سریع حافظه دیتابیس می‌شود.

مایکروسافت در آخرین ورژن EF Core یعنی EF Core 6 این قابلیت را فراهم کرده‌است که به واسطه EF هم بتوانیم از این قابلیت SQL استفاده کنیم.

برای این که جدول مورد نظر از این ویژگی برخوردار باشد باید توسط Fluent Api این کار را انجام دهیم:

    modelBuilder
.Entity<Product>()
.ToTable("Products", b => b.IsTemporal());

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

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

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

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

________
قابلیت Layout در فریم‌ورک Blazor

اگر از فریم‌ورک Blazor استفاده می‌کنید از قابلیت تعریف Layout غافل نشوید. Layout در Blazor مثل Component با دو ویژگی بیشتر است. layout مانند کامپوننت‌های data binding , dependency injeciton و غیره را دارد و علاوه بر آن از BlazorLayoutComponent به ارث رفته و با @body مشخص می‌کند content باید کجا render شود.

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

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

مثلا فرض کنید، صفحاتی که برای یوزر ادمین نمایش می‌دهید المان‌ها و استایل‌های خاص و مشترکی دارند. شما می‌توانید زیر Layout اصلی (که شامل هدر و فوتر و ... است)، یک Layout تعریف کنید و اون را فقط برای صفحات ادمین استفاده کنید.

علاوه بر داکیومنتی که خود ماکروسافت منتشر کرده است، می‌توانید از مقاله زیر هم بهره ببرید:

https://blazor-tutorial.net/layout

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

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

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

_______
Forwarded from فلسفه دیزاین
اولویت‌بندی کارها با ماتریس آیزنهاور

این فریم‌وُرک اولویت‌بندی که به نام ۳۴مین رئیس‌جمهور ایالات متحده آمریکا Dwight D. Eisenhower نامگذاری شده است، به شما کمک می‌کند تا وظایف و فعالیت های خود را با توجه به اهمیت و ضرورت آن‌ها سازماندهی کنید. این به ویژه هنگامی مفید است که سرتان بسیار شلوغ است، اما احساس نمی‌کنید کاری که انجام می‌دهید تأثیر زیادی دارد.

نحوه استفاده از آن
ماتریس آیزنهاور دارای چهار ربع در دو محور اهمیت و ضرورت است.
برای هر فعالیت یا کاری از خود بپرسید: آیا این مهم است یا نه؟ آیا ضروری است یا خیر؟

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

۱. اگر مهم و ضرویست ← آن را انجام دهید
۰ اینها کارهایی هستند که شما می‌خواهید آن‌ها را در اسرع وقت انجام دهید.
۰ بحران‌ها، مشکلاتی که در حال حاضر به شما فشار می‌آورند و سایر مواردی که اگر اکنون به آن رسیدگی نکنید، عواقب بدی خواهند داشت.

۲. اگر مهم است و ضروری نیست ← آن را برنامه‌ریزی کنید
۰ زمانی را برای این کارها پیدا کنید و آنها را بعداً انجام دهید.
۰ این ربع نمودار معمولاً محلی است که در آن کارهای عمیق اتفاق می‌افتد - وظایفی که به پروژه‌ها یا اهداف بلند مدت شما کمک می‌کنند.

۳. اگر ضروری است ولی مهم نیست ← آن را محول کنید (به دیگری واگذار کنید)
۰ اگر می‌توانید، شخصی را پیدا کنید که بتواند این کارها را برای شما انجام دهد.
۰ اگر نمی‌توانید آن را به شخص دیگری محول کنید، آن را برنامه‌ریزی کنید اما همیشه سعی کنید کارهای مهم و غیرضروری را اول انجام دهید.
۰ اینها اغلب کارهای اداری یا مواردی هستند که مهلت دارند، اما حیاتی نیستند.

۴. اگر ضروری و مهم نیست ← آن را انجام ندهید (قیدش را بزنید)
۰ این کارها ارزش وقت شما را ندارند و به هیچ وجه نباید آنها را انجام دهید.
۰ فعالیت‌هایی که می‌توانید آن‌ها را نادیده بگیرید، کارهای بیهوده شلوغ روزانه و سرگرمی‌های شما در این ربع نمودار قرار می‌گیرد.

در بالا ترتیب اولویت وظایف را فهمیدید. بله وظایف مهم و غیرضروری قبل از بی‌اهمیت و ضروری قرار می‌گیرند.

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

همچنین می توانید با آن در بازه‌های زمانی مختلف کار کنید: روز خود را با آن برنامه‌ریزی کنید و در مقابل نیز فعالیت‌های کلی زندگی خود را اولویت‌بندی کنید.

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

تعیین ضرورت و اهمیت همیشه به زمینه و توانایی شما در تشخیص آنچه که واقعاً فوری و واقعاً مهم است بستگی دارد.

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

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

http://bit.ly/dxgn769-1

http://bit.ly/dxgn769-2

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

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

#ماتریس_آیزنهاور #مدیریت_کارها #اولویت_بندی_کارها #مهم #ضروری

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

______
👍1
انتقال داده ها به واسطه Azure Service Bus

امروزه سرعت انتقال داده‌ها از اهمیت بالایی برخوردار است. برای مثال فرض کنید پروژه شما شامل ۲ اپلیکیشن مجزا از هم است که هر دوی آنها از یک دیتابیس مشترک برای داده‌های خود استفاده می‌کنند. اپلیکیشن ۱ بر روی داده‌ها تغییراتی انجام می‌دهد و اپلیکیشن ۲ از این تغییرات استفاده می‌کند.

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

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

برای مثال Apache Kafka٬RabbitMQ٬Google Cloud Pub/Sub و ... از جمله معروف‌ترین message broker موجود هستند.

یکی از بهترین message broker های موجود٬ Azure Service Bus است.

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

البته به صورت پیشفرض (پلن رایگان) از Topic نمیتوانیم استفاده کنیم و صرفا از همان مفهوم Queue می‌شود استفاده کرد.

در این ویدیو نحوه استفاده از Azure Service Bus آموزش داده شده است.

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

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

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

________
🖌 بالاخره 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

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

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

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

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

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

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

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

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

_______
Forwarded from فلسفه دیزاین
سند نیازمندی‌های محصول (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

________
👍72
Forwarded from فلسفه دیزاین
فونت‌هایی از جنس تصویر
درباره فونت آیکن بیشتر بدانیم

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

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

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

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

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

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

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

http://bit.ly/dxgn774

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



کانال فلسفه نرم‌افزار: @SoftwarePhilosophy
👍9
Forwarded from فلسفه دیزاین
تصمیم‌گیری و تفکر به روش مرتبه‌ دوم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://bit.ly/dxgn777

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

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

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

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

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

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

________
👍5
مفهوم 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

________
👍22🥰31
Forwarded from Iran Agile
🎛️ اسکرام برای پروژه‌های سخت‌افزاری

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

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

@iranagile
Forwarded from فلسفه دیزاین
بازی سرعت و کیفیت هنگام ساخت محصول

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

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

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

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

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

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

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

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

http://bit.ly/dxgn781

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

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

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

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

_____
👍2