علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت بیست و یکم

آغاز فصل سوم:

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

مشکلی که در توزیع اسمبلی‌های عمومی وجود دارد این است که شما باید این اطمینان را کسب کنید که اسمبلی شما، همیشه همان اسمبلی خواهد بود و تغییری در آن رخ نخواهد داد. فرض کنید که شما از یک اسمبلی که توسط شرکت تلریک تهیه شده است استفاده کرده‌اید و برنامه‌ی شما به خوبی با آن کار می‌کند. ولی چه اتفاقی می‌افتد که اگر برنامه‌ی دیگری بعد از شما نصب شود و از همان اسمبلی، منتها از نسخه‌ی دیگر آن استفاده می‌کند؟ بله برنامه‌ی شما احتمال زیادی دارد که در این حالت به مشکل بر بخورد یا اینکه شخص دیگری یک اسمبلی دیگری همنام اسمبلی و هم نسخه‌ی اسمبلی شما تولید می‌کند. برای رفع این مشکلات مایکروسافت تمهیداتی را اندیشیده است که ما به آن می‌گوییم «اسمبلی با نام قوی Strong Name Assembly».

اسمبلی‌ها به دو دسته تقسیم می‌شوند: اسمبلی‌های با نام قوی و اسمبلی هایی با نام ضعیف ( این مورد در مستندات مایکروسافت نیست و توسط نویسنده‌ی کتاب، این اصطلاح ایجاد شده است).

در قسمت دوم گفتیم که اسمبلی‌ها از قسمت‌هایی چون جداول مانیفست، هدرها، متادیتاها و ... تشکیل می‌شوند. اسمبلی‌های نام قوی هم به همین شکل هستند. فقط توسط جفت کلید عمومی و خصوصی محافظت و امضا می‌شوند که برای ناشر، یک کلید منحصر به فرد را ایجاد می‌کنند و به ناشر این اطمینان را می‌دهند که اگر جفت کلیدی را که در دست شما است، به کسی ندهید، هیچ کس دیگری نمی‌تواند اسمبلی را با مشخصات اسمبلی شما امضاء کند.

حال یک اسمبلی نام قوی، دارای چهار خصوصیت است: نام اسمبلی بدون پسوند، نگارش، فرهنگ (Culture) و کلید عمومی.

از آنجا که خود کلید عمومی بسیار بزرگ می‌باشد، ما برای استفاده‌ی راحت‌تر، از توکن کلید عمومی استفاده می‌کنیم که طول کمتری دارد. توکن کلید عمومی، یک مقدار هش شده است که از کلید عمومی به دست می‌آید: 

"MyTypes, Version=1.0.8123.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
"MyTypes, Version=1.0.8123.0, Culture="en­US", PublicKeyToken=b77a5c561934e089" 
"MyTypes, Version=2.0.1234.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
"MyTypes, Version=1.0.8123.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

استفاده از فضای نام 

System.Reflection.AssemblyName

به شما اجازه‌ی ساخت و دریافت اطلاعاتی را از اسمبلی‌ها می‌دهد؛ هر نوع اطلاعاتی را که شامل 4 خصوصیت بالا می‌شود، به شما می‌دهد.

از آنجا که مطالب مربوطه به  امضاء کردن اسمبلی، در سایت جاری موجود می‌باشند، این مباحث را می‌توانید از طریق این مقاله "نام قوی" دنبال کنید تا در این باره گزافه گویی نکرده باشیم .

مکانیزم اعمال این امضاء بدین شکل است که بعد از ساخت فایل PE که شامل مانیفست است، کل محتویات آن ( به جز امضاهای شناسایی و هدر (Checksum) و اطلاعات مربوط به نام قوی) هش می‌شوند و سپس این مقدا هش شده توسط کلید خصوصی امضاء می‌شود و در همان PE، در بخش هش نشده‌ای به نام Reserved Section ذخیره می‌گردند و در نهایت CLR Header برای ارتباط با این بخش آپدیت می‌شود. 

تصویر زیر توضیح بند بالا را نشان می‌دهد:

 

مختصری در مورد GAC

