اشتراک‌ها
گیت هاب ! ( GitHub ) شبکه اجتماعی برنامه نویسان

برای خیلی ممکن است سوال پیش آمده باشد چطور یک برنامه نویس از پروژه ای که به صورت اوپن سورس منتشر میکند محافظت کرده و از سوء استفاده جلوگیری میکند ؟ بر اساس همین سوال شخص لینوس توروالدز Git را ایجاد کرد برای ذخیره پروژه‌های متن باز و حفظ حقوق برنامه نویس پروژه

سایت گیت هاب (github.com) بر پایه Git تشکیل شده و به همین منظور استفاده میشود. البته برنامه نویس میتواند پروژه را بصورت خصوصی ذخیره کند و از انتشار عمومی پروژه خودداری کند. با استفاده از این سیستم برنامه نویسان پروژه‌های متن باز را با خیال راحت و با حفظ حقوق منتشر کنند و به این ترتیب پروژه به نام آن برنامه نویس ثبت خواهد شد. در این سیکل برنامه نویس یک اکانت در این سایت ایجاد و برای هر پروژه متن باز که منتشر میکند یک صفحه (مخزن) ساخته و پروژه را در آن ذخیره میکند.

یکی دیگر از مواردی که ممکن است برای برنامه‌های متن باز پیش بیاید این است که اگر برنامه نویسی یک پروژه متن باز را از گیت هاب توسعه داد ، موارد اضافه شده بر عهده برنامه نویس اول گذاشته نشه و حق برنامه نویس اصلی رعایت شود ؛ برای این منظور سیکلی در سایت گیت هاب ایجاد شده با عنوان Forking که یک برنامه نویس میتواند پروژه را داشته باشد و پس از توسعه پروژه ، تغییرات ایجاد شده در برنامه را به برنامه نویس اصلی ارسال کند و پس از تایید ، تغییرات ایجاد شده در مخزن اصلی پروژه اعمال شود.

گیت هاب امکانات بیشتری را در خود پیاده کرده که این سایت را تبدیل به شبکه اجتماعی برای برنامه نویسان کرده است. موارد از قبیل انجمن برای پرسش و مشکلات ، ارسال پیغام خصوصی برای سایر اعضا و ….

گیت هاب ! ( GitHub ) شبکه اجتماعی برنامه نویسان
نظرات مطالب
Blazor 5x - قسمت 21 - احراز هویت و اعتبارسنجی کاربران Blazor Server - بخش 1 - افزودن قالب ابتدایی Identity
یک نکته‌ی تکمیلی: روشی برای عدم استفاده از Razor Pages جهت لاگین کاربران در برنامه‌های Blazor Server

در این سری، از razor pages به همراه قالب پیش‌فرض ASP.NET Core Identity، جهت پیاده سازی ورود کاربران به سیستم، استفاده شده‌است. یعنی کاربر یکبار از فضای Blazor Server خارج شده و وارد یک برنامه‌ی ASP.NET Core Razor Pages معمولی می‌شود؛ لاگین می‌کند (در یک ناحیه‌ی مخصوص razor pages) و سپس مجددا وارد قسمت Blazor Server می‌شود که ... تجربه‌ی کاربری مطلوبی را به همراه ندارد. علت این خروج و ورود را هم در این مطلب می‌توانید مطالعه کنید: «دستیابی به HttpContext در Blazor Server». هدف این بوده که بتوان با استفاده از HttpContext مهیای در razor pages (و نه توسط اتصال web socket یک برنامه‌ی blazor server)، کوکی‌های پس از لاگین موفق را به سمت مرورگر ارسال و ثبت کرد و درگیر مشکلات به همراه دسترسی به HttpContext در برنامه‌های Blazor server نشد.
راه دیگری هم برای مواجه شدن با این مشکل وجود دارد: حذف قسمت razor pages؛ حذف نیاز به خروج و ورود از برنامه‌ی blazor server و ... استفاده از ProtectedBrowserStorage که اکنون جزئی از blazor server استاندارد است؛ جهت ثبت اطلاعات user claims و عدم استفاده از کوکی‌ها که نیاز به دسترسی به HttpContext را دارند. اگر علاقمند به مشاهده‌ی یک مثال کامل در این زمینه هستید، می‌توانید به پروژه‌ی « BlazorServerAuthenticationAndAuthorization   » مراجعه کنید. در اینجا یک CustomAuthenticationStateProvider را به کمک ProtectedSessionStorage طراحی و استفاده کرده تا نیاز به کار با کوکی‌ها برطرف شود و دیگر نیازی به استفاده از razor pages نباشد. البته باید دقت داشت که SessionStorage محدود به tab جاری است و اگر نیاز است اطلاعات آن در تمام برگه‌های باز شده در دسترس باشد، بهتر است از ProtectedLocalStorage استفاده کرد. همچنین باید دقت داشت که چون این protected storageها برای رمزنگاری خودکار اطلاعات از ASP.NET Core data protection API استفاده می‌کنند، نکات مطلب « غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن » نیز در مورد آن‌ها صادق است.
نظرات مطالب
Blazor 5x - قسمت 19 - کار با فرم‌ها - بخش 7 - نکات ویژه‌ی کار با EF-Core در برنامه‌های Blazor Server
خلاصه‌ی بحث جاری به روشی دیگر (مدیریت صحیح طول عمر DbContext در برنامه‌های Blazor Server)

