بسیاری از برنامه نویسان قدیمی و افرادی که علاقه زیادی به مایکروسافت و برنامه های انحصار طلب مایکروسافت نداشتند اصلی ترین علت را انحصار طلبی و عدم توانایی اجرا در سایر پلتفرم ها مطرح مینمودند. مایکروسافت در چند سال اخیر به لزوم اوپن سورس، چند پلتفرم بودن پی برده است که سیستم هایی نظیر Azure و سایر سرویس ها را برای رفع این نواقص ارائه داده است. یکی از پروژه های اساسی مایکروسافت در زمینه برنامه نویسی NET CORE. میباشد. مایکروسافت اساسی ترین پلتفرم برنامه نویسی خود را با این پروژه ارائه داده است. NET CORE. پلت فرم اوپن سورس و سریع میباشد که برای همه دیوایس ها از جمله موبایل، وب ، اپلیکیشن های ویندوزی ، لینوکس و MAC میباشد که شما قادر هستید برنامه های خود را با این فریم ورک و پلتفرم جدید به راحتی قابل حمل کرده و در تمامی دیوایس ها پیاده کنید.

ویژگیهای اساسی NET CORE. چیست؟

اوپن سورس: اولین ویژگی مثبتی که همه برنامه نویسان را مجددا به سمت مایکروسافت کشانده است اوپن سورس بودن آن میباشد که شما میتوانید این پلتفرم را بسته به نیاز خود شخصی سازی کنید.

NET CORE. و برنامه های اجرا شده در این پلتفرم بسیار سبک و کم حجم میباشند.

Cross Platform میباشد، شما با NET CORE. به معنای کامل میتوانید بصورت یکپارچه در تمامی سیستم عامل ها و دیوایس ها پروژه خود را پیاده کنید.

توسعه راحت و سریع NET CORE. باعث شده است پروژه ها و استارت آپ های زیاد به جهت راحتی در تیم برنامه نویسی این پلتفرم را انتخاب کنند.

پشتیبانی از Github و نیوگت برای برنامه های اوپن سورس

هزینه های پایینتر، از دیگر مشکلات برنامه های ویندوزی هزینه نگهداری و منابع مورد نیاز آنها بود. با کاهش محسوس حجم برنامه ها و منابع مورد نیاز میتواند یکی دیگر از بهترین مزیت های NET CORE. را هزینه نگهداری پایین آن درنظر گرفت.

پشتیبانی از خط فرمان بسیار قدرتمند برای نصب بسته های پیش نیاز

.NET CORE جایگزین دات نت فریم ورک میباشد؟

بسیاری از متخصصین در ابتدای ارائه دات نت کور بر این باور بودند که مایکروسافت در حال آماده سازی جهت کوچ به سمت اوپن سورس میباشد و به احتمال زیاد آینده دات نت فریم ورک رو به اتمام میباشد و بایستی جای خود را به دات نت کور بدهد. ولی طبق بررسی های انجام شده قرار نیست چنین اتفاقی بیافتد و فعلا تا اطلاع ثانوی مایکروسافت همچنان قصد ارائه آپدیت و امکانات جدید به دات نت فریم ورک را دارد.

در حال حاضر شما توسط دات نت کور میتوانید برنامه های تحت وب، کتابخانه ای و کنسول را برنامه نویسی کنید. البته همانطور که میدانید در برنامه های Asp.net خیلی وقت هست که مایکروسافت از وب فرم پشتیبانی نمیکند و در صورتی که قصد استفاده از Asp.net روی پلتفرم .NET CORE میبایست حتما روی MVC پروژه های خود را پیاده سازی کنید.

کتابخانه هایی که برای دات نت فریم ورک و ابزارهایی که برای آن تهیه شده است به قدری زیاد هست که برنامه نویسان .Net احتمالا با شنیدن این موضوع که هنوز دات نت کور ابزارهای بسیار کمتری نسبت به .Net دارد نا امید خواهند شد. ولی نبایستی فراموش کرد که پلتفرم جدید مایکروسافت بسیار جدید میباشد و نیاز به زمان زیادی دارد تا همانند .Net از لحاظ کلاس ها، ابزارها و … تکمیل گردد.