اگر مقاله‌ی بالا را خوانده باشید، الان باید بدانید که GAC، وظیفه‌ی رجیستر و توزیع اسمبلی نام قوی را بر عهده دارد؛ ولی چرا باید اینکار را به GAC، واگذار کنیم؟ فرض کنید دو اسمبلی با نام‌های dotnettips.dll وجود دارند. اگر قرار باشد هر دو داخل یک دایرکتوری قرار بگیرند، مسلما اسمبلی دوم بر روی اسمبلی اولی overwrite خواهد شد. درنتیجه کاری که GAC انجام می‌دهد، جلوگیری از این اتفاق است و GAC مدیریت می‌کند که در داخل مسیر
%SystemRoot%\Microsoft.NET\Assembly
زیرشاخه هایی ایجاد شوند و اسمبلی‌ها در آن‌ها قرار بگیرند.

هر اسمبلی را که توزیع می‌کنید، حتما حداقل به یک اسمبلی نام قوی ارجاع خواهد داشت؛ دلیل این گفته هم وجود فضای نام system.object در اسمبلی mscorlib است. برای همین، موقعیکه شما با csc، کامپایل می‌کنید، از سوئیچ reference استفاده می‌شود تا ارجاعی را به نام اسمبلی مورد نظر داشته باشد. اگر نام اسمبلی به طور کامل به همراه مسیر ذکر شود که مستقیما از همانجا فراخوانی می‌شود؛ در غیر این صورت مسیرهای زیر مورد بررسی قرار می‌گیرند:
  1. مسیر پوشه‌ی کاری برنامه
  2. مسیر کامپایلر CSC
  3. هر مسیری که با سوئیچ lib به کامپایلر معرفی کرده باشید.
  4. هر مسیری که با متغیرهای Lib Environment مشخص شده باشند.
بنابراین اگر شما مثلا از یک اسمبلی مانند system.drawing استفاده کرده باشید، کمپایلر به طور خودکار دستور زیر را صادر می‌کند:
/reference:System.Drawing.dll
و همانطور که گفته شد، کامپایلر شروع به اسکن دایرکتوری‌ها می‌کند و در نهایت آن را در مسیر خود کامپایلر، یعنی مورد 2 پیدا می‌کند. برنامه کمپایل می‌شود، ولی این اسمبلی همان اسمبلی نیست که برنامه در زمان اجرا، مورد استفاده قرار می‌دهد؛ چون این اسمبلی یک اسمبلی نام قوی است و انتظار می‌رود تا در مسیر مورد تایید GAC یافت شود. به همین دلیل است که موقع نصب دات نت فریم ورک، از هر اسمبلی، دو نسخه بر روی سیستم کپی می‌شود. یکی در مسیر کامپایل و دیگری برای GAC.
در ضمن اسمبلی‌های موجود در مسیر کامپایلر به هیچ عنوان اهمیتی به نوع ماشین نمی‌دهند؛ چون متادیتاهای اسمبلی آن‌ها اهمیت دارند نه کد IL آن‌ها. کد IL فقط در زمان اجرا، برای ما اهمیت دارد و در زمان کامپایل، همان متادیتا کفایت می‌کند و در نهایت برنامه موقع اجرا، با توجه به نوع ماشین x86,x36,ARM، اسمبلی مورد نیاز خود را از طریق GAC فراهم می‌کند که هر یک از اسمبلی‌های مخصوص هر ماشین، توسط GAC، در داخل زیر شاخه‌های مخصوص خود قرار گرفته‌اند.
‫۸ سال و ۵ ماه قبل، جمعه ۲۴ اردیبهشت ۱۳۹۵، ساعت ۰۴:۵۵
وحید نصیری وحید نصیری
نظرات مطالب
روش نصب اندروید 10 بر روی گوشی‌های قدیمی سامسونگ
روش اصلاح daylight saving time در سیستم عامل اندروید


باتوجه به اینکه از امسال دیگر تغییر ساعت بهاری و تابستانی را نداریم، از ابتدای سال، سیستم عامل‌های اندرویدی، یک ساعت جلوتر را نمایش می‌دهند که در ابتدا تصور بر این بود که مشکل از اپراتورهاست، اما اینطور نیست! ساعت ارسالی توسط آن‌ها صحیح است. مشکل از قدیمی بودن بانک اطلاعاتی tzdata سیستم عامل‌های اندرویدی است.

