دلایل بیزنسی مهاجرت به 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
________
داستانِ داشتن یک تیم نرمافزاری همیشه یک داستان پر فراز و نشیب برای شرکتهای نرمافزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژیها، پیدا کردن نیروهای خوب و متعهد، همه اینها فقط قسمتی از چالشهایی است که یک تیم نرمافزاری با آن مواجه است. یکی از مواردی که این داستان را پیچیده میکند، وجود تکنولوژیهای مختلف و زبانهای مختلف است.
تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیمهایی با زبانهای هر یک از محیطهای بالا نیاز دارید:
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
________
ویرگول
دلایل بیزنسی مهاجرت به Blazor، خوش شانسی داتنتیها
داستانِ داشتن یک تیم نرمافزاری همیشه یک داستان پر فراز و نشیب برای شرکتهای نرمافزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژیها، پید…
👍18❤5🔥2
Forwarded from فلسفه دیزاین (mohsen)
درنگ کردن: مهمترین ابزار برای مدیران محصول
کار کردن در شرکتهای تکنولوژیک به عنوان یک مدیر محصول، کار چالش برانگیزی است. تقریبا همه کارها اورژانسی هستند و باید خیلی سریع انجام شوند. ممکن است در میان انبوه ایمیلها، چارتها و اسلایدها حس کنید زمانی برای نفس کشیدن ندارید. این لحظات زمانهایی هستند که شما باید چند دقیقه درنگ کنید. یک قدم به عقب بردارید و چند برای دقیقه کاری را که انجام میدادید متوقف کنید.
در ادامه، در این مورد صحبت میکنیم که درنگ کردن چطور به شما برای تحویل محصول بهتر کمک میکند.
درنگی برای اولویتبندی مجدد
معمولا ذینفعان میخواهند همه کارها همزمان انجام شود. این رویکرد باعث میشود همه کارها همیشه اورژانسی و در اولویت بالا باشند. اما وقتی همه چیز اولویت بالایی دارد، هیچ چیز در اولویت نیست. در این موقعیت لازم است درنگ کنید.
شما به عنوان مدیر محصول بهتر از هرکس دیگری از تاثیرات هر کار و منابع لازم برای آن آگاه هستید. پس درنگ کنید و با ذهن باز اولویتبندی را مشخص کنید. سپس نتیجه را شفاف و کامل، به اطلاع ذینفعان برسانید.
درنگی برای هماهنگی مجدد با گروه
برای جواب دادن عجله نکنید. وقتی از سمت ذینفعان سوالی از شما پرسیده میشود، درنگ کنید و با گروههای مختلفِ مشغول در پروژه هماهنگ شوید، اطلاعات را دسته بندی کنید و پس از آن جواب بدهید.
درنگی برای بررسی
به عنوان مدیر محصول شما با انبوهی از مسئولیتهای مختلف درگیر هستید. مراقب باشید در میان این بحبوحه کاربر را از یاد نبرید. همیشه زمانی را برای درنگ کردن در کارهای جاری، و تمرکز روی کاربران اختصاص دهید. این زمان را باید به بررسی عمیق نیاز کاربران، فیدبکهای آنها، رفتار و پیشنهاداتشان سپری کنید. البته که برای پروژه رودمپ طراحی شده که شما موظف هستید بر اساس آن پیش بروید، ولی فراموش نکنید کاربر از همه چیز مهمتر است.
درنگی برای تجلیل کردن
دستاوردهایتان را دست کم نگیرید. در بین کارهایتان اندکی درنگ کنید و از مسیری که آمدهاید و اهداف پروژه که به آن دست پیدا کردهاید لذت ببرید. با تجلیل از دستاوردهایتان، برای خودتان و تیم انرژی بیشتری برای ادامه مسیر فراهم میکنید.
در محیطهای کاری پرسرعت این روزها، فشار زیادی به مدیران پروژه وارد میشود. احساس گیر افتادن در یک چرخه بی پایان و خسته کننده آسان است. پس فراموش نکیند که گاهی درنگ کنید و انرژی لازم برای ادامه کار را کسب کنید.
مقاله کامل را در لینک زیر مطالعه کنید:
https://bit.ly/dxgn946
(زمان حدودی مطالعه: ۴ دقیقه)
نویسنده: عاطفه صفری
#مدیر_محصول #PM
@Dexign فلسفه دیزاین
_______
کار کردن در شرکتهای تکنولوژیک به عنوان یک مدیر محصول، کار چالش برانگیزی است. تقریبا همه کارها اورژانسی هستند و باید خیلی سریع انجام شوند. ممکن است در میان انبوه ایمیلها، چارتها و اسلایدها حس کنید زمانی برای نفس کشیدن ندارید. این لحظات زمانهایی هستند که شما باید چند دقیقه درنگ کنید. یک قدم به عقب بردارید و چند برای دقیقه کاری را که انجام میدادید متوقف کنید.
در ادامه، در این مورد صحبت میکنیم که درنگ کردن چطور به شما برای تحویل محصول بهتر کمک میکند.
درنگی برای اولویتبندی مجدد
معمولا ذینفعان میخواهند همه کارها همزمان انجام شود. این رویکرد باعث میشود همه کارها همیشه اورژانسی و در اولویت بالا باشند. اما وقتی همه چیز اولویت بالایی دارد، هیچ چیز در اولویت نیست. در این موقعیت لازم است درنگ کنید.
شما به عنوان مدیر محصول بهتر از هرکس دیگری از تاثیرات هر کار و منابع لازم برای آن آگاه هستید. پس درنگ کنید و با ذهن باز اولویتبندی را مشخص کنید. سپس نتیجه را شفاف و کامل، به اطلاع ذینفعان برسانید.
درنگی برای هماهنگی مجدد با گروه
برای جواب دادن عجله نکنید. وقتی از سمت ذینفعان سوالی از شما پرسیده میشود، درنگ کنید و با گروههای مختلفِ مشغول در پروژه هماهنگ شوید، اطلاعات را دسته بندی کنید و پس از آن جواب بدهید.
درنگی برای بررسی
به عنوان مدیر محصول شما با انبوهی از مسئولیتهای مختلف درگیر هستید. مراقب باشید در میان این بحبوحه کاربر را از یاد نبرید. همیشه زمانی را برای درنگ کردن در کارهای جاری، و تمرکز روی کاربران اختصاص دهید. این زمان را باید به بررسی عمیق نیاز کاربران، فیدبکهای آنها، رفتار و پیشنهاداتشان سپری کنید. البته که برای پروژه رودمپ طراحی شده که شما موظف هستید بر اساس آن پیش بروید، ولی فراموش نکنید کاربر از همه چیز مهمتر است.
درنگی برای تجلیل کردن
دستاوردهایتان را دست کم نگیرید. در بین کارهایتان اندکی درنگ کنید و از مسیری که آمدهاید و اهداف پروژه که به آن دست پیدا کردهاید لذت ببرید. با تجلیل از دستاوردهایتان، برای خودتان و تیم انرژی بیشتری برای ادامه مسیر فراهم میکنید.
در محیطهای کاری پرسرعت این روزها، فشار زیادی به مدیران پروژه وارد میشود. احساس گیر افتادن در یک چرخه بی پایان و خسته کننده آسان است. پس فراموش نکیند که گاهی درنگ کنید و انرژی لازم برای ادامه کار را کسب کنید.
مقاله کامل را در لینک زیر مطالعه کنید:
https://bit.ly/dxgn946
(زمان حدودی مطالعه: ۴ دقیقه)
نویسنده: عاطفه صفری
#مدیر_محصول #PM
@Dexign فلسفه دیزاین
_______
Medium
Pause: The Most Important Tool for Product Manager
Taking a step back and pausing could actually be your strongest tool as a Product Manager.
👍4
Forwarded from فلسفه دیزاین (mohsen)
ببخشید، ولی شما مدیر محصول نیستید!
بعضی از مدیرها ادعا میکنند مدیر محصول هستند ولی در واقع با کانسپت مدیریت محصول آشنایی ندارند. در این مقاله مواردی ذکر شده که اگر در مورد شما صدق میکند، نشان میدهد شما یک مدیر محصول نیستید.
۱. اگر اجازه میدهید ذینفعان کسب و کار به شما دیکته کنند که فیچر چطور ساخته شود.
در مسیر پروژههایتان به ذینفعانی برمیخورید که تلاش میکنند شما را مجبور کنند یا حداقل پیشنهاد دهند که محصول چطور باید ساخته شود. این پیشنهادات معمولا با سوگیری همراه است و پشتوانه اطلاعاتی ندارند. به عنوان یک مدیر محصول شما باید از ذینفع در مورد چرایی مشکل سوال کنید. آنقدر به پرسیدن این چرا ادامه بدهید تا مشکلی که باید حل شود، به وضوح مشخص شود.
۲. اگر راه حل را بیشتر از مشکل دوست دارید.
به عنوان یک مدیر محصول باید بتوانید مشکلات کاربر یا ذینفعان را حل کنید. برای این که بتوانید راه حل درست را پیدا کنید، لازم است عمیقا مشکل را بشناسید. برای شناخت عمیق مشکل از ریسرچ، مصاحبه با کاربر، تحلیل دیتا، پیشبینی دیتا و ... استفاده میکنید. وقتی که مشکل را با جزئیات فهمیدید وقت آن است که انتخاب کنید چه راه حلی، بهترین است. به یاد داشته باشید که یک راه حل ممکن است در یک موقعیت بهترین باشد و در موقعیت دیگر نه. یکی از اساتید این حوزه میگوید: عاشق مشکل باشید نه راه حل!
۳. اگر از دیتا برای تصمیم گیری استفاده نمیکنید.
یک مدیر محصول نباید زیاد تصمیمات شهودی بگیرد. در مورد هر تصمیم، از خودتان سوال کنید چرا و در صورتی که یک پاسخ دیتامحور ندارید، به تحقیق ادامه بدهید. حتی گاهی باید در مورد دیتا پارانویید باشید!
۴. اگر نمیتوانید حداقل یک وایرفریم لوفیدیلیتی بسازید.
درست است که در پروژه طراحانی وجود دارند که مسئولیت طراحی محصول به عهده آنهاست. اما بهترین کسی که محصول را میفهمد شما هستید و باید بتوانید یک وایرفریم حداقلی بسازید تا هرجایی که لازم شد برای بهتر منتقل کردن منظورتان از آن استفاده کنید. نرمافزار بالزامیک گزینه مناسبی برای تازهکارهاست.
۵. اگر برای تعریف معیارهای موفقیت تا بعد از لانچ محصول صبر میکنید.
به عنوان یک مدیر محصول باید در ابتدا تحقیقات لازم را انجام دهید و همه پارامترها را بررسی کرده و معیارهایی را تعریف کنید که نشاندهنده موفقیت محصول هستند. نه اینکه پیش بروید تا ببینید چه پیش میآید. تیمهای دیگر مثل تیم مارکتینگ هم میتوانند از معیارهایی که شما تعریف کردهاید استفاده کنند.
در ادامه این مقاله موارد دیگری آورده شده است. اگر در حال حاضر مدیر محصول هستید یا به مدیریت محصول علاقهمندید پیشنهاد میکنیم از لینک زیر مقاله را به صورت کامل مطالعه کنید:
https://bit.ly/dxgn948
(زمان حدودی مطالعه: ۴ دقیقه)
نویسنده: عاطفه صفری
#مدیر_محصول #PM
@Dexign فلسفه دیزاین
_______
بعضی از مدیرها ادعا میکنند مدیر محصول هستند ولی در واقع با کانسپت مدیریت محصول آشنایی ندارند. در این مقاله مواردی ذکر شده که اگر در مورد شما صدق میکند، نشان میدهد شما یک مدیر محصول نیستید.
۱. اگر اجازه میدهید ذینفعان کسب و کار به شما دیکته کنند که فیچر چطور ساخته شود.
در مسیر پروژههایتان به ذینفعانی برمیخورید که تلاش میکنند شما را مجبور کنند یا حداقل پیشنهاد دهند که محصول چطور باید ساخته شود. این پیشنهادات معمولا با سوگیری همراه است و پشتوانه اطلاعاتی ندارند. به عنوان یک مدیر محصول شما باید از ذینفع در مورد چرایی مشکل سوال کنید. آنقدر به پرسیدن این چرا ادامه بدهید تا مشکلی که باید حل شود، به وضوح مشخص شود.
۲. اگر راه حل را بیشتر از مشکل دوست دارید.
به عنوان یک مدیر محصول باید بتوانید مشکلات کاربر یا ذینفعان را حل کنید. برای این که بتوانید راه حل درست را پیدا کنید، لازم است عمیقا مشکل را بشناسید. برای شناخت عمیق مشکل از ریسرچ، مصاحبه با کاربر، تحلیل دیتا، پیشبینی دیتا و ... استفاده میکنید. وقتی که مشکل را با جزئیات فهمیدید وقت آن است که انتخاب کنید چه راه حلی، بهترین است. به یاد داشته باشید که یک راه حل ممکن است در یک موقعیت بهترین باشد و در موقعیت دیگر نه. یکی از اساتید این حوزه میگوید: عاشق مشکل باشید نه راه حل!
۳. اگر از دیتا برای تصمیم گیری استفاده نمیکنید.
یک مدیر محصول نباید زیاد تصمیمات شهودی بگیرد. در مورد هر تصمیم، از خودتان سوال کنید چرا و در صورتی که یک پاسخ دیتامحور ندارید، به تحقیق ادامه بدهید. حتی گاهی باید در مورد دیتا پارانویید باشید!
۴. اگر نمیتوانید حداقل یک وایرفریم لوفیدیلیتی بسازید.
درست است که در پروژه طراحانی وجود دارند که مسئولیت طراحی محصول به عهده آنهاست. اما بهترین کسی که محصول را میفهمد شما هستید و باید بتوانید یک وایرفریم حداقلی بسازید تا هرجایی که لازم شد برای بهتر منتقل کردن منظورتان از آن استفاده کنید. نرمافزار بالزامیک گزینه مناسبی برای تازهکارهاست.
۵. اگر برای تعریف معیارهای موفقیت تا بعد از لانچ محصول صبر میکنید.
به عنوان یک مدیر محصول باید در ابتدا تحقیقات لازم را انجام دهید و همه پارامترها را بررسی کرده و معیارهایی را تعریف کنید که نشاندهنده موفقیت محصول هستند. نه اینکه پیش بروید تا ببینید چه پیش میآید. تیمهای دیگر مثل تیم مارکتینگ هم میتوانند از معیارهایی که شما تعریف کردهاید استفاده کنند.
در ادامه این مقاله موارد دیگری آورده شده است. اگر در حال حاضر مدیر محصول هستید یا به مدیریت محصول علاقهمندید پیشنهاد میکنیم از لینک زیر مقاله را به صورت کامل مطالعه کنید:
https://bit.ly/dxgn948
(زمان حدودی مطالعه: ۴ دقیقه)
نویسنده: عاطفه صفری
#مدیر_محصول #PM
@Dexign فلسفه دیزاین
_______
Medium
Sorry but you are not a Product Manager
There are a number of managers who claim to master product but eventually do not understand Product concepts in detail. I was this person…
👍4👏2
📋 استفاده از Bit platform برای ساخت یک پروژه Blazor
احتمالا هنگام ایجاد یک پروژه #Blazor ای با سوالها و چالشهای متعددی روبرو شدید.
🖊 کندی سرعت لود اولیه سایت در حالت Wasm به دلیل دانلود فایل های مورد نیاز.
🖊 مشکلات سئو.
🖊 مشکلات ایجاد شده به واسطه تعداد بالای کاربر در آن واحد در حالت Blazor Server.
🖊 دردسر زیاد زمانی که تصمیم به سوییچ کردن بین حالتهای مختلف Blazor داشته باشید.
🖊 و مشکلات احتمالی دیگر
تمام این مسائل در🔗 Bit platform مورد بررسی قرار گرفته و شما میتوانید از پروژه Todo Template به عنوان template اولیه خود استفاده کنید.
همچنین 🔗در داکیومنت Todo template توضیحات مختصر و مفیدی مبنی بر نحوه کانفیگ پروژه ارائه شده است که در صورت استفاده از آن میتوانید اکثر مشکلات مطرح شده را حل کنید.
🎯 در حالت کلی هم در اکثر مواقع شما نیاز به یک پروژه Blazor Webassembly ای دارید که Prerendering دارد. یعنی کانفیگ زیر:
🎯 به خاطر کانفیگهایی که در این Template وجود دارد و در داکیومنت به آن اشاره شده است سئو سایت در بهینهترین حالت خود قرار میگیرد.
🎯 با یک کانفیگ بسیار ساده میتوانید بین سه حالت BlazorServer, BlazorWebAssembly و BlazorHybrid سوئیچ کنید.
🎯 میتوانید با یک کد خروجی Web,Android, IOS, Windows و ... داشته باشید.
💻 در نهایت اگه به نظرتون #BitPlatform ابزار مفیدی بود با ستاره دادن و Contribute در Github و اشتراک گزاری این مطلب میتونید از این ابزار حمایت کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
احتمالا هنگام ایجاد یک پروژه #Blazor ای با سوالها و چالشهای متعددی روبرو شدید.
🖊 کندی سرعت لود اولیه سایت در حالت Wasm به دلیل دانلود فایل های مورد نیاز.
🖊 مشکلات سئو.
🖊 مشکلات ایجاد شده به واسطه تعداد بالای کاربر در آن واحد در حالت Blazor Server.
🖊 دردسر زیاد زمانی که تصمیم به سوییچ کردن بین حالتهای مختلف Blazor داشته باشید.
🖊 و مشکلات احتمالی دیگر
تمام این مسائل در🔗 Bit platform مورد بررسی قرار گرفته و شما میتوانید از پروژه Todo Template به عنوان template اولیه خود استفاده کنید.
همچنین 🔗در داکیومنت Todo template توضیحات مختصر و مفیدی مبنی بر نحوه کانفیگ پروژه ارائه شده است که در صورت استفاده از آن میتوانید اکثر مشکلات مطرح شده را حل کنید.
🎯 در حالت کلی هم در اکثر مواقع شما نیاز به یک پروژه Blazor Webassembly ای دارید که Prerendering دارد. یعنی کانفیگ زیر:
<BlazorMode>BlazorWebAssembly</BlazorMode>
<WebAppDeploymentType>SSR</WebAppDeploymentType>
🎯 در این حالت شما یک PWA ای دارید که حالت Prerendering دارد و چالش سرعت اولیه لود سایت در همین جا حل میشود. 🎯 به خاطر کانفیگهایی که در این Template وجود دارد و در داکیومنت به آن اشاره شده است سئو سایت در بهینهترین حالت خود قرار میگیرد.
🎯 با یک کانفیگ بسیار ساده میتوانید بین سه حالت BlazorServer, BlazorWebAssembly و BlazorHybrid سوئیچ کنید.
🎯 میتوانید با یک کد خروجی Web,Android, IOS, Windows و ... داشته باشید.
💻 در نهایت اگه به نظرتون #BitPlatform ابزار مفیدی بود با ستاره دادن و Contribute در Github و اشتراک گزاری این مطلب میتونید از این ابزار حمایت کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
GitHub
GitHub - bitfoundation/bitplatform: Build all of your apps using what you already know and love ❤️
Build all of your apps using what you already know and love ❤️ - bitfoundation/bitplatform
👍18❤8🔥2
Directives in Angular
یکی از کانسپتهای بسیار مهم در انگولار، دیرکتیوهاست.
به طور کلی دیرکتیوها کلاسهایی برای ایجاد رفتار جدید یا تغییر رفتارهای موجود المنتهای DOM میباشند، در واقع میشود گفت: هر نوع دستکاری در المنتهای DOM. برای مثال میشود به حذف و اضافه کردن، تغییرات ظاهری المنتها اشاره کرد.
میتوانیم دیرکتیوها را به سه نوع تقسیم کنیم:
• Component directive
کامپوننتها یک دیرکیتو خاص در انگولار هستند.
یک دیرکیتو همراه با یک تمپلیت، یعنی اجزای اصلی اپلیکیشن انگولاری که کامپوننتها میباشند. کامپوننتها در واقع از مجموعهای از دیرکیتوها ساخته میشوند (این موضوعه که انقدر اهمیتشو بالا میبره).
• Structural directive
همانطور که از اسمش پیداست، این دیرکتیوها ساختار DOM را تحت تاثیر قرار میدهند، از مهمترینهای این نوع میتوانیم به ngIf و ngFor اشاره کنیم که به ترتیب برای حذف و اضافه کردن المنت و رندر کردن لیستی از المنتها در DOM مورد استفاده قرار میگیرند.
این دیرکتیوها همیشه باید با پیشوند ' * ' مورد استفاده قرار گیرند
مثال:
*ngIf
• Attribute directive
این نوع دیرکتیوها به طور کلی برای تغییر ظاهر یا رفتار المنتها مورد استفاده قرار میگیرند که از مهمترینهایشان میشود به ngClass, ngStyle و ngModel اشاره کرد.
دیرکتیوهای نام برده شده همگی از پیش ساخته هستند، ولی ما میتوانیم دیرکتیو خود را بسازیم، ساختن دیرکتیو اصول و قواعد خاصی دارد و از موارد نسبتا تخصصی برای توسعهدهندگان انگولار است.
توضیحات تکمیلی و نحوه ساختن انواع دیرکتیو در لینک زیر قابل دسترس است:
https://blog.bitsrc.io/directives-in-angular-6160ce805416
#حسن_یوسفی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
یکی از کانسپتهای بسیار مهم در انگولار، دیرکتیوهاست.
به طور کلی دیرکتیوها کلاسهایی برای ایجاد رفتار جدید یا تغییر رفتارهای موجود المنتهای DOM میباشند، در واقع میشود گفت: هر نوع دستکاری در المنتهای DOM. برای مثال میشود به حذف و اضافه کردن، تغییرات ظاهری المنتها اشاره کرد.
میتوانیم دیرکتیوها را به سه نوع تقسیم کنیم:
• Component directive
کامپوننتها یک دیرکیتو خاص در انگولار هستند.
یک دیرکیتو همراه با یک تمپلیت، یعنی اجزای اصلی اپلیکیشن انگولاری که کامپوننتها میباشند. کامپوننتها در واقع از مجموعهای از دیرکیتوها ساخته میشوند (این موضوعه که انقدر اهمیتشو بالا میبره).
• Structural directive
همانطور که از اسمش پیداست، این دیرکتیوها ساختار DOM را تحت تاثیر قرار میدهند، از مهمترینهای این نوع میتوانیم به ngIf و ngFor اشاره کنیم که به ترتیب برای حذف و اضافه کردن المنت و رندر کردن لیستی از المنتها در DOM مورد استفاده قرار میگیرند.
این دیرکتیوها همیشه باید با پیشوند ' * ' مورد استفاده قرار گیرند
مثال:
*ngIf
• Attribute directive
این نوع دیرکتیوها به طور کلی برای تغییر ظاهر یا رفتار المنتها مورد استفاده قرار میگیرند که از مهمترینهایشان میشود به ngClass, ngStyle و ngModel اشاره کرد.
دیرکتیوهای نام برده شده همگی از پیش ساخته هستند، ولی ما میتوانیم دیرکتیو خود را بسازیم، ساختن دیرکتیو اصول و قواعد خاصی دارد و از موارد نسبتا تخصصی برای توسعهدهندگان انگولار است.
توضیحات تکمیلی و نحوه ساختن انواع دیرکتیو در لینک زیر قابل دسترس است:
https://blog.bitsrc.io/directives-in-angular-6160ce805416
#حسن_یوسفی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Medium
What are Directives in Angular?
Directives are one of the most important concepts in angular, In this section, we will see what is a directive and its types and how to…
👍6❤2🔥2
💻 به روزرسانی View در Blazor توسط یک Event غیر UI ای
فرض کنید قصد پیاده سازی یک Toaster در Blazor را دارید. احتمالا به این شکل کامپوننت خود را پیاده سازی میکنید که برای مشاهده Toast یک Event را در یک Thread مجزا Raise میکنید و بعد از مثلا ۵ ثانیه یک Event دیگر Raise میکنید که آن Toast محو شود.
داخل Event محو کننده نیز حتما از کد زیر استفاده میکنید.
این مشکل در Blazor (اکثرا) زمانی رخ میدهد که در آن Thread ای که توسط event غیر UI ای صدا زده شده است بخواهید StateHasChanged را صدا بزنید.
راه حل ساده در Blazor استفاده از کد زیر است.
توضیحات کامل را میتوانید از این لینک مطالعه کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
فرض کنید قصد پیاده سازی یک Toaster در Blazor را دارید. احتمالا به این شکل کامپوننت خود را پیاده سازی میکنید که برای مشاهده Toast یک Event را در یک Thread مجزا Raise میکنید و بعد از مثلا ۵ ثانیه یک Event دیگر Raise میکنید که آن Toast محو شود.
داخل Event محو کننده نیز حتما از کد زیر استفاده میکنید.
StateHasChanged();اما در این حالت با خطای زیر مواجه میشوید:
System.InvalidOperationException: The current thread is not associated with the Dispatcher.در پروژههای Blazor,WPF,WinForm, ... زمانی که کد فرانت توسط یک event غیر UI ای صدا زده شده باشد، نیاز به پیاده سازی نوعی سیستم thread locking/synchronisation هست.
این مشکل در Blazor (اکثرا) زمانی رخ میدهد که در آن Thread ای که توسط event غیر UI ای صدا زده شده است بخواهید StateHasChanged را صدا بزنید.
راه حل ساده در Blazor استفاده از کد زیر است.
InvokeAsync(() => StateHasChanged());داخل بدنه InvokeAsync در این مثال StateHasChanged قرار دارد ولی شما میتوانید هر کدی که بخواهد باعث تغییر در View شود را در نظر بگیرید.
توضیحات کامل را میتوانید از این لینک مطالعه کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
👍14
بررسی خطای همزمانی آپدیت در EFCore
فرض کنید از جدول user یک آبجکت با آیدی x لود و track کردهاید. سپس فیلد name را آپدیت میکنید. اما هنوز SaveChange را صدا نزدهاید.
در این بین (بعد از لود و قبل از save کردن) در یک جای دیگر از سیستم همین user آپدیت میشود.
میتوانید مثالی شبیه به کد زیر را پیاده سازی کرده و نتیجه را ببینید:
اتفاقی که خواهد افتاد صادر شدن خطای DbUpdateConcurrencyException است.
چون چیزی که track شده مقدارش steve است ولی در زمان ذخیره مقدار در دیتابیس متفاوت است.
برای درک بهتر این اتفاق و بررسی نحوه حل کردن آن میتوانید از این لینک کمک بگیرید.
در این لینک یک قسمت TODO ای وجود دارد که شما باید تصمیم بگیرید که کدام یک از آپدیتها را اعمال کنید.
اما در این حالت مشکلی وجود دارد. فرض کنید با EF یک user لود کردهاید و نام او را به "jamez" تغییر دادهاید و در آن لحظه age برابر ۲۰ بوده (یعنی ما اصلا در اینجا کاری با age نداریم)
در این مثال قبل از این که savechange را صدا بزنید یک جابی ران شده ونام را به "david" تغییر داده و علاوه بر آن age را نیز به 22 تغییر داده است.
در لینک بالا سیاستی که پیش گرفته شده این است که یا باید name=jamez , age=20 را اعمال کنیم یا name=david, age=22.
در صورتی که به نظر منطقیتر این است که name=jamez و age= 22 را اعمال کنیم.
✅ برای این حالت هم میتوانیم به جای Catch ای که در اینجا آمده از این کد استفاده کنیم:
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
فرض کنید از جدول user یک آبجکت با آیدی x لود و track کردهاید. سپس فیلد name را آپدیت میکنید. اما هنوز SaveChange را صدا نزدهاید.
در این بین (بعد از لود و قبل از save کردن) در یک جای دیگر از سیستم همین user آپدیت میشود.
میتوانید مثالی شبیه به کد زیر را پیاده سازی کرده و نتیجه را ببینید:
var user = await Db.Users.Find(x);⁉️ چه اتفاقی خواهد افتاد؟
user.Name = "jamez";
Db.Database.ExecuteSqlRaw("UPDATE User SET Name = 'david',age=22 WHERE Id = x");
await Db.SaveChangesAsync();
اتفاقی که خواهد افتاد صادر شدن خطای DbUpdateConcurrencyException است.
چون چیزی که track شده مقدارش steve است ولی در زمان ذخیره مقدار در دیتابیس متفاوت است.
برای درک بهتر این اتفاق و بررسی نحوه حل کردن آن میتوانید از این لینک کمک بگیرید.
در این لینک یک قسمت TODO ای وجود دارد که شما باید تصمیم بگیرید که کدام یک از آپدیتها را اعمال کنید.
// TODO: decide which value should be written to databaseدر مثال لینک بالا اینگونه به نظر میرسد که باید یکی از آپدیتهای دیتابیس یا #EF را اعمال کنیم.
// proposedValues[property] = <value to be saved>;
اما در این حالت مشکلی وجود دارد. فرض کنید با EF یک user لود کردهاید و نام او را به "jamez" تغییر دادهاید و در آن لحظه age برابر ۲۰ بوده (یعنی ما اصلا در اینجا کاری با age نداریم)
در این مثال قبل از این که savechange را صدا بزنید یک جابی ران شده ونام را به "david" تغییر داده و علاوه بر آن age را نیز به 22 تغییر داده است.
در لینک بالا سیاستی که پیش گرفته شده این است که یا باید name=jamez , age=20 را اعمال کنیم یا name=david, age=22.
در صورتی که به نظر منطقیتر این است که name=jamez و age= 22 را اعمال کنیم.
✅ برای این حالت هم میتوانیم به جای Catch ای که در اینجا آمده از این کد استفاده کنیم:
foreach (var entry in ex.Entries)___________
{
var proposedValues = entry.CurrentValues;
var databaseValues = await entry.GetDatabaseValuesAsync(cancellationToken);
foreach (var property in proposedValues.Properties)
{
var proposedValue = proposedValues[property];
var databaseValue = databaseValues[property];
var propEnrty = entry.Property(property.Name);
if (propEnrty.IsModified)
{
proposedValues[property] = proposedValue;
}
else
{
proposedValues[property] = databaseValue;
}
}
// Refresh original values to bypass next concurrency check
entry.OriginalValues.SetValues(databaseValues);
}
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Docs
Handling Concurrency Conflicts - EF Core
Managing conflicts when the same data is updated concurrently with Entity Framework Core
👍10🔥9❤4
نحوه کار کردن با UTC در دیتابیسهایی که خارج از ایران مستقر شدهاند
در یکی از پروژههایمان پایگاه داده ما خارج از ایران مستقر شده است و زمانی که کوئریهایی را مینویسیم که نیاز به مقایسه تاریخ داده با تاریخ حال حاضر سیستم دارد (سیستم SQL) دچار مشکل میشویم.
⁉️چه مشکلی؟
فرض کنید الان ساعت ۲ بامداد روز ۵ مرداد است (با احتساب TimeZone ایران). پایگاه داده ما جایی مستقر شده است که TimeZone اش برای مثال 01:00+ است.
اگر بخواهیم دادههای ۵ مرداد فراخوانی شود (همین دو ساعت، یعنی تا ۲ بامداد) چه اتفاقی خواهد افتاد؟
🖊 پاسخ:
اگر تاریخ SQL را در سادهترین حالت مورد استفاده قرار دهیم دادههای روز قبل فراخوانی میشوند.
منظور از ساده ترین حالت مثال زیر است:
⁉️اما راه حل چیست؟
برای این مشکل شما باید مستقیما به #SQL بگویید که چه تایمزونی مد نظرتان است:
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
در یکی از پروژههایمان پایگاه داده ما خارج از ایران مستقر شده است و زمانی که کوئریهایی را مینویسیم که نیاز به مقایسه تاریخ داده با تاریخ حال حاضر سیستم دارد (سیستم SQL) دچار مشکل میشویم.
⁉️چه مشکلی؟
فرض کنید الان ساعت ۲ بامداد روز ۵ مرداد است (با احتساب TimeZone ایران). پایگاه داده ما جایی مستقر شده است که TimeZone اش برای مثال 01:00+ است.
اگر بخواهیم دادههای ۵ مرداد فراخوانی شود (همین دو ساعت، یعنی تا ۲ بامداد) چه اتفاقی خواهد افتاد؟
🖊 پاسخ:
اگر تاریخ SQL را در سادهترین حالت مورد استفاده قرار دهیم دادههای روز قبل فراخوانی میشوند.
منظور از ساده ترین حالت مثال زیر است:
select CAST( SYSDATETIMEOFFSET() AS Date )خروجی این کوئری در مثال ما در آن ساعتهای خاص به جای این که ۵ مرداد باشد برابر است با ۴ مرداد.
⁉️اما راه حل چیست؟
برای این مشکل شما باید مستقیما به #SQL بگویید که چه تایمزونی مد نظرتان است:
select SYSDATETIMEOFFSET() AT TIME ZONE 'Iran Standard Time'برای دیدن لیست TimeZone ها نیز میتوانید از کوئری زیر استفاده کنید:
SELECT * FROM sys.time_zone_info;برای بررسی بیشتر موارد مربوطه میتوانید از این دو مطلب ( یک , دو ) استفاده کنید.
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
👍24❤1🔥1
دردسرهای فعال کردن nullable reference types و راه حل جدید سیشارپ
📘قبل از ورژن ۱۱ سی شارپ، اگر شما nullable value type را در پروژه خود فعال میکردید، هنگام تعریف یک property اگر این property از نوع nullable بود، به چالشی که قرار است مطرح کنیم بر نمیخوردیم، اما اگر nullable نباشد، شما با warning ای مواجه میشوید که باید حتما مقدار اولیه را به این property بدهید.
📗چالشهایی در مقدار دهی این property ها وجود داشت که باعث شد مایکروسافت در C# 11 از کلمه کلیدی required رو نمایی کند.
🔗 از این لینک (https://vrgl.ir/1aVWd) میتوانید جهت مشاهده دقیقتر چالشها و همچنین نحوه استفاده از این ویژگی جدید استفاده کنید.
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
📘قبل از ورژن ۱۱ سی شارپ، اگر شما nullable value type را در پروژه خود فعال میکردید، هنگام تعریف یک property اگر این property از نوع nullable بود، به چالشی که قرار است مطرح کنیم بر نمیخوردیم، اما اگر nullable نباشد، شما با warning ای مواجه میشوید که باید حتما مقدار اولیه را به این property بدهید.
📗چالشهایی در مقدار دهی این property ها وجود داشت که باعث شد مایکروسافت در C# 11 از کلمه کلیدی required رو نمایی کند.
🔗 از این لینک (https://vrgl.ir/1aVWd) میتوانید جهت مشاهده دقیقتر چالشها و همچنین نحوه استفاده از این ویژگی جدید استفاده کنید.
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
ویرگول
ویژگی Required، روشی برای مشکلات فعال بودن Nullable
سری معرفی آپدیت های C# 11 - قسمت دوم - معرفی کلمه کلیدی required
👍12❤9
امکان Raw String Literals، یکی از جذابترینهای C# 11
معمولا زمانی که قصد دارید در متغییری از جنس string دادهای قرار دهید که فرمت خاصی دارد، مثلا داخل آن " وجود دارد یا زمانی که قصد دارید در یک sting interpolated کاراکتر کرلی براکت ({}) نیز در خروجی نمایش داده شود.
و یا زمانی که با گذاشتن @ قبل از string قصد دارید با زدن Enter، در خروجی نیز محتوایی ببینید که Enter خورده است ولی مجبورید خطوط بعدی را به اول کد بچسبانید و یا زمانی که قصد دارید یک xml یا json ایجاد کنید و آن را داخل یک string بریزید...
تقریبا باید با نوشتن کدهای بیریخت آپولو هوا کنید!
مایکروسافت در ورژن ۱۱ سیشارپ خود امکان Raw String Literals را اضافه کرده است و به تمام این شامورتی بازی ها خاتمه داده است.
جهت مشاهده نحوه کار با این قابلیت میتواتید از این لینک استفاده کنید.
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
معمولا زمانی که قصد دارید در متغییری از جنس string دادهای قرار دهید که فرمت خاصی دارد، مثلا داخل آن " وجود دارد یا زمانی که قصد دارید در یک sting interpolated کاراکتر کرلی براکت ({}) نیز در خروجی نمایش داده شود.
و یا زمانی که با گذاشتن @ قبل از string قصد دارید با زدن Enter، در خروجی نیز محتوایی ببینید که Enter خورده است ولی مجبورید خطوط بعدی را به اول کد بچسبانید و یا زمانی که قصد دارید یک xml یا json ایجاد کنید و آن را داخل یک string بریزید...
تقریبا باید با نوشتن کدهای بیریخت آپولو هوا کنید!
مایکروسافت در ورژن ۱۱ سیشارپ خود امکان Raw String Literals را اضافه کرده است و به تمام این شامورتی بازی ها خاتمه داده است.
جهت مشاهده نحوه کار با این قابلیت میتواتید از این لینک استفاده کنید.
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
ویرگول
امکان Raw String Literals، یکی از جذابترینهای C# 11
سری معرفی آپدیت های C# 11 - قسمت اول - معرفی ویژگی Raw String Literals
👍18❤2🔥1
رسیدن به Small Team, Big Impact با تکنولوژیهای Cross-Platform
داستانِ داشتن یک تیم نرمافزاری همیشه یک داستان پر فراز و نشیب برای شرکتهای نرمافزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژیها، پیدا کردن نیروهای خوب و متعهد، همه اینها فقط قسمتی از چالشهایی است که یک تیم نرمافزاری با آن مواجه است. یکی از مواردی که این داستان را پیچیده میکند، وجود تکنولوژیهای مختلف و زبانهای مختلف است.
تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیمهایی با زبانهای متفاوت برای هر کار نیاز دارید، مثلا:
Backend: Java
Frontend: Angular
Android: Kotlin
iOS: Swift
IoT: C++
Windows: C#
اگر هر تیم قرار باشد از یک تکنولوژی با زبان متفاوت کار کند شما تقریبا به ۶ تیم نیاز دارید. همچنین اگر بخواهید تیم نسبت به رفت و آمد نیرو امن باشد باید برای هر کاری حداقل ۳ نفر در تیمتان داشته باشید. یک نفر با تسلط ۱۰۰٪، یک نفر با تسلط ۷۰٪ و یک نفر با تسلط ۵۰٪.
بنابراین برای داشتن یک تیم امن شما به حدود ۱۸ نفر نیرو نیاز خواهید داشت تا بتوانید دیسیپلینهای بالا را پوشش دهید.
شاخص «تحملپذیری» یک تیم نرمافزاری
این شاخص نشان میدهد تیم شما نسبت به رفت و آمد نیرو و یا تحمل تیم در مقابل حجم زیاد کار نامتوازن لحظهای چقدر است. هر چه افراد تیم به قسمتهای مختلف کد مسلطتر باشند این شاخص بالاتر است.
مقاله زیر نشان میدهد که چطور استفاده از یک تکنولوژی Cross-Platform میتواند به شما کمک کند به تحملپذیری بالاتری در تیم خود برسید و بتوانید این کار را حتی با تعداد برنامهنویس کمتر انجام دهید.
در حقیقت این مقاله برای یک مخاطب بیزنسی نوشته شدهاست تا توضیح دهد چرا از لحاظ بیزنسی استفاده از این تکنولوژیها بسیار به نفع شرکت است.
توضیحات دقیقتر را میتوانید در اینجا مطالعه کنید.
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
داستانِ داشتن یک تیم نرمافزاری همیشه یک داستان پر فراز و نشیب برای شرکتهای نرمافزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژیها، پیدا کردن نیروهای خوب و متعهد، همه اینها فقط قسمتی از چالشهایی است که یک تیم نرمافزاری با آن مواجه است. یکی از مواردی که این داستان را پیچیده میکند، وجود تکنولوژیهای مختلف و زبانهای مختلف است.
تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیمهایی با زبانهای متفاوت برای هر کار نیاز دارید، مثلا:
Backend: Java
Frontend: Angular
Android: Kotlin
iOS: Swift
IoT: C++
Windows: C#
اگر هر تیم قرار باشد از یک تکنولوژی با زبان متفاوت کار کند شما تقریبا به ۶ تیم نیاز دارید. همچنین اگر بخواهید تیم نسبت به رفت و آمد نیرو امن باشد باید برای هر کاری حداقل ۳ نفر در تیمتان داشته باشید. یک نفر با تسلط ۱۰۰٪، یک نفر با تسلط ۷۰٪ و یک نفر با تسلط ۵۰٪.
بنابراین برای داشتن یک تیم امن شما به حدود ۱۸ نفر نیرو نیاز خواهید داشت تا بتوانید دیسیپلینهای بالا را پوشش دهید.
شاخص «تحملپذیری» یک تیم نرمافزاری
این شاخص نشان میدهد تیم شما نسبت به رفت و آمد نیرو و یا تحمل تیم در مقابل حجم زیاد کار نامتوازن لحظهای چقدر است. هر چه افراد تیم به قسمتهای مختلف کد مسلطتر باشند این شاخص بالاتر است.
مقاله زیر نشان میدهد که چطور استفاده از یک تکنولوژی Cross-Platform میتواند به شما کمک کند به تحملپذیری بالاتری در تیم خود برسید و بتوانید این کار را حتی با تعداد برنامهنویس کمتر انجام دهید.
در حقیقت این مقاله برای یک مخاطب بیزنسی نوشته شدهاست تا توضیح دهد چرا از لحاظ بیزنسی استفاده از این تکنولوژیها بسیار به نفع شرکت است.
توضیحات دقیقتر را میتوانید در اینجا مطالعه کنید.
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
👍20🔥4
راهنمای قدم به قدم برای آپتیمایز کردن کدی برای ساخت ۲،۰۰۰،۰۰۰ GUID
فرض کنید با مسئلهای مواجه هستید که باید ۲ میلیون گوئد (GUID) در ثانیه بسازید؛ و بسیار مهم است که این کار در کوتاهترین زمان ممکن انجام شود.
در مقاله زیر ابتدا سادهترین کد ممکن که حلقهای ساده برای انجام این کار است نوشته شده، و سپس قدم به قدم با استفاده از تکنیکهای مختلف آپتیمایز شده. کد سادهای که با آن کار شروع شده حدود ۲۱۲ میلیثانیه زمان میبرد و پس از اعمال آخرین آپتیمایزیشن این کار ۴۵ میلیثانیه طول میکشد.
کل کد و بنچمارک این کار در گیتهاب وجود دارد و میتوانید آن را امتحان کنید و یا حتی راههای دیگری برای آپتیمایز کردن آن پیشنهاد دهید.
https://dev.to/mehrandvd/optimizing-guid-generation-step-by-step-225o
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
فرض کنید با مسئلهای مواجه هستید که باید ۲ میلیون گوئد (GUID) در ثانیه بسازید؛ و بسیار مهم است که این کار در کوتاهترین زمان ممکن انجام شود.
در مقاله زیر ابتدا سادهترین کد ممکن که حلقهای ساده برای انجام این کار است نوشته شده، و سپس قدم به قدم با استفاده از تکنیکهای مختلف آپتیمایز شده. کد سادهای که با آن کار شروع شده حدود ۲۱۲ میلیثانیه زمان میبرد و پس از اعمال آخرین آپتیمایزیشن این کار ۴۵ میلیثانیه طول میکشد.
کل کد و بنچمارک این کار در گیتهاب وجود دارد و میتوانید آن را امتحان کنید و یا حتی راههای دیگری برای آپتیمایز کردن آن پیشنهاد دهید.
https://dev.to/mehrandvd/optimizing-guid-generation-step-by-step-225o
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
DEV Community
Optimizing GUID Generation Step by Step
Consider you need to create 2,000,000 GUIDs per second. And believe me, you need it to be so fast! In...
👍26🔥3❤1👏1🤯1
داستان بازگشت به داتنت پس از ۱۰ سال!
داتنت در ۲۰ سال گذشته فراز و نشیبهای زیادی داشته. همه میدانیم داتنتی که امروز با آن کار میکنیم تفاوتهای بسیار بنیادینی با ابتدای آن دارد. مایکروسافت گریزان از اوپنسورس تبدیل شده به یکی از بزرگترین طرفداران پروژههای اوپن سورس جهان.
ولی بسیاری از برنامهنویسان که با داتنت خداحافظی کردهبودند از تغییرات اخیر آن خبر ندارند و کماکان از چیزی متنفرند که دیگر آن نیست!
در مقاله زیر که توسط مدیرعامل شرکت Functionland نوشته شده، او توضیح میدهد که چطور پس از ۱۰ سال دوباره به داتنت برگشته و چرا فکر میکند ظاهرا زمان خوبی برای برگشتن به داتنت است.
این مقاله در لینکدین با این عنوان منتشر شده:
Is Microsoft becoming the cool company that Google used to be? I shared our recent experience with the new .NET!
نسخه کامل این مقاله را میتوانید در 🔗 اینجا بخوانید.
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
داتنت در ۲۰ سال گذشته فراز و نشیبهای زیادی داشته. همه میدانیم داتنتی که امروز با آن کار میکنیم تفاوتهای بسیار بنیادینی با ابتدای آن دارد. مایکروسافت گریزان از اوپنسورس تبدیل شده به یکی از بزرگترین طرفداران پروژههای اوپن سورس جهان.
ولی بسیاری از برنامهنویسان که با داتنت خداحافظی کردهبودند از تغییرات اخیر آن خبر ندارند و کماکان از چیزی متنفرند که دیگر آن نیست!
در مقاله زیر که توسط مدیرعامل شرکت Functionland نوشته شده، او توضیح میدهد که چطور پس از ۱۰ سال دوباره به داتنت برگشته و چرا فکر میکند ظاهرا زمان خوبی برای برگشتن به داتنت است.
این مقاله در لینکدین با این عنوان منتشر شده:
Is Microsoft becoming the cool company that Google used to be? I shared our recent experience with the new .NET!
نسخه کامل این مقاله را میتوانید در 🔗 اینجا بخوانید.
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
DEV Community
Ditching .NET and finding faith again after 10 years!
Case study of developing an open-source File Manager app in .NET MAUI
👍18🔥9🥰3👏3
داستان ساخت یک تیم نرمافزاری نینجایی برای شرکت FxLand!
ساختن تیم نرمافزاری همیشه برای بیزنسها یک کار پر دغدغه و پر ریسک است.
مخصوصا اگر بخواهید تیمی نرمافزاری درست کنید تا محصولی بسازد که همزمان روی پلتفرمهای مختلف مثل وب، اندروید، آیاواس، ویندوز و ... کار کند.
شما باید تیمهای مختلفی روی تکنولوژیهای مختلف تشکیل دهید. به این داستان پیچیده این را هم اضافه کنید که پروژه کلاٌ ۳ ماه وقت دارد! و حتی یک روز تاخیر باعث شکست کل پروژه میشود... این وضعیتی بود که شرکت کانادیی FxLand با آن مواجه بوده و ما قرار است داستان ساخت تیم نرمافزاری برای چنین موقعیتی را با هم بخوانیم.
A hard deadline for December 30th!
در پست زیر داستان ساخت چنین تیم نرمافزاری که باید در عرض یک هفته ساخته میشد را میخوانید.
تیمی که باید در عرض مدت سه ماه، یک اپ را برای پلتفرمهای Android, iOS, Windows و macOS آماده میکرد، و بر خلاف داستانهای معمول ساخت تیمهای نرمافزاری، این بار پایان خوشی داشت!
https://mehrandvd.me/2022/12/18/building-a-ninja-team-for-fxland/
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
ساختن تیم نرمافزاری همیشه برای بیزنسها یک کار پر دغدغه و پر ریسک است.
مخصوصا اگر بخواهید تیمی نرمافزاری درست کنید تا محصولی بسازد که همزمان روی پلتفرمهای مختلف مثل وب، اندروید، آیاواس، ویندوز و ... کار کند.
شما باید تیمهای مختلفی روی تکنولوژیهای مختلف تشکیل دهید. به این داستان پیچیده این را هم اضافه کنید که پروژه کلاٌ ۳ ماه وقت دارد! و حتی یک روز تاخیر باعث شکست کل پروژه میشود... این وضعیتی بود که شرکت کانادیی FxLand با آن مواجه بوده و ما قرار است داستان ساخت تیم نرمافزاری برای چنین موقعیتی را با هم بخوانیم.
A hard deadline for December 30th!
در پست زیر داستان ساخت چنین تیم نرمافزاری که باید در عرض یک هفته ساخته میشد را میخوانید.
تیمی که باید در عرض مدت سه ماه، یک اپ را برای پلتفرمهای Android, iOS, Windows و macOS آماده میکرد، و بر خلاف داستانهای معمول ساخت تیمهای نرمافزاری، این بار پایان خوشی داشت!
https://mehrandvd.me/2022/12/18/building-a-ninja-team-for-fxland/
#مهران_داودی (لینکدین - بلاگ)
کانال تلگرام:
@SoftwarePhilosophy
_____
👍12🔥2👏1
ویژگی های محیط Debug و تفاوت آن با محیط Release
ما دو محیط توسعه نرم افزار خیلی مهم داریم به اسم Debug و Release، بیشتر کار برنامه نویسان در محیط Debug انجام میشود تا بتوانند برنامه خود را اشکال زدایی کنند.
در محیط Debug ابزارهایی داریم که نقش پررنگی در پیدا کردن مشکل ایجاد شده دارند، یکی از این ابزارها Breakpoint ها هستند که به ما برنامه نویسها قدرت کارآگاه بودن میدهد و میتوانیم قسمتهایی را که به عنوان سرنخ تشخیص دادهایم با تمام جزئیات ببینیم.
اگر دوست دارید مسیر کارگاه بودن در کدهایتان را آغاز کنید میتوانید از این لینک شروع کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#هوتن_همتی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
ما دو محیط توسعه نرم افزار خیلی مهم داریم به اسم Debug و Release، بیشتر کار برنامه نویسان در محیط Debug انجام میشود تا بتوانند برنامه خود را اشکال زدایی کنند.
در محیط Debug ابزارهایی داریم که نقش پررنگی در پیدا کردن مشکل ایجاد شده دارند، یکی از این ابزارها Breakpoint ها هستند که به ما برنامه نویسها قدرت کارآگاه بودن میدهد و میتوانیم قسمتهایی را که به عنوان سرنخ تشخیص دادهایم با تمام جزئیات ببینیم.
اگر دوست دارید مسیر کارگاه بودن در کدهایتان را آغاز کنید میتوانید از این لینک شروع کنید.
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#هوتن_همتی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
DEV Community
Debugging in .NET apps using Visual Studio Part 1
I’m getting back from cycling right now and I think about the relationship between car and bicycle in...
👍9🔥3👏1🤔1
Software Philosophy
Photo
سفر قهرمانی #C از روزی که به دنیا آمد!
این قهرمان ما از سال ۲۰۰۲ سفر خودش را همراه با Visual Studio 2002 شروع کرد و تا امروز (۲۰۲۳) حدود ۱۱ بار آپدیتهای جدیدی را ارائه داده است.
در اوایل کار زبانی شبیه به Java بود و صرفا نسبت به زبانهای سطح پایین تنها چیزی که اضافه داشت بحث شیگرایی بود، اما در ادامه وارد دورههای مختلفی شد که نگاهی به این مسیر خواهیم کرد.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر نخستین: تبدیل شدن به یک زبان قابل قبول
C# 1.0, C# 1.2, C# 2.0
در این عصر زبانی را مشاهده میکنیم که تقریبا مثل بقیه زبانهای C-Base است و تفاوت چندانی با آنها ندارد. میشود گفت اینجا کار کردن با انواع دادهها نسبت به بقیه زبانها آسونتر است.
با قابلیتهای شیگرایی شروع کرده و در ادامه به خاطر چالشهای نشت حافظه و ... ویژگیهای دیگری را در ورژنهای بعدی ارائه داد.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر دوم: اضافه شدن امکانات منحصر بفرد
C# 3.0, C# 4.0, C# 5.0
حدود سال ۲۰۰۷ قهرمان ما تصمیم گرفت امکانات منحصر بفردی را ارائه دهد تا این زبان را از بقیه هم ردیفهای خود متمایز کند.
این امکانات همراه با NET Framework version 3.5 و Visual Studio 2008 وارد بازار شدند.
امکانات نام آشنایی از قبیل Lambda expression ها،Object and collection initializer ها و ... در این ورژن به سیشارپ اضافه شدند.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر سوم: باز نویسی کامل کامپایلر با سیشارپ (Roslyn)
C# 6.0
سال ۲۰۱۵ سیشارپ ۶ همراه با Visual Studio 2015 وارد بازار شد. اینبار سیشارپ شروع به اعمال تغییراتی کرد که عمدتا با ذهنیت کد تمیز و ساده همراه بود. از جمله تغییرات مهم هم بازنویسی کامل کامپایلر با خود زبان سیشارپ بود.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر چهارم: رضایت طرفداران کد تمیز و ساده
C# 7.0, C# 7.1, C# 7.2, C# 7.3
استارت تغییرات کوچک نسخه ۶ سیشارپ خورده شده بود ولی از نسخه ۷ به بعد مایکروسافت تمرکز بیشتری روی این امر داشت و تغییرات همگی دارای یک هدف مهم بودند: آسان و تمیز بودن کدها!
امکاناتی از قبیل tuple,out,ref و ... از جمله این تغییرات بودند.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر پنجم: دنیای Cross-Platform، خداحافظی با NullReferenceException و تلاش برای شبیه شدن به زبانهای اسکریپت نویسی
C# 8.0, C# 9, C# 10, C# 11
با روی کار آمدن NET Core. مایکروسافت امکاناتی را ارائه داده بود که مبتنی بر تواناییهای CLR بود.
سالها برنامه نویسها با خطای NullReferenceException دست و پنجه نرم میکردند ولی حالا با استفاده درست از قابلیت Nullable refrence type ها میشد تا حد قابل قبولی جلوی این اتفاق را گرفت.
در ادامه تغییرات به سمتی رفته که زبان سیشارپ را شبیه به یک زبان اسکریپت نویسی کرده بود. حالا میشد بدون تعریف کلاس و متد خاصی دستورات ساده را اجرا کرد. همچنین قابلیتهایی که در pattern maching به سیشارپ اضافه شد باعث سادهتر و قابل فهمتر شدن سیشارپ میشد.
🔗 مشاهده جزئیات ورژن های مختلف سیشارپ
🔗 مطالعه مقاله در ویرگول
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
این قهرمان ما از سال ۲۰۰۲ سفر خودش را همراه با Visual Studio 2002 شروع کرد و تا امروز (۲۰۲۳) حدود ۱۱ بار آپدیتهای جدیدی را ارائه داده است.
در اوایل کار زبانی شبیه به Java بود و صرفا نسبت به زبانهای سطح پایین تنها چیزی که اضافه داشت بحث شیگرایی بود، اما در ادامه وارد دورههای مختلفی شد که نگاهی به این مسیر خواهیم کرد.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر نخستین: تبدیل شدن به یک زبان قابل قبول
C# 1.0, C# 1.2, C# 2.0
در این عصر زبانی را مشاهده میکنیم که تقریبا مثل بقیه زبانهای C-Base است و تفاوت چندانی با آنها ندارد. میشود گفت اینجا کار کردن با انواع دادهها نسبت به بقیه زبانها آسونتر است.
با قابلیتهای شیگرایی شروع کرده و در ادامه به خاطر چالشهای نشت حافظه و ... ویژگیهای دیگری را در ورژنهای بعدی ارائه داد.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر دوم: اضافه شدن امکانات منحصر بفرد
C# 3.0, C# 4.0, C# 5.0
حدود سال ۲۰۰۷ قهرمان ما تصمیم گرفت امکانات منحصر بفردی را ارائه دهد تا این زبان را از بقیه هم ردیفهای خود متمایز کند.
این امکانات همراه با NET Framework version 3.5 و Visual Studio 2008 وارد بازار شدند.
امکانات نام آشنایی از قبیل Lambda expression ها،Object and collection initializer ها و ... در این ورژن به سیشارپ اضافه شدند.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر سوم: باز نویسی کامل کامپایلر با سیشارپ (Roslyn)
C# 6.0
سال ۲۰۱۵ سیشارپ ۶ همراه با Visual Studio 2015 وارد بازار شد. اینبار سیشارپ شروع به اعمال تغییراتی کرد که عمدتا با ذهنیت کد تمیز و ساده همراه بود. از جمله تغییرات مهم هم بازنویسی کامل کامپایلر با خود زبان سیشارپ بود.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر چهارم: رضایت طرفداران کد تمیز و ساده
C# 7.0, C# 7.1, C# 7.2, C# 7.3
استارت تغییرات کوچک نسخه ۶ سیشارپ خورده شده بود ولی از نسخه ۷ به بعد مایکروسافت تمرکز بیشتری روی این امر داشت و تغییرات همگی دارای یک هدف مهم بودند: آسان و تمیز بودن کدها!
امکاناتی از قبیل tuple,out,ref و ... از جمله این تغییرات بودند.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🔹عصر پنجم: دنیای Cross-Platform، خداحافظی با NullReferenceException و تلاش برای شبیه شدن به زبانهای اسکریپت نویسی
C# 8.0, C# 9, C# 10, C# 11
با روی کار آمدن NET Core. مایکروسافت امکاناتی را ارائه داده بود که مبتنی بر تواناییهای CLR بود.
سالها برنامه نویسها با خطای NullReferenceException دست و پنجه نرم میکردند ولی حالا با استفاده درست از قابلیت Nullable refrence type ها میشد تا حد قابل قبولی جلوی این اتفاق را گرفت.
در ادامه تغییرات به سمتی رفته که زبان سیشارپ را شبیه به یک زبان اسکریپت نویسی کرده بود. حالا میشد بدون تعریف کلاس و متد خاصی دستورات ساده را اجرا کرد. همچنین قابلیتهایی که در pattern maching به سیشارپ اضافه شد باعث سادهتر و قابل فهمتر شدن سیشارپ میشد.
🔗 مشاهده جزئیات ورژن های مختلف سیشارپ
🔗 مطالعه مقاله در ویرگول
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Docs
The history of C#
Learn how the C# language has changed over its many releases. Learn when different features were introduced in the language.
👍28❤9🔥3🤩2
ولیدیشنی آسان و بدون درد!
در NET. ابزارهایی برای Validation پراپرتیهای یک کلاس وجود دارد که نام آشناترین آنها DataAnnotation است.
اما یکی از قویترین و آسانترین Library ها، ابزار FluentValidation است.
دلیل آسان بودن کار کردن با این کتابخانه strongly-typed بودن آن است.
مثال:
🔗 داکیومنت FluentValidation
🔗 سورس کد پروژه FluentValidation
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
در NET. ابزارهایی برای Validation پراپرتیهای یک کلاس وجود دارد که نام آشناترین آنها DataAnnotation است.
اما یکی از قویترین و آسانترین Library ها، ابزار FluentValidation است.
دلیل آسان بودن کار کردن با این کتابخانه strongly-typed بودن آن است.
مثال:
RuleFor(person => person.UserName)
.NotEmpty()
.MinimumLength(3);
🔗 نسخه کامل این مقاله را میتوانید در اینجا مطالعه کنید. با مطالعه کامل این مقاله میتوانید از این ابزار در هر جایی استفاده کنید. یکی از کاربردی ترین امکانات آن استفاده در EF Core و Razor Page ها است. همچنین میتوانید Validation های Customize شده توسط خودتان را نیز تعریف و اعمال کنید.🔗 داکیومنت FluentValidation
🔗 سورس کد پروژه FluentValidation
___________
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنتها به اشتراک بگذارید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Docs
System.ComponentModel.DataAnnotations Namespace
Provides attribute classes that are used to define metadata for ASP.NET MVC and ASP.NET data controls.
👍15❤7🔥3👏2
Forwarded from Functionland Announcements (Kel ~ Does Not PM first)
Join us and learn how Blazor MAUI can help you maximize code sharing across Web, Android, iOS, Windows, macOS and more.
This is a must-see event for anyone who knows C#! Come see how Blazor worked its magic for Functionland’s FxFiles app!📲
Gain valuable insights on FxFiles development from our very own CEO Keyvan M.Sadeghi and software architecture Mehran Davoudi.💫
bit.ly/BlazorFxFiles
@functionland
This is a must-see event for anyone who knows C#! Come see how Blazor worked its magic for Functionland’s FxFiles app!📲
Gain valuable insights on FxFiles development from our very own CEO Keyvan M.Sadeghi and software architecture Mehran Davoudi.💫
bit.ly/BlazorFxFiles
@functionland
🔥7👍4🎉2❤1
یک تیر و دو نشان با Blazor United
همانطور که میدانید در ASP.NET Core دو روش برای بیلد web UI وجود دارد:
۱. روش Server Side Rendering (SSR): در این روش HTML مورد نیاز برای نمایش سمت سرور ساخته میشود و همه چیز آماده نمایش سمت کلاینت میرسد و کلاینت فقط و فقط باید HTML رندر شده را نمایش دهد. با توجه به اینکه همه کارهای سخت مثل گرفتن دیتا و نحوه نمایش سمت سرور مشخص شده است، وظایف سمت کلاینت خیلی سبکتر است. بنابراین از مزایای این روش سرعت لود بالا و سئو بهتر است.
۲. روش Client Side Rendering (CSR): در این روش اتفاقاتی که روی UI رخ میدهد، سمت کلاینت هندل میشود. این در حالیست که در روش SSR هر تغییر و اتفاق روی UI باید سمت سرور فرستاده شود تا نتیجه مشخص گردد. به همین دلیل سرور رندرینگ برای پروژههایی که تعامل زیادی با کاربر دارد مناسب نیست و CSR پیشنهاد میشود.
در بیشتر پروژهها ترکیبی از این دو روش لازم است، یعنی برخی صفحات تعامل کمتری با کاربر دارند ولی سرعت لود بالایی را میطلبند و اینکه لازم است بتوانند به راحتی ایندکس شوند، مانند صفحات home و درباره ما و مانند آن. از طرف دیگر برخی صفحات ارتباط بیشتری با کاربر دارند و پاسخگو بودن در هر لحظه حائز اهمیت است.
اینجاست که Blazor United به کار میآید. Blazor United به شما این امکان ر میدهد که با معماری واحد از هر کدام از روش های لازم (SSR or CSR)، برای رندرینگ صفحات خود استفاده کنید. حتی به شما این امکان را میدهد که از هر دو روش در یک صفحه استفاده کنید.
در این رابطه میتوانید صحبتهای Steve Sanderson را بشنوید:
https://youtu.be/48G_CEGXZZM
⁉️ سوالات و نکات خود را در قسمت کامنت با ما در میان بگذارید.
#مریم_داودی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
_______
همانطور که میدانید در ASP.NET Core دو روش برای بیلد web UI وجود دارد:
۱. روش Server Side Rendering (SSR): در این روش HTML مورد نیاز برای نمایش سمت سرور ساخته میشود و همه چیز آماده نمایش سمت کلاینت میرسد و کلاینت فقط و فقط باید HTML رندر شده را نمایش دهد. با توجه به اینکه همه کارهای سخت مثل گرفتن دیتا و نحوه نمایش سمت سرور مشخص شده است، وظایف سمت کلاینت خیلی سبکتر است. بنابراین از مزایای این روش سرعت لود بالا و سئو بهتر است.
۲. روش Client Side Rendering (CSR): در این روش اتفاقاتی که روی UI رخ میدهد، سمت کلاینت هندل میشود. این در حالیست که در روش SSR هر تغییر و اتفاق روی UI باید سمت سرور فرستاده شود تا نتیجه مشخص گردد. به همین دلیل سرور رندرینگ برای پروژههایی که تعامل زیادی با کاربر دارد مناسب نیست و CSR پیشنهاد میشود.
در بیشتر پروژهها ترکیبی از این دو روش لازم است، یعنی برخی صفحات تعامل کمتری با کاربر دارند ولی سرعت لود بالایی را میطلبند و اینکه لازم است بتوانند به راحتی ایندکس شوند، مانند صفحات home و درباره ما و مانند آن. از طرف دیگر برخی صفحات ارتباط بیشتری با کاربر دارند و پاسخگو بودن در هر لحظه حائز اهمیت است.
اینجاست که Blazor United به کار میآید. Blazor United به شما این امکان ر میدهد که با معماری واحد از هر کدام از روش های لازم (SSR or CSR)، برای رندرینگ صفحات خود استفاده کنید. حتی به شما این امکان را میدهد که از هر دو روش در یک صفحه استفاده کنید.
در این رابطه میتوانید صحبتهای Steve Sanderson را بشنوید:
https://youtu.be/48G_CEGXZZM
⁉️ سوالات و نکات خود را در قسمت کامنت با ما در میان بگذارید.
#مریم_داودی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
_______
YouTube
Blazor United prototype
A quick look at some of the experiments we're considering for Blazor in .NET 8
👍14🔥4❤3