بعد از ارائه موفق .NET CORE مایکروسافت اعلام کرده است که Asp.NET 5 و همچنین MVC5 قابلیت اجرا پیاده سازی بر روی دات نت کور را دارا میباشند. همچنین هم اکنون در صورتی که شما برنامه خود را با .NET CORE و ASP.NET 5 پیاده سازی کرده اید میتوانید برنامه های خود را علاوه بر ویندوز با Mono Runtime روی لینوکس و مک اجرا کنید.

.NET CORE روی سرورهای فعلی ویندوز اجرا میگردد؟

یکی از اساسی ترین سوالات برنامه نویسان مخصوصا برنامه نویسان .NET این هست که آیا میتوانند برنامه های Asp.Net که بر پایه .Net Core پیاده سازی شده اند را روی سرور ویندوز اجرا کنند؟ جواب این سوال شاید برای خیلی از کاربران ساده تر از این میباشد که بخواهیم روی آن بحث کنیم، ولی واقعیت این هست که در حال حاضر تمامی شرکت های هاستینگ سرور های خودرا آماده برای .Net Core نکرده اند. با توجه به اینکه اجرای این برنامه ها کمی متفاوت میباشد احتمالا شرکت هایی که به امنیت بیشتر اهمیت میدهند هنوز ریسک این را نپذیرند که در اولین فرصت .Net Core را پشتیبانی کنند. البته کنترل پنل محبوب پلسک بصورت پیش فرض از .Net Core پشتیبانی میکند و حتی در نسخه جدید Onyx هنگام نصب پلسک میتوانید .Net Core را براحتی بدون هیچ دانشی نصب کنید.

در انتها پیشنهاد میگردد در صورتی که برنامه نویس .Net هستید شک نکنید که بایستی به دات نت کور کوچ کنید و در اولین فرصت شروع به یادگیری آن کنید. همچنین در صورتی که میخواهید برنامه نویسی را شروع کنید باهم پیشنهاد میگردد در کنار سایر زبانها و پلتفرم ها، دات نت کور را نیز در لیست انتخاب پلتفرم یادگیری خود نیز قرار دهید.

به عبارت ساده سی اس اس (CSS) زبانی است که با استفاده از آن می توان ظاهر کدهای زبان های Markupیی همچون اچ تی ام ال را تغییر داد. در واقع اچ تی ام ال (HTML) ساختار یک صفحه از وب سایت را ایجاد می کند و این در حالی است که سی اس اس (CSS) نحوه به نمایش در آمدن عناصر مختلف زبان اچ تی ام ال (HTML) را مشخص می سازد:

the relationship between html and css

برای روشن شدن مطلب، زبان اچ تی ام ال (HTML) را به اسکلت یک ساختمان تشبیه می کنیم. همانطور که در تصویر فوق می بینیم اسکلت ساختمان عاری از هرگونه زیبایی ظاهری فقط چهارچوب اصلی ساختمان را مشخص می سازد. در سمت چپ، همان سازه را می بینیم که با اعمال قوانین سی اس اس (CSS) ظاهری متفاوت به خود گرفته است. همانطور که در سمت چپ تصویر می بینیم با اعمال سه سری متفاوت از قوانین سی اس اس (CSS) توانسته ایم ساختاری یکسان را به سه مدل مختلف نمایش دهیم.

زبان CSS مخفف واژگان Cascading Style Sheet به معنی "الگوهای آبشاری" است. علت اختصاص صفت Cascading به معنی "آبشاری" به این زبان این است که قوانین این زبان به صورت آبشاری یا از بالا به پایین اعمال می شوند. برای روشن شدن این مسئله ابتدا نیاز است تا راه های مختلفی که از آن طریق می توان کدهای سی اس اس (CSS) را روی یک سند اچ تی ام ال (HTML) اعمال کرد مورد بررسی قرار دهیم:

به طور کلی سه راه برای استفاده از کدهای سی اس اس در یک سند اچ تی ام ال وجود دارد که عبارتند از:

Inline: منظور از این اصطلاح این است که می توان کدهای سی اس اس (CSS) را در قالب Attribute، داخل تگ های اچ تی ام ال (HTML) استفاده کرد. برای روشن شدن این مطلب کد زیر را مد نظر قرار می دهیم:

این یک پاراگراف است

همانطور که می بینیم داخل تگ آغازین