یک روش دیگر مدیریت طول عمر Context در برنامه‌های Blazor Server که تمام نکات این بحث را به نحو ساده‌ای پوشش می‌دهد، به صورت زیر است:
الف) حتما بجای AddDbContext از AddDbContextFactory که در مطلب فوق توضیح داده شد، استفاده کنید تا بتوان هرجائیکه نیاز است یک Context جدید را به صورت دستی ایجاد کرد، تا از به اشتراک گذاری آن و مشکلات مرتبط با طول عمر اینگونه Contextها، مصون ماند:
// Do NOT do this anymore
//services.AddDbContext(o => o.UseSQlite("filename.db"));

// But instead do this:
services.AddDbContextFactory(o => o.UseSQlite("filename.db"));
ب) سپس بجای انواع و اقسام روش‌های مدیریت طول عمر Scoped و سپس Dispose کردن‌ها، آن‌ها را در سرویس‌های برنامه به نحو زیر پیاده سازی و ساده کنید:
public class MyService
{
   private readonly IDbContextFactorey _contextFactory;

   public MyService(IDbContextFactory contextFactory)
   {
      _contextFactory = contextFactory;
   }

   // create a new context for each operation / unit of work
   public async Task DoSomethingAsync()
   {
      using (var ctx = _contextFactory.CreateDbContext())
      {
         // this using clause contains your unit of work
      }
   }
}
در این حالت با استفاده از IDbContextFactory تزریقی، هر جائیکه که نیاز هست، یک Context جدید و همچنین Scoped، ایجاد و همانجا هم در پایان کار، تخریب و Dispose می‌شود و نیازی به پیاده سازی سرویس‌های IDisposable ندارد. این روشی است که در مثال‌های خود مایکروسافت هم مشاهده می‌شود. سپس کار کردن با سرویس فوق، نیازی به نکات مرتبط با inherits OwningComponentBase ندارد و کاملا به همراه injectهای عادی و متداول است. همچنین هم مطمئن هستیم، Context ای که در هر متد استفاده می‌شود، کاملا جدید و غیر اشتراکی است و در پایان کار همان متد، حتما Dispose می‌شود.
نظرات مطالب
روش‌هایی برای بهبود قابلیت دیباگ بسته‌های NuGet
راستش اینا که سهله، قبلا مقالات جامع‌تری رو مطالعه کردم و ایشو‌های sourcelink داخل ریپوی خودش و dotnetsdk رو زیرُ رو کردم.
واقعیت اینه که این قابلیت آنچنان stable و قابل استفاده نیست. توی ورژن‌های مختلف sdk مشکلات متعددی براش پیش اومده و workaround‌های متفاوتی هم براش دادن. 
این موارد رو میشه توی issue معروف این قضیه که بعد از گذشت 3 سال هنوز باز هست مشاهده کنین. انصافا من از بعضی از workaround هاش هم جواب گرفتم ولی همچنان راه سر راست و درست و درمون نداره مگر با اون کدی که فرستادم.
پکیج EFCoreSecondLevelCacheInterceptor  رو روی چندین سیستم هم امتحان کردم و جواب نداد و نهایتا با قرار دادن کد زیر توی csproj (که یکی از workaround‌های همون issue هست) جواب داد. البته اونم رو فقط رو net5.0!
<!-- https://github.com/dotnet/sdk/issues/1458#issuecomment-420456386 -->
<Target Name="_ResolveCopyLocalNuGetPackagePdbsAndXml" Condition="$(CopyLocalLockFileAssemblies) == true" AfterTargets="ResolveReferences">
<ItemGroup>
  <ReferenceCopyLocalPaths
