اشتراک‌ها
معرفی اعتبارسنجی بدون پسورد استاندارد WebAuthn

For decades, passwords have been the common backbone (headache) of authentication and are well known to lack in security while being frustrating and difficult to use. As we continue to see daily data breaches, the reality of moving away from weak static credentials and killing the password is upon us. Join this session to learn how FIDO2 and WebAuthn open authentication standards, in conjunction with YubiKeys, are solving the elimination of passwords at scale. Hear how organizations like Microsoft have implemented these standards for a true passwordless experience and find out how your organization can follow suit. You'll gain a greater understanding of how to achieve a modern and flexible security architecture through the use of FIDO open standards and hardware authenticators. 

معرفی اعتبارسنجی بدون پسورد استاندارد WebAuthn
مطالب
تعامل و انتقال اطلاعات بین کامپوننت‌ها در Angular – بخش دوم
در قسمت قبل نحوه انتقال اطلاعات از کامپونت پدر به فرزند را از طریق متادیتای Input@ برسی کردیم. در اینجا نکات تکمیلی را مورد بحث قرار خواهیم داد.
همانطور که قبلا مشاهده کردید، نام متغیر تعریف شده در کامپوننت فرزند (FormIsReadOnly) به عنوان یک خصوصیت در هنگام استفاده از کامپوننت ظاهر شده و عمل انقیاد از طریق این خصوصیت FormIsReadOnly صورت می‌گیرد. در صورتیکه قصد دارید نام خصوصیت ظاهر شده در کامپوننت، با نام متغیر تعریف شده در کامپوننت فرزند متفاوت باشد، به شکل زیر عمل کنید. 
@Input('readOnly') FormIsReadOnly: boolean;
در این حالت عمل انقیاد از طریق خصوصیتی با نام readOnly صورت خواهد گرفت.

ردیابی تغییرات اعمال شده بر روی خصوصیت 

در برخی موارد لازم است بعد از انتساب مقداری از سمت کامپوننت پدر به کامپوننت فرزند و قبل از استفاده کامپوننت فرزند از آن مقدار، تغییرات یا اعتبار سنجی بر روی مقدار منتسب شده اعمال کنیم. مثلا فرض کنید کامپوننتی را به نام LeftSideMenu تعریف کرده‌اید که باز بودن یا بسته بودن آن توسط کامپوننت پدر تنظیم میشود. در اینجا لازم است همواره منتظر تغییر این خصوصیت از سمت کامپوننت پدر بود تا بلافاصله بعد از تنظیم این خصوصیت، کامپوننت فرزند نسبت به باز شدن یا بسته ماندن، عکس العمل نشان داده و بلافاصله تغییرات را اعمال کند (منو را باز کند یا ببندد). لازمه این کار ردیابی تغییرات اعمال شده از سمت کامپوننت پدر می‌باشد تا به محض تغییر، اصلاحات یا اعتبار سنجی‌های لازم بر روی آن اعمال شود. برای این کار دو راه حل وجود خواهد داشت. 
  1. ردیابی تغییرات صورت گرفته از طریق تنظیم setter به متغیر تعریف شده با متادیتای Input@
  2. پیاده سازی onChanges توسط کامپوننت فرزند جهت ردیابی تغییرات کامپوننت 


ردیابی تغییرات از طریق تنظیم setter

همانطور که گفته شد استفاده از کامپوننت فرزند به شکل زیر:
<app-customer-info FormIsReadOnly="true"></app-customer-info>
باعث خواهد شد مقدار انتساب یافته به FormIsReadOnly از جنس رشته‌ای باشد (یعنی "true"). در اینجا می‌خواهیم قبلا از اینکه مقدار، از طریق کامپوننت پدر به فرزند مقدار دهی شود، برسی کنیم در صورتیکه مقدار انتسابی از جنس boolean نبود، خطایی را صادر و برنامه نویس را برای این استفاده نادرست از کامپوننت هشیار کنیم: 
@Component({
    selector: 'app-customer-info',
    templateUrl: './customer-info.component.html',
    styleUrls: ['./customer-info.component.css']
})
export class CustomerInfoComponent implements OnInit {
    private _formIsReadOnly: boolean;

