در کل به نحوی باید بشود آنرا باز تولید کرد. مثلا یک مثال عمومی ساده درست کنید که این خطا را سبب شود.
خطای null
در کل به نحوی باید بشود آنرا باز تولید کرد. مثلا یک مثال عمومی ساده درست کنید که این خطا را سبب شود.
{ "compilerOptions": { "strict": true, "removeComments": false, "sourceMap": false, "noEmitOnError": true, "target": "ES2020", "module": "ES2020", "outDir": "wwwroot/scripts" }, "include": [ "Scripts/**/*.ts" ], "exclude": [ "node_modules" ] }
<Project Sdk="Microsoft.NET.Sdk.Razor"> <ItemGroup> <PackageReference Include="Microsoft.TypeScript.MSBuild" Version="4.3.5"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> <ItemGroup> <Content Remove="tsconfig.json" /> </ItemGroup> <ItemGroup> <TypeScriptCompile Include="tsconfig.json"> <CopyToOutputDirectory>Never</CopyToOutputDirectory> </TypeScriptCompile> </ItemGroup> </Project>
window.exampleJsFunctions = { showPrompt: function (message) { return prompt(message, 'Type anything here'); } };
namespace JSInteropWithTypeScript { export class ExampleJsFunctions { public showPrompt(message: string): string { return prompt(message, 'Type anything here'); } } } export function showPrompt(message: string): string { var fns = new JSInteropWithTypeScript. ExampleJsFunctions(); return fns.showPrompt(message); }
private const string ScriptPath = "./_content/----namespace-here---/scripts/file.js"; private IJSObjectReference scriptModule;
protected override async Task OnAfterRenderAsync(bool firstRender) { if (scriptModule == null) scriptModule = await JSRuntime.InvokeAsync<IJSObjectReference>("import", ScriptPath);
await scriptModule.InvokeVoidAsync("exported fn name", params);
public partial class MyComponent : IAsyncDisposable
public async ValueTask DisposeAsync() { if (scriptModule != null) { await scriptModule.DisposeAsync(); } }
public static class CurryMethodExtensions { public static Func< A, Func< B, Func< C, R > > > Curry< A, B, C, R >( this Func< A, B, C, R > f ) { return a => b => c => f( a, b, c ); } }
Func< int, int, int, int > addNumbers = ( x, y, z ) => x + y + z; var f1 = addNumbers.Curry(); Func< int, Func< int, int > > f2 = f1( 3 ); Func< int, int > f3 = f2( 4 ); Console.WriteLine( f3( 5 ) );
public static class CurryMethodExtensions { public static Func< C, R > Partial< A, B, C, R >( this Func< A, B, C, R > f, A a, B b ) { return c => f( a, b, c ); } }
Func< int, int, int, int > sumNumbers = ( x, y, z ) => x + y + z; Func< int, int > f4 = sumNumbers.Partial( 3, 4 ); Console.WriteLine( f4( 5 ) );
var obj = new WeakReferenceTest { FirstName = "Vahid" }; var w = new WeakReference(obj); obj = null; GC.Collect(); var weakReferenceTest = w.Target as WeakReferenceTest; if ( weakReferenceTest != null ) Console.WriteLine( weakReferenceTest.FirstName );
public abstract class ThreadSafeLazyBaseSingleton< T > where T : new() { static readonly Lazy< T > lazy = new Lazy< T >( () => new T() ); public static T Instance => lazy.Value; }
var positiveString = "91389681247993671255433422114345532000000"; var negativeString = "-9031583741089631207100208803453423537140000"; var posBigInt = BigInteger.Parse( positiveString ); Console.WriteLine( posBigInt ); var negBigInt = BigInteger.Parse( negativeString ); Console.WriteLine( negBigInt );
معیار پذیرش
اگرچه product backlog ، sprint backlog و نمودار burn-down بخشهای اصلی اسکرام هستند، معیار پذیرش خروجی جانبی بسیار مهمی از فرآیند اسکرام است. بدون معیار پذیرش خوب، یک پروژه محکوم به شکست است.
معیار پذیرش ضرورتاً شفاف کنندۀ داستان است. چنین معیاری مجموعهای از گامهای مختلف را در اختیار توسعه دهنده میگذارد که پیش از آنکه کار تمام شده تلقی شود، باید انجام دهد. معیار پذیرش، توسط صاحب محصول ( product owner ) به کمک مشتری ایجاد میشود. این معیار انتظار از داستان کاربر را تنظیم میکند. استفاده از این معیار درجای خود نقطۀ شروع خوبی برای نوشتن تستهای خودکار یا حتی توسعۀ آزمون محور توسط توسعهدهنده است. بدین طریق، توسعهدهنده چیزی را تولید میکند که مشتری بدان نیاز داشته و آن را میخواهد.
دیگر مزیت معیار پذیرش وقتی آشکار میشود که یک ویژگی در طول یک اسپرینت کامل نشده و نیاز است تا از اسپرینتها خارج شود. در چنین موردی تیم میتواند معیار پذیرش را به عنوان ابزاری به کار گیرد تا بفهمد که داستان کاربر چگونه به قطعات کوچکتری تقسیم شود تا کماکان ارزشی را برای مشتری فراهم کرده تا بتواند در یک اسپرینت کامل شود.
این سوالی است که ممکن است هر توسعه دهندهای به آن در ابتدا پاسخ دهد: «جهت بالابردن سرعت و کارآیی!» حال اگر بپرسیم چگونه؟ توضیحات چندان دقیقی ارائه نمیشود.
SELECT [computer_id],[nic_device_id],[nic_vendor_id],[nic_desc] FROM [eXpress].[dbo].[nics]
فرض کنید در جدول بالا ایندکس گذاری انجام نشده باشد و قصد داشته باشید رکوردهایی را دریافت نمایید که در آنها computer_id>5100 باشد. اس کیو ال سرور مجبور است کلیه رکوردهای جدول را جهت اعمال شرط بررسی نماید.
حال، برروی ستون computer_id ایندکسی را اعمال مینماییم و شرط computer_id>5100 را مجدد بررسی میکنیم. اس کیو ال از محل رکوردهای با مقادیر بزرگتر از 5100 اطلاع دارد و از جستجوی کل جدول اجتناب میکند. چرا؟ بدلیل اینکه براساس این ستون مرتب شده است.
دو نوع ایندکس اصلی وجود دارد: ایندکس خوشهای و ایندکس غیرخوشهای
نحوهی ذخیره سازی فیزیکی رکوردها را تغییر میدهد. هنگامیکه یک ایندکس خوشهای را ایجاد میکنید، بر روی یک ستون (یا ترکیبی از چند ستون)، اس کیو ال سرور رکوردها را براساس ستون/ها بصورت صعودی مرتب شده (مانند یک دیکشنری که کلیه کلمات بصورت الفبایی قرار گرفتهاند) ذخیره مینماید.
بوسیله ایندکس زیر تمام رکوردها براساس ستون computer_id مرتب شده ذخیره میگردند.CREATE CLUSTERED INDEX [IX_CLUSTERED_COMPUTER_ID] ON [dbo].[nics] ([computer_id] ASC)
همانطور که اشاره شد، رکوردها بصورت مرتب شده براساس ستون انتخاب شدهی در
جدول نگهداری میشوند. اما این مرتب سازی توسط ساختار BTree بهشرح زیر انجام
خواهد شد. جدول زیر را در نظر داشته باشید:
فرض کنید بعد ایندکس گذاری ستون StudId جدول فوق، درخت BTree زیر ایجاد میگردد که این ساختار بهصورت جداگانهای بر روی دیسک ذخیره میگردد. در این درخت، مقدار گره سمت چپ ریشه از آن کمتر و مقدار گره سمت راست ریشه از آن بیشتر است (البته عکس این فرض نیز امکان پذیر است).
و سپس کوئریهای زیر را صادر میکنید:
Select * from student where studid = 103; Select * from student where studid = 107;
در صورتیکه تعداد رکوردها کم باشند، تفاوت کارآیی جداول دارای ایندکس و بدون ایندکس قابل لمس نخواهد بود.
این نوع ایندکس، تغییری در نحوهی ذخیره سازی رکوردها انجام نمیدهند. ولی شیء دیگری را که شامل ستون/هایی که قرار است ایندکس شوند و اشارهگر به رکورد (RID) هستند، در جدول ایجاد میکند. برای مثالی از ایندکس غیرخوشهای در دنیای واقعی، میتوان به فهرست انتهای کتابها که شامل عناوین و شماره صفحهی مربوطه میباشد، اشاره کرد.
نکته: RID به موقعیت فیزیکی رکورد اشاره خواهد کرد و شامل شناسه، شماره صفحه و تعداد رکوردهای در یک صفحه میباشد.
برای درک بهتر به سناریوی زیر دقت کنید:
کتابی داریم که شامل 1200 صفحه میباشد و فهرست مطالب آن شامل عناوین و
شماره صفحات عناوین میباشد. حال اگر عنوان درخواستی A در صفحات 700، 300،
800 قرار داشته باشد، برای رفتن به این صفحات، مراحل زیر را برای هر یک طی
خواهید کرد:
مراحل فوق برای یافتن عنوان A واقع شدهی در صفحه 700 انجام شد که همین مراحل نیز برای سایر صفحات میتواند انجام شود. در این مثال، صفحه فهرست مطالب کتاب، به ایندکس غیرخوشهای تعبیر خواهد شد.
این نوع ایندکسها جهت ستون هایی مفید هستند که مقادیر آن تکرار خواهد شد؛ مانند جدولی با بیش از چند میلیون رکورد که دارای ستون نوع حساب است، ولی تعداد نوع حساب منحصر بفرد محدودی را خواهد داشت. فرض کنید مقادیر منحصر بفرد، ستون نوع حساب A، B، C باشد. زمانیکه برروی این ستون ایندکس گذاری غیرخوشهای انجام میشود، فهرست ما دارای سه عنوان خواهد بود که هر عنوان به صفحات مربوط به همان عنوان اشاره خواهد کرد. به این ترتیب هنگامیکه برروی نوع حساب عملیات جستجو انجام شود، اس کیو ال میداند رکوردهای نوع حساب مثلا A در کدام صفحات قرار دارد و بهسرعت رکوردهای متناظر را پیدا مینماید.
A: 300, 700, 800 B: 100, 110 C: 600, 1200
ایندکس غیرخوشه ای توسط دستور زیر ایجاد میگردد:
CREATE NONCLUSTERED INDEX [IX_NONCLUSTERED_COMPUTER_ID] ON [dbo].[nics] ([computer_id] ASC)
نکته: یک جدول میتواند بیش از یک ایندکس غیرخوشهای و فقط و
فقط یک ایندکس خوشهای داشته باشد.
اشارهگر به رکورد (RID) در یک جدول دارای ایندکس خوشهای، کلید ایندکس خوشهای خواهد بود.