Include="@(ReferenceCopyLocalPaths->'%(RootDir)%(Directory)%(Filename).pdb')"
Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' != '' and Exists('%(RootDir)%(Directory)%(Filename).pdb')" />
  <ReferenceCopyLocalPaths
Include="@(ReferenceCopyLocalPaths->'%(RootDir)%(Directory)%(Filename).xml')"
Condition="'%(ReferenceCopyLocalPaths.NuGetPackageId)' != '' and Exists('%(RootDir)%(Directory)%(Filename).xml')" />
</ItemGroup>
</Target>
در کل چون این یه موضوعی هست که به چندین تیم و محصول وابسته هست (تیم های 
dotnet SDK  و VS و Nuget و  SourceLink) و نیاز به هماهنگی هست متاسفانه خیلی کند پیش میرن و در حال حاضر پلن کردند واسه  milestone دات نت 6 که انشالا برطرف بشه
نظرات مطالب
سری بررسی SQL Smell در EF Core - استفاده از مدل Entity Attribute Value - بخش دوم
نظرات مطالب
استفاده از مسیرهای مطلق در حین import ماژول‌ها در برنامه‌های مبتنی بر TypeScript
خیلی ممنون فکر میکنم حق با شما بود مسیر‌ها رو تغییر دادم و چندین حالت رو امتحان کردم بالاخره کامپایل شد.
ضمن اینکه اینجا یک سری موارد رو میگم شاید بدرد بقیه دوستان هم بخوره اگه به این مشکلات بر خوردن.

اگر پروژه شما به جز فایل tsconfig.json اصلی که در ریشه پروژه هست، دارای فایل‌های tsconfig.app.json و tsconfig.spec.json هم هست، باید مسیرها رو به این صورت تنظیم کنید:
مقدار baseUrl در فایل tsconfig.json برابر با src
مقدار baseUrl در فایل‌های tsconfig.app.json و tsconfig.spec.json برابر با : /.

مورد دیگه ای که بهش برخوردم خطای circular dependency بود که مربوط به ارجاع دادن مسیرهای مطلق به همدیگر هست.
اگر در پروژه از فایل‌های index.ts جهت کوتاه کردن آدرس‌ها استفاده میکنید، نباید در داخل خود فایل هایی که در index.ts معرفی شدند، از مسیر مطلق استفاده کنید.
برای مثال:
شما یک پوشه به اسم common دارید که داخل آن یک پوشه دیگر به اسم utilities که برای مثال کلاسی به اسم DateTime را در آن تعریف کردید. و حال شما میخواهید کلاس DateTime را با آدرس مطلق app/common@ در سراسر پروژه استفاده کنید.
به همین دلیل شما در داخل پوشه common فایل index.ts رو ایجاد میکنید و دستور زیر را قرار میدید:
 export * from './utilities/DateTime'
حال، اگر در هر یک از فایل هایی که داخل پوشه common که فایل index.ts را قبلا در آن تعریف کردیم، بخواهید از DateTime استفاده کنید، اگر آن را با مسیر مطلق مانند:
 import { DateTime } from '@app/common'
 استفاده کنید به خطای circular dependency بر میخورید.
به همین خاطر باید از مسیر نسبی استفاده کنید مانند:
 import { DateTime } from './utilities/DateTime'
