نوشته های Payam Jafari

چگونه ستون های دیتابیس لاراول رو رمزگذاری کنیم

Payam Jafari — Mon, 29 Nov 2021 17:30:58 +0330

درود بیکران بر شما. امروز میخوایم ببینیم چطور میشه راحت و سریع ستون های دیتابیس در فریم ورک لاراول رو رمزگذاری کرد.برای این کار به یک پکیج نیازمندیم که یکی از اعضای جامعه لاراول نوشته. ابتدا پکیج رو به پروژه اضافه میکنیم.composer require betterapp/laravel-db-encrypterاین پکیج اومده و یک trait ساخته که بتونیم به مدل اضافه کنیم. بعد از اضافه کردن تریت به مدل فقط کافیه که یک property به مدلمون اضافه کنیم و داخلش اسم ستون هایی که میخوایم رمزگذاری بشه رو قرار بدیم.create([ "title" => "Foo Bar", "mobile" => "09120000000", /** این فیلد به طور خودکار رمزگذاری میشه */ "email" => "email@example.com", /** این فیلد به طور خودکار رمزگذاری میشه */ ]);همینطور زمانی که یک مدل رو فراخوانی میکنیم فیلد مربوطه به طور رمزگشایی شده(decrypted) برگردونده میشه.find(1); dd($post->getAttribute("mobile")); // 09120000000این پکیج برای رمزگذاری و رمزگشایی مقدار های یک فیلد از کلاس Crypt لاراول استفاده میکنه. همچنین خود Crypt برای رمزگذاری و رمزگشایی از مقدار APP_KEY داخل فایل .env استفاده میکنه.پس اینجا مهمه که از مقدار داخل APP_KEY مراقبت بشه و به دست افراد قابل اعتماد سپرده بشه. همچنین اگر این کد گم بشه یا حذف بشه تموم فیلد هایی که رمزگذاری کردید قابل بازگشت نیست و کار به جاهای باریک میکشه.نکته:‌ این پکیج در هنگام ساختن سطر در دیتابیس به صورت دسته جمعی(bulk insert) کار نمیکنه. پس باید خودتون در هنگام ساختن یک سطر در دیتابیس از کلاس Crypt استفاده کنید.رمزگذاری کردن مقدار های قبلی یک ستون دیتابیساگر از قبل توی دیتابیستون سطر هایی وجود داره که هنوز رمزگذاری نشده میتونین با اجرا کردن کد زیر مقدار های قبلی رو رمزگذاری کنید.getAttribute('mobile')){ $post->update([ 'mobile' => $mobile ]); } }استفاده از این پکیج در دیتابیس MongoDBاحتمالا برای بعضی از شما که از دیتابیس MongoDB برای سیستم لاراول استفاده میکنید این مشکل پیش بیاد که پکیج jenssegers/mongodb و این پکیج با هم سازگار نباشن. برای حل این مشکل من از پکیج بالا یک فورک گرفتم و تغییرات لازم رو دادم تا بتونین توی مونگو ازش استفاده کنید.نحوه نصب پکیجcomposer require payamjafari/laravel-db-encrypterاین پکیج هم مثل قبلی هست و برای استفاده با پکیج jenssegers/mongodb آماده هست.خب این هم پایان مطلب. تا درودی دیگر بدرود.

دلمغز نوشته - چالش های من در Big Data - معماری درست کدام است

Payam Jafari — Sat, 06 Feb 2021 14:09:21 +0330

