اشتراک‌ها
کنفرانس NET Conf: Focus on Blazor.

.NET Conf: Focus on Blazor is a free, one-day livestream event that features speakers from the community and .NET product teams that are working on building web apps with C# and Blazor. You don't need to use JavaScript anymore with Blazor technology! Blazor lets you build interactive web UIs using C# instead of JavaScript. 

کنفرانس NET Conf: Focus on Blazor.
اشتراک‌ها
جاوا اسکریپت برای توسعه دهندگان #C
The conference is a two-day, multi-track event that covers all aspects of software development, design and project management. We have speakers from all over the world who are industry experts that deliver both break-out sessions as well as hands-on workshops to further our attendee’s knowledge and understanding of the topics 
جاوا اسکریپت برای توسعه دهندگان #C
اشتراک‌ها
دریافت 9 هندبوک ویژه‌ی توسعه‌ی وب
  • The JavaScript Handbook (171 pages) fall 2018
  • JavaScript from ES5 to ESNext (84 pages) early 2019
  • The React Handbook (220 pages) early 2019
  • The Node.js Handbook (189 pages) fall 2018
  • The Express.js Handbook (61 pages) fall 2018
  • The Vue.js Handbook (122 pages) summer 2018
  • The CSS Handbook (173 pages) spring 2019
  • The HTML Handbook (87 pages) summer 2019
  • The Svelte Handbook (41 pages) fall 2019 
دریافت 9 هندبوک ویژه‌ی توسعه‌ی وب
اشتراک‌ها
انواع driver شبکه و موارد استفاده آن در docker

Bridge Network Driver

The bridge networking driver is the first driver on our list. It’s simple to understand, simple to use, and simple to troubleshoot, which makes it a good networking choice for developers and those new to Docker. The bridge driver creates a private network internal to the host so containers on this network can communicate. External access is granted by exposing ports to containers. Docker secures the network by managing rules that block connectivity between different Docker networks. 


Overlay Network Driver

The built-in Docker overlay network driver radically simplifies many of the complexities in multi-host networking. It is a swarm scope driver, which means that it operates across an entire Swarm or UCP cluster rather than individual hosts. With the overlay driver, multi-host networks are first-class citizens inside Docker without external provisioning or components. IPAM, service discovery, multi-host connectivity, encryption, and load balancing are built right in. For control, the overlay driver uses the encrypted Swarm control plane to manage large scale clusters at low convergence times. 


MACVLAN Driver

The macvlan driver is the newest built-in network driver and offers several unique characteristics. It’s a very lightweight driver, because rather than using any Linux bridging or port mapping, it connects container interfaces directly to host interfaces. Containers are addressed with routable IP addresses that are on the subnet of the external network.

As a result of routable IP addresses, containers communicate directly with resources that exist outside a Swarm cluster without the use of NAT and port mapping. This can aid in network visibility and troubleshooting. Additionally, the direct traffic path between containers and the host interface helps reduce latency. macvlan is a local scope network driver which is configured per-host. As a result, there are stricter dependencies between MACVLAN and external networks, which is both a constraint and an advantage that is different from overlay or bridge. 

انواع driver شبکه و موارد استفاده آن در docker
اشتراک‌ها
تفاوت مجوز LGPL با GPL در چیست؟

A component licensed under LGPL can be used by closed source, proprietary software, both internally used and distributed, for free, with no effects on the software using the component. LGPL is not “contagious” in the same way as GPL, so it only affects the component under LGPL. As long as you’re only using official distributions of the component, it is free to use and free to redistribute. The only requirement is that you include a notice in your “about” page or similar that the component is used. 

تفاوت مجوز LGPL با GPL در چیست؟
اشتراک‌ها
هزینه‌ی استفاده از Duende Identity Server

So imagine you’ve bought the license for redistribution business edition for 10000 and that is only for 5 clients. But for unlimited clients the price is 35000 per year! Now we have about 27 clients and 5 client would not be enough and the price is a lot to swallow.  

