<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های علیرضا حیدری | Alireza Heydari</title>
        <link>https://virgool.io/feed/@alireza97hi</link>
        <description>فارغ‌التحصیل دانشگاه امیرکبیر |‌ برنامه‌نویس فرانت کافه‌بازار/بلد</description>
        <language>fa</language>
        <pubDate>2026-06-17 16:51:49</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/19197/avatar/avatar.png?height=120&amp;width=120</url>
            <title>علیرضا حیدری | Alireza Heydari</title>
            <link>https://virgool.io/@alireza97hi</link>
        </image>

                    <item>
                <title>مطمئن کد بزنیم، مطمئن دیپلوی کنیم - برشی از Continuous Delivery</title>
                <link>https://virgool.io/@alireza97hi/%D9%85%D8%B7%D9%85%D8%A6%D9%86-%DA%A9%D8%AF-%D8%A8%D8%B2%D9%86%DB%8C%D9%85-%D9%85%D8%B7%D9%85%D8%A6%D9%86-%D8%AF%DB%8C%D9%BE%D9%84%D9%88%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-%D8%A8%D8%B1%D8%B4%DB%8C-%D8%A7%D8%B2-continuous-delivery-yblvyjispltk</link>
                <description>برای تعریف Continuous Delivery می‌توانیم به تعریف زیر اتکا کنیم:تحویل مداوم (CD) یک رویکرد مهندسی نرم‌افزار است که در آن تیم‌ها نرم‌افزار را در چرخه‌های کوتاه تولید می‌کنند و تضمین می‌کنند که نرم‌افزار را می‌توان به طور قابل اعتماد در هر زمان منتشر کرد و هنگام انتشار نرم‌افزار، بدون انجام دستی این کار را انجام داد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 13 Dec 2021 23:55:35 +0330</pubDate>
            </item>
                    <item>
                <title>  با مانیتورتون مانیتور کنید / ابزارهای مانیتورینگ و قدرت‌های خدایی آن‌ها - Monitoring Tools</title>
                <link>https://virgool.io/@alireza97hi/%D8%A8%D8%A7-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%D8%AA%D9%88%D9%86-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1-%DA%A9%D9%86%DB%8C%D8%AF-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-%D9%88-%D9%82%D8%AF%D8%B1%D8%AA-%D9%87%D8%A7%DB%8C-%D8%AE%D8%AF%D8%A7%DB%8C%DB%8C-%D8%A2%D9%86-%D9%87%D8%A7-monitoring-tools-cnymdnl55knf</link>
                <description>برنامه‌های زیادی به محصولی تبدیل شده‌اند که توسط کاربران مختلفی استفاده می‌شود. بسیاری از برنامه‌ها به قدری توسعه پیدا کرده‌اند که هزاران تا میلیون‌ها کاربر روزانه از آن‌ها استفاده می‌کنند. به هر نسبتی که کاربران یک برنامه بیشتر شود دقت در بررسی مشکلات برنامه بیشتر می‌شود. همچنین برنامه‌های سطح وب‌ای نیز وجود دارند که لازم دارند تا همیشه و بدون اشکال بالا باشند و پاسخگو کاربران باشند به این دلیل که توسط موتور‌های جستجو مورد بررسی قرار می‌گیرند و اگر ثانیه‌ای مشکل داشته باشند امتیاز پایینی توسط موتور‌های جستجو میگیرند از طرفی کاربران نیز از محصول ناراضی خواهند بود.چندین و چند راه برای زیر نظر داشتن محصول وجود دارد. راه‌حلی که ما میخواهیم در این مطلب به آن بپردازیم  monitoring tools ها هستند.این ابزار‌ها کمک می‌کنند تا اطلاعات لحظه‌ای برنامه‌ها زیر نظر باشد. برای مثال فرض کنید  uptime سرویس مدنظر باشد و اگر ثانیه‌ای سرویس پایین بیاید لازم است تا این ۱۰۰ درصد نبودن uptime به اطلاع برسد. یا مثلا  response time ها مدنظر است و زمانی که response time از حدی بالاتر برود نشان می‌دهد که سیستمی زیر بار فشار زیادی است و لازم است تا راه‌حل‌های متناسب با آن زیر نظر قرار بگیرد. به طور کلی یک monitoring tools به صورت زیر تعریف می‌شود:ابزارهای مانیتورینگ برای پیگیری مداوم وضعیت سیستم در حال استفاده، به منظور دریافت اولین هشدار در مورد خرابی، نقص یا مشکلات و بهبود آنها استفاده می شود.یکی از این ابزار‌ها Prometheus است.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 13 Dec 2021 23:45:08 +0330</pubDate>
            </item>
                    <item>
                <title>پستچی به سبک صف! Message Queue ها و ویژگی‌های آن‌ها</title>
                <link>https://virgool.io/@alireza97hi/%D9%BE%D8%B3%D8%AA%DA%86%DB%8C-%D8%A8%D9%87-%D8%B3%D8%A8%DA%A9-%D8%B5%D9%81-message-queue-%D9%87%D8%A7-%D9%88-%D9%88%DB%8C%DA%98%DA%AF%DB%8C-%D9%87%D8%A7%DB%8C-%D8%A2%D9%86-%D9%87%D8%A7-gppkvt9bobl9</link>
                <description> احتمالا در پروژه‌های برنامه‌نویسی به قسمتی رسیده‌اید که در آن دو برنامه باید با یکدیگر ارتباط داشته باشند. این ارتباط می‌تواند ویژگی‌های مختلف داشته باشد. مثلا ممکن است ارتباط  real-time مدنطر باشد. مثلا مانند زمانی که در لحظه در پروژه نیاز به گرفتن دیتای لحظه‌ای نتایج مسابقات دارید یا موارد مشابه. در شرایط دیگری این ارتباط می‌توانند مانند  API Call های ساده باشد که منتظر جواب آن نیز هستید. مثلا کلاینت درخواستی را به سرور ارسال می‌کند و برای مثال میخواهد آیتم جدیدی بسازد و نیاز به تایید از سرور دارد. یا پولی را آنلاین پرداخت می‌کنید و نیازمند گرفتن کد پیگیری آن هستید.ارتباط دیگری وجود دارد که بین دو برنامه ایجاد می‌شود اما نیازی به گرفتن پاسخ آن در لحظه نیست و دو برنامه مستقل از یکدیگر هستند. برای مثال در دنیای واقعی وقتی نامه‌ای ارسال می‌شود این نامه به اداره پست ارسال می‌شود. سپس اداره پست پس از اینکه خودش صلاح دید (!) نامه‌ها را به مناطق مشخص می‌برد و به دست گیرنده‌های آن می‌رساند. گیرنده‌ها نیز از طریق صندوق پستی راه ارتباطی با اداره پست را باز گذاشته اند. در برنامه‌ها نیز ممکن است این مورد پیش بیاید. برای مثال فرض کنید که میخواهید اطلاعاتی را به قسمتی بدهید یا درخواست پردازش اطلاعاتی را به برنامه‌ای بدهید اما دیگر به نتایج آن در لحظه کاری ندارید. می‌توانید این درخواست را به یک واسط میانی داده تا این کار را انجام دهد و به گیرنده انتقال دهد. حال ممکن است سوال پیش بیاید که چرا یک واسط میانی باید وجود داشته باشد؟ یکی از دلایل وجود این واسط میانی تبدیل درخواست‌های asynchronous به یک صف است. به این صورت که هر برنامه‌ای می‌تواند به صورت موازی درخواست ایجاد کند و واسط این درخواست‌ها را می‌گیرد و در یک صف قرار می‌دهد و به صورت صف آن‌ها را به مقصد مشخص می‌رساند. با این کار دیگر فرستنده منتظر پاسخ نیست و هر زمان که لازم بداند درخواست را ارسال می‌کند. پس اگر بخواهیم تعریفی از  message queue داشته باشیم به صورت زیر خواهد بود:یک  message queue یک پروتکل ارتباطی ناهمزمان را ارائه می دهد، که سیستمی است که پیامی را در صف پیام قرار می دهد و نیازی به پاسخ فوری برای ادامه پردازش ندارد.ایمیل احتمالاً بهترین نمونه از ارتباطات ناهمزمان است. در این ارتباط شما محتوای خود را می‌فرستید و این محتوا در صف قرار می‌گیرد و بدون آن که نیازی به نتیجه ارسال آن داشته باشید به ادامه کار خود می‌پردازید. این محتوا در صف قرار میگیرد و در سریعترین زمان ممکن به گیرنده خود می‌رسد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 13 Dec 2021 23:15:10 +0330</pubDate>
            </item>
                    <item>
                <title>Containerization and container orchestration: یک جعبه سربسته که کاری با دیگران ندارد</title>
                <link>https://virgool.io/@alireza97hi/containerization-and-container-orchestration-%DB%8C%DA%A9-%D8%AC%D8%B9%D8%A8%D9%87-%D8%B3%D8%B1%D8%A8%D8%B3%D8%AA%D9%87-%DA%A9%D9%87-%DA%A9%D8%A7%D8%B1%DB%8C-%D8%A8%D8%A7-%D8%AF%DB%8C%DA%AF%D8%B1%D8%A7%D9%86-%D9%86%D8%AF%D8%A7%D8%B1%D8%AF-ikylb4rbspjf</link>
                <description>اگر دستی بر برنامه‌نویسی داشته باشید حتما تجربه کار با پروژه‌های مختلف رو هم تجربه کرده‌اید. پروژه‌هایی که نیازمندی‌های خاص خود را دارند و هرکدام پیش‌نیاز‌های نرم‌افزاری خود را دارند. این پیش‌نیازها چه هستند؟فضای لازم: برای مثال شما لازم دارید تا یک فضای مشخص برای اپلیکیشن خود ایجاد کنید تا داده‌ها در آن ذخیره شوند یا برنامه‌ها فضای مشخصی از آن را اشغال کنند. همچنین احتمالا میخواهید این فضا محدودیت‌ها و حد خاص خود را داشته باشد و بر دیگر فضاها دسترسی نداشته باشد.برنامه‌های لازم: احتمالا این پروژه‌ها نیازمند این هستند تا برنامه‌های مشخصی را از قبل در محیط خود نصب داشته باشند. مثلا اگه برای اجرای یک پروژه پایتون اقدام می‌کنید ممکن است که لازم داشته باشید تا پکیج‌های پایتون توسط دستور pip یا به هر روش دیگری ذخیره شده باشند. یا اگر یک پروژه NodeJS مدنظر باشد ممکن است لازم باشد تا کتابخانه‌های مشخص شده در package.json نصب شده باشند.محیط مشخص: ممکن است لازم داشته باشید تا محیطی که برنامه در آن اجرا می‌شود دستور‌های مشخصی تعریف شده باشند یا تنظیمات خاصی فعال شده باشند.محدودیت دسترسی: احتمالا بخواهید پروژه موردنظرتان فقط در محیط مشخصی که دسترسی‌های مشخصی دارد فعال باشد و نتواند فراتر از آن تغییری ایجاد کند و مثلا در سطح سیستم‌عامل شما اثری بگذارد. یا پروژه‌های مختلفی در حال اجرا دارید که میخواهید هرکدام بر روی دیگری اثر نگذارند و در محیطی ایزوله در حال اجرا باشند.اطلاعات لازم پروژه: همچنین شما علاوه بر تمامی مشخصات بیان شده نیاز دارید تا کد پروژه را نیز در محیط داشته باشید.پس براساس اطلاعات بالا به طور خلاصه به محیطی نیاز داریم تا موارد زیر را با هم در قالب یک بسته داشته باشد:coderuntimesystem toolssystem librariessettingsدارا بودن این موارد در یک محیط ایزوله کمک می‌کند تا شما یک پروژه را در سطح سیستم‌عامل اجرا کنید و اجرای این پروژه در بیرون از سطح دسترسی آن اثری نداشته باشد. با این کار چندین پروژه می‌توانند در یک سیستم‌عامل اجرا شوند که باتوجه به ایزوله بودن هرکدام محیطی ایده‌آل شبیه‌سازی می‌شوند همانند اینکه یک معماری micro-service پیاده‌سازی شده باشند و ذخیره داده و انجام پردازش‌ها و غیره در دیگر محیط‌ها اثری نگذارد. مثلا با این کار شما در صورتی که دولوپر کلاینت باشید و بخواهید پروژه بک‌اند را اجرا کنید تنها لازم است تا محیط خاص بک‌اند را با دستوراتی ساده اجرا کنید و از آن استفاده کنید.تمامی ویژگی‌هایی که در بالا بیان شد منجر به تولید مفهوم containerization , کانتینر‌ها شد. به طور کلی میتوانیم تعریف زیر از container ها را داشته باشیم: Container : is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. ( از سایت docker ) مزایای  containerization:Consistent Environment:کانتینرها به توسعه دهندگان این امکان را می دهند که محیط های قابل پیش بینی ایجاد کنند که از سایر برنامه ها جدا شده اند. کانتینرها همچنین می توانند شامل وابستگی های نرم افزاری مورد نیاز برنامه باشند، مانند نسخه های خاص زمان اجرا زبان برنامه نویسی و سایر کتابخانه های نرم افزار.Runnable Virtually:کانتینرها می توانند تقریباً در همه جا اجرا شوند و توسعه و استقرار را تا حد زیادی تسهیل می کنند: در سیستم عامل های لینوکس، ویندوز و مک. در ماشین های مجازی ؛ در ماشین توسعه دهنده یا در مراکز داده در محل؛ و البته در  فضای ابری.Isolation:کانتینرها CPU، حافظه، ذخیره سازی و منابع شبکه را در سطح سیستم عامل مجازی می کنند و به توسعه دهندگان یک نمای سندباکس از سیستم عامل به طور منطقی ایزوله از سایر برنامه ها ارائه می دهند.معایب  containerization:از آنجایی که کانتینرها دارای هسته سیستم عامل هستند، اگر سیستم عامل با آسیب پذیری مواجه شود، به طور بالقوه روی همه کانتینرهایی که در سیستم عامل ریشه دارند تأثیر می گذارد. از طرف دیگر ماشین های مجازی فقط هایپروایزر را به اشتراک می گذارند که عملکرد کمی دارد و کمتر مستعد حملات است.اگر در حال اجرای یک برنامه پیچیده سازمانی با کانتینر هستید، باید از کانتینرهای زیادی مراقبت کنید، شاید صدها یا حتی هزاران. مراقبت از تعداد زیادی ظروف می تواند بسیار طاقت فرسا باشد و پیچیدگی را افزایش دهد.سرویس‌های متعددی جهت ایجاد کانتینر ایجاد شده است.در کنار ایجاد کانتینتر‌ها مسئله‌ای برای مدیریت این کانتینر‌ها نیز ایجاد می‌شود. به این صورت که این کانتینرها به چه صورت در شبکه قرار بگیرند. یا چطور بتوانیم چندین کانتینر مشابه داشته باشیم تا در صورت پایین بودن یکی از دیگری بتوان استفاده کرد. برای حل این مسائل مفهوم container orchestration  ایجاد شد. با کمک این راه‌حل ابزار‌هایی به وجود آمد تا بتواند مسائل زیر را بررسی کند:Container’s lifecycle:در ابتدا بگذارید یک تعریف از چرخه حیات داشته باشیم. چرخه حیات از همان ابتدا بالا آمدن یک کانتینر تا زمانی که کانتینر به کار خود خاتمه می‌دهد و دیگر از آن استفاده نمی‌شود گفته می‌شود.چرخه حیات را می‌توان شامل تمامی موارد زیر دانست:Create Container:  ایجاد کانتینرStart Container: مراحل اولیه بالا آمدن کانتینرRun Container: در حال اجرا بودن کانتینرPause Container: توقف کوتاه کانتینرStop Container: توقف کامل کانتینر جهت نابود کردن آنDelete Container: حذف کانتینرKill Container: خارج کردن از حالت  RUN یکی از وظایف  container orchestration ها این است که این حالت‌ها را مدیریت کند و در صورت بروز مشکل در هر حالت به حل آن بپردازند.Provisioning: به دلیل اینکه کانتینرها به وجود آمده و در طول حیات خود اطلاعات را ذخیره می‌کنند و نیز حذف می‌شوند داده‌هایی که دارند به اصطلاح ephemeral هستند که یعنی پس از اینکه کانتیر متوقف شود از بین می‌روند. یکی از مثال‌ها برای این مورد مثل داده‌هایی هست که در stdout و به صورت لاگ منتشر می‌شوند. یکی از قابلیت‌هایی که orchestration ها می‌توانند به کانتینرها بدهند این است که محیطی را در اختیار آن‌ها قرار بدهند تا داده‌ها در آن‌ها ذخیره شود و حتی پس از توقف کانتینر نیز بتوان به آن دسترسی داشت.Deployment: دیپلویمنت و بالا آوردن پروژه نیز از وظایف orchestration است تا بتواند به راحتی کانتینر را به محیط محصول وصل کند.Scaling (up and down):همانطور که گفته شد یکی از ویژگی‌ کانتینر‌ها فضای اختصاصی خود است. اما تمامی محصولات ممکن است روزی بزرگ و بزرگ‌تر شوند و کاربران بیشتری را جذب کنند یا بالعکس از کاربران خود بکاهند و همین موارد باعث افزایش یا کاهش فضا و کانفیگ‌های کانتینر می‌شود. یکی از کارهایی که orchestration ها می‌توانند بکنند این است که این فضاها را به راحتی برای کانتینر تغییر دهند.Networking:اتصال به شبکه نیز از کارهای این راه‌حل است. تا بتواند کانتینر بالا آمده را به شبکه اینترنت وصل کند، به آن ip مشخص بدهد، دامنه‌های آن را تعیین کند و غیره و غیره.Load balancing:از جمله کارهای دیگری که orchestration می‌تواند برای کانتینری که scale شده است انجام بدهد این است که چندین کانتینر مشابه بالا بیاورد و جهت اینکه درخواست‌ها به یک کانتینر مشخص زیاد نشود درخواست‌ها را بین کانتینر‌های مختلف پخش کند. از جمله پیچیدگی‌ای که این قسمت دارد نگهداری اطلاعات مشترکی که بین کانتینر‌ها در اشتراک است می‌باشد.ابزارهای متن باز برای containerization و container orchestration:k8s (kubernetes):این ابزار یکی از بهترین container orchestration های ممکن است که امکانات گسترده‌ای را در اختیار قرار می‌دهد.ابزار Kubernetes یک سیستم منبع باز قدرتمند است که در اصل توسط گوگل برای مدیریت برنامه های کاربردی کانتینری در یک محیط خوشه ای توسعه یافته است. ماموریت آن ارائه بهترین راه ممکن برای مدیریت اجزا و خدمات مرتبط و توزیع شده در طیف گسترده ای از زیرساخت ها است. هنگامی که برنامه‌ها (سرویس‌های میکرو) با وابستگی‌ها و پیکربندی‌هایشان در یک کانتینر بسته‌بندی می‌شوند، ابزاری برای مدیریت خودکار کانتینرها و کوچک‌سازی آن‌ها بر اساس الزامات دسترسی برنامه مورد نیاز است. Kubernetes ابزار عالی برای آن است.باتوجه به اینکه مفاهیم این ابزار در بسیاری از ابعاد کاربرد دارد به توضیح برخی از این مفاهیم می‌پردازیم:Container:یک image اجرایی که شامل یک نرم افزار واحد و تمام وابستگی های آن است. در مورد ما، این یک ظرف Docker است.Node:یک ماشین مجازی یا فیزیکی که به عنوان کارگر برای Kubernetes استفاده می شود. Kubernetes مدیریت خود را در عمل انتزاع خواهد کرد. یک خوشه Kubernetes شامل یک گره اصلی است که برای مدیریت وضعیت خوشه در زمان واقعی استفاده می شود و امکان تعامل کاربر را فراهم می کند.Cluster:مجموعه ای از node ها که کانتینرهای مدیریت شده توسط Kubernetes را اجرا می کنند.Pod:کوچکترین شی k8s. یک pod مجموعه ای از کانتینرها را اجرا می کند. معمولاً، pod ها هر کدام یک کانتینر دارند، اما در برخی موارد، ممکن است شامل خدمات کانتینری اضافی مانند یکی برای افزودن قابلیت های ثبت گزارش نیز باشد.Deployment:یک object ای که مجموعه ای از pod های تکرار شده را مدیریت می کند. مقیاس پذیری یک میکروسرویس شامل افزودن pod های بیشتری به یک deployment است.Service:یک object که نحوه دسترسی به deploymentها یا گروه‌هایی از پادها را از طریق یک نقطه پایانی مشترک توضیح می‌دهد. ممکن است چیزهایی مانند متعادل کننده بار برای دسترسی به منبع ایجاد کند.Label:اصطلاح label ها به اشیاء Kubernetes (پاد، deployment، services و غیره) اضافه می شوند تا با هم انتخاب شوند.Selector:یک selector به یک label ارجاع می دهد تا به عنوان مثال، امکان تعامل با مجموعه ای از اشیاء، مانند چندین کانتینر برای اهداف متعادل سازی بار را فراهم کند.Kubectl:ابزار command line که برای تعامل با node اصلی Kubernetes استفاده می شود.منابع:Introduction to Containerization and Kubernetes - https://medium.com/crossml/introduction-to-containerization-and-kubernetes-294d1f9b4aa8این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 13 Dec 2021 22:19:43 +0330</pubDate>
            </item>
                    <item>
                <title>دروازه‌ها را باز کنید/ مفهوم API Gateway و استفاده‌ها</title>
                <link>https://virgool.io/@alireza97hi/%D8%AF%D8%B1%D9%88%D8%A7%D8%B2%D9%87-%D9%87%D8%A7-%D8%B1%D8%A7-%D8%A8%D8%A7%D8%B2-%DA%A9%D9%86%DB%8C%D8%AF-%D9%85%D9%81%D9%87%D9%88%D9%85-api-gateway-%D9%88-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-qmitrxhqe7ss</link>
                <description>بذارید شروع مطلب رو با تعریف‌های پایه شروع کنیم و به طرح مسئله‌مون برسیم. تعریف پایه‌مون رو هم بذاریم  API.API, API in Systems, and Finally API Gateway! همونطور که میتونید API  مخفف عبارت Application Programming Interface است. تعریف آن براساس چیزی که در ویکیپدیا به آن اشاره شده است به صورت زیر است:An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.مبحث قابل بحث ما در حوزه وب است پس به زبان فارسی و در محدوده‌ای که قابل بحث این مطلب است  API به واسط برنامه‌نویسی گفته می‌شود که بین دو عامل قرار می‌گیرد. دو عامل را در این قسمت Client و Server در نظر می‌گیریم. پس هر ارتباطی که بین این دو عامل صورت بگیرد را با کمک این مفهوم تعریف می‌کنیم. این ارتباط می‌تواند از چندین نوع مختلف کلاینت و با اهداف مختلف صورت گیرد. برای مثال فرض کنید شما یک سایت پخش آنلاین فیلم هستید که کاربران از طریق تلویزیون، گوشی، تبلت، لپتاپ یا هر وسیله ارتباطی دیگری از شما سرویس می‌گیرند. حال بگذارید یک سری از ویژگی‌هایی که در این ارتباطات مشاهده می‌شود را مشخص کنیم. مثلا ممکن است یکی از سرویس‌ها ( مثلا لاگین ) به دو API نیاز داشته باشد. یکی جهت تعیین هویت کاربر و دیگری جهت دریافت اطلاعات کاربر. برای این کار می‌توان چندین راه‌حل ارائه کرد. یکی از راه‌حل‌ها می‌تواند این باشد که در قسمت کلاینت ریکوئست اول حهت تعیین هویت کاربر زده شود و پس از تایید آن اطلاعات کاربر گرفته شود. اما این کار سربار ریکوئست‌ها را زیاد می‌کند و موجب شلوغ شدن سرور و حتی کند شدن آن می‌شود و همچنین رفت و آمد زیادی بین کلاینت و سرور ایجاد می‌کند. راه‌حل جایگزین می‌تواند این باشد که یک لایه میانی بین server و client قرار گیرد تا این لایه میانی هر دو ریکوئست را بزند و نتیجه نهایی را به client بزند. به این صورت دیگر  رفت و آمد بین سرور و کلاینت کاهش می‌یابد و همچنین سرعت انتقال ریکوئست‌ها کمتر به سرعت اتصال کلاینت تا سرور مرتبط است زیرا اکثر ریکوئست‌ها در لایه بین لایه میانی و لایه سرور زده می‌شود. این لایه میانی که یکی از مسائل ما را در زمینه ارتباط بین entity های مختلف را حل می‌کند  API Gateway نامیده می‌شود.هدف از ایجاد API Gateway  بودن به عنوان یک لایه میانی است تا بتواند عوامل زیر را ویژگی‌های زیر را در سیستم‌ها مجهز کند:SecureScale Protocol TranslationLoad balancing Cachingبا کمک API Gateway ها می‌توان اپ را Secure کرد. برای این کار لایه میانی می‌تواند ارتباط مستقیمی که بین کلاینت و سرور بود را از بین ببرد و مطمئن شود تا ریکوئست ارسالی اعتبار کافی جهت ارسال ریکوئست به سرور را دارا است. این ویژگی می‌تواند در هر دو معماری  Monolithic و Microservice پیاده‌سازی شود.از جهت Scale کارهای متعددی از سمت API Gateway صورت می‌گیرد. یکی از این کارها همانطور که در ابتدای مطلب به آن اشاره شد این است که به جای اینکه ریکوئست‌ها به صورت رفت و برگشتی باشند درخواست‌ها در قسمت API Gateway می‌زند و باعث می‌شود تا round trip و ریکوئست‌هایی که بین کلاینت و سرور به صورت پشت سر هم ارسال می‌شد کاهش یابد. این کاهش باعث می‌شود تا معماری در قسمت ارسال درخواست از API Gateway به سرور‌ها و سرویس‌های مختلف میکروسرویس ساده‌تر شود. یکی از این سادگی‌ها حذف بسیاری از موارد صحت کاربر در ریکوئست‌ها است. به این صورت که فقط ریکوئست ارسالی اول از سمت کلاینت مورد بررسی قرار می‌گیرد و بقیه ریکوئست‌ها با دیتا و  payload کمتری ارسال می‌شود. این کاهش داده باعث می‌شود تا حجم پردازش چندین برابر کمتر شود. از طرفی حذف بسیاری از ریکوئست‌ها در لایه کلاینت باعث می‌شود تا سرعت برقراری اتصالات افزایش یابد و همین نیز موجب Scalability می‌شود.به دلیل وجود این لایه میانی میتوان پروتکل‌های مختلفی را پشتیبانی کرد. به این صورت که هر ریکوئستی با هر پروتکل و دیتایی که لازم است به  API Gateway ریکوئست ارسال کند و API Gateway  با تبدیل پروتکل به پروتکل‌هایی که توسط سرویس‌ها پشتیبانی می‌شود اطلاعات را ارسال کند و در هنگام پاسخ دهد این عکس این عمل را انجام دهد و دروازه‌های جدیدی جهت ارسال ریکوئست ایجاد کند. با این کار کلاینت‌های مختلف که نیازمند ارسال ریکوئست با پروتکل‌های متناسب با شرایط خود هستند امکان ارسال درخواست را دارا خواهند بود و این معماری باعث می‌شود تا پشتیبانی از این نوع درخواست‌ها مستقل از توسعه کد باشد که به ماژولار کردن بیشتر کد کمک می‌کند.  همچنین می‌توان با کمک این معماری یک Load Balancer  نیز داشته باشیم. با این هدف که بتوانیم ریکوئست‌های مختلف را بین سرور‌های مختلف پخش کنیم تا از حجوم درخواست به یک سرور مشخص و ایجاد سربار زیاد در آن جلوگیری شود. با این کار به اصلاح لود ریکوئست‌ها  بالانس شده و باعث می‌شود تا بتوان به  Scale سیستم نیز کمک شود.  همچنین می‌توان با کمک این ویژگی بررسی کرد تا اگر دیتایی از سروری نیامد ریکوئست را به سرور دیگری ارسال کرد و با این کار از پایین بودن سرور و فرستاده نشدن ریسپانس به ریکوئست‌ها جلوگیری کرد.یکی از مواردی که به ما در ارسال پاسخ‌ها کمک می‌کند caching است. اگر بتوانیم پاسخ ریکوئست‌هایی را که قبلا ارسال شده ذخیره کنیم می‌توانیم در موارد متعددی از آن استفاده کنیم. در واقع لایه cache کمک می‌کند تا با کمک آن در مواردی که سرور پایین است یا نیازمند پاسخ‌دهی سریعتر هستیم با کمک آن سریعتر ریسپانس را ارسال کنیم. سرویس‌های ایرانی ارائه‌دهنده API Gateway: در ادامه به بیان دو سرویس‌دهنده ایرانی در این زمینه می‌پردازیم. این دو سرویس دهنده عبارتند از:سرویس  ابر درسا  سرویس وصلابر درسا: این سرویس دهنده محصولات متنوعی دارد. یکی از این محصولات به  API Gateway اختصاص دارد که نحوه کار آن به صورت کار با پنلی‌است که در اختیار صاحب وب‌سایت قرار می‌دهد. نمایی از این پنل را در زیر مشاهده کنید:پنل ابر درساهمانطور که مشاهده می‌کنید جهت استفاده نباید رکوردی با هاست را در DNS سروری که دست شماست تنظیم کنید. ابتدا مقدار host را مشخص کنید که نشان‌دهنده همان ip سرور شماست که در دامنه‌ای با همان هاست موردنظر بالا آمده است. path را که همان ادرس صفحه موردنظرتان هست را وارد کنید. host و path با یکدیگر صفحه مشخص را مشخص می‌کنند (  host:path ) و شما می‌توانید در این قسمت با کمک الگوریتم‌های مشخصی تعیین کنید که برای دسترسی به صفحات مشخص به کدام سرور مشخص ریکوئست زده شود تا این ترافیک پخش شود و از مشکلات احتمالی آینده جلوگیری شود.الگوریتم‌هایی که این سامانه تاکنون از آنان پشتیبانی می‌کند به صورت زیر است: FirstRandomRoundRobinLeastRequestsPowerOfTwoChoicesاین سامانه می‌تواند در آینده امکانات بیشتری را اضافه کند (!).نحوه پرداخت نیز به این صورت است که پس از انتخاب سرویس موردنظر خود می‌توانید فاکتور آن را جهت استفاده در مدت زمان معین پرداخت کنید.وصل:شرکت وصل یک سامانه با نام سورنا جهت مدیریت  API یا با استفاده مشخص‌تر API Gateway راه‌اندازی کرده است. پلتفرم مدیریت API سورنا توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند. همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژهای ارائه می‌کند تا شرکت‌های طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند. ( برگرفته از توضیحات وب‌سایت وصل )امکاناتی که این سامانه و پلتفرم در اختیار کاربران می‌دهد به شرح زیر است:مدیریت چرخه APIها با یک پلتفرم واحدفروشگاه ; کسب درآمد از سرویس‌هاامنیت، اعتماد در ارائه خدماتراه‌حل برای اینترنت اشیاءمانیتورینگ قدرتمندپنل مدیریت پیشرفتهابزار‌های متن‌باز برای استفاده از  API Gateway:یکی از ابزارهای متن‌باز جهت استفاده به عنوان  API Gateway نرم‌افزار متن باز nginx است:لینک اصلی سایت nginx:https://www.nginx.com/resources/wiki/#:~:text=NGINX%20is%20a%20free%2C%20open,an%20IMAP%2FPOP3%20proxy%20server.&amp;amp;amp;amp;amp;amp;text=NGINX%20is%20one%20of%20a,to%20address%20the%20C10K%20problem. لینک ریپازیتوری گیت‌هاب:https://github.com/nginxنرم افزار NGINX یک سرور رایگان، منبع باز و HTTP با کارایی بالا و پراکسی معکوس و همچنین یک سرور پراکسی IMAP/POP3 است. NGINX به دلیل عملکرد بالا، پایداری، مجموعه ویژگی های غنی، پیکربندی ساده و مصرف کم منابع شناخته شده است.این وب‌سرور که توسعه آن از اکتبر ۲۰۰۴ شروع شده است برای سرو کردن بسیاری از سامانه‌هایی که هم اکنون در حال فعالیت هستند استفاده می‌شود و به جز  API Proxy بسیاری از قابلیت‌های دیگر را نیز در اختیار کاربران قرار می‌دهد و استفاده‌های متنوعی دارد.نرم‌افزار NGINX به عنوان پراکسی معکوس و متعادل کننده بار با کارایی بالا و سبک وزن، دارای قابلیت های پیشرفته پردازش HTTP مورد نیاز برای مدیریت ترافیک API است. این باعث می شود NGINX به پلتفرم ایده آلی برای ساخت یک دروازه API تبدیل شود. جهت پیاده‌سازی ساده یک API Gateway تنها لازم است با کمک دستور proxy pass در nginx آشنا شوید. به قطعه کد زیر دقت کنید:location /api/warehouse/inventory { 
      proxy_pass http://warehouse_inventory;
 } با همین دستور ساده می‌توان آدرس /api/warehouse/inventory  آدرس را به آدرس ware_house_inventory پراکسی کرد. با کمک دستورات دیگر می‌توان استفاده‌های کامل‌تری از این نرم‌افزار کرد.برای آشنایی بیشتر می‌توانید به لینک زیر مراجعه کنید: Deploygin Nginx as an API Gateway - https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/  یکی دیگر از گزینه‌های متن‌باز برای استفاده به عنوان API Gateway میتواند kong باشد. ریپازیتوری این نرم‌افزار در لینک زیر قابل دسترسی است:kong - open source API Gatewayking - https://github.com/Kong/kongاز جمله کارهایی که توسعه‌دهندگان kong انجام داده است این است که تمامی فیچر‌های نام‌برده برای proxy را به صورت پیش‌فرض برنامه‌نویسی کرده‌اند و برنامه‌نویس می‌تواند تنها با کمک دانستن api بیان شده توسط kong کانفیگ موردنظر خود را مشخص کند و از هرکدام از فیچر‌های از قبل برنامه‌نویسی شده استفاده کند. این امکان باعث می‌شود تا توسعه دهندگان دیگر به اختراع کردن چرخ از اول نپردازند و تمرکز خود را بر روی حل مسائل پیچیده‌تر بگذارند. از جمله مواردی که این نرم‌افزار پیاده‌سازی کرده است موارد زیر است:Advanced routing:  این فیچر همان ریدایرکت کردن یا پروکسی را با امکانات بیشتر در اختیار قرار می‌دهدload balancing: https://docs.konghq.com/getting-started-guide/2.1.x/load-balancing/health checking: https://docs.konghq.com/gateway-oss/2.5.x/health-checks-circuit-breakers/Proxy, SSL/TLS termination, and connectivity support for L4 or L7 traffic.Plugins for enforcing traffic controls: با کمک این قسمت به کنترل مشخص‌تر روی ترافیک و حتی گذاشتن ریت‌لیمیت روی ریکوئست‌ها می‌توان کمک کردمنابع:What Is an API Gateway? - https://www.youtube.com/watch?v=1vjOv_f9L8IWhat is API gateway really all about? Java Brains - Brain Bytes : https://www.youtube.com/watch?v=1vjOv_f9L8Inginx - https://www.nginx.com/resources/wiki/nginx - API Gateway: https://www.nginx.com/learn/api-gateway/این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 13 Dec 2021 00:56:30 +0330</pubDate>
            </item>
                    <item>
                <title>  تفسیری بر DDD</title>
                <link>https://virgool.io/@alireza97hi/%D8%AA%D9%81%D8%B3%DB%8C%D8%B1%DB%8C-%D8%A8%D8%B1-ddd-gcl87lezun9a</link>
                <description>در این مطلب قرار است تا نکاتی در رابطه با موارد مطرح شده در کلاس معماری نرم‌افزار بیان شود تا با کمک آن دانش معماری مهندسان کامپیوتر افزایش یابد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 06 Dec 2021 22:52:04 +0330</pubDate>
            </item>
                    <item>
                <title>تفسیری بر   MVVM</title>
                <link>https://virgool.io/@alireza97hi/%D8%AA%D9%81%D8%B3%DB%8C%D8%B1%DB%8C-%D8%A8%D8%B1-mvvm-xtjrhkf4vxcj</link>
                <description> در مطلب زیر به شرح معماری    MVVM و تمایز آن با مدل‌های دیگر می‌پردازیم.بگذارید دید خودمان از برنامه‌ها و application ها بیان کنیم. هر برنامه یک لایه را دارا است که اطلاعات و داده‌ها را در خود ذخیره می‌کند. بگذارید نام این لایه را model  بگذاریم. در این لایه تنها داده‌های خام نگهداری می‌شود.همچنین لایه دیگری از نرم‌افزار هست که داده‌ها به کاربران نمایش داده می‌شود. مانند فرم‌ها، متن‌ها و ... . تمامی این قسمت را نیز در لایه‌ای با اسم  view فرض می‌کنیم.پس تاکنون دو لایه view و model را دارا هستیم و در اپلیکیشنی با کمترین نیاز می‌توان داده‌های model را در view  نمایش دهیم. اما اپلیکیشن‌ها معمولا پیچیده‌تر از این سادگی قرار دارند و لازم دارند تا منطق یا logic ای را داشته باشند. برای مثال فرض کنید میخواهیم بگوییم هر وقت داده‌ای با نام  age از ۲۵ بیشتر بود باید قسمتی از view به صورت زرد نمایش داده شود. یا اگر داده‌ای با نام is_activated مقدار  false  داشت اطلاعات به خصوصی را نمایش دهیم. با توجه به این نیاز‌ها لازم می‌شود تا به صورتی این منطق را پیاده‌سازی کنیم.پترن  MVVM  جهت حل همین مسئله معرفی شده است.براساس این مدل یک لایه جدیدتر با نام   ViewModel  معرفی می‌شود که منطق برنامه در آن قرار می‌گیرد. به تصویر زیر دقت کنید.مدل MVVMهمانطور که در عکس بالا مشاهده می‌کنید قسمت  ViewModel بین دو قسمت Model و View  قرار گرفته است و منطق بین این دو قسمت را در این منطقه تعیین می‌کنیم.ارتباطی که بین Model  و ViewModel  هست نشان دهنده Manipulating Data است با این مفهوم که داده‌ها را تغییر دهیم تا خواندن و تفسیر آن‌ها راحت‌تر شود. این هماند ارتباطی است که با کمک آن می‌گوییم اگر داده‌ها شرایط خاصی را داشتند به چه صورتی در بیایند.همچنین ارتباط بین View و ViewModel نیز با نام Two-Way Data Binding شناخته می‌شود. در این ارتباط هم منطق‌های بیان شده در قسمت  ViewModel در قسمت View به کاربران نمایش داده می‌شود و هم کاربران می‌توانند منطق را با کمک تغییر در قسمت View  عوض کنند تا در ViewModel اثر بگذارد و اطلاعات نمایش داده شده متفاوت باشد. به همین دلیل است که two way در اسم این رابطه قرار داده شده است.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 06 Dec 2021 22:50:48 +0330</pubDate>
            </item>
                    <item>
                <title>  تفسیری بر  Event Sourcing</title>
                <link>https://virgool.io/@alireza97hi/%D8%AA%D9%81%D8%B3%DB%8C%D8%B1%DB%8C-%D8%A8%D8%B1-event-sourcing-jewlazpqfcij</link>
                <description> در این مطلب قرار است تا نکاتی در رابطه با موارد مطرح شده در کلاس معماری نرم‌افزار بیان شود تا با کمک آن دانش معماری مهندسان کامپیوتر افزایش یابد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 06 Dec 2021 22:49:58 +0330</pubDate>
            </item>
                    <item>
                <title>چهار عدد C جهت نمایش بی‌نهایت! - توضیح مدل C4</title>
                <link>https://virgool.io/@alireza97hi/%DA%86%D9%87%D8%A7%D8%B1-%D8%B9%D8%AF%D8%AF-c-%D8%AC%D9%87%D8%AA-%D9%86%D9%85%D8%A7%DB%8C%D8%B4-%D8%A8%DB%8C-%D9%86%D9%87%D8%A7%DB%8C%D8%AA-%D8%AA%D9%88%D8%B6%DB%8C%D8%AD-%D9%85%D8%AF%D9%84-c4-jb0a0heprfc5</link>
                <description>احتمالا اگر دستی بر مهندسی نرم‌افزار داشته باشید با نمودارهای متنوعی جهت نمایش سیستم آشنایی دارید. یکی از نمودار‌هایی که جهت توصیف یک سیستم استفاده می‌شود نمودار UML است. تعریف آن را می‌توان به صورت زیر ارائه داد:زبان مدل سازی یکپارچه (UML) یک زبان همه منظوره، توسعه ای و مدل سازی در زمینه مهندسی نرم افزار است.نمونه‌ای از UMLاین نمودار با کمک زبان خاصی که دارد جزئیات سیستم را نمایش می‌دهد. با کمک این جزئیات می‌توان اهداف و توانایی‌های سیستم را به افرادی که با جزئیات پروژه آشنا نیستند به اشتراک گذاشت.اما مشکلی که این نوع از نمایش دارد کم نیست! این زبان جزئیات زیادی را در سطح کامپوننت ارائه می‌دهد و همچنین دید کلی‌ای را شامل نمی‌شود. همچنین زمان زیادی جهت بیان جزئیات آن صرف می‌شود و خیلی‌ها با آن ارتباط برقرار نمی‌کنند. همچنین تنها یک سطح از معماری را نمایش می‌دهد. براساس تحقیقی که سایمون براون به عنوان یکی از بررسی کنندگان معماری نرم‌افزار انجام داده از هر ۱۰ نفر ۱ نفر از UML جهت توصیف سیستم استفاده می‌کند. با توجه به این مسائل شاید  استفاده از مدل دیگری که بتواند دید بهتری بدهد و نمایش آن هم از جهت خواندن و هم از جهت طراحی راحت‌تر باشد بهینه‌تر باشد. مدلی که در این مطلب آن را بررسی خواهیم کرد مدل 4C است.همانطور که از اسم پیداست این مدل از C4 به صورت زیر تشکیل شده است:Context, Containers, Components, Codeاین مدل سعی دارد تا با نمایش معماری در ۴ سطح مختلف برای مخاطبین مختلف و از دید بالا و کلی شروع کند و سپس به جزئیات بپردازد. این معماری یک معماری abstraction-first است با این مفهوم که نشان دهد معماری و مهندسان نرم‌افزار چه ایده‌ای و دیدی در رابطه با سیستم دارند. مجموعه‌ای از این انتزاعات فهم این مدل را آسان‌تر می‌کند.بگذارید تا با نمایش مثالی از این مدل یه دید کلی نسبت به آن داشته باشیم:نمایش مثالی از مدل C4همانطور که در تصویر بالا مشاهده می‌کنید در نمودار اول دید کلی سیستم و ارتباط سیستم با سایر سیستم‌ها و کاربرانش نمایش داده شده و سپس در هر مرحله به جزئیات آن وارد می‌شود.در ابتدا باید با چند مفهوم برای تعریف بقیه موارد پیش برویم.مفاهیم اولیه:افراد ( People ):یک شخص نماینده یکی از کاربران انسانی سیستم نرم افزاری شما است.سیستم نرم‌افزار ( Software System ):یک سیستم نرم‌افزاری بالاترین سطح انتزاع است و چیزی را توصیف می‌کند که ارزشی را به کاربران خود ( انسان یا غیرانسان) ، ارائه می‌کند. این شامل سیستم نرم افزاری است که شما مدل سازی می کنید و سایر سیستم های نرم افزاری که سیستم نرم افزاری شما به آنها وابسته است (یا برعکس). در بسیاری از موارد، یک سیستم نرم افزاری متعلق به یک تیم توسعه نرم افزار است.دیاگرام اصلی C4:این دیاگرام، نمودار اصلی برای نمایش C4 است که شامل نمودار‌های زیر است:System Context diagram:در این نمودار نمایشی کلی از سیستم و ارتباطی که با بقیه قسمت‌ها دارد نمایش می‌دهیم. همچنین افراد ( People ) ای که با این سیستم در ارتباط هستند نمایش داده می‌شوند. هدف این دیاگرام نمایش کلی سیستم بدون نمایش جزئیات آن است تا بتوان با اشاره به آن هدف کلی سیستم را دریافت. در این قسمت تکنولوژی‌ها معرفی نمی‌شوند و در نمودارهای جزئی به آن اشاره می‌شود.Container diagram:در این نمودار پس از اینکه هدف سیستم و ارتباط آن با سایر سیستم‌ها مشخص شد به نمایش مشخصات container می‌پردازیم که تعریف آن به این صورت است که مانند یک single-page application و یا server-side web application به صورت مجزا قابل deploy است.مثال‌هایی از container می‌تواند موارد زیر باشد:desktop applicationsingle-page applicationmobile applicationdatabase schemafile systemاین نمودار سطح بالایی از معماری را نمایش می‌دهد.در این سطح می‌توان به بیان تکنولوژی‌های مورد استفاده پرداخت.Component diagram:در این مرحله از نمودار می‌توان هر container را ریزتر شد و به وظایف کامپوننت هر container پرداخت. هر container از یک یا چندین component تشکیل می‌شود.Code diagram:در این نمودار به بیان جزئیات کد هر کامپوننت می‌توان اشاره کرد.در کنار این موارد می‌توان نمودارهای فرعی نیز برای C4 تعریف کرد تا اطلاعات بیشتری را به نمایش قرار داد.جهت مطالعه در رابطه با این موارد می‌توان به لینک‌های زیر مراجعه کرد:https://c4model.com/https://www.youtube.com/watch?v=x2-rSnhpw0ghttps://www.youtube.com/watch?v=Ym9nhVZs89oاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.#معماری_نرم_افزار_بهشتی</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Wed, 17 Nov 2021 18:16:05 +0330</pubDate>
            </item>
                    <item>
                <title>چطور باگ‌هامون رو همه‌جا گسترش دادیم | YektaUI از بدعت تا توسعه</title>
                <link>https://virgool.io/yektanet/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7%DA%AF%D9%87%D8%A7%D9%85%D9%88%D9%86-%D8%B1%D9%88-%D9%87%D9%85%D9%87%D8%AC%D8%A7-%DA%AF%D8%B3%D8%AA%D8%B1%D8%B4-%D8%AF%D8%A7%D8%AF%DB%8C%D9%85-yektaui-%D8%A7%D8%B2-%D8%A8%D8%AF%D8%B9%D8%AA-%D8%AA%D8%A7-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-y95lt21mju4e</link>
                <description>احتمالا اگه اندکی با یکتانت آشنا باشین میدونید که دولوپر‌های سمت فرانت‌اند بیشتر وقتشون رو به توسعه پنل‌ها می پردازن. سال پیش یکی از همین روزا بود که فهمیدیم چقدر کد مشابه داریم که تو پنل‌های مختلف استفاده میکنیم. نمونه‌اش کامپوننت پشتیبانی(Ticketing)‌مون بود که برای هر پنل از یک کد مشابه استفاده می‌شد اما هر باگ فیکس یا افزودن فیچری بهش مستلزم این بود که به تک‌تک پنل‌ها سر زده بشه یا اطلاع‌رسانی کنیم که تو هر پنل این قسمت‌ها رو آپدیت کنید! خب این روش درست نبود. شاید دلمون میخواست هر فیچری که میزدیم رو یکبار بزنیم و بقیه جاها هم آپدیت بشن. یا اصلا دلمون می‌خواست و شوق این رو داشتیم که باگ‌هامون رو زودتر تو همه پلتفرم‌ها توسعه دهیم. چرا باید این فرآیند دیپلوی کردن یه باگ انقدر طول بکشه؟!کد تکراری، منشأ همه شرارت‌هایک اصل در معماری نرم‌افزاری هست به اسم Don&#x27;t Repeat Yourself) DRY) . با این مفهوم که کد تکراری منشاء همه‌ی شرارت‌هاست. این شد که جرقه یک کیت فرانت شکل گرفت تا از ایجاد چنین کد‌هایی جلوگیری کنه و به افزایش کیفیت کد‌ها هم منجر بشه. ما اسمش رو گذاشتیم YektaUI. سعی میکنم در متن زیر به دلایل ایجاد این کیت فرانت که توسعه‌اش تا الان توسط تمام بچه‌های فرانت‌اند یکتانت انجام شده اشاره کنم، درمورد خصوصیاتش توضیح بدم و نحوه‌ی توسعه‌‌اش رو شرح بدم.Don&#039;t Repeat Yourselfداستان یکتانت و پلتفرم‌هامجموعه یکتانت تا حدود یک سال قبل، شامل پنل‌های یکتانت و نجوا می‌شد. اما یکتانت فقط به همین‌ موارد ختم نشد. از سال پیش تاکنون پنل پلتفرم‌های تریبون و جریان هم توسط یکتانت لانچ شد.تعداد پنل‌ها تا این لحظه تقریبا به هفت پنل میرسه. تمامی این پلتفرم‌ها نیاز به زیرساختی داشتند تا سرویس‌هایی مثل احراز هویت(Authentication)، پشتیبانی(تیکتینگ) و موارد مالی رو پوشش بدن. از این جهت، زیرساخت موارد ذکر شده، در یک سال اخیر ایجاد شد و تمامی پلتفرم‌ها تونستند از این زیرساخت‌ها استفاده کنند.استک و کتابخانه‌های مورد استفاده در تمامی پنل‌ها در حال حاضر موارد زیر است:SCSSBootstrap 4BootstrapVueNuxtVueاما آیا لازم بود که هر پلتفرم، فارغ از پلتفرم‌های دیگر نیازمندی‌های خودش رو پیاده‌سازی کنه؟ این مسئله باعث میشه تا وقت زیادی از توسعه‌دهندگان، صرف کدهایی بشه که قبلا توسط اعضای دیگه یکتانت زده شده. ما دنبال توسعه سریعتر و باکیفیت‌تر بودیم. این جرقه‌ی شروع کیت بود. اما چون شروع این کار ممکن بود وقت زیادی از افراد رو بگیره باید با دلایل محکم‌تری به سمتش می رفتیم.ادله کافی جهت ایجاد و توسعهاحتمالا بهترین جواب‌ها، از بهترین سوالات شروع به شکل‌گیری می‌کنند. سوال‌های ما چی بود که نتیجه‌اش شد ایجاد یک کیت فرانت اند؟ میتونم بگم این‌ها بودند:کامپوننت‌های مشترک را چطور استفاده کنیم/توسعه بدهیم؟توابع و utilityهای پراستفاده، از کجا قابل دسترسی باشند؟استایل کدهامون رو چگونه و بر چه اساس یکی کنیم؟ آیا امکان دارد همه این استایل را رعایت کنند؟چطور از دانش افراد مختلف به طور عملی استفاده کنیم؟چطور میتونیم از طریق توسعه با کمک یکدیگر، کیفیت توسعه را افزایش دهیم؟با توجه به گسترش تیم‌ها و زیاد شدن محصولات، ابزارهای داخلی را به چه صورت منتشر کنیم؟احتمالا جواب این سوالات رو میتوانستیم با توسعه YektaUI پیدا کنیم. باتوجه به موارد ذکر شده و با استناد به این مفهوم که زودتر کد رو بزنیم تا اینکه بیشتر از حد راجع به مسئله فکر کنیم، توسعه رو شروع کردیم. این توسعه چه چیزهایی رو شامل می‌شد؟۱.کامپوننت‌هادریا دریا کامپوننت. همه‌اش برای خودمون. در همه‌ی پنل‌ها به اندازه کافی کامپوننت‌های مشترک داشتیم که هرکدوم فیچر‌های خاص خودشون رو داشتند و لازم بود تا این موارد در کنار یکدیگر قرار بگیرند و پازل بزرگ ما رو شکل بدن.دریا دریا کامپوننت به روایت تصویرمهمترین کامپوننت‌ها را میتونیم به کامپوننت‌های فرم‌(form) تخصیص بدیم. صحبت در مورد توسعه این کامپوننت‌ها، خودش چندین سلسله مطلب رو میطلبه، اما از جهت بیان کلی نیازمندی‌هامون، میتونم موارد زیر رو اشاره کنم:در فرم‌ها labelها به چه صورت نمایش داده شوندخطای هر input و هر form را به چه صورت نمایش دهیمصحت و validation محتوای inputها را چطور اعتبار‌سنجی کنیمچهارچوب و layout فرم به چه نحوی باشد تا کاربر با آن ارتباط بیشتری برقرار کندتعدادی از موارد بالا توسط متخصص UX انجام میشه اما باتوجه به اینکه این پوزیشن در حال حاضر در یکتانت تعریف نشده، قسمتی از فعالیت دولوپر فرانت‌اند و مدیر محصول به تعیین چنین تصمیماتی تخصیص پیدا میکنه.سوالات بالا، سوالات خیلی خوبی بودند. اما جواب‌ها مدت زمانی حدود دو ماه را از ما گرفت تا بتونیم تعداد زیادی مقاله بخونیم و کتابخونه‌های مختلف رو بررسی کنیم تا پاسخ کاملی براش پیدا کنیم; ولی نتیجه لذتبخش بود.سری بعدی کامپوننت‌های پر استفاده برای ما، جدول‌ها(table) بودند. چندین نوع جدول مختلف در پروژه‌ها داشتیم با چندین فیچر مختص هرکدام(هنوز هم داریم. این قسمت هنوز درست نشده :دی) که هر فردی که از یه پروژه به پروژه دیگری منتقل می‌شد نیاز داشت تا با جدول‌های پروژه جدید آشنا بشه ( همونطور که گفتم هنوزم باید یاد بگیره :) )‌. تعداد زیادی کامپوننت تیکتینگ داشتیم که مشتری‌ها از طریق این قسمت‌ها میتونستند سوالاتشان رو مطرح کنند و از ما پاسخ دریافت کنند و این کامپوننت‌ها نیز بسته به پروژه، پیاده‌سازی متفاوتی داشتند ( این یکی مورد درست شده!). یک جلسه کامل از جلسات فرانت چپتر(در مورد فرانت چپتر‌مون از اینجا بخونید) رو به این اختصاص دادیم که بتونیم کامپوننت‌های مشترک رو شناسایی کنیم و نسخه کامل رو به YektaUI اضافه کنیم.از طرفی استایل‌ها و ظاهر تمامی پنل‌ها منحصر به فرد ه. پس یکی از چالش‌های تیم فرانت این بود که کامپوننت‌هایی رو ایجاد کنن که قابلیت کاستوم شدن رو داشته باشند و بتونند با تمامی پنل‌ها هماهنگ باشند. تم بوت‌استرپ (Bootstrap Theming) و استایل‌های scss آن، از جهت به کارگیری تنظیمات مختلف css ای در هر پنل، راه‌حل ما جهت شخصی‌سازی هرکدوم از پنل‌ها بود. رنگ‌بندی‌ها، سایزبندی‌ها و موارد مشابه را از طریق override کردن تم‌های اصلی به صورت پویا در هر پنل تغییر دادیم.۲.توابع مشترک و utilityهاتبدیل اعداد به حروف، نمایش اعدادی که نشان دهنده مبلغ هستند به صورت ویرگول‌گذاری شده. ارسال ریکوئست‌ها با درنظرگرفتن احزار هویت میانی مانند JWT و … مواردی بود که تقریبا در تمامی پنل‌ها از اون‌ها استفاده می‌شد. سعی کردیم این موارد رو نیز تا حد امکان به YektaUI اضافه کنیم.با این روند، به جای صرف وقت جهت پیاده‌سازی‌های متعدد، باعث شد تا وقت مورد نظر رو جهت بهینه کردن کارایی استفاده کنیم و یا برحسب نیاز تنها به افزودن فیچرهایی که موجود نیست بپردازیم.utility functions - حدف کاما و یا کاما‌گذاری مقادیر عددی۳.کد استایلEvery major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. -Google Style Guidesبا توجه به پویایی سازمان، و اینکه برنامه‌نویسای یکتانت پس از حل چالش‌های مربوطه در قسمتی که در اون فعالیت دارند ممکن است برحسب نیاز شرکت یا تمایل خودشون، به توسعه پروژه‌های دیگه شرکت که در حال توسعه است یا قراره توسعه‌اش شروع بشه مشغول بشن، لازم داشتیم تا یک استایل کد زدن یکسان و مناسب داشته باشیم و همچنین به این کد استایل وفادار بمونیم تا هنگام این جابه‌جایی، با مشکل و فوت وقت مواجه نشویم. در واقع عدم وجود این استایل موارد زیر رو به دنبال داشت:پایین بودن سرعت خوانایی کدعدم رعایت ثبات (consistency) استایل در بین تیم‌های مختلفمشخص نبودن سطح خطای کد (error, warning یا خطایی که disabled شده است)ابزارهایی که کمکمان می‌کردند تا به تمامی موارد بالا برسیم eslint و prettier بودند.ابزار eslint جهت مدیریت قواعد در javascript استفاده میشه. نهادها و سازمان‌های مختلفی قواعد درنظرگرفته خود را جهت استفاده توسط eslint منتشر کرده اند که میتوانید این موارد را دراین لینک بیابید.از جمله مزیت‌های eslint ایجاد قواعد و قوانین شخصی‌سازی شده یا custom است. در حین توسعه پروژه‌ها در سازمان نیاز داشتیم تا تعدادی قواعد شخصی‌سازی شده رو به این صورت به قوانین دیگه اضافه کنیم. نامگذاری کامپوننت‌ها و متغیرهای boolean از جمله مواردی است که نیاز به رعایت داشتند. این قواعد از ابتدای توسعه پروژه‌ها وجود نداشتند و با توجه به احساس نیاز و مطرح شدنش در یکی از جلسات چپتر فرانت تصمیم گرفتیم هرکدوم رو به قواعد مورد نیازمون اضافه کنیم و با مستندسازی این موارد در پلتفرم slite اون رو در بین تیم‌ها به اشتراک بذاریم.استفاده از استایل یکسان، باعث شد تا بتونیم با صرف زمان کمتری جهت درک کد،‌ به فهم نوآوری‌های استفاده شده در کد‌ها بپردازیم و کیفیت به عنوان مسئله اصلی در کدها بجای دغدغه نحوه کد زدن در اولویت قرار بگیره.مرج ریکوئست‌ها و روند تایید فیچر‌هااین پروژه در حال حاضر بر روی بستر داخلی یکتانت قرار داره و به صورت open source درنیومده. روند ایجاد تغییرات در YektaUI به صورت زیر ه:ایجاد branch و توسعه feature یا برطرف کردن bug در branch مربوطهایجاد درخواست merge requestانجام review کد توسط دو نفر از افراد دیگر فرانت و بیان بازخوردرفع نواقص و اعمال بازخوردهامرج با کد اصلی و ایجاد ورژن جدیدمرحله‌ای که در توسعه فنی شخصی افراد تاثیر جدی‌ای داشته و کیفیت کد‌ها را به مراتب چندین مرحله بهتر کرد، مرحله review کد‌ها بود. در ابتدای این امر، این کار توسط تنها یکی از اعضای فنی(علی محمدی) صورت می‌‌گرفت. اما با توجه به توسعه گسترده این کیت، تصمیم بر این شد تا reviewها به افراد مختلف واگذار شود که تاثیر به سزایی در تعامل افراد با یکدیگر با این کار صورت گرفت.دردم از یار است و درمان نیز هماحتمالا در هر سودی ضرری هم نهفته است. کلیت مزیت‌ها و مضرت(!)هایی که در توسعه این پروژه دخیل بودند رو میتونیم به موارد زیر خلاصه کنیم:مزیت‌هااشتراک‌گذاری کدهای مشترکتعامل فنی بیشتر کارمندان با یکدیگرافزایش کیفیت و کارایی خروجیتسریع در تغییرات مشترک بین پلتفرم‌های سازمانمضرت‌هانیاز به سپری شدن سلسله مراتبی از توسعه، جهت ایجاد و تایید تغییراتنیازمند صرف زمان جهت هماهنگی و ایجاد قواعد و مدیریت پروژهنیازمند صرف زمان جهت انتقال تمامی کامپوننت‌های پنل‌هاسرعت کم در تغییرات به دلیل عدم وجود تست‌ها برای کامپوننت‌هادر رابطه با سپری شدن سلسله مراتب مورد نیاز جهت ایجاد تغییر در کدها، با وجود اینکه ممکن است از سرعت توسعه در وهله اول کم بکنه، اما همین سلسله مراتب منجر به افزایش کیفیت کدها میشه. خالی از لطف نیست که بیان کنیم با گذشت زمان، سرعت انجام شدن این سلسله مراتب نیز افزایش یافته و انتظار می‌رود با صرف زمان‌های بیشتری در گسترش پروژه، زمان سپری شده توسط این سلسله مراتب نیز کاهش پیدا کنه.با توجه به اینکه یکتانت در حال رشد ه و برنامه‌های بیشتری جهت توسعه قسمت‌های مختلف پیش رو داره، زمانی که جهت هماهنگی و ایجاد قواعد این پروژه صرف میشه تنها مختص مراحل اولیه است و با تخصیص این وقت اولیه، در ادامه سهولت بیشتری رو ایجاد می‌کنه.کیت YektaUI اولین ابزاری هست که دولوپرها برای راحتی کار خودشان در یکتانت توسعه دادن و همین مورد development experience را برای دولوپرهای فرانت‌اند بالاتر برده و بعد از اون می‌تونند با دغدغه کمتری بر روی محصول یا مساله‌ی خاص خودشون وقت بذارند.با توجه  به اهمیتی که در توسعه این پروژه ایجاد شد، قرار بر این شد تا افراد حاضر در یکتانت با عنوان front-end بتوانند ۲۰ درصد از زمان کاری خود را جهت توسعه این کار اختصاص بدن.در حال حاضر YektaUI در چه وضعیتی قرار دارد؟تا این لحظه که این مطلب در حال نوشته شدن است (اواسط مرداد ۹۹) YektaUI در حال توسعه داخلی در شرکت یکتانت است و تقریبا در تمامی پنل‌ها استفاده می‌شه.رهی به سوی مقصد عالی - آینده YektaUIمسیری که در جهت توسعه این کیت شروع شده احتمالا مسیر طولانی و جذابی خواهد بود. هدف نهایی ما توسعه ابزارهایی با سطح کیفیت عالی برای جامعه‌ی Vue فارسی است. اما برنامه‌ای که در برنامه‌ریزی کوتاه مدت برای توسعه این قسمت خواهیم داشت شامل موارد زیر ه:اضافه کردن استوری بوک(Storybook) و مستندسازی کامپوننت‌ها توسط آناضافه کردن تست توسط فریم ورک Jestاپن‌سورس کردن قسمت‌هایی که به تنهایی اختصاص به یکتانت نداشته باشندیکتانت - پیش به سوی بینهایت و فراتر از آناحتمالا باتوجه به مقاله با مقداری از چالش‌های سمت فرانت آشنا شده باشید اما تمرکز اصلی ما در تمامی پوزیشن‌ها، تعریف مسئله‌هایی است که در هنگام انجام تسک‌ها باهاشون برخورد میکنیم و سعی‌میکنیم به طور عمومی اون‌ها رو حل کنیم. انجام موارد با پیش‌فرض گفته شده، منجر به پیشرفت فرد و سازمان باهمدیگه میشه و به نظر خودم جذابیت رو برای هر دو طرف خواهد داشت. اگر علاقه‌مند بودی که در این حل مسئله‌ها با ما هم مسیر بشید میتونید از طریق موقعیت‌های شغلی یکتانت بیشتر از وضعیت‌های شغلی‌مون آگاه بشید.</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Mon, 17 Aug 2020 01:26:55 +0430</pubDate>
            </item>
                    <item>
                <title>همنشینی با دیو سپید‌ پای در بند: دشت لار</title>
                <link>https://virgool.io/@alireza97hi/%D9%87%D9%85%D9%86%D8%B4%DB%8C%D9%86%DB%8C-%D8%A8%D8%A7-%D8%AF%DB%8C%D9%88-%D8%B3%D9%BE%DB%8C%D8%AF-%D9%BE%D8%A7%DB%8C-%D8%AF%D8%B1-%D8%A8%D9%86%D8%AF-%D8%AF%D8%B4%D8%AA-%D9%84%D8%A7%D8%B1-n0hnnmvhbc09</link>
                <description>اینکه بتونی با فاصله کمتر از دو ساعت از تهران به یه دشت برسی که بتونی دماوند رو در یک سمتت و گلزاری از شقایق‌های وحشی رو تو سمت دیگه‌ای داشته باشی، اونم تو دوران قرنطینه‌ای که میشه به کوه و دشت پناه آورد میتونست تفریح خوبی برای ما باشه. با دوستامون سفر نیم‌روزه‌ای داشتیم به دشت لار شامل توصیفات بالا که سعی میکنم از هرآنچه که شاید به درد شما هم بخوره و ما تجربه کردیم بگم.دشت شقایقدشت لار ناحیه‌ای از مازندران و تهران ه که اگه تهرانی باشید میتونید از سمت جاده هراز بهش دسترسی داشته باشید.بعد از اینکه از جاده هراز خارج میشید میتونید تیکه‌هایی از دشت‌های گل شقایق‌های وحشی رو ببینید. اما لازم هم نیست دقیقا در اولین دشت توقف کنید. جلوتر که در ادامه هم خواهم گفت فضاهای سرسبزی هست که شامل سد لار میشه و میتونه جذابیت بیشتری رو داشته باشه.شروع سفر ما از ۶ صبح بود. میدونستیم که از ظهر به بعد هوای آفتابی توی دشت ممکنه اذیتمون بکنه و برای همین این ساعت پاشدیم و حدود ۶ و نیم حرکت کردیم به سمت هدفمون در دشت لار. لوکیشن زیر جایی بود که ما ماشینمون رو پارک کردیم.منطقه شروع جاده خاکی دشت لارحدود ساعت ۸ و ربع به لوکیشن رسیدیم.از اینجا به بعد جاده از آسفالت خارج می‌شد و بقیه جاده رو باید به صورت خاکی میرفتید. که هم میشد با ماشین رفت و هم پیاده. نگهبان‌های منطقه نکته‌های زیر رو بهمون گفتن:نمیتونید ماهیگیری کنیداز قسمت منطقه خاکی به بعد نمیتونید با ماشین off road برید (گرچه که اوایل صبح که ما رفتیم به چند مورد گیر دادند اما از ساعت ۹ صبح خیلی ماشین‌های off road زیادی رد می‌شدند و زمانی برگشت هم دیدیم که به همشون اجازه ورود به منطقه خاکی رو میدادند)شب نمیتونید بمونیددرنهایت وسایلمون رو برداشتیم و از جاده خاکی حدود نیم ساعت راه رفتیم تا بتونیم یه جایی رو پیدا کنیم که هم منظره قله دماوند رو داشته باشیم و هم بتونیم سد لار رو ببینیم. فضا برای زیرانداز انداختن و چندین جای مناسب برای درست کردن آتیش بود. هدف ما گرم کردن کنسرو‌های لوبیایی بود که آورده بودیم و با توجه به بادی هم که در جریان بود روشن کردن آتیش و گرم کردنشون برامون دشواری زیادی نداشت. با توجه به دشت بودن منطقه ممکن‌ بود موجودات و حشراتی که بتونند نیش بزنند و آسیب وارد کنند وجود داشته باشند. گرچه ما خودمون این موارد رو ندیدیم و اکثرا جیرجیرک‌ها بودند که اطرافمون بالا پایین میرفتند اما جهت اطمینان از ناحیه پا یکم خودمون رو عایق کردیم تا مشکلی پیش نیاد.دماوندهمچنین همونطور که اول هم گفتم آفتاب در بعضی مواقع ممکنه به صورت مستقیم بتابه و برای همین لباس آستین بلند یا کرم ضدآفتاب برای همچنین مواقعی ممکنه لازم بشه.با توجه به سبزه‌زار‌ها و گل‌های موجود در منطقه به ما گفته بودند که بهترین زمان گشت و گذار اواسط خرداد تا اواسط شهریوره. براساس توییت‌هایی که از افراد مختلف دیدم پارسال حتی در اواخر اردیبهشت هم زمان مناسبی بوده اما امسال دقیقا آخر‌های خرداد گل‌ها غنچه کرده بودند و دقیقا یک هفته قبل از این غنچه منطقه بارش برف و باران رو داشته. خلاصه که قبل از اینکه بخواید راهی شید از راه‌هایی که بلدید ببینید افرادی که یکی دو هفته پیش رفتند شرایط رو مناسب میدیدند یا خیر.در نهایت حدود ۱۱ برگشتیم و دقیقا زمانی بود که آفتاب شدیدتر میشد. اما تازه در این ساعت بود که شاهد بودیم افراد بیشتری دارند وارد دشت لار میشن و به سمت سد میرند. اگر چادر یا سایه‌بونی برای این مواقع که خورشید به صورت خیلی مستقیم میتابه دارید که مشکلی نیست. اما اگه اینطوری نیست توصیه میکنم همون صبح زود راه بیوفتید که اذیت نشید و بتونید قبل ظهر برگردید.سد لارچندتا نکته هم در رابطه با این گشت‌مون در این دشت بگم:تقریبا از قسمت شروع جاده خاکی به بعد، با وجود چندین منطقه مسکونی، هیچ سطح آشغالی نبود. پس حتما با خودتون پلاستیک زباله همراه داشته باشیدیک ساختمون سرویس بهداشتی اوایل جاده خاکی وجود داشت اما قابل استفاده نبود. و تقریبا با درنظر گرفتن شرایط و اینکه قبل از جاده خاکی هم امکانات خاصی نبود عملا درنظربگیرید که سرویسی در کار نیست.از حدود ۱۰ دقیقه قبل از جاده خاکی آنتن نخواهید داشتزمانی که ما به این گردش رفتیم هفته آخر خرداد بود و شرایط برای مواقع دیگه ممکنه فرق کنه. مثلا با توجه به شرایط فصل تولید مثل یا موارد دیگه ممکنه که اجازه ورود به ناحیه خاکی رو ندند. اما اونطور که متوجه شدیم در همون مدت نیمه خرداد تا نیمه شهریور امکان گشت هست.</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Fri, 19 Jun 2020 14:00:54 +0430</pubDate>
            </item>
                    <item>
                <title>قشم، جزیره خاک‌های رنگی</title>
                <link>https://virgool.io/@alireza97hi/%D9%82%D8%B4%D9%85-%D8%AC%D8%B2%DB%8C%D8%B1%D9%87-%D8%AE%D8%A7%DA%A9%D9%87%D8%A7%DB%8C-%D8%B1%D9%86%DA%AF%DB%8C-rtzxwocrmj5p</link>
                <description>اولش فکر نمیکردم قشم به این بزرگی‌ای که دیدم باشه. اگه یه نیم نگاهی فقط از نقشه هم داشته باشیم به عظمتش نسبت به بقیه جزیره‌هامون پی‌میبریم. سفرمون از سمت بندرعباس به قشم بود که با کشتی‌های تندرو میشه با فاصله یک ساعتی به قشم رسید. محل اقامت ما از خود شهر قشم خیلی دور بود و هدفمون برای برفتن به اونجا نزدیک‌های نیمه شب بود. پس لازم بود تا وسایلمون رو به امانت جایی قرار بدیم. خود اسکله محل تحویلی نداشت . کلی پرس و جو کردیم که درنهایت وقتی از در ورودی اسکله خارج بشید روبروش چندین تعاونی دیده میشه که میتونید با یکیش صحبت کنید و در حدود ۴ ساعت و با قیمت پنج تومان کیف‌هاتون رو پیششون به امانت بذارید. درواقع این کاری بود که ما کردیم.از جمله ویژگی‌های شهر قشم حداقل تو این دوره‌ای که ما بودیم(اواسط زمستون) این بود که خیلی از رستوران‌ها و فست‌فودی‌ها تا ساعت ۵ یا ۶ بسته‌اند. با کلی گشت‌وگذار تو خیابان رسالت کلی رستوران یافتیم که در نهایت رستوران‌های سی‌رول و لارستان باز بودن و به نظر خوب می‌اومدند. ما خودمون لارستان رو انتخاب کردیم  و یه همبرگر گرفتیم که کلی با نوع نونی که داشت حال کردیم. قیمت‌هاش هم ارزون بود ولی خب شاید برای یک آدمی که اشتهای خوبی داره یدونه ساندویچ کافی نباشه. رستوران سی‌رول هم ما خودمون نرفتیم اما دقیقا همسفر‌های دیگه‌ای تو شهر همراهمون بودن که همزمان با ما اونجا رفتن و گفتن غذاهای دریایی خوب و ارزونی داره.فست‌فود لارستان - قشم پس از ناهار به سیتی‌سنتر رفتیم که در واقع شامل دو تا مجتمع سیتی‌سنتر ۱ و سیتی‌سنتر ۲ است و هردوشون در دو سمت یک میدان قراردارند. مغازه‌های این مجتمع‌ها هم از اقبال خوب ما اطراف ظهر بسته بودند و ما با بازدید اندکی از مجتمع و خوردن یک عصرونه کارمون رو تو روز اول تموم کردیم. البته در فرصتی دیگه باز هم به این مجتمع سر زدیم. از ویژگی‌هاش میشه گفت که دقیقا مثل بقیه موارد مشابه شامل سینما و شهربازی بود و داخل فودکورت هم رستوران‌های زیادی داشت که تمامشون هم سرظهر باز بودند. داخل فودکورت یک تلویزون هم بود که با کمک اون تونستیم بازی ایران رو ببینیم. از امکانات شهربازی هم که شامل بیلیارد و فوتبال‌دستی بود استفاده کردیم. البته بولینگ هم بود که ما به خاطر کمبود وقت نتونستیم بریم سراغش. چندتا دستگاه ps4 هم بود که یکم گرون بود اما اگه لازم باشه خلاصه که اونجا از اینا هم دارند. درنهایت باید به محل اقامت‌گاه میرفتیم و ماشین میگرفتیم. به دلیل اینکه هنوز سرویس‌های آنلاین حمل و نقل در قشم راه نیافتاده بودند مجبور بودیم کلی چونه سر ماشین‌ها بزنیم. اقامت‌گاه‌مون در نزدیکی فرودگاه شهر قشم به اسم اقامتگاه ساحلی فردیس قشم بود که یک اقامت‌گاه بوم‌گردی ه. فضای بیرونی واقعا حس یک فضای سنتی را تداعی کرده بود. داخل هر اتاق هم یک حموم و دستشویی فرنگی بود و برای همه افراد نیز یک دستشویی ایرانی به اشتراک در اطراف اقامت‌گاه قرار داشت. یک تاب معمولی و یک تاب درازکشیدنی هم لب ساحل داشتند که واقعا از تجربه‌های دیدنی‌ای بود که هنگام غروب استراحت روش واقعا توصیه میشه. تور و توپ والیبال هم داشتند که به مراتب به جذابیت‌های مکانمون اضافه می‌کرد. صبحونه هم همراهش داشت و کلی افراد خوش‌برخوردی بودند. در حال توسعه بودند و گفتند کلی امکانات دیگه هم اضافه خواهند کرد.اقامتگاه بوم گردی ساحلی فردیس قشم صبح روز دوم راهی جزیره هرمز شدیم که شاید بهترین قسمت از این سفر بود. معمولا دوتا قایق تندرو هستند که ساعت‌های ۷ و ۱۴ حرکت می‌کنند و لازمه یک ساعت قبلش اسکله باشین. بلیط‌ها رو میشه همون موقع از اسکله خرید و گفتند که معمولا تموم نمیشوند. برای برگشت‌هم ساعت ۱۵ تندرو‌ها آماده حرکت هستند. مسیر آبی تقریبا ۴۰ دقیقه طول میکشه. وقتی وارد جزیره میشید هم میتونید موتور خودتون کرایه کنید هم موتور ۳ چرخ بگیرید که تقریبا شاید تا ۵ یا ۶ نفر توش جا بشند. ما خودمون گزینه موتور سه چرخ رو انتخاب کردیم و با راننده‌اش که اسمش آقا مختار بود راهی شدیم. به ترتیب به سمت کوه‌های نمک و خاکی، غاری از نمک، دره رنگین‌کمان، دره مجسمه‌ها، ساحل خاک قرمز، غار رنگین‌کمان، جزیره لاک‌پشت‌ها و قلعه پرتغالی‌ها رفتیم. واقعا توصیه میشه این قسمت از سفر رو با حوصله برید و از دستش ندید. از مزیت‌هایی هم که موتور سه‌چرخ نسبت به تور‌هایی که میومدن داشت این بود که لازم نبود مثل تور‌ها منتظر خیلی از افراد تور بشیم و خودمون به عنوان یک مجمع چهارنفره سریع از همه‌جا بازدید می‌کردیم. یادتون باشه از جزیره خاک رنگی برندارید چون دارن به سمت نابودی و کمبود پیش میرن. در آخر هم آقا مختار بردمون یک سفره‌خانه که چندتا خانم خانه دار تو خونه خودشون راه انداخته بودند و میتونستیم هرنوع غذای دریایی رو با ۳۵ هزارتومان بخوریم. که ما میگو رو انتخاب کردیم.جزیره هرمز برای شام یکی از رستوران‌های نزدیک ساحل به اسم رستوران خاله رو انتخاب کردیم که اگر تهرانی باشید میتونیم بگیم شبیه ‌هفت‌چنار‌های تهران است. کلی غذای دریایی به صورت ساندویچی یا پرسی و با قیمت ارزون که معمولا ۲۰ دقیقه طول میکشه آماده بشه. صندلی‌ها و میز‌ها هم در فضای باز قرار دارند. فقط هم شب‌ها از ساعت ۷ به بعد باز هستند. از رستوران‌های دیگه که برای ناهار رفتیم رستوران دفاری بود که اندکی گرونه و خیلی از غذاهاش هم دونفره حساب میشه و میتونید به تعداد نفرات سفارش ندید. معمولا گوشت‌های بخارپز و متر رو پیشنهاد میدن و ما هم همین‌ها رو به همراه یک ظرف غذاهای دریایی شامل کوسه، صدف و میگو گرفتیم. شب‌ها هم گفته میشه که موسیقی زنده دارند و اگه امکانش باشه شب ساعت ۱۰ به بعد برید.روز آخر رو به گردش داخل خود شهر قشم پرداختیم. میتونین از سایت‌های آنلاین تور بگیرید ولی ما با یک ماشین صحبت کردیم و در نهایت با یک قیمت توافقی قرار شد که از صبح تا قبل از تاریکی هوا هرجا تونستیم بریم. جزیره هنگام و جنگل حرا رو موقعی که دریا طوفانی نیست میشه رفت و واقعا جزیره هنگام و دلفین‌هاش لذت خاصی داشت. معمولا با اولین قایق نرید چون اولین قایق معمولا باید بره و دنبال دلفین‌ها بگرده و وقتش تلف میشه. در نهایت یک قسمت از جزیره هنگام پیاده میشید و میتونید در مدت ۲۰ دقیقه سمبوسه بخورید یا از دستفروش‌های اطراف جزیره خرید کنید. یک قسمتی از جزیره به اسم گوران هست که توش دارن کلی کشتی درست می‌کنن و میتونین برید توشون و از صحنه‌های عرشه ساحل رو تماشا کنید. از جمله جاهای که شامل صخره‌های هیجان‌انگیز بود هم میشه به چوهکاه و دره‌ستارگان اشاره کرد. دره‌ستارگان رو زود برید چون تا قبل از تاریکی شب میبندنش.چاهکوه - جزیره قشم شب از ساعت ۸ به بعد تا طلوع آفتاب هوا تقریبا سرد بود و به یک لباس گرم نیاز داشتیم اما در مواقع دیگر یک لباس یا تی‌شرت ساده بسیار مناسب بود. خیلی از جاهای جزیره شنی‌ه پس اگه تونستید حتما دمپایی همراه داشته باشید.</description>
                <category>علیرضا حیدری | Alireza Heydari</category>
                <author>علیرضا حیدری | Alireza Heydari</author>
                <pubDate>Wed, 30 Jan 2019 15:33:38 +0330</pubDate>
            </item>
            </channel>
</rss>