https://virgool.io/feed/@KeivanDamirchi توسعه دهنده نرم افزار fa 2026-04-15 05:20:02 https://files.virgool.io/upload/users/3552/avatar/33Be2Z.jpeg?height=120&width=120 https://virgool.io/@KeivanDamirchi https://virgool.io/@KeivanDamirchi/%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%D8%B9%D9%85%D9%84%DA%A9%D8%B1%D8%AF-%D9%88-%D9%85%D9%82%DB%8C%D8%A7%D8%B3-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D9%87%D8%A7-nocfqz6ziuzd ساخت اپلیکیشن‌های سریع، مقیاس‌پذیر و قابل اعتماد بسیار مهم است. این راهنما راهکارها، ابزارها و تکنیک‌های کلیدی را برای بهبود عملکرد، مقیاس‌پذیری و پایداری بررسی می‌کند.بهترین روش‌ها، ابزارها و تکنیک‌ها برای ساخت اپلیکیشن‌های سریع، مقاوم و مقیاس‌پذیر. 📌 Feature Flags🔴 مشکل: انتشار ویژگی‌های جدید معمولاً نیاز به استقرار مجدد دارد که باعث داون‌تایم شده و بازگشت تغییرات را پیچیده می‌کند.🛠️ ابزارها:✅ LaunchDarkly✅ Unleash📌 Secrets Management🔴 مشکل: ذخیره اطلاعات حساس در فایل‌های پیکربندی، ریسک‌های امنیتی را افزایش می‌دهد.🛠️ ابزارها:✅ Azure Key Vault✅ HashiCorp Vault📌 WebSockets🔴 مشکل: تأخیر بالا در اپلیکیشن‌های بلادرنگ باعث کاهش پاسخ‌گویی می‌شود.🛠️ ابزارها:✅ SignalR📌 Load Balancing🔴 مشکل: در زمان افزایش ناگهانی ترافیک، یک سرور به تنهایی می‌تواند تبدیل به یک گلوگاه شود.🛠️ ابزارها:✅ NGINX✅ Traefik📌 Message Brokers🔴 مشکل: وابستگی زیاد بین سرویس‌ها ارتباط را کند کرده و ریسک خرابی را افزایش می‌دهد.🛠️ ابزارها:✅ RabbitMQ✅ Kafka📌 Building Resilient Applications🔴 مشکل: خرابی سرویس‌های خارجی می‌تواند باعث داون‌تایم شود.🛠️ ابزارها:✅ Polly✅ Circuit Breaker✅ Hystrix📌 Background Jobs🔴 مشکل: وظایف طولانی‌مدت باعث افزایش زمان پاسخ‌دهی می‌شوند.🛠️ ابزارها:✅ Hangfire✅ Quartz.NET✅ Celery📌 Data Consistency🔴 مشکل: حفظ یکپارچگی داده‌ها بین سرویس‌های توزیع‌شده چالش‌برانگیز است.🛠️ ابزارها:✅ EventStoreDB✅ Akka📌 API Gateway🔴 مشکل: مدیریت چندین API می‌تواند پیچیده شود.🛠️ ابزارها:✅ YARP✅ Kong📌 API Documentation🔴 مشکل: عدم وجود مستندات مناسب برای API باعث کند شدن توسعه می‌شود.🛠️ ابزارها:✅ Swagger📌 Multi-Tenancy🔴 مشکل: مدیریت داده‌های مخصوص به هر کاربر در یک اپلیکیشن واحد پیچیدگی را افزایش می‌دهد.🛠️ ابزارها:✅ SaaSKit📌 Distributed Tracing🔴 مشکل: دیباگ کردن میکروسرویس‌ها بدون داشتن دید مناسب دشوار است.🛠️ ابزارها:✅ Jaeger✅ Zipkin🔗 لینک‌های مرتبط:📌 Medium: اینجا کلیک کنید📌 GitHub: اینجا کلیک کنید#Scalability #Microservices کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Fri, 07 Feb 2025 16:15:53 +0330 https://virgool.io/@KeivanDamirchi/%D9%86%DA%A9%D8%A7%D8%AA%DB%8C-%D9%85%D9%87%D9%85-%D8%AF%D8%B1%D8%A8%D8%A7%D9%87-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%A7%DB%8C-%D9%BE%DB%8C-%D8%A2%DB%8C-%D9%87%D8%A7-uqtnsoxak8cv ساخت API‌ های REST کارآمد و مقیاس‌پذیر، کلید ایجاد برنامه‌های قوی و قابل نگهداری است. این راهنما نکات ضروری را برای طراحی و توسعه API‌هایی که امن، کاربرپسند و آماده برای رشد همراه با پروژه‌ها هستند، بررسی می‌کند.این راهنما نکات اساسی را برای طراحی و توسعه APIهایی که امن، کاربرپسند و آماده برای رشد با پروژه‌های شما هستند، بررسی می‌کند.برای مطالب بیشتر صفحات من را در شبکه های اجتماعی زیر دنبال کنید.لینکدینگیت هابمدیوم کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Sat, 28 Sep 2024 12:48:20 +0330 https://virgool.io/codenevis/%D8%A7%D8%B4%D8%AA%D8%A8%D8%A7%D9%87%D8%A7%D8%AA-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D9%88-%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF%D8%A7%D8%AA%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AD%D9%84-%D8%A2%D9%86%D9%87%D8%A7-a8bgh0ckxtaq به نظر من برنامه نویسی در کنار همه پیچیدگی هایش یک هنر است. به عنوان برنامه نویس، ما اغلب در این صنعت با چالش های مختلف، اعم از جزئی و عمده مواجه می شویم. هنر ما به عنوان برنامه نویس این است که این چالش ها را حل کنیم. در این پست 21 اشتباه رایج که ممکن است در هنگام کدنویسی با آنها مواجه شویم را جمع آوری کرده ام و در کنار هر کدام راه حل های بهینه و بهتری را پیشنهاد کرده ام.این مجموعه در چندین پست آپدیت می شود که می توانید با مراجعه به لینک Github ذکر شده از بروز رسانی آن مطلع شوید.GithubMedium کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Wed, 10 Jul 2024 05:12:49 +0330 https://virgool.io/@KeivanDamirchi/32-tools-for-developers-vhsgnfsqf9eb گاهی اوقات به دلیل عدم شناخت ابزارهای توسط توسعه دهندگان، ممکن است کارها به شکل عجیبی زمان بر شود. با استفاده از برخی ابزارهایی که توسط شرکتها و اشخاص مختلف تولید شده اند، بسیاری از کارهای مرتبط فرایند تولید یک نرم افزار مانند تحلیل، توسعه، خطایابی، استقرار و ... با سرعت بیشتری انجام خواهد شد.لیست زیر شامل برخی از این ابزارها می باشد، در کنار نام هر ابزار، ویدیویی مرتبط با آموزش و نحوه استفاده آن قرار داده شده است.32 ابزار برای توسعه دهندگان نرم افزار - به همراه لینک ویدیوهای مرتبط در یوتویوبنکات کلیدی که باید در نظر بگیرید:? تا حد امکان ویدیوهای جدید، کوتاه و مرتبط ذکر شده است.? گاهی اوقات انجام کارها به صورت دستی سود بیشتری نسبت به استفاده از ابزار دارد.? مهم است که به طور مداوم مجوزهای مرتبط با نرم افزاری را که استفاده می کنید در نظر بگیرید.? لطفا توجه داشته باشید که لینک های موجود در تصویر ممکن است به مرور زمان قدیمی شوند. می توانید پیوندهای معتبری را در گیت هاب من پیدا کنید.[اگر ابزارهای دیگری را می شناسید که به روند توسعه یک نرم افزار کمک می کند، حتماً آن را در قسمت نظرات معرفی کنید.]? Github? Medium? LinkedIn کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Sat, 07 Oct 2023 04:15:56 +0330 https://virgool.io/@KeivanDamirchi/%D8%B3%D9%88%D9%84%D9%88%D8%B4%D9%86-%D9%87%D8%A7%DB%8C-%D8%A2%D9%85%D8%A7%D8%AF%D9%87-%D8%A8%D8%A7-%D8%A7%D8%B5%D9%88%D9%84-%DA%A9%D9%84%DB%8C%D9%86-%DA%A9%D8%AF-tigag7xlrvzh هر زمان که پروژه جدیدی را آغاز می کنید، احتمالا متوجه این موضوع شده اید که زمان قابل توجهی را برای ایجاد فایل ها و تعریف ساختار پروژه صرف می کنید و ممکن است بعد از مدتی به این نتیجه برسید که کل معماری ایجاد شده(یا حداقل بخشی از آن) فاقد تمیزی مطلوب (کیفیت و رعایت کردن اصول کدنویسی تمیز) است؟خبر خوب این است که به عنوان یک توسعه دهنده، همیشه لازم نیست از ابتدا شروع کنید. می‌توانید از پروژه‌های موجود نوشته شده به زبان یا چارچوب دلخواه خود استفاده کنید و در زمان و هزینه صرفه‌جویی کنید. برخی از این پروژه های در زیر فهرست شده اند.لیست سولشن های آماده برای شروع پروژه جدید در زبان و فریم های مختلفبا کلیک روی هر کدام از لینک های زیر به صفحه گیت هاب مربوط به آن منتقل خواید شد:- .Net Core (C#)https://github.com/jasontaylordev/CleanArchitectureFork: 3kStart: 13.4khttps://github.com/ardalis/CleanArchitectureFork: 2.kStart: 13.5- Spring Boot (Java)https://github.com/anton-liauchuk/educational-platformFork: 39Start: 173https://github.com/soyjuanmalopez/clean-architectureFork: 86Start: 219- ReactJs (JS, Type Script)https://github.com/eduardomoroni/react-clean-architectureFork: 165Start: 1.4khttps://github.com/falsy/react-with-clean-architectureFork: 106Start: 580- Angular (Type Script)https://github.com/aziznal/typescript-clean-architectureFork: 16Start: 47https://github.com/coffeeandcloud/angular-clean-architecture/tree/masterFork: 80Start: 214- Flutter (Dart)https://github.com/hungps/flutter_pokedexFork: 518Start: 2.1khttps://github.com/ShadyBoukhary/flutter_clean_architectureFork: 162Start: 607- Nodejs (JS)https://github.com/talyssonoc/node-api-boilerplateFork: 5373.2khttps://github.com/jbuget/nodejs-clean-architecture-appFork: 276Start: 1.4k- Django (Python)https://github.com/jacob-y/django-clean-architectureFork: 11Start: 40https://github.com/sdediego/django-clean-architectureFork: 4Start: 30- FastAPI (Python)https://github.com/jujumilk3/fastapi-clean-architectureFork: 15Start: 69https://github.com/Hulvdan/fast-api-templateFork: 0Start: 7- Gohttps://github.com/bxcodec/go-clean-archFork: 1.4kStart: 8.1khttps://github.com/evrone/go-clean-templateFork: 510Start: 5.5k- Kotlinhttps://github.com/igorwojda/android-showcaseFork: 864Start: 6.1khttps://github.com/android10/Android-CleanArchitecture-KotlinFork: 9024.5k- Laravel (PHP)https://github.com/bdelespierre/laravel-clean-architecture-demoFork: 37Start: 137https://github.com/smortexa/laravel-arkitectFork: 3Start: 81- SwiftUIhttps://github.com/nalexn/clean-architecture-swiftuiFork: 586Start: 4.9khttps://github.com/kudoleh/iOS-Clean-Architecture-MVVMFork: 575Start: 3.3kنکات کلیدی که باید در نظر بگیرید:* این پروژه ها با تمرکز بر اصول کلین کد طراحی شده اند.* پس از کلون/دانلود هر یک از این پروژه ها، ممکن است لازم باشد آنها را مطابق با نیازهای خاص خود تغییر دهید.* همیشه مراقب لاینسنس های مرتبط با کدی که استفاده می کنید باشید.[اگر پروژه‌ای را نوشته‌اید که از شیوه‌های کلین کد پیروی می‌کند و برای عموم قابل دسترسی است، در صورت تمایل به اشتراک بگذارید.]پیوند های مربوطه:گیت هابمدیوملینکدین کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Wed, 04 Oct 2023 15:47:05 +0330 https://virgool.io/@KeivanDamirchi/100-%D9%BE%DA%A9%DB%8C%D8%AC-%D8%AF%D8%A7%D8%AA-%D9%86%D8%AA%DB%8C-%D9%86%D9%88%DA%AF%D8%AAnet-nuget-packages-%D8%AF%D8%B1-32-%DA%AF%D8%B1%D9%88%D9%87-%D9%85%D8%AE%D8%AA%D9%84%D9%81-hmv6pm7xueoi لیست زیر شامل 100 پکیج نوگت برای توسعه دات نت می باشد که در 32 گروه مختلف دسته بندی شده است.موارد رنگی شده جهت خوانایی به این شکل در آمده اند و هدف از آن نمایش اهمیت پکیج ها نمی باشد. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Fri, 28 Apr 2023 22:27:07 +0330 https://virgool.io/@KeivanDamirchi/15-%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%D8%B1-%DB%8C%DA%A9-%D8%B4%D8%A7%D8%AA-lsjncdykyijn لیست زیر شامل الگوهای طراحی رایج است که هر کدام به طور خلاصه و کلی توضیح داده شده است.کلمات کلیدی فهرست شده در زیر هر الگو یک راهنمای سریع برای برای درک بهتر می باشد. گیت هاب منلینکدین منمدیوم من کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Sat, 15 Apr 2023 22:12:26 +0330 https://virgool.io/@KeivanDamirchi/jsontoclass-czhklp2aezlg گاهی اوقات ممکن است لازم باشد در طول فرآیند توسعه نرم افزار خود با سرویس های مختلف ارتباط برقرار کنیم. در حال حاضر اکثر سرویس ها از فرمت JSON برای تبادل اطلاعات استفاده می کنند. تبدیل دستی JSON به مدل مورد نظر ما می تواند زمان بر و کسل کننده باشد. لیست زیر وب سایت ها و روش های تبدیل JSON به کلاس مورد نظر شما در زبان های برنامه نویسی مختلف را ارائه می دهد.تبدیل جیسان به کلاسهای دلخواه در زبانهای برنامه نویسی مختلفJson to C#json2csharp: https://json2csharp.comquicktype: https://quicktype.io/csharpquicktype vs code extention: https://marketplace.visualstudio.com/items?itemName=quicktype.quicktypejsonformatter: https://jsonformatter.org/json-to-csharpwtools: https://wtools.io/convert-json-to-csharp-classsite24x7: https://www.site24x7.com/tools/json-to-csharp.htmlVisual Studio Option: Edit > Paste Special > Paste JSON As ClassesJson to Javajsonschema2pojo: https://www.jsonschema2pojo.orgcodebeautify: https://codebeautify.org/json-to-java-converterjson2csharp: https://json2csharp.com/code-converters/json-to-pojojsonformatter: https://jsonformatter.org/json-to-javasite24x7: https://www.site24x7.com/tools/json-to-java.htmlJson to Dart(Flutter)javiercbk: https://javiercbk.github.io/json_to_dartjsontodart: https://jsontodart.comwebinovers: https://www.webinovers.com/web-tools/json-to-dart-convertorjsontodart: https://www.jsontodart.inJson to Pythonjson2csharp: https://json2csharp.com/code-converters/json-to-pythonjsonformatter: https://jsonformatter.org/json-to-pythonمطالعه در گیتهاب: لینکمطالعه در مدیوم: لینکلینکدین من: لینک کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Fri, 07 Apr 2023 16:52:16 +0330 https://virgool.io/@KeivanDamirchi/message-brokers-1-v1s2zydplmoa مسیج برورکر (Message Broker) چیست؟مسیج بروکرها یک تکنولوژی ارتباط بین برنامه ای هستند که به ایجاد یک ارتباط یکپارچه در معماری سیستم های ابری، میکروسرویس ها و Serverless کمک می کنند. یک مسیج بروکر نرم افزاری است که به برنامه ها، سیستم ها و سرویس ها را در انتقال و جابجایی پیام میان یکدیگر کمک می کند. در اینجا یک پیام (Message) می تواند در خواست ثبت یک لاگ، ارسال یک متن ساده از یک سرویس به سرویس دیگر و یا ارسال یک دیتا مدل پیچیده به چند دریافت کننده باشد. مسیج بروکرها عمل انتقال پیام ها را با ترجمه پیام ها با استفاده از پروتکل های قراردادی انجام می دهند که این قابلیت به سرویس هایی که به یکدیگر وابسته هستند کمک می کند تا با یکدیگر "گفتگو" کنند حتی اگر در زبان ها و پلتفرم های جداگانه ای پیاده سازی شده باشند.انتقال یک پیام از یک ارسال کننده به یک دریافت کننده توسط مسیج بروکرمسیج بروکرها ماژول های نرم افزاری به همراه Messaging Middleware یا Message-Oriented Middleware (MOM) هستند که این نوع از میان افزارها به توسعه دهندگان در استانداردسازی جریان داده ها بین کامپوننت های نرم افزاری کمک می کند که در نهایت باعث می شود تا توسعه دهندگان بر روی منظق برنامه خود تمرکز بیشتری بگذارند و نگران نحوه ارتباط بین سرویس ها نباشند. این میان افزارها می توانند بعنوان یک لایه ی ارتباطی توزیع شده میان برنامه ها عمل کنند و در واقع نقش یک پل ارتباطی را میان پلتفرم ها بازی می کنند. مواردی نظیر اعتبارسنجی، ذخیره پیام، مسیریابی و تحویل پیام از جمله کارهای یک مسیج بروکر است که میتواند انجام دهد. فرقی نمی کند که چند دریافت کننده برای یک پیام وجود دارد، فعال یا غیر فعال بودن و یا موقعیت دریافت کنندهای یک پیام اهمیتی ندارد، مسیج بروکرها به ارسال کنندگان پیام این اجازه را می دهند تا با خیال راحت پیام خود را ارسال کنند و با ارائه امکانات ذکر شده گره و اتصال موجود بین فرایندها و سرویس ها را از بین می برند.صف پیام (Message Queue)برای فراهم سازی یک فضای ذخیره سازی قابل اطمینان و تحویل تضمین شده یک پیام، مسیج بروکرها اغلب به یک ساختار یا یک بخشی به نام صف پیام(Message Queue) متکی هستند که وظیفه ذخیره و مرتب سازی پیام ها را تا زمان دریافت شدن توسط یک دریافت کننده بر عهده دارد. یک صف، در واقع یک فضای ذخیره سازی پیام می باشد که پیام ها دقیقا به همان شکلی که وارد صف شدند تا زمان قبول(دریافت) توسط یک دریافت کننده نگهداری می شوند.یک صف، بخش اصلی مسیج بروکر می باشدپیام رسانی غیرهمزمان (Asynchronous messaging) Asynchronous messaging اشاره به نوعی از ارتباط بین برنامه ای می کند که توسط مسیج برورکرها پشتبانی می شود. این راهکار باعث می شود تا جلوی از دست رفتن داده های ارزشمند گرفته شود و سیستم در شرایطی نظیر قطع و وصل شدن مکرر ارتباطات و یا مشکلات رایج در سطح شبکه به فعالیت خود ادامه دهد. پیام رسانی غیرهمزمان تضمین می کند که پیامها توسط دریافت کننده تنها "یک بار" و آن هم با ترتیبی که قبلا ثبت شد دریافت شود. بطور مثال یک پیام منحصر به فرد با وصل شدن مجدد دریافت کننده بصورت چندباره دریافت نمی شود.انواع مسیج بروکرهامسیج بروکرها از دو الگوی ساده جهت توزیع پیام ها استفاده می کنند:Point-to-point messaging:این یک الگوی توزیع می باشد که توسط صف پیام مورد استفاده قرار می گیرد و یک رابطه "یک به یک" را میان یک ارسال کننده و یک دریافت کننده نمایندگی می کند. هر پیام در صف تنها یک بار به یک دریافت کننده ارسال می شود و این عمل فقط یک بار اتفاق می افتد. این الگو زمانی استفاده می شود که تنها نیاز به یک مرتبه اجرای یک دستور در یک لحظه وجود دارد. بطور مثال برای این الگو می توان به عملیات انتقال وجه اشاره کرد که میان پرداخت کننده و دریافت کننده برای هر پرداخت انجام می شود و این تراکنش کافیست یک بار در یک زمان روی دهد.Publish/Subscribe Messaging:در این الگو که اغلب به pub/sub معروف است، تولید کننده هر پیام، پیام را را درون یک تاپیک(Topic) قرار می دهد و چندین دریافت کننده ی پیام(Message Consumers)، در آن تاپیکی که میخواهند از آن پیام دریافت کنند مشترک(Subscribe) می شوند. همه پیام های منتشر شده در یک تایپک میان همه ی مشترکان یک تایپک توزیع می شود، این یک روش پخش توزیع شده می باشد که یک رابطه "یک به چند" میان ارسال کننده پیام و دریافت کنندگان آن پیام در آن حاکم می باشد. برای مثال، اگر یک شرکت هواپیمایی قصد انتشار بروزرسانی اطلاعاتی درباره ساعت پروازها و یا تاخیر یک پرواز داشته باشد، چندین بخش می توانند از این اطلاعات استفاده کنند: قسمت خدمه هایی که وظیفه سوخت گیری یا تعمیر و یا نگهداری هواپیما را بر عهده دارند، حمل کنندگان چمدانها، خدمه پرواز و خلبانان که آماده پرواز بعدی می شوند و نمایشگرها که اطلاعات مربوط به پرواز را نمایش می دهند. در این حالت یک ارسال کننده پیام و چندین دریافت کننده پیام (pub/sub) برای این سناریو مناسب می باشد.تفاوت مسیج بروکر با APIای پی آی ها معمولا جهت ارتباط میان سرویس ها در یک معماری میکروسرویس مورد استفاه قرار می گیرند. عبارت Representational State Transfer (REST) مجموعه از اصول و قوانین را تعریف می کند که یک توسعه دهنده با استفاده از آنها اقدام به ایجاد یک وب سرویس میکند. هر سرویسی با رعایت این اصول قادر به تعامل با دیگر سرویس ها خواهد بود.Rest Apiها از HTTP برای ارتباط استفاده می کنند و به دلیل استاندارد بودن پروتکل HTTP و بکارگیری آن در اینترنت، Rest APIها بطور گسترده ای شناخته شده اند و مورد استفاده قرار گرفته اند. HTTP یک پروتکل Request/Response می باشد که برای ارسال درخواست و دریافت پاسخ بصور همزمان مورد استفاه قرار میگیرد، این بدین معنا می باشد که زمانی که یک سرویس درخواستی را از طریق Rest API ارسال می کند، انتظار پاسخ آن را بدون فاصله و بصورت همزمان دارد اما در مقابل، مسیج برورکرها قادر به ارتباط به صورت غیر همزمان می باشند، بنابراین سرویس ارسال کننده درخواست نیاز به انتظار جهت دریافت پاسخ را ندارد. این ویژگی تحمل پذیری سیستم در مقابل خطاها و پایداری آن را افزایش می دهد.تفاوت مسیج بروکر ها با پلتفرمهای جریان رویداد (Event Streaming Platforms)در حالی که مسیج بروکر ها دو یا چند الگوی پیام رسانی را پشتیبانی می کنند، پلتفرم های جریان داده تنها از الگوی pub/sub پشتیبانی می کنند. پلفترمهای جریان داده جهت پشتبانی از حجم زیاد مسیج ها و بصورت کاملا مقیاس پذیر توسعه داده شده اند. بر خلاف مسیج بروکر ها، پلتفرم های جریان داده نمی توانند تحویل یک پیام را تضمین کنند و یا امکان فهمیدن اینکه کدام دریافت کننده پیام را دریافت کرده ندارند. پلتفرمهای جریان داده مقیاس پذیری بالاتری نسب به مسیج بروکر ها دارند اما در مقابل ویژگی های کمتری را در حوزه تحمل پذیری خطا(مانند باز ارسال پیام) دارند.تفاوت مسیج بروکر با ESBیک ESB(Enterprise Service Bus) یک الگوی معماری می باشد که گاها در معماری های سرویس گرا استفاده می شود. زمانی که از ESB استفاده میکنیم، در واقع در حال متمرکز سازی ارتباطات و پروتکل های استفاده شده در پلفترم نرم افزاری خود هستیم که در نهایت قصد داریم به یک "زبان مشترک" میان سرویس های خود برسیم تا به راحتی بتوانند کارکردهای خود را میان دیگر سرویس ها اشتراک بگذارند. بطور مثال، یک درخواست با فرمتی مثل XML دریافت می شود و به فرمت JSON تبدیل می شود. از جمله کارهای یک ESB انتقال خودکار پیام ها، مسیریابی، اتصال سرویس ها به یکدیگر می باشد. ESB ها عموما پیچیده هستند و پیاده سازی و استفاده از آنها دشوار می باشد و نیاز به زمان و هزینه بالا برای بکار گیری دارند، فرایند خطایابی و تغییر محیط در این سیستم ها و همچنین به روز رسانی آنها از مواردی می باشد که باعث می شود استفاده از آنها برای توسعه دهندگان و معماران سیستم هزینه زا باشد. در مقابل مسیج بروکرها جایگزین سبک تری برای ESB ها هستند که قابلیت هایی مانند ماکنیزم ارتباط بین سرویس ها، چیزی مشابه ای ESB ها بصورت سبک تر و با هزینه کمتری دارند.موارد استفاده از مسیج برورکراستفاده از مسیج بروکرها می تواند نیازمندی های مختلف یک بیزینس را پوشش دهد. آنها در زمانها و جاهایی که نیاز به ارتباطات میان سرویسی و اطمینان از تحویل یک پیام از یک سرویس به سرویس دیگر=وجود دارد بسیار سودمند هستند. مسیج بروکرها اغلب در موارد زیر مورد استفاده قرار می گیرند:تراکنش های مالی و فرایند های پرداختبسیار حائز اهمیت است که یک پرداخت که توسط یک کاربر انجام شده تنها یک بار ارسال شود، منظور از ارسال یک باره یک درخواست این است که بطور مثال انتقال وجه از حساب الف به حساب ب که توسط کاربر انجام شده است بصورت دو باره یا چند باره انجام نشود و یا زمانی که شبکه قطع می باشد، فرایند نقل و انتقال وجه پس از برطرف شدن مشکل شبکه به درستی انجام شود.سفارشات آنلاین در حوزه تجارت الکترونیک مشابه سناریو تراکتش مالی که در بالا ذکر شد، اگر قصد راه اندازی یک سیستم فروشگاهی آنلاین را داشته باشید و پایداری این سیستم برای شما مهم باشد، نیاز دارید تا از مسیج برورکر ها بعنوان ابزار جهت ارسال درخواست های مهم مانند ثبت سفارش استفاده کنید. در این نوع درخواست ها بسیار حائز اهمیت می باشد که درخواست ثبت سفارش کاربر در زمان خرابی یا مشکل میان سرویس ها مختلف به درستی انجام شود.محافظت از حجم زیادی از اطلاعات حساسی که نیاز به نقل و انتقال دارنداگر سرویس های که در حوزه کاری خود با آن سر و کار دارید نیاز دارند که بسیار دقیق(از لحاظ زمانبندی) باشند و یا از لحاظ مسائل امنیتی ممکن است هدف برخی از خطرات قرار بگیرید، مسیج برورکرها می توانند انتخاب مناسبی جهت رمز نگاری end-to-end برای انتقال پیام ها باشند.در نوشته های بعدی با انواع مسیج بروکرها و نحوه بکارگیری آنها آشنا می شویم. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Thu, 05 May 2022 20:25:29 +0430 https://virgool.io/@KeivanDamirchi/cicd-%D9%82%D8%B3%D9%85%D8%AA-4-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-nlfiqtpfdvgm پیاده سازی یک نمونه از پایپ لاینهای بیلد و ریلیز با Microsoft Azure DevOps 2019 در این قسمت، با مشاهده ویدیویی که لینک آن قرار داده شده، بعد از بررسی موارد :حل چالشهای موجود در سازمان با DevOpsتعاریف مفاهیم DevOps و مفاهیم وابسته به آنمفاهیم مرتبط با DevOpsبه سراغ پیاده سازی یک نمونه پروژه واقعی که با Asp.Net Core توسعه داده شده است می رویم و بعد از تعریف پایپ لاینهای Build و Release و پیکربندی های مورد نظر، با اعمال تغییر جدید در کد و ارسال آن به سرور، یک نسخه جدید از نرم افزار را در سرور خواهیم داشت.لینک مشاهده ویدیو : آموزش Devops/CI/CD و پایپ لاینهای Build-Release به همراه پیاده سازیاسلاید مورد استفاده در ویدیو : کلیک کنید کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Mon, 26 Oct 2020 22:46:48 +0330 https://virgool.io/@KeivanDamirchi/cicd-%D9%82%D8%B3%D9%85%D8%AA-3-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D9%85%D8%B1%D8%AA%D8%A8%D8%B7-xt953qc31gcr در قسمت قبل با تعاریف اصلی CI/CD و همچنین مزایای آنها آشنا شدیم، در این قسمت با مفاهیم مرتبط با CI/CD که در حین کار با آن برخورد می کنیم آشنا می شویم.داکر در طی فرایندهای CI/CD فواید بسیاری از جمله سرعت، اطمینان، ... را به توسعه دهندگان و سازمان می رساندداکر و داکرایز کردن سرویس هاابتدا در این پست تعریف ساده ای از داکر را با هم می خوانیم : با استفاده از داکر به خوبی می‌توان مواردی که برای یک پروژه نیاز است را در کنار هم جمع‌آوری کرد و به صورت کامل آنها را در یک پکیج قرار داد. یعنی به اختصار هر آن چیزی که یک نرم‌افزار نیاز خواهد داشت اعم از پکیج‌های وابسته (Dependency Package) و کتابخانه‌ها (library) مورد نیاز در یک کانتینر آماده خواهد شد و همواره همراه نرم‌افزار در هر محیط که نیاز به راه‌اندازی دارد منتقل خواهد شد.همانطور که مطالعه کردید، بطور کلی داکر یک تکنولوژی می باشد که یکی از مزایای آن امکان یکپارچه سازی وابستگی های یک سرویس یا نرم افزار است. برای درک عمیق تر داکر این پست را مطالعه کنید.با توجه به وضعیت های مختلفی که در مراحل تولید و توسعه نرم افزارهای یک سازمان وجود دارد، ممکن است سازمان از تکنولوژی داکر در مراحل توسعه نرم افزار خود استفاده نکند، با در نظر گرفتن اینکه فرایند داکرایز کردن نرم افزارها برای انتشار و نگهداری نسخه های نرم افزاری بسیار با ارزش و سودمند می باشد، با داکرایز کردن نرم افزارهای و سرویس های سازمان، علاوه بر استفاده از فوایدی که داکرایز کردن به خودی خود دارد (از جمله سرعت لود بالاتر نسبت به ماشین مجازی و سیستم عامل ها، امکان تعیین میزان دلخواه سی پی یو و رم برای نرم افزار، قابل حمل بودن image ها، ...) از مزایای آن در انتشار نسخه های جدید نرم افزارها که یکی از اصلی ترین آن پیکربندی آسان تر و یکپارچه بودن با سیستم های رایج CI/CD است استفاده شود.تست اتوماتبعد از انتشار یک نسخه نرم افزاری بصورت دستی، در اکثر مواقع توسعه دهندگان نرم افزار مجبور به تست بخش به بخش قسمت های جدید و قسمت هایی که تغییرات در آن اعمال شده است می باشند تا از صحت عملکرد موارد تغییر داده شده مطلع شوند. با توجه به هزینه بر بودن تست دستی و همچنین امکان وجود خطا در فرایند تست دستی، می توان به تدریج و بصورت مرحله به مرحله به هرکدام از نرم افزارها و سرویس های موجود در سازمان، تست هایی از قبیل تست واحد، تست یکپارچه سازی هر چند بصورت ابتدایی اضافه شود تا در کنار انتشار خودکار نسخه های جدید نرم افزار، عملکرد بخش های مختلف نرم افزار یک بار بصورت کامل تست شود تا نسخه جدید با اطمینان خاطر بیشتری در محیط عملیاتی قرار گیرد. با افزودن تست های ذکر شده مزیتهایی که برای سازمان حاصل می شود شامل اطمینان توسعه دهندگان نرم افزار و مدیران پروژه از صحت کارکرد موارد تغییر داده شده در نسخه منتشر شده و همچنین کارکرد درست نرم افزار برای کاربران(درون سازمانی یا برون سازمانی) می باشد. در فرایند CI/CD می توان از انواع تست ها بهره برد و با سرعت بیشتری باگها و خطاهای سیستم را کشف کرداز آنجا که وجود تست اتومات بعنوان یک مزیت برای CI/CD مطرح می شود، همانطور که ذکر شد توصیه می شود شروع اتوماسیون کردن تست ها بصورت ابتدایی و مرحله به مرحله به نرم افزارها و سرویس های موجود در سازمان اضافه شود. از جمله فوایدی که برای تست اتومات می توان برشمرد به شرح زیر می باشد :دریافت بازخورد سریعتر و دقیق تر در هر فاز از پروژه به توسعه دهندگان و مدیران پروژهبالا بردن کیفیت کدهای نوشته شده به جهت وجود خطاهای کمترمستندسازی کدها توسط برخی تست ها(تست های واحد)پروداکتیو شدن هر چه سریعتر نرم افزار به جهت تست سریع ترافزایش امنیت در حوزه قوانین تجاری و منطقی یک نرم افزارRollback کردن نسخه های منتشر شدهبعد از انتشار یک نسخه نرم افزار با استفاده از CI/CD ، به دلایل مختلف ممکن است کارکرد نرم افزار با مشکل مواجهه شود و تیم توسعه نیاز داشته باشد تا وضعیت نرم افزار را به حالت قبل از انتشار بازگرداند. برای انجام این کار چند استراتژی وجود دارد که در زیر به آن اشاره شده است :بازگردانی تغییرات با استفاه از انتشار نسخه قبلی(بازنشر نسخه قبل)، یکی از ساده ترین راه های پیش روی تیم توسعه این است که با استفاده از آخرین نسخه منتشر شده قبل از نسخه فعلی، وضعیت نرم افزار را به حالت قبل از انتشار شکست خورده ببرند. نحوه انجام آن نیز بدین صورت می باشد که با مراجعه به لیست Release های قبلی و انتخاب Release مورد نظر، به سادگی اقدام به بازگردانی به نسخه دلخواه نمایند. البته این روش در هر شرایطی پاسخگوی نیاز تیم توسعه نمی باشد، چرا که ممکن است نرم افزار به همراه سرویس های خارجی منتشر شده باشد و یا تغییرات مربوط به دیتابیس از قبیل تغییر نام جدول و .. اتفاق افتاده باشد. همانطور که ذکر شد، در صورت وجود تغییرات روی دیتابیس همراه با نسخه جدید، استفاده از این روش بطور کاملا روال بازگردانی را پوشش نمی دهد و قسمتی از فرایند بازگردانی در این روش نیازمند برگرداندن دستی تغییرات مربوط به دیتابیس می باشد.برطرف کردن مشکل و انتشار مجدد نسخه، روشی عمدتا دستی اما منعطف تر می باشد که تیم توسعه قادر است بصورت دستی تغییرات اعمال شده را به حالت قبل از انتشار شکست خورده برگرداند و تغییرات مربوط به سرویس های خارجی و اسکریپت های دیتایس و ... اعمال نماید. گرچه ممکن است شرایط بازم هم مطمئن نباشد اما بصورت حداقلی می توان کارکرد نرم افزار را تا بعد از برطرف کردن مشکل تضمین کرد. این روش زمانی سودمند می باشد که تیم توسعه وقت کافی برای اصلاح خطای موجود داشته باشد و یا ابعاد خطای بوجود آمده آنقدر کوچک باشد که با صرف زمان اندک نسبت به رفع آن اقدام شود.ترکیبی از دو روش قبل، بدین صورت که با فرض پیش بینی وجود خطا در انتشار نسخه، اقدام به تهیه اسکریپت های مرتبط با تغییرات جاری کرده و در صورت وجود خطا و با اجرای اسکریپت های اصطلاحا Rollback وضعیت را به حالت قبل از بروز خطا برگردانیم و بعد از برطرف کردن مشکل اقدام به بازنشر نسخه جدید کنیم. در کنار تهیه اسکریپت های Rollback، می توان اقدام به تعریف وظایف Rollback نیز نمود تا اسکریپت ها نیز به صورت خودکار برگردانده شوند. برای ایجاد اسکریپت های مربوط به Rollback می توان از نرم افزارهای موجود در زمینه کار با دیتابیس استفاده نمود. بطور مثال نرم افزار ApexSQL یک نرم افزار قدرتمند در زمینه رهگیری تغییرات دیتابیس و ... می باشد که به سادگی قابلیت بررسی تغییرات انواع مختلف نسخه های دیتابیس را می دهد. با توجه به استفاده تیم توسعه از CI/CD برای انتشار نسخه های نرم افزاری، می توان این پیشفرض را پذیرفت که میزان تغییرات مربوط به یک نسخه با نسخه قبل، به دلیل انتشار سریع نسخه ها، به اندازه ای کم است که زمان و انرژی چندانی از تیم های برای ایجاد اسکریپت های Rollback نمی گیرد.مانیتورینگ عملیات های CI/CDاز آنجا که هدف اصلی CI/CD خودکار سازی و سرعت بخشی هر چه بیشتر به فرایند توسعه و انتشار نسخه های نرم افزاری می باشد، معمولا فرایندهای درگیر در توسعه و انتشار در صورت پیکربندی مناسب کمتر با خطا یا شکست مواجهه می شوند، اما با توجه به اهمیت نرم افزارهای موجود در سازمان ها، نیاز است با استفاده از ابزارهای موجود در طی مراحل تست، بیلد خودکار، انتشار در محیط های مختلف تستی و عملیاتی مانیتورینگ و پایش توسط تیم توسعه صورت بگیرد تا در صورت وجود شکست در یک مرحله، تیم توسعه با دریافت یک نوتیفیکیشن( که ممکن است ازطریق یکنرم افزار نصب شده در تلفن همراه توسعه دهندگان و یا ایمیل و اس ام اس دریافت شود) از بروز خطا مطلع شود و قبل از اینکه کاربران وجود خطا را حس کنند اقدام به رفع مشکل و اصلاح فرایندهانمایند. با استفاده از مانیتورینگ مراحل انتشار نرم افزار، مدیران پروژه های نرم افزاری و توسعه دهندگان از تمامی مراحل در فرایند نسخه گذاری نرم افزار مطلع می شوند و می توانند با راهکارهایی اقدام به بهتر شدن مراحل انتشار نرم افزار نمایند.امکان ارسال اعلان در صورت وجود خطا در فرایندهای CI/CD یکی از مزیتهایی مورد علاقه راهبران سیستم می باشد.** نرم افزارهای متفاوتی در حوزه اعلام رویدادهای جدید(نوتیفیکیشن و پیام رسانی) وجود دارد که از معروف ترین آن ها سرویس Slack می باشد که علی رغم به همراه داشتن امکانات متنوع و یکپارچه سازی بالا با دیگر نرم افزارها، طی سالهای گذشته استفاده از آن با مشکلات و چالشهای مختلفی از جمله کندی،تحریم(تا زمان انتشار این پست) و هزینه بالای استفاده از آن در نسخه های تجاری در داخل ایران وجود داشته که استفاده از آن را پر هزینه کرده است.در قسمت بعد بصورت عملی و با استفاده از Microsoft Azure Devops اقدام به اعمال CI/CD بر روی یک نرم افزار خواهیم کرد. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Tue, 20 Oct 2020 21:42:09 +0330 https://virgool.io/@KeivanDamirchi/cicd-%D9%82%D8%B3%D9%85%D8%AA-2-wbc1fcdlgnx2 در قسمت قبل با چالشهای موجود در سازمانها برای انتشار و توسعه نرم افزارها آشنا شدیم، در این قسمت با تعریف CI و CD و همچنین مزایای آنها آشنا می شویم.CI/CD بصورت فزاینده ای باعث افزایش سرعت توسعه و انتشار نرم افزارها می شوند فرایند Continuous Integration فرایند CI که می توان معادل های فارسی چون "ادغام مدام" یا "یکپارچه سازی مستمر" برای آن در نظر گرفت، به مجموعه فعالیت­ها و فرایندهایی اشاره دارد که به وسیله آنها توسعه دهندگان و برنامه نویسان سازمان تغییرات جدید کدهای خود را به سورس کنترل(سیستم مرکزی که کدهای مربوط به یک پروژه در آن قرار دارد) اضافه کنند. در کنار فرایند اضافه شدن تغییرات جدید به سیستم کنترل سورس، فعالیت­هایی مانند بیلد خودکار برای بررسی عدم تاثیر منفی تغییرات روی کدهای قسمتهای دیگر پروژه و همچنین اجرای تست های واحد برای بررسی کارکرد صحیح کدهای موجود و کدهای جدید انجام می شود تا مشکلات مربوط به یکپارچه سازی به شدت کم شود و تیم ها توانایی توسعه نرم افزار را بصورت منسجم تری داشته باشند. بصورت خلاصه تر، به فرایند ادغام یکپارچه کدها و بیلد کردن پروژه و اجرای تست های واحد به صورت اتوماتیک و بدون دخالت نیروی برنامه نویس CI می گویند. عملیات شرح داده شده در بالا، ممکن است در طول یک روز و در حین کار یک گروه توسعه نرم افزاری کوچک تا بزرگ بر روی یک نرم افزار، به دفعات متعددی اتفاق بیافتد(در بازه های زمانی مختلف و تعداد نیروهای مختلف اتفاق می افتد).مزایا اصلی CI چیست؟فواصل زمانی Check In یا Push توسط توسعه دهندگان کوتاه تر می شود و تغییرات جدید با سرعت بیشتری به سورس کنترل اضافه می شود.توسعه دهندگان از تغییرات یکدیگر با سرعت بیشتری با خبر می شوند(در صورت نیاز و وابستگی یک ماژول به ماژول دیگر، معطلی توسعه دهندگان کمتر می شود).با استفاده از بیلد های خودکار بعد از هر Check In تیم توسعه اطمینان حاصل می کند که خطا ها و باگ ها خیلی زود کشف می شوند و از هزینه و زمان توسعه کمتری صرف شناسایی باگ ها خواهد شد.در اثر بیلد خودکار، تغییرات در یک پروژه نرم افزاری به کیفیت پایداری خواهد رسید.با مانیتورینگ وضعیت بیلد­ها و اجرای تست ­های واحد بعد از هر بار Check In ، توسعه دهندگان و مدیران پروژه از وضعیت فعلی کار خود با خبر می شوند.بوجود آمدن فرهنگ جدید سازمانی که در نتیجه آن، تمرکز اعضا بیشتر بر روی توسعه نرم افزار صرف می شود تا هماهنگی جهت مسائل حاشیه ای مانند یکپارچه بودن کدها و ... .فرایند Continuous Deliveryفرایند CD که معادل فارسی " تحویل مداوم یا مستمر" را می توان برای آن در نظر گرفت، یک رویکرد در توسعه و تولید نرم افزار می باشد که بر اساس آن تیم توسعه نرم افزار بصورت سریع و مطمئن، همواره آماده است تا جدیدترین نسخه از نرم افزار تولیدی را در هر زمانی منتشر کند. این فرایند از زمان اضافه شدن یا تغییر کد در سرور سورس کنترل شروع می شود و شامل بیلد، تست، پیکربندی و انتشار در محیط های گوناگون تستی یا عملیاتی می باشد. اهمیتی ندارند که تیم های توسعه چه تعداد بزرگ باشند و یا نرم افزاری که مد نظر است توزیع شده باشد یا خیر، با استفاده از CD فرایندهای شرح داده شده بصورت ساده و قابل پیش بینی و روتین تبدیل می شوند. مفهوم دیگری که مرتبط با مفهوم CD می باشد Continuous Deployment می باشد که گاها با Continuous Delivery یکسان تلقی می شود. Continuous Deployment فرایند انتشار تماما خودکار نرم افزار اشاره می کند. فعالیت­های حوزه CD عموما بعد از CI روی می دهد، به این معنی که پس از بروزرسانی سورس کد و انجام تست ها، CD وارد عمل می شود و به تیم توسعه این اطمینان را می دهد که نرم افزار آماده انتشار می باشد. با استفاده از CD فرایند دریافت بازخورد از کاربران با سرعت بیشتری انجام می شود، در نتیجه بعد از اعمال تغییرات و دریافت بازخورد کاربران می توان تغییرات جدیدتر را با دقت بیشتری در نرم افزار اعمال کرد.مزایای اصلی CDانتشار نرم افزار با حداقل ریسک و بدون استرس برای تیم توسعه نرم افزاری به دلیل اینکه نسخه ای از نرم افزار همیشه آماده انتشار می باشد.بروزرسانی هر چه سریعتر نرم افزار با توجه با نیاز کاربربه دلیل آسان تر شدن فاز انتشار، بروزرسانی ها با فاصله زمانی کمتر و با تغییرات کوچکتری اعمال می شود، در نتیجه کیفیت محصول نرم افزاری بیشتر می شود.تمرکز بیشتر تیم تولید و توسعه بر روی کار توسعه نرم افزار به دلیل خودکار سازی فاز انتشار نرم افزار. تیم های توسعه با استفاده از CD دیگر درگیر مسائلی مربوط به انتشار نرم افزار نمی شوند و فقط روی توسعه و افزایش کیفیت نرم افزار تمرکز می کنند.همانطور که شرح داده شد، مزایای اصلی پیاده سازی CI/CD در سازمانها این می باشد که وقفه مابین توسعه نرم افزار و انتشار آن روی سرورهای اصلی از بین می رود. از نکات حائز اهمیت بعد از پیاده سازی CI/CD مانیتورینگ فرایندها می باشد. به دلیل بالا بودن سرعت تغییرات که حاصل خودکار سازی فرایندهاست، سرعت انتشار نرم افزار روی سرورهای اصلی به حدی بالا می رود که تیم توسعه نرم افزاری دقایقی(ممکن است به چند ثانیه نیز کاهش یاید) بعد از اعمال تغییرات روی کدها، نتایج کار خود را روی محصول اصلی که بصورت زنده در اختیار کاربران قرار دارد مشاهده می کنند، به همین دلیل از نکاتی که در این فرایند باید در نظر گرفته شود مانیتورنیگ می باشد.نیازمندیهای سخت افزاریبهتر است قبل از انتشار نرم افزار بر روی سرور عملیاتی، بر روی سرور تست منتشر شود تا از کارکرد نرم افزار مطمئن شداز آنجا که یک محیط ثابت(محیط عملیاتی : سروری که نسخه اصلی نرم افزار برای استفاده کاربران در آن قرار میگیرد) همیشه وجود دارد، بهتر است به ازای هر سرویس یا نرم افزار، یک محیط تست جهت تست توسط گروه خاصی از کاربران یا توسعه دهندگان، با توجه به مکانیزم پیاده سازی قرار دادن نرم افزار در سرور( داکرایز کردن، انتشار در ماشین مجازی، انتشار در یک سرور فیزیکی) وجود داشته باشد تا همیشه قبل از نهایی شدن انتشار نرم افزار در محیط عملیاتی واقعی، یک نسخه بر روی محیط تست قرار گیرد تا از کارکرد صد درصدی نرم افزارها اطمینان حاصل شود. واضح است که برای عملیاتی کردن CI/ CD نیاز به سروری جهت نگهداری کدها (سورس کنترل) و پیکربندی و تعارف مربوط به بیلد ها، پایپ لاین ها و .... می باشد.با مفاهیم بیلد، پایپ لاین، داکرایز کردن و ... در قسمتهای بعد آشنا خواهید شد. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Tue, 20 Oct 2020 20:53:40 +0330 https://virgool.io/@KeivanDamirchi/cicd-%D9%82%D8%B3%D9%85%D8%AA-1-qhxskphsorzf امروزه سازمان ها و ارگان های مختلف، به دلیل نیاز به نرم افزارهای متنوع، تیم های فنی و توسعه نرم افزاری را در درون خود تشکیل داده اند. درخواست تولید، توسعه اعمال تغییرات گوناگون در نرم افزارهای این گونه سازمانها بسیار زیاد می باشد. یک سازمان ممکن است تعداد زیادی توسعه دهنده و برنامه نویس نرم افزار در واحد فناوری اطلاعات خود داشته باشد که هر کدام از این افراد، با توجه به نیاز سازمان و تشخیص مدیران مافوق، بصورت تیم های جداگانه و به همراه مهارت های مختلف روی یک یا چند پروژه نرم افزاری مورد نیاز سازمان مشغول به کار شوند. بعد از گذشت مدتی، هر کدام از تیم های نرم افزاری سازمان، محصولی را تولید و منتشر می کنند و کاربران مختلف اعم از کاربران درون سازمانی یا برون سازمانی شروع به استفاده از نرم افزارهای تولید شده می کنند. رفته رفته بعد از افزایش نیاز کاربران به ویژگی های جدید و همچنین کشف خطاها و نیاز به تغییرات به گروه های توسعه نرم افزاری ابلاغ می شود و تیم های نرم افزاری مجبور به اختصاص بخشی از زمان و انرژی خود برای به انجام رساندن رفع خطاها، افزودن ویژگیهای جدید و انتشار مجدد نرم افزار می شوند. با توجه به این که وظیفه و هدف اصلی تیم توسعه نرم افزار، تولید و توسعه و پشتیبانی نرم افزار می باشد، انجام کارهای موازی با این هدف مانند انتشار، تست و یکپارچه سازی بخش های نرم افزار انرژی، زمان و هزینه بسیار زیادی را به تیم های توسعه نرم افزاری وارد می کند.در کنار موارد ذکر شده، فرایندهایی که بصورت جزئی تر جدا از مرحله تولید و توسعه نرم افزار هستند،باعث کاهش بهره وری و هدر رفتن تمرکز نیروهای توسعه نرم افزاری بر روی فرایند های روتینی چون تست، یکپارچه سازی و انتشار نرم افزار می شود. در سالهای اخیر تیم های توسعه نرم افزاری در سرتارسر جهان به روشهایی دست یافته اند که امکان انجام خودکار فعالیتهای پیچیده مربوط به انتشار نرم افزار را به توسعه دهنگان می دهد. به مجموعه فعالیتهای موثری که باعث صرف جویی در زمان و هزینه در فرایندهای یکپارچه سازی کد، تست و انتشار نرم افزار می شود CI/CD می گویند که بعد تر مفصلا تشریح خواهد شد.Continuous Integration / Continuous Deliveryچالشهای پیش روتعداد نیرو های درگیر در یک پروژه در تیم های نرم افزاری مختلف، از یک نفر تا چند ده نفر متغیر می باشد، اگر یکپارچه سازی و ادغام تغییرات مربوط به کدهای یک گروه نرم افزاری به مدت چند روز یا چند هفته به تاخیر بیافتد، منجر به conflict(تداخل کدهای توسعه دهندگان مختلف) زیادی خواهد شد. در چنین شرایطی رفع خطا بسیار دشوار خواهد شد و نیاز به صرف زمان و هزینه های اضافی می شود که سازمان، مدیران و توسعه دهندگان را درگیر می کند.انتشار نرم افزار در تیم های نرم افزاری و فناوری اطلاعات عموما یک مسئله دشوار و تکراری به همراه خطا( به جهت فراموشی انجام یک یا چند مرحله از فرایند یا اجرای اسکریپت یا ...) می باشد، فرایند دستی و غیر خودکار انتشار و تست نرم افزار باعث انتشار نرم افزاری غیر قابل اتکا و همچنین تاخیر در زمان تحویل می شود.انجام دستی فرایند انتشار نرم افزار بصورت ناخواسته منجر به بوجود آمدن تیمی در سازمان می شود که اکثر وظایف آن حول پیرامون تست و انتشار نرم افزار می چرخد، حال آنکه با اتوماتیک کردن این فرایند نیاز به تیمی جداگانه برای این کار نخواهد بود.(در بعضی از سازمانها ممکن است این تیم بصورت رسمی وجود نداشته باشد اما در اکثر موارد، افرادی در سازمان هستند که اکثر زمانشان صرف نامه نگاری، تایید و انتشار نسخه های نرم افزاری می شود).عدم دسترسی به نرم افزار(توقف اجرای نرم افزار) در فرایند انتشار نسخه جدید، یکی از چالشهایی است که نه تنها تیم توسعه بلکه کاربران نرم افزار را به دلیل اینکه قادر به استفاده از نرم افزار در بازه زمانی خاصی نیستند درگیر خود می کند.تغییر موارد مربوط به پایگاه داده بعد از انتشار یک نسخه از نرم افزار و همچنین برگرداندن تغییرات در صورت وجود خطا یکی دیگر از چالشهایی می باشد که تیم های توسعه گاها با آن مواجهه می شوند. وجود چنین مشکلی با توجه به دستی بودن فرایند انتشار معمولا دور از انتظار نیست و برگردان تغییرات مربوط به نرم افزار، سرویس ها و پایگاه های داده به حالت قبل از شکست، یک معضل برای تیم توسعه می باشد که ممکن است با اعمال یک تغییر اشتباهی منجر به از دست دادن بخش وسیعی از اطلاعات موجود در پایگاه داده و یا ... شود که گاها هزینه های گزاف و جبران ناپذیری را برای سازمان به همراه دارد.بنابراین بصورت کلی سازمان با این مشکلات مواجهه است :توقف نرم افزار یا سرویس جهت انتشار نسخه جدیدمعطلی کاربران در صورت وجود مشکل در فرایند انتشار نرم افزاراحتمال به درستی انجام نشدن انتشار نسخه جدید و در نهایت وجود ناهماهنگی و باگ در نسخه مورد استفاده کاربرانتحویل کندتر ویژگی ها و تغییرات کاربران به جهت صرف زمان تیم توسعه بر روی مسائلی مربوط به تست و انتشارتخصیص زمان و افرادی درون تیم جهت انتشار نسخه های جدیداجرای اسکریپت ها اشتباه بر روی بانکهای اطلاعاتی به دلیل خطای انسانیفراموشی اعمال بعضی از موارد مربوط به پیکربندی جهت انتشار نسخه جدیدبه هم ریختن بعضی از وظایف زمانبندی شده در نرم افزارفرایندها، ابزارها و روشهای مورد استفادهبرای اعمال فرایندهای یکپارچه ­سازی کد، تست خودکار و انتشار خودکار نرم افزارها، از مفاهیم اصلی حوزه DevOps که اختصارا به آن CI/CD گفته می شود استفاده شده است. CI/CD مجموعه ای از مفاهیم، فرایندها و فعالیتهایی هستند که به واسطه آن، تیم های توسعه نرم افزاری سرعت، دقت و اطمینان بیشتری در توسعه و انتشار نرم افزار در سازمانها را خواهند داشت. هر کدام از این مفاهیم CI و CD بصورت جداگانه در قسمت بعد تشریح خواهد شد. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Tue, 20 Oct 2020 20:07:44 +0330 https://virgool.io/@KeivanDamirchi/%D8%A2%D9%BE%D8%A7%DA%86%DB%8C-%DA%A9%D8%A7%D9%81%DA%A9%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-xpuzmflovgxw شما در سیستم خود سرویسی دارید که نقش مبدا را بازی می کند و سرویس دیگری که نقش مقصد را بر عهده دارد و قصد دارید میان این دو سرویس داده های خود را رد و بدل کنید. در این سناریو ساده که فقط یک مبدا و مقصد وجود دارد، ابزارهای زیادی وجود دارند که به ما برای انجام کارمان کمک می کنند، اما اگر تعداد سرویس های مبدا و مقصد در سیستم نرم افزاری ما بیشتر شود میزان ارتباطات میان سرویسها نیز افزایش پیدا می کند.مثلا یک سیستم انبارگردانی را در نظر بگیرید که 5 سرویس نقش مبدا و 6 سرویس نقش مقصد را بازی می کنند، در این حالت ما 30 ارتباط میان سرویسهای خود خواهیم داشت که هر کدام از این ارتباط ها چالشهای مختلفی برای ما بوجود می آورند، از جمله :پروتکل های ارتباطی که برای انتقال داده میان این سرویسها استفاده می شود ممکن است برای هر کدام از آنها متفاوت باشد، مثلا یک سرویس از HTTP استفاده کند و سرویس دیگر از Rest و ....فرمت داده های هر کدام از این سرویس های مبدا یا مقصد ممکن است با سرویس طرف مقابل متفاوت باشد، مثلا یک سرویس ممکن است از فرمت Json و سرویس دیگر از فرمت XML و سرویس دیگر ... . هر کدام از سرویس ها در مبدا و مقصد باید داده های دریافتی را برای خواندن پردازش کنند.در فواصل زمانی مختلف و بنا بر تغییرات احتمالی که در سیستم شما بوجود می آید ممکن است ساختار داده های شما تغییر کند.در کنار موارد ذکر شده، ممکن است در سیستم های مقصد با افزایش بار و افزایش تعداد اتصالات (Connections) مواجهه شوید که به نوبه خود ممکن است دچار چالشهای جدی در آینده شوید.اینجاست که آپاچی کافکا به داد ما می رسد، با استفاده از کافکا تبادل اطلاعات میان سرویس ها به سادگی انجام خواهد شد، به این صورت که هر کدام از سرویس های مبدا یا مقصد از یک سو به کافکا متصل خواهند شد و عمل رد و بدل کردن داده ها را انجام میدهند. کافکا عملا یک سیستم انتقال پیام(شامل یک دستور یا ...) میان سیستم هاست، در بالا به نرم افزار انبارداری اشاره کردیم، تصور کنید که ما یک سرویس سفارش و یک سرویس کالا داریم و قصد داریم یک سفارش جدید در سیستم ثبت کنیم، ابتدا سرویس سفارش درخواستی مبنی بر ثبت سفارش جدید دریافت می کند و با ارسال یک پیام به سرویس کالا (که از طریق کافکا انجام می شود) اقدام به به‌روزرسانی موجودی کالای مورد استفاده در سفارش می کند.پلتفرمهای مختلفی برای انتقال و تبادل پیام بین سرویس ها وجود دارد، از جمله RabbitMQ، ActiveMQ، MSMQ که هر کدام دارای مزایایی هستند، چرا از کافکا استفاده کنیم؟یکی از مسائلی که در انتخاب یک تکنولوژی مطرح است، میزان استفاده آن تکنولوژی در شرکتها و نرم افزار های اصطلاحا مشهور است، مسئله مهم بعدی سازنده و بوجود آورنده آن تکنولوژی است که توسط کدام کمپانی ایجاد شده و نگهداری می شود. آپاچی کافکا توسط لینکداین بصورت Open Source ایجاد شده و در حال حاضر توسط شرکت Confluent نگهدای می شود، همچنین توسط شرکتهایی نظیر نت‌فلیکس، اوبر، والمارت، لینکداین استفاده می شود.معماری کافکا بصورت توزیع شده (Distributed) می باشد، بسیار انعطاف پذیر است (Resilient Architecture) و قابلیت یکپارچگی بالایی با دیگر سیستم ها دارد.این پلتفرم قابلیت مقیاس پذیری افقی را دارد(افزایش تعداد سیستم بجای افزایش توان سیستم). کلاسترهای کافکا قابل توسعه تا 100 Broker هستند. با استفاده از پیکربندی مناسب امکان انتقال میلیونها پیام در ثانیه را دارند.کافکا تاخیر در پاسخگویی در کمتر از 10 میلی ثانیه دارد که عموما به این نوع پاسخگویی Real Time گفته می شود(زمان پاسخگویی در لحظه).با ذکر موارد بالا متوجه اهمیت آپاچی کافکا شده ایم، سوال بعدی این است که در چه مواردی از آپاچی کافکا استفاده می کنیم؟مورد استفاده اصلی کافکا که عموما با آن شناخته می شود سیستم انتقال پیام میان سرویس هاست (Messaging System)، اما کافکا در موارد زیر نیز مورد استفاده قرار می گیرد :ردیاب فعالیت ها (Activity Tracking)جمع آوری Metrics از بخش ها مختلف سرویس ها (متریکها یا معیارها، اطلاعاتی عموما آماری از نرم افزارها هستند که بیانگر کارایی سیستم در پاسخگویی به یک درخواست یا ... می باشند، مانند زمان پاسخگویی برای دریافت لیستی از کارمندان از سرویس مربوط به کارمندان).جمع آوری لاگ از سرویس هاپردازش جریان داده (Stream Processing)، با توجه به زمان پاسخگویی بالای کافکا؛ این پلتفرم قابلیت آن را دارد که در سیستم هایی که جریان اطلاعات بصورت پیوسته وجود دارد مورد استفاده قرار گیرد(مثالی از این مورد می تواند سنسورهای مربوط به چک کردن دما یک محیط باشد که پیوسته در حال دریافت اطلاعات دما و ارسال آن به یک سرویس یا ...است).همانطور که ذکر شد، اصلی ترین کار کافکا که بصورت یک تعریف کلی که بواسطه آن شناخته می شود این است که کافکا یک مکانیزم نقل و انتقال پیام از یک سیستم(ممکن است یک سرویس، پایگاه داده، ...) به یک سیستم دیگر است.ما اشاره کردیم که شرکتهای معروفی از کافکا برای توسعه و بهتر کردن کارکرد نرم افزارهای خود استفاده می کنند، در زیر نمونه هایی از این شرکتها به همراه موارد استفاده آن بیان شده است:نت‌فلیکس از کافکا در سیستمهای توصیه گر خود استفاده می کند، به این شکل که زمانیکه شما در نت‌فلیکس مشغول تماشای یک ویدیو هستید، در فواصل زمانی مختلف مشاهده می کنید که نت‌فلیکس ویدیوهای متنوعی به شما پیشنهاد می کند.(از طریق پردازش کنشهای شما در وبسایت نت‌فلیکس، مثلا بر روی چه ویدیوهایی کلیک میکنید و یا چه ویدیویی را بیشتر تماشا میکنید؛ همه این کنش ها در لحظه پردازش و تحلیل می شوند و ویدیو مناسبی به ازای آن به شما پیشنهاد می شود).اوبر از کافکا برای جمع آوری اطلاعات کاربران، تاکسی ها و سفرها بصورت Real Time برای محاسبه و پیش بینی تقاضا و همچنین پیش بینی هزینه ها استفاده می کند(مهمترین سرویس های اوبر از کافکا برای تبادل پیام استفاده می کند). لینکداین برای جلوگیری از هرزنامه ها، گردآوری کنشهای کاربر برای پیشنهاد کانکشن ها(افرادی که از چند لحاظ نزدیکی بیشتری به کاربر دارند) بصورت Real Time استفاده می کند.همانگونه که گفته شد شرکتهای مطرحی از کافکا در بخش های مختلفی مانند توصیه های در لحظه، تصمیم گیری های در لحظه برای بهتر کردن سرویس خود استفاده می کنند.در قسمت های بعد سعی می شود بصورت جزئی تری با کافکا آشنا شویم و بصورت مفصل تری به تشریح امکانات و موارد استفاده از این پلتفرم می پردازیم، همچنین یک نرم افزار ساده را در ASP.Net Core با آپاچی کافکا پیاده سازی خواهیم کرد.منابع : وبسایت آپاچی کافکالینکداین کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Sun, 03 May 2020 20:59:37 +0430 https://virgool.io/@KeivanDamirchi/%D8%A7%DB%8C%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-%D8%B4%DB%8C%D9%BE%D9%88%D8%B1%DB%8C-aojf9ulylkie برنامه نویس نیستید اگه هر از چند گاهی یکی از دوستان یا آشنایان به شما زنگ نزنند و از ایده ی فوق العادشون که اتفاقا یکم شبیه فلان استارت آپ فعلی هست صحبت نکنند. حداقل برای خود من در یک سال گذشته تقریبا پنج یا شش بار اتفاق افتاده. معمولا با هیجان و حرارت خاصی از ایدشون حرف میزنند که انگار ایدشون قراره بشریتو نجات بده. وقتی یک مقدار بیشتر صحبت میکنید متوجه میشید که قصد دارند علاوه بر کپی یک سری از ویژگی های استارت آپ X، یک سری ویژگی های دیگه از استارات آپ Y و Z هم تو ایدشون داشته باشن. عموما هم از فضای استارات آپ و آی تی اطلاعی ندارند. تا اینجای کار ایراد چندانی بهشون نیست و صرفا یه چیزی به ذهنشون رسیده و میخوان پیاده سازی کنند، اما کار از اونجا جالب میشه که ازتون هزینه انجام کارو میپرسند. خب شما اینجا مجبورید یه توضیح اولیه ای درباره ی فضای استارات آپ و آی تی بهشون بدید و بر اساس گفته هاشون بیاید قسمت های مختلف نرم افزار مد نظرشونو جدا کنید و بگید مثلا این کار از 8 قسمت مختلف تشکیل شده و حدودا چهار ماه زمان میبره و برای تعیین دقیق زمان و هزینه نیاز به وقت بیشتری دارید، که دوباره دوست عزیز اصرار داره هزینه حدودی رو بدونه( تقریبا در تمام موارد برای من به این صورت پیش اومده) و شما یه رنج مبلغی از فلان تا فلان رو بهش پیشنهاد میدید.در این مرحله چشم های دوست عزیزتون یکم از تعجب گرد میشه و یه جوری واکنش نشون میده که انگار قیمت ساخت بویینگ 747 رو شنیده و شروع میکنه به صحبت کردن درباره اینکه برای این کار مثلا 2 میلیون در نظر داشت و یه مبلغیو هم برای تبلغات کنار گذاشته بوده و فوقش بتونه 4 میلیون بابتش بپردازه! و در کنارش علت این قیمتِ به اصطلاح بالای شمارو جویا میشه، شما بازم مجبورید شرح بدید براش که با توجه به زمان و سختی کار و تجربه ای که دارید حتی این قیمت هم براتون به صرفه نیست و صرفا به دلیل آشنایی با اون این قیمتو پیشنهاد دادین. از این به بعدش چندتا سناریو مختلف ممکنه پیش بیاد:اون دوستتون دست از سرتون بر نمیداره و کلافتون میکنه و ازتون میخواد با قیمت کمتری کارو قبول کنید( در حد همون چیزی که خودش پیشنهاد داد!).میره سراغ یکی از این شرکتهایی که یکم زرق و برق دارند و اونا میبرنش تو اتاق مدیر و راضیش می کنند هزینه ای به مراتب بیشتر از شما ازش بگیرن، اغلبشون هم سعی در تخریب گفته های شما پیش اون دوستتون دارند.( اکثر این شرکتها یه چیزی مشابه ای مثل ایده مشتریو از قبل پیاده سازی کرده اند و یه نمونه به مشتری نشون میدن، بعدش با تغییر همون کار قبلی، به مشتری تحویل میدن).سناریو آخر هم اینه که بالاخره این دوست عزیزتون بیخیال میشه و هم شما راحت میشید و هم خودش.خب بدی این داستان اینه که وقت و انرژی شما بصورت بیهوده ای صرف کاری میشه که براتون فایده ای نداره و شما مجبور میشید کلی انرژی برای یه نفر صرف کنید که اونو به فضای آی تی آشنا کنید و در کنارش بیاید ایده ای که خودش پیشنهاد داده رو براش تشریح کنید. کاری که شما در این موارد میتونید انجام بدید اینه که بهتره اول ببینید طرفتوتون چقدر از فضای آی تی آشنایی داره، اگه یه دید کلی خوبی نسبت به این فضا داشت و آشناییش قابل قبول بود میتونید امیدوار باشید که حداقل وقت و انرژیتون بی فایده به هدر نمیره، اگه هم آشنایی نداشت در مرحله اول میتونید به بهونه اینکه وقتتونو میخواید صرف کار دیگه ای بکنید و یا ... حداقل از سر خودتون بازش کنید و یه درگیری چند روزه براتون بوجود نیاد. امیدوارم فردا کسی براتون زنگ نزنه و نگه یه چیز مثل شیپور میخواد :) کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Fri, 01 May 2020 16:56:58 +0430 https://virgool.io/@KeivanDamirchi/%DA%A9%D8%AA%D8%A7%D8%A8%D8%AE%D8%A7%D9%86%D9%87-restease-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-typesafe-%D8%A8%D8%A7-api-ztajkjvsk4yp ممکن است پروژه ای که بر روی آن کار میکنیم با استفاده از معماری میکروسرویس باشد، یا نرم افزار های خود را بصورت چند سرویس Monolith بصورت جدا از هم طراحی کرده باشیم و یا قصد داشته باشیم در نرم افزار خود از API سرویس های دیگر استفاده کنیم، در این حالت برنامه نویسان در سی شارپ معمولا از کلاس HttpClient بصورت مستقیم و یا با قرار دادن یک کلاس Wrapper روی این کلاس عملیات مربوط به رد و بدل کردن اطلاعات به سرویس های دیگر را انجام می دهند. در حالت استفاده از Wrapper بر روی HttpClient اغلب ما اینترفیس ها و کلاس های ساده ای درست میکنیم که کار خاصی بجز ارسال درخواست و دریافت پاسخ و Map کردن آن به کلاس مورد نظر ما، کار خاصی انجام نمی دهند. این کلاس ها اغلب بصورت سرسام آوری با اضافه شدن سرویس های خارجی در پروژه ی ما ایجاد می شوند. بطور مثال سرویسی داریم که اطلاعات مربوط به کالاهای یک فروشگاه را به ما می دهد و با استفاده از آن اطلاعات و ایجاد یک پروژه ASP .NET MVC MVC اطلاعات آن را به کاربر نمایش میدهیم. در مرحله اول یک Controller ایجاد میکنیم، در اکثر مواقع سعی میکنیم فراخوانی های مربوط به سرویس های خارجی را در یک کلاس دیگر انجام دهیم و نتیجه آن را در اختیار کنترلر قرار دهیم. اینجاست که سر و کله کلاس های ساده ای که فقط کارشان ارتباط با سرویسهای خارجی است پیدا می شوند. RestEast اما با ایجاد یک Interface ساده و پیاده سازی این اینترفیسها بصورت درونی، مشکل تولید کلاسهای اضافی را حل می کنید. نحوه استفاده از این کتابخانه کوچک به این صورت است که ابتدا ما یک اینترفیس تعریف میکنیم و تعاریف متدهایی که قرار است با سرویس های خارجی ارتباط برقرار کنند را در آن قرار میدهیم. در تصاویر زیر مراحل استفاده از RestEast پیاده سازی شده است. فرض شده که ما بنا داریم سرویسی ارائه دهیم که خدمات تاکسی آنلاین و پیک موتوری ارائه میدهد.ساختار Solution یک Solution به همراه سه Project از نوع Web Api ایجاد شده است که پروژه TakC.Api کار Endpoint نهایی ما را انجام میدهد و به نوعی Api Gateway هم هست. TakC.Services.BikeDelivery سرویس مربوط به پیک موتوری می باشد و در نهایت TakC.Services.Taxis سرویس تاکسیهاست. پروژه TakC.Api ارائه دهنده نهایی سرویس ها به کلاینت ها می باشد. TakC.Services.Taxis کنترلر مربوط به سرویس اکشن Get صرفا یک اکشن ساده است که آرایه ای از داده های استاتیک مدل تاکسی بر میگرداند. برای استفاده از این سرویس در TakC.Api ابتدا یک اینترفیس به نام ITaxisService ایجاد میکنیم.ITaxisService اینترفیسهمانطور که میبینیم، این اینترفیس شامل تعریف یک متد با نام BrowseAsync می باشد که لیستی از تاکسی ها را بر میگرداند. صفت Get در اینجا کار آدرس دهی را انجام میدهد و صفت AllowAnyStatusCode این اجازه را به متد تعریف شده می دهد که هر Status Code را برگرداند و صفت SerializationMethods بیانگر Serialized کردن پارامترهای ارسالی می باشد.در نهایت در کنترلر TransportationController از سرویس ITaxisService استفاده میکنیم و در اکشن GetTaxis آن را فراخوانی میکنیم. در Startup پروژه TakC.Api عمل شناساندن ITaxisService را انجام میدهیم. در اینجا ما از یک Extension Method به نام RegisterServiceForwarder استفاده کردیم که با خواندن فایل appsettings.json که به صورت زیر می باشد اقدام به Map کردن آدرس، محل و نام سرویس ها می کند.( برای آشنایی به نحوه کارکرد متد RegisterServiceForwarder به Github پروژه مراجعه کنید.)همانطور که اشاره شد، با استفاده از RestEast و تنها با تعریف یک اینترفیس ساده به ازای هر سرویس، از تعریف کلاس های اضافی که کار خاصی بجز فراخوانی سرویس ها را انجام نمی دهند جلوگیری کردیم. در واقع RestEast عمل پیاده سازی این سرویسها را بصورت توکار برای ما انجام میدهد. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Tue, 21 Apr 2020 00:39:40 +0430 https://virgool.io/@KeivanDamirchi/in-memory-caching-i9xx0nsihog7 عموما مکانیزم کشینگ این امکان را به ما میدهد که منابع کمتری را بکار ببریم. جلوگیری از لود کردن دوباره یک فایل (مثلا ذخیره یک CSS Style یا یک فایل جاوا اسکریپت در مرورگر) یا ذخیره Response یک Action با استفاده از Response Caching، یا ذخیره یک شی در حافظه موقت با استفاده از In-Memory Cache که موضوع این پست می باشد (نوع دیگری از کشینگ اصطلاحا با Distributed Caching شناخته میشود که موضوع بحث ما نیست). In-Memory Caching ساده ترین نوع کش کردن می باشد که به سادگی در ASP.NET Core قابل پیاده سازی می باشد. این نوع کشینگ معمولا زمانی استفاده می شود که نرم افزار ما بر روی یک سرور قرار دارد و اصلاحا توزیع شده نیست( در صورتی که نرم افزار ما بر روی چند سرور قرار گرفته باشد و همچنان قصد استفاده از این In-Memory Caching را داشته باشیم، Request های مختلف برای استفاده از اطلاعات موجود در کش باید به سروری هدایت شوند که کشینگ در آن اعمال می شود). با استفاده از In-Memory Caching میتوانیم انواع مختلف داده ها را بدون مشکل در حافظه نگهداری کنیم. برای مثال داده ما میتواند یک string ساده یا یک لیست از اطلاعات کارمندان باشد. یک سری قوانین در پیاده سازی و استفاده از مکانیزنم کشینگ وجود دارد که باید رعایت شود :کدهای نوشته شده برای دستیابی به اطلاعات کش همیشه باید یک راه جبران در صورت نبود اطلاعات در حافظه کش داشته باشند. مثلا هنگامی که ما یک لیستی از کالاها را در حافظه کش ذخیره کردیم و در زمان واکشی آن اطلاعات ذخیره شده وجود نداشت ( مثلا منقضی شدن مدت زمان نگهداری اطلاعات)، قطعه کد شما باید راهی برای دوباره بارگیری کردن لیست کارمندان داشته باشد.حتما در هنگام ذخیره/بازیابی اطلاعات کش، از یک کلید معتبر داخلی; مثلا نام کلاس+شناسه یا یک عبارت منحصر به فرد مربوط به داده مورد نظر استفاده کنید تا تداخلی بین داده های مختلف بوجود نیاد. بطور مثال اگر برای ذخیره نام یک دانشجو تنها از شناسه آن که مثلا 1 است استفاده کنید و برای ذخیره یک درس هم از شناسه آن درس که اتفاقا آن هم 1 می باشد استفاده کنید، در هنگام بازیابی با اطلاعات معتبری مواجه نمی شوید، چون ممکن است اطلاعات مربوط به درس با شناسه 1 بر روی اطلاعات دانشجو بازنویسی شده باشد.استفاده از یک زمان انقضای مشخص شده برای هر داده ضروری می باشد، چرا که ما از یک منبع محدود که حافظه موقت است استفاده میکنم و ممکن است در صورت لحاظ نکردن زمان انقضا مربوط به داده با درگیر کردن بخش زیادی از حافظه موقت به کمبود منبع حافظه مواجهه شویم.( در نظر داشته باشید که ASP.NET Core محدودیتی برای ذخیره داده در In-Memory Cache در نظر نمی گیرد.)بعضی از توسعه دهندگان از هاست های اشتراکی برای انتشار نرم افزار خود استفاده می کنند که در این صورت به دلیل کمبود منابع حافظه (در اختیار داشتن مقدار بسیار کمی از منبع حافظه موقت) باید دقت بیشتری در کش کردن اطلاعات لحاظ کنند و حدالامکان از کشینگ برای اطلاعات ضروری با بازه زمانی محدودتر استفاده کنند. نحوه استفاده از کشینگ حافظه موقت :در کلاس Startup و در متد ConfigureServices متد زیر را برای فعال کردن کشینگ فراخوانی میکنیم : services.AddMemoryCache ();و در قسمتی که قصد استفاده از کشینگ را داریم، عمل تزریق ImemoryCache را به Constructor انجام میدهیم، در اینجا ما در یک کنترلر به نام InfoController قصد استفاده از کشینگ را داریم : private readonly IMemoryCache _memoryCache;public InfoController (IMemoryCache memoryCache) {_memoryCache = memoryCache;}در متد/اکشن مورد نظر، بعد از تعریف یک کلید بعنوان کلید دستیابی به کش، بررسی میکنیم که در صورت خالی بودن کش، اطلاعات مورد نظر از منبع مناسب واکشی شود و در کش قرار گیرد، متغیر expirationOptions حاوی تنظمات مربوط به مدت زمان غیر فعال بودن مقدار کش شده، الویت و مدت زمان قطعی نگهداری داده کش شده است :[HttpGet]public string GetInfo () {var key = &quotinfo1&quot if (!_memoryCache.TryGetValue (key, out string info)) { info = getInformation (); var expirationOptions = new MemoryCacheEntryOptions { SlidingExpiration = TimeSpan.FromMinutes (2), Priority = CacheItemPriority.Normal, AbsoluteExpiration = DateTime.Now.AddMinutes (50)};_memoryCache.Set (key, info, expirationOptions);}return info;}نکات حائض اهمیت برای تنظیمات یک شی کش شده که در متغیر expirationOptions تعیین شده بصورت زیر است :SlidingExpiration : تعیین کننده این می باشد که یک مقدار کش شده در صورت استفاده نشدن تا چه زمانی میتواند غیر فعال شود. مثلا در مورد بالا مقدار 2 دقیقه برای این فیلد در نظر گرفته شده که یعنی اگر در مدت زمان 2 دقیقه ، این مقدار کش شده مورد استفاده قرار نگیرد، اطلاعات کش شده از بین خواهد رفت. این مقدار از مقدار زمان منقصی قطعی(فیلد پایینی) فراتر نخواهد رفتAbsoluteExpiration : زمان منقضی شدن قطعی یک مقدار کش شدهPriority : میزان اهمیت مقدار کش شده، در صورت نیاز به پاکسازی حافظه این متغییر تعیین کننده اهمیت نگهداری یه مقدار کش شده استو متد private زیر به اصطلاح یک منبع داده می باشد( در حالتهای واقعی تر این منبع می تواند یک دیتابیس یا یک سرویس خارجی باشد) :private string getInformation () {return $&quotthis is a sample text. generated at : {DateTime.Now.ToLongTimeString()}&quot}یک نمونه ساده از نحوه استفاده از In-Memory Caching در github کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Thu, 16 Apr 2020 00:31:20 +0430 https://virgool.io/@KeivanDamirchi/refactoring-when-to-refactor-cjixsnvnoeea در قسمت قبل درباره بدهی فنی (Technical debt) صحبت کردیم، اینکه بدهی فنی چه زمانی بوجود می آید و دلایل بوجود آمدنش چیست. حال میخواهیم بدانیم چه زمانی کدهای نوشته شده را ریفکتور (Refactor) کنیم، فرض کنید که متوجه شده ایم که بعضی از قطعات کد را بد نوشته ایم، اما چه زمانی باید کدهای بد را ریفکتور کنیم؟وقتی یک ویژگی (Feature) جدید به نرم افزار اضافه می کنیمممکن است بخشی از یک کدی که قبلا نوشته شده به شما داده شود، اگر کدی که مشغول به توسعه (Develop) آن هستید خیلی درهم و کثیف باشد، اولین کاری که باید انجام دهید ریفکتور کردن کدهای نوشته شده است، بعد از تمیز کردن کدهای نوشته شده میتوانید مشغول به توسعه آن شوید. کد تمیز آسانتر درک می شود، بعد از ریفکتور کردن کد نوشته شده، بخاطر داشته باشید که علاوه بر راحتی که خود شما درهنگام توسعه کد دارید، نفر بعدی که وظیفه توسعه این کد را دارد احساس بهتری خواهد داشت.وقتی باگی (Bug) را در سیستم برطرف کنیمرفتار یک باگ مانند یک میکروب است، در کثیف ترین و تاریکترین قسمت کدهای ما زندگی می کنند، احتمال اینکه در هنگام ریفکتور با آنها مواجهه شوید خیلی زیاد است، ریفکتور درهنگام رفع باگ یک حرکت با دو امتیاز است؛ علاوه بر اینکه باگی در سیستم بر طرف می شود، کدهای بررسی شده، ریفکتور می شوند و دیگر نیازی به اختصاص زمان جداگانه برای ریفکتور بخش مربوطه در نظر گرفته نمی شود.وقتی Code Review می کنیمزمان بازنگری کد، آخرین شانس شما برای ریفکتور کردن کد می باشد، ممکن است بعد از اتمام یک قسمت از کدتان، زمانی برای بازنگری کدهای نوشته شده در نظر بگیرید، این زمان هم میتواند وقت خوبی برای ریفکتور کردن بخشی که مورد بازنگری قرار گرفته باشد.نکته : اگر از سیستم های Source Control استفاده میکنید، قبل از Mergeکردن Branch زمان مناسبی برای ریفکتور کردن می باشد.اصل کلی در ریفکتورینگریفکتورینگ باید در یک سری از تغییرات کوچک و متوالی اتفاق بیفتد، توجه کنید که این تغییرات کوچک نباید در روند اجرایی نرم افزار تاثیر بگذارند، ممکن است ریفکتورینگ Performanceبعضی از بخش ها را دستکاری کند، اما نباید موجب بوجود آمدن Functionalityجدید در سیستم شود، هدف اصلی ریفکتورینگ تمیز کردن و خواناتر کردن کد می باشد.نکته : اگر درهنگام ریفکتورینگ، متوجه شدید که با تغییر یک قسمت از کد میتوانید ویژگی جدید به نرم افزار اضافه کنید، این مورد را در جایی ثبت کنید و در زمان دیگر و در یک Branchجداگانه تغییرات مربوطه را اعمال کنید. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Sat, 28 Apr 2018 18:09:57 +0430 https://virgool.io/Software/refactoring-technical-debt-%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-l9cuwhevwa8e در بخش اول به بدهی فنی اشاره مختصری شد؛ از آنجایی که علت ریفکتورینگ عموما بدهی فنی می باشد پس نیاز داریم به مفهوم بدهی فنی بیشتر بپردازیم. احتمالا با مثال جناب مارتین فالور درباره "وام گرفتن و پرداخت سود اضافه به ازای دیرکرد پرداخت قسط" دید کلی نسبت به بدهی فنی پیدا کردید، در ادامه توضیح بیشتری خواهیم داد.بدهی فنی دقیقا چه زمانی و چرا بوجود می آید؟عموما توسعه دهندگان از اینکه یک پروژه را خودشان از صفر ایجاد کنند لذت بیشتری می برند، و معمولا در اوایل توسعه پروژه حس بهتری دارند، احتمالا هیچ برنامه نویسی عامدانه کد شلوغ و بد نمی نویسد ولی کدهای بد، که بعد چند ماه در پروژه وجود دارد از کجا آمده است؟ احتمالا شخصی با ما دشمنی داشته و کدهای ما را شلوغ و درهم کرده!!بدهی فنی یک شکل محترمانه از "کد کثیف و ناخواناست" که توسط آقای Ward Cunningham در یکی از مقالاتش اشاره شده است. (آقای Cunningham یکی از مهندسین نرم افزارمطرح دنیاست و از بوجود آورندگان مفاهیم مرتبط با دیزاین پترن می باشد). سوال اصلی این است که چرت بدهی فنی بوجود می آید؟ علت اصلی آن چیست؟فشار کاریبعض اوقات(اکثر اوقات) شرکت ها وقت زیادی برای تحویل پروژه را ندارند، بطور مثال پروژه باید تا ماه آینده تکمیل شود و عموما چیز زیادی قرار نیست به پروژه اضافه شود (البته از دید مشتریان و مدیران پروژه)، احتمالا فقط نیاز به طراحی چند فرم کوچک است،همین! اما غافل از اینکه همین فرمهای کوچک ممکن است بصورت زنجیره وار در کل سیستم تاثیر بگذراد(خطاهای زنجیره وارهم بیشتر زمانی اتفاق میفتد که کل سیستم ما در یک سولوشن/پکیج باشد، وقتی نرم افزار به سرویس های مختلف تقسیم نمی شود و از لحاظ business جدا سازی نمی شود، این قشیه بیشتر خود را نشان می دهد. یک مثال از این قشیه میتواند یک وب اپ مدیریت فروشگاه باشد؛ اگر بخش پرداخت و بخش کالا و لاگ سیستم از هم جدا شوند، در این حالت اگه یم بخش، مثلا پرداخت دچار اشکال شود یا حتی اگر این بخش down شود، افرادی که "فقط" قصد دیدن کالا را دارند با مشکل خاصی مواجه نمی شوند و تنها زمانی بحث خرید و پرداخت مطرح می شود ممکن اسن برنامه پاسخ مناسی ندهد.فقدان تستبدهی فنی میتواند شامل عدم وجود تست یا نبود تست خوب هم باشد؛ وقنی مجبورید یک بخش را سریع جمع بندی کنید، بعد توسعه آن احتمالا برای آن تستی نمی نویسید یا تست های محدودی می نویسید که عملا بی فایده هستند. نوشتن تست معمولا باعث می شود که کدهایی که نوشته می شود و یا کدهایی که در آینده به پروژه اضافه می شود با خطای کمتری مواجه شوند.فقدان داکیومنتاین مورد کاملا بدهی است، وقتی شما وقت نوشتن کد تمیز را ندارید، قطعا وقت نوشتن داکیومنت را هم ندارید. در این صورت اگر در تیمی کار می کنید و یکی از اعضای تیم قصد ترک کردن تیم را داشته باشد، اسپاگتی کدی را تجویل می گیرید کسی توانایی درک آن را ندارد.فاصله ی زمانی زیاد بین merge کردن branch هااین یک مورد جدی و تقریبا خطرناک می باشد، وقتی branch ها دیر به دیر merge می شوند باعث به وجود آمدن conflict های زیادی در پروژه می شود و این خود یک نوع بدهی فنی خواهد بود که ممکن است بسیاری از توسعه دهندگان را به دردسر بیندازد.فاجعه ی Copy & Pastزمانی که یه تکه کدی را از پروژه دیگری کپی می کنید، یا همکارتان قطعه کدی به شما می دهد تا از آن برای رفع نیاز خود استفاده کنید؛ ممکن است آن قطعه کد نیاز شما را برطرف کند، ام اگر ندانید چه اتفاقی در اجرای آن قطعه کد می افتد واقع آن قطعه کد را درک نکنید، نتیجه آن با گذشت زمان این خواهید شد که امکان توسعه آن قسمت از برنامه بسیار سخت خواهد شد و در نهایت سودی که از کپی و پیست کد بدست آوردید را احتمالا با صرف زمان چند برابر برای توسعه و تغییر آن باید پرداخت کنید.عدم صلاحیت برنامه نویس(دانش ناکافی)برنامه نویسی که تازه از دانشگاه فارغ التحصیل شده و یا شخصی که تازه وارد حیطه برنامه نویسی شده، عموما دانش عمیقی از توسعه کد تمیز ندارد و احتمالا سعی می کند کدی را بنویسید که صرفا "کار" می کند. در این صورت به پروژه کدی اضافه می شود که اگر چه نیاز مورد نظر را بر طرف می کند، اما به دلیل دانش ناکافی توسعه دهنده ممکن است کثیف و ناخوانا باشد و توسعه آن در آینده با مشکل مواجه شود.موارد ذکر شده،مواردی بودند که باعث بوجود آمدن بدهی فنی می شوند، کپی/پیست قطعه کدی که کار می کند ممکن است چیز لذت بخشی باشد، یا اینکه ممکن است با صرف نکردن زمان برای نوشتن داکیومنت، حس بهتری داشته باشید و حتی ممکن است از یک نظر مثبت هم باشد(وقت بیشتری برای توسعه کد صرف شود) اما عواقب موارد مطرح شده ممکن است باعث شکست پروژه ی نرم افزاری شما شود.برای مطالعه قسمت سوم اینجا کلیک کنید. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Wed, 25 Apr 2018 17:21:35 +0430 https://virgool.io/Software/refactoring-1-j4ntmwedkvhd شما قصد دارید یک بخش جدید(مانند : ویژگی، کد، متد،...) به پروژه ی خوداضافه کنید؛ دو راه در پیش روی خود دارید، روش اول این است که خیلی سریع قطعات کد کثیف و درهمی بنویسید که حتما از دردسرهای مربوط به توسعه و تغییر آن در آینده آگاه هستید. روش دوم این است که با صرف زمان بیشتر و نوشتن کد تمیز و قابل فهم از فواید آن در حین توسعه برای خود و همکارانتا سود ببرید. شرکتی را در نظر بگیرید که در آن یک نرم افزار آرشیو اسناد پزشکی در حال توسعه است که با استفاده از آن اسناد و پرونده های بیماران را اسکن می کنند، تقریبا دو ماه از استارت پروژه گذشته است و شما به تیم توسعه پروژه اضافه شدید، تقاضای اضافه کردن ویژگی به نرم افزار از طرف مشتری بسیار بالاست و هر از چندگاهی چند باگ گزارش می شود که تیم توسعه مجبور به رفع آن است، به دلیل فشار کاری و کمبود زمان مجبورهستید مقداری سریع تر بخش های جدید را توسعه دهید و متعاقبا کدهای کثیف تری خواهید داشت و حتی فرصت نوشتن داکیومنت منانسب را هم ندارید؛ نداشتن تست، داکیومنت خوب و قابل فهم و از همه مهمتر توسعه نرم افزار به این شکل بعد از مدتی میتواند برای پروژه های نرم افزاری فاجعه بار باشد، و توسعه دهندگان جدید جرات دست زدن به کدهای نوشته شده را نداشته باشند، حتی ممکن است توسعه دهندگانی که خودشان کد را نوشته اند با ناراحتی سراغ توسعه یا تغییر پروژه بروند. در این سری نوشته های مرتبط با ریفکتوریگ قصد داریم به این موضوع بپردازیم.کد تمیزهدف اصلی ریفکتورینگ مبازه با بدهی فنی است، که در نهایت کدهای درهم و کثیف را تبدیل به کدهای تمیز و ساده و قابل فهم میکند، اما بدهی فنی چیست؟مارتین فالور در وبلاگ خود می گوید: بدهی فنی مانند بدهی مالی می باشد، دقیقا مانند بدهی مالی وقتی شما پولی که وام گرفته اید را به موقع پرداخت نکنید مجبور به پرداخت سود اضافه به ازای دیرکردتان خواهید شد، در واقع شما جریمه می شوید، که اگه بخواهیم به برنامه نویسی تشبیه اش کنیم؛ همان تلاش های اضافی می باشد که بعدها برای توسعه کدِ نوشته شده می کنیم؛ چون ما قبلا کدی نوشته ایم که خیلی کثیف بوده و درواقع کمبود تمیزی داشته است، راه حل هایی که پیش روی ماست این است که میتوانیم درگیر تلاش ها و کار کردن های اضافی شویم و همچنان به کد نویسی سریع و کثیف ادامه دهیم و برای توسعه آن مجبور به صرف هزینه های اضافی شویم و یا اینکه با حفظ یک سری اصول و قواعد، کدهای جدیدتر را به گونه ای بنویسیم که تمیزتر باشد و با استفاده از همین قواعد کدهایی که قبلا نوشته شده را بهتر کنیم،هرقد ما کدهای تمیزتری بنویسیم، جریمه ای که بعدا برای توسعه آن پرداخت میکنیم کمتر خواهد بود.احتمالا با توضیحات بالا قانع شدید که تمیزتر کد بنویسیم، اما یه کد خوب و تمیز چه ویژگی هایی دارد؟1- کد تمیز برای توسعه دهندگان جدیدی که به تیم اضافه می شوند کاملا واضح و خواناستالبته منظور از کد، الگوریتم های پیچیده نیست! نام گذاریِ بد متیغیرها و کلاسها، نوشتن کلاسها و متدهای بزرگ و اصلاحا باد کرده، استفاده از مقادیر عددی و رشته ایِ hard code شده که فقط برای برنامه نویسی که آنها را قابل فهم است و ... همه ی این موارد باعث می شود کدهای ما عجیب و غیرقابل فهم برای دیگران به نظر برسد لبته شاید غیر قابل فهم برای خود توسعه دهنده بعد از گذشت زمان مانند شش ماه بعد از ونوشته شدن!2 – کدهایی که تمیز نوشته شده اند بلاک، متد، و کلاسی با کد تکراری ندارنداگر شما در پروژه خود کدی داشته باشید که یک کار را انجام می دهد اما در دو یا چندجای مختلف تکرار شده است، باید گفت که مسیر بدی را رفته اید، فرض کنید سه متد دارید که نیاز به تبدیل dto یا view model به entity دارند؛ اگه شما این کار را در هر متد و بصورت جداگانه map کنید، با اضافه یا کم کردن یک property جدید باید هر سه متد را تغییر دهید، حالا موردی شبیه به این مورد را در ابعاد بزرگتر تصور کنید ، مثلا در حد بیست entity و سی dto که احتملا ممکن است با شصد یا هفتاد مدل map شوند، تغییر هر کدام از این متدها کاری تکراری و طاقت فرساست که در نهایت منجر به خستگیه مفرط برای توسعه دهنده می شود؛ حداقل برای نویسنده این پست که کاملا اینطور بوده.3 – کدهای تمیز اغلب کم حجم هستندمتدها و کلاسهای کوچک تر فضای کمتری را از ذهن توسعه دهنده اشغال می کنند؛ کد کمتر، نگهداری کمتری را می طلبد؛ کد کمتر، باگهای کمتری را ممکن است بوجود بیاورد و در نهایت توسعه آن راحت تر است. سعی کنید تا حد امکان کدهایخود را به بخش های کوچیک تری تقسیم کنید، یک پیشنهاد این است که اجازه ندهیم تعداد خطوط متدها بیشتر از 30 خط شوند(بدون در نظر گرفتن خطوط خالی و کامنت های میان کدها) و همچنین نگذاریم تعداد کلاس هایمان بیشتر از 30 متد در خود داشته باشند و در نهایت تعداد خطوط کدهای یک کلاس بشتر از 900 خط نشوند.هر package یا dll بیشتر از 30 کلاس نداشته باشند و یک سری قواعد دیگر که در آینده به آن اشاره خواهد شد.برای مطالعه قسمت دوم اینجا کلیک کنید. کیوان دمیرچی - Keivan Damirchi کیوان دمیرچی - Keivan Damirchi Mon, 23 Apr 2018 18:30:30 +0430