نگارش جدید و کامپایل شده‌ی این فایل‌ها را از اینجا می‌توانید دریافت کنید: tzdata-new.zip

محل ذخیره شدن بانک اطلاعاتی time-zones در اندروید

بسته به نگارش اندروید شما، یکی از مکان‌های زیر، محل ذخیره سازی دو فایل tzdata و tz_version است:
/data/misc/zoneinfo/tzdata
/system/usr/share/zoneinfo
/apex/com.android.tzdata/etc/tz/tzdata
برای مثال بر روی اندروید 10 من (که روش نصب آن در این مطلب آمده)، مسیر آخری، مسیر اصلی و تاثیرگذار است.


مشکل! به روز رسانی مسیرهای سیستمی اندروید، نیاز به دسترسی root دارند!

تا اینجا مشخص شد که برای رفع مشکل time-zone و به روز رسانی اطلاعات آن، باید دو فایل tzdata و tz_version را در مسیرهای یاد شده، بازنویسی کنیم؛ اما ... اندروید چنین اجازه‌ای را نمی‌دهد!
در سیستم عامل LineageOS 17.1 ای که من نصب کردم، می‌توان با نصب برنامه‌ی معروف Magisk، دسترسی روت پیدا کرد. روش نصب آن هم به صورت زیر است:
1) فایل apk آن‌را از این آدرس دریافت کرده و پسوند آن‌را به zip. تغییر دهید.
2) سیستم را ری‌استارت کرده و رفتن به گزینه‌ی recovery را انتخاب کنید تا پس از ری‌استارت سیستم، وارد برنامه‌ی TWRP شویم (که روش نصب آن در مطلب جاری بحث شده).
3) در برنامه‌ی TWRP، گزینه‌ی install را انتخاب و سپس فایل zip. برنامه‌ی magisk را انتخاب و نصب کنید.
4) پس از نصب، یکبار هم کش را پاک کنید (Wipe cache/dalvik).
5) در آخر بر روی دکمه‌ی Reboot System تا ... وارد اندروید شوید.
 6) پس از راه اندازی سیستم، برنامه‌ی Magisk را اجرا کنید تا مرحله‌ی آخر نصب آن به پایان برسد (یکسری از فایل‌ها را نیاز دارد تا از اینترنت دریافت و نصب کند؛ این نصب، از github و به صورت خودکار است).

پس از نصب magisk، برنامه‌ی total commander را هم نصب کنید. به محض اجرای آن، پیام درخواست دسترسی root آن هم ظاهر می‌شود (این برنامه‌ی magisk هست که این درخواست را تشخیص داده و مدیریت می‌کند) و نیاز است این دسترسی را بدهید تا بتوان:
 1) به مسیر file system root و سپس apex/com.android.tzdata/etc/tz/tzdata وارد شد و دو فایل موجود و قدیمی tzdata و tz_version را به نحو متداولی پاک کرد.
 2) سپس دو فایل جدید tzdata و tz_version را (که لینک دریافت آن کمی بالاتر ارائه شد) به سیستم خود منتقل کنید (همانند تمام فایل‌های دیگر از طریق usb) و در آخر با استفاده از total commander ای که اکنون دسترسی root هم دارد، این فایل‌ها را به مسیر یاد شده، کپی کنید.
 3) اکنون سیستم را ری‌استارت کنید تا تنظیمات جدید خوانده شوند (همانند تصویر زیر، که در آن منطقه زمانی جدید 3:30+ قابل مشاهده‌است):

یک نکته: « Magisk-Modules-Repo / Systemless_TZData » در صورت به روز شدن، این کار نصب دستی tzdata را به صورت خودکار انجام می‌دهد که در زمان نگارش این مطلب، هنوز به‌روز نشده.

‫۱ سال و ۵ ماه قبل، پنجشنبه ۱۰ فروردین ۱۴۰۲، ساعت ۱۶:۵۱
وحید نصیری وحید نصیری
اشتراک‌ها
Bootstrap 4.5.0 منتشر شد
  • New interaction utilities. Quickly set user-select with the new utilities and Sass map.
  • New Reboot style for pointer cursors. We now include a role="button" selector in Reboot to set cursor: pointer on non-<button> element buttons.
  • Examples are now downloadable. We’ve added a script to zip up and offer all our Examples as their own download from the docs.
  • Saved ~5% from the compressed minified JS builds. 