درود مجدد. در قسمت های قبلی راجب اینکه دیتابیس نوپا کلیک هاوس چیست و توییتر چیکار میکنه صحبت کردیم و به این اشاره کردیم که دیتا باید کش بشه.همچنین دوباره اشاره میکنم که در سری دلمغز نوشته ها ممکنه که مطالب ۱۰۰ درصد درست و دقیق نباشه اما تلاش بر این هست که حرفای گفته شده مستند باشه.در ادامه تحقیقاتی که انجام شد به یک الگوی رایج و محبوب رسیدم که به اجزای اون اشاره میکنم.در تصویر زیر مراحل از چپ به راست جلو میره.مراحل اجرای Big Dataساختار منابع اطلاعات / Data Sourcesما در بحث Big Data انواع داده رو داریم. این داده ها به ۳ دسته Structured, Semi-Structured, Unstructured تقسیم میشن. اطلاعات ساخت یافته / Structured Dataاین نوع اطلاعات شامل دیتابیس ها و اطلاعات دارای ساختار منظم و ثابت هست، مثل فایل های Excel و MySqlاطلاعات نیمه ساخت یافته / Semi-Structured Dataاطلاعاتی مثل ایمیل ها و اطلاعاتی که کاملا ساخت یافته نیستن اما در عین حال مثل دیتای غیر ساخت یافته هم نیستن.اطلاعات غیر ساخت یافته / Unstructured Dataدیتاهایی مثل فایل های صوتی و تصویری و اطلاعاتی که غیر قابل ویرایش و ردیابی هستن.انتقال و ادغام اطلاعات / Integrationپس از دریافت اطلاعات نوبت این میرسه که این اطلاعات پردازش بشه، راه هایی که برای این مرحله استفاده میشه متفاوت هست بسته به نوع و ساختار اطلاعات.به عنوان مثال برای اطلاعات ساخت یافته از یک فرایند به اسم ETL-Extract, Transform, Load استفاده میشه. این فرایند اطلاعات خام موجود رو به اطلاعات قابل استفاده برای آمارگیری و محاسبات آینده آماده میکنه. در مرحله بعدی این اطلاعات ذخیره میشه.همچنین اگر اطلاعات از نوع غیر ساخت یافته باشه میتونیم مستقیما از طریق API اطلاعات رو توزیع کنیم.انبار ذخیره اطلاعات / Data Storages / Data Warehouseدر اینجا اطلاعاتی که در مرحله قبل پردازش و قابل استفاده شده رو ذخیره میکنیم. این فرایند بسته به نوع اطلاعات متفاوته و ممکنه که از ابزارهای مختلفی استفاده بشه.برای مثال اطلاعات ساخت یافته رو در دیتابیس های NoSql مثل MongoDB یا ElasticSearch ذخیره میکنیم. همچنین اطلاعات غیر ساخت یافته رو هم در فایل سیستم های مخصوص مثل HDFS که در Hadoop استفاده میشه ذخیره میکنیم.نکته:‌ Hadoop یک فریم ورک برای مدیریت و توزیع و پردازش اطلاعات به طور وسیع بین چندین سرور هست و برای مدیریت Big Data استفاده میشه.تجزیه و تحلیل اطلاعات / Analyticsدر این مرحله اطلاعاتی که مرحله قبل ذخیره و آماده استفاده هست رو تجزیه و با استفاده از علم داده، تحلیل و به اطلاعات قابل نمایش برای استفاده کننده ها و تحلیلگر ها در شرکت تبدیل میکنیم و یا اطلاعات رو برای نمایش به مشتری ها و کاربران عادی آماده میکنیم.در این مرحله میتونیم از ۲ روش برای ارائه اطلاعات به مشتری یا تیم تحلیل استفاده کنیم. راه اول Batch Processing هست و راه دوم Stream Processing. همونطور که از اسمشون معلوم هست در روش اول ما اطلاعات رو دسته بندی و به صورت زمان بندی شده به تحلیلگر ها ارائه میدیم، اما در راه دوم ما به صورت مستقیم از منبع اطلاعت که در قسمت Data Sources دیدیم اطلاعات رو برداشته و نتایج ساده تر اما آنی(زیر ۱ ثانیه) به کاربر و مشتری ها نشون میدیم.هر ۲ روشی که اشاره کردم در جای خود استفاده های متفاوتی دارند. اما من در اینجا بیشتر روی Batch Processing تمرکز میکنم چون نیاز شرکت ما با این روش به نتیجه میرسه.در روش Batch Processing میتونیم به ۲ راه عمل کنیم. یکی اینکه مستقیم به Data Warehouse کوئری میزنیم و نتایج مورد نظرمون رو میگیریم ( که ممکنه دریافت پاسخ چندین ثانیه یا دقیقه طول بکشه )، یا اینکه به صورت زمان بندی شده در ساعاتی از روز کوئری های مورد نیاز رو میزنیم و جواب ها رو کش میکنیم.در اینجا ما یک دیتابیس مجزا که میتونه شامل Redis, Mysql, Mongodb باشه رو به عنوان مکانی برای قرار دادن اطلاعات تحلیلی قرار بدیم و به صورت زمان بندی شده و منظم در روز یا ساعت اطلاعات رو بروزرسانی کنیم.در نهایت لایه فرانت در پنل کاربری، اطلاعات قرار داده شده در مرحله قبل رو فراخوانی میکنه و به کاربر نشون میده.بسیارخب تا اینجا نکات جالبی رو بررسی کردیم. خیلی از چالش هایی که میخوریم رو میتونیم با این معماری حل کنیم. در قسمت های بعدی ادامه مطالعاتم رو مینویسم براتون.تا درودی دیگر بدرود.

