مطالب
کار با دیتاتایپ JSON در MySQL - قسمت چهارم
MySQL قادر به ایندکس کردن ستون‌های JSON نمی‌باشد. برای حل این مشکل میتوانیم از generated columnها استفاده کنیم. منظور، ایجاد ستون‌هایی است که مقدارشان به صورت محاسبه شده و براساس ستون‌های دیگر میباشد؛ به عنوان مثال جدول کاربران زیر را در نظر بگیرید:
CREATE TABLE `Users` (
  id int NOT NULL AUTO_INCREMENT,
  first_name VARCHAR(255) NOT NULL,
  last_name VARCHAR(255) NOT NULL,
  email VARCHAR(255) NOT NULL,
  gender ENUM('Male','Female') NOT NULL,
  PRIMARY KEY (`id`)
)
برای کوئری گرفتن full name در حالت معمول میتوانیم از تابع CONCAT استفاده کنیم:
SELECT 
    *, CONCAT(first_name, '', last_name) AS full_name
FROM
    Users;
اما توسط generated columns میتوانیم یک ستون را به جدول کاربران اضافه کنیم که مقدارش براساس دو فیلد first_name و last_name محاسبه و مقدار دهی شود:
ALTER TABLE Users
ADD COLUMN full_name TEXT GENERATED ALWAYS 
AS (CONCAT(first_name, ' ', last_name))
همانطور که مشاهده میکنید از سینتکس GENERATE ALWAYS برای ایجاد generated column استفاده شده‌است. در MySQL دو نوع generated column وجود دارد: STORED و VIRTUAL؛ تفاوت آنها نیز در نحوه ذخیره‌سازی است. در حالت VIRTUAL که حالت پیش‌فرض است، مقادیر ذخیره نمیشوند؛ بلکه به صورت on the fly محاسبه و در خروجی نمایش داده خواهند شد. در حالیکه نوع STORED همانطور که از نامش پیداست، ذخیره خواهند شد؛ در نتیجه قابلیت ایندکس‌گذاری را دارد. برای تعیین نوع ستون نیز سینتکس آن اینگونه خواهد بود:
ALTER TABLE Users
ADD COLUMN full_name TEXT GENERATED ALWAYS 
AS (CONCAT(first_name, ' ', last_name)) STORED

همچنین لازم به ذکر است که حین استفاده از generated columns باید نکات زیر را در نظر داشته باشید:
  • generated columnsها نمیتوانند شامل subqueries, parameters, variables, stored procedure, user-defined functions باشند.
  • بر روی یک ستون generated نمیتوان AUTO_INCREMENT گذاشت یا اینکه از یک ستون AUTO_INCREMENT برای محاسبه generated column استفاده کرد.
  • کلیدهای خارجی‌ای که در generated columnsها استفاده میشوند، قابلیت استفاده از CASCADE, SET NULL, or SET DEFAULT as ON UPDATE or ON DELETE را نخواهند داشت.

در ادامه یک generated column را برای جدول productsMetadata تعیین خواهیم کرد: 
ALTER TABLE productMetadata
ADD COLUMN id INT GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.id'))) STORED NOT NULL

بنابراین زمانیکه یک مقدار JSON را ذخیره میکنیم، کلید اصلی از path تعیین شده استخراج شده و به عنوان یک computed column برای این جدول تعیین خواهد شد. در ادامه میتوانید جزئیات تغییر فوق را مشاهده کنید: 

  
اکنون کوئری زیر را در نظر بگیرید که رکوردی با آی‌دی ۱ را بازیابی خواهد کرد:
SELECT data ->> "$.description.shortDescription" FROM productMetadata
WHERE id = 1;
از آنجائیکه هیچ ایندکسی برای این فیلد جدید لحاظ نشده است، MySQL کل ردیف‌ها را برای یافتن id موردنظر جستجو خواهد کرد. این مورد را میتوانید با دستور EXPLAIN نیز مشاهده کنید:


همانطور که مشاهده میکنید مقدار type به ALL تنظیم شده‌است؛ همچنین مقدار rows نیز تعداد ردیف‌های جدول است که در اینجا ۱۳ ردیف دیتا را داریم. قاعدتاً با اضافه شدن دیتای جدید به جدول، جستجو نیز به مراتب کندتر خواهد شد. بنابراین با اضافه کردن ایندکس میتوانیم مشکل این کند بودن را رفع کنیم. به همین جهت در ادامه یک ایندکس را براساس ستون id که یک generated column است ایجاد خواهیم کرد:

CREATE INDEX idx_json_data ON productMetadata (id);

اکنون اگر یکبار دیگر کوئری قبلی را اجرا کنیم، خواهیم دید که تعداد rows به ۱ و همچنین type به ref ست شده‌اند:



مطالب
الگوریتم‌های داده کاوی در SQL Server Data Tools یا SSDT - قسمت ششم (آخرین قسمت) - الگوریتم‌ Neural Network و Logistic Regression

در  قسمت قبل با الگوریتم Association Rules که بیشتر برای تحلیل سبد خرید استفاده می‌شد، آشنا شدیم. در این قسمت که قسمت آخر از سری مقالات الگوریتم‌های داده کاوی در SSDT می‌باشد، با الگوریتم‌های Neural Network و Logistic Regression آشنا می‌شویم.


Neural Network (هوش مصنوعی)

مقدمه

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



توصیف الگوریتم

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

پیچیدگی تحلیل انجام شده توسط این الگوریتم به دو عامل بر می‌گردد:

  1. ممکن است یک یا تمام ورودی‌ها به طریقی با یک یا همه‌ی خروجی‌ها مرتبط باشند و الگوریتم باید این موضوع را در آموزش مدل درنظر بگیرد.
  2. ممکن است ترکیبات مختلفی از ورودی‌ها به طریقی با خروجی‌ها در ارتباط باشند.