Bootstrap 4.5.0 منتشر شد
‫۴ سال و ۴ ماه قبل، چهارشنبه ۲۴ اردیبهشت ۱۳۹۹، ساعت ۱۲:۲۸
وحید نصیری وحید نصیری
نظرات مطالب
6# آموزش سیستم مدیریت کد Git : استفاده به صورت محلی (بخش دوم)
یک gitignore مفید برای VS.NET:
#OS junk files
[Tt]humbs.db
*.DS_Store

#Visual Studio files
*.[Oo]bj
*.user
*.aps
*.pch
*.vspscc
*.vssscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.[Cc]ache
*.ilk
*.log
*.lib
*.sbr
*.sdf
*.opensdf
*.unsuccessfulbuild
ipch/
obj/
[Bb]in
[Dd]ebug*/
[Rr]elease*/
Ankh.NoLoad

#MonoDevelop
*.pidb
*.userprefs

#Tooling
_ReSharper*/
*.resharper
[Tt]est[Rr]esult*
*.sass-cache

#Project files
[Bb]uild/

#Subversion files
.svn

# Office Temp Files
~$*

#NuGet
packages/

#ncrunch
*ncrunch*
*crunch*.local.xml

# visual studio database projects
*.dbmdl

#Test files
*.testsettings

‫۱۲ سال و ۲ ماه قبل، یکشنبه ۱۹ شهریور ۱۳۹۱، ساعت ۱۳:۴۳
وحید نصیری وحید نصیری
مطالب
کش کردن اطلاعات غیر پویا در ASP.Net - قسمت سوم

در دو قسمت قبل در مورد IIS7 و IIS6 صحبت شد (+ و +).
در تکمیل قسمت دوم، یک مورد هم جزو قابلیت‌های ذاتی IIS6 و همچنین IIS5 است که می‌توان آن‌را فعال نمود (اگر دسترسی به سرور دارید) :




تنظیم مدت زمان content expiration ، بدون نیاز به برنامه نویسی خاصی، کار اضافه کردن هدر مربوط به مدت زمان کش شدن سمت کلاینت را به محتویات غیرپویای سایت شما مانند تصاویر ، فایل‌های CSS و غیره انجام می‌دهد. آمارها نشان می‌دهند که این تنظیم، زمان بارگذاری بعدی را بین 50 تا 70 درصد کاهش می‌دهد.
تنظیم این قابلیت را می‌توانید به چک لیست نصب IIS خود اضافه نمائید.

‫۱۵ سال و ۶ ماه قبل، دوشنبه ۲۸ اردیبهشت ۱۳۸۸، ساعت ۰۳:۳۱
وحید نصیری وحید نصیری
مطالب
بررسی ساختار ویجت‌های وب Kendo UI
ویجت‌های وب Kendo UI کدامند؟

ویجت‌های وب Kendo UI مجموعه‌ای از کنترل‌های سفارشی HTML 5 هستند که برفراز jQuery تهیه شده‌اند. این کنترل‌ها برای برنامه‌های وب و همچنین برنامه‌های دسکتاپ لمسی طراحی شده‌اند.
بهترین روش برای مشاهده‌ی این مجموعه، مراجعه به فایل examples\index.html پوشه‌ی اصلی Kendo UI است که لیست کاملی از این ویجت‌ها را به همراه مثال‌های مرتبط ارائه می‌دهد. تعدادی از اعضای این مجموعه شامل کنترل‌های ذیل هستند:
Window, TreeView, Tooltip, ToolBar, TimePicker, TabStrip, Splitter, Sortable, Slider, Gantt, Scheduler, ProgressBar, PanelBar, NumericTextBox, Notification, MultiSelect, Menu, MaskedTextBox, ListView, PivotGrid, Grid, Editor, DropDownList, DateTimePicker, DatePicker, ComboBox, ColorPicker, Calendar, Button, AutoComplete


نحوه‌ی استفاده کلی از ویجت‌های وب Kendo UI

با توجه به اینکه کنترل‌های Kendo UI مبتنی بر jQuery هستند، نحوه‌ی استفاده از آن‌ها، مشابه سایر افزونه‌های جی‌کوئری است. ابتدا المانی به صفحه اضافه می‌شود:
 <input id="pickDate" type="text"/>