دلمغز نوشته - چالش های من در Big Data - قسمت ۲ - توییتر چکار میکنه

Payam Jafari — Tue, 02 Feb 2021 20:57:36 +0330

درود مجدد بر شما. امروز میریم برای ادامه قسمت قبلی و به چالش هایی که من در Big data خوردم میپردازیم. همچنین دوباره میگم که ممکنه در سری قسمت های دلمغز نوشته نکاتی و جملاتی به کار برده بشه که ۱۰۰ درصد دقیق و مستند نباشه و فقط قصد داره که زاویه دید یک برنامه نویس بکند رو به متن تبدیل کنه.در قسمت قبلی راجب این گفتیم که در شرکت ما برای مدیریت بیگ دیتا از الاستیک استفاده کرده و کار از اونجایی به چالش کشید که برخی از مشتری ها میخواستن کوئری هایی از نوع رابطه ای یا relational بزنن که برای ما این سوال رو به وجود آورد که چطور میتونیم کوئری هایی شبیه رابطه ای اما از نوع غیر رابطه ای بزنیم.تا الان از روش های دستی و غیر بهینه استفاده میشده که در خیلی از مواقع به شدت سرعت کوئری ها رو کند میکرده.با مطالعه هایی که دیروز و امروز داشتم باعث شد که به این فکر بیوفتم که شاید قرار نیست ما به طور آنی یا realtime کوئری های سنگین بزنیم.اگه به نمونه های واقعی مثل شبکه های اجتماعی بزرگ همانند فیسبوک و توییتر نگاه کنیم. با کمی تحقیق به این جواب میرسیم که تمامی نتایجی در این شبکه های اجتماعی میبینیم تماما کش شده هست و هیچ چیزی به طول مستقیم پردازش نمیشه.به طور مثال با تحقیقاتی که راجب توییتر کردم میبینیم که برای نمایش صفحه Home در توییتر از یک ترفند جالب استفاده شده که در زیر مشاهده میکنیم.همونطور که میبینید وقتی در توییتر ما یک پست رو ارسال میکنیم ابتدا به سمت لود بالانسر میره و بعد در داخل ردیس redis درون لیست پست های کاربرانی که فالو کرده اند قرار داده میشه.نکته: ردیس redis یک دیتابیس درون رم هست که برای ذخیره موقت اطلاعات به صورت key=value استفاده میشه.درواقع اینجا ما برای هر کاربر یک لیست از ۱۰۰ پست اولی که قراره در صفحه Home یک کاربر نشون داده بشه داریم که بصورت کش داخل رم قرار دادیم. این محتوای کش شده هر بار که فالوور ها پستی جدید میذارن اپدیت میشه. پس در این صورت وقتی ما وارد سایت یا اپلیکیشن توییتر میشیم همون لحظه تمامی پست هایی که باید نشون داده بشه رو از کش میخونه و به ما نمایش میده در کمتر از یک ثانیه.پس تا اینجا اینو فهمیدیم که ما قرار نیست از دیتای اصلی در همه جا استفاده کنیم. اون اطلاعات قرار هست که کش بشه و به صورت خلاصه و تمیز شده در دیتابیس دیگری قرارداده بشه.حالا این سوال برام پیش میاد که در قسمت جستجو پیشرفته توییتر چجوری کوئری ها رو مدیریت کردن. آیا تموم جواب های اونجا هم کش شده هست یا اینکه به صورت آنی سرچ میشه. اینجاست که باید تحقیقات بیشتری اعمال بشه.در قسمت بعدی به اینکه اصول طراحی Big Data چیست و چه مراحلی و چه ابزار هایی باید استفاده بشه اشاره میکنم.فعلا تا قسمت بعدی...

دلمغز نوشته - چالش های من در Big data - قسمت اول