کلیدواژه style را نوشته و یک علامت مساوی مقابل آن قرار می دهیم. سپس داخل علامت های " " به هر تعداد Property که بخواهیم می توانیم مورد استفاده قرار دهیم و آن ها را با یک فاصله از یکدیگر جدا می سازیم. تا حد ممکن استفاده از این نوع نوشتن کدهای سی اس اس (CSS) توصیه نمی شود چرا که اگر بخواهیم روزی مقادیر یک تگ را تغییر دهیم، می بایست شروع به ویرایش کلیه کدهای سی اس اس (CSS) در کلیه فایل های اچ تی ام ال (HTML) نماییم.

2. Internal: منظور از این اصطلاح این است که می توان کلیه کدهای سی اس اس (CSS) را در تگ یک سند اچ تی ام ال (HTML) نوشت:

این یک پاراگراف است

در نسخه های قبلی اچ تی ام ال (HTML) برای تگ

این یک پاراگراف است

همانطور که در کد فوق می بینیم، ابتدا تگ را کامنت کرده ایم سپس در تگ ابتدا تگ های

منبع

https://natilos.ir/

بازی زندگی (Life Game)

برای اثبات مفاهیم ارائه شده از بازی زندگی طراحی شده از سوی Conway به عنوان مسئله استفاده کرده‌ایم. این بازی بدون بازیکن است و قواعد ساده‌ای دارد:

دنیا از یک ماتریس تشکیل یافته است که در آن هر سلول دو حالت زنده یا مرده دارد.

تنها ورودی بیرونی، حالت اولیه است.

تعامل سلول جاری با سلول همجوار افقی، عمودی و قطری حالت کنونی سلول را تعیین می‌کند.

یک سلول زنده که کمتر از دو همسایه آن زنده باشند، می‌میرد.

یک سلول زنده که دو یا سه همسایه‌اش زنده باشند، برای نسل بعدی زنده می‌ماند.

یک سلول زنده که بیش از سه سلول همسایه‌اش زنده باشند، می‌میرد.

یک سلول مرده که دقیقاً سه سلول همسایه‌اش زنده باشند، زنده می‌شود.

بنابراین طرح ما این است که یک ماتریس بزرگ داشته باشیم و آن را با مقادیر تصادفی (0 یا 1) پر کنیم و این حالت اولیه را ارسال کرده و نتیجه را رندر کنیم، سپس حالت بعدی را محاسبه کرده و آن را مجدداً رندر کنیم و این مرحله اخیر را چندین بار تکرار کنیم.