دسته بندی اسناد یکی از موضوعاتی است که شبکه‌های عصبی بهتر از الگوریتم‌های دیگر آن را حل می‌کنند. البته اگر سرعت برای ما مهم باشد، می‌توان از الگوریتم Naïve Bayes استفاده کرد. اما درصورتیکه دقت مهم‌تر باشد، آنگاه باید از الگوریتم شبکه‌های عصبی استفاده نمود.


تفسیر مدل

 نتیجه‌ی حاصله از این الگوریتم نسبت به الگوریتم‌های قبلی کاملا متفاوت است. در اینجا دیگر خبری از طرح محتوای مدل و نمودار گرافیکی لایه آموزش نیست. هدف اصلی در اینجا نمایش تاثیر صفت-مقدار، بر ویژگی قابل پیش بینی است. برای مثال جدول زیر در رابطه با تمایل به خرید یا اجاره خانه در رابطه با صفات مختلف می‌باشد. همانطور که مشخص است، دو ستون اول نشان دهنده‌ی جفت صفت-مقدار و دو ستون دوم، صفت مدنظر جهت پیش بینی را نشان می‌دهند. براساس این جدول می‌توان نتیجه گرفت که مهمترین فاکتور در تمایل به خریداری خانه، سن افراد می‌باشد. افرادی که سنی بین 38 تا 54 سال را دارند، بیشترین تمایل را در خرید یک خانه دارند. فاکتورهایی مانند متاهل بودن، سطح تحصیلات فوق دکترا، بازه سنی 33 تا 38  و خانم بودن نیز دارای اهمیت می‌باشند که به ترتیب از درجه اهمیت آن‌ها کم می‌شود. از طرفی بازه سنی 20 تا 28 سال بیشترین تمایل برای اجاره خانه را دارند. همچنین می‌توان گفت که افرادی که مجرد هستند، طلاق گرفته‌اند و یا سطح تحصیلاتشان دبیرستان است، بیشتر تمایل به اجاره خانه دارند تا به خرید آن.



Logistic Regression

همانند الگوریتم شبکه‌های عصبی است؛ با این تفاوت که لایه مخفی‌ای برای تولید ترکیبی از ورودی‌ها ندارد. یعنی سعی در برقراری ارتباط بین ترکیبی از ورودی‌ها و خروجی‌ها نمی‌کند (در واقع همان الگوریتم شبکه‌های عصبی است که پارامتر Hidden Node Ratio آن روی صفر تنظیم شده است). بنابراین سرعت پردازش و آموزش مدل در آن، بالاتر می‌باشد. البته صرف اینکه این الگوریتم دارای پیچیدگی کمتری است نمی‌توان گفت که همیشه ضعیف‌تر از الگوریتم شبکه‌های عصبی است. بلکه حتی در بعضی از مدل‌ها بهتر از الگوریتم شبکه‌های عصبی عمل می‌کند و مانع از باز آموزشی مدل می‌گردد.


به پایان آمد این دفتر، حکایت همچنان باقی است!

باسپاس فراوان از تمامی دوستانی که در این مدت سری مقالات الگوریتم‌های داده کاوی را دنبال نمودند. از آنجاکه هر یک از الگوریتم‌ها، دارای ریزه کاری‌های به خصوصی است، بنابراین انتخاب الگوریتم مناسب در رابطه با داده کاوی بسیار حائز اهمیت می‌باشد و به دلیل فرّار بودن این ریزه کاری‌ها، در گذشته بنده هر زمانیکه نیاز به داده کاوی داشتم مجبور بودم مطالب مربوط به الگوریتم‌ها را مطالعه کنم تا بتوانم بهترین الگوریتم (ها) را در رابطه با داده کاوی مدنظر انتخاب نمایم. در نتیجه برآن شدم تا چکیده‌ای نسبتا کارا را از این الگوریتم‌ها که در این شش قسمت آورده شد، تهیه و در اختیار عموم قرار دهم. به امید موفقیت و پیشرفت روز افزون تمامی برنامه نویسان و توسعه دهندگان ایرانی.

مطالب
MongoDb در سی شارپ (بخش چهارم)
در این بخش قصد داریم در مورد Chunk شدن فایل‌ها بدانیم. ولی قبل از هر چیز، نیاز است که ابتدا با اصول اولیه مونگو و حتی بانک‌های nosql آشنا شویم.

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

Sharding : یک خوشه شاردینگ(Sharded Cluster) در واقع مجموعه‌ای از همین سرورهای ریپلیکیشن میباشد که ماموریتشان توزیع یکسان بار، بر روی سرورهاست که به ما امکان مدیریت داده‌های حجیم و توسعه و به روزرسانی افقی سرورها (Horizontally Scale) را میدهد.
از این پس میدانیم که ریپلیکیشن‌ها شامل داده‌های یکسانی بوده و شاردینگ‌ها، تقسیم بندی دیتا را صورت میدهند و هر شارد میتواند شامل رپلیکشن‌های متفاوتی باشد.

اصلی‌ترین هدف این خوشه شاردینگ‌ها عبارتند از:
1-  مقیاس پذیری: توزیع بار پردازشی بر روی سرور‌های مختلف.
2- موازنه سازی لود دیتا: دیتا به طور خودکار در بین شاردهای مختلف توزیع می‌شود. موازنه‌گر تصمیم میگیرد که چگونه دیتا انتقال داده شده و به چه سروری منتقل شود و از طریق یک کلید به نام Partition Key رنج بندی دیتا را انجام میدهد تا بداند هر شاردی، چه رنج دیتایی را شامل میشود.

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