سپس این المان را در رویداد document ready، به یکی از کنترل‌های Kendo UI مزین خواهیم کرد. برای مثال تزئین یک TextBox معمولی با یک Date Picker:
 <script type="text/javascript">
  $(function() {
        $("#pickDate").kendoDatePicker();
  });
</script>
روش دیگری به نام declarative initialization نیز برای اعمال ویجت‌های وب Kendo UI قابل استفاده است که از ویژگی‌های *-data مرتبط با HTML 5 کمک می‌گیرد. برای نمونه، کدهای جاوا اسکریپتی فوق را می‌توان با ویژگی data-role ذیل جایگزین کرد:
 <input id="dateOfBirth" type="text" data-role="datepicker" />
اگر در این حالت برنامه را اجرا کنید، تفاوتی را مشاهده نخواهید کرد.
برای فعال سازی حالت declarative initialization باید به دو نکته‌ی مهم دقت داشت:
الف) در مطلب معرفی Kendo UI اسکریپت‌های ذیل برای آماده سازی Kendo Ui معرفی شدند:
 <!--KendoUI: Web-->
<link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" />
<link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" />
<script src="js/jquery.min.js" type="text/javascript"></script>
<script src="js/kendo.web.min.js" type="text/javascript"></script>

<!--KendoUI: DataViz-->
<link href="styles/kendo.dataviz.min.css" rel="stylesheet" type="text/css" />
<script src="js/kendo.dataviz.min.js" type="text/javascript"></script>

<!--KendoUI: Mobile-->
<link href="styles/kendo.mobile.all.min.css" rel="stylesheet" type="text/css" />
<script src="js/kendo.mobile.min.js" type="text/javascript"></script>
باید دقت داشت که در آن واحد نمی‌توان تمام این بسته‌ها را با هم بکار برد؛ چون برای مثال فایل‌های جداگانه ویجت‌های وب و موبایل با هم تداخل ایجاد می‌کنند. بجای اینکار بهتر است از فایل‌های kendo.all.min.js (که حاوی تمام اسکریپت‌های لازم است) و css‌های عنوان شده استفاده کرد:
 <link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" />
<link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" />
<script src="js/jquery.min.js" type="text/javascript"></script>
<script src="js/kendo.all.min.js" type="text/javascript"></script>
ب) data-roleها توسط متد kendo.init فعال می‌شوند.
یک مثال کامل:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>

    <link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" />
    <link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" />
    <script src="js/jquery.min.js" type="text/javascript"></script>
    <script src="js/kendo.all.min.js" type="text/javascript"></script>

    <script type="text/javascript">
        $(function () {
            $("#pickDate").kendoDatePicker();
        });

        $(function () {
            // initialize any widgets in the #container div
            kendo.init($("#container"));
        });
    </script>
</head>
<body>
    <span>
        Pick a date: <input id="pickDate" type="text" />
    </span>

    <div id="container">
        <input id="dateOfBirth" type="text" data-role="datepicker" />
        <div id="colors"
             data-role="colorpalette"
             data-columns="4"
             data-tile-size="{ width: 34, height: 19 }"></div>
    </div>
</body>
</html>
- در این مثال نحوه‌ی پیوست تمام فایل‌های لازم Kendo UI را به صورت یکجا ملاحظه می‌کنید که در ابتدای head صفحه ذکر شده‌اند.
- در اینجا pickDate به صورت معمولی فعال شد‌ه‌است.
- اما در قسمت kendo.init نام یک ناحیه یا نام یک کنترل را می‌توان ذکر کرد. برای مثال در اینجا کل ناحیه‌ی مشخص شده توسط یک div با id مساوی container به صورت یکجا با تمام کنترل‌های داخل آن فعال گردیده‌است.

بنابراین برای اعمال declarative initialization، یک ناحیه را توسط kendo.init مشخص کرده و سپس توسط data-roleها، نام ویجت وب مورد نظر را به صورت lower case مشخص می‌کنیم. همچنین فایل‌های اسکریپت مورد استفاده نیز نباید تداخلی داشته باشند.


تنظیمات ویجت‌های وب Kendo UI

