توی شماره‌ی 1 تیتر مسئله رو بزنید.
توی شماره‌ی 2 با توجه به توضیحات می‌تونید قالب رو رعایت کنید و توضیحات مسئله رو بیان کنید.
توی شماره‌ی 3 در صورتی که دسترسی‌های لازم رو داشته باشید می‌تونید مشکل رو به یک شخص برای انجام Asign کنید یا برچسب های مورد نظر برای باگ و فیچر و ... رو بزنید.
و بعد از اینکه کارتون تموم شد روی دکمه‌ی submit new issue در مرحله‌ی 4 کلیک کنید.
مسئله‌ی شما ثبت میشه، شما یک contribution دریافت می‌کنید و مسئله میره تا توسط ادمین‌ها بررسی و توسعه داده بشه.

چون بچه‌ها خیلی زودتر از موعدی که انتظار داشتم وارد پروژه‌ی FileManager شدن من یه توضیحاتی در مورد این پروژه بدم و اینکه قراره چه نیازی رو از ما برطرف کنه تا بقیه‌ی دوستان هم جوین شن.

هدف این پروژه اینه که بتونه کار با فایل و فولدر رو برای شما آسون کنه.
چالش های پیش رو چیا هستن؟
1.مهمترین چالش سیستم عامل های مختلف هستند، برای مثال سیستم عامل ویندوز توی حالت عادی (غیر UWP) برای کار با پوشه و فایل از نرم افزار دسترسی نمیگیره ولی توی سیستم عامل های گوشی به این شکل نیست بلکه نیاز به دسترسی کاربر هست برای همین براحتی نمیتونید از Api های ساخت فایل و پوشه مثل همیشه استفاده کنید.
2.چالش بعدی عدم یکپارچگی مدیریت فایل ها بین دیسک و مموری و Api ها و سایت های مدیریت فایل هست. برای مثال Azure و Amazon و ... از نمونه سایت هایی هستند که به شما این امکان رو میدن که بتونید مدیریت فایل رو در بستر cload یا هاست اونها انجام بدید ولی ما میخوایم طوری FileManager رو پیاده سازی کنیم که کسی که میخواد از Api های مدیریت فایل هم استفاده کنه نیاز نباشه تا دانش زیادی از اون api ها بدونه و بره کلی مطالعه کنه که بفهمه مثلا برای ساخت فایل توی Amazon S3 باید چه api ای رو صدا بزنه (در حد همون secret هاش بدونه کافیه). ما این بستر رو براش فراهم میکنیم و مثل همیشه یک Interface برای انجام اینکار براش کافیه.
3.تست پذیر بودن این نوع پروژه، سخته که یک کتابخانه بنویسید که براحتی بتونید بین کتاب خانه های مختلف سوییچ کنید، ما یک معماری و راه ساده پیدا کردیم پس با استفاده از یک پیاده سازی Memory میتونید حتی فایل ها و پوشه هاتون رو توی حافظه بسازید و بدون درگیر بودن با مسائل مثلا دسترسی ها توی Android میتونید ابتدا با این حرکت فرایند اپتون رو تست کنید. سپس که دیدید فرایند درست کار میکنه سوییچ میکنید روی دیسک و دسترسی هاشو اوکی میکنید.


بنابراین ما در پروژه‌ی FileManager یک interface داریم و یک داکیومنت یکسان برای همه‌ی کتابخانه ها مینویسم که هرکسی این داکیومنت رو بخونه میتونه از هر Api ای که توی این بستر پیاده سازی بشه استفاده کنه.

میشه همون هلو بره تو گلوی خودمون 😄

آدرس ریپازیتوری:
https://github.com/EasyMicroservices/FileManager

چطوری #فورک خودمون رو با سورس اصلی سینک کنیم.
حتما براتون پیش اومده که وقتی فورک خودتون رو پول می‌کنید تغییرات سورس اصلی رو دریافت نمی کنید بلکه فقط تغییرات فورک خودتون رو پول می کنید، در ادامه در چند مرحله توضیح میدم که چطوری فورک خودتون رو با سورس اصلی سینک کنید که گاها اگر کانفیلیت دارید بتونید رفعش کنید.
یکی از روش‌ها استفاده از خود گیتهاب هست، همونطور که در تصویر می‌بینید می‌تونید وارد فورک خودتون بشید و روی گزینه‌ی Sync fork کلیک کنید سپس Update branch رو بزنید.

