مطالب
رفع مشکل تبدیلات UTC با تغییر اطلاعات TimeZone ایران در ویندوز
در سال جدید، حتی اگر گزینه‌ی daylight saving time را در تنظیمات ویندوز غیرفعال کنید:


با اجرای قطعه کد زیر که سعی می‌کند DateTimeOffset.UtcNow را بر اساس اطلاعات منطقه‌ی زمانی ایران، به زمان محلی تبدیل کند:
var iranStandardTime = TimeZoneInfo.GetSystemTimeZones()
                                       .FirstOrDefault(timeZoneInfo =>
                                                           timeZoneInfo.StandardName.Contains("Iran",
                                                            StringComparison.OrdinalIgnoreCase));
Console.WriteLine(iranStandardTime.BaseUtcOffset); // 03:30:00

var dateTime = DateTimeOffset.UtcNow;
var iranTime = TimeZoneInfo.ConvertTime(dateTime, iranStandardTime);
Console.WriteLine(iranTime); // 06/02/1402 12:34:23 ?.? +04:30 --> this is coming from the `adjustment rules`
باز هم در خروجی، درنظر گرفته شدن 4:30+ مشخص است و به همین جهت در تبدیل صورت گرفته، ساعت نهایی، یک ساعت جلوتر از ساعت واقعی خواهد بود. علت آن هم به مفهوم dynamic daylight saving time برمی‌گردد که اطلاعات بیشتر آن‌را در این مطلب می‌توانید مطالعه کنید.

دات نت نیز در پشت صحنه، همین اطلاعات را دریافت و تحت عنوان Adjustment rules، مورد استفاده قرار می‌دهد:


همانطور که مشاهده می‌کنید، آخرین گزینه‌ی پویای آن به بازه‌ی زمانی 1402 تا سال 9378 تنظیم شده‌است و در طی این بازه، دات نت هنوز همان 4:30+ را جهت تبدیلات منطقه‌ی زمانی ایران به رسمیت می‌شناسد؛ مگر اینکه در به‌روز رسانی‌های بعدی ویندوز، این مشکل برطرف شود و یا ... می‌توانید از این وصله، جهت رفع این مشکل استفاده کنید:


پس از افزودن اطلاعات این فایل رجیستری به ویندوز، نه فقط daylight saving time غیرفعال می‌شود، بلکه اجزای dynamic daylight saving time نیز از سال 2023 به بعد، غیرفعال خواهند شد و اینبار دات نت، سال 1401 را سال آخر تنظیمات ساعت تابستانی درنظر می‌گیرد:


مابقی موارد در اینجا ذکر نشده‌اند، چون به عنوان ورودی دارای daylight saving time غیرفعال تشخیص داده می‌شوند.

اکنون اگر مجددا همان مثال ابتدای بحث را اجرا کنیم، بجای 4:30، عدد 3:30 قابل مشاهده است.
 

اشتراک‌ها
انتشار نسخه 5.0.0 Swashbuckle.AspNetCore

This release contains a number of significant changes, including a transition to Swagger/OpenAPI v3 and support for ASP.NET Core 3.0, and will require modifications to your application setup if you're upgrading from previous major versions. 

انتشار نسخه 5.0.0 Swashbuckle.AspNetCore
اشتراک‌ها
اضافه شدن قابلیت Package Registry به Github

Today, we’re excited to introduce GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code.

GitHub Package Registry is fully integrated with GitHub, so you can use the same search, browsing, and management tools to find and publish packages as you do for your repositories. You can also use the same user and team permissions to manage code and packages together. GitHub Package Registry provides fast, reliable downloads backed by GitHub’s global CDN. And it supports familiar package management tools: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), and Docker images, with more to come.

اضافه شدن قابلیت Package Registry به Github
اشتراک‌ها
نگاهی به PHP در سال 2019
  • PHP is actively developed with a new release each year
  • Performance since the PHP 5 era has doubled, if not tripled
  • There's a extremely active eco system of frameworks, packages and platforms
  • PHP has had lots of new features added to it over the past few years, and the language keeps evolving
  • Tooling like static analysers has matured over the past years, and only keeps growing 