    @Input()
    set FormIsReadOnly(value: boolean) {
        if (typeof (value) != 'boolean')
            throw new Error(`${value} type is not boolean.`);
        this._formIsReadOnly = value;
    }

    get FormIsReadOnly(): boolean { return this._formIsReadOnly; }

    constructor() { }

    ngOnInit() {
    }
}
با تنظیم setter بر روی متغیر FormIsReadOnly، لازمه‌ی تمامی تغییرات بر روی این متغیر، اجرای آن setter خواهد بود. در اینجا برسی کردیم در صورتیکه نوع مقدار (typeof(value)) از جنس boolean نباشد، خطایی صادر شود. 


پیاده سازی onChanges توسط کامپوننت فرزند جهت ردیابی تغییرات کامپوننت 

یکی دیگر از راه‌های تشخیص تغییرات اعمال شده بر روی کامپوننت، پیاده سازی اینترفیس onChanges توسط کامپوننت و پیاده سازی متد تعریف شده در این اینترفیس به نام ngOnChanges می‌باشد. 
import { Component, OnInit, Input, OnChanges, SimpleChange } from '@angular/core';
import { ICustomerInfo } from '../../core/model/ICustomerInfo';

@Component({
    selector: 'app-customer-info',
    template: '<ul>< li *ngFor="let change of changeLog">{{change }}</li></ul>',
    styleUrls: ['./customer-info.component.css']
})
export class CustomerInfoComponent implements OnChanges {
    changeLog: string[] = [];

    @Input() FormIsReadOnly: boolean;

    ngOnChanges(changes: { [propKey: string]: SimpleChange }) {
        let log: string[] = [];
        for (let propName in changes) {
            let changedProp = changes[propName];
            let to = JSON.stringify(changedProp.currentValue);
            if (changedProp.isFirstChange()) {
                log.push(`Initial value of ${propName} set to ${to}`);
            } else {
                let from = JSON.stringify(changedProp.previousValue);
                log.push(`${propName} changed from ${from} to ${to}`);
            }
        }
        this.changeLog.push(log.join(', '));
    }

    constructor() { }
}
این کامپوننت تمامی تغییرات اعمال شده بر روی FormIsReadOnly را ردیابی کرده و نمایش خواهد داد. نمونه خروجی به شکل زیر خواهد بود. 
•    Initial value of FormIsReadOnly set to true
•    FormIsReadOnly changed from true to "trued"
•    FormIsReadOnly changed from "trued" to "true"
•    FormIsReadOnly changed from "true" to "truef"
•    FormIsReadOnly changed from "truef" to "true"
•    FormIsReadOnly changed from "true" to "tru"
•    FormIsReadOnly changed from "tru" to "tr"
•    FormIsReadOnly changed from "tr" to "t"
•    FormIsReadOnly changed from "t" to ""
•    FormIsReadOnly changed from "" to "t"
•    FormIsReadOnly changed from "t" to "tr"
•    FormIsReadOnly changed from "tr" to "tru"
•    FormIsReadOnly changed from "tru" to "true"

در ادامه عنوان «به‌جریان انداختن رخدادها از کامپوننت فرزند و گرفتن آن‌ها را از طریق کامپوننت پدر» را مورد برسی قرار خواهیم داد.


ادامه دارد/

مطالب
بررسی چند نکته در مورد ارث بری کلاس‌ها در #C
مقدمه
وراثت، بین کلاس‌های والد (Parent) و فرزند (Child) ارتباط ایجاد می‌کند. در این مطلب، با یک مثال ساده، نکات مختلفی را بررسی خواهیم کرد.

در ابتدا کلاس‌هایی را با نام parent و child، به شکل زیر ایجاد می‌کنیم:
public class Parent
{
  public Parent()
  {
            Console.WriteLine("Parent Constructor");
  }
  public void Print()
  {
            Console.WriteLine("Parent Print");
  }
} public class Child : Parent { public Child() { Console.WriteLine("Child Constructor"); } public void Print() { Console.WriteLine("Child Print"); } }
با کامپایل کد فوق، هشدار (نه خطا) زیر توسط ویژوال استودیو صادر خواهد شد:

هشدارفوق این نکته را تذکر می‌دهد که متد Print تعریف شده در کلاس Child، پیاده سازی متد Print را در کلاس والد، مخفی (Hide) می‌کند. به همین خاطر پیشنهاد می‌کند که اگر واقعا قصد چنین کاری را داریم (نادیده گرفتن پیاده سازی print کلاس والد) از کلمه کلیدی (keyword) new استفاده کنیم. بدین شکل:
 public new void Print()
  {
     Console.WriteLine("Child Print");
  }
حال با نمونه سازی کلاس‌های فوق، رفتار سازنده و متد Print را بررسی می‌کنیم:
Console.WriteLine("====Parent====");
Parent parent = new Parent();
parent.Print();

Console.WriteLine("====Child====");
Child child = new Child();
child.Print();

Console.WriteLine("====Parent Via Child====");
Parent pc = new Child();
pc.Print();
در قسمت اول نمونه سازی از والد، نکته خاصی وجود ندارد. در ابتدا سازنده و سپس فراخوانی متد Print اتفاق خواهد افتاد.
در قسمت دوم نمونه سازی از فرزند، ابتدا سازنده والد و سپس سازنده فرزند فراخوانی خواهند.
در بخش سوم، یک نمونه فرزند را از نوع والد، ایجاد کرد‌هایم .( () Parent pc=new Child). در این بخش ابتدا سازنده والد و بعد از آن سازنده فرزند، فراخوانی می‌شود و با فراخوانی متد Print، متد والد اجرا خواهد شد.


استفاده از Virtual  و Override
اگر بدنبال این باشیم که در قسمت سوم متد Print فرزند فراخوانی شود، مفاهیم virtual و override به کمک ما خواهند آمد:
  public class Parent
{
  public Parent()
  {
Console.WriteLine("Parent Constructor");
  }

  public virtual void  Print()
  {
Console.WriteLine("Parent Print");
  }
}

public class Child : Parent
{
  public Child()
  {
Console.WriteLine("Child Constructor");
  }

  public override void Print()
  {
Console.WriteLine("Child Print");
  }
}
با تعریف متد از نوع virtual، امکان تحریف رفتار پیش فرض متد را توسط فرزند‌ها، مهیا خواهیم کرد. فرزندان نیز با override کردن متد والد، پیاده سازی خود را اعمال می‌کنند.
اگر خروجی کد بالا را با قسمت قبل مقایسه کنید، متوجه خواهید شد که در قسمت سوم فرزند، رفتار متد والد را تحریف/بازنویسی (override) کرده است ( پیاده سازی فرزند اجرا شده است).


سازنده‌های استاتیک (Static Constructor)
سازنده‌های استاتیک برای مقدار دهی به داده‌های استاتیک و یا انجام عملیاتی که تنها قرار است یکبار انجام شوند مورد استفاده قرار میگیرند. این سازنده‌ها بصورت اتوماتیک قبل از ساخت نمونه و مقداردهی اعضای استاتیک و قبل از سازنده‌های غیر استاتیک اجرا می‌شوند.
   public class Parent
{
  static Parent()
  {
Console.WriteLine("Parent static Constructor");
  }
  public Parent()
  {
Console.WriteLine("Parent Constructor");
  }

  public virtual void  Print()
  {
Console.WriteLine("Parent Print");
  }
}

public class Child : Parent
{
  static Child()
  {
Console.WriteLine("Child static Constructor");
  }
  public Child()
  {
Console.WriteLine("Child Constructor");
  }

  public override void Print()
  {
Console.WriteLine("Child Print");
  }
در بخش سوم در ابتدا سازنده استاتیک فرزند و سپس سازنده استاتیک والد فراخوانی خواهند شد و ترتیب اجرای سایر متد‌ها و سازنده‌ها مثل قبل است.