یکی از روش‌های Sync# کردن فورک خودتون با سورس اصلی استفاده از ابزار git هست.
دوتا مفهوم برای این موضوع در گیت وجود داره:
1.Origin
2.Upstream

ابزار cmd رو کنار سورستون اجرا کنید و دستور زیر رو توش بنویسید:
git remove -v

این دستور نسخه های موجود از درس های اون سورس رو روی کامپیوترتون به شما میده برای مثال نمونه‌اش رو در تصویر می‌بیینید که برای من آدرس upstream و آدرس origin تنظیم شده.
برای شما شاید فقط origin تنظیم شده باشه.

در صورتی که میخواید upstream یا origin رو حذف و اضافه کنید می‌تونید از دستورات زیر استفاده کنید.

برای مثال:
git remote add upstream gitRemoteAddress

به جای gitRemoteAddress آدرس گیت سورس اصلی رو بذارید.

اگر خواستید origin رو اضافه کنید به این شکل:
git remote add origin gitRemoteAddress

برای حذف origin هم میتونید از دستور زیر استفاده کنید:
git remote remove origin

برای حذف upstream:
git remote remove upstream

در نهایت همه‌ی این تنظیمات در پوشه‌ی .git که کنار پوشه‌ی سورس ساخته میشه توی فایل config هست.

جلسه‌ی ضبط شده‌ی جمعه 2023-01-06

سوال:
آیا بعد از اینکه پول رکوئست زدیم به ازای تغییراتی که روی همون برنچ میزنیم باید دوباره پول رکوئست بزنیم؟

پاسخ:
خیر، هر پول رکوئستی که می‌زنید در واقع مشخص می‌کنید که کدوم برنچ از روی فورک شما به کدوم برنچ روی سورس اصلی مرج بشه، پس هر تغییری که روی اون برنچ روی فورکتون بفرستید بالا، اتوماتیک روی پول رکوئستی که زدید تغییرات اعمال میشه و Code reviewer ها مجدد باید بررسی کنن. بدون اینکه نیاز باشه کاری انجام بدید، یعنی فقط git push بزنید روی فورکتون کافیه، گیتهاب اونارو بروز میکنه.
دقت کنید که اگر پول رکوئستتون فعال باشه این اتفاق میوفته.

اگر دوتا تغییر متفاوت برای دوتا تسک متفاوت دارید باید روی فورکتون برنچ متفاوت بزنید اینطوری می‌تونید دوتا پول رکوئست رو از هم تفکیک کنید تا کامیت‌هاتون با هم مخلوط نشن.

#پول_رکوئست
#برچ
#branch
#pullrequest

زیرساخت اولیه ریپازیتوری Database رو هم پیاده سازی کردیم روی Ef Core به زودی توسعه های بیشتری روش اعمال می کنیم اما معماریش رو استخراج کردیم که بقیه ی ساختار دیتابیسی هم پیرو اون معماری باشن.
دوستان عزیز میتونید روی زیرساخت دیتابسی زبان های مختلف و ... هم کار کنید.

https://github.com/EasyMicroservices/Database

بالاخره FolderBrowserDialog رو به WPF اضافه کردن 😭😂

خیلی از باگ‌ها و مشکلات اولونیا رفع شده و روی دات نت کور 7 هم قابلیت پیاده سازیش هست.

WPF
روی ویندوز، مک و لینوکس

پروژه‌ی عجیب و بزرگیه...

https://github.com/AvaloniaUI/Avalonia

کلی ریپازیتوری ساختم به ازای میکروسرویس هایی که قراره پیاده سازی کنیم.
قراره تک تک میکروسرویس ها رو پیاده سازی کنیم 😉.