هزینه‌ی استفاده از Duende Identity Server
مطالب
PowerShell 7.x - قسمت نهم - آشنایی با Crescendo
همانطور که در ابتدای این سری نیز اشاره شد، یکی از ویژگی‌های منحصربه‌فرد PowerShell، طراحی شیءگرای آن است، به‌طوریکه خروجی cmdletهای آن، به صورت آبجکت هستند. همچنین، در PowerShell امکان اجرای کامندهای native نیز وجود دارد. به عنوان مثال اگر کامند زیر را وارد کنید: 
git log --oneline
خروجی، همانطوری که در دیگر shellها انتظار میرود، نمایش داده خواهد شد؛ یعنی به صورت string. همچنین امکان intellisense را نیز برای پارامترهای کامند موردنظر نخواهیم داشت؛ چون در اصل، به اصطلاح یک legacy command است و نه یک cmdlet. برای بهره بردن از امکانات PowerShell میتوانیم این نوع کامندها را توسط یک wrapper به cmdlet تبدیل کنیم، اما آپدیت نگه‌داشتن این wrapper و نوشتن آن فرآیند سختی است. برای سهولت انجام اینکار، یک فریم‌ورک تحت عنوان Crescendo توسط مایکروسافت ارائه شده است.
یک مثال
فرض کنید میخواهیم کامند git log را به همراه تعدادی از دستورات آن به یک PowerShell cmdlet تبدیل کنیم؛ برای اینکار ابتدا نیاز است ماژول عنوان شده را نصب کنیم: 
Install-Module -Name Microsoft.PowerShell.Crescendo
بعد از نصب ماژول فوق، یکسری cmdlet به مجموعه کامندهای PowerShell اضافه خواهند شد. یکی از این کامندها New-CrescendoCommand است. با کمک این کامند، فایل JSON موردنیاز Crescendo را میتوانیم تولید کنیم: 
$Configuration = @{
    '$schema' = "https://aka.ms/PowerShell/Crescendo/Schemas/2021-11"
    Commands  = @()
}
$parameters = @{
    Verb = "Get"
    Noun = "GitLog"
    OriginalName = "git"
}
$Configuration.Commands += New-CrescendoCommand @parameters

$Configuration | ConvertTo-Json -Depth 3 | Out-File ./git-ps.json
در اینجا تعیین کرده‌ایم که کامندی که میخواهیم برایمان تولید شود، چه ویژگی‌هایی باید داشته باشد. به عنوان مثال Verb آن Get و Noun آن باید GitLog باشد (براساس استانداری که مایکروسافت برای نامگذاری cmdletها پیشنهاد میدهد). در نهایت میتوانیم به صورت Get-GitLog از آن استفاده کنیم. همچنین legacy command اصلی که میخواهیم برای آن cmdlet ایجاد کنیم نیز توسط OriginalName تعیین شده‌است. لازم به ذکر است که در ویندوز باید مسیر کامل آن را وارد کنید. سپس با اجرای دستورات فوق، خروجی زیر برایمان تولید خواهد شد: 
{
  "Commands": [
    {
      "Verb": "Get",
      "Noun": "GitLog",
      "OriginalName": "git",
      "OriginalCommandElements": null,
      "Platform": [
        "Windows",
        "Linux",
        "MacOS"
      ],
      "Elevation": null,
      "Aliases": null,
      "DefaultParameterSetName": null,
      "SupportsShouldProcess": false,
      "ConfirmImpact": null,
      "SupportsTransactions": false,
      "NoInvocation": false,
      "Description": null,
      "Usage": null,
      "Parameters": [],
      "Examples": [],
      "OriginalText": null,
      "HelpLinks": null,
      "OutputHandlers": null
    }
  ],
  "$schema": "https://aka.ms/PowerShell/Crescendo/Schemas/2021-11"
}
نکته: دقت داشته باشید که schema$ باید درون single quote نوشته شود؛ چون در غیراینصورت، key آن درون فایل تولید شده، خالی خواهد بود: 
"": "https://aka.ms/PowerShell/Crescendo/Schemas/2021-11",
با کمک این schema درون Visual Studio Code امکان Intelisense را نیز خواهیم داشت: 


اکنون باید این فایل Configuration را به Crescendo معرفی کنیم تا cmdlet را برایمان تولید کند. اینکار را توسط Export-CrescendoModule انجام خواهیم داد: 

Export-CrescendoModule -Configuration ./git-ps.json -ModuleName ./git-ps.psm1

با اجرای دستور فوق، فایل‌های git.psm1 و همچنین git.psd1 تولید خواهند شد. نیاز به بررسی فایل‌های جنریت شده نیست؛ چون تنها جایی که با آن باید در ارتباط باشیم، همان فایل JSON ابتدای بحث است که در ادامه آن را بررسی خواهیم کرد. اما قبل از آن اجازه دهید ماژول تولید شده را Import کنیم و دستور Get-GitLog را وارد کنیم: 