تاکنون نمونه‌ی ساده‌ای از بکارگیری ویجت‌های وب Kendo UI را بررسی کردیم؛ اما این ویجت‌ها توسط تنظیمات پیش بینی شده برای آن‌ها بسیار قابل تنظیم و تغییر هستند. تنظیمات آن‌ها نیز بستگی به روش استفاده و آغاز آن‌ها دارد. برای مثال اگر این ویجت‌ها را توسط کدهای جاوا اسکریپتی آغاز کرده‌اید، در همانجا توسط پارامترهای افزونه‌ی جی‌کوئری می‌توان تنظیمات مرتبط را اعمال کرد:
 <script type="text/javascript">
  $(function () {
      $("#pickDate").kendoDatePicker({
              format: "yyyy/MM/dd"
        });
  });
</script>
که در اینجا توسط پارامتر format، نحوه‌ی دریافت تاریخ نهایی مشخص می‌شود.
در حالت declarative initialization، پارامتر format تبدیل به ویژگی data-format خواهد شد:
<input id="dateOfBirth" type="text"
          data-role="datepicker"
          data-format="yyyy/MM/dd" />


تنظیمات DataSource ویجت‌های وب

بسیاری از ویجت‌های وب Kendo UI با داده‌ها سر و کار دارند مانند Grid، Auto Complete، Combo box و غیره. این کنترل‌ها داده‌های خود را از طریق خاصیت DataSource دریافت می‌کنند. برای نمونه در اینجا یک combo box را در نظر بگیرید. در مثال اول، خاصیت dataSource کنترل ComboBox در همان افزونه‌ی جی‌کوئری تنظیم شده‌است:
    <input id="colorPicker1" />
    <script type="text/javascript">
        $(document).ready(function () {
            $("#colorPicker1").kendoComboBox({
                dataSource: ["Blue", "Green", "Red", "Yellow"]
            });
        });
    </script>
و در مثال دوم، نحوه‌ی مقدار دهی ویژگی data-source را در حالت declarative initialization مشاهده می‌کنید. همانطور که عنوان شد، در این حالت ذکر متد kendo.init بر روی یک ناحیه و یا یک کنترل ویژه، جهت آغاز فعالیت آن ضروری است:
    <input id="colorPicker2" data-role="combobox" data-source='["Blue", "Green", "Red", "Yellow"]' />
    <script type="text/javascript">
        $(document).ready(function () {
            kendo.init($("#colorPicker2"));
        });
    </script>


کار با رویدادهای ویجت‌های وب

نحوه‌ی کار با رویدادهای ویجت‌های وب نیز بر اساس نحوه‌ی آغاز آن‌ها متفاوت است. در مثال‌های ذیل، دو حالت متفاوت تنظیم رویداد change را توسط خواص افزونه‌ی جی‌کوئری:
    <input id="colorPicker3" />
    <script type="text/javascript">
        function onColorChange(e) {
             alert('Color Change!');
        }

        $(document).ready(function () {
            $("#colorPicker3").kendoComboBox({
                dataSource: ["Blue", "Green", "Red", "Yellow"],
                change: onColorChange
            });
        });
    </script>
و همچنین توسط ویژگی data-change مشاهده می‌کنید:
    <input id="colorPicker4" data-role="combobox"
           data-source='["Blue", "Green", "Red", "Yellow"]'
           data-change="onColorChange" />

    <script type="text/javascript">
        function onColorChange(e) {
            alert('Color Change!');
        }

        $(document).ready(function () {
            kendo.init($("#colorPicker4"));
        });
    </script>
در هر دو حالت، انتخاب یک گزینه‌ی جدید combo box، سبب فراخوانی متد callback ایی به نام onColorChange می‌شود.


تغییر قالب ویجت‌های وب

