- درباره CDN | it-rasht.blogfa.com
- Introducing the Xamarin Mobile API | blog.xamarin.com
- استفاده از GZip جهت فشرده سازی رشتهها | samondotnet.blogspot.com
- ایجاد تصاویر panorama | www.codeproject.com
- ایجاد سادهتر فایلهای CSS توسط انتخاب کنندهی رنگ | www.dailydotnettips.com
- ساعتی با طراحی جالب | qlocktwo.com
اشتراکها
نگاهی به زبان Dart
اشتراکها
طراحی متریال گوگل، خوب یا بد
این قهرمان ما از سال ۲۰۰۲ سفر خودش را همراه با 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)
سال ۲۰۱۵ سیشارپ ۶ همراه با Visual Studio 2015 وارد بازار شد. اینبار سیشارپ شروع به اعمال تغییراتی کرد که عمدتا با ذهنیت کد تمیز و ساده همراه بود. از جملهی این تغییرات مهم، بازنویسی کامل کامپایلر، با خود زبان سیشارپ بود.
عصر چهارم: رضایت طرفداران کد تمیز و ساده
شروع تغییرات کوچک، در ورژن ۶ سیشارپ بود؛ ولی از ورژن ۷ به بعد، مایکروسافت تمرکز خیلی بیشتری را بر روی این کار گذاشت و تغییراتش همگی دارای یک هدف مهم بودند. آسان و تمیز بودن کدها؛ امکاناتی از قبلی tuple,out,ref و ... از جمله این تغییرات بودند.
عصر پنجم: دنیای Cross-Platform، خداحافظی با NullReferenceException و تلاش برای شبیه شدن به زبانهای اسکریپت نویسی
سالها برنامه نویسها با خطای NullReferenceException دست و پنجه نرم میکردند، ولی حالا با استفادهی درست از قابلیت Nullable reference typeها میشد تا حد قابل قبولی جلوی این اتفاق را گرفت. در ادامه تغییرات به سمتی میرفت که زبان سیشارپ را شبیه به یک زبان اسکریپت نویسی کرده بود. حالا میشد بدون تعریف کلاس و متد خاصی، دستور سادهای را اجرا کرد. همچنین قابلیتهایی که در pattern matching به سیشارپ اضافه شد، باعث سادهتر و قابل فهمتر شدن سیشارپ میشد.
نقشهی راه تصویری پیشرفت سیشارپ
با توجه به ماهیت چندسکویی NET 5.، در اکثر سیستمهای ویندوزی، سرویس بومی سازی، بر اساس استاندارد NLS کار میکند، اما در سیستمهای لینوکسی و مبتنی بر یونیکس، این استاندارد از نوع ICU است (و وجود و تنظیم آنها خارج از NET. و توسط سیستم عامل مدیریت میشود). جهت یکدست سازی این دو نوع سیستم بومی سازی در دات نت، از نگارش 5 آن به بعد، استاندارد ICU که به صورت گستردهتری مورد پذیرش قرار گرفتهاست، استاندارد بومی سازی پیشفرض دات نت درنظر گرفته میشود؛ مگر اینکه سیستم عاملی آنرا پشتیبانی نکند.
کدام نگارش از ویندوز، از ICU پشتیبانی میکند؟
تمام ویندوزهای پس از Windows 10 May 2019 Update، به همراه icu.dll، به عنوان جزء استاندارد سیستم عامل هستند. بنابراین دات نت 5 و نگارشهای پس از آن، در این سیستم عاملها، از سرویس بومی سازی ICU استفاده خواهند کرد؛ اما اگر از نگارشهای پیشین ویندوز استفاده میکنید، به اجبار به سیستم NLS سوئیچ خواهد شد.
تاثیر ICU بر برنامههای دات نت 5 به بعد
قطعه کد زیر را درنظر بگیرید:
در نگارشهای پیش از 5 دات نت، خروجی کدهای فوق، عدد 6 است؛ اما ... اما ... (!) از زمان دات نت 5 به بعد، خروجی آن «منهای یک» است! البته به شرطی که آخرین به روز رسانی ویندوز 10 را نصب کرده باشید؛ یعنی حداقل Windows 10 May 2019 Update را داشته باشید.
حالت «پیشفرض» جستجو و مقایسهی رشتهها در دات نت 5 به بعد، یک مقایسهی مبتنی بر «دستورات زبانی» بر اساس فرهنگ تنظیم شدهی در Thread جاری برنامهاست (یا همان System.Threading.Thread.CurrentThread.CurrentCulture).
چرا متدهای کار بر روی رشتهها در دات نت 5 به بعد، نسبت به نگارشهای قبلی متفاوت عمل میکنند؟
زمانیکه متدی مانند IndexOf فراخوانی میشود، هدف عمدهی برنامهنویسها، یک جستجوی Ordinal است (یعنی مقایسهی کاراکتر به کاراکتر؛ بدون درنظر گرفتن نکات زبانی و بومی)؛ اما فراموش میکنند که این متدها دارای پارامتر دومی هم هستند که از نوع StringComparison است و سالها است که توصیه میشود این پارامتر را هم به صورت صریحی مقدار دهی کنید تا هدف خود را از نوع جستجو دقیقا مشخص نمائید. از زمان دات نت 5 به بعد، اگر این پارامتر را مشخص نکنید، جستجوی صورت گرفته یک رفتار culture-specific را خواهد داشت و نه Ordinal. از این لحاظ مقایسهی رشتهها توسط استانداردهای ICU و NLS، بر اساس پیاده سازیهای مختلف زبانشناسی، خروجیهای یکسانی را ارائه نمیدهند و به همین جهت است که اینبار خروجی منهای یک را دریافت میکنیم.
یک نکته: خروجی قطعه کد فوق در سیستمهای لینوکسی که از .NET Core 2x - 3x. هم استفاده میکنند، دقیقا منهای یک است؛ چون پیشفرض بومی سازی آنها نیز ICU است.
چگونه میتوان به همان حالت پیشین مقایسهی رشتهها در NET. بازگشت؟
مایکروسافت بستهی نیوگت Microsoft.CodeAnalysis.FxCopAnalyzers را جهت گوشزد کردن نکتهی ذکر صریح StringComparison، به روز رسانی کردهاست. بنابراین بهتر است تا آنرا به پروژهی خود اضافه کنید. در این حالت اخطارهای مناسبی را جهت یافتن قسمتهای مشکلدار برنامهی خود دریافت میکنید. برای مثال برای اینکه در قطعه کد فوق به همان پاسخ متداول 6 برسیم، تنها کافیاست پارامتر دوم StringComparison را ذکر کنیم:
و یا حتی میتوانید فایل csproj پروژهی خود را ویرایش کرده و یک سطر زیر را به آن اضافه کنید:
در این حالت کل برنامهی شما بدون هیچ تغییری مانند قبل کار کرده و از سیستم NLS استفاده میشود.
کدام متدهای کار با رشتهها در دات نت 5، تحت تاثیر این تغییرات قرار گرفتهاند؟
اگر از متدهای زیر در برنامههای خود استفاده میکنید، نکتهی ذکر پارامتر StringComparison.Ordinal را فراموش نکنید:
سؤال: اگر متدی پارامتر دوم StringComparison را نداشت چطور؟
اگر به ماخذ «Behavior changes when comparing strings on .NET 5» مراجعه کنید، در انتهای آن جدولی را ارائه داده که دو سطر اول آن، به صورت زیر است:
در این جدول، هر متدی که رفتار پیشفرض آن از نوع CurrentCulture است، تحت تاثیر قرار گرفتهاست و متدی مانند string.Contains که رفتار پیشفرض آن Ordinal است، از این تغییرات مصون است و نیازی به تغییری ندارد.
برای مطالعهی بیشتر:
Behavior changes when comparing strings on .NET 5+
.NET globalization and ICU.
Globalization breaking changes
بحث و گفتگویی در این مورد
کدام نگارش از ویندوز، از ICU پشتیبانی میکند؟
تمام ویندوزهای پس از Windows 10 May 2019 Update، به همراه icu.dll، به عنوان جزء استاندارد سیستم عامل هستند. بنابراین دات نت 5 و نگارشهای پس از آن، در این سیستم عاملها، از سرویس بومی سازی ICU استفاده خواهند کرد؛ اما اگر از نگارشهای پیشین ویندوز استفاده میکنید، به اجبار به سیستم NLS سوئیچ خواهد شد.
تاثیر ICU بر برنامههای دات نت 5 به بعد
قطعه کد زیر را درنظر بگیرید:
string s = "Hello\r\nworld!"; int idx = s.IndexOf("\n"); Console.WriteLine(idx);
حالت «پیشفرض» جستجو و مقایسهی رشتهها در دات نت 5 به بعد، یک مقایسهی مبتنی بر «دستورات زبانی» بر اساس فرهنگ تنظیم شدهی در Thread جاری برنامهاست (یا همان System.Threading.Thread.CurrentThread.CurrentCulture).
چرا متدهای کار بر روی رشتهها در دات نت 5 به بعد، نسبت به نگارشهای قبلی متفاوت عمل میکنند؟
زمانیکه متدی مانند IndexOf فراخوانی میشود، هدف عمدهی برنامهنویسها، یک جستجوی Ordinal است (یعنی مقایسهی کاراکتر به کاراکتر؛ بدون درنظر گرفتن نکات زبانی و بومی)؛ اما فراموش میکنند که این متدها دارای پارامتر دومی هم هستند که از نوع StringComparison است و سالها است که توصیه میشود این پارامتر را هم به صورت صریحی مقدار دهی کنید تا هدف خود را از نوع جستجو دقیقا مشخص نمائید. از زمان دات نت 5 به بعد، اگر این پارامتر را مشخص نکنید، جستجوی صورت گرفته یک رفتار culture-specific را خواهد داشت و نه Ordinal. از این لحاظ مقایسهی رشتهها توسط استانداردهای ICU و NLS، بر اساس پیاده سازیهای مختلف زبانشناسی، خروجیهای یکسانی را ارائه نمیدهند و به همین جهت است که اینبار خروجی منهای یک را دریافت میکنیم.
یک نکته: خروجی قطعه کد فوق در سیستمهای لینوکسی که از .NET Core 2x - 3x. هم استفاده میکنند، دقیقا منهای یک است؛ چون پیشفرض بومی سازی آنها نیز ICU است.
چگونه میتوان به همان حالت پیشین مقایسهی رشتهها در NET. بازگشت؟
مایکروسافت بستهی نیوگت Microsoft.CodeAnalysis.FxCopAnalyzers را جهت گوشزد کردن نکتهی ذکر صریح StringComparison، به روز رسانی کردهاست. بنابراین بهتر است تا آنرا به پروژهی خود اضافه کنید. در این حالت اخطارهای مناسبی را جهت یافتن قسمتهای مشکلدار برنامهی خود دریافت میکنید. برای مثال برای اینکه در قطعه کد فوق به همان پاسخ متداول 6 برسیم، تنها کافیاست پارامتر دوم StringComparison را ذکر کنیم:
int idx = s.IndexOf("\n", StringComparison.Ordinal);
و یا حتی میتوانید فایل csproj پروژهی خود را ویرایش کرده و یک سطر زیر را به آن اضافه کنید:
<ItemGroup> <RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" /> </ItemGroup>
کدام متدهای کار با رشتهها در دات نت 5، تحت تاثیر این تغییرات قرار گرفتهاند؟
اگر از متدهای زیر در برنامههای خود استفاده میکنید، نکتهی ذکر پارامتر StringComparison.Ordinal را فراموش نکنید:
System.String.Compare System.String.EndsWith System.String.IndexOf System.String.StartsWith System.String.ToLower System.String.ToLowerInvariant System.String.ToUpper System.String.ToUpperInvariant System.Globalization.TextInfo (most members) System.Globalization.CompareInfo (most members) System.Array.Sort (when sorting arrays of strings) System.Collections.Generic.List<T>.Sort() (when the list elements are strings) System.Collections.Generic.SortedDictionary<TKey,TValue> (when the keys are strings) System.Collections.Generic.SortedList<TKey,TValue> (when the keys are strings) System.Collections.Generic.SortedSet<T> (when the set contains strings)
سؤال: اگر متدی پارامتر دوم StringComparison را نداشت چطور؟
اگر به ماخذ «Behavior changes when comparing strings on .NET 5» مراجعه کنید، در انتهای آن جدولی را ارائه داده که دو سطر اول آن، به صورت زیر است:
API Default behavior Remarks string.Compare CurrentCulture
برای مطالعهی بیشتر:
Behavior changes when comparing strings on .NET 5+
.NET globalization and ICU.
Globalization breaking changes
بحث و گفتگویی در این مورد
نظرات مطالب
روش بهینه نمایش عکس در Xamarin Forms
آیا برای برنامههای موبایل هیبریدی هم راه حلی دارید ؟
قسمت پنجم
17. پرهیز از استفاده نسخه debug
وقتی به ASP.NET مراجعه میکنید، توجه فرمایید که از چه نوع build برای محصول نهایی استفاده میکنید. وقتی از نسخه debug برنامه استفاده میکنید، بهبود دهندههای سطح کامپایلر عمل نکرده و کدشما در حالت بهینه اجرا نخواهد شد (کد شما همانگونه که هست اجرا میشود!).
برای مثال هنگامی که از نسخه release استفاده میکنید، کامپایلر c# به صورت خودکار از StringBuilderها به جای تلفیق عادی رشته ها، از آرایهها به جای لیست ها، از دستور switch/case به جای دستورات if/then/else، تلفیق شروط با یکدیگر و... استفاده کرده و کد شما را در حالت بهینهتری اجرا میکند. عدم استفاده از این نسخه شما را از این مزایا محروم میسازد و نرم افزار شما به کندی اجرا خواهد شد. البته ناگفته نماند این موضوع فقط باید برای محصول نهایی استفاده شود و جهت دیباگ کردن برنامه همچنان باید از نسخه debug استفاده نمایید.
توجه نمایید میتوانید با استفاده از متغیرهای کامپایلر در کد خود بخشی از کد را مختص build خاصی از برنامه کنید. مثلا اگر برنامه در حال debug کامپایل شد، MiniProfiler را فعال کن در غیر این صورت غیر فعال باشد.
#if DEBUG //فعال کردن MiniProfiler #endif18.تنظیم دقیق لاگهای سیستم در محیط اجرا
وقتی محصول نهایی را آماده میکنید، فراموش نکنید که سطح لاگ گیری را در سطح مطلوبی قرار دهید تا بتوانید در صورت نیاز برنامه را اشکال زدایی کنید. البته زیاده روی در این مورد نیز میتواند مشکل زا باشد.
اکثر برنامه نویسان هنگامی که محصول نهایی را برای مشتری آماده میکنند، لاگ را غیر فعال میکنند تا کاربر سرعت بیشتری را تجربه کند. این سیاست غلط شما را از امکانات بی نظیر لاگ کردن (مانند وقابع نگاری امنیتی، رفع سریع مشکلات و...) محروم میسازد. بنابر این حتما سیستم لاگ خود را در زمان تولید محصول اصلی (و نصب بر روی سرور اصلی) در حالت متعادلی تنظیم نمایید. کمی تست و تجربه شما را در این امر یاری میکند.
19.مشخص کردن اندازه عکس
مشخص کردن اندازه عکس در تک img به صورت css یا attribute باعث میشود که همان اولین بار که صفحه رندر میشود، اندازه مورد نیاز عکس به آن اختصاص یابد تا در صورت دانلود سریعا جایگرین آن گردد. عدم مشخص کردن سایز عکس (طول و عرض) باعث رندر شدن مجدد تمامی المانهای صفحه بعد از دانلود هر عکس از سرور میشود و منابع با ارزش cpu کاربر شما را به سادگی از بین میبرد.
<img src="smiley.gif" alt="Smiley face" height="42" width="42">