نگاهی به PHP در سال 2019
بازخوردهای دوره
مدیریت استثناءها در حین استفاده از واژه‌های کلیدی async و await
همانطور که در بالا اشاره کردید "در مثال فوق، نحوه‌ی ترکیب دو Task را توسط Task.WhenAll .... "در برخی موارد استفاده از async باعث افزایش کارآیی نیز می‌شود، آیا در موردی که مثلا من در یک اکشن برای انجام کاری نیاز به 4 درخواست  مجزا به دیتابیس دارم و بعد از گرفتن نتیجه این 4 درخواست می‌توانم درخواست نهایی را به دیتابیس بفرستم، استفاده از async باعث افزایش کارایی نیز می‌شود ؟
برای تشریح بهتر من نتیجه تست خود را اضافه میکنم. من از mvc5 و EF6  database first استفاده کردم.
حالت sync :
var watch = Stopwatch.StartNew();

 int actionId = db.CF_AccessLevel.Where(a => a.Name.ToLower().Trim() == "Edit").Select(a => a.CF_AccessLevelId).Single();

 int moduleItemId = db.CF_ModuleItem.Where(m => m.Title.ToLower().Trim() == "license".ToLower().Trim()).Select(m => m.CF_ModuleItemId).Single();

 int groupRoleId = db.Users.Where(u => u.UserId == 1).Select(u => u.UserRoleId).Single();

watch.Stop();
 var elapsedMs = watch.ElapsedMilliseconds;

حالت async:
var watch = Stopwatch.StartNew();
 var something = Task<int>.Factory.StartNew(() => db.CF_AccessLevel.Where(a => a.Name.ToLower().Trim() == "Edit").Select(a => a.CF_AccessLevelId).Single());
something.Wait();
int actionId = something.Result;

var something1 = Task<int>.Factory.StartNew(() => db.CF_ModuleItem.Where(m => m.Title.ToLower().Trim() == "license".ToLower().Trim()).Select(m => m.CF_ModuleItemId).Single());
 something1.Wait();
 int moduleItemId = something1.Result;

var something2 = Task<int>.Factory.StartNew(() => db.Users.Where(u => u.UserId == 1).Select(u => u.UserRoleId).Single());
 something2.Wait();
 int groupRoleId = something2.Result;
 watch.Stop();
 var elapsedMs = watch.ElapsedMilliseconds;
در هر  حالت بعد از انجام  3 درخواست ، درخواست نهایی را به سرور میفرستم (در کدهای بالا موجود نیست)
و نتیجه با جزئیات را در آخر اضافه کرده ام :
اما خلاصه میانگین روش sync 222 ms و روش async 191.75ms می‌باشد حدود 35.25ms تفات وجود دارد.
حال آیا تفاوت معنی دار می‌باشد؟ آیا کد async نوشته شده صحیح است؟ اگر صحیح نیست چه روشی صحیح میباشد؟ اگر نباید از async استفاده شود چه روشی بهتر است؟
همانطور که از کد مشخص است برای هدف authorization  نوشتم، ولی اگر بخواهم به صورت async در فیلتر استفاده کنم امکانپذیر نیست ، آیا راهی وجود دارد برای استفاده از async در فیلتر سفارشی توی    mvc5 ؟
202  221
 179 226
 198 208
 197  219
 188  245
 195  207
 193  217
 187  220
 171  212
 227  215
 177  312
 187  222
 191.75  227
   
اشتراک‌ها
درک بهتر this در JavaScript

A lot of time this keyword was a mystery for me and many starting JavaScript developers. It is a
powerful feature, but requires efforts to be understood


درک بهتر this در JavaScript
اشتراک‌ها
رونمایی از Windows Compatibility Pack for .NET Core

Porting existing code to .NET Core used to be quite hard because the available API set was very small. In .NET Core 2.0, we already made this much easier, thanks to .NET Standard 2.0. Today, we’re happy to announce that we made it even easier with the Windows Compatibility Pack, which provides access to an additional 20,000 APIs via a single NuGet package. 

رونمایی از Windows Compatibility Pack for .NET Core
اشتراک‌ها
NET Core 3.1. تا یک ماه دیگر ارائه خواهد شد
Milestone Release Date
.NET Core 2.2.x, 2.1.x, 1.x (servicing) Approximately every 1-2 months or as needed (see also releases)
.NET Core 3.0 Preview releases
RC (Release Candidate) released in September 2019 (Preview 9)
GA (General Availability) released on September 23, 2019
.NET Core 3.1 LTS (Long Term Support) release, scheduled for November 2019
.NET 5.0 Release scheduled for November 2020
.NET 6.0 LTS (Long Term Support) release, scheduled for November 2021
.NET 7.0 Release scheduled for November 2022
.NET 8.0 LTS (Long Term Support) release, scheduled for November 2023

NET Core 3.1. تا یک ماه دیگر ارائه خواهد شد