Kendo UI همیشه یک جفت CSS را جهت تعیین قالب‌های ویجت‌های خود، مورد استفاده قرار می‌دهد. برای نمونه در مثال‌های فوق، kendo.common.min.css حاوی اطلاعات محل قرارگیری و اندازه‌ی ویجت‌ها است. شیوه نامه‌ی دوم همیشه به شکل kendo.[skin].min.css تعریف می‌شود که دارای اطلاعات رنگ و پس زمینه‌ی ویجت‌ها خواهد بود؛ مانند kendo.black.min.css، kendo.blueopal.min.css و امثال آن که در پوشه‌ی styles قابل مشاهده هستند.
همچنین باید دقت داشت که همیشه common باید پیش از skin ذکر شود؛ زیرا در تعدادی از حالات، شیوه نامه‌ی skin، اطلاعات common را بازنویسی می‌کند.
علاوه بر skinهای پیش فرض موجود در پوشه‌ی styles، امکان استفاده از یک theme builder آنلاین نیز وجود دارد: kendo-ui-themebuilder
‫۹ سال و ۱۲ ماه قبل، چهارشنبه ۱۴ آبان ۱۳۹۳، ساعت ۱۷:۴۵
امید شکری امید شکری
مطالب
اندازه گیری کارآیی پرس و جوها با استفاده از SET STATISTICS TIME
یکی از وظایف اصلی مدیر و یا توسعه دهنده یک بانک اطلاعاتی، نوشتن کدهای T-SQL و اندازه‌گیری عملکرد آنها می‌باشد. ابزارهای مختلفی برای انجام این کار وجود دارد، چه آنهایی که در خود SQL Server بصورت محلی وجود دارند و چه آنهایی که توسط شرکت‌های ثالث ارائه می‌شوند. اما مسئله مهمی که باید در نظر بگیرید چگونگی نوشتن یک پرس و جو (Query) و اندازه گیری کارآیی آن می‌باشد و اینکه باید روی چه مواردی متمرکز شد. در اکثر مواقع گرفتن زمان اجرای یک پرس و جو تا اندازه‌ای خوب می‌باشد. یکی از مواردی که باید روی آن متمرکز شد منابع استفاده شده توسط سرور می‌باشد، درحالیکه زمان اجرای پرس وجو به پارامترهای دیگری همچون بار سرور نیز بستگی دارد. علاوه بر استفاده از پروفایلر و نقشه اجرای کوئری (Execution Plan) ، می‌توانید از SET STATISTICS TIME نیز استفاده نمایید.
 SET STATISTICS TIME تنظیمی است که برای اندازه گیری منابع مورد نیاز اجرای یک پرس و جو به شما کمک می‌کند. SET STATISTICS TIME آمار مربوط به زمان تجزیه و تحلیل (Parse)، کامپایل و اجرای هر دستور در یک پرس و جو را نمایش می‌دهد. راه‌های مختلف اندکی برای مقایسه آماری دو پرس و جو و انتخاب بهترین آنها برای استفاده وجود دارند.  
برای روشن کردن این تنظیم دو راه وجود دارد. ابتدا اینکه از دستور Set برای روشن و خاموش کردن استفاده نمایید و یا اینکه از طریق Query Analyzer اقدام به انجام این کار نمایید. 
SET STATISTICS TIME ON
برای اینکه بتوانید آمارهای این تنظیمات را مشاهده کنید می‌بایست قبل از اجرای پرس و جو تنظیم مورد نظر را روشن نمایید. در نظر داشته باشید که با روشن کردن این تنظیم، برای تمامی پرس و جوهای مربوط به آن جلسه (Session) روشن خواهد ماند تا زمانیکه آنرا خاموش نمایید.  
SELECT ProductID, StartDate, EndDate, StandardCost 
FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;
با اجرای دستورات بالا خروجی آن بصورت زیر می‌باشد:
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 1 ms.

(269 row(s) affected)

SQL Server Execution Times:
   CPU time = 1 ms,  elapsed time = 2 ms.