  جمع بندی
* اگر نمونه‌ای از یک فرزند را ایجاد کنیم، ابتدا سازنده‌ی والد فراخوانی خواهد شد و پس از آن سازنده‌ی کلاس فرزند.
* اگر قصد تحریف رفتار متد والد را در فرزندان داریم، می‌توانیم این متد‌ها را در کلاس والد بصورت virtual تعریف کنیم.
اشتراک‌ها
پیش نمایش MAUI و اجرای یک مثال

At Microsoft Build 2021 .NET MAUI Preview 4 was launched. This version is already pretty complete and starts to reflect what the end result is going to look like. In this video I will show you the new .NET MAUI template in Visual Studio 2019 and walk you through the Weather 21 demo app.  

پیش نمایش MAUI و اجرای یک مثال
مطالب
استفاده از مسیرهای مطلق در حین import ماژول‌ها در برنامه‌های مبتنی بر TypeScript
در حین import ماژول‌های TypeScript ایی پس از مدتی به یک چنین کدهایی خواهیم رسید:
import { SpecialCollection } from "../../special";
import { LoginComponent } from "../login";
import { TextUtils } from ".../../utils/text";
import { Router } from "../../../core/router";
در این حالت، در یک پوشه برای import ماژولی مشخص، چنین import ایی را خواهیم داشت:
import { Data } from '../data';
و در پوشه‌ی تو در توی دیگری، این تعریف به صورت زیر تغییر می‌کند:
import { Data } from '../../../data';
و در آخر برنامه پر می‌شود از مسیرهای نسبی ‘../../../..’ مانند. به این ترتیب جابجا کردن فایل‌ها و Refactoring آن‌ها، مشکل می‌شود.
خوشبختانه کامپایلر TypeScript به همراه تنظیمات baseUrl و paths است که توسط آن‌ها می‌توان این مسیرهای نسبی را به مسیرهای مطلق تبدیل کرد و در این حالت اهمیتی ندارد که ماژول مدنظر از چه سطحی و درون چه پوشه‌ی تو در تویی فراخوانی می‌شود، این مسیر import همواره ثابت خواهد بود.


تنظیمات فایل tsconfig.json برای معرفی مسیرهای مطلق ماژول‌ها

فرض کنید می‌خواهید از یکی از سرویس‌های Core Module استفاده کنید:


بسته به عمق پوشه‌ی استفاده کننده، به یک چنین تعریفی خواهید رسید:
import { BrowserStorageService } from "./../../core/browser-storage.service";
برای بهبود این وضعیت، فایل tsconfig.json و یا همان تنظیمات کامپایلر TypeScript را به نحو ذیل تکمیل می‌کنیم:
{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@app/*": [
        "app/*"
      ],
      "@app/core/*": [
        "app/core/*"
      ],
      "@app/shared/*": [
        "app/shared/*"
      ],
      "@env/*": [
        "environments/*"
      ]
    }
  }
}
در اینجا baseUrl به پوشه‌ی src برنامه اشاره می‌کند و مسیرهای بعدی بر این اساس محاسبه می‌شوند. در ادامه در قسمت paths، ابتدا یک نام مستعار ذکر می‌شود و سپس مسیری که ارائه دهنده‌ی آن است. ذکر @ در اینجا اختیاری است؛ اما ذکر */‌ها اجباری است.
پس از این تغییرات، اکنون افزونه‌ی پیشنهاد دهنده‌ی imports، هر دو حالت استفاده‌ی از مسیر مطلق بر اساس نام مستعار تعریف شده:
 import { BrowserStorageService } from "@app/core/browser-storage.service";
و یا استفاده‌ی از مسیر نسبی را نیز پیشنهاد می‌دهد:
 import { BrowserStorageService } from "./../../core/browser-storage.service";


برای مثال اگر دقت کرده باشید، روش import اجزای خود Angular به صورت زیر است:
 import { Component } from '@angular/core';
علت اینجا است که Angular از تعریف مشابهی به صورت زیر برای نگاشت پوشه‌ی node_modules آن به angular@ استفاده می‌کند:
"paths": {
    "@angular/*": ["node_modules/@angular/*"]
},
و ذکر @ اختیاری هم از اینجا اقتباس شده‌است.


یک نکته‌ی مهم: تنظیمات فوق بدون تنظیمات معادل webpack ناقص هستند

اگر از برنامه‌ی Angular CLI استفاده می‌کنید، تنظیمات ذکر شده، تا همینجا به پایان می‌رسند؛ چون webpack جزئی از Angular CLI است و تنظیمات پیش فرض آن، قسمت baseUrl و paths فایل tsconfig.json را به صورت خودکار پردازش می‌کند. اما اگر از TypeScript در محیط‌های دیگری استفاده می‌کنید که از webpack به صورت مجزایی استفاده می‌کنند، نیاز است قسمت resolve.alias فایل webpack.config.js را نیز جهت معرفی این تغییرات، اصلاح کنید. از این جهت که کامپایلر TypeScript این مسیرهای مطلق را در حین تولید فایل‌های نهایی JavaScript ایی معادل، به مسیرهای نسبی بازنویسی نمی‌کند و در این حالت webpack نمی‌داند که چطور باید این ماژول‌ها را یافته و یکی کند.
resolve: {
  extensions: ['*', '.js', '.ts'],
  modules: [
    rootDir,
    path.join(rootDir, 'node_modules')
  ],
  alias: {
    '@app': 'src/app'
  }
},


کوتاه کردن مسیرهای مطلق با معرفی فایل ویژه‌ی index.ts

تا اینجا بجای ذکر مسیر
import { BrowserStorageService } from "./../../core/browser-storage.service";
به مسیر مطلق زیر رسیدیم (صرفنظر از محل قرارگیری ماژولی که قرار است آن‌را import کند):
import { BrowserStorageService } from "@app/core/browser-storage.service";
این را هم می‌خواهیم به صورت زیر کوتاه‌تر کنیم:
import { BrowserStorageService } from "@app/core";
یعنی فقط app/core@ را ذکر کنیم.

برای اینکار نیاز است فایل ویژه‌ای را به نام index.ts، در ریشه‌ی پوشه‌ی core ایجاد کنیم (src\app\core\index.ts)، با این محتوا:
export * from "./browser-storage.service";
export * from "./app-config.service";
export * from "./seo-service";
در اینجا تمام ماژول‌هایی که توسط Core Module ارائه می‌شوند را یکبار export می‌کنیم.
برای نمونه اگر به پوشه‌ی node_modules\@angular خود مجموعه‌ی Angular هم مراجعه کنید، هر پوشه‌ی src آن به همراه یک فایل index.d.ts شبیه تعاریف فوق نیز هست.

پس از افزودن فایل index.ts به ریشه‌ی پوشه‌ی مدنظر، اکنون در لیست پیشنهادات، ذکر app/core@ تنها نیز ظاهر شده و استفاده‌ی از آن مجاز است:

اشتراک‌ها
کتاب رایگان WPF Debugging and Performance Succinctly

WPF allows you to build modern desktop applications for Windows, and part of building an application is debugging code and optimizing performance. In Alessandro Del Sole’s WPF Debugging and Performance Succinctly, you will learn how to debug a WPF application by leveraging all the powerful tools in Visual Studio, including the most recent additions that allow you to investigate the behavior of the UI at runtime. Also, you will learn how to analyze and improve an application’s performance in order to provide your customers with the best possible experience and thereby make them happy.

Table of Contents
  1. Debugging WPF Applications
  2. Stepping Through Code
  3. Working with Debug Windows
  4. Debugger Visualizers and Trace Listeners
  5. XAML Debugging
  6. Analyzing the UI Performances
  7. Analyzing the Application Performances 
کتاب رایگان WPF Debugging and Performance Succinctly
اشتراک‌ها
کتابخانه a2d3

A set of composable and extensible Angular 2 directives for building SVGs with D3 declaritively. This library provides functionality for basic charts out of the box, but it can be easily extended to support building declarative syntaxes for just about any SVG generated by D3.  Demo

کتابخانه a2d3
اشتراک‌ها
پلاگینی برای ساخت DropDownList های مرتبط
A multi level dependent dropdown JQuery plugin that allows nested dependencies. The plugin allows you to convert normal select inputs, whose options are derived based on value selected in another input/or a group of inputs. It works both with normal select options and select with optgroups as well. 
پلاگینی برای ساخت DropDownList های مرتبط