ولی در خارج از پوشه common میتوانید از مسیر مطلق استفاده کنید.
امیدوارم تونسته باشم منظور رو برسونم.
نظرات مطالب
طبقه بندی Bad Code Smell ها
به صورت کلی استفاده  enum‌ها به تنهایی پیشنهاد نمیشود چون enum نشان دهنده یک وضعیت ( state ) است و ما در برنامه نویسی شی گرا نیاز به  وضعیت و رفتار ( state & behavior) داریم و یکی از مشکلات اصلی enum‌ها این است که قابلیت refactoring رو به خوبی ندارن به همین دلایل ما enum‌ها رو در یک کلاس قرار می‌دهیم مانند این مثال:
sealed class DeviceStatus : IEquatable<DeviceStatus>
    {
        [Flags]
        private enum StatusRepresentation
        {
            AllFine = 0,
            NotOperational = 1,
            VisiblyDamaged = 2,
            CircuitryFailed = 4
        }

        private StatusRepresentation Representation { get; }

        private DeviceStatus(StatusRepresentation representation)
        {
            this.Representation = representation;
        }

        public static DeviceStatus AllFine() =>
            new DeviceStatus(StatusRepresentation.AllFine);

        public DeviceStatus WithVisibleDamage() =>
            new DeviceStatus(this.Representation | StatusRepresentation.VisiblyDamaged);

        public DeviceStatus NotOperational() =>
            new DeviceStatus(this.Representation | StatusRepresentation.NotOperational);

        public DeviceStatus Repaired() =>
            new DeviceStatus(this.Representation & ~StatusRepresentation.NotOperational);

        public DeviceStatus CircuitryFailed() =>
            new DeviceStatus(this.Representation | StatusRepresentation.CircuitryFailed);

        public DeviceStatus CircuitryReplaced() =>
            new DeviceStatus(this.Representation & ~StatusRepresentation.CircuitryFailed);

        public override int GetHashCode() => (int)this.Representation;

        public override bool Equals(object obj) => this.Equals(obj as DeviceStatus);

        public bool Equals(DeviceStatus other) =>
            other != null && this.Representation == other.Representation;

        public static bool operator ==(DeviceStatus a, DeviceStatus b) =>
            (object.ReferenceEquals(a, null) && object.ReferenceEquals(b, null)) ||
            (!object.ReferenceEquals(a, null) && a.Equals(b));

        public static bool operator !=(DeviceStatus a, DeviceStatus b) => !(a == b);
    }
اگه دقت کرده باشید این کلاس به صورت value object طراحی شده است و از مهمترین ویژگی اینگونه کلاس‌ها این که تغییرناپذیر هستند. 
نظرات مطالب
ساخت یک Form Generator ساده در MVC
- برای دریافت اطلاعات یک فرم مشخص:
        public IList<Value> GetValues(int formId)
        {
            return _values.Include(x => x.Field)
                          .Where(value => value.FormId == formId)
                          .ToList();
        }
- این پروژه از دیدگاه دریافت اطلاعات از کاربر و همچنین تولید فرم پویا جالب است (صرفا قسمت UI آن). به لطف نبود ViewState، طراحی فرم‌های پویا در اینجا خیلی ساده‌تر است از وب‌فرم‌ها.
- اما از دیدگاه ذخیره سازی این اطلاعات پویا ... مشکل دارد. در طراحی بانک اطلاعاتی آن فرض شده‌است که برنامه مثلا فرم یک را دارد. این فرم یک، 10 فیلد پویا یا بیشتر را دارد. این 10 فیلد فقط یکبار توسط کاربر پر می‌شوند. اگر کاربر قرار باشد بار دوم این فرم یک را پر کند، امکان پذیر نیست. در کلاس Value آن که فقط محتوای یک فیلد را ذخیره می‌کند، مفهومی به نام ردیف سند جاری وجود ندارد. به ازای هر فیلد یک ردیف مجزا داریم؛ اما مشخص نیست این ردیف‌ها متعلق به کدام سند هستند (منظور از سند، شمار منحصربفرد پر کردن فرم جاری است؛ هر کاربر یک فرم را بیش از یکبار می‌تواند پر کند).
 برای حل این نوع مشکلات (برای اینکه به ازای مقدار هر فیلد فرم پویا، یک ردیف مجزا تولید نشود و schemaless کار کرد) یا باید از یک بانک اطلاعاتی NoSQL استفاده کرد که مثلا کل فرم را در قالب یک شیء JSON سریالایز کند و آن‌را داخل یک فیلد از یک ردیف (یک سند) ذخیره کند. یا اگر با SQL Server کار می‌کنید، فیلد XML آن چنین قابلیتی را دارد. کل اطلاعات دریافتی فرم را تبدیل به XML کنید و سپس ذخیره. به این صورت امکان تهیه کوئری و گزارش گرفتن‌های پیشرفته و بهینه را به همراه تعریف ایندکس و مسایل دیگر نیز خواهید داشت. اینبار هر ردیف بانک اطلاعاتی، مفهوم یک سند کامل را پیدا می‌کند؛ بجای اینکه هر ردیف فقط یک مقدار از یک فیلد باشد. همچنین در این حالت هر ردیف می‌تواند محتوای فرمی را ذخیره کند که با ردیف بعدی کاملا متفاوت است (بر اساس طراحی پویای متفاوت هر فرم).
