افزونه تبدیل تاریخ میلادی به شمسی با کمک Extension Method ها در #C :
https://www.nuget.org/packages/Codehaks.PersianDateTime
https://www.nuget.org/packages/Codehaks.PersianDateTime
کدهک
افزونه تبدیل تاریخ میلادی به شمسی با کمک Extension Method ها در #C : https://www.nuget.org/packages/Codehaks.PersianDateTime
برای استفاده از این افزونه ها کافیه پکیج Codehaks.PersianDateTime رو از طریق nuget نصب کنید. بعد هرجا نیاز به تبدیل تاریخ میلادی به شمسی داشتید ازش استفاده کنید :
DateTime.Now.ToPersianDate()
DateTime.Now.ToPersianDateTime()
DateTime.Now.ToFullPersianDate()
DateTime.Now.ToFullPersianDateTime()
این افزونه در ویو ها و کلاسهای سی شارپ قابل فراخوانیه و کار تبدیل تاریخ میلادی به شمسی رو راحت میکنه، ضمن اینکه خروجی از نوع string هست. سورس پروژه در آدرس زیر قابل مشاهده است :
https://github.com/codehaks/Codehaks.PersianDateTime
DateTime.Now.ToPersianDate()
DateTime.Now.ToPersianDateTime()
DateTime.Now.ToFullPersianDate()
DateTime.Now.ToFullPersianDateTime()
این افزونه در ویو ها و کلاسهای سی شارپ قابل فراخوانیه و کار تبدیل تاریخ میلادی به شمسی رو راحت میکنه، ضمن اینکه خروجی از نوع string هست. سورس پروژه در آدرس زیر قابل مشاهده است :
https://github.com/codehaks/Codehaks.PersianDateTime
GitHub
codehaks/Codehaks.PersianDateTime
Codehaks.PersianDateTime - Extention Methods to convert DateTime to persian
هنر بریدن ، چیدن و کوتاه کردن
وقتی تیمور لنگ شروع به کشور گشایی کرد هدفش فتح دنیا نبود، او فقط به قلعه ی بعدی فکر میکرد. عجیب آنکه سر آخر تا پشت دیوار چین پیش رفت . تنها چیزی که او را از ادامه ی پیروزی باز داشت مرگش بود.
مدیریت پروژه فرق زیادی با کشور گشایی ندارد. وقتی پروژه ای بیش از حد بزرگ باشد انجامش غیر ممکن میشود. بسیاری از کافرما ها اصرار دارند یک پروژه ی کامل تحویل بگیرند. آنها لیستی به شما میدهند و انتظار دارند با نسخه ی کامل رویایشان برگردید . در حالی که هیچکدام از شرکتهای تولید کننده ی نرم افزار از چنین روشی استفاده نمی کنند. آنها از سر و ته یک رویا میزنند تا پروژه در قالب زمان و پول جا شود.
سایت محصولات یکبار تولید نیست. ساده ترین سایت هم نیاز به بروز رسانی دارد. حتی اگر تکنولوژی تغییر نکند ، آمار بازدید زیاد نشود یا حادثه برای سرور رخ ندهد، خود کار فرما ایده های جدیدی خواهد داشت.
مهم نیست انتظار کارفرمای شما چیست. کار اول شما این است که از آن کم کنید. کارفرماها معمولا رویاهای بزرگی در ابعاد آمازون ، فیس بوک و یوتیوب دارند. به آنها یاد آوری کنید هدف اول باید فتح قلعه ی بعدی باشد. اینکه آیا در نهایت به دیوار چین میرسید یا نه به آینده بستگی دارد.
وقتی تیمور لنگ شروع به کشور گشایی کرد هدفش فتح دنیا نبود، او فقط به قلعه ی بعدی فکر میکرد. عجیب آنکه سر آخر تا پشت دیوار چین پیش رفت . تنها چیزی که او را از ادامه ی پیروزی باز داشت مرگش بود.
مدیریت پروژه فرق زیادی با کشور گشایی ندارد. وقتی پروژه ای بیش از حد بزرگ باشد انجامش غیر ممکن میشود. بسیاری از کافرما ها اصرار دارند یک پروژه ی کامل تحویل بگیرند. آنها لیستی به شما میدهند و انتظار دارند با نسخه ی کامل رویایشان برگردید . در حالی که هیچکدام از شرکتهای تولید کننده ی نرم افزار از چنین روشی استفاده نمی کنند. آنها از سر و ته یک رویا میزنند تا پروژه در قالب زمان و پول جا شود.
سایت محصولات یکبار تولید نیست. ساده ترین سایت هم نیاز به بروز رسانی دارد. حتی اگر تکنولوژی تغییر نکند ، آمار بازدید زیاد نشود یا حادثه برای سرور رخ ندهد، خود کار فرما ایده های جدیدی خواهد داشت.
مهم نیست انتظار کارفرمای شما چیست. کار اول شما این است که از آن کم کنید. کارفرماها معمولا رویاهای بزرگی در ابعاد آمازون ، فیس بوک و یوتیوب دارند. به آنها یاد آوری کنید هدف اول باید فتح قلعه ی بعدی باشد. اینکه آیا در نهایت به دیوار چین میرسید یا نه به آینده بستگی دارد.
فریم ورک Blazor
فریم ورک Blazor یک پروژه ی آزمایشی است که به تازگی به ASP اضافه شده و امکان استفاده از Web Assembly در دات نت را فراهم میکند. تمام مرورگرهای جدید از Web Assembly پشتیبانی می کنند. در نتیجه می توانید برنامه ی کلاینتی بنویسید که مانند جاوا اسکریپت به رویدادهای موس و کیبورد واکنش میدهد در کلاینت اجرا میشود.
نسخه ی آزمایشی این فریم ورک قابلیت دیباگ و Live Reloading دارد همچنین به شما امکان میدهد کامپوننت هایی بنویسید که به صورت تو در تو به هم وابستگی دارند. ابزاری مانند Dependency Injection و Server-Side Rendering هم در آن گنجاده خواهد شد.
یکی از جالبترین قابلیت های این فریم ورک امکان اجرای دستورات جاوا اسکریپت از درون #C است. حجم فریم ورک در حدود 400 کیلوبایت است که به همراه اولین بارگذاری صفحه دانلود میشود. در صورت عدم پشتیبانی مرورگر از Web Assembly یک فایل جاوا اسکریپت اجرای کدهای #C را شبیه سازی میکند. پس برنامه ی شما روی مرورگرهای قدیمی هم بدون مشکل اجرا خواهد شد.
جهت دانلود و نصب قالب نمونه می توانید به آدرس زیر مراجعه کنید :
https://github.com/aspnet/blazor
فریم ورک Blazor یک پروژه ی آزمایشی است که به تازگی به ASP اضافه شده و امکان استفاده از Web Assembly در دات نت را فراهم میکند. تمام مرورگرهای جدید از Web Assembly پشتیبانی می کنند. در نتیجه می توانید برنامه ی کلاینتی بنویسید که مانند جاوا اسکریپت به رویدادهای موس و کیبورد واکنش میدهد در کلاینت اجرا میشود.
نسخه ی آزمایشی این فریم ورک قابلیت دیباگ و Live Reloading دارد همچنین به شما امکان میدهد کامپوننت هایی بنویسید که به صورت تو در تو به هم وابستگی دارند. ابزاری مانند Dependency Injection و Server-Side Rendering هم در آن گنجاده خواهد شد.
یکی از جالبترین قابلیت های این فریم ورک امکان اجرای دستورات جاوا اسکریپت از درون #C است. حجم فریم ورک در حدود 400 کیلوبایت است که به همراه اولین بارگذاری صفحه دانلود میشود. در صورت عدم پشتیبانی مرورگر از Web Assembly یک فایل جاوا اسکریپت اجرای کدهای #C را شبیه سازی میکند. پس برنامه ی شما روی مرورگرهای قدیمی هم بدون مشکل اجرا خواهد شد.
جهت دانلود و نصب قالب نمونه می توانید به آدرس زیر مراجعه کنید :
https://github.com/aspnet/blazor
GitHub
GitHub - dotnet/blazor: Blazor moved to https://github.com/dotnet/aspnetcore
Blazor moved to https://github.com/dotnet/aspnetcore - GitHub - dotnet/blazor: Blazor moved to https://github.com/dotnet/aspnetcore
معرفی Technical Debt
بدهی فنی یا Technical Debt زمانی پیش می آید که بجای راه درست راه سریع را در پیش میگیرید. راه درست در بسیاری موارد طولانی و پیچیده است و شما خسته هستید،حوصله ندارید یا عجله دارید، پس سعی میکنید از راه میانبر بروید و با سرهم بندی مشکل را حل کنید.
ممکن است انتخاب راه میانبر از روی نادانستن باشد. اما معمولا این انتخاب عمدی است. محدودیت پول و زمان ، فشار کارفرما و یا باگ می تواند شما را به مسیر میانبر هدایت کند. وقتی سایت شما با هزاران کاربر ناگهان کرش میکند چیزی که اهمیت دارد آنلاین شدن مجدد پروژه است. با خود میگوید بعدا برمیگردم و اصلاح میکنم. اینجاست که بدهکار میشوید. بدهی مانند لایه های چربی دور شکم پروژه ی جمع میشود و آن را سنگین و مریض میکند.
هر چقدر پروژه بزرگتر باشد بدهی فنی با سرعت بیشتری بالا میرود. وقتی از برنامه عقب باشید اعضای تیم شروع به میانبر زدن میکنند و رهگیری همه آنها برای مدیر پروژه غیر ممکن است.
بدهی فنی لزوما بد نیست. در بسیاری از موارد چاره ای جز بدهکار شدن ندارید. مهم این است که :
1- بدانید کجا در حال میانبر زدن هستید.
2- آمار آن را به خوبی نگه دارید و هر وقت میانبر زدید جایی ثبت کنید.
3- همه روزه بخشی از زمان خود را صرف از بین بردن بدهی های قبلی کنید.
4- هیچوقت اجاز ندهید میزان بدهی فنی از 20 درصد کل پروژه بیشتر شود.
هر چه میزان بدهی بالا رود توسعه ی پروژه در درازمدت سخت تر میشود. خیلی زود مجبور میشوید روی میانبر های قبل میانبر های جدید پیاده کنید. آن وقت است که باید زنگ خطر را به صدا در آورید.
همانطور که بدهی بیش از حد باعث ورشکستگی میشود و وزن زیاد هم برای بدن شما خوب نیست ، بدهی فنی هم می تواند توسعه ی پروژه را غیر ممکن کند و هزینه ی حفظ و نگه داری را بیش از حد بالا ببرد. تا جایی که مجبور میشوید پروژه را رها کنید یا آن را از نو پیاده کنید.
بدهی فنی یا Technical Debt زمانی پیش می آید که بجای راه درست راه سریع را در پیش میگیرید. راه درست در بسیاری موارد طولانی و پیچیده است و شما خسته هستید،حوصله ندارید یا عجله دارید، پس سعی میکنید از راه میانبر بروید و با سرهم بندی مشکل را حل کنید.
ممکن است انتخاب راه میانبر از روی نادانستن باشد. اما معمولا این انتخاب عمدی است. محدودیت پول و زمان ، فشار کارفرما و یا باگ می تواند شما را به مسیر میانبر هدایت کند. وقتی سایت شما با هزاران کاربر ناگهان کرش میکند چیزی که اهمیت دارد آنلاین شدن مجدد پروژه است. با خود میگوید بعدا برمیگردم و اصلاح میکنم. اینجاست که بدهکار میشوید. بدهی مانند لایه های چربی دور شکم پروژه ی جمع میشود و آن را سنگین و مریض میکند.
هر چقدر پروژه بزرگتر باشد بدهی فنی با سرعت بیشتری بالا میرود. وقتی از برنامه عقب باشید اعضای تیم شروع به میانبر زدن میکنند و رهگیری همه آنها برای مدیر پروژه غیر ممکن است.
بدهی فنی لزوما بد نیست. در بسیاری از موارد چاره ای جز بدهکار شدن ندارید. مهم این است که :
1- بدانید کجا در حال میانبر زدن هستید.
2- آمار آن را به خوبی نگه دارید و هر وقت میانبر زدید جایی ثبت کنید.
3- همه روزه بخشی از زمان خود را صرف از بین بردن بدهی های قبلی کنید.
4- هیچوقت اجاز ندهید میزان بدهی فنی از 20 درصد کل پروژه بیشتر شود.
هر چه میزان بدهی بالا رود توسعه ی پروژه در درازمدت سخت تر میشود. خیلی زود مجبور میشوید روی میانبر های قبل میانبر های جدید پیاده کنید. آن وقت است که باید زنگ خطر را به صدا در آورید.
همانطور که بدهی بیش از حد باعث ورشکستگی میشود و وزن زیاد هم برای بدن شما خوب نیست ، بدهی فنی هم می تواند توسعه ی پروژه را غیر ممکن کند و هزینه ی حفظ و نگه داری را بیش از حد بالا ببرد. تا جایی که مجبور میشوید پروژه را رها کنید یا آن را از نو پیاده کنید.
نصب و راه اندازی dotnet watch
ابتدا باید بگم اگر سیستم شما دارای پردازنده ی سریع و رم بالایی نیست این ابزار کندتر از انتظار کار میکند. به نظر میرسه در نسخه ی 2.1 با تکنیک جدید بیلد سرعت این ابزار هم بیشتر باشه . قعلا باید منتظر نسخه ی بعدی باشیم.
برای نصب این ابزار کافیه پکیج Microsoft.DotNet.Watcher.Tools رو به پروژه اضافه کنید. البته مانند همه ی ابزار باید از طریق فایل csproj این کار را انجام دهید. خط زیر رو به فایل اضافه کنید :
<ItemGroup
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
</ItemGroup>
بعد از تغییر فایل csproj مطمئن شوید پکیج ها restore شوند. سپس برای فعال کردن سیستم watch کافی است در cmd به مسیر پروژه بروید و دستور dotnet watch run را اجرا کنید.
حالا بعد از هر تغییر در فایلهای cs بلافاصله سیستم متوجه میشه و پروژه رو مجدد بیلد میکنه. خوبه که یکبار امتحان کنید و سرعتش رو روی سیستم خودتون بررسی کنید.اطلاعات بیشتر در لینک زیر موجود است :
https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
ابتدا باید بگم اگر سیستم شما دارای پردازنده ی سریع و رم بالایی نیست این ابزار کندتر از انتظار کار میکند. به نظر میرسه در نسخه ی 2.1 با تکنیک جدید بیلد سرعت این ابزار هم بیشتر باشه . قعلا باید منتظر نسخه ی بعدی باشیم.
برای نصب این ابزار کافیه پکیج Microsoft.DotNet.Watcher.Tools رو به پروژه اضافه کنید. البته مانند همه ی ابزار باید از طریق فایل csproj این کار را انجام دهید. خط زیر رو به فایل اضافه کنید :
<ItemGroup
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
</ItemGroup>
بعد از تغییر فایل csproj مطمئن شوید پکیج ها restore شوند. سپس برای فعال کردن سیستم watch کافی است در cmd به مسیر پروژه بروید و دستور dotnet watch run را اجرا کنید.
حالا بعد از هر تغییر در فایلهای cs بلافاصله سیستم متوجه میشه و پروژه رو مجدد بیلد میکنه. خوبه که یکبار امتحان کنید و سرعتش رو روی سیستم خودتون بررسی کنید.اطلاعات بیشتر در لینک زیر موجود است :
https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
Docs
Develop ASP.NET Core apps using a file watcher
This tutorial demonstrates how to install and use the .NET Core CLI's file watcher (dotnet watch) tool in an ASP.NET Core app.
میزان دانلود فریم ورک ReactJS در مقایسه با Angular و VueJS بسیار بیشتر است و عملا می توان گفت گوگل رقابت را به فیس بوک باخته است.
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
چرا انگولار محبوبیتش را از دست داد ؟
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.