Payam Jafari — Sun, 31 Jan 2021 20:56:21 +0330

درود بیکران بر شما. این قسمت اول از سری دلمغز نوشته هاست که اصلا جنبه آموزشی نداره و فقط قصد داره چالش ها و اتفاقات رخ داده برای یک برنامه نویس بکند-Backend رو تبدیل به متن بکنه. پس ممکنه که در اون حرفای غلط و کمتر دقیق باشه. به همین خاطر خواهشمندم از دوستان آگاه تا در نظرات من رو تصحیح کنن.امروز تو شرکت صحبت بر این شد که ساختار دیتابیسی یکی از پروژه هامون که خیلی وقت هست با الاستیک کار میکنه رو بهینه کنیم چون در هنگام استفاده ازش به چالش هایی خوردیم که نیاز به یک بازنگری درباره اش هست.اولین چالش ما این بود که نیازمند این بودیم که در دیتابیس non relational کوئری هایی از نوع relational بزنیم. بعد از مدتی کوتاه به این فکر افتادیم که شاید اصلا معماری دیتابیسمون نیاز به تغییر داره و حتما نیاز نیست که از دیتابیس relational استفاده کنیم.پس از مدتی تحقیق و جستجو به یک دیتابیس جالب بر خوردم که بهتون معرفی میکنم.کلیک هاوس - ClickHouseدر زمان هایی نچندان دور در سال 2016 کمپانی روسی Yandex تصمیم گرفت که دیتابیس پیشرفته خودشو به جهانیان ارائه بده. به گفته خودشون اونها از این دیتابیس برای کارهای آماری و گزارش گیری استفاده میکنند.این دیتابیس ادعا میکنه که از دیتابیس های رایج حدود ۱۰۰ الی ۱۰۰۰ برابر سریع تره. شاید این ادعا یکم ترسناک یا حتی غیرممکن بیاد، اما تست ها نشون میده که حداقل در Aggregation و Histogram این آمار درست هست و کلیک هاوس به شدت سریع پاسخ میده اما همچنان مثل دیتابیس های NoSql دیگه مثل الاستیک در Update, Delete کند هست.متاسفانه به دلیل نوپا بودن این دیتابیس هنوز نمیشه روش به عنوان یک دیتابیس اصلی برای پروژه های بزرگ استفاده کرد. اما تا الان نتایجی که ازش دیدیم به شدت راضی کننده بوده. نمونه شرکت های بزرگی که ازش استفاده کردن تا الان میشه از Cloudflare و Uber و چند شرکت بزرگ دیگه نام برد.پس چکار کنیم ؟طبق چیزایی که من خوندم و مشورت با برخی از همکاران میتونیم از مکانیزم های داینامیک استفاده کنیم. به طور مثال میتونیم دیتاها رو به دیتاهای کم اهمیت و پر اهمیت و یا دیتاهای بازه زمانی فلان تا فلان موقع دسته بندی کنیم و هنگامی که کاربر درخواست میده بسته به نوع درخواست و چیزهایی که میخواد دیتاهای مناسب رو نشونش بدیم. اینجوری میشه سرعت کوئری ها رو بالا برد.یک راه دیگه هم که میشه استفاده کرد میزان بالای کش-Cache هست. میتونیم اکثر دیتا رو کش کنیم و به کاربر مقادیر کش شده رو نشون بدیم. این راه یک محدودیت بزرگ داره و اونم اینه که اگه کاربر فیلتر های غیر قابل پیش بینی بزنه دیگه کشی وجود نداره که بهش نشون بدیم.راه حل های دیگه ای مثل استفاده از MSSQL یا Oracle بود که وقت نشد بیشتر روش وقت بذارم. در قسمت های بعدی بهش میپردازم. همچنین در قسمت بعدی به راه حل هایی که کمپانی های بزرگ مثل فیسبوک و توییتر و اینستاگرام و ... ساخته و پرداخته اند اشاره میکنم.ممنون که تا اینجا با دل و مغز من همراهی کردین.

همه چیز درباره phpdoc - قسمت اول

Payam Jafari — Sat, 02 Jan 2021 17:40:22 +0330