ما می‌خواهیم این راه‌حل را با سه راهبرد پیاده‌سازی کنیم: جاوا اسکریپت خالص، وب‌اسمبلی، و وب ورکرها. پیچیدگی زمانی الگوریتم ما روی همه رویکردها برابر با (O(m*m است که n عرض دنیا و m ارتفاع آن است. از آنجا که رندر برای هر سه رویکرد یکسان است، آن را در اندازه‌گیری‌های خود لحاظ نمی‌کنیم.

جاوا اسکریپت محض

معماری زیرساختی برای این رویکرد شامل ایجاد یک بازی جدید و سپس ایجاد و ارسال حالت نخست (ماتریسی پر شده از 0 و 1) به آن است. کامپوننت game این حالت را نگه‌داری می‌کند و تابعی به نام next بازمی‌گرداند که حالت بعدی را هنگام فراخوانی بازگشت می‌دهد. در این صورت تابع ()getNextState را از فایل environment.js فراخوانی می‌کنیم که پیاده‌سازی جاوا اسکریپت خالص است.

const next = game(

document.getElementById('game'),

COLUMNS,

LINES,

createGameMatrix(LINES, COLUMNS), // generates the initial state

strategy(

STRATEGY,

COLUMNS,

LINES,

initialConfig

) // Defines which strategy to use to calculate the next state

function loop() {

next().then(() => {

requestAnimationFrame(loop);

loop()

const next = game(

document.getElementById('game'),

COLUMNS,

LINES,

createGameMatrix(LINES, COLUMNS), // generates the initial state

strategy(

STRATEGY,

COLUMNS,

LINES,

initialConfig

) // Defines which strategy to use to calculate the next state

function loop() {

next().then(() => {

requestAnimationFrame(loop);

});

};

loop();

داخل کامپوننت environment.js همچنان مسئله را به تابع‌های تخصصی کوچک‌تر افراز می‌کنیم. بدین ترتیب به روشی آسان‌تر می‌توانیم بهینه‌سازی کامپایلر JIT را تحریک کنیم. این بهینه‌سازی‌ها را در مقاله بعدی بررسی خواهیم کرد. این تابع‌ها به محاسبه حالت کنونی همسایه‌های فوقانی، تحتانی و کناری پرداخته و همه حالت‌های گوشه‌ای را پوشش می‌دهند.

میانگین سرعت این محاسبه حالت از 9 تا 4 میلی‌ثانیه برای یک ماتریس 800×450 متفاوت است. برای مشاهده تصویر در ابعاد اصلی روی این لینک کلیک کنید.

ممکن است از این که چقدر این محاسبات برای حالت بعدی متفاوت هستند و یا این که چرا این همه تابع وجود دارد شگفت‌زده شوید. برای پاسخ به این سؤال باید با طرز کار کامپایلرهای JIT آشنا باشیم و بدانیم که چگونه این وضعیت موجب شده است که جاوا اسکریپت امروزه تا این حد سریع باشد. در بخش بعدی این نوشته این موضوع را بررسی می‌کنیم.

اندکی از تاریخچه جاوا اسکریپت

جاوا اسکریپت در سال 1995 از سوی «برندن آیک» (Brendan Eich) طراحی شد و هدف وی ارائه زبانی بود که طراحان به کمک آن بتوانند اینترفیس‌های دینامیک را با آن به سادگی پیاده‌سازی کنند. به بیان دیگر جاوا اسکریپت برای این ساخته نشده که سریع باشد؛ بلکه هدف اولیه این بود که لایه رفتاری را به صفحه‌های HTML به روشی راحت و سرراست اضافه کند.

ایتنرنت در دهه 90 میلادی

زمانی که جاوا اسکریپت معرفی شد، اینترنت این گونه به نظر می‌رسید.

جاوا اسکریپت در ابتدا یک زبان تفسیری بود. بدین ترتیب فاز آغازین سریع‌تر می‌شد، چون مفسر تنها کافی بود که خط نخست کد را بخواند تا بتواند آن را به بایت‌کد ترجمه کرده و به طرز صحیح اجرا کند. برای نیازهای اینترنت در دهه 1990 میلادی، جاوا اسکریپت این کار را به طرز خوبی انجام می‌داد. مشکل زمانی بروز کرد که اپلیکیشن‌ها رفته‌رفته پیچیده‌تر شدند.

در دهه 2000 میلادی فناوری‌هایی مانند Ajax موجب شدند که وب اپلیکیشن‌ها، پویاتر شوند، جیمیل در سال 2004 و گوگل مپ در سال 2005 آغازگر روندی برای استفاده از این فناوری ای‌جکس بودند. این روش جدید برای ساخت وب اپلیکیشن‌ها موجب شد که بیشتر بخش منطقی برنامه در سمت کلاینت نوشت شود. در این زمان جاوا اسکریپت باید عملکرد خود را ارتقا می‌داد و این اتفاق در سال 2008 با ظهور گوگل و موتور V8 آن که همه کدهای جاوا اسکریپت را به طور بی‌درنگ به بایت‌کد کامپایل می‌کرد رخ داد. اما اینک شاید بپرسید طرز کار کامپایلرهای JIT چگونه است؟

آشنایی با طرز کار کامپایلرهای JIT

اگر بخواهیم کامپایلرهای JIT را به طور خلاصه توضیح دهیم، زمانی که کد بارگذاری شد، کد منبع به یک بازنمایی درختی تبدیل می‌شود که «درخت ساختار مجرد» (Abstract Syntax Tree) یا AST نامیده می‌شود. پس از آن بسته به این که از چه موتور/سیستم عامل/پلتفرمی استفاده می‌شود، یا یک نسخه مبنا از کد کامپایل می‌شود و یا بایت‌کد تولید می‌شود که باید تفسیر شود.

در این مرحله profiler به رصد و گردآوری داده‌های اجرای کد می‌پردازد. البته این توضیح بسیار مختصر بوده و تفاوت‌هایی در میان موتورهای مرورگر مختلف در این زمینه وجود دارد.

در گام نخست، همه چیز از تفسیر عبور می‌کند، این فرایند تضمین می‌کند که کد پس از ایجاد AST سریع‌تر اجرا می‌شود. زمانی که قطعه کدی چندین بار اجرا می‌شود، مانند تابع ()getNextState ما، تفسیر عملکرد خود را از دست می‌دهد، زیرا باید قطعه کد یکسانی را به طور مکرر تفسیر کند و زمانی که این اتفاق بیافتد profiler این قطعه کد را به صورت «کد گرم» (Warm Code) علامتگذاری می‌کند و «کامپایلر مبنا» (Baseline Compiler) وارد عمل می‌شود.

کامپایلر مبنا

برای این که طرز کار JIT را بهتر نشان دهیم از این پس از قطعه کد زیر به عنوان مثال استفاده می‌کنیم:

function sum (x, y) {

return x + y;

}

[1, 2, 3, 4, 5, '6', 7, 8, 9, 10].reduce(

(prev, curr) => sum(prev, curr),

function sum (x, y) {

return x + y;

}

[1, 2, 3, 4, 5, '6', 7, 8, 9, 10].reduce(

(prev, curr) => sum(prev, curr),

0

);

زمانی که پروفایلر یک قطعه کد را به صورت «کد گرم» علامتگذاری می‌کند، JIT کد را به کامپایلر مبنا می‌سپارد که یک کد کامپایل شده می‌سازد و در همین حال پروفایلر همچنان به گردآوری داده‌ها در ارتباط با فراوانی و انواع کدهای اجرا شده ادامه می‌دهد. زمانی که این بخش از کد اجرا می‌شود (در مثال فرضی ما بخش ;return x + y است) JIT تنها کافی است این بخش کامپایل شده را مجدداً اجرا کند. زمانی که کد گرم چندین بار به روش مشابه فراخوانی شود، به صورت «کد داغ» (hot code) علامتگذاری می‌شود.

کامپایلر بهینه‌ساز

زمانی که یک قطعه کد به صورت کد داغ علامت‌گذاری شود، «کامپایلر بهینه‌ساز» (Optimizer Compiler) یک نسخه باز هم سریع‌تر از این کد می‌سازد. این وضعیت تنها بر مبنای این فرضیه عمل می‌کند که کامپایلر بهینه‌ساز، نوع متغیرها یا شکل شیءهای مورد استفاده در کد را بهینه‌سازی می‌کند. در مورد مثال فرضی ما می‌توان تصور کرد که «کد داغ» ;return x + y هر دو مقدار x و y را به صورت number فرض می‌کند.

مشکل این است که در مواردی کد با چیزی مواجه می‌شود که کامپایلر بهینه‌ساز انتظار ندارد، برای نمونه در مورد مثال ما با (‘sum(15, ‘6 فراخوانی می‌شود، چون y یک string است. زمانی که این اتفاق می‌افتد، پروفایلر فرض می‌کند که فرضیات آن اشتباه بوده است و همه چیز را کنار گذاشته و به نسخه کامپایل شده مبنا (یا تفسیری) باز می‌گردد. این مرحله «غیر بهینه‌سازی» (Deoptimization) نام دارد. برخی اوقات این اتفاق چنان مکرر رخ می‌دهد که حتی نسخه بهینه شده نسبت به نسخه مبنا کندتر می‌شود.

جمع‌بندی

برخی موتورهای جاوا اسکریپت در خصوص کمّیت تلاش‌های بهینه‌سازی محدودیت‌هایی دارند و زمانی که به این حد برسند دیگر برای بهینه‌سازی تلاش نمی‌کنند. برخی دیگر مانند V8 به صورت شهودی زمانی که می‌بینند احتمالاً کد «غیربهینه‌سازی» خواهد شد از بهینه‌سازی آن اجتناب می‌کنند. این فرایند bailing out نام دارد.

بنابراین به طور خلاصه مراحل کامپایلر JIT را می‌توان به صورت زیر توصیف کرد:

تجزیه

کامپایل

بهینه‌سازی/غیر بهینه سزی

اجرا

Garbage Collector

منبع

https://blog.faradars.org/