وقتی میکروسرویس ها پیاده سازی بشن، اونوقت دیگه به ازای هر پروژه که میخوایم پیاده کنیم به زمان خیلی کمتری نیاز داریم.
جوین شید و ابراز آمادگی کنید، کلی کار داریم.
@easymicroservice
@easymicroservices

چرا باید از Easy microservices حمایت کنیم؟ 😆

https://www.linkedin.com/posts/guilleojeda_software-architecture-is-cyclic-and-its-activity-7063488919262117889-6D24?utm_source=share&utm_medium=member_desktop

پکیج https://github.com/EasyMicroservices/SMS برای کاوه نگار تا به الان پیاده سازی شده.
چندتا چیز برای یادگرفتن هست:
1.یکپارچه سازی زیرساخت پیامکی
2.مجازی سازی httpclient در تست کیس ها با استفاده از پکیج EasyMicroservices/Laboratory و ببینید که چطوری سرویس کاوه نگار تست هاش زده شده بدون اینکه به لایو خود کاوه نگار درخواست بزنه.
3.پیاده سازی یک سیستم پیامکی جدید روی این ساختار چقدر سریع و آسون خواد بود 😉.

دوستانی که میخوان شروع کنن میتونن سیستم های پیامکی دیگری رو که مد نظرشون هست در این ساختار پیاده سازی کنند.

پکیج https://github.com/EasyMicroservices/Mapper هم برای AutoMapper تا به الان پیاده سازی شده. اگر علاقه مند بودید می‌تونید سر بزنید و issue های مد نظرتون رو براتی دیگر پکیج ها و یا توسعه های جدید رو اعمال کنید.

سلام بچه ها روزتون بخیر.
تا الان حدود 5 تا میکروسرویس رو به مرحله ی استفاده‌ی اولیه رسوندیم و اولین پروژه‌ی لایومون رو داریم روی این بستر پیاده سازی میکنیم که بزودی خبراشو بهتون میرسونیم که چی شد و چیکار کردیم. همچنان دوستانی که جوین شدن دارن با قدرت و سرعت زیر سیستم هارو توسعه میدن، هرچی زودتر به ما جوین شید❤️.
اگریگیتورها که سورس اصلی و داخلی شرکت ها هستن رو اوپن سورس نمی‌کنیم. چون پروژه‌های بزینسی هستن ولی ارائه اش رو بهتون خواهیم داد. اما تجمیع کردن میکروسرویس‌ها و ساخت یک پروژه کار خیلی آسونی میشه.
حمایتمون کنید تا دنیای کار با میکروسرویس رو برای همه آسون کنیم👌.

@easymicroservices

39 پکیج تا الان توی این زیر ساخت پیاده سازی و ریلیز شده.

@easymicroservices
@easymicroservice
@CsharpTips

#تخصصی

در معماری نرم افزار یکی از مولفه‌های مهم «حذف وابستگی» هست.
چطوری بفهمیم معماری نرم افزاری که پیاده سازی کردیم از نظر «حذف وابستگی» داره درست کار میکنه؟
تنها با طرح سوال می‌تونید متوجه معماری درست برای بخش «حذف وابستگی» بشید.
برای مثال:
از چه ابزاری برای کشینگ استفاده می‌کنید؟
پاسخ: Redis
آیا با بسته شدن Redis بخشی از سیستم شما از کار میوفته؟
در صورتی که پاسخ به این سوال بله باشه نشان از ضعف معماری در بخش «حذف وابستگی» هست.
سوال بعدی:
از چه ابزاری برای Api gateway استفاده می‌کنید؟
پاسخ: Ocelot
آیا با از کار افتادن Api gateway ها، بخشی از سیستم شما از کار میوفته؟
پاسخ به این سوال هم مانند سوال قبلی به شما کمک می‌کنه تا راه حل هایی رو برای حذف وابستگی ها در معماری نرم افزار خودتون پیدا کنید.

حذف وابستگی ها در معماری نرم افزار کمک می‌کنه تا اپلیکیشن شما با کمترین خطا در ارائه‌ی خدمات به مشتری به کارش ادامه بده.

#وابستگی
#معماری
#معماری_نرم_افزار

@CSharpTips