نظرات مطالب
EF Code First #12
- یک Context در EF باید طول عمر کوتاهی داشته باشد. سینگلتون تعریف کردن آن یعنی زنده نگه داشتن آن در طول عمر برنامه. در یک برنامه وب به این ترتیب اگر جایی کاربری به مشکلی برخورد، چون یک Context در این حالت بیشتر وجود نخواهد داشت، تمام خطاهای آن کاربر به سایر کاربران نیز منعکس می‌شود. همچنین Context به صورت thread safe طراحی نشده و به این ترتیب به مشکلات تخریب اطلاعات در برنامه‌های چند کاربره نیز برخواهید خورد.
- در مطلب فوق به ازای هر درخواست یک Context ایجاد می‌شود (مقدمه بحث). Context در طول عمر یک درخواست کاربری خاص، زنده نگه داشته شده و بعد در پایان کار آن درخواست Dispose می‌شود. نه فقط بحث مدیریت اتصالات در اینجا مطرح است، بحث مدیریت یک تراکنش واحد در طول عمر یک درخواست نیز باید درنظر گرفته شود.

چند پیشنهاد:
- یکبار مطلب جاری را مطالعه کنید.
- یکبار وقت بگذارید نظرات آن‌را هم بررسی کنید. در مورد سینگلتون یا حتی Contextهای استاتیک و امثال آن قبلا بحث شده.
- یکبار دوره پیشنیاز این مطلب را مطالعه کنید: «بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن»
- یکبار دوره خاص برنامه‌های دسکتاپ طراحی شده با این الگو را هم مطالعه کنید: «طراحی یک فریم ورک برای کار با WPF و EF Code First توسط الگوی MVVM»
- نگاهی هم به یک پروژه کامل ASP.NET MVC که با درنظر گرفتن الگوی مطرح شده در این بحث تهیه شده، داشته باشید: «سیستم مدیریت محتوای IRIS»

این مبحث باز شده‌اش بالای 20 قسمت است.
نظرات مطالب
با ASP.MVC چه مزایایی را به دست خواهیم آورد
- باتوجه به جمله بندی که بکار بردید، به نظر تصمیم خودتون رو در مورد سیلورلایت گرفتید. اما اگر برای 10 سال آینده می‌خواهید سرمایه گذاری کنید، سیلورلایت چیزی شبیه به VB6 خواهد شد. یعنی بیشتر فقط پشتیبانی و هات فیکس خواهد داشت. خلاصه سرمایه گذاری روی فناوری که عده‌ای درحال درخواست از مایکروسافت هستند که لطفا آن‌را ادامه دهید و وضعیتش معلوم نیست، کار صحیحی برای 10 سال بعد نخواهد بود.
سیلورلایت و فلش با تبلیغ منفی استیوجابز به علت مشکلات فلش در پلتفرم آن‌ها از بین رفتند.
- سریعتر و راحت‌تر برای برنامه‌ای که قرار است 10 سال کار کند معنا ندارد. چون یک چنین سیستمی حداقل 2 سال طول خواهد کشید تا نگارش یک آن جا بیفتد و بعد کار نگهداری خواهید داشت. در قسمت نگهداری، کار با سیستمی ساده‌تر و لذت بخش‌تر خواهد بود که اجزای آن به خوبی از هم جدا شده باشند و اینجا است که MVC از روز اول بر روی این مساله تاکید دارد، آن هم به صورت یک فریم ورک توکار رسمی. هیچ وقت مایکروسافت MVVM رو با سیلورلایت و WPF به صورت یکپارچه و چیزی شبیه به MVC ارائه نداد. هرچند ده‌ها فریم ورک MVVM وجود دارند ولی در کل از نظر من بیشتر یک سری Helper هستند تا فریم ورکی شبیه به MVC.
- یک مقدار کار با jQuery و فریم ورک‌های جدید جاوا اسکریپتی را بدانید، اکثر قابلیت‌های سیلورلایت رو می‌تونید داشته باشید. ضمن اینکه الان مایکروسافت روی فریم ورک‌های SPA برای MVC به شدت مشغول تبلیغ است. برنامه‌های تک صفحه‌ای وب = Single page applications = SPA. این مورد جایگزین بهتری است برای سیلورلایت.