عملیات Chunk یا قطعه سازی فایل‌ها، بر اساس همین تعداد شاردینگ‌های مختلف می‌باشد که به صورت انتزاعی یا مفهومی ایجاد شده‌است و شامل دیتای اصلی نمیشود؛ بلکه شامل اطلاعاتی برای هر قطعه از دیتاها میشود که شامل یک کلید به نام SharedKey میباشد و دو مقدار Min و Max را برای هر رنج دیتا شامل میشود.

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


 شارد نهایت مقدار  Max
حداقل مقدار Min
 شناسه یا Id چانک
 “shard” : “shard0001”   “max” : { “x” : 8000 }   “min” : { “x” : 7000 }   “_id” : “testdb.presplit-x_7000.0” 
 “shard” : “shard0001”   “max” : { “x” : 9000 }   “min” : { “x” : 8000 }   “_id” : “testdb.presplit-x_8000.0” 
  “shard” : “shard0002” 
 “max” : { “x” : 10000 }   “min” : { “x” : 9000 }   “_id” : “testdb.presplit-x_9000.0” 
 “shard” : “shard0002”   “max” : { “x” : 11000 }   “min” : { “x” : 10000 }   “_id” : “testdb.presplit-x_10000.0” 

  این تقسیم چانک‌ها باید طوری باشد که سرور‌ها همیشه در حالت موازنه باشند و بالانس خود را حفظ کنند. جدول زیر به شما کمک میکند که بدانید سرور بالانس است یا خیر.
 تعداد چانک ها
 میزان تفاوت
 کمتر از 20 عدد
 2
 20 تا 79
 4
 از 79 عدد بیشتر
 8

برای درک این مسئله، فرض کنید ما 2 عدد شارد داریم و 31 عدد چانک. اگر 17 عدد از چانک‌ها به شارد 1 برسد و 14 تای باقی مانده به شارد شماره 2 برسد، اختلاف این تعداد شاردها سه میباشد که طبق جدول تا 4 عدد جا دارد. پس بالانسی بین شاردها بر قرار است. موقعی که فایلی به مقدار مشخص شده‌ی برای چانک برسد که به طور پیش فرض 64 مگابایت می‌شود، شروع به چانک گذاری کرده و برای حفظ بالانس و موازنه سازی، این چانک‌ها را بین شاردهای مختلف توزیع میکند و چانک را از سروری که شامل چانک‌های زیاد است، به سروری که شامل چانک‌های کمتر است منتقل میکند.

مطالب
مروری بر کتابخانه ReactJS - قسمت چهارم - state در ReactJS

همانطور که در قسمت اول گفته شد، React برای اینکه بتواند تگ‌ها را در زمان اجرا و به صورت پویا به روز کند، وضعیت فعلی تگ‌ها را دنبال میکند و در صورت وقوع تغییرات، تگ‌ها را به روز میکند. به این حالت Stateful گفته میشود. تگ‌های ساخته شده توسط React دو وضعیت را دارند. یکی وضعیت اولیه که به مرورگر ارسال شده، در حال نمایش است و ثابت، و دیگری در پشت زمینه در فایل جاوااسکریپت، در انتظار وقوع تغییری. React این دو وضعیت را با هم مقایسه میکند و اگر بین آنها تفاوتی وجود داشت، تغییرات را اعمال میکند. 

در React.createClass به همراه متدهای داخلی React میتوانیم برای یک کامپوننت، وضعیتی اولیه را مشخص کنیم، تغییرات را دنبال کنیم و وضعیت فعلی را تغییر دهیم. برای روشن شدن نحوه کار، مثال قسمت قبل را که یک منو از نوشیدنی‌ها بود، اینطور تغییر میدهیم که کاربر بتواند با input‌ها و یک دکمه، به لیست نوشیدنی‌ها، مورد تازه‌ای را اضافه کند:

var hotDrinks = [
    { item: "Tea", price: "7000" },
    { item: "Espresso", price: "10000" },
    { item: "Hot Chocolate", price: "12000" }
];

var MenuItem = React.createClass({
    render: function () {
        return (
            <li className="list-group-item">
                <span className="badge">{this.props.price}</span>
                <p>{this.props.item}</p>
            </li>
        )
    }
});

var Menu = React.createClass({
    getInitialState: function () {
        return {
            menuList: this.props.data
        };
    },
    componentDidMount: function () {
        var component = this;
        $("#btnAddNewItem").click(function () {
            component.state.menuList.push(
                {
                    item: $("#textInputItemName").val(),
                    price: $("#textInputItemPrice").val()
                });
            component.setState({
                menuList: component.state.menuList
            });
        });
    },
    render: function () {
        return (
            <div className="row">
                <div className="col-md-4">
                    <ul className="list-group">
                        {this.state.menuList.map(item => <MenuItem {...item} />)}
                    </ul>
                </div>
            </div>
        )
    }
});

ReactDOM.render(
    <Menu data={hotDrinks} />,
    document.getElementById("reactTestContainer")
);


توضیح کامپوننت Menu

getInitialState، componentDidMount، setState، state و render همگی از کتابخانه React هستند. اگر intelisense و code snippets  مخصوص React را در VSCode نصب کرده باشید، دسترسی به سایر متدها و خاصیت‌های کتابخانه ساده‌تر است. 

شیء state، وضعیت کنونی کامپوننت است. وقتی داده‌ای را به state اختصاص میدهیم، آن را به عنوان وضعیت اولیه در نظر میگیرد. با تغییر داده، React وضعیت کامپوننت را تغییر یافته حساب میکند و به صورت خودکار تگ‌ها را دوباره با داده‌های تازه میسازد. داده‌های state همان داده‌هایی هستند که تگ‌ها با آنها ساخته می‌شوند؛ در بخش render.

getInitialState مثل یک سازنده عمل میکند؛ مقدار ورودی کامپوننت را به یک شیء اختصاص میدهد و آن را برمیگرداند. به کجا؟ به state. یعنی menuList عضوی از شیء state میشود. در مثال بالا و در این متد، لیست نوشیدنی‌ها به menuList اعمال میشود.