زمان صرف شده برای اجرای یک کوئری به دو بخش تقسیم می‌شود:

  • زمان کامپایل و تجزیه و تحلیل ( parse and compile time) :   زمانیکه یک کوئری را برای اجرا به SQL Server  ارائه می‌دهید، SQL Server آنرا از نظر خطای نحوی بررسی می‌نماید و بهینه ساز یک نقشه بهینه را برای اجرا تولید می‌نماید. اگر به خروجی نگاه کنید، زمان پردازش ( CPU time) و زمان سپری شده ( elapsed time)  را نشان می دهد. منظور از زمان پردازش زمان واقعی صرف شده روی پردازنده می‌باشد و زمان سپری شده اشاره به زمان تکمیل شدن عملیات کامپایل و تجزیه و تحلیل می‌باشد. تفاوت بین زمان پردازش و زمان سپری شده ممکن است زمان انتظار در صف برای گرفتن پردازنده و یا انتظار برای تکمیل عملیات IO باشد. 

  • زمان اجرا  ( Execution Times) : این زمان اشاره به زمان سپری شده برای تکمیل اجرای نقشه کامپایل شده دارد. زمان پردازش اشاره به زمان واقعی صرف شده روی پردازنده دارد و زمان سپری شده نیز مجموع زمان صرف شده تا تکمیل اجرای دستور که شامل زمان انتظار برای تکمیل عملیات IO و زمان صرف شده برای انتقال خروجی به کلاینت می‌باشد، دارد. زمان پردازش می‌تواند به عنوان مبنایی برای اندازه‌گیری کارآیی مورد استفاده قرار بگیرد. این مقدار در اجراهای مختلف تفاوت چندانی با هم ندارند جز اینکه کوئری و یا داده‌ها تغییر نمایند. توجه نمایید که زمان براساس میلی ثانیه می‌باشد. زمان سپری شده نیز به فاکتورهایی مانند بارگذاری روی سرور، بارگذاری IO، و پهنای باند بین سرور و کلاینت وابسته می‌باشد. بنابراین همیشه زمان پردازش به عنوان مبنایی برای اندازه‌گیری کارایی استفاده می‌شود .

در این بخش به بررسی SET STATISTICS TIME  در SQL Server پرداختیم. در بخش بعدی به بررسی   SET STATISTICS IO  برای اندازه گیری کارایی پرس و جوها از نظر میزان استفاده IO خواهیم پرداخت.
‫۱۰ سال و ۸ ماه قبل، یکشنبه ۱۱ اسفند ۱۳۹۲، ساعت ۰۱:۲۰
وحید نصیری وحید نصیری
نظرات مطالب
Blazor 5x - قسمت یازدهم - مبانی Blazor - بخش 8 - کار با جاوا اسکریپت
یک نکته‌ی تکمیلی: امکان نوشتن فایل‌های CSS اختصاصی کامپوننت‌ها در برنامه‌های Blazor

در نکته‌ی قبلی، در مورد JavaScript Isolation بحث شد؛ یک چنین قابلیتی در مورد فایل‌های css. هم وجود دارد و جزو تازه‌های Blazor 5x است. در این حالت (CSS Isolation) می‌توان شیوه‌نامه‌ای را تهیه کرد که تنها مختص به یک کامپوننت است و بر روی سایر کامپوننت‌ها تاثیری ندارد. این قابلیت نیاز به کدنویسی خاصی نداشته و به سادگی قابل استفاده‌است: در این حالت اگر کامپوننتی برای مثال Counter.razor نام دارد، برای ایجاد فایل css مختص به آن، تنها کافی است در کنار فایل آن، فایل Counter.razor.css را ایجاد و تکمیل کرد. به این ترتیب هر شیوه‌نامه‌ای که در این فایل تنظیم شود، فقط بر روی کامپوننت Counter تاثیرگذار خواهد بود؛ حتی اگر از این کامپوننت در کامپوننت‌های دیگر نیز استفاده شود.
h1 {
    color:red;
}
برای نمونه شیوه‌نامه‌ی فوق تنها به المان h1 کامپوننت Counter اعمال می‌شود و هیچ تاثیری را بر روی سایر کامپوننت‌های برنامه نخواهد داشت:


همانطور که مشاهده می‌کنید، در زمان build برنامه، تمام این شیوه‌نامه‌های اختصاصی کامپوننت‌های مختلف برنامه، تبدیل به یک فایل خواهند شد (با نام project_name.styles.css) که توسط ویژگی‌های HTML ای که به صورت خودکار تولید می‌شوند، از یکدیگر متمایز خواهند شد.

 اگر علاقمند باشیم تا این شیوه‌نامه به فرزندان کامپوننت Counter نیز به ارث برسد، باید از روش زیر استفاده کرد (استفاده از deep combinator):
::deep h1 {
   color:red;
}
‫۳ سال و ۵ ماه قبل، پنجشنبه ۲ اردیبهشت ۱۴۰۰، ساعت ۱۹:۴۶