PP /> Import-Module ./git-ps.psd1
PS /> Get-GitLog

usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [--super-prefix=<path>] [--config-env=<name>=<envvar>]
           <command> [<args>]

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone     Clone a repository into a new directory
   init      Create an empty Git repository or reinitialize an existing one

work on the current change (see also: git help everyday)
   add       Add file contents to the index
   mv        Move or rename a file, a directory, or a symlink
   restore   Restore working tree files
   rm        Remove files from the working tree and from the index

examine the history and state (see also: git help revisions)
   bisect    Use binary search to find the commit that introduced a bug
   diff      Show changes between commits, commit and working tree, etc
   grep      Print lines matching a pattern
   log       Show commit logs
   show      Show various types of objects
   status    Show the working tree status

grow, mark and tweak your common history
   branch    List, create, or delete branches
   commit    Record changes to the repository
   merge     Join two or more development histories together
   rebase    Reapply commits on top of another base tip
   reset     Reset current HEAD to the specified state
   switch    Switch branches
   tag       Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)
   fetch     Download objects and refs from another repository
   pull      Fetch from and integrate with another repository or a local branch
   push      Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.

همانطور که مشاهده میکنید، خروجی دستور git، نمایش داده شده‌است. دلیل آن نیز این است که در فایل configuration، هیچ آرگومانی را به عنوان ورودی آن تعیین نکرده‌ایم. برای اضافه کردن آرگومان‌های موردنظر باید پراپرتی OrginalCommandElements را مقدار دهی کنیم: 

"OriginalCommandElements": ["log", "--oneline"],

بنابراین با فراخوانی دستور Get-GitLog، در اصل دستور git log —oneline فراخوانی خواهد شد:  

PS /> Get-GitLog

e9590e8 init

اما تا اینجا نیز خروجی به صورت رشته‌ایی است. برای داشتن یک خروجی Object، باید پراپرتی OutputHandlers را از Configuration، تغییر دهیم: 

"OutputHandlers": [
  {
    "ParameterSetName": "Default",
    "Handler": "$args[0] | ForEach-Object { $hash, $message = $_.Split(' ', 2) ; [PSCustomObject]@{ Hash = $hash; Message = $message } }"
  }
]

در اینجا توسط args$ به خروجی کامند اصلی دسترسی خواهیم داشت. این خروجی را سپس با کمک ForEach-Object، به یک شیء با پراپرتی‌های Hash و Message تبدیل کرده‌ایم. در اینجا فقط میخواستم روال تهیه یک آبجکت را از کامندهایی که خروجی JSON ندارند، نشان دهم؛ اما خوشبختانه توسط پرچم pretty در git log، امکان تهیه‌ی خروجی JSON را نیز داریم: 

git log --pretty=format:'{"commit": "%h", "author": "%an", "date": "%ad", "message": "%s"}'

در نتیجه عملاً نیازی به split کردن نیست و بجای آن میتوانیم به صورت مستقیم، خروجی را توسط ConvertFrom-Json پارز کنیم: 

"OutputHandlers": [
  {
    "ParameterSetName": "Default",
    "Handler": "$args[0] | ConvertFrom-Json"
  }
]

همچنین درون فایل schema با کمک پراپرتی Parameters، امکان تعریف پارامتر را نیز برای کامند Get-GitLog خواهیم داشت. به عنوان مثال میتوانیم فلگ reverse را نیز به کامند اصلی از طریق PowerShell ارسال کنیم: 

"Parameters": [
  {
    "Name": "reverse",
    "OriginalName": "--reverse",
    "ParameterType": "switch",
    "Description": "Reverse the order of the commits in the output."
  }
],

دقت داشته باشیم که با هربار تغییر فایل schema باید توسط دستور Export-CrescendoModule ماژول موردنظر را تولید کنید:

Export-CrescendoModule -Configuration ./git-ps.json -ModuleName ./git-ps.psm1
Import-Module ./git-ps.psd1

در نهایت cmdletمان به این صورت قابل استفاده خواهد بود:

اشتراک‌ها
لیستی از C# Source Generators

C# Source Generators

A list of C# Source Generators (not necessarily awesome), because I haven't found a good list yet.

C# Source Generators is a Roslyn compiler feature introduced in C#9/.NET 5. It lets C# developers inspect user code and generate new C# source files that can be added to a compilation. 

لیستی از C# Source Generators