componentDidMount باید حتما قبل render تعریف شود، به این دلیل که زمان اجرایش باید حتما بعد از اولین render باشد. این متد وظیفه دارد تغییرات مورد نظر ما را در سطح کد یا رابط کاربری دنبال کند. اگر تغییر دلخواهی به وجود آمد، وضعیت کامپوننت را به روز میکند که بعد از آن React به صورت خودکار تگ‌ها را دوباره میسازد. در مثال بالا متد به رویداد کلیک یک دکمه گوش میدهد. اگر کلیک زده شد، نام نوشیدنی جدید و قیمت آن را از inputها میخواند و به عنوان یک آیتم جدید به menuList در state اضافه میکند. اما هنوز یک قدم مانده و بدون آن React، شیء state را تغییر یافته به حساب نمی‌آورد. در بخش setState وضعیت جاری کامپوننت را با تغییرات اعمال شده، جایگزین میکنیم. در این نقطه React به صورت خودکار به سراغ render میرود و ادامه داستان! 

همانطور که قبلا گفته شد، React.createClass و React.Component فقط در Syntax با هم تفاوت دارند. در نتیجه این مثال را میشود در حالت React.Component هم اجرا کرد.

در قسمت بعد موضوع دیگری را به نام Composability شرح میدهیم. مبحثی ساده با مثال که نشان میدهد چطور کامپوننت‌ها را مستقل از هم بسازیم و در عین حال با هم استفاده کنیم.

مطالب
پیاده سازی گروه بندی ایمیل‌های ارسالی یا message threading
اگر به ایمیل‌های ارسالی از طرف GitHub دقت کرده باشید، کلاینت‌های دریافت ایمیل‌ها، تمام ایمیل‌های مرتبط با یک Issue موجود را، در ذیل هم نمایش می‌دهند و بجای اینکه چند 10 ایمیل ارسالی را به نحوی جداگانه نمایش دهند، برای خلوت‌تر کردن نحوه‌ی نمایش ایمیل‌های رسیده و کاهش نویز، آن‌ها را تنها در طی یک ایمیل ارائه می‌کنند:


برای نمونه در اینجا کل موضوع مرتبط با ELMAH، تنها در طی یک ایمیل نمایش داده می‌شود و هرچند 13 ایمیل، مرتبط با آن هستند، اما 13 ایمیل به صورت جداگانه نمایش داده شده را دریافت نمی‌کنیم. علت این موضوع به Header خاص این نوع ایمیل‌ها بر می‌گردد:
 From: Atif Aziz <notifications@github.com>