درود بر شما. از امروز شروع میکنیم و یک سری از قسمت های آموزشی برای phpdoc رو خدمت شما اراعه میدیم. همچنین یادآوری میکنم که مطالبی که در این مقالات اشاره میشه ممکنه ۱۰۰ درصد دقیق نباشه اما تلاش بر این هست که حداکثر دقت رو داشته باشه.برای شروع این دوره نیاز به دانش های اولیه ای هست که شامل موارد زیر میشه:دانش کافی درباره برنامه نویسی سمت وبدانش کافی درباره زبان phpدانش کافی درباره بحث شی گراییمقدمهبحث phpdoc یک الگو کامنت نویسی برای زبان php و برخی زبان های دیگه هستش که با به کارگیری اون میتونیم مستندات مربوط به هر کلاس یا متد یا ... در کد هامون رو بسازیم.همونطور که میدونید در ابزار های کدنویسی مثل phpstorm یا vscode و ... قابلیت های خاصی برای ساختن phpdoc وجود داره که کار ما رو آسون تر میکنه. به طور مثال در phpstorm با وارد کردن کد /** و سپس اینتر میتونید به طور خودکار برای کلاس یا متد هاتون کامنت بسازید.بذارید در عمل با یک مثال ساده تمرین کنیم.

چند نکته جالب برای بهینه کردن داکرفایل Dockerfile - قسمت دوم

Payam Jafari — Tue, 29 Dec 2020 19:20:13 +0330

سلام. امروز میریم به سراغ ادامه قسمت قبلی که راجب بهینه کردن داکرفایل صحبت کردیم. همچنین دوباره یادآوری میکنم که نکاتی که اراعه میدم ممکنه ۱۰۰ درصد دقیق نباشه اما تلاش من بر این هست که حداکثر دقت رو داشته باشه. همچنین یادآوری میکنم که برای درک این نکات لازمه که دانش حداقلی با داکر و داکرفایل داشته باشید.از دوستان آگاه در زمینه داکر خواهش میکنم در صورت مشاهده هر اشتباهی در نظرات ما رو باخبر کنن.حالا بریم سر ادامه مطلب:ورژن های مختلف یک ایمیج رو با استیج جداگانه تعیین کنیدگاهی اوقات میخوایم که ورژن های مختلف یک ایمیج رو برای سیستم عامل های مختلف یا موقعیت های مختلف استفاده کنیم برای این کار میتونیم چندین FROM از یک ایمیج منتها با ورژن های مختلف وارد کنیم و سپس در دستور اجرایی نام اون رو وارد کنیم.از متغیر ها میتونیم استفاده کنیمیک امکان جالب در داکرفایل این هست که میتونیم متغیر های مختلف رو بسازیم و مقدار اون رو به عنوان پارامتر در دستور ترمینال بگیریم. یکی از مزیت هاش این هست که باعث میشه از تکرار مجدد کد های داکرفایل جلوگیری کنیم. در مورد بالا که اشاره کردیم برای هر ورژن یک ایمیج کد ها رو مجددا استفاده کرده و حجم کد رو بالا برده. در اینجا میتونیم از متغیر ها استفاده کنیم و در ترمینال ورژن مورد نظر رو دریافت کنیم.در اینجا در هنگام اجرای دستور در ترمینال میتونیم با پارامتر --build-arg متغیر ها و مقدار های اون رو قرار بدیم.مراقب پر شدن هاردتون باشید :)بعد از مدتی که با داکر و کانتینر ها زیاد کار میکنید متوجه میشید که حجم زیادی رو اشغال کرده و برای کسایی که تو مقدار هارد محدودیت دارند ممکنه اذیت کننده باشه. با وارد کردن دستور زیر میتونید فایل های کش و اضافی رو حذف کنید.با وارد کردن این دستور محتوای زیر حذف میشوند:تمامی کانتینر های متوقف شدهتمامی نتورک هایی که حداقل در یک کانتینر استفاده نشده اندتمامی ایمیج های بی مصرفتمامی کش مربوط به کانتینر های ساخته شدهمیتونید روند تمیز کردن داکر رو اتوماتیک کنیدبا وارد کردن دستور زیر میتونید عملیات بالا که اشاره کردیم رو اتوماتیک کنید که به طور خودکار هر چند ساعت یا چند دقیقه اجرا بشه. $ docker run -d --restart=unless-stopped --name cleanup \ -v /var/run/docker.sock:/var/run/docker.sock \ docker /bin/sh -c \ "while true; do docker system prune -f; sleep 1h; done"داکرفایل از نوع "بزن در رو"گاهی اوقات ما میخوایم که یک داکرفایل کوتاه و اینلاین inline داشته باشیم و کد های داخل داکرفایل رو مستقیما در ترمینال قرار بدیم. یا اینکه میخوایم الکی فایل Dockerfile برای یک عملیات کوچیک نسازیم.اینجاست که این روش به کار میاد. برای انجامش ۲ تا راه داریم که هر ۲تارو در زیر قرار دادم.هر دو روش زیر یک نتیجه رو دارند و عملیات یکسانی رو انجام میدن.$ echo -e 'FROM busybox\nRUN echo "hello world"' | docker build ---$ docker build -<

چند نکته جالب برای بهینه کردن داکرفایل Dockerfile - قسمت اول

Payam Jafari — Mon, 28 Dec 2020 17:35:02 +0330

سلام. امروز میخوایم یکم راجب نکاتی که ممکنه زیاد باهاش توی داکرفایل بر بخورین صحبت کنیم. نکاتی که اراعه میدم ممکنه ۱۰۰ درصد دقیق نباشه اما تلاش من بر این هست که حداکثر دقت رو داشته باشه. همچنین یادآوری میکنم که برای درک این نکات لازمه که دانش حداقلی با داکر و داکرفایل داشته باشید.از دوستان آگاه در زمینه داکر خواهش میکنم در صورت مشاهده هر اشتباهی در نظرات ما رو باخبر کنن.حالا بریم سر اصل مطلب:در هنگام گرفتن یک ایمیج دقیقا ورژن رو مشخص کنید.وقتی در داکر فایل با دستور FROM میخوایم نام ایمیج رو مشخص کنیم بهتره که ورژن ایمیج مورد نظر رو وارد کنیم. معمولا خیلی از ماها از دستور latest استفاده میکنیم که ممکنه در آینده با ورژن های جدیدتر اون ایمیج به مشکل بخوره. پس وارد کردن ورژن دقیق ایمیج مهم هست که مطمعن بشیم در آینده کاربران آن به ارور نخورن.در صورت امکان از ایمیج های رسمی استفاده کنیدگاهی اوقات برای استفاده از یک برنامه خاص میشه از چند روش استفاده اش کرد. به طور مثال در تصویر زیر میبینید که پکیج openjdk رو اومده داخل ایمیج debian دانلود و نصب کرده. در صورتی که اگر در داکرهاب جستجو کنیم ایمیج رسمی openjdk هست و نیازی به کد های اضافی نیستشبه دنبال نسخه های کم حجم تر ایمیج مورد نظر بگردیدگاهی اوقات در ایمیج های رسمی ورژن های مینیمال شده و کم حجم شده وجود داره که فقط کافیه در هنگام اجرای دستور FROM ورژن درست رو وارد کنیم. با این کار بیخودی حجم پکیج بالا نمیره.میتونید از چند FROM در داکرفایل استفاده کنیددر داکرفایل میتونید چندین FROM را اجرا کنید و برای هر کدام یک نام مشخص تعیین کنیددر دستور COPY میتونید از محتوای استیج های دیگه استفاده کنیداگر به تصویر دقت کنید در مرحله دوم FROM که openjdk رو فراخوانی میکنه از دستور COPY استفاده کرده و یک پارامتر با نام --from استفاده کرده. با این پارامتر میگیم که محتوای مرحله قبلی که نامش رو builder گذاشته بودیم رو به عنوان مبنا قرار بدهمیتونید در هنگام اجرای ساخت داکر استیج خاصی رو وارد کنیددر قسمت های بالا گفتیم که میتونیم در یک داکرفایل چندین استیج یا همان FROM استفاده کنیم و برای هر کدام یک نام خاص تعیین کنیم. نکته جالب اش اینجاست که میتونیم در هنگام اجرای دستور docker build نام یک استیج خاص رو وارد کنیم که فقط همون اجرا بشه.گاهی اوقات ما داکرفایل رو قبلا اجرا کردیم و بعدا میخوایم فقط قسمت خاصی از پروژه که ویرایش شده اپدیت بشه. اینجا این دستور به کار میاد.خب من ازین بیشتر خسته اتون نمیکنم در قسمت دوم با نکات بیشتری ادامه میدیم :)