دات نت محلی (NET Native)

وقتی با دات نت 1 تا 4.6 کار می کنید کدها بعد از کامپایل به زبان ماشین ترجمه نمی شوند بلکه به یک زبان میانه (Intermediate Language) تبدیل می شوند. وقتی برنامه را اجرا می کنید دات نت این زبان میانی را در لحظه به زبان ماشین تبدیل می کند که به این عمل ترجمه ی لحظه ای یا Just in time Compile گفته می شود. این عمل در بهینه سازی حجم فایلها و سرعت اجرا برنامه بسیار موثر است.

اما با ظهور گوشی های هوشمند و تبلت ها و با توجه به منابع محدود این دو استفاده از ترجمه ی لحظه ای روش مناسبی نیست و کارایی لازم را ندارد. در دات نت محلی یا Native با استفاده از عمل Ahead of time compile یا ترجمه ی پیاپیش کدها مستقیما به زبان ماشین تبدیل میشوند و زبان میانه حذف میشود .

کجاها می توانید از EF Core استفاده کنید ؟

https://github.com/codehaks/FileManagerDemo

پروژه ی نمونه ی کار با فایل و آپلود و دانلود در ASP MVC Core 2.0

آیا Stored Procedure از LINQ سریعتر است ؟

اخیرا در یک پروژه ی قدیمی از من خواسته شد سرعت تولید گزارشات را بالا ببرم.اجرای آن بیش از 5 دقیقه طول می کشید. مشکل اصلی این بود که بخش اصلی گزارش ها با SP برنامه نویسی شده بود . بعد از بررسی دقیق سورسها ساده ترین راهی که به نظرم رسید بازنویسی آن با LINQ درون #C بود. خروجی کار نتیجه ی جالب توجهی داشت. حالا گزارش در کمتر از 5 ثانیه تولید میشد. این یعنی سرعت کار بیش از 300 برابر شده بود.

جواب کوتاه سوال "بله" است. SQL دارای مکانیزم هایی است که به SP امکان میدهد همیشه چند برابر از LINQ یا Query های خارجی سریعتر عمل کند. اما سرعت همیشه ملاک برتری یک روش نیست. نوشتن SP نیاز به تخصص در T-SQL دارد. مهارتی میطلبد که خیلی از برنامه نویسان وب ندارند. خیلی راحت میتوانید یک SP بد بنویسید که از صد LINQ کندتر کار کند.

مسئله ی دیگر بروز رسانی و تغییر SP ها است. مدیریت کردن SP ها در درازمدت بسیار سخت تر از LINQ است. در بسیاری موارد زمان اجرای Query ها کسری از ثانیه است در نتیجه استفاده از SP چیز زیادی به سرعت سیستم اضافه نمیکند.

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

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

آمارهای مایکرسافت می گوید در حال حاضر بیش از نیم میلیون برنامه نویس از Net Core استفاده می کنند و استفاده از Core 2.0 پیشرفت چشم گیری داشته است.

طبق اعلام Scott Hunter مدیر پروژه ی Net Core پیش نمایس نسخه 2.1 این فریم ورک تا آخر این ماه عرضه میشود. او همچنین پیش بینی میکند نسخه ی اصلی2.1 تا تابستان آماده شود.

هنر بریدن ، چیدن و کوتاه کردن

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

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

سایت محصولات یکبار تولید نیست. ساده ترین سایت هم نیاز به بروز رسانی دارد. حتی اگر تکنولوژی تغییر نکند ، آمار بازدید زیاد نشود یا حادثه برای سرور رخ ندهد، خود کار فرما ایده های جدیدی خواهد داشت.

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

مقایسه زمان Build شدن ASP Core بین نسخه ی 2.0 و 2.1

بهبود روی پروژه های بزرگ (WebLarge) بسیار زیاد است. برای تست از Orchard CMS استفاده شده است.

مراحل توسعه و انتشار نرم افزار

وب اسمبلی استاندارد جدیدی است که امکان اجرای کد Nativeدر مرورگر را فراهم میکند. به زودی می توانید بجای جاوا اسکریپت با #C برای کلاینت برنامه نویسی کنید.

فریم ورک Blazor

فریم ورک Blazor یک پروژه ی آزمایشی است که به تازگی به ASP اضافه شده و امکان استفاده از Web Assembly در دات نت را فراهم میکند. تمام مرورگرهای جدید از Web Assembly پشتیبانی می کنند. در نتیجه می توانید برنامه ی کلاینتی بنویسید که مانند جاوا اسکریپت به رویدادهای موس و کیبورد واکنش میدهد در کلاینت اجرا میشود.

نسخه ی آزمایشی این فریم ورک قابلیت دیباگ و Live Reloading دارد همچنین به شما امکان میدهد کامپوننت هایی بنویسید که به صورت تو در تو به هم وابستگی دارند. ابزاری مانند Dependency Injection و Server-Side Rendering هم در آن گنجاده خواهد شد.

یکی از جالبترین قابلیت های این فریم ورک امکان اجرای دستورات جاوا اسکریپت از درون #C است. حجم فریم ورک در حدود 400 کیلوبایت است که به همراه اولین بارگذاری صفحه دانلود میشود. در صورت عدم پشتیبانی مرورگر از Web Assembly یک فایل جاوا اسکریپت اجرای کدهای #C را شبیه سازی میکند. پس برنامه ی شما روی مرورگرهای قدیمی هم بدون مشکل اجرا خواهد شد.

جهت دانلود و نصب قالب نمونه می توانید به آدرس زیر مراجعه کنید :

https://github.com/aspnet/blazor

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

معرفی Technical Debt

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

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

هر چقدر پروژه بزرگتر باشد بدهی فنی با سرعت بیشتری بالا میرود. وقتی از برنامه عقب باشید اعضای تیم شروع به میانبر زدن میکنند و رهگیری همه آنها برای مدیر پروژه غیر ممکن است.

بدهی فنی لزوما بد نیست. در بسیاری از موارد چاره ای جز بدهکار شدن ندارید. مهم این است که :

1- بدانید کجا در حال میانبر زدن هستید.
2- آمار آن را به خوبی نگه دارید و هر وقت میانبر زدید جایی ثبت کنید.
3- همه روزه بخشی از زمان خود را صرف از بین بردن بدهی های قبلی کنید.
4- هیچوقت اجاز ندهید میزان بدهی فنی از 20 درصد کل پروژه بیشتر شود.

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

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