Reply-To: elmah/Elmah <reply+000bb03ad52eb40a4ec2d49bf78c53c3eba42efc401701a592cf00000001143e18c892a169ce0ae0bf4c@reply.github.com>
To: elmah/Elmah <Elmah@noreply.github.com>
Message-ID: <elmah/Elmah/issues/407/260080923@github.com>
In-Reply-To: <elmah/Elmah/issues/407@github.com>
References: <elmah/Elmah/issues/407@github.com>
Subject: Re: [elmah/Elmah] Will ELMAH be ported to ASP.NET Core? (#407)
در اینجا هدرهای استاندارد (RFC 5322) و ویژه‌ی Message-ID، In-Reply-To و References هستند که سبب فعال شدن گروه بندی ایمیل‌های ارسالی یا message threading در کلاینت‌های دریافت و نمایش ایمیل‌ها می‌شوند و فرمت کلی آن‌ها به صورت <ID@HOST> است.
Message-ID بیانگر شماره‌ی منحصربفرد ایمیل ارسالی است.
فیلدهای اختیاری In-Reply-To و References تنها زمانی ذکر می‌شوند که قصد ارسال پاسخی، به یک Message-ID خاص، وجود داشته باشد. بنابراین مقدار درج شده‌ی در آن‌ها دقیقا باید معادل Message-ID ایی باشد که پیشتر ارسال شده‌است.
اگر تنها فیلد References ذکر شود، از آن جهت تشخیص گروه یا Thread ایمیل‌های رسیده استفاده می‌شود.
اگر نیاز به ذکر بیش از یک Message-ID وجود داشته باشد، نحوه‌ی درج آن به صورت ذیل است:
 References:
<11111@yoursite.com>
<22222@yoursite.com>
<33333@yoursite.com>


نحوه‌ی پیاده سازی این قابلیت توسط SmtpClient دات نت

در کدهای ذیل نحوه‌ی افزودن هدرهای یاد شده را توسط SmtpClient دات نت مشاهده می‌کنید:
var smtpClient = new SmtpClient("….",587);

using (MailMessage message = new MailMessage("USERNAME@gmail.com","USERNAME@gmail.com"))
{
   message.Subject = "test";
   message.Headers.Add("Message-ID", "<MESSAGEID@site.com>");   
   smtpClient.Send(message);
}

using (MailMessage message = new MailMessage("USERNAME@gmail.com","USERNAME@gmail.com"))
{
   message.Subject = "Re: test";
   message.Headers.Add("In-Reply-To", "<MESSAGEID@site.com>");
   message.Headers.Add("References",  "<MESSAGEID@site.com>");
   smtpClient.Send(message);
}
ابتدا یک ایمیل معمولی ارسال شده‌است؛ با این تفاوت که هدر جدید Message-ID را به آن افزوده‌ایم.
از این ID در ایمیل‌های بعدی جهت ارجاع به آن و نمایش Thread مانند آن‌ها، به کمک فیلدهای In-Reply-To و References، استفاده خواهیم کرد.

برای مثال هدر اطلاع رسانی شروع یک بحث جدید به صورت ذیل است:
message.Headers.Add("Message-ID", $"<post/{post.id}@your-app-name.example>");
و سپس نظری که برای آن ارسال می‌شود، چنین هدرهایی را خواهد داشت:
message.Headers.Add("Message-ID", $"<comments/{comment.id}@your-app-name.example>");
message.Headers.Add("In-Reply-To", $"<post/{post.id}@your-app-name.example>");
message.Headers.Add("References", $"<post/{post.id}@your-app-name.example>");
مطالب
C# 6 - Index Initializers
زمان زیادی از ارائه‌ی امکان Collection Initializer برای ایجاد یک متغیر از نوع Collection می‌گذرد؛ برای نمونه به مثال زیر توجه کنید:
enum USState {...}
var AreaCodeUSState = new Dictionary<string, USState>
    {
        {"408", USState.California},
        {"701", USState.NorthDakota},
        ...
    };
در پشت صحنه، کامپایلر، Collection Initializer را می‌گیرد، با استفاده از یک <Dictionary<TKey, TValue و با فراخوانی متد Add آن بر روی لیست Collection Initializer شروع به درج آن در دیکشنری ساخته شده می‌کند. Collection Initializer فقط بر روی کلاس هایی که در آن‌ها IEnumerable پیاده سازی شده باشد امکان پذیر است چرا که کامپایلر کار اضافه کردن مقادیر اولیه را به ()IEnumerable.Add می‌سپارد.

اکنون در C# 6.0 ما می‌توانیم از Index Initializer استفاده کنیم:
enum USState {...}
var AreaCodeUSState = new Dictionary<string, USState>
    {
        ["408"] = USState.California,
        ["701"] = USState.NorthDakota,
        ...
    };
اولین تفاوتی که این دو روش با هم دارند این است که در حالت استفاده‌ی از Index Initializer پس از کامپایل، ()IEnumerable.Add فراخوانی نمی‌شود. این تفاوت بسیار مهم است و کار اضافه کردن مقادیر اولیه را با استفاده از کلید (Key) ویژه انجام می‌دهد.
شبه کد مثال بالا به صورت زیر می‌شود:

Collection Initializer
create a Dictionary<string, USState>
add to new Dictionary the following items: 
     "408", USState.California
     "701", USState.NorthDakota
Index Initializer
create a Dictionary<string, USState> then
using AreaCodeUSState's default Indexed property
    set the Value of Key "408" to USState.California
    set the Value of Key "701" to USState.NorthDakota
حال به مثال زیر توجه کنید:

Collection Initializer 
enum USState {...}
var AreaCodeUSState = new Dictionary<string, USState>
        {
            { "408", USState.Confusion},
            { "701", USState.NorthDakota },
            { "408", USState.California},
            ...
        };
Console.WriteLine( AreaCodeUSState.Where(x => x.Key == "408").FirstOrDefault().Value );
Index Initializer
enum USState {...}
var AreaCodeUSState = new Dictionary<string, USState>
    {
        ["408"] = USState.Confusion,
        ["701"] = USState.NorthDakota,
        ["408"] = USState.California,
        ...
    };
Console.WriteLine( AreaCodeUSState2.Where(x => x.Key == "408").FirstOrDefault().Value );  // output = California
هر دو کد بالا با موفقیت کامپایل و اجرا می‌شود، اما در زمان اجرای Collection Initializer هنگامیکه می‌خواهد مقدار دوم "408" را اضافه کند با استثناء ArgumentException متوقف می‌شود چرا که کلید "408" از قبل وجود دارد.
اما در زمان اجرا، Index Initializer به صورت کامل و بدون خطا این کار را انجام می‌دهد و در کلید "408" مقدار USState.Confusion قرار می‌گیرد. سپس "701" مقدار USState.NorthDakota و بعد از استفاده‌ی مجدد از کلید "408" مقدار USState.California جایگزین مقدار قبلی می‌شود.

var fibonaccis = new List<int>
    {
        [0] = 1,
        [1] = 2,
        [3] = 5,
        [5] = 13
    }
این کد هم معتبر است و هم کامپایل می‌شود. البته معتبر است، ولی صحیح نیست. <List<T اجازه‌ی تخصیص اندیسی فراتر از اندازه‌ی فعلی را نمی‌دهد.
تلاش برای تخصیص مقدار 1 با کلید 0 به <List<int، سبب بروز استثناء ArguementOutOfRangeException می شود. وقتی (List<T>.Add(item فراخوانی می‌شود اندازه‌ی لیست یک واحد افزایش می‌یابد. بنابراین باید دقت داشت که Index Initializer از ()Add. استفاده نمی‌کند؛ در عوض با استفاده از خصوصیت اندیس پیش فرض، مقداری را برای یک کلید تعیین می‌کند.
برای چنین حالتی بهتر است از همان روش قدیمی Collection Initializer استفاده کنیم:
var fibonaccis = new List<int>()
    {
        1,
        3,
        5,
        13
    };
مطالب
C# 6 - The nameof Operator
یکی دیگر از قابلیت‌های جذاب نسخه‌ی جدید سی‌شارپ، عملگر nameof است. هدف اصلی آن ارائه کدهایی با قابلیت Refactoring بهتر است؛ زیرا به جای نوشتن نام فیلدها و یا متدها در صورت نیاز به صورت hard-coded، می‌توانیم از این عملگر استفاده کنیم. به عنوان مثال در زمان صدور استثناءیی از نوع ArgumentNullException باید نام آرگومان را به سازنده‌ی این کلاس پاس دهیم. متاسفانه یکی از مشکلاتی که با رشته‌ها در حالت کلی وجود دارد این است که امکان دیباگ در زمان کامپایل را از دست خواهیم داد و با تغییر هر المنت، تغییرات به صورت خودکار به رشته پاس داده شده، به سازنده‌ی کلاس ArgumentNullException اعمال نخواهد شد:
public static void DoWork(string name)
{
       if (name == null)
       {
           throw new ArgumentNullException("name");
       }
}
اما با استفاده از عملگر nameof، کد امن‌تری را خواهیم داشت؛ زیرا همیشه نام واقعی آرگومان به سازنده‌ی کلاس ArgumentNullException پاس داده می‌شود:
public static void DoWork(string name)
{
       if (name == null)
       {
           throw new ArgumentNullException(nameof(name));
       }
}
اگر ReSharper را نصب کرده باشید، به شما پیشنهاد می‌دهد که از nameof به جای یک رشته‌ی جادویی (magic string) استفاده نمائید:


یک مثال دیگر می‌تواند در زمان فراخوانی رخدادهای مربوط به OnPropertyChanged باشد. در اینجا باید نام خصوصیتی را که تغییر یافته است، به آن پاس دهیم: 
        public string Name
        {
            get { return _name; }
            set
            {
                _name = value;
                OnPropertyChanged("Name");
            }
        }
اما با کمک عملگر nameof می‌توانیم قسمت فراخوانی متد OnPropertyChanged را به اینصورت نیز بازنویسی کنیم:
OnPropertyChanged(nameof(Name));
ممکن است عنوان کنید قبلاً در سی‌شارپ 5 هم می‌توانستیم از ویژگی [CallerMemberName] استفاده کنیم، پس دیگر نیازی به استفاده از عملگر nameof نخواهد بود. اما تفاوت کلیدی این است که CallerMemberName در زمان اجرا نام فیلد فراخوان را دریافت میکند (run time)، در حالیکه با استفاده از عملگر nameof می‌توانید در زمان کامپایل به نام فیلد دسترسی داشته باشید (compile time).

محدودیت‌های عملگر nameof
این عملگر حالت‌هایی را که مشاهده می‌کنید، فعلاً پشتیبانی نخواهد کرد:
nameof(f()); // where f is a method - you could use nameof(f) instead
nameof(c._Age); // where c is a different class and _Age is private. Nameof can't break accessor rules.
nameof(List<>); // List<> isn't valid C# anyway, so this won't work
nameof(default(List<int>)); // default returns an instance, not a member
nameof(int); // int is a keyword, not a member- you could do nameof(Int32)
nameof(x[2]); // returns an instance using an indexer, so not a member
nameof("hello"); // a string isn't a member
nameof(1 + 2); // an int isn't a member
برای آزمایش عملگر nameof می‌توانیم یک تست را در حالت‌های زیر بنویسیم:


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

برای شروع کار ابتدا دو دیتابیس به اسم‌های databasefrm و databaseto می‌سازیم. دیتابیس databasefrm شامل یک جدول به اسم emp با سه فیلد ID,Name,Address می‌باشد. قصد داریم جدول tmp از دیتابیس databasefrm را به دیتابیس databaseto انتقال دهیم. برای انجام این کار، یکی از روش‌های زیر را استفاده خواهیم کرد:

روش 1 : استفاده از کوئری

ساختار کلی انجام این عمل به صورت زیر خواهد بود:
Select * into DestinationDB.dbo.tableName from SourceDB.dbo.SourceTable
مثال :
select * into databaseto.dbo.emp from databasefrm.dbo.Emp
با اجرای دستور فوق یک کپی از جدول emp به همراه تمامی داده‌های آن به دیتابیس databaseto منتقل و ایجاد می‌شوند. اگر بخواهیم تمامی ایندکس‌ها، تریگر‌ها و قید‌ها (Constraint) نیز منتقل شوند، برای اینکار نیاز به تولید یک اسکریپت خواهد بود (در ادامه).

حال اگر بخواهیم یک کپی از  جدول را در دیتابیس جاری ایجاد کنیم، ساختار آن به صورت زیر خواهد بود  :
select * into newtable from SourceTable
که نمونه ای از آن برای دیتابیس ما به صورت زیرخواهد بود :
 select * into  emp1 from emp

می‌توانیم فقط فیلدهایی مشخص را به جدول دیگر کپی کنیم. برای انجا این کار کافیست به جای *  اسم فیلد‌های مورد نیاز را نوشت که ساختار دستوری آن به صورت زیر است :
select col1, col2 into <destination_table> from <source_table>
که برای مثال ما به صورت زیر خواهد بود :
select Id,Name into databaseto.dbo.emp1 from databasefrm.dbo.Emp

بعد از اجرای کوئری فوق نتیجه به صورت زیر خواهد بود :

کد فوق باعث کپی کردن فیلد‌های Id,Name شده است.

اگر بخواهیم فقط ساختار جدول را کپی کنیم روند کار به صورت زیر خواهد بود :

select *into <destination_database.dbo.destination table> from _
<source_database.dbo.source table> where 1 = 2
که نمونه ای از آن برای مثال ما به صورت زیر خواهد بود :
select * into databaseto.dbo.emp from 
databasefrm.dbo.emp where 1 = 2
کاربرد where در دستور فوق برای این است که عنوان فیلد‌ها را بگیریم و در جدول دیگری ذخیره کنیم.

نکته: هر وقت نیاز بود که فقط فیلد‌های یک جدول را دریافت کنید، می‌تواند از کدی همانند فوق استفاده کنید؛ با یک شرط که همیشه false برگرداند. ولی راه بهتری که توصیه میکنم استفاده از Top در دستور  Select می‌باشد. نمونه‌ای از دستور فوق:
select top(0) * into databaseto.dbo.emp from 
databasefrm.dbo.emp
همانطور که مشاهده می‌کنید دیگر در دستور فوق خبری از where نیست.

روش 2: ویزارد

جهت تهیه کارهای فوق به صورت ویزارد، به صورت خلاصه فقط به روند انجام کار بسنده می‌کنیم:
1- SSMS را باز کنید.
2- بر روی دیتابیس مورد نظر کلیک راست کرده و از منوی ظاهر شده Task را انتخاب نموده و در کادر بازشو Export data را انتخاب کنید.
3- در پنجره‌ی ظاهر شده بر روی دکمه next کلیک کرده و در پنجره بعدی، نوع اعتبار سنجی را انتخاب کرده و دیتابیس مورد نظر را انتخاب نمایید (databasefrm).
4- همانند مرحله 3 است با این تفاوت که اینبار دیتابیس مقصد را انتخاب می‌کنیم (databaseto).
5- در پنجره‌ی بعدی گزینه اول را انتخاب کرده (copy data from ...) و بعد از کلیک بر روی next در پنجره ظاهر شده، جدول یا جداول مورد نظر را انتخاب کنید.

روش 3 : تولید اسکریپت

 
با استفاده از دو روش فوق فقط می‌توانستیم ساختار جداول و داده‌های آن را انتقال بدهیم. برای انتقال کامل جداول مثل تریگرها، قیدها و ... می‌بایست از جدول یا جداول اسکریپت تولید و در نهایست اسکریپت را اجرا نماییم.
Right click on datbase >>Task>>Generate script>>next

انتخاب دیتابیس مورد نظر و بعد انتخاب مواردی که قصد داریم از آنها اسکریپت ایجاد کنیم و در پایان اسکریپت مورد نظر را بر روی دیتابیس مقصد (databaseto) اجرا می‌کنیم.

و در پایان نهایت تشکر را از تمام عزیزان و دوستان نویسنده‌ی سایت دارم. امیدوارم در سال 94 شاهد موفقیت‌های خوبی در حوزه‌ی نرم افزار باشیم.
مطالب
مقید سازی پارامترهای نوع جنریک
احتمالا در بیشتر مقالات (فارسی/انگلیسی) عبارات هایی مثل نمونه‌های زیر را دیده اید :
where T:clas
where T:struc
...
در این مقاله قصد داریم بپردازیم به «مقید سازی پارامتر‌های نوع جنریک» و اینکه چه کاربردی دارند و در چه زمانی بهتر است از آن‌ها استفاده کنیم و نحوه استفاده از آنها چگونه است. فرض میکنیم که خواننده‌ی محترم با مفاهیم جنریک آشنایی دارد. در صورتیکه با جنریک‌ها آشنا نیستید ابتدا مروری داشته باشید بر جنریک‌ها و بعد این مقاله را مطالعه فرمایید؛ به این دلیل که موضوع مورد بحث بر پایه‌ی جنریک‌ها می‌باشد.

همانطور که مطلع هستید هر عنصری جنریکی را که تعریف میکنید حداقل دارای یک پارامتر نوع هست و در زمان بکارگیری آن جنریک باید نوع آن را مشخص نمایید. برای نمونه مثال زیر را در نظر بگیرید :
public  class MyCollection<T>
        {
            private List<T> collections = new List<T>();
            public void Add(T value)
            {
                collections.Add(value);
            }
        }
کلاس فوق یک کلاس جنریک است که در هنگام ساخت نمونه‌ای از آن، باید ابتدا data type نوعی را که که می‌خواهیم با آن کار کنیم، تعیین کنیم. برای مثال در کد فوق در هنگام ساخت نمونه‌ای از آن، نوع int را برای آن مشخص میکنیم و هر وقت بخواهیم متد Add آن را فراخوانی کنیم، فقط نوعی را قبول خواهد کرد که در ابتدا برای آن تعیین کرده ایم (int):
MyCollection<int> myintObj = new MyCollection<int>();
            myintObj.Add(12);
            myintObj.Add(33);
             myintObj.Add(33.3);// ERROR z 
سؤال: می‌خواهیم فقط نوع‌هایی را بتوان به T نسبت داد که از نوع ارجاعی (reference type) هستن و یا فقط نوع هایی را به T نسبت داد که یک سازنده دارند؛ چگونه؟

ایجاد قید‌ها یا محدودیت‌ها بر روی پارامتر‌های جنریک‌ها شامل پنج حالت می‌باشد:

حالت اول : Where T:struct
در این حالت T باید یک ساختار باشد .

حالت دوم : where T:class
T  باید یک نوع ارجاعی باشد. اگر در مثال فوق این قید را به آن اضافه کنیم، در هنگام ساخت نمونه‌ای از کلاس فوق، اگر یک نوع value type را به T نسبت دهیم، در هنگام وارد کردن یک نوع value type با خطا مواجه خواهیم شد. مثال:
public  class MyCollection<T> where T:class
        {
            private List<T> collections = new List<T>();
            public void Add(T value)
            {
                collections.Add(value);
            }
        }
و برای استفاده :
 MyCollection<int> myintObj = new MyCollection<int>(); // ERROR , int is value type

حالت سوم : ()Where T:new
نوعی که به T نسبت داده می‌شود باید یک سازنده‌ی پیش فرض داشته باشد.
داخل پرانتز : سازنده‌ی پیش فرض: زمانی که شما یک کلاس می‌نویسید اگر آن کلاس دارای هیچ سازنده‌ای نباشد، کامپایلر یک سازنده‌ی بدون پارامتر را به کلاس فوق اضافه می‌کند که کار آن مقدار دهی به فیلد‌های کلاس است. در اینجا از مقادیر پیش فرض استفاده می‌شود. مثلا برای int مقدار صفر و برای string مقدار "" و به همین ترتیب.
اگر از مقدار دهی پیش فرض توسط کامپایلر خرسند نیستید، می‌توانید سازنده پیش فرض را تغییر داده و مطابق میل خود فیلد‌ها را مقدار دهی اولیه کنید .


حالت چهارم : where T:NameOfBaseClass
نوعی که به T نسبت داده می‌شود باید از کلاس NameOfBaseClass ارث بری کرده باشد.

حالت پنجم : where T:NameOfInterface
همانند حالت چهارم می‌باشد؛ با این تفاوت: نوعی که به T نسبت داده می‌شود باید واسط NameOfInterface را پیاده سازی کرده باشد.

پنج حالت فوق نمونه‌هایی از ایجاد محدودیت بر روی پرامتر نوع اعضای جنریک بودند و اما در ادامه قصد داریم نکاتی را در این باب، بیان کنیم:

نکته اول : می‌توانید محدودیت‌های فوق را با هم ترکیب کنید برای اینکار آنها را با کاما از هم جدا کنید :
 public  class MyCollection<T> where T:class,IDisposable,new()
        {
   //content
}
نوعی که به T نسبت داده می‌شود
  • باید از نوع ارجاعی باشد.
  • باید واسط IDisposable را پیاده سازی کرده باشد.
  • باید یک سازنده‌ی پیش فرض داشته باشد.

نکته دوم : زمانیکه از چندین محدودیت استفاده می‌کنید مثل مثال فوق، باید محدودیت ()new در آخرین جایگاه محدودیت‌ها قرار گیرد؛ در غیر اینصورت با خطای زمان ترجمه روبه رو خواهید شد .

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

public void Swap<T>(ref T val1,ref T val2) where T:struct
            {
//content
            }
نکته چهارم : زمانیکه کلاس و یا متدهای شما بیش از یک نوع پارامتر از نوع جنریک را دریافت می‌کنند، باید محدودیت‌های مورد نظر را برای هر کدام به صورت جداگانه قید کنید. به طور مثال به کلاس زیر که دو پارمتر T و K را دارد، باید برای هر کدام جداگانه محدودیت‌های مورد نظر را اعمال کنیم (در صورت نیاز):
 public  class MyCollection<T,K> where T:class where K:IDisposable,new()
        {
//content
}
مطالب
استفاده از Unity در پیاده سازی الگوی Service locator
یکی از راهکارهای پیاده سازی IOC یا همان Inversion Of Control در پروژه‌های MVC استفاده از Unity و معرفی آن به DependencyResolver خود دات نت است.
برای آشنایی با Unity و قابلیت‌های آن میتوانید به اینجا و اینجا سر بزنید.
اما برای استفاده از Unity در پروژه‌های MVC کافی است در Global یا فایل راه انداز (bootstrapper ) تک تک انتزاع‌ها (Interface) را به کلاس‌های مرتبط شان معرفی کنید.
var container = new UnityContainer();  
container.RegisterType<ISomeService, SomeService>(new PerRequestLifetimeManager());
container.RegisterType<ISomeBusiness, SomeBusiness>(new PerRequestLifetimeManager());
container.RegisterType<ISomeController, SomeController>(new PerRequestLifetimeManager());
و بعد از ایجاد container از نوع UnityContainer میتوانیم آنرا به MVC معرفی کنیم:
DependencyResolver.SetResolver(new UnityDependencyResolver(container));
تا به اینجا به‌راحتی میتوانید از سرویس‌های معرفی شده در پروژه MVC استفاده کنید.
var someService=(ISomeService)DependencyResolver.Current.GetService(typeof(ISomeService));
var data=someService.GetData();
اما اگر بخواهیم از کلاس‌های معرفی شده در Unity در لایه‌های دیگر (مثلا Business) استفاده کنیم چه باید کرد؟
برای هر این مشکل راهکارهای متفاوتی وجود دارد. من در لایه سرویس از Service locator بهره برده ام. برای آشنایی با این الگو اینجا را بخوانید. اکثر برنامه نویسان الگوهای IOC و Service Locator را با هم اشتباه میگیرند یا آنها را اشتباها بجای هم بکار میبرند.
برای درک تفاوت الگوی IOC و Service locator اینجا را بخوانید.

در لایه سرویس یک کلاس Service Factory داریم که قرار است همه سرویس‌ها، برای برقراری ارتباط با یکدیگر از آن استفاده کنند.این کلاس معمولا در لایه سرویس به اشکال گوناگونی پیاده سازی میشود که کارش وهه سازی از Interface‌های درخواستی است. اما برای یکپارچه کردن آن با Unity من آنرا به شکل زیر پیاده سازی کرده ام

public class ServiceFactory : MarshalByRefObject
    {
        static IUnityContainer uContainer = new UnityContainer();
        public static Type DataContextType { get; set; }

        public static void Initialise(IUnityContainer unityContainer, Type dbContextType)
        {
            uContainer = unityContainer;
            DataContextType = dbContextType;
            uContainer.RegisterType(typeof(BaseDataContext), DataContextType, new HierarchicalLifetimeManager());
        }
        public static T Create<T>()
        {
            return (T)Activator.CreateInstance<T>();
        }
        public static T Create<T>(string fullTypeName)
        {
            return (T)System.Reflection.Assembly.GetExecutingAssembly().CreateInstance(fullTypeName);
        }
        public static T Create<T>(Type entityType)
        {
            return (T)Activator.CreateInstance(entityType);
        }
        public static dynamic Create(Type entityType)
        {
            return Activator.CreateInstance(entityType);
        }

        public static T Get<T>()
        {
            return uContainer.Resolve<T>();
        }
        public static object Get(Type type)
        {
            return uContainer.Resolve(type);
        }
    }

در این کلاس ما بجای ایجاد داینامیک آبجکت‌ها، از Unity استفاده کرده‌ایم. در همان ابتدا که برنامه‌ی وب ما برای اولین بار اجرا میشود و بعد از Register کردن کلاس‌ها، می‌توانیم container را به صورت پارامتر سازنده به کلاس Service Factory ارسال کنیم. به این ترتیب برای استفاده از سرویس‌ها در لایه Business از Unity بهره میبریم.

البته استفاده از Unity برای DataContext خیلی منطقی نیست و بهتر است نوع DataContext را در ابتدا بگیریم و هرجا نیاز داشتیم با استفاده از متد Create از آن وهله سازی بکنیم.